Re: New clipboard API for front ends, and textarea progress
On Sun, 2013-02-24 at 22:34 +0000, Steve Fryatt wrote:
On 10 Jan, Michael Drake wrote in message
<530c15f056tlsa(a)netsurf-browser.org>:
> In article <mpro.mgds7b08fs7pc01k4.lists(a)stevefryatt.org.uk>,
> Steve Fryatt <lists(a)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[1] 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:
http://git.netsurf-browser.org/netsurf.git/commit/?id=64ae9e8693aaaf09cb4...
J.