Re: [gtk-list] Re: [patches] more tags for gzilla

[Otto Hammersmith <otto redhat com>]

On Mon, May 19, 1997 at 02:51:03PM -0700, Raph Levien wrote:
> 
> On Mon, 19 May 1997, Otto Hammersmith wrote:
> 
> > 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.

That's what I did, at first.  But it doesn't work...

gtk_page_add_text(page, "\n\t\tSome text");

The newline and tabs just end up disappearing.

Fortunately, the way things are parsed the any newline or tab in the
string is at the front, so they're easy to intercept.  So, when (I
forget which function) a newline is found, the function calls
gtk_page_linebreak()... the tricky part is the tabs.
 
> 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.

When a tab is found, I tried using gtk_page_add_text(page, "       ")
but that caused seg faults on exit and when links were activated.

Multiple gtk_page_add_space()'s don't work either... only one space
ends up in the output.

I haven't really looked at the problem, since it wasn't that
important.  I presume it's some problem with a counter somewhere not
being updated as it should be... 

> > 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. 

Does this mean gtk_page_set_width can be used to expand the page after
it's first drawn?  I'll give it a try... there are some HTML I'd like
to use gzilla for (HTML source with Global) that's just a tad too big
for the default width.

> 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.

Another nice thing would be to only call a redraw when the updates are
to text/graphics in the visable window... i.e., on a big page, there's
a lot of flicker due to data loading way down at the end of the page
off the viewable window.  Not sure how easy it would be to figure out
whether something is visable.

> > 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.

I should have some comments and ideas about the whole bytesink thing,
as soon as I can look at the code for a bit uninterrupted and see how
they fit in with my ideas for the filemanager.

> 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.

I've had some ideas on this, somewhat related to my thoughts on the
bytesink-similar constructs.... more to come.

I don't suppose you'd like to run the code through indent before the
next release?  I did it to a couple files to make it easier to read,
but futzed things around to make the patches minimal.

-- 
					-Otto.