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

[Marcin Antczak <marcin antczak e-dev pl>]

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.

-- 
Marcin Antczak <marcin antczak e-dev pl>