2:34 a.m.
Text inputs and textareas used in HTML forms have never been robust and
we've decided to fix them for NetSurf 3.0.
Since the existing implementation is unmaintainable, the plan is to make
html forms use the desktop/textarea.{c|h} widget (which is currently used
for Hotlist node editing and the Atari URL bar).
The first stage of this is to add all the extra functionality we require
to the desktop/textarea widget, including clipboard support.
I've updated the front end clipboard API so now it can be used outside
browser windows, and to remove use of the html/text-plain selection
structure:
http://source.netsurf-browser.org/netsurf.git/commit/?id=e93fae7f2d9fdcc4...
The Atari, Amiga, and BeOS front ends all need updated.
The RISC OS front end needs attention so that it can paste when another
application has ownership of the clipboard.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
3:06 a.m.
On 08 Jan, tlsa(a)netsurf-browser.org wrote:
The Atari, Amiga, and BeOS front ends all need updated.
In case it isn't clear, if you need to implement a menu option to
cut/copy/paste, you pass the approprate key to the core.
So for browser windows:
browser_window_key_press(bw, KEY_CUT_SELECTION);
browser_window_key_press(bw, KEY_COPY_SELECTION);
browser_window_key_press(bw, KEY_PASTE);
Then the gui_{get|set}_clipboard functions will be called by the core if
the core is able to deal with the action.
(e.g. for KEY_PASTE, there must be an editable feature with input focus in
the core for it to act on the KEY_PASTE and call gui_get_clipboard).
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
3:33 a.m.
Hi Michael
On Tue, 08 Jan 2013 18:06:23 +0000 (GMT), Michael Drake wrote:
(e.g. for KEY_PASTE, there must be an editable feature with input
focus in
the core for it to act on the KEY_PASTE and call gui_get_clipboard).
Previously I was checking to see if something was selected in order to
update the menu items as enabled/disabled (so you can't even select
"copy" if there is no area highlighted). Is it still possible to do
this?
If not functions like can_copy(), can_paste(), can_select etc would be
very nice to have.
Chris
3:41 a.m.
In article
<OUT-50EC6665.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
If not functions like can_copy(), can_paste(), can_select etc would
be
very nice to have.
OK, noted.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
1:34 a.m.
In article <530af2254btlsa(a)netsurf-browser.org>,
Michael Drake <tlsa(a)netsurf-browser.org> wrote:
In article
<OUT-50EC6665.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
> If not functions like can_copy(), can_paste(), can_select etc
would be
> very nice to have.
OK, noted.
We now have browser_window_get_editor_flags(), which provides this info
for browser windows. I've updated the front ends to use it.
There is no such thing for treeview windows as yet. I'm planning a
treeview rewrite anyway.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
5:25 a.m.
Hi Michael
On Tue, 08 Jan 2013 18:06:23 +0000 (GMT), Michael Drake wrote:
Then the gui_{get|set}_clipboard functions will be called by the core
if
the core is able to deal with the action.
For gui_get_clipboard, if the clipboard is empty should the frontend
return a pointer to a NULL string? Currently I'm returning NULL, but
the core doesn't like that. Returning NULL makes more sense to me, as
it makes it easy to bail out early if memory allocations are failing.
Chris
7:55 p.m.
On Tue, 08 Jan 2013 18:06:23 +0000 (GMT), Michael Drake wrote:
(e.g. for KEY_PASTE, there must be an editable feature with input
focus in
the core for it to act on the KEY_PASTE and call gui_get_clipboard).
Pasting into fields that are in frames doesn't seem to be working.
Try: http://www.amiupdate.net
Click on "login" (the entire site is one of those horrid "invisible
frames")
Try pasting something into the username field.
Chris
8:23 p.m.
In article
<OUT-51177C93.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
Pasting into fields that are in frames doesn't seem to be
working.
It works in my local version, which uses the textarea widget for forms.
I've got a bit more work before I can push my changes.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
8:06 a.m.
On 8 Jan, Michael Drake wrote in message
<530aec009ctlsa(a)netsurf-browser.org>:
The RISC OS front end needs attention so that it can paste when
another
application has ownership of the clipboard.
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.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
8:48 a.m.
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?
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
7:34 a.m.
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.
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.
1. Does anyone reading know?
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 20 April 2013
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
8:05 a.m.
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.
9:14 a.m.
On 24 Feb, John-Mark Bell wrote in message
<1361747132.31757.59.camel@duiker>:
However, I believe this is mostly moot, as we fixed paste some time
ago:
http://git.netsurf-browser.org/netsurf.git/commit/?id=64ae9e8693aaaf09cb4...
Ah, OK -- I'd clearly not spotted that. Thanks!
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
8:51 a.m.
Here's the current textarea progress.
Key: + done
- todo
+ Add clipboard support
+ Improve selection handling
+ Fix various editing crashes
+ Fix serious redraw problems
+ Improve caret behaviour
+ Improve word wrap
- Enable styling for HTML usage
- Padding widths
- Background/text/selected colours
- Optional borders
- Add scrollbars (multiline only)
- Scaled redraw (needed for HTML)
- Mouse input to handle scale? (or have the client pre-scale)
- Native caret? (currently requires a gui_window)
Then there are a bunch of minor things, like the textarea only
scrolling when the caret is right at the edge, rather than trying
to keep it near the center, if there is more text after the caret.
Once all that's done I can look at plugging it into the HTML content
handler's forms.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
10:56 p.m.
In article <530c164516tlsa(a)netsurf-browser.org>,
Michael Drake <tlsa(a)netsurf-browser.org> wrote:
Once all that's done I can look at plugging it into the HTML
content
handler's forms.
That's now done. So forms are now using the textarea widget for:
+ INPUT element type TEXT
+ INPUT element type PASSWORD
+ TEXTAREA element
The forms elements are still forced to BOX_INLINE_BLOCK, since changing
what would require extensive and fiddly changes to layout. So that can
wait for the layout engine rewrite. :)
There are some remaining issues, main ones being:
- There is currently no way to provide a clip rectangle for the native
caret rendering, so if you give a textarea widget focus and scroll it,
the caret will be rendered outside the textarea.
- Selecting text in a textarea widget doesn't cause any existing
selections elsewhere in the window to be cleared.
Cheers,
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
2:04 a.m.
Hi,
On 08/01/2013 18:34, Michael Drake wrote:
Text inputs and textareas used in HTML forms have never been robust and
we've decided to fix them for NetSurf 3.0.
The Atari, Amiga, and BeOS front ends all need updated.
I just fixed the BeOS/Haiku port, pretty straightforward thanks to the
styles array, works fine:
http://source.netsurf-browser.org/netsurf.git/log/?h=mmu_man/beos-fixes
François.
6:15 p.m.
On Sun, 2013-01-20 at 18:04 +0100, François Revol wrote:
Hi,
On 08/01/2013 18:34, Michael Drake wrote:
>
> Text inputs and textareas used in HTML forms have never been robust and
> we've decided to fix them for NetSurf 3.0.
>
> The Atari, Amiga, and BeOS front ends all need updated.
I just fixed the BeOS/Haiku port, pretty straightforward thanks to the
styles array, works fine:
http://source.netsurf-browser.org/netsurf.git/log/?h=mmu_man/beos-fixes
Merged.
Ta,
J.
3863
days inactive
3911
days old
netsurf-dev@netsurf-browser.org
16 comments
5 participants
participants (5)
-
Chris Young -
François Revol -
John-Mark Bell -
Michael Drake -
Steve Fryatt