New clipboard API for front ends, and textarea progress
jmb at netsurf-browser.org
Sun Feb 24 23:05:32 GMT 2013
On Sun, 2013-02-24 at 22:34 +0000, Steve Fryatt wrote:
> On 10 Jan, Michael Drake wrote in message
> <530c15f056tlsa at netsurf-browser.org>:
> > In article <mpro.mgds7b08fs7pc01k4.lists at stevefryatt.org.uk>,
> > Steve Fryatt <lists at stevefryatt.org.uk> wrote:
> > > That shouldn't be too tricky to sort. I'm a little busy at present with
> > > non-computery stuff, but will try to take a look in the next couple of
> > > weeks if no-one else gets there first.
> > Thanks, that would be great. All pastes happen as a result of passing
> > KEY_PASTE to the core, so maybe it can request the clipboard when it
> > passes that to the core, and then when the core calls gui_get_clipboard,
> > maybe it will be easier?
> Will gui_poll be called between KEY_PASTE being passed in to the core and
> gui_get_clipboard getting called in return? This would potentially have to
> happen several times -- and the required number could vary.
gui_poll will only ever be called from the main loop. Beyond that, we
make no guarantees.
> If not, is it safe for the front end to go and make calls to its own
> gui_poll before gui_get_clipboard returns? I'm not sure if RISC OS
> defines that a task won't get other poll codes (eg. redraws) during a
> message exchange; if not, then there's the potential for the core to get
> called for something else before gui_get_clipboard returns.
User messages have higher priority than any others, so if there is a
user message waiting, it will take precedence. I don't believe this
permits any assumption about not having to deal with other message types
(or other user messages, for that matter)
However, I believe this is mostly moot, as we fixed paste some time ago:
More information about the netsurf-dev