Hi, On Fri, May 07, 2010 at 11:45:02PM -0800, rogerx@sdf.org wrote:
I posted to the mailing list sometime ago concerning a bug with Dillo text entry form. After some time, the text entry box in google search box (or on other websites) would only allow certain keys to be typed (ie. s and g, most other keys simply ignored when typed in text entry boxes).
I can reproduce this now, however as you say, I think it just looses focus, so here no keys work at all until I refocus the text input.
I've finally resolved this, or hacked around it to live with it better.
Did you fix some code, or do you just refocus manually?
The bug occurs when a user of the DWM desktop moves Dillo from one virtual window to another virtual window using "Meta key + right mouse click" and the "right mouse click + virtual window number" to move a window to another virtual desktop within DWM.
Once moved to the other window, the text entry box will exhibit the above keyboard entry anomly. Basically, I think it's just loosing focus. The user can get back regular keyboard entry by using "Meta Key + Tab" to toggle focus from the previous desktop and then again to regain focus of the virtual desktop containing Dillo, and should then be able to type normally again. All keys should work.
Again, I think Dillo is just losing focus of the text entry box.. or something similar.
As other fltk2 apps don't show this behaviour we should be able to fix that in dillo, but I don't yet understand fully what is going on. Cheers, Johannes PS: Good to see that there is other dwm + dillo users out there :-)
On Sun, May 09, 2010 at 07:23:38AM +0200, Johannes Hofmann wrote:
Hi,
On Fri, May 07, 2010 at 11:45:02PM -0800, rogerx@sdf.org wrote:
I posted to the mailing list sometime ago concerning a bug with Dillo text entry form. After some time, the text entry box in google search box (or on other websites) would only allow certain keys to be typed (ie. s and g, most other keys simply ignored when typed in text entry boxes).
I can reproduce this now, however as you say, I think it just looses focus, so here no keys work at all until I refocus the text input.
I've finally resolved this, or hacked around it to live with it better.
Did you fix some code, or do you just refocus manually?
The bug occurs when a user of the DWM desktop moves Dillo from one virtual window to another virtual window using "Meta key + right mouse click" and the "right mouse click + virtual window number" to move a window to another virtual desktop within DWM.
Once moved to the other window, the text entry box will exhibit the above keyboard entry anomly. Basically, I think it's just loosing focus. The user can get back regular keyboard entry by using "Meta Key + Tab" to toggle focus from the previous desktop and then again to regain focus of the virtual desktop containing Dillo, and should then be able to type normally again. All keys should work.
Again, I think Dillo is just losing focus of the text entry box.. or something similar.
As other fltk2 apps don't show this behaviour we should be able to fix that in dillo, but I don't yet understand fully what is going on.
If this doesn't happen in other fltk2 apps, then the focus event (or similar) is correctly delivered by the WM and lost in the way by dillo's UI. I'd try to find what events a one-input widget-fltk2-program receives and how it handles it, and then see what happens in dillo. PS: This can be done simply by adding a custom handle() method with some printfs and that calls the old handle(). -- Cheers Jorge.-
On Sun, May 09, 2010 at 09:14:01AM -0400, Jorge Arellano Cid wrote:
On Sun, May 09, 2010 at 07:23:38AM +0200, Johannes Hofmann wrote:
Hi,
On Fri, May 07, 2010 at 11:45:02PM -0800, rogerx@sdf.org wrote:
I posted to the mailing list sometime ago concerning a bug with Dillo text entry form. After some time, the text entry box in google search box (or on other websites) would only allow certain keys to be typed (ie. s and g, most other keys simply ignored when typed in text entry boxes).
I can reproduce this now, however as you say, I think it just looses focus, so here no keys work at all until I refocus the text input.
I've finally resolved this, or hacked around it to live with it better.
Did you fix some code, or do you just refocus manually?
The bug occurs when a user of the DWM desktop moves Dillo from one virtual window to another virtual window using "Meta key + right mouse click" and the "right mouse click + virtual window number" to move a window to another virtual desktop within DWM.
Once moved to the other window, the text entry box will exhibit the above keyboard entry anomly. Basically, I think it's just loosing focus. The user can get back regular keyboard entry by using "Meta Key + Tab" to toggle focus from the previous desktop and then again to regain focus of the virtual desktop containing Dillo, and should then be able to type normally again. All keys should work.
Again, I think Dillo is just losing focus of the text entry box.. or something similar.
As other fltk2 apps don't show this behaviour we should be able to fix that in dillo, but I don't yet understand fully what is going on.
If this doesn't happen in other fltk2 apps, then the focus event (or similar) is correctly delivered by the WM and lost in the way by dillo's UI. I'd try to find what events a one-input widget-fltk2-program receives and how it handles it, and then see what happens in dillo.
I now tried with another wm (twm) and also see the problem there, also with dw-ui-test. If I focus a textinput or textarea, then unfocus the window and focus it again, the textinput has lost focus. I'm not sure if that is really the same problem that rogerx reported, but it is certainly not ok. Are others seeing that behaviour too?
PS: This can be done simply by adding a custom handle() method with some printfs and that calls the old handle().
Tried that a bit, but no luck so far. Cheers, Johannes
Johannes wrote:
I now tried with another wm (twm) and also see the problem there, also with dw-ui-test. If I focus a textinput or textarea, then unfocus the window and focus it again, the textinput has lost focus. I'm not sure if that is really the same problem that rogerx reported, but it is certainly not ok.
Are others seeing that behaviour too?
Yes. (fvwm)
Hi On Sun, 9 May 2010 21:04:27 +0200, Johannes Hofmann <Johannes.Hofmann@gmx.de> wrote:
If I focus a textinput or textarea, then unfocus the window and focus it again, the textinput has lost focus. (...) Are others seeing that behaviour too?
i can confirm this in fluxbox higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946
On Sun, May 09, 2010 at 09:14:01AM -0400, Jorge Arellano Cid wrote:
On Sun, May 09, 2010 at 07:23:38AM +0200, Johannes Hofmann wrote:
Hi,
On Fri, May 07, 2010 at 11:45:02PM -0800, rogerx@sdf.org wrote:
I posted to the mailing list sometime ago concerning a bug with Dillo text entry form. After some time, the text entry box in google search box (or on other websites) would only allow certain keys to be typed (ie. s and g, most other keys simply ignored when typed in text entry boxes).
I can reproduce this now, however as you say, I think it just looses focus, so here no keys work at all until I refocus the text input.
I've finally resolved this, or hacked around it to live with it better.
Did you fix some code, or do you just refocus manually?
The bug occurs when a user of the DWM desktop moves Dillo from one virtual window to another virtual window using "Meta key + right mouse click" and the "right mouse click + virtual window number" to move a window to another virtual desktop within DWM.
Once moved to the other window, the text entry box will exhibit the above keyboard entry anomly. Basically, I think it's just loosing focus. The user can get back regular keyboard entry by using "Meta Key + Tab" to toggle focus from the previous desktop and then again to regain focus of the virtual desktop containing Dillo, and should then be able to type normally again. All keys should work.
Again, I think Dillo is just losing focus of the text entry box.. or something similar.
As other fltk2 apps don't show this behaviour we should be able to fix that in dillo, but I don't yet understand fully what is going on.
If this doesn't happen in other fltk2 apps, then the focus event (or similar) is correctly delivered by the WM and lost in the way by dillo's UI. I'd try to find what events a one-input widget-fltk2-program receives and how it handles it, and then see what happens in dillo.
PS: This can be done simply by adding a custom handle() method with some printfs and that calls the old handle().
I just committed a fix which works for me. Please give it a try and report any focus weirdness. Cheers, Johannes
On Mon, May 10, 2010 at 05:21:14AM +0200, Johannes Hofmann wrote:
On Sun, May 09, 2010 at 09:14:01AM -0400, Jorge Arellano Cid wrote:
On Sun, May 09, 2010 at 07:23:38AM +0200, Johannes Hofmann wrote:
Hi,
On Fri, May 07, 2010 at 11:45:02PM -0800, rogerx@sdf.org wrote:
I posted to the mailing list sometime ago concerning a bug with Dillo text entry form. After some time, the text entry box in google search box (or on other websites) would only allow certain keys to be typed (ie. s and g, most other keys simply ignored when typed in text entry boxes).
I can reproduce this now, however as you say, I think it just looses focus, so here no keys work at all until I refocus the text input.
I've finally resolved this, or hacked around it to live with it better.
Did you fix some code, or do you just refocus manually?
The bug occurs when a user of the DWM desktop moves Dillo from one virtual window to another virtual window using "Meta key + right mouse click" and the "right mouse click + virtual window number" to move a window to another virtual desktop within DWM.
Once moved to the other window, the text entry box will exhibit the above keyboard entry anomly. Basically, I think it's just loosing focus. The user can get back regular keyboard entry by using "Meta Key + Tab" to toggle focus from the previous desktop and then again to regain focus of the virtual desktop containing Dillo, and should then be able to type normally again. All keys should work.
Again, I think Dillo is just losing focus of the text entry box.. or something similar.
As other fltk2 apps don't show this behaviour we should be able to fix that in dillo, but I don't yet understand fully what is going on.
If this doesn't happen in other fltk2 apps, then the focus event (or similar) is correctly delivered by the WM and lost in the way by dillo's UI. I'd try to find what events a one-input widget-fltk2-program receives and how it handles it, and then see what happens in dillo.
PS: This can be done simply by adding a custom handle() method with some printfs and that calls the old handle().
I just committed a fix which works for me. Please give it a try and report any focus weirdness.
It work great here. FWIW, I also noticed the problem with dw-resource-test, and it's fixed now. Kudos! -- Cheers Jorge.-
hi again On Mon, 10 May 2010 05:21:14 +0200, Johannes Hofmann <Johannes.Hofmann@gmx.de> wrote:
I just committed a fix which works for me. Please give it a try and report any focus weirdness.
i'm getting mixed results in fluxbox... sometime it works, others dont... On a dropdown menu, the focus always work, but in a textarea, when i click on it, it works, and i can change the focus to other apps as long as i want without any problem. if i then click again on the textarea, when i change focus to other apps, i lose the textarea focus and will not work again, until i click again on the textarea and gain focus one more time and it will work fine until i click yet another time on the textarea... making it stop working. So odd clicks on the textarea will work, even clicks fail to work ... or was that the inverse!? :) Hope this helps cya higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946
On Mon, May 10, 2010 at 11:23:38PM +0100, higuita wrote:
hi again
On Mon, 10 May 2010 05:21:14 +0200, Johannes Hofmann <Johannes.Hofmann@gmx.de> wrote:
I just committed a fix which works for me. Please give it a try and report any focus weirdness.
i'm getting mixed results in fluxbox... sometime it works, others dont...
On a dropdown menu, the focus always work, but in a textarea, when i click on it, it works, and i can change the focus to other apps as long as i want without any problem.
if i then click again on the textarea, when i change focus to other apps, i lose the textarea focus and will not work again, until i click again on the textarea and gain focus one more time and it will work fine until i click yet another time on the textarea... making it stop working.
So odd clicks on the textarea will work, even clicks fail to work ... or was that the inverse!? :)
Haha, I also see this now - weird. I will look into it.
participants (4)
-
corvid＠lavabit.com -
higuita7＠yahoo.co.uk -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de