Re: SVG format in metacity, gtk, desklets and build system for Gnome
- From: Diego Gonzalez <diego pemas net>
- To: Marcin Antczak <marcin antczak e-dev pl>
- Cc: gnome desktop <desktop-devel-list gnome org>
- Subject: Re: SVG format in metacity, gtk, desklets and build system for Gnome
- Date: Wed, 03 Sep 2003 14:19:25 +0200
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.
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?
Diego
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]