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

List:       kde-core-devel
Subject:    Re: RE: Key management
From:       David Faure <faure () kde ! org>
Date:       1999-11-27 18:26:46
[Download RAW message or body]

> Well, how about different completion kinds.  Say automatic in konqueror and
> manual in minicli.  Reason for this might be that I tend to use minicli much
> often and the autocompletion gets in the way or is an annoyance or vise-versa.
> I know this is not a great example, but this is the about the same type of
> argument that was given when I was initially adding abbreviated URL support to
> minicli ...
As yo usay it's not a great example at all.
I think things like autocompletion are meant to be consistent, not
different in each app.

Just like we don't have support for setting some titlebars of a different color,
or just like we you choose a shortcut for "Close" (global key), you get it for
all apps.

> > > > We always have to choose between configurability and consistency.
> > > > Either everything is configurable on a per-app basis (and we lose
> > > > consistency), or everything is only configurable globally 
> > > (and we lose flexibility)...
> > > 
> > > Right.  Most everything is a tradeoff in any design environment.  However, that
> > > does not necessarily mean we necessarily have to loose flexibility.  We can for
> > > example make the default behavior the same for everything.  Then it will be up
> > > to each individual user or to the distros to modify these settings to fit
> > > their needs. But I think it is important to allow this flexibility to all apps.
> > > A good example I can think of that shows the importance of flexibility or
> > > there lack of is font type/size issue in kfm.  Remember the request that many
> > > people had about wanting to have different font settings for kfm - the
> > > file manager and kfm - the browser.   
> >
> > Yup, I changed that in the head branch. (See libkcm_konq and libkcm_konqhtml).
> >
> > > Also the recent discussion about when pop-up menus should be displayed is 
> > > another key example of the need to have as many things configurable as possible.
> >
> > Wrong example : this is a KDE-wide setting, not a per-app setting !
> Hmm ... right, but most of the developers in that discussion were arguing about
> the merits of one over the other.  And the reason why I suggested making
> configurable was becuase this way at least we encourage many developers to make
> their apps flexiable so that they can be changed through a gloabal or a local
> setting.
Those are two completely different things !!
Aps should be flexible in the sense that they should obey whatever the global
setting is.
It does NOT mean that config dialogs should have such a complexity as to
allow setting things on a per-app basis.

>  I guess the problem is no matter what the standard says, there will
> always be apps that break it ( for perfectly good or technical reasons or just
> as a matter of preference by the developer ) and hence break the consistency. 
Then they have to be fixed.

> Thus, I figured we can nudge more people to follow the standards by making the
> standards as flexiable as possible.
I don't follow this reasoning at all.

> > > Hence, IMHO the configurability minicli, konqueror or any other app. By
> > > default they should use the global settings.  But then we should leave it
> > > up to each app to allow the change of these settings to the user's liking.
> > > But then again I personally tend to always favor flexibility as long as it
> > > does not impact performance ...
> >
> > This sounds good, but it leads to a problem : the default is the same
> > everywhere, fine, but if you change this somewhere, it doesn't change
> > somewhere else. Say I hate auto-completion, and say it's the default
> > (Waldo : it's just an example !), well, I would have to turn it off in minicli,
> > then in konqueror, then in kmail, then in every other program that tries to
> > auto-complete whatever I'm typing. Damnit I just want to turn it off once
> > and for all ...
> >
> > As I said this makes it very difficult to change the global setting,
> > since there is no more global setting (only a non-configurable global
> > default).
> > Then you're going to say : fine, let's have an option to change the global
> > setting as well - but that's impossible since the apps have their own
> > setting and don't know if they should obey it or the global setting :-)
> 
> Well actually the better solution IMO is the other way around. We can have a
> flag for global settings that says something like "Always use this setting" and
> on startup, when each app reads its config file, they should check this flag and
> if set, use the global setting and foget about the local one. In fact, the
> local configuration dialog should be greyed out when this flag is checked so
> that the user would not be confused as to why his/her changes are not taking
> effect.  Thus, all you have to do when you want to change your settings
> globally and have them take effect is to simply check this box and you are
> done.  This would obviously require a little bit more work for developers, but
> I think it is worth what we would gain.  What do you think ?
It's just the reverse way from what KConfig implements
(a global setting in $KDEDIR and if there is a local value it overrides it).
I don't see what's the point in re-inventing the wheel.

> > Yes, I've been having tons of issues like that in the settings and
> > view-properties (and local-URL-properties !) stuff for konqueror :-)
> > 
> > Example : there is a default background color and a way to set it for the
> > local directory (with explicit saving, not implicit). Say you change the local
> > color (but don't save it). Then if you change the default color... what
> > happens to the current view ? Obey the default color or keep its own ? :-)
> >
> > Hmmm, looks like the only way is to compare the local color with the _old_
> > default, and if equal, obey to the new default. Not easy (because the old
> > default is lost at that time).
> 
> IMO it shoudl keep its own local color if the user has not already exited the
> window yet.
So what the user just did resulted to no change on the screen, and he thinks
it hasn't worked !
(Think that the 'local color' could be in fact the 'global' one, if he
didn't bother to set a local color.

>  Otherwise, it should show the default color since you have not
> saved the local change.  Local config should take presedence unless there is an
> overidding global setting.
Sure

> Take for example, the html widget.  In konqueror,
> you can change the colors for the links and the background and then check
> "Always use my colors" box.  This will (or should) always override the colors
> set specified by the html document.  However, once I make this change I do not
> expect the browser to immediately adjust, although it is possible to do that
> in this particluar.
Well, I don't see why you wouldn't expect that. I would.

>  Generally though the changes do not really have to take
> effect until the next time the application is started/re-started.  In the mean
> time so as not to confuse the user, when (s)he select such a global flag, we
> should display a message dialog box that states that the changes do not take
> effect until they re-start the application.
Or the next time they reboot their computer ? :-)


-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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