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 <[EMAIL PROTECTED]> http://atownley.org _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
