|
Hi everyone,
ROSEDU (Romanian Open Source Education) people are organising an Open Source Development Course, where they teach a group of selected students (aprox. 30 students) about tools used in open source development. Also, during the course, the students will be grouped in teams of 3-4 to work on a contribution to an existing open-source software. Each group of students is coordanated by a menthor.
Because I participated in the last year GSoC, the organisers invited me to be a menthor for a team and propose a project related to Digikam/KIPI Plugins. Now, I would like to know if you have some junior jobs for Digikam or KIPI Plugins that will not involve more than 5-6 hours/week for 7-8 weeks. The projects should contains easy things to do, like modifying a UI or make some small changes in different parts of Digikam. I mention that the course will be from the start of March until the the start/middle of May.
If you have any ideas, please tell me as soon as possible, because I should speak with the organisers until Wednesday 5th January. Also, it's no problem if you tell me after 5th January. :-) Best wishes,
Gabriel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Hi,
I remember seeing couple UI mockups here on ML, but noone really got through (what happened to that new statusbar thinggy?). So maybe after some consultation with Gilles or Marcel, you could work on these. Also adding some decent animations could refresh the UI. You could also help porting the rest of Qt3 stuff to Qt4/kdelibs (btw. the thumbbar centering of the selected image doesn't work, I tried to fix that, but with no luck. Also the Qt4 views have better methods for handling this). That's all I can think of right now :) Marty On Monday, January 3, 2011, Gabriel Voicu <[hidden email]> wrote: > Hi everyone, > ROSEDU (Romanian Open Source Education) people are organising an Open Source Development Course, where they teach a group of selected students (aprox. 30 students) about tools used in open source development. Also, during the course, the students will be grouped in teams of 3-4 to work on a contribution to an existing open-source software. Each group of students is coordanated by a menthor. > > Because I participated in the last year GSoC, the organisers invited me to be a menthor for a team and propose a project related to Digikam/KIPI Plugins. Now, I would like to know if you have some junior jobs for Digikam or KIPI Plugins that will not involve more than 5-6 hours/week for 7-8 weeks. The projects should contains easy things to do, like modifying a UI or make some small changes in different parts of Digikam. I mention that the course will be from the start of March until the the start/middle of May. > > If you have any ideas, please tell me as soon as possible, because I should speak with the organisers until Wednesday 5th January. Also, it's no problem if you tell me after 5th January. :-) > > Best wishes, > Gabriel > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Hi,
Thank you very much, Martin, for the ideas! They indeed sound good for this kind of project. Gabriel
On Tue, Jan 4, 2011 at 1:21 AM, Martin Klapetek <[hidden email]> wrote: Hi, _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Hi Gabriel,
In general, for junior jobs, i recommend to take a look into components outside digiKam core. Why ? because it can have side-effect with the whole program to touch in this area. It must be better to take a look in plugins. You have 2 way : 1/ plug-ins for image editor. 2/ plug-ins for album gui (kipi-plugins). Now how to select job ? Use bugzilla and look Wishes files by preference order. Bugs can be more complex to fix and can take a while. In all case, use bugzilla for each entry found and post messages and patches by this way. This is the best QA work-flow. I don't recommend to use kde review tool. It's not link to bugzilla, and it's complex to follow in time. Do not use devel mailing list directly. Use bugzilla instead. All post from bugzilla are posted in this mailing list. For new idea, i recommend also to use bugzilla, and create new entries with attached patches. Like you can see, the main tool is bugzilla. Another idea is to review all entries with patch attached. All these entries have "[patch]" annotation in the title. It's easy to find these entries with bugzilla search engine. Now the ultimate question which code to patch ? - If patch is not too intrusive, 1.x from trunk can be patch, and later code backported to GoSC 2010 branch. - If patch is intrusive, it's will be better to use GoSC2010 branch. Don't forget that trunk is stable used in production, and we trying to stabilize this code now. We plan 1.8 and probably 1.9 release including minors changes. I hope these tips will help you in this task... Best Gilles Caulier 2011/1/4 Gabriel Voicu <[hidden email]> Hi, _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
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. Best Regards, Gabriel Voicu On Tue, Jan 4, 2011 at 9:54 AM, Gilles Caulier <[hidden email]> wrote: Hi Gabriel, _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Hey,
Am 05.01.2011 12:23 schrieb Gabriel Voicu: > 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. There are still some improvements possible in the exposure blending plugin. For example sometimes an error is reported that a file could not be stored and so on. Also some usability tweaks would really help. Johannes _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Hi,
Thank you Gilles and Johannes for the ideas! I will present them tonight when I meet to the course organisers. Have a nice day, Gabriel Voicu On Wed, Jan 5, 2011 at 1:36 PM, Gilles Caulier <[hidden email]> wrote:
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gabriel Voicu
2011/1/5 Gabriel Voicu <[hidden email]> Hi Gilles, SECOND IDEA : ------------------- Merge MetadaEdit EXIF/IPTC/XMP dialogs to one dialog with tabs. The goal is to reduce MetadataEdit menu enties in kipi host application. Currently, we can edit Exif or Iptc, or Xmp using dedicated dialog. it's too long if users want to modify Exif and Xmp values for ex. it need to open/close 2 dialogs The idea is to take exif, iptc, and xmp dialog content and to create a common dialog with tabs to host exif, iptc, and xmp settings. The settings gui and backgroud metadata process implementation do not change but must be factored in the same implementation or something like that. It's purely a gui factoring. There is entries in B.K.O about : https://bugs.kde.org/show_bug.cgi?id=208502 Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gabriel Voicu
In MetadaEdit plugin there are some easy fix entries, i think :
https://bugs.kde.org/show_bug.cgi?id=251349 https://bugs.kde.org/show_bug.cgi?id=208500 https://bugs.kde.org/show_bug.cgi?id=203047 A little bit more complex is this one : https://bugs.kde.org/show_bug.cgi?id=251278 Gilles 2011/1/5 Gabriel Voicu <[hidden email]> Hi Gilles, _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
THIRD IDEA :
--------------- This entry, about WallPaper plugin can be done. It's not too complex i think : https://bugs.kde.org/show_bug.cgi?id=254932 The goal is to be able to post an image in desktop backgroud. This tool existed for KDE3, not KDE4 due a lack of feature in Plasma. This require probably something to do in Plasma code (an xml config file to create, i'm not sure) Else, there is api available in KDELibs. Review bug file comment for details. Gilles Caulier 2011/1/5 Gilles Caulier <[hidden email]> In MetadaEdit plugin there are some easy fix entries, i think : _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gilles Caulier-4
On 01/05/2011 12:36 PM, Gilles Caulier wrote:
> 2011/1/5 Gabriel Voicu<[hidden email]> > >> 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 _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gilles Caulier-4
4th IDEA :
------------ In AdvancedSlideshow, there are some easy fix reports about GUI : https://bugs.kde.org/show_bug.cgi?id=122284 https://bugs.kde.org/show_bug.cgi?id=261862 https://bugs.kde.org/show_bug.cgi?id=240147 https://bugs.kde.org/show_bug.cgi?id=238598 More complex : https://bugs.kde.org/show_bug.cgi?id=130786 Gilles Caulier 2011/1/5 Gilles Caulier <[hidden email]> THIRD IDEA : _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gilles Caulier-4
GalleryExport plugin do not use ImagesList widget from kipi-plugins :
https://bugs.kde.org/show_bug.cgi?id=154699 It's also the case about PiwigoExport tool. Both tool use the smae gui implementation (not factored) Gilles Caulier 2011/1/5 Gilles Caulier <[hidden email]>
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Michael G. Hansen
On 01/05/2011 01:02 PM, Michael G. Hansen wrote:
> On 01/05/2011 12:36 PM, Gilles Caulier wrote: >> 2011/1/5 Gabriel Voicu<[hidden email]> >> >>> 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. >>> We also still don't have any code that saves people tags with regions to files. We discussed some possible options about using RDF etc. So here one could write code that takes a face tag with region coordinates, and writes it into XMP via libkexiv2, and can also produce a face tag from the XMP. Here, one would need to know the representation of face tags inside digikam, and then spend some time getting save/load code to work using test based development, without touching any digikam code. Once the code is done, either the students or a digikam developer would integrate it into the image metadata load/save routines of digikam. Document containing research on face tag representations: http://websvn.kde.org/branches/extragear/graphics/digikam/core/project/documents/ImageAnnotation.odt?view=log I think at the last sprint, we were most favorable of the scheme used my Masahide Kanzaki: http://www.kanzaki.com/docs/sw/img-annotator.html Required knowledge would be RDF/XMP, and how libkexiv2 represents it. Michael _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gabriel Voicu
5th IDEA :
----------- This time, in digiKam Slideshow tool (not advanced slideshow kipi-plugin), i would like to see world map displayed somewhere in the corner : https://bugs.kde.org/show_bug.cgi?id=159824 it's easy to do with libkmap i think... You know better than me (:=)))) Video support in slideshow can be implemented easily using Phonon widget: https://bugs.kde.org/show_bug.cgi?id=159824 It's already done in preview mode by digiKam : http://websvn.kde.org/*checkout*/trunk/extragear/graphics/digikam/digikam/mediaplayerview.h?revision=1200823 Code must be factored there between slideshow and preview mode to support video files. These jobs are not too intrusive in digiKam. Gilles Caulier 2011/1/5 Gabriel Voicu <[hidden email]> Hi Gilles, _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gabriel Voicu
6Th IDEA :
------------- Following idea from Michael about to tag a specific image region in digiKam core, there is a file that i want to see implemented in digiKam since a long time : Color Label . This feature already exist in all major photo management softwares, as Aperture or LightRoom. this feature help a lots during photo selection process : https://bugs.kde.org/show_bug.cgi?id=152424 In GUI, it's not too complex to implement using Model view. But this require path in database schema... Gilles Caulier 2011/1/5 Gabriel Voicu <[hidden email]> Hi Gilles, _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gabriel Voicu
Hi,
if there's interest to learn multithreading: Some plugins work in the event loop. Try the timeadjust plugin with 1000 images, it takes minutes and is unresponsive. This may be a small task, may be not depending on the programming experience. Marcel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Michael G. Hansen
On 01/05/2011 01:13 PM, Michael G. Hansen wrote:
> On 01/05/2011 01:02 PM, Michael G. Hansen wrote: >> On 01/05/2011 12:36 PM, Gilles Caulier wrote: >>> 2011/1/5 Gabriel Voicu<[hidden email]> >>> >>>> 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. >>>> http://apachelog.wordpress.com/2011/01/05/phonon-loves-codecs/ In this blog post, KPackageKit intregration into solid is mentioned, which installs some codecs semi-automatically. For digikam, a similar technique would be useful to: - install opencv haar cascades (see https://bugs.kde.org/show_bug.cgi?id=262074 ) - install the documentation when the user clicks into the Help menu. There has been a discussion about documentation not being included into the digikam package by default by some distributions, and this would be one way to solve this issue. I honestly don't know anything about PackageKit, so some research would have to be done. There may be other cases where it could be useful in digikam, maybe installing kipi-plugins if they are not installed yet. Michael _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gabriel Voicu
Gabriel,
As for Martin, I edited your Bugzilla right as Admin. Like this you can manage entries like you want for the event. Gilles Caulier 2011/1/3 Gabriel Voicu <[hidden email]> Hi everyone, _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
| Free forum by Nabble | Edit this page |
