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

List:       quanta-devel
Subject:    Re: [quanta-devel] Project views in kdevquanta
From:       Jens Herden <jens () kdewebdev ! org>
Date:       2005-05-25 0:53:59
Message-ID: 200505250753.59344.jens () kdewebdev ! org
[Download RAW message or body]

Hi Andras,

> > 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.

It seems that here was/is the misunderstanding. I do not want to create a new 
toolview but integrate Project Views in the file list 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).

I am aware about the reasons for this and I support this rule but you also 
have to think what you would create if you follow this rule strictly. And I 
think it is OK if a plugin does not create it actions in the menu. 
Maybe we have to move this discussion to the KDevelop list again?

> > 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?

Yes, in fact I changed my mind because I think it is better to make the 
general interface (menus and toolbars) easy to comprehend and put the 
advanced features in the toolview. Even if you have to open the toolview 
first you save a lot of mouse clicks.
But I was also thinking about a configuration option that would allow the user 
to decide where to see the toolbar. Now that we know how to do this it should 
not be so hard.


> > 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.

Sure I did not mention this but it was in my mind that we need to do something 
for this. I was thinking about a signal that a project view was loaded. But 
this depends on the experience you make with inter plugin communication.


> 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.

I disagree here. This is over engineered for may taste. If I start showing the 
content of the views the people will ask for means to add or remove files 
from the views and other things. 
What I like in the current implementation is that it is strait foreward and 
has not much of an GUI. 

Jens
_______________________________________________
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]