Re: SVG format in metacity, gtk, desklets and build system for Gnome

[Bastien Nocera <hadess hadess net>]

Bowie? Is that you?

On Wed, 2003-09-03 at 14:22, Marcin Antczak wrote:
> W liście z śro, 03-09-2003, godz. 14:19, Diego Gonzalez pisze: 
> > On Wed, 2003-09-03 at 12:02, Marcin Antczak wrote:
> > > Hello!
> > > 
> > > I have some thoughts after reading "KDE and Gnome" threat recently on
> > > this list and I would like to share them and ask what do you think about
> > > it.
> > > 
> > > 1. About themes...
> > > 
> > > 	a. We have Metacity which uses specific XML structure do 	describe
> > > theme layout and elements.
> > > 
> > > 	I wonder why developer invents it's own "priopretary" format 	instead
> > > adapt SVG semantics?
> > > 
> > > 	b. We have librsvg with experimental SVG theme engine for GTK+ 	why
> > > community doesn't promote this way of describing user 	interface?
> > > 
> > > 	We have great SVG icon themes why not draw entire desktop with 	SVG?	
> > > 
> > > 	c. after karamba success we have gdesklets and they has it's own 	way
> > > to define properties in XML format - again not compatible 	with SVG
> > > 
> > > 2. About building and deployment
> > > 
> > > I know that this ugly GNU build system with their automakes and
> > > autoconfs are most popular way to build applications in Linux world.
> > > 
> > > But I think that it is really ugly way do deploy desktop environment.
> > > 
> > > I wonder if Gnome community couldn't use it's own more modern way to
> > > build, pack and deploy applications...
> > > 
> > > Just it's own package format and build system - I know that there's
> > > Garnome but I just compiled 2.4rc2.... it took me about 18h and I was
> > > really frustrated after this experience... (Ximian patches for GTK are
> > > nice :-) so I switched back to "stable" XD2).
> > > 
> > > Don't you think that Gnome desktop could have it's own modern build
> > > system, which could be fast and effective? (with easy way to define
> > > build preferences for applications and easy patching)
> > > 
> > it would be awesome, do you have time to start working on it? currently
> > one of the problems of every project is the *lack* of resources and
> > developers. If there is something that already works or that almost
> > works there is no need to change it.
> 
> Well I'm not C/C++ and especially I'm not M4 coder but I thought about
> some kind of web based service which would allow to interactively
> generate build scripts and resolve software dependencies - something
> like Ximian RedCarpet but not only for rpm based binaries which I think
> are really awful but for building.
> 
> I know that there is for example Garnome but in my opinion main
> drawbacks of Garnome is that you cannot easily apply patches for
> components and if you want to go with "make install" philosophy than you
> just don't know what you will get - some options could be missed because
> your system doesn't have opional libraries.
> 
> Sometimes if there is something really required you will get an error
> and compilation will stop but there will be a lot of software which will
> build and install but will lack some options...
> 
> And there is another drawback - there is no easy way to rebuild only a
> fragment of Gnome structure when your system settings will change or
> when only few libraries will change (for example you will add an alsa
> support with new 2.6.0 kernel, or would like to update mozilla etc...)
> 
> But... I'm not sure if I will have time to do this "for free".
> 
> I rather think that I could create some service like Ximian does but
> really based on Java engine and I would like to use Ant, Jelly, and
> other XML based technologies to generate shell scripts user could
> downolad and build binaries preconfigured and optimized for his needs -
> just something like more andvanced and interactive rpm spec files.
> 
> Maybe you could give me some opinions what do you think about this idea?
> Is it worth to spend some time and energy on this?
> 
> 
> > 
> > a new packaging system, those are mayor words, there are already enough
> > different packaging systems to built yet another one.
> > 
> > patching is easy patch -p0 < patch.diff, could there be anything easier?
> 
> Well, yes there should be - patch is easy but first you have to know
> where to find usefull patches and then you should know what konsequences
> patching could make. For example patches can add more dependencies and
> after patching your biuld procedure can crash because you will not
> resolve required dependencies etc...
> 
> And more currently rpm's are only known to me good way for "automated"
> patching (you have patches collected and you put these patches before
> building) but rpm'a are just like Garnome - they have "hardcoded" build
> options (maybe they are not big problem in gnome where you don't really
> have too much options but for example rpm and PHP is not really good
> couple - rpms are awful everywhere you have really modular construction
> and where you can build something as compiled in option or just as
> module...).
> 
> And these are reasons why I don't like any currently available
> distribution based on rpm's and on sources with Gnu build system and
> this is why I think about something different and really cool.
---
Bastien Nocera <hadess hadess net> 
McMurphy fell 12 stories, hitting the pavement like a paper bag filled
with vegetable soup.