[Digikam-devel] gpssearch improvment

Gabriel Voicu ping.gabi at gmail.com
Tue Jul 27 13:40:00 BST 2010


On Tue, Jul 27, 2010 at 3:03 PM, Gilles Caulier <caulier.gilles at gmail.com>wrote:

> Some remarks before to respond properly to your questions :
>
> 1/ There is no map settings used by default (save and restore this
> settings is important there). Typically, i cannot see a map view in
> this sidebar, until i set one in right menu.
>
> Yes, I didn't add a map backend as default because of database work. I will
add this in the future commit.


> 2/ With Googlemaps and marble, if i click to a group of items, nothing
> happen in icon view.
>
> 3/ sidebar tab layout : i recommend to add an horizontal splitter to
> be able to resize map view and map search album list with large
> screen. It will improve usability.
>
> OK, I will add one.


> 4/ I'm not able to make a selection with googlemaps, as with marble.
>
> 5/ CTRL + mouse left button create a selection rectangle on canvas.
> It's fine, but nothing happen on icon view.
>
> I use marble from KDE 4.4.3 (marble 0.9.3).
>
> Yes, the selection is not working now because it's work in progress. I've
asked you all this questions before implementing to see if you all agree
with my changes.


> 2010/7/26 Gabriel Voicu <ping.gabi at gmail.com>:
> > Hi everyone,
> >
> > As you may have seen, I've start changing gpssearch from the oldversion
> > using marble to the new version using libkmap. Now, me and Michael have
> came
> > with some ideas about how this should look, but if you think that we
> should
> > change something, please let us know. I will copy/paste fragments from an
> > e-mail from Michael because he explained very well the options and
> comment
> > on them.
> >
> > " We have to think about how the user actually performs a search. In the
> > current implementation, he has to control+left-click to start a search
> > rectangle. With the thumbnails shown even before a search is started, I
> see
> > two ways:
> >
> > 1a) Still using some sort of selection rectangle. Since we can probably
> not
> > handle the control modifier on mouse clicks in the Google Maps backend,
> we
> > could instead introduce 'mouse modes'. By this, I mean buttons which
> change
> > what the mouse does. In the old search there are already mouse modes like
> > 'Pan', 'Select', 'Filter' and 'Zoom'. We could make a 'Start search
> > rectangle' mouse mode, where the user clicks a button, then clicks on the
> > map, and a rectangle appears as he drags the mouse. This should be doable
> in
> > both Marble and Google Maps.
>
> I like the mouse modes. dragging selection rectangle will be nice too...


We will use dragging selection rectangle for both Marble and Google Maps.

>
> >
> > 1b) Obviously, users will try clicking on thumbnails. They would probably
> > expect to then see the images belonging to the thumbnail in the album.
> There
> > are two issues with this:
> >
> > 1b1) Currently, the map search albums are rectangular lat/lon areas. The
> > grouped images, however, are not rectangular areas in some cases, because
> if
> > there are some images left between two groups, they are given to one of
> the
> > adjacent groups. So if a user clicks on a thumbnail indicating 100
> images,
> > depending on how we define the rectangle, he may get more or less images.
>
> This depand of projection mode over the canvas, and the precision of
> selection, due to zoom level. If yes, why not to introduce an average
> of selected zone to query DB to limit error prone ?
>

The mainly error comes from the thumbnails size. For example, let's say we
have some photos grouped as a thumbnail big as Paris and some photos very
close to Paris. Also, let's say that we want to select all the photos from
Paris. If we click that big thumbnail, it's a very big chance that the
photos around Paris be also selected, because they have been "eaten" by the
Paris thumbnail when we made it larger. To see how this process works, make
the thumbnails from gpssearch smaller and bigger by clicking 'T+' or 'T-'
buttons.
By using the selection rectangle we have more precision because we select
the points where the query will be made. And this error precision is more
accurate than the grouping selection.

>
> >
> > 1b2) If a user has clicked on one image, then clicks on another, do we
> only
> > show images belonging to the new click? Or do we add some sort of way to
> do
> > 'control+click' to add to the existing selection? To handle this, we will
> > need multiple search areas at once and will have to extend the map search
> > album code."
>
> Do you confuse search geolocation tool on the left and geolocation
> viewer on the right ?
>

No, there was no confusion. Here, Michael reffered to the case where
selection would have been based on groups (click on thumbnails) instead of
rectangles. Since we are all decided to use rectangles as selection, we
don't have to worry about this.

>
> >
> > Taking in consideration his good analysis, I've thought that it should be
> > better to keep the rectangle selection because it's more precise than the
> > group selection. Another positive thing about rectangle selection would
> be
> > the the small amount of actions to select photos(2 clicks and some mouse
> > movement vs (number of groups) * clicks). Is this OK for you?
> >
> > Another thing would be:
> >
> > "2) Now let's say a user has made a selection, either using a rectangle
> or
> > by clicking on a thumbnail. We then create a map search album from the
> > coordinates. What should happen on the map? Do we hide all other markers
> > outside of the selection? Or do we just gray them out?
>
> gray ou sound like fine for me. How other similar search map tools
> work in this case ?
>
> >
> > 3) Interaction with the images in the search range: Currently, you can
> > easily filter the album view by clicking on a thumbnail. I find this
> quite
> > useful,
>
> me too.
>
> >because you can quickly refine a search to have a look at some
> > images, without having to do a new selection. So I would like to keep
> this
> > possibility. Another thing we offer is selecting images on the map, and
> > making this selection correspond to the selection in the album view. Not
> > sure how much this is actually used.
> >
> > 4) If we hide the images outside the search range, we can make the points
> > noted in 5) easier by removing the database based marker tiler from the
> > kmap, and instead showing the images from the model displayed in the
> album
> > view. If we get access to a selection model, many things are already
> solved.
> > We then only have to implement filtering."
> >
> > I find hiding the selected markers/thumbnails outside selection the best
> and
> > easy way to do it, as Michael said. It would be more faster(less
> > transactions to database) and it's more intuitive for the user. Also,
> please
> > let me know if you are OK with this.
> >
>
> no idea. i need to have a demo or better to see this feature in action
> on my computer.
>

OK, I will announce you when I finish this part to proper test it and tell
me what you think.


Gabriel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20100727/b1d47a2d/attachment.html>


More information about the Digikam-devel mailing list