KDE/kdevplatform/plugins/projectmanagerview

[Andreas Pakulat]

On 23.06.09 11:17:59, Dan Leinir Turthra Jensen wrote:
> On Tuesday 23 June 2009 10:56:50 Andreas Pakulat wrote:
> > On 23.06.09 09:58:23, Dan Leinir Turthra Jensen wrote:
> > > On Tuesday 23 June 2009 08:32:39 Andreas Pakulat wrote:
> > > > On 22.06.09 22:00:52, David Nolden wrote:
> > > > > SVN commit 985481 by zwabel:
> > > > >
> > > > > Don't collapse items on single-click. Since it should be possible to
> > > > > just select something in the project-manager, collapsing the item is
> > > > > often an annoying and unexpected action.
> > > >
> > > > I don't like this at all. If a single click expands, then another click
> > > > should collapse the tree. Thats the normal behaviour.
> > > >
> > > > However I agree that its annoying that you cannot select something
> > > > easily. So how about we only expand/collaps on double click?
> > >
> > >   Down this path lies dragons. Seriously, don't start implementing this
> > > sort of thing - we've just removed the custom click handling in Amarok
> > > because it was a nightmare for both developers and users to keep track
> > > of. i said this on IRC yesterday as well, and i hope that people will
> > > listen to experience on this one.
> >
> > Uhm, I don't see a problem with that, because all we do is handle folders
> > (or expandable items) in the doubleClick slot. The activate slot will still
> > contain the code to open files, hence KDE's single-click behaviour is only
> > worked around for folders/expandable items.
> 
>   The point is that it's worked around at all. i of course can't stop you, but 
> trust me, this /will/ become a problem. Because KDE's single-click behaviour 
> isn't single-click behaviour. It's "whatever the user likes" behaviour. So, 
> you force this, and people who happen to like double-click will no longer be 
> able to use that.

What we workaround is the bogus and stupid decision that "everything"
should follow that globally configured single-click behaviour, no matter
how specialized the component in question is. Following such things just to
follow them is stupid. In fact maybe we shouldn't follow it in this
treeview at all and simply enforce double-clicking for both opening files
and opening folders.

> > > > The QTest toolview also provides a solution by implementing something
> > > > similar to dolphins "+/-" overlay icons, but personally I'd like simple
> > > > double-click behaviour better.
> > >
> > >   Dolphin's solution is designed specifically to alleviate the problems
> > > described above. Please! please use that in stead.
> >
> > This needs a _lot_ more code to be implemented properly than we should
> > spend on this. Apart from that in a treeview (small icons, little space)
> > this thing eats up too much of the treeview space, especially when the tree
> > gets deeper.
> 
>   i am aware that it will take more work (a lot), but it really is something 
> you should consider doing really, really carefully. And your track record does 
> show that considering things is indeed something you do - i hope you'll apply 
> it here as well :)

Looking at the QTest Treeview I don't think I'm going to change my mind on
this one. Reason is that the icons for selection (and other fancy things)
are overlayed at the right end of the real item. Which means I have to
scroll horizontally to deselect an item further up in the tree if I've
expanded a couple of folders. Thats not working for me as GUI at all, so
you'd even have to write code that makes sure the icons are shown on the
border of the view, not at the end of items. I can recall that Alex had a
really tough trying to get this to work for the original implementation of
the fileview. Thats also one of the reasons why we use KDirOperator now.

Andreas

-- 
You're working under a slight handicap.  You happen to be human.