Re: [Evolution-hackers] PATCH: gtkhtml-search.c fixes segfault in gtk_html_isearch

["Andrew S. Townley" <ast atownley org>]

On Thu, 2008-10-16 at 15:40 -0400, Matthew Barnes wrote:
> On Wed, 2008-10-15 at 15:22 +0100, Andrew S. Townley wrote:

> > I haven't looked through evolution's source in great detail, but I've
> > seen enough that you're using "magic" URIs to trigger
> > application-specific behavior as well.  Maybe this is just on the
> > viewing side instead of the editing side, but I don't see you'll be able
> > to get rid of GtkHTML until the link intercept support is part of the
> > GTK+ interface.
> 
> Probably true, and thanks for bringing that issue to my attention.

As far as I know, the groupware support for meeting requests and other
special messages relies on being able to intercept the object_requested
signal to put in the appropriate UI controls.  I think I also saw some
other places, but I'm pretty sure there's reasonable use of all of the
link_clicked, url_requested and object_requested signals.  Maybe it's
all localized to a single area.  Like I said, I haven't done a thorough
analysis.

For what I'm doing, that kind of interception is also a necessity, so I
hope that all of them eventually find their way into WebKit.  I'd be
happy to help you present your case to Alp or whomever is the right
person.  Unless there's another way to accomplish basically the same
thing (which I'd be happy to use), those kinds of hooks are extremely
useful when you're doing custom interfaces based on HTML.  Let's face
it, that's one of the main reasons GtkHTML was developed in the first
place, right?

> > I'm not considering starting it today, but I was just trying to get a
> > feel for if it was a 3 week, 3 month or 3 year type of effort.  Part of
> > my issue is that I'm on a pretty tight deadline to deliver the core
> > functionality in weeks rather than months, but I've been hitting walls
> > until I bit the bullet and went down the GtkHTML path (including
> > throwing together a very minimal ruby binding this morning which is how
> > I found the bug).  Unfortunately, it was either that or fix GtkHTML2's
> > busted selection model, implement text search, etc., etc.
> 
> CSS is a complex beast, and I know WebKit has put a great deal of effort
> into making its CSS support fully standards-compliant.  I really have no
> idea how much the effort it would take to get basic CSS support working
> in GtkHTML, but if you're serious about pursuing it I'd suggest forking
> the code and trying to get something working well enough to meet your
> own needs, which I assume is significantly less than full standards
> compliance.

Yes and no.  I've gotten things working quite a bit more in the last
couple of days, and I have to say that I think the way GtkHTML deals
with the formatting is... let's just say it's less than stellar.  Why on
earth would you generate something like this:

<h1>
<b><font size=6>Original Text</font></b>
</h1>

I have to say that my enthusiasm for the control waned a bit when I
started seeing stuff like that--along with changing all of the <p></p>
pairs into <br> tags.  Sheesh!

I know it isn't your fault, but after getting frustrated, digging into
the renderer code (what the hell is an HTMLClue, anyway???), getting
overwhelmed many times in a repeat until dead cycle, I'm sure that it's
more effort/pain than I need at the moment.  Maybe if I was bored for
about 6 months with nothing else to do...  I think it'd take 3 months
for me to figure out what it was really doing enough to come up with a
new plan, and then another 3 to rip it apart and do it again with CSS.
By that time, hopefully WebKit would have the support I needed
anyway--the effort would be better spent there, I think.

> I don't know if your design is modular enough for this to be feasible,
> but you might also consider starting a parallel implementation using
> WebKit and get as far with it as you can, with the intent of switching
> away from GtkHTML once the issues that are blocking you get fixed.  That
> way you don't wind up "stuck" with GtkHTML for the long term, especially
> after _we_ abandon it.

Modularity isn't the issue.  All of the GtkHTML stuff is fully
encapsulated into a single view class with the HTML rendering being
isolated into another class.  However, since what I'm doing right now
involves 0% rendering of HTML from anywhere other than traversing my
application's internal data structures, if I can't intercept the
navigation requests, I'm finished before I start.

Because of this, a parallel effort with WebKit just isn't a runner.  I
do appreciate the thought, however.  Maybe prayers to the WebKit gods to
add the missing functionality are my best bet! ;)

In the meantime, I've no real choice but to struggle on with what's
there at the moment.  As bad as it is, it still allows me to make
forward progress.  I can implement the functionality now and then make
it suitably sexy with proper CSS once WebKit supports what we both are
likely to need.

Thanks for all the info.

Cheers,

ast 
-- 
Andrew S. Townley <ast atownley org>
http://atownley.org