I think this is already answered within the FAQ, but just in case it isn't, I seem not to be able to copy & paste into form input boxes. When I do try to "middle mouse button" copy/paste, my output goes into the url entry field of the browser instead of where I intended to paste a form input box. -- Roger http://rogerx.freeshell.org/
On Wed, Jul 21, 2010 at 12:48:10AM -0800, Roger wrote:
I think this is already answered within the FAQ, but just in case it isn't, I seem not to be able to copy & paste into form input boxes.
When I do try to "middle mouse button" copy/paste, my output goes into the url entry field of the browser instead of where I intended to paste a form input box.
This seems to work ok for me - at least when I tried with google. But I remember that we have some focus related problems recently. Cheers, Johannes
On Wed, Jul 21, 2010 at 01:29:36PM +0200, Johannes Hofmann wrote:
On Wed, Jul 21, 2010 at 12:48:10AM -0800, Roger wrote:
I think this is already answered within the FAQ, but just in case it isn't, I seem not to be able to copy & paste into form input boxes.
When I do try to "middle mouse button" copy/paste, my output goes into the url entry field of the browser instead of where I intended to paste a form input box.
This seems to work ok for me - at least when I tried with google. But I remember that we have some focus related problems recently.
Here it works. I don't even need to focus the place to paste, the cursor over the widget is enough (FLTK2 v7513). -- Cheers Jorge.-
On Wed, Jul 21, 2010 at 10:29:32AM -0400, Jorge Arellano Cid wrote:
On Wed, Jul 21, 2010 at 01:29:36PM +0200, Johannes Hofmann wrote:
On Wed, Jul 21, 2010 at 12:48:10AM -0800, Roger wrote:
I think this is already answered within the FAQ, but just in case it isn't, I seem not to be able to copy & paste into form input boxes.
When I do try to "middle mouse button" copy/paste, my output goes into the url entry field of the browser instead of where I intended to paste a form input box.
This seems to work ok for me - at least when I tried with google. But I remember that we have some focus related problems recently.
Here it works. I don't even need to focus the place to paste, the cursor over the widget is enough (FLTK2 v7513).
=x11-libs/fltk-2.0_pre6970 cairo debug doc examples games +jpeg opengl +png threads +xft xinerama +zlib =www-client/dillo-2.2 doc +gif ipv6 +jpeg +png +ssl When you state "focus problems", I would assume you're talking about when fltk/dillo borks on my focus problem and screws up what I'm typing into the focus box -- until I press ctrl+tab (or switch virtual desktops, then switch back again to the dillo virtual desktop). Here's a thought, maybe it's because I'm a power user and am using DWM instead of some funky desktop such as Gnome/XFCE ... or even KDE? -- Roger http://rogerx.freeshell.org/
On Wed, Jul 21, 2010 at 10:50:01AM -0800, Roger wrote:
On Wed, Jul 21, 2010 at 10:29:32AM -0400, Jorge Arellano Cid wrote:
On Wed, Jul 21, 2010 at 01:29:36PM +0200, Johannes Hofmann wrote:
On Wed, Jul 21, 2010 at 12:48:10AM -0800, Roger wrote:
I think this is already answered within the FAQ, but just in case it isn't, I seem not to be able to copy & paste into form input boxes.
When I do try to "middle mouse button" copy/paste, my output goes into the url entry field of the browser instead of where I intended to paste a form input box.
This seems to work ok for me - at least when I tried with google. But I remember that we have some focus related problems recently.
Here it works. I don't even need to focus the place to paste, the cursor over the widget is enough (FLTK2 v7513).
=x11-libs/fltk-2.0_pre6970 cairo debug doc examples games +jpeg opengl +png threads +xft xinerama +zlib
=www-client/dillo-2.2 doc +gif ipv6 +jpeg +png +ssl
When you state "focus problems", I would assume you're talking about when fltk/dillo borks on my focus problem and screws up what I'm typing into the focus box -- until I press ctrl+tab (or switch virtual desktops, then switch back again to the dillo virtual desktop).
Here's a thought, maybe it's because I'm a power user and am using DWM instead of some funky desktop such as Gnome/XFCE ... or even KDE?
No, that can't be the issue, as I also use dwm :-) However I hardly use virtual desktops - or whatever it's called in suckless speak. Can you give me an example page where you can't copy / paste into a form field? Cheers, Johannes
On Thu, Jul 22, 2010 at 10:44:26PM +0200, Johannes Hofmann wrote:
On Wed, Jul 21, 2010 at 10:50:01AM -0800, Roger wrote:
On Wed, Jul 21, 2010 at 10:29:32AM -0400, Jorge Arellano Cid wrote:
On Wed, Jul 21, 2010 at 01:29:36PM +0200, Johannes Hofmann wrote:
On Wed, Jul 21, 2010 at 12:48:10AM -0800, Roger wrote:
I think this is already answered within the FAQ, but just in case it isn't, I seem not to be able to copy & paste into form input boxes.
When I do try to "middle mouse button" copy/paste, my output goes into the url entry field of the browser instead of where I intended to paste a form input box.
This seems to work ok for me - at least when I tried with google. But I remember that we have some focus related problems recently.
Here it works. I don't even need to focus the place to paste, the cursor over the widget is enough (FLTK2 v7513).
=x11-libs/fltk-2.0_pre6970 cairo debug doc examples games +jpeg opengl +png threads +xft xinerama +zlib
=www-client/dillo-2.2 doc +gif ipv6 +jpeg +png +ssl
When you state "focus problems", I would assume you're talking about when fltk/dillo borks on my focus problem and screws up what I'm typing into the focus box -- until I press ctrl+tab (or switch virtual desktops, then switch back again to the dillo virtual desktop).
Here's a thought, maybe it's because I'm a power user and am using DWM instead of some funky desktop such as Gnome/XFCE ... or even KDE?
No, that can't be the issue, as I also use dwm :-) However I hardly use virtual desktops - or whatever it's called in suckless speak.
Virtual desktop for DWM == dwm.h ...snip... /* tagging */ static const char *tags[] = { "1", "2", "3", "4", "5", "6", "7" }; ...snip...
Can you give me an example page where you can't copy / paste into a form field?
http://www.google.com is probably the best standard example. I cannot copy/paste onto any web page with a form box to enter data. All data within the copy buffer ends-up within the URL box of Dillo. No matter how I even try to focus with the keyboard, or where I click concerning (X coordinates) with the mouse middle button. One thing is for sure, Dillo (or X/DWM) is recognizing the middle mouse button click and is sending the correct data -- but not to the right X coordinates!
On Thu, Jul 22, 2010 at 02:15:54PM -0800, rogerx@sdf.org wrote:
On Thu, Jul 22, 2010 at 10:44:26PM +0200, Johannes Hofmann wrote:
On Wed, Jul 21, 2010 at 10:50:01AM -0800, Roger wrote:
On Wed, Jul 21, 2010 at 10:29:32AM -0400, Jorge Arellano Cid wrote:
On Wed, Jul 21, 2010 at 01:29:36PM +0200, Johannes Hofmann wrote:
On Wed, Jul 21, 2010 at 12:48:10AM -0800, Roger wrote:
I think this is already answered within the FAQ, but just in case it isn't, I seem not to be able to copy & paste into form input boxes.
When I do try to "middle mouse button" copy/paste, my output goes into the url entry field of the browser instead of where I intended to paste a form input box.
This seems to work ok for me - at least when I tried with google. But I remember that we have some focus related problems recently.
Here it works. I don't even need to focus the place to paste, the cursor over the widget is enough (FLTK2 v7513).
=x11-libs/fltk-2.0_pre6970 cairo debug doc examples games +jpeg opengl +png threads +xft xinerama +zlib
=www-client/dillo-2.2 doc +gif ipv6 +jpeg +png +ssl
When you state "focus problems", I would assume you're talking about when fltk/dillo borks on my focus problem and screws up what I'm typing into the focus box -- until I press ctrl+tab (or switch virtual desktops, then switch back again to the dillo virtual desktop).
Here's a thought, maybe it's because I'm a power user and am using DWM instead of some funky desktop such as Gnome/XFCE ... or even KDE?
No, that can't be the issue, as I also use dwm :-) However I hardly use virtual desktops - or whatever it's called in suckless speak.
Virtual desktop for DWM == dwm.h ...snip... /* tagging */ static const char *tags[] = { "1", "2", "3", "4", "5", "6", "7" }; ...snip...
Can you give me an example page where you can't copy / paste into a form field?
http://www.google.com is probably the best standard example.
I cannot copy/paste onto any web page with a form box to enter data.
All data within the copy buffer ends-up within the URL box of Dillo. No matter how I even try to focus with the keyboard, or where I click concerning (X coordinates) with the mouse middle button.
One thing is for sure, Dillo (or X/DWM) is recognizing the middle mouse button click and is sending the correct data -- but not to the right X coordinates!
Can you check whether fltk2-config --ldflags says something about cairo? If so please compile fltk2 from source without enabling cairo. There are multiple issues when cairo is enabled (see warning on http://www.dillo.org/download.html). You could also try whether pasting works for you with the fltk2 sample apps that come with fltk2. Cheers, Johannes
On Fri, Jul 23, 2010 at 12:31:58AM +0200, Johannes Hofmann wrote:
Can you check whether
fltk2-config --ldflags
says something about cairo? If so please compile fltk2 from source without enabling cairo. There are multiple issues when cairo is enabled (see warning on http://www.dillo.org/download.html).
You could also try whether pasting works for you with the fltk2 sample apps that come with fltk2.
$ fltk2-config --ldflags -L/usr/lib/fltk -lfltk2 -lX11 -lXi -lXcursor -lXft -lpthread -lm -lXext -lsupc++ Seems I stripped building with cairo to prevent unwanted dependecies (aka bloat). But, I did recompile fltk with the cairo flag enabled --ldflags does show cairo now, but the ebuild for Dillo (Gentoo Ebuild) keeps complaining: No matter what USE flags I specify, Dillo complains recursively about *nothing* -- and wants me to now recompile fltk without cairo! # USE="cairo -doc -gif -ipv6 -jpeg -png -ssl" emerge dillo -pv These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds built with USE flags to satisfy "x11-libs/fltk:2[-cairo,-png,-jpeg]". !!! One of the following packages is required to complete your request: - x11-libs/fltk-2.0_pre6970 (Change USE: -cairo) (dependency required by "www-client/dillo-2.2" [ebuild]) (dependency required by "dillo" [argument]) In short, think I need to probably file a bug report against the Dillo ebuild?? And one other thing, after compiling fltk without cairo and not recompiling Dillo, Dillo's display is flickering -- so I'm guessing I just need to recompile Dillo (as I was trying above) to resolve the screwed flickering display. -- Roger http://rogerx.freeshell.org/
On Thu, Jul 22, 2010 at 04:49:46PM -0800, rogerx@sdf.org wrote:
# USE="cairo -doc -gif -ipv6 -jpeg -png -ssl" emerge dillo -pv
These are the packages that would be merged, in order:
Calculating dependencies... done!
emerge: there are no ebuilds built with USE flags to satisfy "x11-libs/fltk:2[-cairo,-png,-jpeg]". !!! One of the following packages is required to complete your request: - x11-libs/fltk-2.0_pre6970 (Change USE: -cairo) (dependency required by "www-client/dillo-2.2" [ebuild]) (dependency required by "dillo" [argument])
In short, think I need to probably file a bug report against the Dillo ebuild??
OK. I found the culprit within the dillo ebuild: RDEPEND="x11-libs/fltk:2[-cairo,jpeg=,png=] Apparently, the Gentoo Dillo Ebuilds are scripted to check for fltk2 compiled without cairo support (ie. -cairo). When fltk is compiled with cairo support, the above error will result requesting fltk be recompiled without cairo support. Did a search for the words "dillo cairo" and "fltk cairo" and I find zero bugs ever filed for them. Is there any reason why Gentoo developers would demand fltk be built without cairo support? Any big evil or huge bug possible? Licensing?? x11-libs/cairo-1.8.8-r1.ebuild LICENSE="|| ( LGPL-2.1 MPL-1.1 )" Well, anyways -- building fltk with cairo (and needlessly recompiling dillo afterwards) support causes Dillo to constantly flicker making the user interface unusable. And still, copy/pasting always causes the copy buffer to end-up within the Dillo url entry field. :-/ As such, it's likely cairo isn't the culprit here.
On Thu, Jul 22, 2010 at 07:07:38PM -0800, rogerx@sdf.org wrote:
On Thu, Jul 22, 2010 at 04:49:46PM -0800, rogerx@sdf.org wrote:
# USE="cairo -doc -gif -ipv6 -jpeg -png -ssl" emerge dillo -pv
These are the packages that would be merged, in order:
Calculating dependencies... done!
emerge: there are no ebuilds built with USE flags to satisfy "x11-libs/fltk:2[-cairo,-png,-jpeg]". !!! One of the following packages is required to complete your request: - x11-libs/fltk-2.0_pre6970 (Change USE: -cairo) (dependency required by "www-client/dillo-2.2" [ebuild]) (dependency required by "dillo" [argument])
In short, think I need to probably file a bug report against the Dillo ebuild??
OK. I found the culprit within the dillo ebuild: RDEPEND="x11-libs/fltk:2[-cairo,jpeg=,png=]
Apparently, the Gentoo Dillo Ebuilds are scripted to check for fltk2 compiled without cairo support (ie. -cairo). When fltk is compiled with cairo support, the above error will result requesting fltk be recompiled without cairo support.
Ah cool, they probabely implemented the check to avoid that people get the flicker problems you were also seeing with dillo and cairo-enabled fltk.
Did a search for the words "dillo cairo" and "fltk cairo" and I find zero bugs ever filed for them. Is there any reason why Gentoo developers would demand fltk be built without cairo support? Any big evil or huge bug possible? Licensing??
x11-libs/cairo-1.8.8-r1.ebuild LICENSE="|| ( LGPL-2.1 MPL-1.1 )"
Well, anyways -- building fltk with cairo (and needlessly recompiling dillo afterwards) support causes Dillo to constantly flicker making the user interface unusable.
And still, copy/pasting always causes the copy buffer to end-up within the Dillo url entry field. :-/
As such, it's likely cairo isn't the culprit here.
Ok, can you test pasting with the test programs from your fltk build, e.g. test/input?
On Fri, Jul 23, 2010 at 09:24:59AM +0200, Johannes Hofmann wrote:
And still, copy/pasting always causes the copy buffer to end-up within the Dillo url entry field. :-/
As such, it's likely cairo isn't the culprit here.
Ok, can you test pasting with the test programs from your fltk build, e.g. test/input?
I just noticed your email. Oh wow, there's this tool called "/usr/bin/fluid2" within the FLTK package. But still, README's state little to nothing about getting good debug output (except likely only through GDB when something bad happens). Neat. Yes, I can copy past into the widgets/windows in this tool. Just tried. So this (kind of) narrows things down to Dillo. Dillo debug output states very little. I'll try stracing it later on today. ;-)
On Wed, 21 Jul 2010 10:50:01 -0800, Roger wrote:
On Wed, Jul 21, 2010 at 10:29:32AM -0400, Jorge Arellano Cid wrote:
On Wed, Jul 21, 2010 at 01:29:36PM +0200, Johannes Hofmann wrote:
On Wed, Jul 21, 2010 at 12:48:10AM -0800, Roger wrote:
I think this is already answered within the FAQ, but just in case it isn't, I seem not to be able to copy & paste into form input boxes.
When I do try to "middle mouse button" copy/paste, my output goes into the url entry field of the browser instead of where I intended to paste a form input box.
This seems to work ok for me - at least when I tried with google. But I remember that we have some focus related problems recently.
Here it works. I don't even need to focus the place to paste, the cursor over the widget is enough (FLTK2 v7513).
=x11-libs/fltk-2.0_pre6970 cairo debug doc examples games +jpeg opengl +png threads +xft xinerama +zlib
=www-client/dillo-2.2 doc +gif ipv6 +jpeg +png +ssl
I also use Gentoo (same versions, fltk2 built without cairo), but I'm not experiencing your problem. Does it not paste properly even if you're typing in the form's input box -- ie. if you're sure it has focus? (ie. I assume besides pasting into the address bar, your keystrokes will also go there?)
When you state "focus problems", I would assume you're talking about when fltk/dillo borks on my focus problem and screws up what I'm typing into the focus box -- until I press ctrl+tab (or switch virtual desktops, then switch back again to the dillo virtual desktop).
This sounds ... pertinent :b.
On Fri, Jul 23, 2010 at 08:46:44AM -0400, Dennis Nezic wrote:
On Wed, 21 Jul 2010 10:50:01 -0800, Roger wrote:
On Wed, Jul 21, 2010 at 10:29:32AM -0400, Jorge Arellano Cid wrote:
On Wed, Jul 21, 2010 at 01:29:36PM +0200, Johannes Hofmann wrote:
On Wed, Jul 21, 2010 at 12:48:10AM -0800, Roger wrote:
I think this is already answered within the FAQ, but just in case it isn't, I seem not to be able to copy & paste into form input boxes.
When I do try to "middle mouse button" copy/paste, my output goes into the url entry field of the browser instead of where I intended to paste a form input box.
This seems to work ok for me - at least when I tried with google. But I remember that we have some focus related problems recently.
Here it works. I don't even need to focus the place to paste, the cursor over the widget is enough (FLTK2 v7513).
=x11-libs/fltk-2.0_pre6970 cairo debug doc examples games +jpeg opengl +png threads +xft xinerama +zlib
=www-client/dillo-2.2 doc +gif ipv6 +jpeg +png +ssl
I also use Gentoo (same versions, fltk2 built without cairo), but I'm not experiencing your problem. Does it not paste properly even if you're typing in the form's input box -- ie. if you're sure it has focus? (ie. I assume besides pasting into the address bar, your keystrokes will also go there?)
...even if I'm typing. (See my previous postings on this thread.) I am sure, that I'm am sure, of course I'm sure. Once I left click in the url bar of dillo, I have no problems typing within the url box. (I don't think Dillo/FLTK accepts ctrl-v for pasting.)
When you state "focus problems", I would assume you're talking about when fltk/dillo borks on my focus problem and screws up what I'm typing into the focus box -- until I press ctrl+tab (or switch virtual desktops, then switch back again to the dillo virtual desktop).
This sounds ... pertinent :b.
It sounds relevant, but only a symptom of the problem. This may all get down to the issue of "focus". The url box of dillo always has focus with the mouse. The mouse can click and use Dillo normally. I can use the keyboard to enter form data. But when it gets to copy/paste, the mouse always puts it's copy buffer into the url box. It is completely amazing you use Gentoo as well, and don't see any of these problems. Just prior to wiping and doing a clean install of Gentoo (to reduce bloat -- and the fact I haven't done a clean install in 5+ years), I was seeing the same problems with the mouse copy/paste buffer in Dillo, along with it on my other laptops and computers. After reinstalling on all three systems, I am still seeing this same problem. Would be great to hear the code responsible for this clicking issue so I can try to dump some debug output. FLTK is responsible correct? For what it's worth, here's something from GDB (compiling fltk & dillo with debug flags): (Action -> mouse button paste in google form box) Nav_open_url: new url='Thisisfreesoftware:youarefreetochangeandredistributeit.' Dpi_get_server_port: can't read server port from dpid. ** ERROR **: dpi.c: can't start dpi daemon ... wow... looky all the debug info just flow out GDB! :-/
Here's a quick strace. I'm pretty sure I'm pasting events happening during the mouse copy/paste, just prior to Dillo accepting the input into it's url box. select(4, [3], [], [], NULL) = 1 (in [3]) read(3, "\4\2\2567\224\252\\\0007\3\0\0\4\0\240\0\0\0\0\0P\1-\2O\1\31\2\0\0\1\0", 4096) = 32 read(3, 0x816e880, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(3, 0x816e880, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) writev(3, [{"\30\0\6\0\4\0\240\0\1\0\0\0\4\1\0\0\1\0\0\0\224\252\\\0", 24}, {NULL, 0}, {"", 0}], 3) = 24 read(3, 0x816e880, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(3, 0x816e880, 4096) = -1 EAGAIN (Resource temporarily unavailable) select(4, [3], [], [], NULL) = 1 (in [3]) read(3, "\237\0\2577\224\252\\\0\4\0\240\0\1\0\0\0\4\1\0\0\1\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32 read(3, 0x816e880, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) writev(3, [{"\24\1\6\0\4\0\240\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0", 24}, {NULL, 0}, {"", 0}], 3) = 24 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) read(3, "\1 \2607\6\0\0\0\4\0\0\0\0\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 56 read(3, 0x816e880, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(3, 0x816e880, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) writev(3, [{"\30\1\6\0\4\0\240\0\1\0\0\0\2\1\0\0\1\0\0\0\224\252\\\0", 24}, {NULL, 0}, {"", 0}], 3) = 24 read(3, 0x816e880, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(3, 0x816e880, 4096) = -1 EAGAIN (Resource temporarily unavailable) select(4, [3], [], [], NULL) = 1 (in [3]) read(3, "\237\0\2617\224\252\\\0\4\0\240\0\1\0\0\0\2\1\0\0\1\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32 read(3, 0x816e880, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) writev(3, [{"\24\1\6\0\4\0\240\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0", 24}, {NULL, 0}, {"", 0}], 3) = 24 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) read(3, "\1\10\2627\3\0\0\0\2\1\0\0\0\0\0\0\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 44 read(3, 0x816e880, 4096) = -1 EAGAIN (Resource temporarily unavailable) write(1, "Nav_open_url: new url='http://op"..., 42Nav_open_url: new url='http://openoffice' ) = 42 gettimeofday({1279904679, 371893}, NULL) = 0 clone(child_stack=0xb7327474, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb7327bd8, {entry_number:6, base_addr:0xb7327b70, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb7327bd8) = 13078 read(3, 0x816e880, 4096) = -1 EAGAIN (Resource temporarily unavailable) gettimeofday({1279904679, 372378}, NULL) = 0 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) writev(3, [{";\3\5\0\7\0\240\0\0\0\0\0\22\0.\0\212\2\30\0\226\6\5\0\37\1\240\0\0\0\0\0"..., 16372}, {NULL, 0}, {"", 0}], 3DNS error: HOST_NOT_FOUND Dns_server [0]: openoffice is (nil) ) = 16372 I figure, if strace is catching this, the event is going to be just prior to Nav_open_url. I am seeing a lot of EAGAIN (Resource temporarily unavailable). <shrugs>
AH HA! I spent a little more time in the past few minutes looking over the dillorc file to see if there's something I aimlessly missed option wise. Turns out I seem to have found the issue! This is what I had: # Mouse middle click by default drives drag-scrolling. # To paste an URL into the window instead of scrolling, set it to NO. # Note: You could always paste the URL onto the URL box clear button. middle_click_drags_page=NO I now changed it to: #middle_click_drags_page=NO Reran Dillo and I can now copy/paste into Dillo's web page forms without the output from the copy buffer always going into the Dillo url entry box! If this is the expected behavior of copy/paste when this option is set to "NO", then I'd suggest putting in a warning into the comment area of the dillorc that it will conflict with copy/paste operations when using the mouse middle button. Cheers!
Am Fri, 23 Jul 2010 17:33:37 -0800 schrieb Roger <rogerx@sdf.org>:
I now changed it to: #middle_click_drags_page=NO
Reran Dillo and I can now copy/paste into Dillo's web page forms without the output from the copy buffer always going into the Dillo url entry box!
Uh. That's collateral damage from a change I prompted ... I have to say sorry for actually seeing this misbehaviour but somehow managing not to raise the issue. As the user who wanted the pasting into the general window area to cause loading of an URL, as it happens to work in other browsers, I want to emphasize that I also think that this URL loading should happen only if there was no other sensible area for pasting underneath the cursor. This is how it usually works: Pasting into some form field causes insertion of the text there, pasting without anything special there means pasting to the browser as such, which triggers loading of the text as URL. Is this tricky to achieve with FLTK? I don't have any time to devote to this myself (apart from testing a bit), nor do I have experience with the dillo code. I have hope that it's not seriously complicated, but if the focus management happens to explicitly not anticipate such situations, it might non-trivial. But again, this is how other browsers work -- it would suit dillo to fulfill such basic expectations. Alrighty then, Thomas. PS: Sorry again, for not settling this one earlier...
participants (5)
-
dennisn＠dennisn.dyndns.org -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
rogerx＠sdf.org -
thomas-forum＠orgis.org