From kde-core-devel  Wed Aug 01 19:07:58 2001
From: Thomas Zander <zander () planescape ! com>
Date: Wed, 01 Aug 2001 19:07:58 +0000
To: kde-core-devel
Subject: Re: Settings vs. View
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=99669311925958
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--PEIAKu/WMn1b1Hv9"


--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 applicati=
on.
> ...
> > 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 doc=
ument
part of the user interface.

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

Well, you are right that this is not the nicest solution possible from a=20
users POV, and I can understand that the destinction will not be immidiatel=
y=20
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=20
> 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 sea=
rch.
  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 entri=
es)

- 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=20
  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=20
  wrote above, that we should look at that app!. (no use to create a standa=
rd
  if not everyone complies ;)

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

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

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=20
with extra controls etc.
At this point adding or removing a toolbar from the UI makes a lot of sense=
=20
to do via the settings menu.

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

--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7aFOOCojCW6H2z/QRAprDAJ0dpgm8XtkJfl6iRbT3udfDQ0SgcgCgzWmy
MZMO2cROSkbtBMDoIplOZkM=
=n9EV
-----END PGP SIGNATURE-----

--PEIAKu/WMn1b1Hv9--