Question about the GSoC project
Gilles Caulier
caulier.gilles at gmail.com
Sat Mar 21 13:18:33 GMT 2020
Hi,
The webservices plugins common code from digiKam core are located here :
https://invent.kde.org/kde/digikam/-/tree/master/core%2Flibs%2Fdplugins%2Fwebservices
The core/libs/dplugins is in fact all the API used by digiKam plugins
architecture/interface
Webservice plugins are located here :
https://invent.kde.org/kde/digikam/-/tree/master/core/dplugins/generic/webservices
The unified plugin, not compiled in standard is the tool written by
Thanh 2 years ago while GoSC to factorize webservices plugin in one :
https://invent.kde.org/kde/digikam/-/tree/master/core%2Fdplugins%2Fgeneric%2Fwebservices%2Funified
The goal, as explained Thanh is to be able later to include export
tool to Batch Queue Manager, which use also DPlugins interface :
https://invent.kde.org/kde/digikam/-/tree/master/core%2Futilities%2Fqueuemanager
Actually, there is no export tools in BQM.
But as explained Thanh, the first task on this project is to migrate
O2 library use in export tool to the Qt framework about
authentication. O2 library source code is include in digiKam core as
well:
https://invent.kde.org/kde/digikam/-/tree/master/core%2Flibs%2Fdplugins%2Fwebservices%2Fo2
Best
Gilles Caulier
Le sam. 21 mars 2020 à 09:14, Thanh Trung Dinh
<dinhthanhtrung1996 at gmail.com> a écrit :
>
> Hi Shyngys,
>
> Glad to hear that you are interested in digiKam project for GSoC. I can't answer all of your questions but some of them. Hope that it could help you understand better the project.
>
> So currently some of the export tools are implemented with libo2 (an old implementation of OAuth2 on Qt), other tools have a pure Qt implementation of OAuth1 (only with QtNetworkManager nà stuffs). Hence, one of the important points for this project is to migrate to QtNetworkAuth, which provides a better implementation of such protocols and supports a wide range OAuth1, OAuth2, etc.
>
> The wizard is actually developed to centralize the tools. It is supposed to replace the windows for each tool, providing a more complete GUI for user using webservices (i.e. the export tools mentioned). Thus, another important point is to finish the dev on wizard and make it work with Batch Queue Management and Plugin Architecture.
>
> Hope this helps.
>
> Best,
> Trung
>
>
> On Thu, Mar 19, 2020, 23:33 Chingiz Kazbekov <artka.kazaktar at gmail.com> wrote:
>>
>> Hello everyone! I have a question about the
>>
>> Project: Factoring all Export Tools with new Export API and port to QtNetworkAuth
>>
>> In particular, I would like to get a more clear understanding of new talker(export) API and wizard dialog. So there are "export to webservice" plugins each of which has its own *talker class that does the oauth2 authorization and photo uploading, and its own *window class which is a photo uploading GUI that is unique to that webservice. Now what I'm finding hard to understand is in what way specifically new export API and wizard dialog supposed to replace that? When exporting to Imgur for example, will the GUI stay the same and the student just needs to change the plugin so that it uses the new talker API? Or will all the options in the "Export" menu item be replaced with one option: to export, and then the choice of webservice will be made in the wizard dialog? What's the purpose of the wizard dialog? To replace all those webservices' *window classes?
>>
>> So in short what I'm finding hard to understand is the purpose of new talker API and especially wizard dialog, and how do they both tie with each other and the existing code. I would be really glad if you could clarify those questions for me.
>>
>> Shyngys Kazbekov,
>> artka.kazaktar at gmail.com,
>> Telegram @chechenitza,
More information about the Digikam-devel
mailing list