Re: nmf packages

On 15 Aug 2002 16:47:05 +0100
Moray Allan <moray_at_sermisy.org> wrote:
> 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.

I think comparison is not fair.
Adding busybox, especially the latest CVS versions, does not change THAT
much. Especially the needed changes are more or less trivial. But
changing Xlib, the X server itself or X11 toolkits is a completely other
area.

> > 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.

Yep!
And I am very pleased to see that we move foreward (and to be honest, a
little bit proud too ;)

> 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.

Sure.
That is more or less what we all want: Make this Linux iPaq a usable
tool that you will not want to miss one day.

> > 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).

I am not sure if this will work.
I have to admit not to know GTK2 at all but I suppose that you cannot
simply #ifdef everything out in any situation. Trying to do so will end
up in an ugly mess of code that no one really wants to maintain anymore.
As long as it can be done cleanly, OK with me; but as I said, I doubt
it.

And yes, we should very closely follow the GTK2 development and do
anything that a later transition will be as harmless as possible. But I
think that any line of GTK2 code written now inside the current GTK1.2
applications is simply wasted. To take full advantage of the new
features I suppose that most parts of the applications will have to be
rewritten from scratch. That's why I proposed the fork. Maybe not
necessary but that was my impression...

> > 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!

We are not talking about nmf itself now anymore. It was just the reason
to start this discussion.

> 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.

For the nmf example this might be true but I doubt it in general (s.a.).

> 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.

That's true. But this future you are referring to.
Now we have GTK1.2 and GTK2 is more or less far away from beeing usable
on the iPaq.

> 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....)

As I said before, yes I see the absolute need to change to GTK2 in
_the_future_. But not right now and not within the next month; even not
within the next half year. After that, maybe.

I suppose we are all working on GPE in our spare time, which is limited
by nature. And starting off with two toolkits in mind is a waste of
effort. Let's first finish this version and then go to the next, OK?

We will, promised ;)

> Moray
CU
  nils faerber

-- 
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          D1 : +49-170-2729106
--