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

List:       kde-core-devel
Subject:    Re: Settings vs. View
From:       Thomas Zander <zander () planescape ! com>
Date:       2001-08-01 19:07:58
[Download RAW message or body]


On Tue, Jul 31, 2001 at 10:58:37PM +0200, Lenny wrote:
> On Tuesday 31 July 2001 21:08, Waldo Bastian wrote:
> > Then again, view is more about the presentation of the content, while
> > "Settings-> Show xxx" is more about the user interface of the application.
> ...
> > With the view menu you control how much information you get to see, with
> > the settings menu you control the user interface. Different things.

First of all, Waldo is right here. There is a difference between the GUI
presentation and the document presentation. I'll explain in a minute.

The View menu is for changing the way a user views the document. This mostly
includes things like 'show fancy headers' (KMail), 'week view' (KOrganizer) etc.
This means that the document is shown differently, and this affects the document
part of the user interface.

The Settings menu is for changing the look and feel of the area outside of the 
document, and non-UI things. Like toolbars and config-settings and such.
 
> IMHO gui should be a real no-brainer. As you said, at some point in time the 
> user wants to _control_ something. Why does he have to think about what to 
> control and decide upon that where to look?

Well, you are right that this is not the nicest solution possible from a 
users POV, and I can understand that the destinction will not be immidiately 
apparent to the user.
This is also because not every KDE program does it the way it should.

> Of course merging all the options in one menu-item wouldnt honor the 
> technical aspects perfectly.

But, Yes, merging all into view is one option to go.


Lets just consider why we choose to do it the way it is now;

- creating one view menu with all stuff from view and all GUI-stuff from
  settings will result in quite a big menu. Big menus will be harder to search.
  Sorting it in submenus will not quite solve the problem since this will
  only make searching harder (the user will actually have to read the entries)

- the options in view are the ones the user will most likely use more often
  then the ones in settings (certainly when that RMB-select toolbars option
  is implemented)

- when MUI or a multiple view (on one document) interface are taken in 
  consideration the effect of the settings in the view verses the settings
  menu will be quite different. View options are per document.
  This is the setup, if you see an application that differs from the stuff I 
  wrote above, that we should look at that app!. (no use to create a standard
  if not everyone complies ;)

- also applications that are nested in one-another should make that distincion
  since clicking on a .doc file in konqueror shows the content of the doc, not 
  the ui around it. (yes konqueror forgets showing the view menu, I consider 
  this a bug in konqueror)

Last; the toolbars can contain every other widget. This means that it is easy 
to use a toolbar for things like a layers-dialog or something like that. 
But naturally this is useless unless we can make the toolbars floating
seperately from the main window. 

In QT3 I understand that floating toolbars has been integrated and then
it is easy to make more usable SDI applications that have extra windows 
with extra controls etc.
At this point adding or removing a toolbar from the UI makes a lot of sense 
to do via the settings menu.

-- 
Thomas Zander                                            zander@earthling.net
The only thing worse than failure is the fear of trying something new

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

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