Hi there! Here come the latest news about the FLTK port feasibility analysis. There're lots of issues, but only a few major ones, so trying to be brief: "The main point of joy in dillo is its extraordinary speed." If porting to GTK2 leads to a much slower browser (as for instance like what Eric's tests showed), and with much bigger memory consumption (twice or more as Owen considered plausible), it certainly becomes a big concern. If the difference between using a BIG browser and dillo narrows to the point of making it better to wait for the BIG one and have all the features, dillo becomes irrelevant. (This is a compose statement because it adds the fact that BIG browsers have more features, which is a thing you currently trade-off for the joy of the speed in dillo). At this point, having an FLTK-based dillo starts to be a very interesting option (especially after considering Owen's remarks, the pango issues, and the new expose model in GTK2 which adds a redesign stage for our progressive rendering). Why did we want to go to GTK2? Mainly because of UTF-8 support. Now, I'll quote some very good news from FLTK's maintainer, Michael Sweet: <q> Jorge, I haven't made the official announcement yet, but we've decided to do a 1.2.x version of FLTK that incorporates many of the FLTK 2.0 things using a FLTK 1.x compatible API. Some things of note: - UTF-8 support - Display/print device support (same code that draws to the screen can print to a printer) - 32-bit coordinates - Basic style/scheme/theme API - New menu, browser, table, spinbox, etc. widgets - Better OSX integration using Quartz instead of QuickDraw - Better RGBA image display using Xrender on X11, AlphaBlend on WIN32, and Quartz on OSX when available. The developers of the FLTK UTF-8 and Fl_Device patches will be joining the project, and we have already completed the initial merge to start things off. We'll probably have beta snapshots available before Christmas, with a "gold" release in early 2004. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com </q> So we'd have: UTF-8, 32-bit coordinates, printer!, themes, antialiasing, etc, and with a much leaner engine. Another strong point is that with the new table widget, and the FLTK layout mechanism, much of the complexity in rendering/resize/event-handling/etc can be sent to FLTK instead of having to directly code it in our widgets. <q author="Michael Sweet"> The current FLTK layout mechanism is infinitely flexible, but takes a little getting used to since there are no layout "hints", just resizeable widgets inside groups. In short, you group widgets (and sometimes create empty "box" widgets) to get the layout behavior you want. This is actually a lot faster than the older Motif-style layout stuff that GTK+ uses... There are specialized group widgets (Fl_Pack, Fl_Tile, etc.) that provide for special positioning/resizing capabilities separate from the user resizing the window. </q> Finally, from what I've seen, images can also be "handed" over to FLTK. Avoiding having to decode them into RGB, and manage them inside dillo (png.c, gif.c, jpeg.c, dicache.c, image.c, dw_image.c, ...). This native FLTK images also provide an alpha channel so background images should be easy to implement too. I've been playing with fltk-1.1.4 for a while. It comes with a manual and lots of examples. ftp://ftp.easysw.com/pub/fltk/1.1.4/fltk-1.1.4-source.tar.bz2 (1.3 MB) Just: ./configure --enable-xft make cd test; ./help to have an idea of HTML rendering with antialiased fonts. then: ./demo to get a feel of the widget set. An interesting exercise. Cheers Jorge.- PS: Sebastian: I'm especially interested in your opinion and concerns about this. We have a very interesting opportunity, and we can ask Michael or Bill Spitzak. PS2: dillo-0.8.0 will be GTK1. (probably with kbnav, frames and tabs). (maybe https as explained in a former email)