Subject: Re: libglade summary
From: Joaquín Cuenca Abela (cuenca@celium.net)
Date: Mon Feb 12 2001 - 05:40:39 CST
Paolo Molaro wrote:
>
> On 02/11/01 Joaqu?n Cuenca Abela wrote:
> > > 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
>
> It was a "generic" you, not directed specifically to you:-)
>
> > > 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 :-)
>
> I'm not against window users: if that platform has a technology that can speed
> up abiword development, by all means they should use it.
> Adding support for embeddable objects could have begun there a year or more
> ago, driving the use of bonobo on unix, for example. Instead what is more
> likely is bonobo support first, now:-)
That has (*nearly*) nothing to do with xp. We didn't have bonobo
support 1 year ago only because I'm lazy (and due to the way I took to
build the abi menus in the gnome build... but it was mainly because I'm
lazy).
> Instead I see that we have gettext and abiword doesn't use it, we
> have an aa canvas but abiword doesn't use it, we have other cool stuff
you could continue:
* We have gnome-print support and abiword doesn't use it... WHAT? WAIT
A MOMENT!! Hell, actually abiword uses it!!?
* We have a lot of cool widgets in gal, and abiword doesn't use it,
because is xp, and well, you know... But, what's that? Abi uses gal!!?
* We can build dialogs without a glitch using the glade/libglade combo
and you can't... (except in the libglade-lists branch, and when these
little problems with libglade disappears I hope it will be used too...
in the meantime, we just use the glade output as nearly everybody :)
* etc etc etc (sorry, but I can not think in any interesting lib right
know...)
> but abiword doesn't use it because it's not available on platform x.
> And instead of porting the technology to platform x, the wheel is
> reivented for every item.
*cough* *cough* read my last paragraph.
> What will happen in a couple of months
> when pango and gtk 2.0 will be released? Will abiword developers
> reimplement pango functionality in unix, windows etc, instead of
> helping the pango port?
Sorry, I don't have a glass ball, or something in these lines, but I
suppose that abi will be ported to gtk+-2, and pango will be used where
it makes sense.
> > > 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.
>
> I claim that all the time spent on XP, on dialogs that take minutes to
> build with rad tools and on gettext replacements could have benn better
> spent on documenting/enhancing/studying the layout engine.
So far, I don't remember a simple patch to our i18n system from the very
very beginning (3 years away?). The "dialogs that take minutes to build
with rad tools" are build with rad tools, anyway (it's just that, like
the 90% of apps out there, we're still using the C output from glade and
not libglade).
And if you check the entire tree, you will find some docs explaining the
layout engine. A few days ago, Mike posted a uml diagram of the layout
engine, and everybody that had the time, studied and understand the
layout engine
It just that some months ago the original architects of abi leaved the
development (except Paul), and that it took some time to the community
to learn all the stuff. Do you remember when Peter & Spencer leaved the
gimp? It followed some months where the gimp was, to say the least,
stagned.
(and I will not say that our i18n system is a "gettext replacement"...
is more of a quick hack that looks more like catgets than gettext).
> > > 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? :-)
>
> ?? You would use a single canvas for each file displayed, that's
> a widget per file. A canvas item would be needed for each displayed run,
> but that is not a waste at all.
So you will be capable to make blink a whole run without any problem,
but how will you make blink a single char? you should use the same code
that abi uses. The canvas doesn't help you here.
> > GnomeCanvas solves refresh problems, but not "ink drops". It's up to
> > your canvas item to not leave "ink drops".
>
> It's so hard to get this wrong with the canvas that that's not a useful
it's hard when you don't know exactly the pixels that you have to
erase. Implement a rich text canvas item (which BTW doesn't exists) and
you will have the same problem. It's *EXACTLY* the same problem.
> distinction:-) Besides, a canvas line item is already implemented.
> Making it blink is 5 lines of code.
exactly, so the question is: do you want a canvas *character* item
(which would be trivial to made blink, and a memory hog)?
If one day you try to implement a WP using the canvas and canvas
"character"'s items (just to avoid the "ink drops" problems), please
fire up [g]top and send me a screenshot :-)
I wiser move will be to implement a rich *text* item. If you do it, and
you do a patch to add gnome-canvas support to the gnome build of abi, we
will take it :-)
> Enough for a rant, just wanted to spark some discussion from a would be
> user that is not willing to spend develop time if he doesn't agree with
> the direction of the project and is frightened at the idea of having to
> use staroffice:-)
P.S.: this discussion is taking me, by now, the same time that it took
me to add libglade support to abi (yes, I know, I should become more
fluent in english...). Just to show that supporting a new lib is not so
hard, it's just that everybody is busy with his real live :)
Cheers,
-- Joaquin Cuenca Abela cuenca@celium.net
This archive was generated by hypermail 2b25 : Mon Feb 12 2001 - 05:41:42 CST