Version: 1.0.99 (using Devel) Installed from: Compiled sources OS: Linux Is it possible to change the behaviour of a treeview (the directory tree view of dolphin in particular) to (be configurable to) work like in Windows? 1. Already working is: If you focus and press arrow right on an unexpanded node, it will get expanded. Focus is (or should be, see bug 155996) unchanged. If you focus and press arrow left on an expanded node, it will get unexpanded. Focus is unchanged. What I would like is: If you focus and press arrow left on an unexpanded node, focus will be set to parent node. 2. When focusing a node, it should automatically get expanded. 3. Don't show the possibility to expand ([+]), when the node doesn't contain subnodes. This is really confusing. I know that KDE is not Windows and just that I'm used to it doesn't mean that it's the way it has to be done. But I really like the way Windows does it, not because it's the Windows way, but because it allows faster navigation.
Thanks for your input, I agree that still a lot of finetuning is required for the treeview. We'll fix this, I just cannot promise whether we can include everything into KDE 4.1 already...
I second that. What you describe was how the treeview of Konqueror KDE3 did things, and I found it very practical. (And I didn't know that it was like that in Windows too...)
I 'third' it, well generally anyway; I agree that; * 'left arrow' on a sub-node, should focus the parent * another 'left arrow' should collapse the subtree I disagree that focusing a node should automatically expand that node. If this were the case, then it would become harder to 'arrow down' (or up) to the desired node. Additinally, however, I would like to see this behaviour for *all* kinds of 'trees' including (but not limited to) the treeview in 'personal settings' aka 'configure desktop' aka 'system settings'. If there is such a thing as a 'treenavigation' library somewhere in the core KDE then that is where it should be 'fixed' IMHO
I just wanted to mention that if widgetstyle is set to `windows' everything works as expected (and the way it worked in 3.5.10 as I can recall). But for oxygen and plastique left arrow has no effect indeed. very annoying, I stick to ugly interface just because of this small bug... or is it a feature which is to stay? :(
Sorry for the late reply. I was not aware that this behavior is in the hand of the widget style, but I just tested it and you are right. It might be possible to bypass this in Dolphin, but I'd prefer if this gets fixed in Oxygen. @Oxygen-team: Do you agree that the behavior for tree views should be implemented like in the "Windows style"? If you disagree I'll try to fix it in Dolphin... Thanks!
SVN commit 1072813 by hpereiradacosta: Set SH_ItemView_ArrowKeysNavigateIntoChildren to true in styleHints to enforce intuitive arrow navigation in treeViews, in a way similar to what's done for the Windows style. CCBUG: 160024 M +3 -0 oxygen.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1072813
Commit from Comment #6 addresses "If you focus and press arrow left on an unexpanded node, focus will be set to parent node." of comment #1. (its a very simple fix and can easily be put in any other style). Item 2: (When focusing a node, it should automatically get expanded) will not be fixed in oxygen style. (and is not present in Qt Window style either, as far as I can tell). Item 3: I think its a dolphin only issue, which makes all directories expandable whether they are empty or not.
SVN commit 1072854 by hpereiradacosta: Backpot r1072813 Set SH_ItemView_ArrowKeysNavigateIntoChildren to true in styleHints to enforce intuitive arrow navigation in treeViews, in a way similar to what's done for the Windows style. CCBUG: 160024 M +3 -0 oxygen.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1072854
This is great news, and then again... Would this (or something similar) have to be done for each individual style? Personally I like Oxygen, and haven't spent much time with the other styles recently, but it'd suck running into the same issue once I do start looking at them... :/ And what's the prospect of having the 'fix' applied to other treeviews (like the one I mentioned in 'system settings' aka 'configure desktop' aka 'personal settings')? Or is that a different bug for a different component?
On 01/11/2010 09:40 AM, Jon Clausen wrote: > https://bugs.kde.org/show_bug.cgi?id=160024 > > > > > > --- Comment #9 from Jon Clausen<kdebugs ymmv dk> 2010-01-11 17:40:46 --- > This is great news, and then again... > > Would this (or something similar) have to be done for each individual style? > Personally I like Oxygen, and haven't spent much time with the other styles > recently, but it'd suck running into the same issue once I do start looking at > them... :/ > Well yes this should be applied to all styles separately (unless you ask the Qt guys to make it the default in QCommonStyle, or you change KStyle to make it the default too, in which case all styles deriving from kstyle would be fixed at once). Still, I think that a consistent treeview navigation (as specified by the style), is better than a per-application treeview navigation (that ignores the style specs). > And what's the prospect of having the 'fix' applied to other treeviews (like > the one I mentioned in 'system settings' aka 'configure desktop' aka 'personal > settings')? > As far as I know the fix I made to oxygen applies to all treeviews, unless customized by the application. I just tried systemsettings and it is working as expected. Unless I missed something. > Or is that a different bug for a different component? > >
> Well yes this should be applied to all styles separately (unless you ask > the Qt guys to make it the default in QCommonStyle, or you change KStyle > to make it the default too, in which case all styles deriving from > kstyle would be fixed at once). I think it is a very good idea, actually I see no reason not to have it default, unless there is a plan to use it somehow differently. Otherwise we are going to have the same issue reappearing again and again. how shell we do that?
On 01/11/2010 12:17 PM, s.v.savenko@gmail.com wrote: > https://bugs.kde.org/show_bug.cgi?id=160024 > > > > > > --- Comment #11 from<s v savenko gmail com> 2010-01-11 20:17:49 --- > >> Well yes this should be applied to all styles separately (unless you ask >> the Qt guys to make it the default in QCommonStyle, or you change KStyle >> to make it the default too, in which case all styles deriving from >> kstyle would be fixed at once). >> > I think it is a very good idea, actually I see no reason not to have it > default, unless there is a plan to use it somehow differently. Otherwise we are > going to have the same issue reappearing again and again. > how shell we do that? > > Someone can make the change to kstyle, and I'd say submit a patch to the reviewboard (as kstyle is part of kde libs). I can do that later today. Any better solution ? Hugo
(In reply to comment #10) > > Would this (or something similar) have to be done for each individual style? > Well yes this should be applied to all styles separately (unless you ask > the Qt guys to make it the default in QCommonStyle, or you change KStyle > to make it the default too, in which case all styles deriving from > kstyle would be fixed at once). I think getting this fix as close to the root as possible is definitely the better solution, but I'm biased ;) > Still, I think that a consistent treeview navigation (as specified by > the style), is better than a per-application treeview navigation (that > ignores the style specs). No doubt about that. > > And what's the prospect of having the 'fix' applied to other treeviews (like > > the one I mentioned in 'system settings' aka 'configure desktop' aka 'personal > > settings')? > > > As far as I know the fix I made to oxygen applies to all treeviews, > unless customized by the application. hmm... Does that explain why 'left-arrow-jumps-to-parent' treenavigation works with Konqueror? Version 4.3.1 (KDE 4.3.1) "release 6" as distributed with openSUSE 11.2 Konquerer, load 'file management' profile, press F9 to get the panel, choose some folder, arrow around: nodes expand/collapse, focus jumps to parent, everything more or less works as (I) expected. But only in the folder 'pane'. > I just tried systemsettings and it is working as expected. Unless I > missed something. Right. I don't have a build environment ATM so I haven't actually tested the fix, but if all 'trees' inherit from the style then I guess everything's fine.
SVN commit 1074163 by hpereiradacosta: Set SH_ItemView_ArrowKeysNavigateIntoChildren to true in styleHints to enforce intuitive arrow navigation in treeViews, in a way similar to what's done for the Windows style. CCBUG: 160024 M +3 -0 kstyle.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1074163
SVN commit 1074164 by hpereiradacosta: Backport r1073856 Set SH_ItemView_ArrowKeysNavigateIntoChildren to true in styleHints to enforce intuitive arrow navigation in treeViews, in a way similar to what's done for the Windows style. CCBUG: 160024 M +3 -0 kstyle.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1074164