Digikam GSoC 2021

Anjani Kumar anjanik012 at gmail.com
Sun Apr 11 19:52:43 BST 2021


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

On Apr 11 2021, at 5:41 pm, Gilles Caulier <caulier.gilles at gmail.com> wrote:
> 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...
>
> Gilles Caulier
> Le dim. 11 avr. 2021 à 13:59, Anjani Kumar <anjanik012 at gmail.com (mailto:anjanik012 at gmail.com)> a écrit :
> > 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
> >
> > On Apr 11 2021, at 5:17 pm, Gilles Caulier <caulier.gilles at gmail.com (mailto:caulier.gilles at gmail.com)> wrote:
> > > No. This part must be done in your project.
> > >
> > > Gilles Caulier
> > > Le dim. 11 avr. 2021 à 13:38, Anjani Kumar <anjanik012 at gmail.com (mailto:anjanik012 at gmail.com)> a écrit :
> > > > Should I mark AppImage builder for future Qt6 "pending later task"?
> > > >
> > > > On Apr 11 2021, at 4:01 pm, Gilles Caulier <caulier.gilles at gmail.com (mailto:caulier.gilles at gmail.com)> wrote:
> > > > > 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 ?
> > > > >
> > > > > https://doc-snapshots.qt.io/qt6-dev/qcolorspace.html
> > > > >
> > > > > 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 :
> > > > >
> > > > > https://invent.kde.org/graphics/digikam/-/tree/master/core/libs/dimg/filters/icc
> > > > > https://invent.kde.org/graphics/digikam/-/tree/master/core/libs/widgets/iccprofiles
> > > > >
> > > > > 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"
> > > > >
> > > > > Best
> > > > > Gilles Caulier
> > > > >
> > > > >
> > > > >
> > > > > Le dim. 11 avr. 2021 à 12:07, Anjani Kumar <anjanik012 at gmail.com (mailto:anjanik012 at gmail.com)> a écrit :
> > > > > > 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
> > > > > >
> > > > > > On Apr 11 2021, at 3:10 am, Gilles Caulier <caulier.gilles at gmail.com (mailto:caulier.gilles at gmail.com)> wrote:
> > > > > > > yes, he is right. He has already worked as a student in the past in digiKam and with libO2.
> > > > > > >
> > > > > > >
> > > > > > > Gilles Caulier
> > > > > > > Le sam. 10 avr. 2021 à 23:38, Anjani Kumar <anjanik012 at gmail.com (mailto:anjanik012 at gmail.com)> a écrit :
> > > > > > > > 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?
> > > > > > > >
> > > > > > > > On Sun, Apr 11, 2021, 2:55 AM Gilles Caulier <caulier.gilles at gmail.com (mailto:caulier.gilles at gmail.com)> wrote:
> > > > > > > > > Yes, sure... Linux is the priority for your project
> > > > > > > > >
> > > > > > > > > Best
> > > > > > > > >
> > > > > > > > > Gilles Caulier
> > > > > > > > > Le sam. 10 avr. 2021 à 22:59, Anjani Kumar <anjanik012 at gmail.com (mailto:anjanik012 at gmail.com)> a écrit :
> > > > > > > > > > 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?
> > > > > > > > > >
> > > > > > > > > > On Apr 11 2021, at 2:25 am, Gilles Caulier <caulier.gilles at gmail.com (mailto:caulier.gilles at gmail.com)> wrote:
> > > > > > > > > > > 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
> > > > > > > > > > >
> > > > > > > > > > > Gilles
> > > > > > > > > > > Le sam. 10 avr. 2021 à 22:53, Anjani Kumar <anjanik012 at gmail.com (mailto:anjanik012 at gmail.com)> a écrit :
> > > > > > > > > > > > I found this for windows. https://stackoverflow.com/a/64427505/5859944 (https://link.getmailspring.com/link/E22AC420-E871-4673-B30D-1DE013D36CD2@getmailspring.com/0?redirect=https%3A%2F%2Fstackoverflow.com%2Fa%2F64427505%2F5859944&recipient=ZGlnaWthbS1kZXZlbEBrZGUub3Jn). It is not portable since it is native code.
> > > > > > > > > > > >
> > > > > > > > > > > > On Apr 11 2021, at 2:20 am, Gilles Caulier <caulier.gilles at gmail.com (mailto:caulier.gilles at gmail.com)> wrote:
> > > > > > > > > > > > > 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.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Gilles Caulier
> > > > > > > > > > > > > Le sam. 10 avr. 2021 à 21:10, Anjani Kumar <anjanik012 at gmail.com (mailto:anjanik012 at gmail.com)> a écrit :
> > > > > > > > > > > > > > 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 (https://link.getmailspring.com/link/3A14941A-EC0C-4DE2-83E5-EC7C85B56AB5@getmailspring.com/0?redirect=https%3A%2F%2Finvent.kde.org%2Fgraphics%2Fcolord-kde&recipient=ZGlnaWthbS1kZXZlbEBrZGUub3Jn)) which is used to find profiles. Would this do the job for wayland?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Apr 9 2021, at 2:08 am, Gilles Caulier <caulier.gilles at gmail.com (mailto:caulier.gilles at gmail.com)> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Le jeu. 8 avr. 2021 à 20:16, Anjani Kumar <anjanik012 at gmail.com (mailto:anjanik012 at gmail.com)> a écrit :
> > > > > > > > > > > > > > > > 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 (https://link.getmailspring.com/link/68541209-B0CE-406B-933C-486035A904D6@getmailspring.com/0?redirect=https%3A%2F%2Fwww.rajce.idnes.cz%2Fapi&recipient=ZGlnaWthbS1kZXZlbEBrZGUub3Jn).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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.
> > > > > > > > > > > > > > > > Why is it necessary to include changes in classes for platforms macOS and Windows if this project focuses on the Linux port? I have no issues in adding this. It is just that I am trying to understand why.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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...
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I have made some changes to the timeline. Please point out any issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > All sounds fine to me, as I can see...
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks
> > > > > > > > > > > > > > > > Anjani
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Apr 8 2021, at 6:20 pm, Anjani Kumar <anjanik012 at gmail.com (mailto:anjanik012 at gmail.com)> wrote:
> > > > > > > > > > > > > > > > > I think qt6-deprecated-api-fixes option is the culprit though I'm not sure.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Apr 8 2021, at 6:16 pm, Gilles Caulier <caulier.gilles at gmail.com (mailto:caulier.gilles at gmail.com)> wrote:
> > > > > > > > > > > > > > > > > > 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.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Gilles Caulier
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > qt6-qhash-signature generate 1218 warnings
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > https://www.digikam.org/reports/clazy/master/#
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I remove all qt6 checks which includes -fix in name
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Gilles Caulier
> > > > > > > > > > > > > > > qt6-qhash-signatureqt6-qhash-signature (https://github.com/KDE/clazy/blob/master/docs/checks/README-qt6-qhash-signature.md)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20210412/c63d72ee/attachment-0001.htm>


More information about the Digikam-devel mailing list