Frederic Wrote: > I think you are completely missing my point : a theme for a specific > toolkit MUST be desktop (and other toolkits) agnostic.. If you need to > patch your theme to read another toolkit settings, this mean something > is broken elsewhere.. You are fixing the consequences of the bug, not > the bug itself..
I suppose the "bug itself" is that KDE/Qt and GNOME/GTK use different color files, and thus each toolkit should be patched to fix this. However, even then, since a GTK theme like Galaxy has hard coded colors, at least part of the "bug" is indeed in Galaxy's court to fix. However, we must also consider this: what is the purpose of a "distribution"? Is it simply to pile a bunch of apps onto a CD? No, its to fill in the areas that aren't handled by other software and to turn a bunch of Linux and GNU packages into something useful. As I said before, using "menu" to keep KDE/GNOME/whatever else menus sync'ed isn't necessarily fixing the bug, but "fixing the consequences of the bug." However, lets face it: it is the smart way to do things until upstream fixes the "bug" completely. It works well. Likewise, a GTK theme that works with .qtrc (which you may feel free to rename, or you can create a cron job that creates a seperate .gtkcolor file if you don't want to be associated with Qt ;-)) is a good way to solve the problem of keeping colors in sync. If we apply the "don't fix the consequence" solution to menus, we would still have GNOME menus with one set of applications and KDE with another. Surely we don't want that. So why do we want the color equivilent of that? -Tim -- ---------------------------------------------------------------- Timothy R. Butler [EMAIL PROTECTED] Universal Networks http://www.uninet.info Christian Portal and Search Tool: http://www.faithtree.com Enterprise Open Source Journal: http://www.ofb.biz ================================================================
