Re: High Contrast Icons

[Shaun McCance <shaunm gnome org>]

On Wed, 2005-11-23 at 13:55 -0500, Rodney Dawes wrote:
> On Tue, 2005-11-22 at 23:14 -0600, Shaun McCance wrote:
> > On Tue, 2005-11-22 at 20:47 -0500, Rodney Dawes wrote:
> > > On Tue, 2005-11-22 at 13:42 -0600, Federico Mena Quintero wrote:
> > > > On Mon, 2005-11-21 at 22:40 +0000, Thomas Wood wrote:
> > > > 
> > > > > If an application calls itself "accessible", having high contrast icons 
> > > > > should be one of the requirements. Applications are allowed to install 
> > > > > icons into the hicolor theme; if we're really taking accessibility 
> > > > > seriously, then high contrast themes should have a similar status to 
> > > > > hicolor.
> > > > 
> > > > How do we keep applications from overwriting each other's icons?
> > > 
> > > Don't name your application the same as another application, and
> > > namespace your icons appropriately? :) There is not really any good
> > > answer to this I guess. The same problem has existed with hicolor for
> > > as long as the Icon Theme Spec has been around. Applications should
> > > ONLY be installing their APPLICATION icon to hicolor or high-contrast
> > > though. Action, status, and other icons, should be part of the theme
> > > for now. We really need to design a good method for doing fallback
> > > themes and paths. The current API, in GTK+ at least, is not all that
> > > great for doing it.
> > 
> > Then what's an application to do when it needs additional
> > icons?  Yelp currently installs 10 images for admonitions
> > and watermarks that can be themed.  And I intend to add
> > more, whenever I get around to it.  All of the filenames
> > start with the yelp- prefix, so they're relatively safe.
> > But unless there's a good recommendation on how to name
> > such things, problems are going to arise.
> > 
> > Note that Yelp currently doesn't install these into hicolor.
> > Instead, it puts them into $(datadir)/yelp/icons and calls
> > gtk_icon_theme_append_search_path.  And while that's fine
> > for avoiding conflicts in hicolor, it doesn't help us when
> > themes need to override the defaults, as our a11y themes
> > certainly would want to.
> 
> It seems to me like these things would be useful not only to yelp, but
> other desktops' help browsers as well. We should probably come up with a
> common set of names if they belong in the icon theme, or a common help
> documentation theming method. Or both. It would be very useful to have
> a common method for theming the documentation through stylesheets. I
> think the closest thing we have now, is to just patch the stylesheets in
> the help browsers at build time.

Perhaps, but only if other help browsers agree with my design
decisions.  The admonition graphics certainly could be shared,
as any system using DocBook will need them.  The watermarks,
however, are unique to Yelp.  No other DocBook processor that
I know of watermarks blockquotes, programlistings, or screens.

As for general themeing of documentation, such as allowing
themes to set colors and such (which would be a nice thing
to be able to do), I'm not convinced it's all that important
to have a shared mechanism.  Getting QT and GTK+ themes to
look and feel similar and getting applications all drawing
from the same pool of themed icons is important, because
people often run non-$(DESKTOP) apps in $(DESKTOP).  Those
things allow applications to feel more native.

Documentation, on the other hand, should really all be done
with the same system, regardless of what toolkit you use.
So ideally, if you're running Gnome, your documentation for
your application would come up in Yelp, regardless if it's
a Gnome program, a KDE program, an XUL program, or whatever
else.  There's certainly some utility in making khelpcenter
and Yelp draw colors and such from the same data, but it's
probably not the most important thing in the world.  And
doing so will necessarily enforce some level of rendering
policy, giving us less flexibility to tweak output.

Back on topic: Real applications in the wild are absolutely
going to need to install some application-specific icons
for various actions or data that are unique to those apps.
Even if a sizable percentage of those icons are things we
could manage to abstract into generic icons, third-party
developers aren't going to wait around for new releases
just so their applications can function.  It's great that
we've finally managed to make progress on standard icon
naming, and I applaud everybody who's been involved with
that effort.  But it's important we have a recommendation
for random application-specific icon names.

--
Shaun