To sort things out, this time a little more detailed :).
What I would like to do is to split the functionality the browser
currently into two parts - the browser window's and the frame's( drawing
A strict separation will let us have one browser_window structure
doing only what it was probably meant to do - representing a BW with a
page rendered inside. The changes should be indifferent for tabs, so I
didn't take them into consideration in order not to complicate the
I think it would be useful to explain what I will understand as a
frame. It would be a structure able to get any of the types
browser_window_type allows for the time being, so it could be a page
with no frames at all( BROWSER_WINDOW_NORMAL ).
At this moment the front-end code contains numerous ifs and cases for
the browser_window_type. This needs removing and the front-end should
communicate only with the browser_window interface, so that it
wouldn't be aware of the existance of frames. The browser structure
would hold only the data common for all frames on the page, which
- history, scale, gui_window, throbbing, caret_p and caret callback pointers
- drag_type and the other drag related variables as there can be only
one drag at a time.
- active_frame, indicating which frame has currently focus. It would
be updated on clicks (could also be keyboard nav, auto focus after
targeted page load etc. ). It would be used for sending events like
select all or deselect affecting only the frame with focus
- main_frame, pointing to the root frame of the page, which can
represent either a frameset or a single page
The remaining variables would be shifted to the frame struct. A few
additions would be:
- browser_window, pointing to the BW containing the particular frame
- scroll_h, scroll_v pointing to the optional scroll widgets
- the x,y position inside the parent frame (or the master one, it
depends on how the functions will exactly work)
I would like to use the current API of the BW in order not to get into
rewriting half of NS from scratch ;). The actual implementation would
be mostly shifted to the frames API. The BW functions would be used to
call their frame equivalents. Lets get an example:
1. A mouse button gets clicked over a frame
2. The front end calls browser_window_mouse_click
3. browser_window_mouse_click walks recursively through the frames
until it determines the clicked one
4. browser_window_mouse_click sets the frame as active_frame and calls
5. [this one is platform dependent]The user chooses 'Select All' in
the menu bar, the selection for the proper frame is obtained through
the the BW and selection_select_all gets called with it.
A frame redraw would be handled like a regular one with the difference
that the frame offsets in the BW would have to be taken into account.
Also, as a BW would be bound up with several contents a way of passing
the one to be redrawn would have to be added.
2009/3/25 Michael Drake <tlsa(a)netsurf-browser.org>:
In article <1237982760.18642.28.camel@duiker>,
John-Mark Bell <jmb(a)netsurf-browser.org> wrote:
> On Wed, 2009-03-25 at 07:49 +0100, Chris Young wrote:
> > On Wed, 25 Mar 2009 00:38:26 +0000, John-Mark Bell wrote:
> > > [frames proposal]
> > > The frontend will still need to provide certain UI widgets (e.g.
> > > scrollbars) but that isn't likely to be a problem on all sane UI
> > > toolkits.
> > Wouldn't it make more sense to draw the scrollbars as part of the
> > area? Like the textarea scrollbars etc?
> The problem with those being that they look awful and don't fit in with
> any platform's UI. They're also pretty temperamental in use, ime.
I think I'd have it so that the core can draw its own scrollbars, if the
front end does not tell the core that it wants to plot native scrollbars.
That way the scrollbars can match native desktop furniture if the front
end has implemented that functionality, but everything will still work if
the front end hasn't got that yet.
Also the framebuffer front end could just use the core scrollbars.
So this would need an (preprocessor?)option, indicating whether
scrollbars should be obtained from the front-end or from core, and the
optional function itself (together with one used for changing the
scrolls). The frames on the other hand would need to provide callbacks
for updating them on scroll. Once this is on place we can use the
scrollbars for whatever we want - frames or boxes with overflow.
I'll base a significant part of my proposal's timeline on my
estimations of how long the above would take so if there are some
nasty complications of which I haven't thought or some nonsense please
let me know :).