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

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

Matthew,

Thanks for the response and the info.

On Wed, 2008-10-15 at 08:25 -0400, Matthew Barnes wrote:
> On Wed, 2008-10-15 at 12:03 +0100, Andrew S. Townley wrote: 
> > I was trying to figure out how searching worked with GtkHTML, and I
> > discovered the following minor bug.  Calling gtk_html_isearch() assumed
> > that the editor component had already been set.  If it wasn't, you got a
> > segfault.
> 
> Thanks for the patch, Andrew.  I'll get that committed.  You might keep
> an eye out for similar cases in other parts of the code.

I'm not looking, but I'll shout if I find more. ;)

> > Now, I haven't actually found anywhere that the editor API *is* set, so
> > pointers to an example would also be appreciated. :)
> 
> The editor API is set by users of the GtkHTML object to customize its
> behavior.  The stock editor that ships with GtkHTML has an example.
> Look in:
> 
>    gtkhtml/components/editor/gtkhtml-editor.c:editor_init()

Right.  I get it now.  I wasn't grepping through the entire tree, just
in the gtkhtml directory.  This might also be handy for parts of my
application.

>From looking at the examples, am I right in thinking that
gtkhtml/components/editor is essentially a "plain", embeddable GTK+
widget, and the html-editor is a bonobo component, requiring all the
CORBA plumbing?  If so, I think I'll lean toward the former rather than
the latter for what I'm doing if I use it for editing support.

> To partially answer your previous mail, we _do_ hope to eventually
> migrate to WebKit within the next year, since GtkHTML is effectively
> unmaintained these days.  I've worked on the editor component and
> dabbled at some pieces of the core HTML renderer, but most of the core
> developers with a deep understanding of the renderer have long since
> moved on.  And with a large PIM application to maintain with our limited
> manpower, you can imagine why we're looking to get out of the HTML
> rendering business.

Yeah.  I sure can--especially with no specs and no docs but the code.
Believe me, I'm not trying to get into the HTML rendering business, but
I just need more control over the link traversal than I can currently
get from any of the "real" browser implementations (WebKit or embedding
Mozilla).

> I don't think anyone on the team has begun looking in detail at the
> technical issues involved in migrating to WebKit yet, particularly with
> respect to HTML editing (to my knowledge, we're still waiting on
> WebKit's GObject-based editing API).  So I don't have an answer to your
> "link_clicked" question yet except to say that Alp Toker seems pretty
> receptive to our editing needs and I expect to be able to negotiate a
> solution with him when the time comes (if it's still an issue by then).

For my project, "rich" editing with HTML is an added bonus, but it isn't
one of my high-priority requirements.  For this part of the project, all
I need is a way to render simple, no-frills, XHTML directly in response
to user link traversal events.  I'm sure WebKit will give you a lot on
the editing side from what I've been reading.

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.

This is the link for the Android approach:
http://developerlife.com/tutorials/?p=369

> As for adding CSS support, I believe it was indeed roughed in but
> unfinished by the former GtkHTML developers.  For Evolution it simply
> hasn't been a priority.  Contributions are always welcome, but with
> GtkHTML's days numbered (as far as the Evolution team is concerned), I
> would caution you to consider whether starting such a large project is
> worth the effort.

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.

Since this is new code, I'm a bit hesitant to start cluttering the
generated HTML with in-line styles, but I've a couple of ideas of some
stop-gap measures that might be a reasonable compromise.  Depending on
how things go and when the support for link interception appears in
either WebKit/GTK+ or embedded Mozilla, I might get frustrated enough to
crack it open and have a bit of a tinker.  Writing GTK+ code in C is
something I haven't done for about 7 years, and even then, I didn't do
very much of it.  So, let's just say that I'm not exactly "chomping at
the bit" to go down that path if I can avoid it. ;)

Thanks again for the response.

Cheers,

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