Version: (using Devel) Installed from: Compiled sources Please consider making these obstrusive overlay buttons optional. I for one never ever rotate an image without viewing the large image, so these overlay buttons are a big big nuisance and only get in the way of selecting images. Disabling this feature and recovering the vertical space occupied by this would make the albumview much nicer for it's main task: navigating your images!
album icon view Qt4 model view relevant... Somebody is interrested to implement this whish ? Note that option must be added to Album View setup page... Gilles Caulier
(In reply to comment #1) > Somebody is interrested to implement this whish ? I could do this. (In reply to comment #0) > Please consider making these obstrusive overlay buttons optional. I for one > never ever rotate an image without viewing the large image, so these overlay > buttons are a big big nuisance and only get in the way of selecting images. > Disabling this feature and recovering the vertical space occupied by this would > make the albumview much nicer for it's main task: navigating your images! Do you mean only the rotation buttons or also the one for adding or removing an image to or from a selection? Or do you think there should be two distinct options? Regarding the space: There is not space reserved specially for these overlays. If you got a squarish image, then all space of the album item is filled, except a small decorative border.
> Do you mean only the rotation buttons or also the one for adding or removing an > image to or from a selection? IMHO there is no need for a secondary selection method, there is a standard way of doing this in all KDE programs (hold the CTRL-key and then left click).. > Or do you think there should be two distinct options? I'm neither in favor of one or the other. As long as the vertical space can be recovered and the interface gets less hectic - I would always remove both... >Regarding the space: There is not space reserved specially for these overlays. >If you got a squarish image, then all space of the album item is filled, except >a small decorative border. Well all my images are either 3:2 or 2:3. In the portrait orientation images the buttons overlap, in the landscape oriented they are placed above. The first is the bigger nuisance, the latter just mildly distracting. Regarding the border, I don't understand why the border is painted whenever I touch an image by passing the mouse over it but it (the border) isn't removed after the mouse left the active area - scrolling the list does remove the border :-(...
(In reply to comment #3) > > Do you mean only the rotation buttons or also the one for adding or removing an > > image to or from a selection? > IMHO there is no need for a secondary selection method, there is a standard way > of doing this in all KDE programs (hold the CTRL-key and then left click).. Gilles, what do you think? The overlay for the selection is added by the base class ImageCategorizedView. I don't know if it's somewhere else used, so the only non-intrusive way to remove that overlay in the view - that I see - is adding a method to remove the overlay to ImageCategorizedView. But that sounds like duplicate work... first adding it in the constructor and then removing it afterwards. Maybe we should add a boolean parameter to the constructor to auto-add this overlay defaulting to true for backwards-compatibility. AlbumIconView can set this to false and use addSelectionOverlay based on the settings. > > Or do you think there should be two distinct options? > I'm neither in favor of one or the other. As long as the vertical space can be > recovered and the interface gets less hectic - I would always remove both... Ok, then I'd suggest a single option to keep the GUI simple. > >Regarding the space: There is not space reserved specially for these overlays. > >If you got a squarish image, then all space of the album item is filled, except > >a small decorative border. > Well all my images are either 3:2 or 2:3. In the portrait orientation images > the buttons overlap, in the landscape oriented they are placed above. The first > is the bigger nuisance, the latter just mildly distracting. But we cannot generalize this, because there may of course be quadratic photos in an album. But this should then be solved for you with an option to remove the overlays. > Regarding the border, I don't understand why the border is painted whenever I > touch an image by passing the mouse over it but it (the border) isn't removed > after the mouse left the active area - scrolling the list does remove the > border :-(... Hm, that sounds like a different problem. The border should be static. Can you provide some screenshots?
(In reply to comment #4) > Gilles, what do you think? The overlay for the selection is added by the base > class ImageCategorizedView. I don't know if it's somewhere else used, so the > only non-intrusive way to remove that overlay in the view - that I see - is > adding a method to remove the overlay to ImageCategorizedView. But that sounds > like duplicate work... first adding it in the constructor and then removing it > afterwards. Maybe we should add a boolean parameter to the constructor to > auto-add this overlay defaulting to true for backwards-compatibility. > AlbumIconView can set this to false and use addSelectionOverlay based on the > settings. Just create a QFlag and set the overlay widgets with a setter method. For example http://lxr.kde.org/source/extragear/graphics/digikam/utilities/advancedrename/advancedrenamewidget.h#48 or http://lxr.kde.org/source/extragear/graphics/digikam/utilities/imageeditor/editor/editortoolsettings.h#51
(In reply to comment #5) > Just create a QFlag and set the overlay widgets with a setter method. Ok, another one of Qt's swiss army knifes. ;) Btw: do you know if I have to manually delete an overlay if I remove it with removeOverlay? Or is the memory management completely done in Qt internals?
Hmm don't know if it is actually removed, this line here only removes it from a QList: http://lxr.kde.org/source/extragear/graphics/digikam/digikam/imagedelegate.cpp#181 But this shouldn't clean up memory. Better ask Marcel about this, he wrote this stuff :-)
(In reply to comment #6) > Ok, another one of Qt's swiss army knifes. ;) Well actually this is nothing special, it is a normal binary compare. The only special thing is that you can use this enum in a function as a parameter, this wouldn't work otherwise and you would have to use a normal integer parameter instead. You'll find this kind of setting in many frameworks, for example MFC etc.
The inconview item Selection button have been added by another bugzilla entry to reproduce same scheme than dolphin, gwenview, konqueror. I'm not sure if it's a good idea to set it optional. About rotation stuff, it's also another whish from bugzilla. gwenview already use this way too... Gilles
> > IMHO there is no need for a secondary selection method, there is a standard way > > of doing this in all KDE programs (hold the CTRL-key and then left click).. With Dolphin and KDE4, the (+) icon has become a standard with KDE, a lot of thought and discussion about usability has went into this. > > Gilles, what do you think? The overlay for the selection is added by the base > class ImageCategorizedView. I don't know if it's somewhere else used, so the > only non-intrusive way to remove that overlay in the view - that I see - is > adding a method to remove the overlay to ImageCategorizedView. But that sounds > like duplicate work... first adding it in the constructor and then removing it > afterwards. Maybe we should add a boolean parameter to the constructor to > auto-add this overlay defaulting to true for backwards-compatibility. > AlbumIconView can set this to false and use addSelectionOverlay based on the > settings. Overlays can be added, removed, and re-added again. (never tested, but should be). It's added in the constructor just for convenience. Store the pointer in the private class and just add or remove it. > > >Regarding the space: There is not space reserved specially for these overlays. Intentionally > > Regarding the border, I don't understand why the border is painted whenever I > > touch an image by passing the mouse over it but it (the border) isn't removed > > after the mouse left the active area - scrolling the list does remove the > > border :-(... which border is this?
SVN commit 1031003 by jwienke: Rotation overlay buttons in album view are now optional BUG: 209189 M +1 -0 CMakeLists.txt M +2 -1 NEWS M +22 -8 digikam/albumsettings.cpp M +9 -0 digikam/albumsettings.h M +21 -35 digikam/digikamimageview.cpp AM digikam/digikamimageview_p.cpp [License: GPL (v2+)] AM digikam/digikamimageview_p.h [License: GPL (v2+)] M +1 -0 libs/widgets/iccprofiles/iccprofilescombobox.cpp M +9 -0 utilities/setup/setupalbumview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1031003