From: Paul Rohr (paul@abisource.com)
Date: Tue May 07 2002 - 14:07:54 EDT
At 10:28 AM 5/7/02 +0100, Tomas Frydrych wrote:
>I would like to remove all the non-bidi code from the HEAD, leaving
>the next version of AW bidi-only. I have talked about this with Dom
>a while back, and I think now, before Martin gets too deep into the
>rewrite, is the right time to do this. This will not only reduce the
>clutter in the sources, but also pull our bugfixing and developing
>resources together. The Pango stuff will only be inside the bidi
>branch anyway, and I am hoping that the Pango layout engine will
>be the only one actively developed by mid summer (Owen Taylor
>tells me that he knows people using glib on all our target platforms
>except BeOS, this would get rid off the main hurdle in our way; I
>will try to get some contacts).
Just to be clear on the proposal. AFAIK, there are three possible variants
of the codebase:
1. native, non-bidi ... the well-tested code that everyone uses now
2. bidi ... some testing, not enough use
3. Pango-based ... to be written and/or ported as needed
I understand why it'd be worth replacing #2 with #3. If Tomas says the
portability problems are worth wading through to gain the future leverage of
Pango support for bidi and shaped scripts, then I'm more than willing to
believe him. Likewise, on any day that he says it's worth turning off
support for #2 in favor of #3, I'll believe him.
I also am willing to believe that we'll get to the point where #3 is good
enough that we should *also* replace #1. However, I'm stunned to hear that
we're already at this point.
Are we? Really?
>If you have objections to me removing the non-bidi bits then please
>voice them now, otherwise I will do this over next weekend.
I object. I think.
We currently have code that Just Works for all "just fonts" languages.
http://www.abisource.com/mailinglists/abiword-dev/02/Apr/1163.html
Most of the developers we hope to attract will only care about those
languages, and we *definitely* want them working on HEAD. Yet it sounds
like you're talking about *removing* that proven code immediately. Why?
While it may make life easier for Pango development to force all developers
to live through that transition as it happens, it makes *much* more sense
(for other developers) to *not* switch everyone over until Pango is further
along.
There must be something I don't understand about this proposal because it
sounds like you want to:
Break the tree to force (other) developers to help fix it.
That sounds so backwards I must be missing something here.
Paul,
quite puzzled
This archive was generated by hypermail 2.1.4 : Tue May 07 2002 - 14:09:28 EDT