Rationale for double click and project view and can we bring back following the global setting?

David Nolden david.nolden.kdevelop at art-master.de
Fri Aug 14 19:17:23 UTC 2009


Am Freitag 14 August 2009 20:58:21 schrieb Andreas Pakulat:
> On 14.08.09 20:16:07, David Nolden wrote:
> > Am Freitag 14 August 2009 19:45:37 schrieb Matt Rogers:
> > > Except that it's not consistent with the global kde settings that I use
> > > everywhere else
> > >
> > > Except that it's not even consistent within the same application.
> > >
> > > I'm not a usability expert by any means, but the lack of consistency
> > > even within the same application is disturbing to me as a user as I
> > > have to context switch my brain (for lack of a better phrase) when
> > > switching between views in the same application.
> >
> > The problem is that the project tree view has already usability problems,
> > and that even without blindly following global settings.
> >
> > Following the kde-global single/double click behavior does only make
> > sense when both behaviors lead to a good usability in the specific
> > usecase.
> >
> > Right now, single-click is more usable in that list, as you sometimes
> > have to select something, and it is not nice if the list expands at the
> > same time.
>
> I assume double-click.
yes
> > I think the ultimate solution is replacing the 'select' logic in that
> > list with something else like checkboxes.
>
> If you look at the QTest treeview, you'll notice that with adding
> _anything_ you'll end up with even less space. The treeview is already
> pretty small and also tries to conserve space by making the spacing
> smaller. Adding a 16x16 icon/checkbox/clickable-thing for selection
> takes away even more space.
>
> Not to mention, that IMHO checkboxes in such a tree look really really
> ugly.
That is true, but we can also implement that logic without using _real_ 
checkboxes.

Idea: Do the same thing dolphin does when hovering the icon of a file in 
'details' treeview mode:
- If the item is not part of the build-set, blend in a 'plus' sign, and show a 
tooltip "Add top buildset"
- If the item already is in the build set, blend in the 'minus' sign, and show 
tooltip "Remove from buildset".

Then we can add a permanent highlighting of items that are part of the 
buildset, and have a well-working selection interface if we define 'build-set 
= selection'.

For all the rest of the treeview, we can then use whatever mouse behavior we 
like. Although I think for group-headers it should then be 'always 
expand/unexpand on single-click', as it already was temporarily.

Greetings, David





More information about the KDevelop-devel mailing list