Re: [patches] more tags for gzilla

[Raph Levien <raph acm org>]

On Mon, 19 May 1997, Otto Hammersmith wrote:

> Well, I spent some spare time this weekend writing some code for gzilla.
> I should've been doing other things, but hey, it's my weekend, right?
> 
> This mail should have six patches attached to it.
> 
> gzilla-0.02-hr.patch: Added support for the <hr> tag.
> gzilla-0.02-address.patch: Added <address> tag. (absolutely trivial)
> gzilla-0.02-dl.patch: Added support for description lists.
> gzilla-0.02-pre.patch: Added reasonable support for <pre> tags.
> gzilla-0.02-jumbo1.patch: Everything up to this point in a single patch to 0.02.
> 
> Note that the <pre> tag support is mostly done, except that tabs
> aren't handled properly.  There's a comment about it in the code... if
> anyone can tell me the best way to solve it, I'd really like to know.

My original idea was to put the entire line, spaces and all, into a 
single add_text. This would ensure that the line doesn't get broken. For 
tabs (which, to be honest, I hadn't thought about), I'd expand them into 
spaces before handing the line to add_text.

I didn't understand your comment about spaces causing the thing to crash. 
If an add_text with embedded spaces caused a crash, it's probably just a 
silly bug somewhere. Spaces aren't treated any differently.

> In any case, I noticed a few problems with gzilla while I was coding
> this stuff.
> 
> Resize doesn't work at all.  When the window is resized, the text
> remains the same size.  I presume you (Raph) already know that... just
> thought I'd mention it.

Yeah, I know about this. It used to be that the size_alloc routine (the
one which attached to the size_alloc signal of the scrolledwindow) would
cause a gtk_page_set_width. However, gtk didn't like check_resize () being
called in the middle of a size_alloc operation, and, to register its
disapproval, would sometimes make the scrollbar state inconsistent.  Thus,
the best approach seems to be to defer the gtk_page_set_width call to an
idle routine, so as to let the original size_all finish its work first. 

A case can be made that _all_ check_resize calls should be deferred 
until the idle cycle, for performance reasons, but I'll worry about that 
later.

> Well, actually I suppose that was the only real problem I saw. :) It's
> coming along quite nicely.. can't wait for the next code escape.

It will probably be a week or so. I've got a paper that really needs to 
get written this week.

> Thanks a bunch.

Thanks for the patches. I'm happy to accept contributions, especially as 
it means less coding for me. Particular needs include text/plain and 
image/jpeg bytesinks. Neither of these is particularly difficult, and it 
should be possible to get a good start by looking over the text/html nad 
image/gif bytesinks.

The other major usability need is a cache. This one is tricker and should 
really only be undertaken by someone who knows the Web protocols and 
asynchronous network programming intimately.

> 					-Otto.

Raph