|
Description
Felix Miata
2012-04-01 02:40:06 UTC
Created attachment 77976 [details]
120 DPI 4.10.0-1 picker window snapshot in virgin user session on openSUSE 12.3
Created attachment 77977 [details]
120 DPI 4.10.0-1 picker window snapshot in virgin user session on openSUSE 12.3
Felix, I have read your comments and I have tried to reproduce the problem (unusable narrow Places left pane) and I could not. Interestingly, your screenshot of FilePicker does not show the Favorites iconified with a yellow star while I see Favorites iconified with a yellow star on the far right-hand side of the FilePicker: I can upload a screenshot if requested. I believe - and I could be wrong here - that FilePicker may be using some user pref Dolphin settings. I am using Kubuntu 12.10 KDE platform development version 4.10.1 DPI settings: 96 screen resolution: 1024x768 Qt version: 4.8.3 Linux 3.5.0-26-generic i686 (32bits) and I have/am using Dolphin version 2.2 Gérard Created attachment 78567 [details]
screenshot: 1440x900 96 DPI 4.10.1 save as window on openSUSE 12.2
taken with KDE virgin user's first login - only showing window resized is Konsole's
Created attachment 78568 [details]
screenshot: 1600x1200 120 DPI 4.10.1 save as window on Mageia 3
Created attachment 78569 [details] 1920x1440 144 DPI 4.10.1 save as window screenshot on Fedora 18 taken with KDE virgin user's first login - only showing window resized is Konsole's (In reply to comment #3) > I have read your comments and I have tried to reproduce the problem > (unusable narrow Places left pane) and I could not. I cannot not reproduce it using Fedora 18, Mageia 3 or openSUSE 12.x. The problem on Mageia is less severe than the openSUSE 12.3 attachment 77977 [details] that is also @ 120 DPI, or the other two. I have no idea why - unless the initial left pane width is somehow tied to the longest folder name in $HOME, which is longest in Mageia. > Interestingly, your screenshot of FilePicker does not show the Favorites > iconified with a yellow star while I see Favorites iconified with a yellow > star on the far right-hand side of the FilePicker: I can upload a screenshot > if requested. > I believe - and I could be wrong here - that FilePicker may be using some > user pref Dolphin settings. I'm an OFM user who has never used Dolphin, so any Dolphin settings that may exist must be KDE defaults. The problem here is that the places panel determines its initial size based on the static entries (system places and custom user places) only. When later disks are scanned, it adds the dynamic entries (removeable devices, mounted partitions, etc), without recomputing its initial size. Possible fixes: - do not add the dynamic entries delayed => would significantly increase the time the dialog opens - recompute the initial size once delayed entries are added => ugly shifting behavior of the dialog on every open - use an arbitrary (larger) initial size, e.g. based on font width, without looking at the entries at all I do not like either of the solutions. When the user is able to resize the splitter, the dialog should simply remember the width for future invokations. (In reply to comment #7) > The problem here is that the places panel determines its initial size based > on the static entries (system places and custom user places) only. When > later disks are scanned, it adds the dynamic entries (removeable devices, > mounted partitions, etc), without recomputing its initial size. > > Possible fixes: > - do not add the dynamic entries delayed => would significantly increase the > time the dialog opens > - recompute the initial size once delayed entries are added => ugly shifting > behavior of the dialog on every open > - use an arbitrary (larger) initial size, e.g. based on font width, without > looking at the entries at all > > I do not like either of the solutions. When the user is able to resize the > splitter, the dialog should simply remember the width for future invokations. Memory is my favorite, but IMO it should have a minimum width on every open based on font size allowing at least 15ex (ex as x-height being on average equal to average character width, making 15ex typically equivalent to 7.5em; IIRC, 15 being the native volume label limit, but also enough for two or so average words) to show in addition to any ellipsis for excess beyond 15. Created attachment 81549 [details]
Fedora 19 KDM 4.10.5 save as window screenshot
Still crazy 16 months later. Here KScreen 1.0.1 is overruling xorg.conf settings, and disallowing any corrections via systemsettings.
Created attachment 82211 [details]
save window screenshot on 4.10.5 @1024x768x86DPI
As of KF5.8 the "always" part seems may be gone. Nevertheless, for a new login/user/profile using a >96DPI screen, the initial width is too narrow. The first instance width needs to be character size based, not a pixel width. Created attachment 107408 [details]
144 DPI screenshot from Spectacle 17.04.3 on openSUSE Tumbleweed
This a11y/u7y situational impairment continues as of KF5.36.
Felix, the bug has already been investigated, see comment #7, so there is no reason to continue nagging. (In reply to Christoph Feck from comment #7) "...-use an arbitrary (larger) initial size, e.g. based on font width, without looking at the entries at all I do not like either of the solutions." 1: "Either:... "one or the other of two" http://www.dictionary.com/browse/either?s=t You listed three items. I too do not like either of the first two, while the third almost perfectly describes the ideal.... 2: The third item makes much more sense than the already arbitrary initial window size. Basing the size on font size is how it should already be done. The arbitrary current sizing could work by simply converting its design px sizes to the em values of those sizes using the default font size, so that those needing larger fonts automatically get a larger window *and* pane sizes that maintain the designer's proportions. Px sizing is an abomination that works only for those with youthful eyes and those who don't mind straining to see what they need to see, and then only if the designer wisely employs empathy for those whose vision is less than perfect. "When the user is able to resize the splitter, the dialog should simply remember the width for future invokations." This should already be the case too, but it's less critical that intelligent initial size. A too small initial size means both the slider needs to be moved and the window needs to be bigger. *** Bug 417512 has been marked as a duplicate of this bug. *** |