- Dillo-dev - lists.mailman3.com

Re: Bug in Dillo Text Entry

by higuita7＠yahoo.co.uk

hi again On Mon, 10 May 2010 05:21:14 +0200, Johannes Hofmann <Johannes.Hofmann(a)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

May 11, 2010

Re: Bug in Dillo Text Entry

by jcid＠dillo.org

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(a)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.-

May 10, 2010

Re: Bug in Dillo Text Entry

by Johannes.Hofmann＠gmx.de

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(a)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

May 10, 2010

Re: Bug in Dillo Text Entry

by higuita7＠yahoo.co.uk

Hi On Sun, 9 May 2010 21:04:27 +0200, Johannes Hofmann <Johannes.Hofmann(a)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

May 10, 2010

Re: Bug in Dillo Text Entry

by corvid＠lavabit.com

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)

May 9, 2010

Re: Bug in Dillo Text Entry

by Johannes.Hofmann＠gmx.de

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(a)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

May 9, 2010

setting image buffer and queueing resize

by jcid＠dillo.org

On Sun, May 09, 2010 at 07:34:29AM +0200, Johannes Hofmann wrote: > On Wed, Apr 28, 2010 at 05:21:56PM +0000, corvid wrote: > > I had just fixed the dw simple image test that hadn't requested a > > resize when setting the imgbuf. And now I just found that one of the > > scaled2 test's images needs it as well. > > > > Perhaps we should make the resize argument to setBuffer() mandatory. > > > > But, better yet, how about if Image::setBuffer() just does a queueResize() if > > either of its dimensions are LENGTH_AUTO? > > I also think we should get rid of the resize parameter of > setBuffer() entirely. > I'm not 100% sure about when we need the queueResize(), that would > need some testing. AFAIR the main idea is to queueResize() whenever a widget changes it size. That way several widgets can make the call and the resize process is done only once when the time arrives. BTW, I'm not oppossed at all in eliminating the resize parameter, but haven't looked at it in enough depth to assign any weight to my opinnion on the subject. ;-) -- Cheers Jorge.-

May 9, 2010

Re: Bug in Dillo Text Entry

by jcid＠dillo.org

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(a)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.-

May 9, 2010

setting image buffer and queueing resize

by Johannes.Hofmann＠gmx.de

On Wed, Apr 28, 2010 at 05:21:56PM +0000, corvid wrote: > I had just fixed the dw simple image test that hadn't requested a > resize when setting the imgbuf. And now I just found that one of the > scaled2 test's images needs it as well. > > Perhaps we should make the resize argument to setBuffer() mandatory. > > But, better yet, how about if Image::setBuffer() just does a queueResize() if > either of its dimensions are LENGTH_AUTO? I also think we should get rid of the resize parameter of setBuffer() entirely. I'm not 100% sure about when we need the queueResize(), that would need some testing.

May 9, 2010

Re: Bug in Dillo Text Entry

by Johannes.Hofmann＠gmx.de

Hi, On Fri, May 07, 2010 at 11:45:02PM -0800, rogerx(a)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 :-)

May 9, 2010