I have been looking at stopping the Amiga front end from #including
desktop/browser_private.h, like I did for the Windows front end earlier
The big problem with the Amiga code at the moment is that the tabs
implementation seems to depend on being able to dereference struct
browser_window (bw), to get to the struct gui_window (gw).
So, for example, to set the Amiga front end's scroll offset for the
window, it starts with a struct gui_window_2 (gw2), which I assume is the
main window containing all the tabs, then it goes to the bw (representing
current tab?), then the gw:
The gui management of tabs should not depend on core data structures.
I suggest that the gw2 be changed to have a pointer to a gw representing
the current tab, and add a pointer to bw entry in the gw. So to get the
scroll_y it would be:
And to use the core browser_window_* functions, you'd be passing the bw
Does that seem doable Chris?
Michael Drake (tlsa) http://www.netsurf-browser.org/
It seems like netsurf is a great candidate for providing HTML based UI in apps. Is this something anyone has tried from a technical point of view?
Does the current licensing support this for paid for apps or is netsurf licensable for such purposes?
This is not strictly NetSurf related but I wanted to make a note of it
here in case it is useful for development/testing/debugging of NetSurf
Thee are some easy steps here on how to set up OS4.1 Classic on the
new beta of WinUAE:
It needs a (legal) image of the OS4.1 Classic CD and a (legal) 3.1 ROM
image (I think the OS4.1 CD has one of these on it these days).
I've not tried it myself as (a) my PC is currently broken and (b) I
don't have the "classic" version of OS4.1.
We have made some significant cleanups and feature improvements to the
master branch since the 3.1 release including a significant number of
fixes for crash causing problems.
As there are currently no large feature merges outstanding and Daniel
and myself triaged and fixed numerous bugs recently this seems like a
suitable time to create a 3.2 release.
As this is principally a bug fix release and the only user visible
change is the persistent object cache I see no reason for an extended
test period. I will be making the release by the end of the month,
probably Saturday 23rd.
The 3.2 roadmap on the issue tracker  only shows two issues tagged
for this release one of which I intend to address immediately, the
other may get ignored if nobody addresses it.
I would like to raise the issue that the RISC OS frontend has received
minimal bug fixing this release cycle as Steve Fryatt has been unable
to dedicate much time recently. There are over twenty RISC OS specific
issues outstanding and I would be delighted if someone could provide
fixes for any of these.