[Digikam-devel] Re: Needing ideas for Rosedu's Open Source Development Course

[Michael G. Hansen]

On 01/05/2011 12:36 PM, Gilles Caulier wrote:
> 2011/1/5 Gabriel Voicu<ping.gabi at gmail.com>
>
>> Hi Gilles,
>>
>> Thank you very much for this long answer! I will speak today with the
>> organisers and see what they have to say.
>>
>> Also, be sure that I was not thinking in starting a junior job project
>> inside digikam's core, because it's under heavy development for the 2.0
>> version. The ideal project would be modifying a GUI for a plugin(album or
>> KIPI, doesn't matter).
>> Do you have in mind a plugin that should need GUI refactoring? If yes,
>> please let me know, because I couldn't find any example on Bugzilla.
>>
>
> FIRST IDEA :
> ---------------
>
> yes, some plugins need factoring about image list widget:
>
> - DNG converter.
>
> http://websvn.kde.org/trunk/extragear/graphics/kipi-plugins/dngconverter/plugin/clistviewitem.h?revision=1194262&view=markup
>
> - Batch RAW Converter.
>
> http://websvn.kde.org/trunk/extragear/graphics/kipi-plugins/rawconverter/clistviewitem.h?revision=1040597&view=markup
>
> - IPodExport
>
> http://websvn.kde.org/trunk/extragear/graphics/kipi-plugins/ipodexport/IpodListItem.h?revision=1033800&view=markup
>
> All these tools use a dedicated list widget of items to process.
>
> The common widget is KipiPlugins::ImagesList :
>
> http://websvn.kde.org/trunk/extragear/graphics/kipi-plugins/common/libkipiplugins/widgets/imageslist.h?revision=1181681&view=markup
>
> It's already used here for ex :
>
> http://websvn.kde.org/trunk/extragear/graphics/kipi-plugins/sendimages/imagespage.cpp?revision=1058617&view=markup
>
> http://websvn.kde.org/trunk/extragear/graphics/kipi-plugins/picasawebexport/picasawebimglist.h?revision=1114544&view=markup
>
> http://websvn.kde.org/trunk/extragear/graphics/kipi-plugins/expoblending/importwizard/itemspage.cpp?revision=1069270&view=markup

I have already a model-view 'ported' version of KipiPlugins::ImageList 
that I used in gpssync. At first I kept it general, but then specialized 
it for gpssync, but of course one could de-specialize it easily and 
merge it into the other plugins. I think the only specialization is that 
kipiimageitem has not virtual functions any more.

http://websvn.kde.org/branches/extragear/graphics/digikam/extra/kipi-plugins/gpssync/kipiimagelist.cpp?view=log

Another more easy task:
In gpssync, we currently load only gpxfiles, and merge all the tracks. 
Here, one could easily extend the loading code to keep track of 
individual tracks, and also support kml files, as they are also XML. The 
code for this is currently supplied in only a few classes, and the task 
would include writing unit-tests (some already exist) to prove that the 
classes work as expected (time zones, different gps receivers, 
multitasking on one/many cores, etc). The next step would be to display 
the gpx/kml files and their tracks in a list in gpssync:

GPX-file-a
-- track 1
-- track 2
-- track 3
GPX-file-b
-- track-1
-- track-2

The user should be able to remove files or individual tracks from the 
list, or select some to be used for correlation. Later, we also want to 
display these tracks on the map, so a visible/invisible button would be 
nice, but display on the map would be outside of the scope of this project.

Since this should also be model-view based, the list can also be 
demonstrated to work in a simple test application, with a window 
containing only the list. If one wants to, all the loading/model code 
could be grouped to appear to the outside as coherent as a library, to 
be later moved into libkmap, as the code could be used inside digikam, 
too. For this task, one would learn about sax-style xml parsing and 
model/view programming in Qt.

http://websvn.kde.org/branches/extragear/graphics/digikam/extra/kipi-plugins/gpssync/gpsdataparser.cpp?view=log

Another idea would be to develop a unified export plugin. This, however, 
would be a much more advanced task. The idea would be that one dialog 
has all common configuration options for export, like resizing, deleting 
of personal information, etc., and that each export backend then 
supplies a dialog with special options, like login, visibility to other 
people, etc. For each export backend which is configured, the plugin 
could export an action to the menu. Then the user would only see menu 
entries for exports that he actually uses. Here, one group could code on 
the main dialog, with the other groups working on porting the individual 
export plugins to it. But of course, everything would depend on the 
'core' group.

Michael