Re: anyone here yet?

[Raph Levien <raph acm org>]

On Thu, 1 May 1997, Otto Hammersmith wrote:

> Hello all,
> 
> Just wondering if there's anyone listening, yet. :)
> 
> If there are people out there, what is everyone doing with GTK?  I've
> seen some interesting projects, but want to get a handle on what
> people are trying to do... don't want to duplicate any effort, now do
> we? :)

Well, now that you ask, I'll fess up. I've just started working on 
gzilla. The name is a joke, really, because I have no intention of 
building a web browser empire. It's going to be a quick, dirty, fast toy 
Web browser. However, because it's built on top of GTK, it's going to be 
extremely cool.

My goal is to put together a reasonable HTML viewer, JPG and GIF image
viewers, and a minimalist HTTP layer. The one "fancy" goal is for it to be
completely streaming. As such, it ought to be a reasonable choice for the
help viewer in Gimp. If other people want to develop it further than that,
I'd welcome it, but I don't have the time or energy to devote to releasing
and maintaining (yet another) major piece of software. 

The architecture is roughly as follows:

                      Wedget
                     /      \
                  Html    WebImage
                           /     \
                         GIF    JPEG

A "Wedget" is a Web widget. It's just like an ordinary widget except for 
one call and a bunch of singals. The new call is more_bytes, which the 
application uses to push in bytes that come from the network (otherwise, 
it's pretty similar in concept to gtk_label_set). The signals will 
include things like link (emitted when a link is clicked), request_url 
(emitted whenever an IMG tag is parsed), and maybe a few more. I haven't 
designed this part thoroughly, so I'll make it up as I go along.

The Html wedget will be a pretty basic HTML displayer, with one cool 
trick: it also act as a container for other widgets or wedgets. This is 
how images will happen. It's also the obvious extension mechanism for 
forms, tables, applets, and such. I'll support the GTK size negotiation 
mechanism so it won't have to hold up page display if the hoser who wrote 
the page forgot the WIDTH and HEIGHT parameters in an IMG tag.

The parsing, streaming, and layout will be handled by the simplest 
possible mechanism. Html's more_bytes method will tokenize the input and 
dispatch on the tag. It will also maintain a stack containing (tag, 
attributes) tuples. For example, parsing <B> will just push B onto the 
tag stack, push the attribute stack, and set the BOLD bit in the 
attributes. Parsing </B> will just pop the stack down one. The text gets 
shoved into an array of lines, each of which is an array of words. Each 
word contains a string (the text of the word) and an index to the table 
of attributes. Word wrapping happens incrementally as the text comes in, 
but if the size changes (e.g. a window resize), the text gets rewrapped. 
There is a bit of extra information in the line and word structures to 
help with this. For example, each line contains a bit stating whether the 
line ends with a hard or a soft break, and each word contains the metrics 
of the word, to speed up both rewrap and display.

I'll keep you guys posted.

Raph

--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null