Hello everyone! I have a question about the
Project: Factoring all Export Tools with new Export API and port to QtNetworkAuthIn 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, Telegram @chechenitza, |
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 <[hidden email]> wrote:
|
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 <[hidden email]> 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 <[hidden email]> 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, >> [hidden email], >> Telegram @chechenitza, |
Free forum by Nabble | Edit this page |