Subject: Re: libglade summary
From: Joaquín Cuenca Abela (cuenca@celium.net)
Date: Sun Feb 11 2001 - 13:47:47 CST
Paolo Molaro wrote:
>
> 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:-).
I'm not an anti-gnome advocate, but the point of a non-gnome dependent
lib is that it doesn't depend in gnome (it's only me, or it sounds
silly?). Definetively the non gnome version of libglade should not
depend on gnome.
> Anyway, I will probably remove the dependency in the next upload
> for the sake of this silly argument vanishing.
ok
> > 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.
And I think that pretty much everybody agrees with you.
> <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.
Let's going to try to change your mind :)
> 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.
There are some windows users in the community :-)
> 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.
nah, it's only that the layout engine is hardest to understand. If you
had a platform specific wp, you will have many little contributions for
the dialogs and general UI fixes, but anyway few people will understand
and be able to contribute to the layout. Nothing to do with xp.
> 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.
I don't know if the decision was due to portability issues. Anyway if
somebody contributes autoconf/automake support I will be happy to
contribute gettext support.
> 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
Are you thinking in using an entire widget per char? :-)
GnomeCanvas solves refresh problems, but not "ink drops". It's up to
your canvas item to not leave "ink drops".
> 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.
Don't worry about this one.
P.S.: Maybe using gtk+ as toolkit for all the platforms is not
desirable, but I agree that there are some unix libs that would be cool
to use in all the platforms.
Cheers,
-- Joaquin Cuenca Abela cuenca@celium.net
This archive was generated by hypermail 2b25 : Sun Feb 11 2001 - 13:47:52 CST