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

List:       kde-core-devel
Subject:    Re: Settings vs. View
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-07-31 17:57:40
[Download RAW message or body]

I wonder what the rest of this thread was about, actually...

On Tuesday 31 July 2001 18:26, Lenny wrote:
> Lazily forwarding from koffice-devel.
>
> ----------  Forwarded Message  ----------
>
> Subject: Re: Settings vs. View
> Date: Tue, 31 Jul 2001 15:18:56 +0200
> From: David Faure <david@mandrakesoft.com>
> To: koffice-devel@max.tat.physik.uni-tuebingen.de
>
> On Tuesday 31 July 2001 13:53, Lenny wrote:
> > Ok, this might be a general kde-topic, but since karbon is yet a
> > koffice-app i try to start a flame war here first.
> >
> > <lenny's pov>
> > "Settings" is about changing how stuff/the application behaves.
> > "View" is about showing/hiding stuff
> > </lenny's pov>
> >
> > At least that's a standard interpretation in the world outside of kde.
> >
> > Artists are quite picky about how their favorite application looks and
> > feels. Having "show toolbar blah" in "settings" feels totally wrong to
> > me.
>
> That's definitely a KDE-wide issue, since e.g. Konqueror and KMail have
> those things under Settings. Please discuss this on a KDE-wide list
> (kde-core-devel, kde-devel, or maybe kde-look).
> We can't take a decision that would affect kmail and konqueror, on this
> list.

A few arguments, both in favour and against, because I've wondered for a 
while if the current system is logical - and I still haven't found out 
myself...

- If you want to change a persistent setting you'd look in the settings menu 
first, to find out next that the option is not there.

- If you want to change something non-persistent you'd look in the view menu, 
since it's temporary and not forever\

- Since non-persistent settings often suck and konq hence saves all settings 
that would mean we don't have a view menu at all

- OTOH, you can save settings from the view menu (all of them?) in a 
.directory, whereas the settings menu stores in rc files.

- Settings in the view menu indeed apply to one view, that is, if you split 
the view they do not apply to other views as well.

- Setting the default preferences though from a view menu is not logical.

Summarizing, in the current situation the view menu applies to a _single_ 
view, whereas settings apply to the entire app.
What Lenny sais would contradict that rule. Not that I completely object, but 
it is not the way it is _now_.

What can be improved?

- I think having all settings from the view menu in the settings as well to 
set the defaults would be a plus. Then a user only needs to look in _one_ 
menu, more consistent. Any view that doesn't use customized settings should 
then take over changes in these global settings

- I personally think a settings _menu_ is wrong, since there is a settings 
_dialog_ as well. I never understood why some settings got their own menu and 
some were only in the dialog. Probably because the settings in the menu are 
accessed most often, but that should be based on the user and not on the 
programmer who decides.

- I think the only logical place is a *consistent* place, since changing the 
look of an app often also somehow affects the app's behaviour. Using an 
index.html file or thumb previews in konq is on the one hand a visual thing, 
but on the other hand also affects behaviour and performance. Generating 
thumbs over a dialup ftp link is not quite a visual thing, though showing the 
same thumbs is. Where should we draw the line then?

Concluding: I think only multi-view apps need a view menu in the first place. 
Settings there are per-view and _also_ available in the settings dialog where 
you can set the default. Per-view settings are not stored on disk unless you 
save a view profile or so, they are otherwise never persistent.

Hmm.. that would suck as well, I can imagine some bug reports about settings 
not being saved... Well.. there must be a solution for that as well, this 
isn't meant to be a definitive paper anyway...

Ok, this should be enough fuel for a nice discussion, I'm waiting for the 
comments and flames ;-)

Martijn

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