just curious. what's stopping you from changing the default single click behavior for desktop?

it is a topic that interests me also.

i had even made a patch to handle the case in 0.7.3 (maybe applicable to 0.7.4)
and to "correct" the behavior on the single click (5 lines patch)
to select a photo.

i would also like an extended patch, to select this mode in the configuration
as the user wishes.

I find the software barely unusable without my little personal patch. (personal opinion, maybe not yours)
then I keep it and manually apply and ajust every time i compile a new version.

The proposed Configuration option would please me also very well.

I have forgetted to answer the question from renchi.

The reason to not change the default behavior of the desktop
is that the desktop is perfectly handy with the single click usage
but the opening of the photos in digikam is not.

I Prefer the single click on desktop to execute a program,
but the single-click in digikam to select the photo
and double-click to open the editor.

By making the option configurable, everyone can handle it 
the way it prefers. (again , personal taste)

Single click (sc) is _far_ superior than double click (dc), just ask my 65+ year old parents ;-) KDE is since ever per default a sc system and every application has to take care that it also works without dc.
  
But if you used to use sc you are also trained to use ctrl or shift for advanced selection, so per se there is no problem with digiKam.

Mixing sc and dc is IMHO a clear no go! There is one KDE app that also has this problem and a config option and that is kaddressbook. Maybe time to find a good solution for multi-select and edit in sc systems? 

For digiKam a small tag box or a collection drop area would increase usability and IMHO this is also criticized by "Kelly Penguin Girl" in
http://www.thepodcastnetwork.com/linuxuser/2005/08/15/the-gnulinux-user-show-11/

There is a patch in the Devel-ML to have make a selection by clicking image border ( http://bugs.kde.org/show_bug.cgi?id=110178 ).

Bye

  Thorsten

Regarding the question (comment #1) and the subsequent comments regarding the standard KDE single click action - I normally prefer single click in most cases, but it doesn't seem appropriate here.

Agree that there should be a single KDE standard, but only where it is a reasonable thing to do in the circumstances.  For Konqueror whether in its file manager or web browser mode it works, since the primary task of that application is opening files or following hyperlinks respectively - there is also a reasonable amount of blank space (in the icon view at least) allowing the selection to be easily cleared with a click outside.  But for an application such as digiKam which has an extensive set of operations that can be applied to a selected image (view/edit the image, view/edit tags/properties/comments, assign/remove tags, go on to select others...) there is not so much point having the single click do just one of these, especially at the cost of popping up an obtrusive new window *and* clearing the selection.

The patch referred in comment #4 helps, but not as much as the double-click option would do.

For another example of where it is not sensible to maintain the systemwide selection model in all cases, consider Windows XP's printing dialogue.  The list of printers has single click activation, but it's not what is normally needed: the user will usually want to first choose a printer and then set printing options before starting to print.  Unfortunately that's not the way it works - clicking on a printer in the list immediately starts printing on that printer, with the user having to remember to Ctrl-click the printer if wanting to select a new printer and set options before starting to print.  The single click model is completely wrong here.

I'll work on a patch (with configuration option) after I get back from holiday...

My answers to Renchi:
I won't change a global option, which is set to the value I generally prefer, to fix an issue with a single application.

So the question is: Why do I prefer single-click everywhere but in digikam?
Because it is quite different from a file manager. There is a clearly defined "primary action", which is opening. You can do renaming, moving, deleting, but if you open Konqueror in ~, with 80% of your clicks you will want to open a file, even more with a directory.

In digikam, there is no such outstanding action. I may want to tag, view properties, show a group of pictures in a slideshow, etc. Also note that operations on a group of pictures are probably much more common than on a single one. I would even argue that selecting is the one primary action, but this might be very different with your and others' way to use digikam.

So I do not say "opening should be double click" or "add an extra configure option". I say "do not always open the image editor on a single click". My suggestion is the patch I posted on #110178. Or some other great new innovative idea someone comes up with.

i find it difficult to digest that "single click to open a file is ok in other kde programs but double click is better in digikam". Single-click-executes default option makes selection difficult in lots of other kde apps; but its magnified in digikam because: a) the item rectangle is quite large and b) the spacing between items is quite small. The only reasonable solution i can see is what Marcel proposed (and provided a patch for), execute only inside the thumbnail area, elsewhere do selection. Also I would like to double the spacing between items from 5 to 10. And, please don't ask a configuration option for changing the default spacing :).

Is there any objections from the other developers.

Yes, here is mine.

I fully agree to your last comment, Renchi. A click into the image selects and opens the image in IE, elsewhere do only selection. But this doesn't have to be configurable - like the spacing.

oh, there is not going to be a configuration option for this. sorry if i didn't make it clear.

I'm happy with proposal in comment #7 - dedicating the image outer rectangle to selection only, and increasing the spacing between items, makes the target areas big enough to click easily.  No need for any related configuration options :-)

I test Marcels patch and like it alot. But why is this a exclusive selection and not a collecting selection? Would not the latter makes more sense, how selection in album view is used?

There is another point I want to ask. Is'nt the patched album view a tri-state logic and need also tri-state mouse over?

thumbnail area -> execute
"dia" area -> selection
space area -> de-selection

IMHO a clear user feedback to point to somehow hidden functions is important

Thanks

  Thorsten

re: comment #11

99% of apps out there do something called the extended selection. a click on an item will select, a click elsewhere will unselect. to retain/enhance selection, you make use of shift/ctrl click. both selection and de-selection should be easy, and an inclusive selection makes the latter part difficult (and also goes against the trend of other apps).

