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

List:       kde-core-devel
Subject:    Re: Settings vs. View
From:       Lenny <kudling () kde ! org>
Date:       2001-08-01 9:40:44
[Download RAW message or body]

On Tuesday 31 July 2001 23:39, Waldo Bastian wrote:
> are to run into deep trouble if you, as developer, don't keep them in mind.
> Imagine a situation where a single mainwindow has two views... each view
> can now get his own "view" settings, but the "settings" would apply to the
> mainwindow as a whole.

Nobody said, that you have to lose the whole concept-picture only because you 
grouped your menu-items in a user-friendly fashion. What's the problem with 
mixing persistent mainwindow-settings with non-persistent view-settings? The 
user surely can expect that (e.g. in kmail) his email-address will be the 
same. But what can he expect on next start-up when he has 2 kmail windows 
open, one w/, one w/o menubar? I think the distinction is clear.

> look'n feel from implementation, is the day it matured.". Look&feel should
> be driven by concepts and it doesn't hurt, on the contrary, if
> implemenation follows the concepts closesy. That may very well result in a
> more or less direct mapping between look&feel and implementation. The big
> issue is not to mistake cause and effect, implementation should follow the
> concepts, it shouldn't drive them.

But that's what we - Martijn and me - critisize: in some areas it's the other 
way around.
You say "kde's design is object oriented". The code, yes, but the ui/the 
concepts?
Having a central config-location for each app is in my pov more 
object-oriented than asking the user to perform a switch()-statement in his 
mind: "if this setting affects local-view, do this, if this setting affects 
the mainwindow...".

Lenny

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