Re: [MiNT] Announce of an early netsurf framebuffer alpha / polipo proxy rpm

[Peter Slegg <p.slegg@scubadivers.co.uk>]

On Wed, 4 Aug 2010 23:17:14 , "m0n0" <ole@monochrom.net> wrote:
>
> As you maybe know, there are several ports of NetSurf. All of these ports
> have a different GUI and not every port has the same features.
>
> These features ( like printing, bookmarking, caching to disk, persistent
> cookies, reading options, etc.) are supported by an common code base
> accessible to all of the ports. All the ports share the same layout
> engine, but they don't share gui / drawing code. Changes to the layout
> engine and changes in networking code or changes in parsing, css or
> language support are shared by all of the ports. But not every ports
> implements all of the features available.
>
> The implementation of GUI code and "usage" of new browser engine code is
> up to the specific port.
> I think the hardest part will be the implementation of the website form
> controls like checkboxes, textboxes, lists (including their event
> handling).
> Maybe it's better to have an look how the windows/GTK versions implemented
> such stuff, in the framebuffer version all of these controls are implented
> as OS independet widgets...
>
> Example:
> If there are GUI changes in the GTK version (like an button to print the
> webpage), this changes will not carried across other versions, but the
> method "print_page" (ok, that's to simple) is probably available to every
> port.
>
> About the webpage Form elements:
> Maybe the dynamic forms engine ( an addition to winDom ) is good for this
> purpose, but that is just a guess. Another approach would be an resource
> tree that contains all the needed Web Form elements. Then, no matter from
> where the Form element definition came, draw it with objc_draw...
> Another approach would be to look how highwire has done that stuff :)
>
> Hope that has answered your questions.
>
> Greets,
> m0n0
>

So it is a layered approach, using the core code like a library.

Thanks,

Peter