regarding the tri-state logic: you have feedback for execute, the mouse cursor turns into a hand-cursor when over the thumbnail. for the other two, users will have to learn it. and i don't believe its very difficult to become comfortable with it in a short period of time (without resorting to reading any manuals).   there are plenty of things in any app which are not obvious. for eg, how many new users will learn the concept of drag-and-drop on their own.

SVN commit 455298 by pahlibar:

* apply marcel's patch for executing the items only if
 cursor is in the thumbnail area.
* double the thumbnail spacing making it easier to unselect 
 or do drag selection
* remove the inner white border in the thumbnail highligher.
  makes the highlights look better, imo and also shows more
  of the thumbnail
BUGS: 111695 110178 99416


 M  +15 -0     albumiconitem.cpp  
 M  +2 -0      albumiconitem.h  
 M  +5 -0      iconitem.cpp  
 M  +1 -0      iconitem.h  
 M  +8 -3      iconview.cpp  
 M  +0 -2      thumbnailjob.cpp  


--- trunk/extragear/graphics/digikam/digikam/albumiconitem.cpp #455297:455298
@@ -159,6 +159,18 @@
     return 0;
 }
 
+QRect AlbumIconItem::clickToOpenRect()
+{
+    if (tightPixmapRect_.isNull())
+        return rect();
+    
+    QRect pixmapRect = tightPixmapRect_;
+    QRect r          = rect();
+
+    pixmapRect.moveBy(r.x(), r.y());
+    return pixmapRect;
+}
+
 void AlbumIconItem::paintItem()
 {
     QPixmap pix;
@@ -185,6 +197,9 @@
         p.drawPixmap(r.x() + (r.width()-thumbnail->width())/2,
                      r.y() + (r.height()-thumbnail->height())/2,
                      *thumbnail);
+        tightPixmapRect_.setRect(r.x() + (r.width()-thumbnail->width())/2,
+                                 r.y() + (r.height()-thumbnail->height())/2,
+                                 thumbnail->width(), thumbnail->height());
         dirty_ = false;
     }
 
--- trunk/extragear/graphics/digikam/digikam/albumiconitem.h #455297:455298
@@ -60,6 +60,7 @@
     QRect thumbnailRect() const;
 
     virtual int compare(IconItem *item);
+    virtual QRect clickToOpenRect();
     
 protected:
 
@@ -70,6 +71,7 @@
     ImageInfo           *info_;
     AlbumIconView       *view_;
     bool                 dirty_;
+    QRect                tightPixmapRect_;
 };
 
 
--- trunk/extragear/graphics/digikam/digikam/iconitem.cpp #455297:455298
@@ -83,6 +83,11 @@
     return r;
 }
 
+QRect IconItem::clickToOpenRect()
+{
+    return rect();
+}
+
 bool IconItem::move(int x, int y)
 {
     if (m_x == x && m_y == y)
--- trunk/extragear/graphics/digikam/digikam/iconitem.h #455297:455298
@@ -51,6 +51,7 @@
     IconView* iconView() const;
 
     virtual int compare(IconItem *item);
+    virtual QRect clickToOpenRect();
 
 protected:
 
--- trunk/extragear/graphics/digikam/digikam/iconview.cpp #455297:455298
@@ -53,7 +53,7 @@
         currItem   = 0;
         anchorItem = 0;
         clearing   = false;
-        spacing    = 5;
+        spacing    = 10;
 
         rubber       = 0;
         dragging     = false;
@@ -982,7 +982,7 @@
 
         if (KGlobalSettings::changeCursorOverIcon())
         {
-            if (item)
+            if (item && item->clickToOpenRect().contains(e->pos()))
                 setCursor(KCursor::handCursor());
             else
                 unsetCursor();
@@ -1127,7 +1127,12 @@
             if (prevCurrItem)
                 prevCurrItem->repaint();
             if (KGlobalSettings::singleClick())
-                itemClickedToOpen(item);
+            {
+                if (item->clickToOpenRect().contains(e->pos()))
+                {
+                    itemClickedToOpen(item);
+                }
+            }
         }
     }
 }
--- trunk/extragear/graphics/digikam/digikam/thumbnailjob.cpp #455297:455298
@@ -280,8 +280,6 @@
         QPainter p(&pix);
         p.setPen(QPen(QColor(0,0,0),1));
         p.drawRect(0,0,w,h);
-        p.setPen(QPen(QColor(255,255,255),1));
-        p.drawRect(1,1,w-2,h-2);
         p.end();
     }
 

@ #12

Hi Renchi,

your comment towards in- and exclusive selection is for sure valid, but is it hard to implement or only a "one-liner"? I still think people will love inclusive selection cause they do not need the keyboard anymore and album view has no need for exclusive selection cause every single picture operation is part of the IE or un RMB. People will love it, believe me! :-)

Another reason is KDE4. There is some discussion for improving single click behavior. Why not show this one as a new concept? The old one is not affected and works as before, the new one could also work with konqi or kaddressbook in symbol mode.

Concerning mouse over. I know the current behavior but again regarding KDE4 why not show an arrow with one frame as symbol for exclusive selection, an arrow with 3 frames as inclusive selection and an arrow with a slashed frame over a deselection area as input for the current usability discussion?

Ok, I went off topic. But can you say something about point #1: Have I still mentioned that people will love damn fast selecting of individual pictures ;-)

Thanks

  Thorsten

Great! (I was about to complain on this too)

I find
- click on image to open it
- click on image frame to select it
as a perfect implementation.

But how to tell users? Tooltip for selection area?
Tutorial for the whole application?
(I find "tip of the day" worthless)

yes Roger, Tip of day is the better interractive way for this informations. Please make a patch against the current text file available on svn. Thanks in advance

Gilles