Re: RFC: 2.3 feature list

On Mon, 2004-11-22 at 10:35 +0000, Tomas Frydrych wrote:
> 1. EndOfBlock strux
> In my view this is an absolute must, and should be among the first
> things we do; if nothing else, it will make it possible for the user
> to select blocks in an intuitive and unambigious manner.

It is already the plan to add End<Strux> struxes to various
Section<Strux>es that don't already have them (ie, HdrFtrs) in 2.4.
This might not be a bad time for you to coordinate with martin about
EndBlocks.

> 2. Pango graphics on *nix
> We have made good progress with support for complex scripts on Win32;
> need to catch up on *nix.
>

There is no reason whatsoever for usage of pango/cairo to be _limited_
to unix. I have no intention whatsoever of trying to force it on win32
folks who have uniscribe, but there's no reason for us to develop it as
unix-only.

> 3. Enchant on win32
> I would quite like to see this, to be able to make use of any
> system/other spell-checking libs, just as fjf is doing on the Mac,
> but have not investigated the feasibility/real usefulness.

I would like to see this too. So would other key people. Of course,
it's not about what we'd like to see, it's about what's _going to
happen_. If we don't limit ourselves to looking at what's realistically
going to happen in the next 2-3 months (coming from branches and taking
form in mainline alike), we'll have another 14 month release cycle. I
have no intention of letting this happen again. However, getting back
to the topic at hand, I think enchant on win32 is readily feasible, but
I'm not volunteering for the job.

> 4. XP framework for Ink support conforming to InkML
> (http://www.w3.org/TR/2004/WD-InkML-20040928/)
> Ink support would be very cool, particularly considering the
> TAbiWord project (see sourceforge).
>

I think merging tabiword and abiword should take place in a branch.
It's just the kind of overhaul that could potentially stall concurrent
testing and development. That said, everybody's a volunteer, so whoever
wants to do this (in a branch) is more than welcome to. But since there
is noone with an explicit intention to do this before 2.4, we should not
be considering it in forumulating the 2.4 timetable. We don't know if
it'll be 2 weeks, 2 months, or 2 years.
Lots of things "would be very cool," we MUST limit ourselves to what we
realistically intend to cover in the next 2 months or quite possibly
have polished in branch in 3 months. And a key point of branches is
that the 'feature list' doesnt limit or be limited by the release
_cycle_.

Math support is under development in branch and is NOT ready to be
merged. GSF IO also is not near ready, but this will take much fewer
manhours than math in general so I'm less worried about it. Once it
works in branch and doesn't fsck over otherwise working platforms, it
should be mergable (as long as we aren't frozen by then). RC is
unfortunately in the same branch but is nearly ready to be merged, so
I'll hand-merge that when I get the goahead from the lead dev with whom
I've talked (after 2.2 is branched).

On that note, 2.2 cannot be branched until after a significant number of
first priority 2.2.x bugs are fixed. NOT all of them, but there's quite
a few that we really felt sick to our stomachs about releasing 2.2
without. Fortunately, I've seen some broad support on irc for this
idea. As for timeframe for this step, it all depends on bugs fixed. If
there's great progress in this respect in the next two weeks, that's all
we have to wait. If the next two weeks are completely quiet from the
coders, branching might be a fine christmas present as fjf pointed out.

Regards
-MG
Received on Mon Nov 22 15:15:46 2004