Re: nmf packages

On Thu, 2002-08-15 at 15:48, Nils Faerber wrote:
> you will see that the huge amount of work that is required to shrink X,
> Xlib, GTK and so on wihch requires very special knowledge will not be
> done within the next 1/2 year; not even within the next full year.

As a comparison, I think the move to Busybox in Familiar happened much
sooner than most people were expecting. Similiarly, lots of people
assumed that that would be too difficult to get working, and would never
really happen.

> GPE was about exactly that: Start now, do it with what we have _now_,
> keep it simple and come up with a solution quite quickly.

I presume you'd agree that that's what's happened; a relatively large
number of people (including myself) have been attracted to the project
for various reasons, and have indeed come up with solutions quickly.

Note that part of the reason I'm working on GPE is to get an environment
that's as close as possible to the one I use on my desktop machines. Of
course, some changes have to be made: I'm convinced that user-interfaces
on a PDA have different needs to desktop ones, so that applications need
to be designed differently. And there's clearly not enough space on my
16MB iPAQ to include all the GNOME libraries, for example.

> We have come very close to a working release of GPE.
> I refuse to stop GTK1.2 development now in favour of _waiting_ for GTK2
> and friends. The only solution I see is to fork.

Sorry, I don't think anyone's suggesting that it's time to stop GTK1.2
development. And forking would be a silly idea - there are some
applications in GPE CVS just now that will compile for either GTK1 or
GTK2 (via #ifdefs); forking would harm precisely those people who are
doing the best thing about the version differences (and the one that
already requires the most effort from them).

> One stable GTK1.2 based tree that will become a release and a GTK2 based
> new tree for development for tomorrow. But like any fork this has the
> disadvantage that we will also split efforts with this, i.e. there will
> be less time spent on the stable tree...

A forked tree would only potentially be necessary if, when everything
needed to support GTK2 is ready, some people would prefer to continue
development for GTK1.2.

While I'm not too enthusiastic myself about there being GTK2 code in the
tree now (my own applications in CVS are of course GTK1.2), it's worth
pointing out that: 1. my 16 MB iPAQ might not have space for the
GTK2-dependent gpe-nmf, but it certainly doesn't have space for audio or
video files! 2. the current code uses GTK2, but even if this is fixed,
it still gives us code that we didn't otherwise have. It's not as if
someone changed a GTK1.2 program to need GTK2. Changing it to use GTK1.2
would be less effort than writing it from scratch.

I would say that the fact that someone already prefers to write for GTK2
shows a practical reason we will need to move to GTK2 before that long:
in a short time many fewer people will want to write for GTK1, since
people who already know about GTK will be using GTK2 on the desktop.
Already myself I've had to backport some pieces of code from GTK2
programs to GTK1, and although they were fairly short it was a pain to
lose facilities and to have to make the code less elegant to make it
work at all.

Of course, if you simply want to criticise people for putting GTK2 code
into GPE now, then you're not saying anything against my own position.
But I'd hope that, if people do the work needed to make GTK2 a viable
option, you'll agree that there are good reasons for moving to that
platform. (And I haven't even mentioned any of the real advantages of
GTK2, such as the huge number of people in the world whose languages can
be displayed by it but not by GTK1....)

-- 
Moray