Re: proposal: slight extension of gtkrc syntax for per-app settings

[Vlad Harchev <hvv hippo ru>]

On Tue, 1 May 2001, Bill Haneman wrote:

 Hi Bill, 

> >On Tue, 1 May 2001, Bill Haneman wrote:
> >
> > Hi Bill, 
> >
> > First of all, it's also possible to load different gtk theme on 
> >per-application basis by setting environment variable or (for gnome apps) by
> >putting gtkrc in the file under special name. And of course there is a
> >programmatic API for changing the style of a particlar widget. The
> >proposed change just provides much more user-friendly means for selecting
> >themes (and probably shooting themself in the foot) - but it doesn't provide
> >any additional means to app developers (they already have everything at their
> >disposal).
> 
> Hi Vlad:
> 
> Yes, this is a good point - you are proposing a "cleaner" way of doing something 
> that is already possible.  I suppose I sounded a little strident, apologies for 
> that.
> 
> >  The advantages of the proposed changes will allow theme creators to
> >more elegantly (in single file) provide per-application theme tuning (in 
> >particular, to increase accessibility).
> 
> I don't quite understand how this would work; are you proposing that themes that are 
> selectable from a "single point of control" would have additional per-app 
> information?  I still think the potential for abuse is very large.  On the other 
> hand, if we are talking about a single file, this could indeed provide a way of 
> improving accessibility if this file could override application properties.

 Yes, the changes I propsed will allow to include per-app configuration
information in one single file.
 Unfortunately gtkrc file can't override values of properties if application
sets them explicitily (programmatically) - that's why gtkrc settings are
called "defaults" of course - but I think that there are few applications that
do this, and the ones that do, do this due to a good reason and do it
properly.
 
> Also, it's actually important to accessibility that things be consistent.  Screen 
> readers or magnifiers may be set up to expect certain behaviors/font metrics and be 
> poorly tuned for others.  Also there may be cognitive disability issues, some 
> dyslexic users report that choice of fonts is important to their readability... in 
> which case those fonts should be used across all apps, not on a per-app basis.

 Yes, I agree that changes I proposed will allow to more easily cause
accessibility issues - but they will also allow to solve accessivility
problems of some applications and offer *incredible* oportunuty for
customization of *properties* and *styles* (usually accessibility issues are
related to styles).

> >  Also, if not at the first hand, Gtk-2.0 allows changing widget properties
> >from gtkrc too! For example, power user will be able to control the default
> >directory for file selection dialog in Gnumeric spreadsheet to one directory
> >(say, ~/files/sheets/) and default directory for file selection dialog in
> >AbiWord to another directory! Or control default font of font selector on
> >per-application basis (or, hopefully, default buttons in various dialogs in
> >various apps or default state of checkboxes on per-dialog and per-app basis) -
> >and all this flexibility comes without any additional efforts from app
> >programmer! 
> 
> But these two examples seem like very bad ideas from a consistency point of view, 
> and what if I need to use a particular font across all file dialogs?  Could I do 
> this without "breaking" the behavior which the application or user has modified 
> using the rc file?

 Of course it will be possible to override anything if .gtkrc is structured
properly - as say, gnome control center organizes .gtkrc it writes - it puts
	include "~/.gtkrc.mine"
at the and of program-generated (in fact, Gnome Control Center-generated)
.gtkrc file so that user will be able to override ANYTHING in "~/.gtkrc.mine".
Of course nothing will break if you use a particular font across all file
dialogs - it may just will look non-harmonical.

> I suppose I am concerned that the modification makes this "too easy", I am not 
> convinced that it should be encouraged.  
> 
> My belief is that the right way to improve consistency and accessibility
> is by using a consistent set of styles across applications, not "tuning"
> them on a per-app basis.  If there is a good argument for modification of
> the default styles, then my suggestion would be to extend the style
> property set - if there is really only one customer for a particular style
> modification I would question the modification.

 I think we shouldn't be afraid that much about newbie-user messing up their
preferences since typically gtk resource files indirectly read by each program
come from following sources:

* files in /etc/gtk/* - these are typically for locale-specific definitions.
 These are shipped with gtk itself.

* machine-generated ~/.gtkrc - this file is typically generated by
configuration tools.

* gtk theme. It's composed by a theme author and can't be altered without
additional efforts or hand-editing ~/.gtkrc. Typically 99% of resource
definition statements happen there. Theme author is responsible for
customization and accessibility issues. If some theme is bad from
accessibility aspect and that it's known fact, sysadmin will remove that gtk
theme, or reasonable distributor won't ship it with their distribution. Or
themes can be "certified" by usability esperts.

* final overrider for all settings - it's "~/.gtrc.mine" in case of Gnome
Control Center. No well behaved application edits it. No user without adequate
knowledge edits it too.

 So, in order newbie-user messed up their styles on appliction-specific basis,
s/he has to learn programming with gtk widgetset, syntax of .gtkrc that not
every gtk-aware programmer knows about, and then edit his/her ~/.gtkrc.mine.

 So, chances are extermely low that proposed change will raise some
accessibility issues. It's just as high as Windows users hacking gdi.dll using
hex editor to replace some bitmaps.
 On the other hand, the proposed change will allow powerusers, ISVs and system
administrators to fully customize various aspects (not only visual
appearance!) of their gtk2.0 based applications.

> >Also it won't be very difficult to write GUI configuration tools
> >that will allow to configure resource values interactively (e.g. user will be
> >allowed to point to widget in any dialog, configure properties, and save new
> >dialog defaults).
> >
> > So, that flexibility will open another dimension in ease of use and
> >configurability of gtk-2.0 based applications. Just to add, all apps that use
> >Xt-based widget sets already have it.
> 
> Yes, and I believe (though I will defer to Calum's opinion on this) that
> this configurability has been a sore point from a usability perspective.  
> It may be that this is more of a mis-feature than a selling point for Xt.
> 
> 
> Best regards,
> 
> Bill
> 
> >> >
> >> > Hi, 
> >> >
> >> > Nobody replied to original letter.
> >> > Does anybody have anything to say about this? Why shouldn't gtk apps 
> >> be as
> >> >easy customizable as apps using Xt-based widgetsets?
> >> >
> >> > Will the patch be accepted that will implement proposed features?
> >> >
> >> > Best regards,
> >> >  -Vlad
> >> 
> >> Hi Vlad:
> >> 
> >> Though the type of customization you suggest (if I understand you 
> >> correctly) adds great flexibility, its widespread use could create very 
> >> serious problems for the desktop.  It's generally considered important 
> >> for UIs to maintain consistent styles across applications on the 
> >> desktop, and you proposal would make it very easy to subvert this.
> >> 
> >> An important functional aspect of this (as opposed to cosmetic issues) 
> >> is that a global theme which supported accessibility for low vision 
> >> users (or color blind users, etc.) could easily be broken this way.  If 
> >> styles and themes are not applied uniformly across the desktop then they 
> >> cannot be fully effective.  To be blunt, your feature would probably 
> >> break accessibility. 
> >> 
> >> This concern is just as valid in Xt, use of .rc files to override 
> >> default styles is potentially very antagonistic to good user interface 
> >> design and presentation of a consistent-looking, usable desktop.  In 
> >> effect, giving applications (and app developers) more control over the 
> >> style of the toolkit effectively takes control away from the user - it's 
> >> a big tradeoff and not necessarily the right thing to do.
> >> 

 Best regards,
  -Vlad