Bug 175630 - setting panels of imageeditor effects should be fully visible
Summary: setting panels of imageeditor effects should be fully visible
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: ImageEditor-Plugins (show other bugs)
Version: 0.10.0
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-20 02:04 UTC by simon
Modified: 2022-02-03 04:08 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.5.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description simon 2008-11-20 02:04:21 UTC
Version:           0.10.0-beta6 (using 4.1.80 (KDE 4.1.80 (KDE 4.2 Beta1)), Gentoo)
Compiler:          x86_64-pc-linux-gnu-gcc
OS:                Linux (x86_64) release 2.6.26-tuxonice

as each property pages of the effects/filters in the image editor window have a different width, one always has to manually adjust the divider to see everything of the GUI elements, everytime a effect/filter is opened.

The minimal needed width for each panel should be automagically used, as it's quite annoying when the controls are hidden
Comment 1 Mikolaj Machowski 2008-12-08 16:47:45 UTC
Confirming for 0.10b7svn and 0.9.5svn.

It is really awkward. In the first moment I always think something is wrong because some info isn't visible.

Several possible solution:
1) redesing settings to accomodate in default minimum width of right panel
2) increase minimum width of right panel to accomodate all settings panels
3) automatically adjust width of right panel to make everything visible
Comment 2 caulier.gilles 2008-12-08 16:54:14 UTC
Marcel, 

This problem come from of QScrollView (QScrollArea) used to display sidebar contents to be compatible with small screen size as with EEEPC.

The problem is how to get the right widget size hosted by scroll view. It's never right here...

Andi,

We need to optimize also the design on the bottom of settings view. Perhaps some buttons text can be removed to optimize space, and let's only icons alone on buttons...

Gilles Caulier
Comment 3 simon 2008-12-08 17:03:59 UTC
hi,

imho "small screen size as with EEEP" are definetely not the main target a image managing software should be optimized for.

i vote for option 3) outlined in comment #1; a option could switch if the scrollbars should be used or not (small size displays)
Comment 4 caulier.gilles 2008-12-08 18:33:25 UTC
This is not only for EEEPC. Problem appears with 19/9 laptop screen (like mine) where digiKam window become behing KDE task bar.

Gilles Caulier
Comment 5 Andi Clemens 2008-12-08 18:38:29 UTC
We should change the hardware specs: Linux 2.6.xx + widescreen beamer :-)
Comment 6 Mikolaj Machowski 2008-12-08 20:30:14 UTC
About design - quick review of plugins:
Method: resized 0.9.5svn IE window to 800x600 (including window decoration); set right panel width to minimum size where Caption/Tags panel fit (the widest default panel - small surprise, always thought Colors is due to histogram).

Looks like *all* plugins are resizing dialog to 830-840px PLUS they don't allow to resize window below this width - so for practical reasons test is for 840px width - which is already 40px too much.

Notes below are not bugs per se but things where some pixels of width can be gained, "OK" means only plugin fits withou horizontal scrollbar:

Auto-Correction: OK
B/C/G: OK
H/S/L: OK
Color correction: value fields are too wide
B&W: just few pixels, value field too wide? in this width mess with buttons
Color management: OK
Levels: value fields too wide? broken vertical scrolling - one histogram stays in place while the rest is moving
Color Effects: OK
White Balance: sliders could be more compressed - due to precise nature of corrections they are already almost unusable - get rid of them?
Curves: OK
Channel mixer: OK
Sharpen: OK
Blur: OK
Red eye: OK
Inpainting: sliders, value fields too wide
Noise reducton: sliders, value fields too wide
Hot pixels: OK
Lens distortion: sliders, value fields too wide
Restoration: sliders, value fields too wide
Vignetting: OK - due to <br> between label and slider - solution everywhere?
Aspect ratio crop: too much everything
Shear: sliders, fields, even <br> doesn't help
Free rotation: as in Shear
Perspective: OK
Texture: OK
Border: OK
Text: narrower font Size column and text alignment buttons
Template superimpose: not OK, no idea how help
Raindrops, Infra red, Oil paint, Emboss, Film grain, Blur effects, Charcoal: OK
Distorition: sliders, value fields too wide

General notes: a) in many UIs width was broken due to adding of reset button without adjusting the rest of the dialog

HTH
Comment 7 Geoff King 2008-12-20 17:02:28 UTC
I didn't see this comment before.  Looks like what I just reported here:
http://bugs.kde.org/show_bug.cgi?id=178291
Comment 8 Geoff King 2008-12-20 17:05:06 UTC
*** Bug 178291 has been marked as a duplicate of this bug. ***
Comment 9 caulier.gilles 2008-12-22 09:45:22 UTC
Marcel,

Are you see my comment #2 ?

Gilles
Comment 10 Marcel Wiesweg 2008-12-22 21:58:38 UTC
SVN commit 900430 by mwiesweg:

Reimplement minimumSizeHint of the scroll area.
The minimumSizeHint of a QScrollArea is usually independent of the widget contained,
but here we want to have a certain amount of minimum horizontal space.
Limit minimum size to 40% of desktop width.

CCBUG: 175630

 M  +23 -9     editortoolsettings.cpp  
 M  +2 -0      editortoolsettings.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=900430
Comment 11 Marcel Wiesweg 2008-12-22 22:02:43 UTC
With this commit the sidebar is automatically extended to the needed size in the horizontal direction, vertical is untouched.
We can limit the required space according to desktop size (currently it's 40% of desktop width).
It also seems to behave quite well when resizing the window.
Please test, if you find no problems we can mark this as fixed.
Comment 12 caulier.gilles 2008-12-25 14:34:07 UTC
Marcel,

Your patch work fine here. Great...

Note: your patch need to be backported to KDE3 branch because the same implementation is used with scroll view container in editor tool settings page.

Gilles Caulier
Comment 13 Geoff King 2008-12-26 03:35:32 UTC
Looks good to me.  Problem solved.
Comment 14 Marcel Wiesweg 2008-12-29 22:38:55 UTC
*** Bug 178190 has been marked as a duplicate of this bug. ***
Comment 15 caulier.gilles 2009-01-01 14:31:23 UTC
Marcel,

Are you see my comment #12 ? KDE3 still not patched yet ?

Gilles Caulier
Comment 16 Marcel Wiesweg 2009-01-01 18:09:15 UTC
SVN commit 904225 by mwiesweg:

Backport commit 900430 to KDE3:

Reimplement minimumSizeHint of the scroll area.
The minimumSizeHint of a QScrollView is usually independent of the widget
contained, but here we want to have a certain amount of minimum horizontal space.
Limit minimum size to 40% of desktop width.

CCBUG: 175630


 M  +22 -7     editortoolsettings.cpp  
 M  +2 -0      editortoolsettings.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=904225
Comment 17 caulier.gilles 2009-01-01 18:15:55 UTC
Thanks MArcel, it work fine here...

Gilles