Re: Status of configurable global options (double-click timeout, etc.)?

[Guy Harris <gharris flashcom net>]

On Sat, Sep 09, 2000 at 11:28:29PM +0500, Vlad Harchev wrote:
>  I think mentioning Windows registry is not suitable here. There is no a
> standard nice gui tool to edit some properties using the registry, and it
> won't exist IMO.

Define "standard nice GUI tool".  There's the Registry Editor, which is
a GUI tool; it exposes the low-level details of each tweakable knob,
which I would certainly agree makes it "not nice"...

...but I would think the same of a tool that *only* lets you tweak, say,
the font of every damn widget in an application, rather than letting you
say "OK, I want the 'system' font to be Arial rather than Helvetica". 
See, for example, the KDE Control Center, which lets you tweak:

	the "General font" (which is the KDE equivalent of the "system
	font", I think);

	the "Fixed font" (so that applications that want a fixed-width
	font, without having to provide their own configuration option
	to specify the fixed-with font to use, can do more than just ask
	for "fixed" or "6x13" or some other hard-coded name);

	the "Window title font" (exactly what it says);

	the "Panel button font" (which appears to be the font used only
	for the buttons on the KDE panel that select which desktop to
	display);

	and the "Panel clock font" (the font used for the clock on the
	panel).

(It doesn't let you *undo* those changes by clicking "Cancel", but
that's another matter; somebody needs to be chastised for that.)

>  It seems you don't use stubborn apps

You must've misread my mail, then; I said

	I.e., that might be a nice general mechanism, but I suspect most users
	of applications (and, if I'm not either

		1) developing an application

	or

		2) trying to beat a particularly stupid and stubborn application
		   into submission

	I probably fall into the "most users of applications" category, ...

which was intended to imply that, alas, I *have* had to beat into
submission applications such as that (there are a number of grumpy
entries in my ".Xdefaults" file for Netscape; they're especially grumpy
because some of them *don't even help*).

> - I think that will change in the
> future (at least not for you, but for other people).

There will, alas, always be stubborn and stupid apps, but the change I'd
most like to see is a *decrease* in the number of apps that require that
I go in and tweak options on individual widgets in order to make them
look nice.

> Also, if there was a 
> nice tool with interface like glade for editing properties of already running 
> widgets, even a newbie wouldn't have difficulty using it (compare to the ease 
> of Xt appres' ease of use).

I presume here that you're attacking, not praising "the ease of Xt
appres' ease of use"; appres just dumps out a lot of gunk that means
nothing to somebody not familiar with the gory details of X resources,
so there's no way that I would ever consider it even remotely easy to
use.

(The same applies to editres, by the way; about the *only* worthwhile
thing it does is let me click on a widget to configure it - once that's
done, it offers me the option to get a big list of resource names and
values, and the option to change a resource, by name, to a given value,
with the value specified as text.  Sorry, that's just the Registry
Editor with, added to it, the ability to click on a widget and pop up
the registry entry for that widget, which is, as far as I'm concerned,
an infinitesimal improvement.)

> And setting properties to widgets should be 
> pattern based like Xt's resources to allow customization the values of 
> parameters for specific app or dialog.

As an end-user, that sort of stuff is not even remotely what I want to
do; I wouldn't consider something that directly presents me with
something like ".Xdefault" entries even remotely user-friendly - if I
want to change the font for a particular app or dialog, I'd want to
click on the widget and get a menu saying something such as:

	Font
	Color

etc., which pops up a font selection box if I select "Font" and a color
selection box if I select "Color", and sets the font and color for that
particular widget in that particular app.

For more generic settings, I'd again want something nicer than typing
some string containing "*"s and names that I'd have to look up in some
document.

>  Owen told that there were plans to provide some aid for setting widget's
> arguments using patters, and in general I proposed to use the same technology
> for setting global properties by creating one-instance object, whose
> arguments will be global options like double-click timeout - i.e. not to
> introduce new API (that was the main idea of my letter, all other words was
> to prove that it can be done).

The only way I'd consider convenient/friendly for setting the
double-click timeout would be to pop up the {KDE,GNOME,...} Control
Center, select the correct item ("Input Devices->Mouse" for KDE,
probably "Peripherals->Mouse" for GNOME), drag the slider for the
double-click timeout to the appropriate setting (I seem to remember that
some timing setting of that sort in Windows had some way of providing
feedback for that; I'll have to look for that when next I fire up NT on
my machine), and click "Apply" or "OK".

If somebody *wants* to tweak it by specifying the random string that
happens to be the name of that property, I have no problem with them
being *able* to do so; I just do *NOT* want to be obliged to have to
remember that name - I'd rather remember details of what I'm using the
computer for (software development, whatever) than low-level technical
details of how to tweak the computer's UI to be what I want.

>  As for usefulness - I think that extra flexibility won't hurt usual users and
> can be enjoyed by power users or sysadmins.

If you want to make the extra flexibility of tweaking individual
configuration options available, fine; just don't make it *obligatory*,
e.g. if I want to set the font to be used for:

	window manager titles;

	window manager icons;

	label widgets;

	option menus;

	menubars;

etc., I do *NOT* want to be obliged to know that window manager titles
are "Mwm*fontList", icon titles are "Mwm*icon*fontList", label widgets
are "*XmLabel*fontList" (*and* "*XmLabelGadget*fontList", thanks to
Motif's widget/gadget distinction), option menus are
"*optionmenu.XmLabelGadget*fontList", and menu bars are
"*menubar*fontList".  (That is, by the way, *NOT* a hypothetical
example; setting those items, *plus* "*XmScale*fontList" and
"*XmBulletinBoard*labelFontList", to the appropriate Helvetica font is
exactly what I had to do in order to get Motif to use Helvetica rather
than "fixed" for them.)

> As for me, here is a list of
> things I would configured using this mechanism, in order of priority:
> * enlarged all file selector and font selector dialogs
> * provided default value for charset in font selector filter (currently filter
> 	allows all charsets)
> * enabled popups for all notebooks (that doesn't hurt at all)
> * configured properties of GtkCalendar (like whether week starts on monday,
> 	whether to show day names)
>   I would like to set options listed above for all widgets of the same
> type.
> 
>  Also, there are a lot of app-specific setting I wished to tune, like
> assigning window classes and window sizes for dialogs of various apps.
>  I think everybody would love to tune options listed above - even a newbie.

The way *I'd* like to tune window sizes for dialogs is to grab one of
the corners of the dialog and stretch it, and have the application
either remember the new size by default (or, if it's a "generic" dialog,
remember it globally, but not all file selection boxes, for example, are
the same - applications may have to add their own controls to it, e.g. 
the "Save only packets currently being displayed" check button and a
"File type" option menu that I added in Ethereal - so one may not want
all file selection dialogs to be *exactly* the same size).

I *might* be willing to have that editable, for "generic" dialogs, from
a system control center application; the app would let me select dialogs
from, say, a list of named dialogs and/or pictures of part or all of the
dialog, and would pop one up and let me resize it.

For the default charset in the font selector, I have the impression that
it may not exist in GTK+ 1.3/2.0, with the Pangoization of font
handling; even if it *does* exist, I'd see that as being set in the
control center as "Character Set", or even set based on the *language*
you've configured the system to use, rather than being set as the XXX
property of the font selection dialog box.

The same applies to at least some of the GtkCalendar properties; you
should be able, in the control center, to choose whether the week begins
on Sunday or Monday (or to have that set automatically based on the
locale, with an override for people who don't want the locale's default
behavior).

Now, whether, at the *implementation* level, something that can be
configured globally from some control center should be implemented as a
single property, or if there should be a pile of individually
configurable parameters all of which the control center sets, or if
there would be both a global value manipulated by the control center
*and* individual parameters that default to values based on what's set
by the control center, probably wouldn't matter to me.

I suspect the third choice there might be the best, as:

	it keeps the control center from having to *infer* the setting
	by looking at a pile of pile of properties;

	it means the control center doesn't have to be taught about
	*new* properties that a given setting should affect;

although, if it's to be able to configure *all* applications, not just
those for the toolkit/desktop environment to which it belongs, it'd have
to know about properties for those toolkits/desktop environments that
don't implement this model, e.g. if it's to tweak Motif applications.

And, yes, I *do* think that the {KDE,GNOME} control center should,
ideally, be able to control non-{KDE,GNOME} applications, so that, for
example, the KDE "General font" is used as the default non-fixed-width
font by KDE applications and GTK+ applications *and* as the appropriate
font for Motif, etc. applications.)

This would allow those who *want* something that lets them tweak
individual widgets do so, but it would let those of us who have better
things to do with our neurons than have them know or care about the
internal structure of applications on which we're doing development work
*not* have to know or care about them (note that editres *DOES* oblige
me to care about the internal structure of applications, as it displays
that structure to me!).

In short, if you like editres, fine; don't *oblige* me to use something
like editres for all configuration, though, as I consider editres to be
a complete hack, not a component of anything resembling a sane GUI. 
(Perhaps it was intended, by its author, to be a sample of how to work
with the resources database, rather than to be the way one configures
applications; if so, I won't flame the author for writing a hack, but I
would *not* use it as an example of How A Desktop's Configuration Tool
Should Work.)

(NOTE: I'm not saying GTK+ should itself provide a control center tool
along the lines of what KDE and GNOME provide; it should just *allow*
control center tools to configure applications in the way I suspect 99
44/100% of users will want - no, I do *NOT* believe that most users will
want something editres-like, and you're going to have to work a lot
harder than I suspect you believe you will in order to convince me of
that.)