Subject: Re: libglade summary
From: Paolo Molaro (lupus@lettere.unipd.it)
Date: Sun Feb 11 2001 - 13:33:16 CST
On 02/10/01 Joaqu?n Cuenca Abela wrote:
> 1. It depends in gnome
>
> False. It's only that the packagers seems to have little interest
> building libglade with the --without-gnome configure option. We can
> provide binaries of libglade compiled with gnome support turned off.
A few comments as debian maintainer for libglade:
at the time I packaged it, I added a dependency on libgnome-dev because
libglade provides a libgladeConf.sh file that is actually useable
only with gnome-config (installed by libgnome-dev). I see that
can be a weak argument, but installing libgnome-dev is not a big deal
on a development machine unless you are an anti-gnome advocate
(but that is your problem anyway:-).
Anyway, I will probably remove the dependency in the next upload
for the sake of this silly argument vanishing.
> 2. It depends in libxml-1, and depending in expat & libxml-1 or
> libxml-1 & libxml-2 is a very bad idea
>
> True (the first part) and (partially) false (the second one).
>
> We're not in windows. We can have in the same system two different
> versions of the same library without any problem. The only conflict
> between libxml1 & libxml2 was that their -dev packages both included a
> little xml-config script. Now this problem is solved, because libxml2
> has changed this script to xml2-config.
The problem is that both libraries provide the same symbols, but some
have incompatible interface, so, while you can have both installed on the
system, it's not safe to link an application to both of them.
libglade on debian will link to libxml1 for some time, until the
major users of the library will support libxml2 two themselves
(I think libglade already works with libxml2): this means probably
by the end of the year.
> 4. It requires gettext to do i18n, and we don't support gettext
I think abiword should use gettext on un*x, just like it uses
a native widget set on every platform.
<warning opinion="lurker">
I do not mean to start a flame war, but I hope some of my comments are
useful to the actual developers, I didn't contribute anything to abiword for
a number of reasons, some of wich are outlined below.
I follow the abiword development since almost the beginning and one of the
first things you note is the slowness in the development (this was true also
when abisource supported the product with more resources).
I discussed this with Paul (I think) at LWE in New York last year
and I think he said the same thing during his talk: XP development
seriously hinders the progress of abiword. At the time he said that
targeting windows users was important for the company, but that should not
be a great concern now that abiword is more community-supported.
The problem is that a lot of effort goes into XP and at the same time the
layout engine has seen little or no changes and a lot of development time
is spent in dialog (?) or other basic support issues.
Take gettext support as an example: gettext is available and working
in unix (and I'm sure it would require little effort to port to windows, if
it's not already done) and yet a different mechanism was developed and
tools to support it instead of reusing already available code.
This means that the port that could be potentially moving faster is slowed
down by all the others.
Another example: for quite some time there were little gliches here and
there in the rendering code (the cursor let ink drops etc.). If abiword
used GnomeCanvas as the rendering engine that would not be a problem
and abiword could then with very little effort support things as
the alpha channel, arbitrary transformations and lots of other goodies.
All this will take years to implement in all the platforms.
Less efforts would be required to help porting/testing gtk on the
same platforms and have a better product at the same time.
So my advice is: let the fastest growing port (or the one with more
potential) make the road. Some of the other ports may die, or may take
different approaches to the porting, but that can also stimulate
innovation. Do not make the same mistake now not allowing libglade.
You'll have a better product in the end.
</warning>
lupus
-- ----------------------------------------------------------------- lupus@debian.org debian/rules lupus@ximian.com Monkeys do it better
This archive was generated by hypermail 2b25 : Sun Feb 11 2001 - 13:30:54 CST