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

List:       kde-core-devel
Subject:    RE: Key management
From:       Dawit Alemayehu <adawit () earthlink ! net>
Date:       1999-11-26 18:44:39
[Download RAW message or body]

On Fri, 26 Nov 1999, David Faure wrote:
> > On Thu, 25 Nov 1999, David Faure wrote:
> > > > On Thu, 25 Nov 1999, David Faure wrote:
> > [snipped]
> > > Auto-completion, manual completion, ... should be configurable at the 
> > > KDE level (i.e. what Waldo already added supported for), and
> > > abbreviated URL and internet keywords should be configurable globally as
> > > well (for konqueror and minicli at the same time)...

I guess we do not see it the same way.  As we both agree many people would
probably not mind these additional features in konqueror, but they would in
minicli.  IMHO, many people expect/want minicli to act like its name implies, a
simple alternative to a full fledged shell.  However, we cannot provide this
type of configuration without allowing apps to make this changes to some global
settings.  See below for a possible idea on how have configurability while
retaining consistency.

> > I know I am probably being very picky, but I guarantee you that someone
> > will complain about this.  Most people would not mind these features in
> > konqueror's location bar.  But when it comes to the minicli box, everyone
> > will complain.  You even said below it is confusing that minicli shows "no
> > such host" error when you type the wrong command.  See what I am getting at.
>
> Yes, but that's what I called the exception.
> For stuff like auto-completion, I don't see why people would want it
> in minicli and not in konqueror location bar or vice-versa...

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 ...

> > > 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.  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. 
Thus, I figured we can nudge more people to follow the standards by making the
standards as flexiable as possible.

> > 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 ?

> 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.  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.  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.  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.

Regards,
Dawit A.

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