|
|
Hi Anjani,
Hope that you and your family are still fine despite this difficult time in India. Welcome to digiKam and GSoC :)
Trung Hello, I'm not sure what to say at this point. These past few weeks have been really difficult for people in India and also me. This comes as such a good news! Thank you for selecting me for GSoC 2021. I hope I do well.
Thanks :) Anjani
Thanks to you too. We will see the feedback from other KDE mentors with your documen.
Best
 Hello, I've submitted the final proposal.
Thanks for all the help :) Anjani
Done. Please take a look...
Hello, I have tried to resolve all the issues. Timeline is modified and more realistic. I think it should be ready for the final submission. Please have look and let me know if i missed something or is there an issue.
Thanks Anjani
This depend of your project advancement.
You must estimate approximately how much time will take each part of digiKam, and make priority of task.
In fact it's a little bit of project management. Interesting no ?
It's acceptable that some tasks cannot be completed in time but, main part must be completed first.
The most important for the moment is to have a global vision of all parts to port, with the estimated working hours, and the priority of task. Of course you will see interdependencies...
Should I mark libO2 part as "pending later". The module will still build with Qt6 and in the timeline it consists of two weeks. Given that I also have an internship, maybe I overestimated a bit. It has 2 week in the timeline, I can use 1 week for the porting work and regression testing and 1 week on the appimage. This will also allow me to have some buffer time so that in case of unexpected events, I can handle the load and meet deadlines with complete work.
Thanks Anjani
No. This part must be done in your project.
Should I mark AppImage builder for future Qt6 "pending later task"?
Ok, well put ICC profile support in a pending list. It's not a priority for your project.
Q : Qt6 do not have color profile support ?
This want mean that we can plan later to port the LCMS2 Qt interface from digiKam core to QColorSpace ?
It just a Q not a goal for your project as color management is really a big component in digiKam :
Note : for all possible Qt6 port but too heavy to be treated in your project, please list in your proposal and mark as "pending later task"
Hello, I talked with krita people. They extract icc info using colord on linux. They don't have anything like this for windows or macOS. All they do is read icc profiles from a system path which is already implemented in digikam
Thanks Anjani
yes, he is right. He has already worked as a student in the past in digiKam and with libO2.
Thanh has proposed to remove the libO2 dependency completely and make a new implementation within digikam using QNetworkAuth as it may be easier than porting whole library and also a dependency will be dropped. Can we do this?
Yes, sure... Linux is the priority for your project
Best
I don't have a windows install right now. I'll have a go at this after I finish and submit the proposal. Will it be fine?
yes, perhaps, it need to be tested. I'm not 100% sure.
But it's out of topic for the Qt6 port, as it native new code to introduce. you can propose a PR at least.
Best
Hum,
I think Qt6 will have ICC profile management. Please double check.
Else, depending to KDE for this very specific feature (color management), will only work under Linux. So it's not the right way.
Look on Krita project which also support MacOS and Windows and has Color Management support.
In all cases, native code (not portable) to handle ICC profile under MacOS and Windows will be easy to found on the web.
And yes, Wayland supports wmust be supported in the future.
Hello, I am working on possible changes in code for future port on windows and macOS. I am using macros Q_OS_WIN and Q_OS_MACOS to look for platform specific code. One issue is the icc profiles. The current implementation doesn't look for profiles on platforms other than X11. I'm not sure how to find a solution to this. I'm trying to find a solution for wayland and so far I've come across colord-kde ( https://invent.kde.org/graphics/colord-kde) which is used to find profiles. Would this do the job for wayland?
Hello, I have tried to resolve all the issues and suggestions in the proposal. There are a few things I would like to clear.
What to do with the rajce plugin? I have proposed that the plugin's new implementation be written when the new api arrives which I don't find it on the website https://www.rajce.idnes.cz/api.
Place Rajce in quarantine if code needs to be ported to a new talker because communication is broken due to changes in web service.
If web service continues to work with current implementation and if Qt6 port needs an extra Qt5 porting help classes propose a temporary solution. Linux port to Qt6 is a prior. For the moment ignore MacOS and Windows OS, but if specificity for non Linux systems exists with Qt6 (as there are few differences with Qt5), well, list the points to take care for the future... All sounds fine to me, as I can see... Thanks Anjani
I think qt6-deprecated-api-fixes option is the culprit though I'm not sure.
Hi,
I can reproduce the crash at around 35% of CLazy compilation.
It Sounds like one of the Qt6 checkers is buggy.
Try to re-run clazy with only with the first Qt6 option enabled to see if it passes. If yes, try again to activate the second, etc... The goal is to determine which option cannot be used.
qt6-qhash-signature generate 1218 warnings
I remove all qt6 checks which includes -fix in name
-- Software Engineer at Kolibree, Baracoda group
Tel: +33 7 53 68 20 29
|
Locked
