On Fri, 2009-04-17 at 14:39 +0100, Joel Holdsworth wrote: > > I would recommend having wine follow the Icon Theme Specification, and > > load the icons from the system theme this way, to integrate with the > > rest of the system. > > The problem is that these icons have to be baked into the dlls at > compile time as windows resources - that is the way Windows does icons, > so wine has to as well, otherwise it'll cause incompatibilities.
Not exactly. It means that a request for those resources in those dlls needs to return an icon. It doesn't necessarily mean that the resource must actually be compiled in to the dll. > The reason to choose tango icons is because of their high quality, and > because they look good on different colour backgrounds for example. > Also, even though it won't match some themes, the tango style guidelines > will help the wine look less conspicuously bad on a good proportion of > target platforms. Yes, and the Tango style guidelines do not mean that you must use the icons from tango-icon-theme, and the style guidelines are not CC-By-SA either. Anyone can create icons under any license that follow the guidelines. However, the current guidelines on the web site are a slight bit out of date at this point, with the icons we are actually creating these days. Also, the SVG icons you linked in your original mail are not even from tango-icon-theme. They're from gnome-icon-theme which is GPLv2. I also don't really think the wine glass is a particularly fitting metaphor for "thing that runs Windows programs" so much as a logo/mascot for the project. Simply sticking it on top of other icons, doesn't really explain what's happening to end users who aren't already somewhat familiar with what wine is. Rather than taking existing icons that are in the Tango style, and sticking the wine glass on top of them, it would probably be better to draw somewhat more distinct/branded icons for the various apps. As for sticking icons in the DLLs, I would recommend using the icons from the tango-icon-theme git repository, and using the artwork in the tango-icon-library git repository as building blocks for others, when you can't load them from the user's theme. > > This could be done by writing a driver back-end that > > uses GTK+ or Qt to load the icons, or by writing an icon theme > > implementation in wine itself. It would also be really sweet if there > > was a GTK+ display driver in wine that used GTK+ to draw the widgets, so > > that wine apps looked the same as the rest of my system, but that's a > > lot more work I think. > > This is a similar problem to above. There is a slow push in wine towards > getting Windows UXThemes supported, but for the sake of applications > this will likely have to be provided through windows .theme mechanism. > People want Gtk and Qt-like Wine themes, but these will likely be > provided through theme files crafted to look like Qt and Gtk. Well some apps will just do their own thing anyway. I don't know how you would create a UXTheme that is cratfed to look like Qt and GTK+, when there is no set look for either toolkit. The look of the toolkit depends on what theme the user is using. Having a specially named UXTheme that causes wine to use some other code to do stuff instead might be better, and still let one do things. > All this because of application compatibility! It really depends on how you define compatibility here. I don't think either of my suggestions would break compatibility for apps. But if you define compatibility as 100% exact clone of what it looks like on a specific version of Windows, then even providing different icons than what is on Windows, would break it. :) _______________________________________________ Tango-artists mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/tango-artists
