May 2010 - Dillo-dev - lists.mailman3.com

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

Re: commit 3e01d83fd6d1 draws too large background box

by Johannes.Hofmann＠gmx.de

Hi, sorry for the delay... On Tue, Apr 27, 2010 at 11:40:11PM +0200, Johannes Hofmann wrote: > On Tue, Apr 27, 2010 at 09:04:49PM +0000, corvid wrote: > > > commit 3e01d83fd6d1 (draw background for all Words, not just text) > > > draws a too large background box e.g. in this example: > > > > > > <html><body> > > > foo <div style="background-color: blue; margin-top: 100px">bar</div> > > > </body></html> > > > > > > The margin should not be blue. > > > What is the reason for this change anyway? Shouldn't each widget be > > > responsible for it's drawing (including the background)? > > > > This is when I was looking at the rectangles of color on the fltk.org > > page around, e.g., "FLTK Apps", "FLTK Library"... > > > > The rectangle of color (which came from the style of the A element, iirc) > > is "supposed" to be taller than the little rounded-corner images, judging > > by what firefox does. > > Ah, I think I see the problem now. Textblock has to draw the > background for the <A> element - even at places where it is covered > by child widgets, as they might be transparent. > On the other hand margins are always transparent (see > http://www.w3.org/TR/CSS2/box.html) so there is a problem in the > current implementation. > I guess I need some time to think about this. > > > > > So if the margin is part of the child, then... > > how should this be disentangled? > > Does it come down to being one of those things that have to wait until > > we have more of a real box model? > > > > We already have a proper box model for block boxes, what we are missing > is proper handling of inline boxes (e.g. drawing borders around > <a>-elements). Ok, the general problem is that a single Textblock widget can handle multiple HTML elements. E.g. in this case: <a href=foo style="background-color: red">foo <b>bar</b></a> there is just a single Textblock drawing the whole thing. The style of the word "bar" would normally not have a background color set, but the red of the <a> element would shine through, but as the textblock simply draws one word after the other, we do not draw the whole <a> element and then draw the <b> element on top. To make the background color work nevertheless, I had introduced the inheritBackgroundColor hack, which will pass the red background to the style of the child element (<b> in this case). However, this hack does not work properly if the child element has a margin: <a href=foo style="background-color: red">foo <img src=foo.png alt=bar style="margin:1em"></a> So I think we should remove the whole inheritBackgroundColor() hack and replace it with some code in textblock.cc, that draws the proper background color for all words as necessary. We need to be careful though to not draw word backgrounds if they are the same color as the whole textblock to avoid excessive drawing. This would still not allow things like: <b style="border: 1px solid black">foo</b> but I currently don't see a simple way to make that work. Cheers, Johannes

May 9, 2010

[rogerx@sdf.org: Bug in Dillo Text Entry]

by jcid＠dillo.org

-- Cheers Jorge.-

May 8, 2010