Re: [gtk-list] Re: Gzilla widget set design proposal

[Raph Levien <raph acm org>]

On Tue, 24 Jun 1997, Kay Winkler wrote:

> Sascha Ziemann wrote:
> 
> > This will be a very bad decision if someone wants to create a
> > Java-capable browser. The more I think about this new widgets, the more
> > I come to the conclusion, that this is the wrong way! On Windows are no
> > extra widgets for the Browser, either. And the masosado-browder scrolls
> > quite fast. Why should this not be possible with GTK? It's really bad
> > design, if one has to create always new widgets, if a bit more
> > complicated problem occurs.
> 
>  I'd second this, as in W3C there are decissions for extendet Forms
> which allow 
> keyboard accelerators too. So an HTML/XML widget will realy nead all
> this stuff.

Hopefully my reply to Sascha made it clear that this is _not_ a problem. 
Forms are implemented as GTK widgets, which support keyboard accelerators 
already.

>  On the other hand, i thought, that an scrolled widget is by now
> realised by a rendering only a small amount outside the viewing area  in
> advace and maps this 
> on scrolling. So what's wrong with this design using in GTK?

That's only true in some cases. When a new widget gets added to a
container, in all existing GTK containers it currently forces repaint of
the entire container.

But that's only one of the problems. The 32767 pixel size limitation and 
lack of support for wrapped text (especially in laying out tables) are 
more serious, and I don't see any acceptable workaround that stays 
entirely within the GTK framework.

It might be possible to extend GTK to directly support everything I need, 
but I think my solution has some advantages - it will take less code, 
offer higher performance, and avoid the need to completely rework the GTK 
widget set.

Raph