Re: glade

> From: Nils Faerber <nils@kernelconcepts.de>
> Date: Mon, 14 Apr 2003 20:35:05 +0200
> To: <Jim.Gettys@hp.com>
> Cc: philb@gnu.org, gpe@handhelds.org
> Subject: Re: [Gpe] glade
> -----
> On Mon, 14 Apr 2003 09:49:36 -0700 (PDT)
> <Jim.Gettys@hp.com> wrote:
> > There is serious discussion in the GTK/Gnome community of completely
> > removing any ability to generate C code from glade, it is hated so
> > much.
>
> Huh ... that will be a tough cut...
>

No, removing it doesn't break existing apps. It hasn't happened, as I
understand it, that no one has stepped up to the task of becoming
the new Glade maintainer.

It hasn't happened, as I understand it,
> > And if you maintain a non-glade GTK program, consider switching it
> > to use libglade, so that we can get things to work well both on
> > different resolution PDA screens (480x320 is soon to be "normal"),
>
> Oh really?
> Why not directly go for VGA like the new Zaurus? The display I saw was
> superbly crisp, high contrast and not bigger than nowadays iPaq
> displays. But 640x480 :)

I meant to say 640x480. Wrong neuron fired. :-). And we also have
the Jornada 720, for those lucky enough to get their hands on a flash
card for one. This issue is a burning one.

>
> > and when teleporting the application to desktop screens. We're going
> > to have to be able to handle differing screen sizes gracefully.
>
> Agreed.
>
> > Secondly, Glade helps in internationalization, as layout can be
> > tweaked as well as the translation to make everything fit well.
>
> Hmm... This should IMHO also be taken care of by the GTK widget packing
> engine which does a pretty bad job at times.

Agreed that the GTK widget packing code could use help.

But it can only go so far. There comes a point with some languages,
where you can't just depend on widget packing to fix your trouble.

>
> > Thirdly, it means you can get help with your UI without the person
> > helping having to learn the insides of your application.
>
> This is only very seldomly the case, isn't it?
> I can only hardly imagine situations where the UI can be tweaked
> signifacantly without having to touch the code.

The big one is where you really want/need to have very different UI's
for small versus large screens (and rotations).

I also don't think that what I said is necessarily a universal prescription:
it is of merit mostly for apps where presenting much different UI's for
different screen sizes brings the most bang for the buck: some simple
apps just don't need/should not take up much screen real-estate at the
best of times.

>
> But anyways, I see your point very well.
> Though I still think that we, meaning GPE, GTK and the hardware are not
> yet ready for it. If you look at the current images we are only very
> slowly regaining speed. We lost a lot of performance by switching to
> GTK2. And using libglade along with this huge libxml it depends upon we
> will again see a significant application startup delay.
>
> Until there isn't a libglade-xml-turbo-boost I would like to delay that.
>

Certainly worth investigation, to see if libglade actually
causes a significant performance issue.

Actually, we should probably try to do some profiling when we get .7 out
the door in general, to identify where to do work. All my experience
is that doing performance work before having done measurement is a
prescription for wasting time and effort. I'd like to know where time
is being spent, and why.

With some luck (I hope to have Vera at long last tomorrow); knock on wood),
we might have a .7 RC1 later this week; bug 99 is almost done.

                             - Jim

--
Jim Gettys
Cambridge Research Laboratory
HP Labs, Hewlett-Packard Company
Jim.Gettys@hp.com