Re: KDE and Gnome

[Julien Olivier <julo altern org>]

> I agree with above - distributors are not for "hacking" themes and UI
> elements.
> 
> But I think we should start - especially in gnome/gtk world from
> documenting and puttind things in order.
> 
> Do you know any good documentation about creating gtk themes?
> Is this really possible without programmistic skills?
> 

No, in fact I have some experience in creating QT styles but I have
never really tried to do GTK themes myself.

> Maybe we could start with good - I mean _really_ good theme engine for
> example based on svg?
> 

Yes, I think SVG could be a better solution than pure bitmaps.

> And then.... create some exporting tools?
> 

I remember there used to be a (somewhat unefficient...) GTK themes
import tool for KDE2. It extracted bitmaps from GTK1 themes and tried to
convert them to QT2 styles. Maybe something like that for SVG themes
could work.

> Converting between good documented and standarized theme engine can be
> easy.
> 
> For example converter between WindowBlins and Metacity themes is easy to
> write and implement using easy tools as sh script + libxml + libxslt +
> ImageMagick.
> 

At least, it should be doable.

> > No it's not a bug ! The problem is that there are about only 3 unified
> > themes: Galaxy, Bluecurve and [K/G]eramik. That means that if you want
> > to fix this "bug", you have to remove every other themes from the GTK
> > and QT theme dialog and display only thise 3 themes. Then you can make a
> > script that synchronizes GTK and QT themes.
> > 
> > Then, if you want to create a theme for Linux, you have to create a GTK1
> > theme, a GTK2 theme and a QT3 theme instead of simply creating one
> > theme.
> 
> Maybe you could create just good scheme concentrating on graphics (for
> example in svg layout) and then export to any target format.
> 

Yes, but what is needed is an easy way for artists to create
"cross-toolkits" themes. AFAIK, those tools don't exist at the moment.

> Well maybe XMMS should die but Rhytmbox is a crap for now.
> 

I don't like to spread unverified rumours but I read somewhere that
XMMS's next version would split the interface from the core. So, it
should be easy to create a new interface for it anyway.

> > Of course it's feasible. All the library would return would be an array
> > of pixels defined by theyr RGB value (a pixmap). Then eahc toolkit would
> > draw it on its widget they way it wants.
> > 
> 
> Well maybe a library could be a waste of time but a good software for
> drawing themes could be very usefull.
> I think that could be something like TopStyle Css editor for Windows it
> contains informations about differences in Css implementations between
> web browsers. The same could be in UI on Linux.
> 

You're right. A good themeing program would almost solve the problem.
But it would need to be widely used. The advantage of a shared library
would be that toolkits that don't use themes (such as OpenOffice's
toolkit) could still (if they wanted to) "synchronize" their look with
other toolkits.

> 
> Marcin Antczak
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list