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

>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

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 

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

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.

>  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

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?

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.

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


>> >
>> > 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,
>> Bill
>> ------
>> Bill Haneman x19279
>> Gnome Accessibility / Batik SVG Toolkit
>> Sun Microsystems Ireland 
> Best regards,
>  -Vlad

Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]