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

[Raph Levien <raph acm org>]

On Tue, 24 Jun 1997, Sascha Ziemann wrote:

> Raph Levien wrote:
> 
> >    I've decided that Gzilla will contain its own widget set
> > specialized for the display of Web pages.
> 
> That does not speak much for GTK, if it is not possible to build a
> "real" application with GTK. I don't think that Motif needs some extra
> Widgets.

   I think you've misunderstood the main focus of what I'm proposing. 
It's definitely possible to build a real application with GTK. Gimp is 
one, and I fully intend for Gzilla to be one. However, to do a really fine 
Web browser, I'm going to need to add some widgets to GTK. I want to get 
table support exactly right, and to do this I'm going to need to change 
some of the interfaces.

   Rather than showing that GTK is inadequate for the task, my approach 
shows one of the strengths of GTK - that it is quite easy for application 
writers to make their own customized widgets if that's what the 
application needs. This is _much_ harder in a framework such as Tcl/Tk.

   I don't think that the "no extra widgets" design philosophy is a good 
one. Take a look at the Grail browser, for example. It uses Tcl/Tk tables 
to implement HTML tables. Well, Tcl/Tk tables are ok, but not quite up to 
the task of full HTML tables, which are quite demanding. Consequently, 
Grail's table support is weak. That's not the way I want to go with 
Gzilla.

> I am thinking about a spreadsheet. There will be the same problem, if
> you look at a database with 20000 entries.

   Yes. So use my scroller! It would have to be extended with keyboard 
support, but that shouldn't be a big problem. I tried to leave out 
everything from the design that wasn't absolutely needed in a Web 
browser, but I see no problems with adapting the basic design.

> Perhaps it will be usefull for GTK, if the objects are not created at
> the time they are defined but at the time they become visible. Perhaps
> this can be implemented via flag, because this method will be slower
> than the normal way. What do you think about such a feature?

   I'll probably implement my scroller so that objects get size allocated
when they're added to the page, but not realized and mapped until they
become visible. Is this what you meant? 

> > 3. GTK size negotiation doesn't support wrapped text. In other words,
> > there's no way for the height of the widget to depend on the width.
> 
> Perhaps this would also be usefull for the other widgets.

   Perhaps. I've heard rumblings that the size negotiation in GTK might 
get redone - there are definitely performance problems in there that come 
out when you have very large containers. If S&P choose to support 
wrapping widgets in the next go-round of GTK, then I hope they will be 
able to make use of some of my Gzilla work.

   Meanwhile, it's possible to get things done now without waiting for a 
new GTK. That's what my Gzilla widget set is designed to do.

> >    Thus, I propose a new Gzilla widget set to function alongside the
> > GTK widget set. Gzilla widgets will be extremely specialized - they
> > will lack all features not required for Web page display (I have in
> > mind grabs, focus, keyboard accelerators, key events, selections, and
> > connectable signals, leaving only size negotiation, exposure, and
> > mouse events).
> 
> 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.

   It _is_ possible in GTK. All the "missing features" I listed are still
accessible - you just need to do them in a GTK widget and then embed the
GTK widget inside a Gzilla container. I see no reason why a Java applet
couldn't be handled this way. Gzilla 0.0.9 supports forms quite nicely
now, using this exact technique.

   Are you saying that no Windows browser defines any new widgets? I find 
that hard to believe. (Actually, from what little I know about Windows 
programming, it's not structured around widgets in the same way as GTK, 
but rather around "child windows").

   Certainly, all state-of-the-art browers contain table layout code of
some complexity, including size negotiation of wrapped text. Perhaps if I
had called my proposal a "wrapped text table layout interface" instead of
"Gzilla widget set" it would have met with less alarm. But I did call it a
widget set because it's very similar in many ways to the GTK widget set -
the widget/container hierarchy is basically identical, and the way that
widgets are implemented as objects is also very similar. 

   So please don't get caught up in the terminology - look at what my 
design does, and whether it's a good approach from the perspectives of 
performance, modularity, and easy coexistence with the rest of GTK.

Raph