[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] Project views in kdevquanta
From:       Andras Mantia <amantia () kde ! org>
Date:       2005-05-24 13:40:12
Message-ID: 200505241640.12299.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 24 May 2005 16:08, Jens Herden wrote:
> The file selector has the same. And there is not only the buttons and
> the dropdown but also the list of open files!

If there is also some more information like a list with files belonging 
to each view, it makes sense to create a toolview.

> > > And
> > > we can add all actions to the toolbar and remove the actions from
> > > the project menu, what would leave the menus slicker.
> >
> > I think there is a guideline that every action should be available
> > from menus. See:
> > http://developer.kde.org/documentation/standards/kde/style/toolbar/
> >index.ht ml
>
> I am not sure if this is meant to be strict, a lot of actions in the
> toolviews have no counterpart in the menus.

That can be considered a violation of the guide. I don't know what the 
upcoming HIG guide will contain, but I can see the reasoning: an icon 
is cryptic compared to a user readable menu  text, even if the same 
text appears as a tooltip. Why? Because:
- requires you to use the mouse
- requires you to know that you have to move the cursor above the icon 
and don't move the mouse for a second or so

This might not be a problem for you or me, but can be a serious problem 
for others who for example have problems with controlling the mouse 
pointer. If the item is in the menus, you can always access with the 
keyboard (and with voice, once it works).


> And this is good because 
> otherwise you would have too much entries in the menu.

You wrote in a Reply to Alexander that you want to keep the project view 
toolbar. I also think that's a good idea to keep. Did your opinion 
changed meantime?

> So grouping the actions of a plugin in the toolview makes perfectly
> sense from my point of view. Especially in this case where a project
> view is nothing else as a list of open files.

You forgot something: right now user toolbars are also included in the 
view. This is also something we need to deal with somehow as the user 
toolbars will be a different plugin.

So what I suggest is that if we want, we can have a toolview which might 
even be a tree-like structure (see below), but having the toolbar in 
addition makes sense. Of course in that case we need the menu items as 
well unless the toolbar contains only the dropdown list.

Proposed toolview (integrated with File List):
Opened Files
  file 1
  file 2
 .....
View 1
  file 1
  file 2
  ....
View 2
... and so one.

Or create a tab for each view, like in the "Find in Files" plugin of 
KDevelop or the annotation view in Quanta.


Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org

[Attachment #5 (application/pgp-signature)]

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel


[prev in list] [next in list] [prev in thread] [next in thread]