Re: Text area refresh
Am Montag, den 08.04.2013, 23:52 +0200 schrieb Ole : 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
Re: Text area refresh
Am Montag, den 08.04.2013, 21:53 +0200 schrieb "Chris Young"
:
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
Re: 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
Re: Text area refresh
In article , Chris Young 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/
Re: Text area refresh
On Fri, 5 Apr 2013 13:09:01 +0200, J. F. Lemaire wrote: > On 5 April 2013 12:30, 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
