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

[Vlad Harchev <hvv hippo ru>]

On Sat, 9 Sep 2000, Guy Harris wrote:

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

 Sorry, I should have been used "point and click interface".
 
> ...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.)
 
  In general, if there was a mechanism for controlling "the font of every damn
widget in application", it will be very easy to write a tool that will call
the fonts in the task-oriented manner (like "font of clock in toolbar"),
rather than "font of GPanelClock") (and of course that mechanism will use
these widget-oriented names internally). But if the only mechanism for
controlling widget's properties doesn't allow specifying properties' values
specific for some apps, it will suck IMO. The general rule is "excess in
flexibility can't hurt once all this flexibility is implemented".

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

 Hmm, people use apps on monitors of different sizes/resolutions (so it's
impossible to select optimal dimensions of some dialog), there are
people with disabilities (like ones that are very short-sighted and need big
UI controls) or ones that use pointer device other than pointer and probably
don't use hands for moving it (so they need to increase scrollbar width for
example and increase double click timeout) - so things should be flexible to
allow precise configuration. Also, it's a setp to automation.

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

 Yes, I was attacking Xt.

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

  It seems you assume I propose to port editres to allow editing properies of
gtk widgets, without adding any features to make it easily usable. You
elaborate in wrong direction. I meant that in general tasks of that proposed
tool would be as the ones of editres, but it will allow doing these tasks in a
more user-friendly way.
  I (and seems others also) proposed to allow control of widget's arguments
(i.e., the one that can be set using "gtk_object_set", not "arguments" in very
general sense as "properties") via pattern-based strings similar to Xt
resources. Each gtk object's argument is identified by string. Compared to 
Xt, it's possible to query the following information for a argument of the
given name:

* type - whether it's int or string or whatever. 
* flags - whether it's writable, readable, or only for construction

* As I understand, gtk-2.0 will also provide long human description for the
argument's name.
* The information that would be nice to have is short human name of argument,
like "popup" - dunno whether gtk-2.0 will include that kind of info.

 The protocol used by gtk apps for exchanging information about arguments
should allow transfer of all this information, not just argument name.
 I think every programmer should understand, that having that information,
it's possible to provide gui controls for editing given argument depending on
all this (complete?) information. So, for example, that imaginary conf tool
will provide checkbox with label "show popup for all notebook pages" for
argument GtkNotebook::show_popup. That tool can present spinbutton for numeric
values, etc. As for fontselector you've mentioned - there could be real font
selector dialog, etc. That imaginary tool can provide custom
implementations of controls for arguments of types that were known at
compile-time (e.g. controls for editing default font and its attributes for
fontselector dialog, etc - so values of  _almost_ _all_ arguments can be 
edited using very intuitive means). That imaginary tool can have ability to
load implementations of "controls" for some GtkTypes at run-time (i.e. loading
modules). Also, to utilize the power of flexibility gtk resources will
provide, that imaginary tool will have options of applying modifications 
to all similar widgets (well, to hide word "widgets", that should be called
simply "apply"), to all similar widgets in that type of dialog, to all similar
widgets in that application (probably the last two should be accessible in
"advanced" menu or be immediately accessible in "advanced mode"). As for
double-click timeout - yes, that tool can interface for controlling it with
any paradigm (e.g. as in windows) by using agrument-specific control.

 I think that imaginary tool as I described above will be easy to use even for
newbies, and that it will differ from editres dramatically.

 Powerusers should still have access to raw gtk resources and should be
allowed to edit/create them, of course.

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

 The fact that you had to dig into these details is due to the absense of
the right configuration tool and that Motif apps' visual appearance is
controlled using Xt-resources also. It's easy to proper configuration tool for
Motif too (but I admit, it's much easier to write one for gtk (if gtk was
configurable via resources) since gtk also provides argument types).

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

 Agree. Intuitive way of setting window size for particular app or dialog is
easily implementable (by allowing to capture current size of the dialog).

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

 That's another topic - how that configuration tool can be accessible - via
control center or using any other means. 

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

 Probably you are right. But I predict there will be a lot of pain for us
international users (what will happen if I have 20 fonts in koi8 encoding and
80 fonts for latin1 encoding - will I only be able to use only least common
denominator 20 fonts( a set of fonts of the same familiy that are available
for both encodings) or all 100 fonts (since I don't always write in russian))?
 But this is different topic. Substitute "default charset" with "default font
size" or weight and you get the problem again.

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

 Providing that functionality in gnomecc is making gtk apps much less usable
without gnome, unless gtk arguments can be set using resources similar to
Xt's.

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

  That's another topic. Granted there are things like grdb and krdb that
export ui setup to xresources for use by Tk and Motif apps. Also, KDE2 seems
to be able to use gtk themes, so it seems there won't be the need to export
preferences from gnome to kde and vice versa.
 
> 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.)

 Yes, I agree with you. Flexible backend technology like Xt resources could
allow precise manual control over the values of arguments and will allow
creation of intuitive gui frontend(s).
 Yes, editres is a hack - but the hack that is the best gui way to control Xt
resources, there couldn't exist a better tool since Xt resources don't report
resource type (integer, boolean, string, color) - at least over protocol Xt
uses when talking to clients to query widget's arguments.

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

 Thank you for reply.

 Best regards,
  -Vlad