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

[Josh MacDonald <jmacd CS Berkeley EDU>]

As I've said in the past, text formatting like this isn't easy.
Handling tabs is not a trivial matter, and was why I suggested
people try and share code with the text widget.  

You want tabs to work when you see:

	this text follows a tab.
blah	so does this, and it's aligned with the above despite the
	word "blah" preceding the tab.

I worked on the text widget few days ago and discovered why everyone 
had come to the conclusion that it totally didn't work.  The last 
version I gave Pete, as I said, worked (with a few things I knew
didn't work, but at least it didn't core dump).  Pete saw fit to
make a quick change without testing it between my last version 
which totally broke things.  I'll mail a version out sometime in 
the next few weeks that works.  In the interest of form over function,
the modifications I recently made were to disable all editing (because
Pete broke it) and make it support background pixmaps which scroll 
with the text (this is, of course, far more important than editing,
right?).

People working on a HTML browser without consulting the text widget
are throwing away nearly 3500 lines devoted to text formatting, 
drawing, and exposure.  It'll probably grow another 1500 by the
time I finish h-scrolling and selection.  It's well laid out.  I figure
it wouldn't be very difficult even, to allow images or child widgets
to be inserted in the text.  The only hard part about an HTML widget
from my perspective, using the text widget as a base, is handling
aligned images (a more general description would be, handling "flows"
in the FrameMaker sense). The text widget assumes there are lines of
text, where each element is a member of some font with known 
dimensions.  Using this abstraction, you can make embedded widgets
a special case--a unique element in a unique font with the correct
dimensions.  The problem is that HTML doesn't always work this way,
because you have images aside a column of text (or, more generally,
two columns of text or any other "flow").  I haven't come up
with the solution to this little complication, but I suspect there
is one--I haven't thought about it much (because its not required
by the text widget..  its required for a word processor or web browser).

Throwing away all that code is not, in my opinion, very wise.  Not
only is there a lot to do with simply drawing the text, there's a
lot more to do with efficiently caching the results of the computation
and being able to do reexposures and scrolling quickly.

>From the looks of it, you're charging in without thinking too much
about the design.  Doing so, you're likely to miss much more than
tabs.  I'm not trying to insult you guys, I'm just urging you to 
consider rethinking your approach before you get too commited.

Design is critical.  I assure you there's a 10x difference in the
complexity and line-count between a poorly and well-written web
browser.  Don't start with the assumption that since the goal is
to end up with something small you should use a small or incomplete
design (what would Brooks say about how much time to spend designing?).

-josh

> 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.
> 
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
>