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. -- Shaun _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
