[KPhotoAlbum] License for PositionBrowserWidget

Johannes Zarl-Zierl johannes at zarl-zierl.at
Fri Dec 23 14:53:31 CET 2016

Hello again,

One thing I missed yesterday was the lack of a license header for the PositionBrowserWidget .cpp and .h files.
I have to ask:
Is it ok to use the same header (GPLv2) that we use for all other C++ files?

Cheers, Johannes

Am 22. Dezember 2016 22:30:26 MEZ, schrieb Johannes Zarl-Zierl <johannes at zarl-zierl.at>:
>Hi Matthias,
>On Samstag, 17. Dezember 2016 19:19:45 CET Matthias Füssel wrote:
>> So the attached patch creates a "map browser" similar to the category
>> browser and folder browser. This browser shows a map with all images
>> match the current filter criteria. When you select a region, it adds
>> another filter that matches all images that have a geolocation and
>> inside the selected area.
>I really like it. I've added a feature branch BrowserGeoPositionPage to
>the development of the patch(set).
>> There are a few limitations:
>>  * There are no optimisations for large numbers of images on the
>> side: Everything works surprisingly well for a few thousand images,
>but if
>> you have a lot more images with geo tags and use the map browser on
>all of
>> them, things will probably get very slow. Workaround: Use other
>> before the map browser (e.g. the timeline) to reduce the number of
>> the map browser has to deal with.
>Fair enough. The same problem exists in the annotation dialog. A
>indicator and the possibility to cancel and go back to the previous
>page would 
>probably reduce the practical impact of this issue...
>>  * Once you have selected the map browser, it is not very obvious
>what you
>> should do: you have to guess that you should draw a rectangle, have
>to find
>> that (rather small) button to switch to "region selection mode" and
>> have to draw the rectangle using the rather unintuitive "2 click"
>> (instead of "click and drag").
>>  * If you use more than one geoposition filter in the same "query",
>I'm not
>> sure if every variation of using the breadcrumbs will behave as
>> (just using "back" and "forward" works).
>That will need some testing. I hope that other people will try out the
>branch and give their feedback...
>>  * I've tried not to break compiling KPhotoAlbum without kgeomap
>> but have never tested whether it actually works.
>It did not. But I've fixed it before committing your patch.
>> For these reasons -- and because it duplicates functionality that is
>> there -- I'm not sure whether this should be included in the
>> release. But since it works quite well for me, I want to share it
>> everybody who likes it ;-)
>This is definitely something that I (and probably others) want in KPA.
>I think 
>I even think I remember a short discussion when Tobias added the
>functionality that such a page would be nice. It's just that nobody
>ever got 
>around to do actually implement it ;-)
>  Johannes

More information about the KPhotoAlbum mailing list