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

Re: Icon Theme Specification



Hi,
I'm more of a user than a develper, but I've been following this list (and hope to get involved evetually) and decided to comment.


I was wondering why not use some kind of ini style files. Icon files could be stored in /usr/share/icons and ~/.icons and their subdirectries. The ini file simply specifies which icons (by their full path) are used for what. There could be seperate section for the various types of icons (application, mime-type, etc). The file could inherit other files, and normally the version in the user's $HOME would always inherit the system default. 3rd party applications need only modify the system-wide (or $HOME version, depending on where the app is being installed...) file. Themes would be pretty easy to add, just modify the inherit line in the system or user version. So the master would be mostly empty, and simply inherit the default and whatever theme(s) desired.

The advantage to this solution is icons can be installed anywhere with any name. This should avoid some backward compadability issues. It also allows for prettier names. Collision avoiding is achived by renaming or putting into a subdir the colliding files, and altering the ini file. It would be possible to do this automaticly and dynamicly at install time.

Collisions in the ini file itself is another matter. For things like application and mime-types, however, collision isn't really a problem, two applications shouldn't have the same name and can't have the same path. For mime-types, they might get overwritten (although I would consider it rude for that to be done without atleast asking..), but thats not the worst thing in the world. And if you're theme is overriding the icon on that mime-type, it will continue to do so.

So the only place where real cooperation is needed is the system section. Things like copy, paste, open, new, save, save as..., etc.
I would recommend that, for example, if you're kde, and kde-copy exits you use that, and if not, fallback to just plain 'copy'. Do this for everything (and use gnome- if you're gnome, etc) and it should just work. This way, if there's a conflict on the meaning of something, we have a way to override it easily in special cases, while also making migration to the standard easy. This will also make those who want their GKT applications to look different than their KDE apps, while running at the same time in the same enviroment, happy. Although I consider that very silly.


For those who say "desktop X shouldn't be forced to use desktop Y's ugly icons!", the startup script of your desktop could always change the icon theme, and switch back on exit. But as long as a shared specification isn't actually limiting what the desktop could do in some real way, I don't understand objections about sharing.


--Tim



_________________________________________________________________
Join the world?s largest e-mail service with MSN Hotmail. http://www.hotmail.com






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