On Thu, 4 Mar 2004, Matt wrote:

Hi Jorge,

Hi Matt!

I just visited your dillo web pages (by a hint from the FLTK mailing list) and I have to say, you guys got something great going there!

Thanks. It's great you liked it because we could make it even better by porting to FLTK!

I saw mentioned that you are checking the feasibility of using FLTK (replacing or adding to gtk?).

The idea is to replace GTK+. (In a nutshell, GTK2 got too big and slow to suit our needs). You can find interesting threads in our mailing list about the FLTK port issue. For instance, go to: http://www.dillo.org/search-dillo-dev.html And search for "FLTK" by "jcid" sorted by "Relevance". This will not only bring my posts but also the ones from Michael Sweet that I forwarded to dillo-dev.

FLTK on the other side is lacking a good browser, or even just a browser interface. So I believe that dillo/FLTK would be a great combination.

Yes. The only thing that scared me a bit about FLTK's help viewer is that it is too slow, even for very simple pages. For instance vertical scrolling is much slower than what we get with GTK1 by now. Considering FLTK's reputation for speed, and after looking at the demo programs (as "scroll"), I feel it should be possible to improve page scrolling speed.

Anyway, I am one of the FLTK core developers and cross platform porter, and I would like to offer you my support in connecting FLTK and dillo.

Excellent! Do you plan to work as an advisor, a porting core-developer or the port's leader? :) After reading Sebastian's comments, there seems to be no major obstacle to start the porting effort. What we'd need is to coordinate the communication of specific knowledge: Sebastian and Dw, me and network2parser and parser2widgets, you and FLTK.

Pleas let me know what you think,

I think it's great to have one of the core developers of FLTK in the porting team! Technically, I see two ways of making the port: (I'll concentrate on the HTML rendering part because the UI port should be pretty easy in comparison). Rendering port alternatives: 1) Port Dw to FLTK 2) Make a pure FLTK widget tree (convert Dw into FLTK analogs) Maybe the first is easier in the short term, but I'd much prefer the second one because: * Having a custom widget system (Dw) that's embedded into FLTK and that also embedds native FLTK widgets is a very complex scenery that requires too much knowledge to work with (BTW that's what we currently have with Dw/GTK+). * If we can push the positioning/resizing/rendering complexity into FLTK's internal mechanism, it would simplify a lot the task (less complex algorithms, less code, less intertoolkit sync) * If we end we a pure FLTK tree (with its parser), it could be easily reused by the FLTK community, and this also leads to easier maintenance because more developers would be deploying it and helping to improve and fix bugs. One of the main points of Dillo's speed is streamed rendering. That is the ability to show the page as it is being constucted. I assume this is possible with FLTK. The way this works is by letting the parser to build the widget tree as it gets the HTML building blocks. By far, the most complex part is table rendering (because you don't know the table size in advance (i.e. each cell size). This means that cells start to resize and affect their rows and hence the table itself. OTOH, I have hopes in FLTK's internal mechanism. Fl_Group manual says: "It is possible to achieve any type of resize behavior by using an invisible Fl_Box as the resizable and/or by using a hierarchy of child Fl_Group's." and Michael S. wrote: <q> 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> So, the way I'd start is by trying to make a FLTK widget (set) that's able to draw generic HTML tables whose content is initially limited to be text only. This means, having HTML test files, a simple parser and the widget tree construction logic. When this is ready, images are added (images are a very good example of resizing cells). After that, a generic HTML content widget should be defined, and it would be a matter of adding support for the missing HTML elements (a much simpler task). In parallel with this last stage, Dillo's UI could be ported and finally merge both to have the first FLTK prototype of Dillo! Looking forward to hear from you Jorge.- PS: Feel free to forward this to the FLTK mailing list.