7:30 p.m.
What I have noticed recently is that pasting into the text area with Ctrl-V
creates 2 copies of the pasted text.
Peter
8:09 p.m.
New subject: Text area refresh
On 5 April 2013 12:30, <p.slegg(a)scubadivers.co.uk> wrote:
What I have noticed recently is that pasting into the text area with
Ctrl-V
creates 2 copies of the pasted text.
Yes, I noticed this too. I suspect this is a frontend issue, however,
not a core one, since each platform has its own mechanism to access
the clipboard.
Cheers,
JFL
--
Jean-François Lemaire
3:31 a.m.
New subject: Text area refresh
On Fri, 5 Apr 2013 13:09:01 +0200, J. F. Lemaire wrote:
On 5 April 2013 12:30, <p.slegg(a)scubadivers.co.uk> wrote:
> What I have noticed recently is that pasting into the text area with Ctrl-V
> creates 2 copies of the pasted text.
Yes, I noticed this too. I suspect this is a frontend issue, however,
not a core one, since each platform has its own mechanism to access
the clipboard.
I'm not so sure. Here the frontend handles RAmiga-V as a paste
shortcut, and that works wonderfully. However, something (I'm
suspecting the core, as I haven't added any code for this) is trapping
Ctrl-V and handling that as a paste operation too.
You've neglected to mention what platform you are using, but what I
suspect is happening, is the frontend is handling Ctrl-V as a paste
operation, and that shortcut is also reaching the core, which handles
it again as a paste - hence the two pastes.
The core handling of Ctrl-V (and any other similar shortcuts) probably
needs to be tracked down and obliterated.
Chris
3:54 a.m.
New subject: Text area refresh
In article
<OUT-51631B25.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
The core handling of Ctrl-V (and any other similar shortcuts)
probably
needs to be tracked down and obliterated.
The core handling of Ctrl-V is the only supported way of pasting.
When you select "Paste" in a menu, the front end should be implementing it
by passing Ctrl-V to the core.
When the core gets a Ctrl-V it passes it on internally to whatever has
input focus. If there is a textarea with focus, the textarea handles the
keypress (by calling gui_get_clipboard, in the case of Ctrl-V).
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
4:53 a.m.
New subject: Text area refresh
On Mon, 08 Apr 2013 19:54:52 +0100, Michael Drake wrote:
The core handling of Ctrl-V is the only supported way of pasting.
When you select "Paste" in a menu, the front end should be implementing it
by passing Ctrl-V to the core.
Oh yes, I didn't realise KEY_PASTE = ASCII 22 = Ctrl-V (until I looked
it up)
I still think the double-pasting would be the frontend interpreting it
directly as a KEY_PASTE *and* passing the original key press as well.
Chris
6:52 a.m.
New subject: Text area refresh
Am Montag, den 08.04.2013, 21:53 +0200 schrieb "Chris Young"
<chris.young(a)unsatisfactorysoftware.co.uk>:
Oh yes, I didn't realise KEY_PASTE = ASCII 22 = Ctrl-V (until I
looked
it up)
I still think the double-pasting would be the frontend interpreting
it
directly as a KEY_PASTE *and* passing the original key press as well.
The following is happening with the Atari frontend:
- First Ctrl+V is captured by the main menu... ("paste" action is
executed).
- The browser window key handling routine passes the keycode to the
internal browser_window structure.
I have to think about how to solve it...:
1. I would still like to process menu events before
browser_window events.
2. catching ctrl+v and not passing it to the core is maybe
incorrect(??).
What looks best suited to me is to drop events which are handled by the
menu area (should be done already,
so this is an bug in the frontend), however, that solution maybe
conflicts with policy number 2 (see above).
Greets,
Ole
7:37 a.m.
New subject: Text area refresh
Am Montag, den 08.04.2013, 23:52 +0200 schrieb Ole <ole(a)monochrom.net>:
Am Montag, den 08.04.2013, 21:53 +0200 schrieb "Chris
Young"
I have to think about how to solve it...:
1. I would still like to process menu events before
browser_window events.
2. catching ctrl+v and not passing it to the core is maybe
incorrect(??).
What looks best suited to me is to drop events which are handled by
the menu area (should be done already,
so this is an bug in the frontend), however, that solution maybe
conflicts with policy number 2 (see above).
I was wrong, browser_window_key_input is called before the deskmenu
shortcut processing,
so now I'm ignoring inputs which are handled by
browser_window_key_input.
The problem should be fixed in the next build, I hope this doesn't
introduce any side-effects :)
Greets,
Ole
3206
days inactive
3209
days old
netsurf-users@netsurf-browser.org
6 comments
5 participants
participants (5)
-
Chris Young -
J. F. Lemaire -
Michael Drake -
Ole -
p.slegg＠scubadivers.co.uk