5:29 p.m.
Hello
As I would like to propose for the Core UI idea together with the frames stuff
I would like to discuss the best approach to handling frames. This is just
a starting draft and absolutely no details are described because I may not fully
understand the frames logic so the first thing I need to know is if that's the
right way to follow in order to develop it further.
Having this said - please read and comment, any feedback will be appreciated :).
For those whom I haven't bugged on #netsurf yet and who might prefer to discuss
there :) - my IRC nick is PaulB_.
The problem (thanks to kyllikki)
Currently the frames are treated as seperate windows in the OS. This forces the
core to take some assumptions on their behaviour which obviously can't be
the same across all platforms. For this reason only the RISC OS front-end
supports frames at the moment. This approach is not only unportable but also
overcomplicated.
The solution
What I would like to do is to split the functionallity the browser window has
currently into two parts - the browser window's and the frame's( drawing
area's)
one.
The browser window would be responsible for everything which wouldn't be done
by the OS any more. This includes keeping track of which frame has
focus, sending
the events to the appropriate one, opening pages in the corret target etc.
The frames would have to handle scrolling logic( together with requesting
for the scroll bars), redrawing, dealing with mouse clicks and other events.
Also, it would be the frame then which would have to deal with the content.
In the matter of how the frame would be used to draw on a part of a screen I see
two basic approaches:
1. The whole page could be plotted into a single drawable surface( like it is
done at present when there are no frames), so basically it means keeping the
gui_window in the browser_window structure. A frame with its coordinates and
dimensions would represent a rectangle on that page thus making a frame-plot
a regular plot with the frame offsets added.
2. A frame would keep a reference to front-end specific data representing
the page rectangle. A set of gadgets would be nested in the window so that
they wouldn't need separate windows. This would let the scrolls and resizing be
done without additional coding. However, I am not sure if this would be possible
on every platform( I'm probably thinking too much GTK-like), actually I am not
even sure if it could be easily applied at GTK. It would probably just move the
front-end-specifics problem to another area so that's why I have abandoned this
approach and chosen the first one, leaving it here just for order.
Once this part is clarified there are other issues which probably will need
addressing, due to the code changes the new implementation of frames would
entail like the history handling as an example.
1:38 a.m.
On Sun, 2009-03-22 at 17:29 +0100, Paweł Blokus wrote:
[frames proposal]
We discussed this on IRC. Essentially, Paweł's approach seems fine and
should significantly simplify the implementation of frontends.
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.
The core will manage the various drawing areas and so on.
J.
7:49 a.m.
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?
Chris
1:06 p.m.
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.
J.
1:46 p.m.
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.
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
2:06 p.m.
On Wed, 2009-03-25 at 12:46 +0000, Michael Drake wrote:
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.
Sure. That's simple enough to do.
J.
11:09 p.m.
To sort things out, this time a little more detailed :).
What I would like to do is to split the functionality the browser
window has
currently into two parts - the browser window's and the frame's( drawing
area's)
one.
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
further description.
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
means:
- 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
frame_mouse_click
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 :).
11:23 p.m.
To sort things out, this time a little more detailed :).
>What I would like to do is to split the functionality the browser
> window has
>currently into two parts - the browser window's and the frame's(
> drawing area's)
>one.
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
further description.
Sorry I don't really have much time to follow the discussion though I'd
need to avoid making it harder to implement it in BeOS...
currently frames are just broken here.
Just to make it quick, currently the BView (the canvas class)-derived
object used to represent a frame or whole page is inserted as child of
a BScrollView, which itself manages the scrollbars.
I'd like to keep it that way for frames too if possible.
Making all frames handle themselves and draw on a single canvas would
forbid this, and mean one would need to handle positionning and
maintaining the BScrollbar objects directly.
I did this for the XEmacs port as it was designed this way, but it's
still buggy and causes many issues, like event loops (scrollbar moving
setting itself back, so moving again, so setting itself back again...).
Now, I'm not sure the BScrollView scheme will work when we implement
proper scaling, which I didn't look much at. BView itself can be given
a float scale value which scales all drawing, but I'm not sure how to
map it to NS yet.
François.
8:06 a.m.
On Wed, 25 Mar 2009 23:23:35 +0100 CET, François Revol wrote:
Making all frames handle themselves and draw on a single canvas would
forbid this, and mean one would need to handle positionning and
maintaining the BScrollbar objects directly.
That's why I said it would be better for the core to draw the frame
scrollbars.
Adding/removing OS scrollbars when switching pages or tabs sounds like
it could potentially cause problems.
I think this will solve your problems as well, as you won't need to do
anything additional for frames to work.
Chris
10:20 a.m.
On Wed, 25 Mar 2009 23:23:35 +0100 CET, François Revol wrote:
> Making all frames handle themselves and draw on a single canvas
> would
> forbid this, and mean one would need to handle positionning and
> maintaining the BScrollbar objects directly.
That's why I said it would be better for the core to draw the frame
scrollbars.
Ugh, this doesn't feel native at all :('
Adding/removing OS scrollbars when switching pages or tabs sounds
like
it could potentially cause problems.
I think this will solve your problems as well, as you won't need to
do
anything additional for frames to work.
Not so sure...
François.
7:43 p.m.
On Wed, 2009-03-25 at 23:09 +0100, Paweł Blokus wrote:
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.
I think it would make more sense to have a 1:1 mapping between contents
and frame objects. Then, perhaps, have the content handler in the frame
object bubble the redraw request up the frames tree where it finally
arrives in the browser_window, which then propagates the request up to
the frontend.
[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 think the simplest solution is to define an interface which provides
all the API we'll need. A partial list might be:
+ create
This wants to pass in the x,y coordinates of the top-left of the
scrollbar widget, relative to the top-left of the parent canvas.
It also wants a flag to state the orientation. It should also be
passed a function pointer and private word for the scroll event
handler.
+ destroy
Obvious.
+ get_scrollbar_width
+ get_scrollbar_height
These two are so the layout code can cater for the spacing required
by the scrollbar widget. They return the widget's dimensions in px.
+ set_extents
Informs scrollbar of the width/height of the canvas and the
width/height of the visible area.
+ get_scroll_offset
Retrieve the current scroll offset [0, width].
+ request_scroll_to
Request a scroll to the specified position. Widget does whatever is
necessary and then calls the scroll event handler to perform the
scroll.
[Note: the above API means that only one thing (the widget) is in
control of scrolling. Everything else must delegate to it.]
Obviously, when navigating between pages, scrollbar widgets should be
removed/added as appropriate by the core. Thus, the frame object should
probably store the current offsets etc so it can recreate the widget if
the user navigates back to the page.
One remaining problem is ensuring that the correct widgets are visible
or not. (Consider an iframe inside a frame, with the containing frame
scrolled so that the iframe is not visible. The iframe's scrollbar
should not be visible, either). This also suggests there might be
interesting clipping issues to resolve.
J.
7:01 p.m.
On Thu, 26 Mar 2009 18:43:02 +0000, John-Mark Bell wrote:
Obviously, when navigating between pages, scrollbar widgets should
be
removed/added as appropriate by the core. Thus, the frame object should
probably store the current offsets etc so it can recreate the widget if
the user navigates back to the page.
The tabs system also needs improving as at the moment there is no way
of telling the core when you are switching tabs, so it can
destroy/create scrollbars as appropriate - unless the platform code
can keep track of which scrollbars are on which page?
Chris
8:06 p.m.
On Thu, 2009-03-26 at 19:01 +0100, Chris Young wrote:
On Thu, 26 Mar 2009 18:43:02 +0000, John-Mark Bell wrote:
> Obviously, when navigating between pages, scrollbar widgets should be
> removed/added as appropriate by the core. Thus, the frame object should
> probably store the current offsets etc so it can recreate the widget if
> the user navigates back to the page.
The tabs system also needs improving as at the moment there is no way
of telling the core when you are switching tabs, so it can
destroy/create scrollbars as appropriate - unless the platform code
can keep track of which scrollbars are on which page?
Given the point is to make things simpler for the frontends, I'm not
entirely sure what the best solution is here. It would be useful to have
input from the other frontend implementors. TBH, it's a very long time
since I went near the core/frontend interface in anger. So, regardless
of what I think, other people are significantly better placed to design
this API.
J.
11:05 a.m.
On Thu, 2009-03-26 at 19:06 +0000, John-Mark Bell wrote:
On Thu, 2009-03-26 at 19:01 +0100, Chris Young wrote:
> On Thu, 26 Mar 2009 18:43:02 +0000, John-Mark Bell wrote:
>
> > Obviously, when navigating between pages, scrollbar widgets should be
> > removed/added as appropriate by the core. Thus, the frame object should
> > probably store the current offsets etc so it can recreate the widget if
> > the user navigates back to the page.
>
> The tabs system also needs improving as at the moment there is no way
> of telling the core when you are switching tabs, so it can
> destroy/create scrollbars as appropriate - unless the platform code
> can keep track of which scrollbars are on which page?
Given the point is to make things simpler for the frontends, I'm not
entirely sure what the best solution is here. It would be useful to have
input from the other frontend implementors. TBH, it's a very long time
since I went near the core/frontend interface in anger. So, regardless
of what I think, other people are significantly better placed to design
this API.
I'd suggest that if frontends need to care about removing/adding native
widgets then they should keep track. GTK and RISC OS will just parent
the widgets to the window/widget containing the render area for the
browser_window and then not care any more.
If that's not how the BeOS or Amiga frontends can do it then they should
disconnect the actual physical native widget from the representation
they use for the core, and then handle
creating/destroying/hiding/showing them as needed.
I think that the framebuffer widget system supports non-visible or
partially obscured widgets, so I imagine it'll cope reasonably.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895
2:42 p.m.
On Fri, 2009-03-27 at 10:05 +0000, Daniel Silverstone wrote:
I'd suggest that if frontends need to care about removing/adding
native
widgets then they should keep track. GTK and RISC OS will just parent
the widgets to the window/widget containing the render area for the
browser_window and then not care any more.
I'm not quite sure how that works, tbh.
Consider http://users.ecs.soton.ac.uk/jmb/test/frames/frameset.html
How do we ensure that the scrollbars on the objects in the iframe in the
bottom left frame are clipped to the iframe?
I concur about scrollbars for non-frame widgets, btw :)
J.
2:53 p.m.
On Fri, 2009-03-27 at 13:42 +0000, John-Mark Bell wrote:
> I'd suggest that if frontends need to care about
removing/adding native
> widgets then they should keep track. GTK and RISC OS will just parent
> the widgets to the window/widget containing the render area for the
> browser_window and then not care any more.
I'm not quite sure how that works, tbh.
Consider http://users.ecs.soton.ac.uk/jmb/test/frames/frameset.html
How do we ensure that the scrollbars on the objects in the iframe in the
bottom left frame are clipped to the iframe?
I kinda expected there to be a gui render area per frame/iframe anyway,
since they're the independently scrollable renderable bits. Not sure if
I expected that for the overflow areas too or not. Perhaps. As I said,
I'd not given it a huge amount of thought yet :-)
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895
3:08 p.m.
On Fri, 2009-03-27 at 13:53 +0000, Daniel Silverstone wrote:
On Fri, 2009-03-27 at 13:42 +0000, John-Mark Bell wrote:
> > I'd suggest that if frontends need to care about removing/adding native
> > widgets then they should keep track. GTK and RISC OS will just parent
> > the widgets to the window/widget containing the render area for the
> > browser_window and then not care any more.
> I'm not quite sure how that works, tbh.
> Consider http://users.ecs.soton.ac.uk/jmb/test/frames/frameset.html
> How do we ensure that the scrollbars on the objects in the iframe in the
> bottom left frame are clipped to the iframe?
I kinda expected there to be a gui render area per frame/iframe anyway,
since they're the independently scrollable renderable bits.
Which is what we currently have. And which is broken on everything that
isn't RISC OS.
Perhaps I'm missing something?
J.
3:37 p.m.
On Fri, 2009-03-27 at 14:08 +0000, John-Mark Bell wrote:
> I kinda expected there to be a gui render area per frame/iframe
anyway,
> since they're the independently scrollable renderable bits.
Which is what we currently have. And which is broken on everything that
isn't RISC OS.
Perhaps I'm missing something?
What we have currently is "browser window" -> "gui window" as the
core
concept.
Then we have "some browser windows are in fact frames" which means they
don't get all the same stuff as before.
And then we have "and some UIs make some browser windows into tabs"
which confuses things even further.
I'd suggest that what we need is a model more along the lines of:
A core concept/struct called 'browser' which encompasses everything
which makes up the browser as far as the core is concerned -- fetchers,
caches, options, etc.
A core concept/struct called 'browser_widget' which encompasses
everything that was originally a browser_window -- I.E. a history path,
display specific settings like scale, a "currently visited url" etc.
A core concept/struct called 'document' which represents the content
object and associated information. Note that a document may end up
referencing more documents (framesets / iframes) and may have one or
more render_widgets (overflowed divs etc)
A core concept/struct called 'render_widget' which encompasses
everything associated with an independently scrollable/sizeable area of
a display which can be rendered.
The GUI becomes the core of the app, using the browser object as a
client, and causing new browser_widget objects to be allocated when
(e.g. a new tab is opened). (naturally the core can request of the gui
that a new browser_widget be created (and given a specific set of inputs
e.g. URL) for _new targets etc). The core then, whenever it needs a new
render_widget, it asks the gui, giving it parenting information etc
associated with the widget. All render_widgets in a given tab/whatever
have a single browser_widget parent, and may have a render_widget
parent. Only one render_widget may be created in a given browser_widget
with no render_widget parent (the top level for the document at the top
level of the browser_widget).
This is all currently braindump, so don't expect it to make perfect
sense, but it's somewhere to work from.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895
2:35 p.m.
On Fri, 2009-03-27 at 14:37 +0000, Daniel Silverstone wrote:
A core concept/struct called 'document' which represents the
content
object and associated information. Note that a document may end up
referencing more documents (framesets / iframes) and may have one or
more render_widgets (overflowed divs etc)
A core concept/struct called 'render_widget' which encompasses
everything associated with an independently scrollable/sizeable area of
a display which can be rendered.
Note that render_widgets may not be opaque. For example, you might have:
<div style="background-color: transparent;
overflow:scroll">...</div>
Also note that CSS3 adds support for alpha channels.
For the rest, I'd appreciate it if people who are actually working on
frontends (and thus with UI toolkits) would comment on Daniel's
proposal.
J.
4:38 a.m.
2009/3/27 Daniel Silverstone <dsilvers(a)netsurf-browser.org>:
On Fri, 2009-03-27 at 14:08 +0000, John-Mark Bell wrote:
> > I kinda expected there to be a gui render area per frame/iframe anyway,
> > since they're the independently scrollable renderable bits.
> Which is what we currently have. And which is broken on everything that
> isn't RISC OS.
> Perhaps I'm missing something?
What we have currently is "browser window" -> "gui window" as the
core
concept.
...
This is all currently braindump, so don't expect it to make
perfect
sense, but it's somewhere to work from.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895
I am not sure if I got your point Daniel, so let me write how I
understand it and ask some questions so that you can tell me if I got
it wrong :). Sorry for repeating the issues but I think it would also
be useful to write down all the doubts at one place.
Looking on your project from the browser_widget layer down it seems to
be similar to what I have suggested as the browser_window-frame split.
The main difference is that the frames are split further into
render_widgets. A render_widget would be responsible for providing the
API for drawing scrolls, handling events connected to them etc. The
additional split lets us add this functionality to elements not being
frames, like overflow boxes.
Would a render_widget be provided by the front end or by the core?
(despite the answer I give myself underneath I'd like to know what you
meant :) )
The first approach hinders frames from working with GUI toolkits
without proper widgets (that's why I abandoned this idea in my first
mail - but maybe unfairly?) but makes the toolkit handle widget
clipping, scrolling etc. Also if we want transparency the widget has
to provide it. On the other side if the core provides the
render_widget it still leaves place for native scrollbars but adds
problems with clipping them. Finally, we can make the core draw
everything but this just makes the pages bad looking.
The simple one
One main conclusion is that the simplest idea (full-core), probably
with some theming, would have to be written either way in order to get
frames on the most limited front ends (i.e framebuffer). Maybe using
bitmaps for the theming would let this look even better but I have no
idea what the scrolls on other front ends look like, if they have some
round edges(which can't be done by the plotters) etc. Although,
because of the need of finding some common factor, scrollbars might
not look/behave perfectly native.
The mixed one
The more demanding way would be making the front end decide whether it
uses its own widgets or the core ones. Those could be different for
each render_widget but would be hidden behind it's API. Events would
be passed to it, where they could be ignored(for native widgets) or
handled by the core. This way it would be up to the front end
developer whether he wants to add functions for drawing clipped
scrollbars (where only scrollbars would be native, not the whole
drawing area) or other complicated stuff in order to get frames
working. This would make frames available everywhere with a simple
choice between simplicity and coolness. By choosing simplicity this
solution acts like the previous one. As long as no other consensus is
reached, this looks like a way of making everyone happy(considering
the previous responses) and the main effort would have to be done once
only.
This seems to show a way of incremental changes leading to frame
support(what I am also aiming for). Later Today I'll try to precise it
together with what render_widget could look like. Now, I really need
to get some sleep :) but I'm sending what I managed to come up with,
to get your feedback. Even if it's not what you meant tell me your
opinion please.
12:46 a.m.
This is a continuation of what I've written last time :)
To give a feeling of how I would understand render_widgets to work
here's a part of a possible implementation:
The API
render_widget_create(bool has_scrollbars, bool
scrollbar_can_be_cropped, bool can_be_transparent, etc.) - depending
on the parameters and the functions provided by the front end this
would create the appropriate internal representation
render_widget_set(box->render_widget) - sets the render widget for plotting
render_widget_unset(box->render_widget) - sets it's parent(if any) back
functions_for_mouse_events_occurring
render_widget_hide() - for hiding it on tab change if necessary
render_widget_show()
...
the internals(I tried to cover at least different "types" of functionality)
- mouse_events, ignored where native scrolls would be present
- scroll_callback - called when scroll gets moved(either from
mouse_events or by the front_end)
- front_end_draw_scroll(x,y,clip rectangle) - pointer to the front end
function which could be optionally provided
...
So if you don't reject the whole concept as completely inappropriate I
could extend it to cover everything what's needed. I'd just need to
know if it's worth the effort, especially now when the deadline for
GSoC proposals gets really close :)
I was also thinking about the connections between the concepts/structs
which would have to be done. Both documents and render_widgets are
trees with their root in a browser_widget. Actually, the render
widgets are separate trees with their roots in frames but the
additional linking will come useful. I am not sure what the proper
event flow should be for redraws. I still see it as
->browser_widget->document->content_redraw. Now what about the
render_widgets? They should be kept somewhere to be considered during
the redraw, but not be a cell in the chain (pass the redraw further).
This makes the best place for them the box tree, i.e by keeping a
pointer in box_types which might need own render widgets. During a
redraw this would be considered e.g by doing:
if (box->render_widget)
render_widget_set(box->render_widget);
some actions here;
render_widget_unset(box->render_widget);
Aha, and please tell me if I'm writing to windily for your patience. I
wouldn't like to scare you off and kill the discussion :)
5:31 p.m.
On Tue, 2009-03-31 at 00:46 +0200, Paweł Blokus wrote:
This is a continuation of what I've written last time :)
I think we're not going to have this finalised before the GSoC
application deadline. My advice, therefore, is for you to submit an
application to do the core UI and the keyboard navigation projects.
We can continue to work on the frames issue over the next few days/weeks
and, if we reach a suitable conclusion soon enough, refocus your project
then.
Cheers,
J.
8:44 p.m.
In article <1238092767.24067.37.camel@duiker>,
John-Mark Bell <jmb(a)ecs.soton.ac.uk> wrote:
I think the simplest solution is to define an interface which
provides
all the API we'll need. A partial list might be:
+ create
+ destroy
+ get_scrollbar_width
+ get_scrollbar_height
+ set_extents
+ get_scroll_offset
+ request_scroll_to
I think it also needs:
+ get_scrollbars_for_browser_window
Requests list of all scrollbars needed for a particular browser window.
You use this to find which scrollbars are needed for when you change to
a new tab.
One remaining problem is ensuring that the correct widgets are
visible
or not. (Consider an iframe inside a frame, with the containing frame
scrolled so that the iframe is not visible. The iframe's scrollbar
should not be visible, either). This also suggests there might be
interesting clipping issues to resolve.
Yeah, I think each scrollbar needs a clip rectangle. The clip rectangle is
the parent frame/iframe viewport. I guess it requires that the GUI toolkit
allows cropped portions of scrollbars to be plotted.
The other frames related issue is navigation history with frames.
Currently if you visit a site with frames at http://domain.tld/ and it has
a navigation bar frame and a content area frame, if you lick a link in the
navigation bar to change the page shown in the content area frame, it does
not cause a new history entry to be created. So if you now click Back, it
doesn't change the content area frame to show what was there originally,
it goes back to the page you viewed before http://domain.tld/.
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
8:49 p.m.
On Thu, 2009-03-26 at 19:44 +0000, Michael Drake wrote:
In article <1238092767.24067.37.camel@duiker>,
John-Mark Bell <jmb(a)ecs.soton.ac.uk> wrote:
> I think the simplest solution is to define an interface which provides
> all the API we'll need. A partial list might be:
> + create
> + destroy
> + get_scrollbar_width
> + get_scrollbar_height
> + set_extents
> + get_scroll_offset
> + request_scroll_to
I think it also needs:
+ get_scrollbars_for_browser_window
Requests list of all scrollbars needed for a particular browser window.
You use this to find which scrollbars are needed for when you change to
a new tab.
Er. That's not part of the scrollbar widget API. It should be
browser_window_get_scrollbars(), or somesuch. What does this call
return?
The other frames related issue is navigation history with frames.
Currently if you visit a site with frames at http://domain.tld/ and it has
a navigation bar frame and a content area frame, if you lick a link in the
navigation bar to change the page shown in the content area frame, it does
not cause a new history entry to be created. So if you now click Back, it
doesn't change the content area frame to show what was there originally,
it goes back to the page you viewed before http://domain.tld/.
Well yeah. But frames + history is a fundamentally broken concept,
anyway. So, whatever we do here is unlikely to be satisfactory.
J.
5110
days inactive
5119
days old
netsurf-dev@netsurf-browser.org
23 comments
7 participants
participants (7)
-
Chris Young -
Daniel Silverstone -
François Revol -
John-Mark Bell -
John-Mark Bell -
Michael Drake -
Paweł Blokus