- Dillo-dev - lists.mailman3.com

[bug]: CSS image crash

by onepoint＠starurchin.org

Johannes Hofmann wrote: > ... I made a test case > (http://www.dillo.org/css_compat/tests/border-color.html) and it > looks wrong when compared e.g. with firefox, so I guess it's a typo. That is very convincing. I find that changing the drawBorderFoo() functions to use only the foo color fixes the crash *and* gives the same results as Firefox. <charlie_sheen>BI-WINNING!!!</charlie_sheen> I withdraw the previous patch and attach a new one. Thanks for the test case. Regards, Jeremy Henty

March 24, 2011

[bug]: CSS image crash

by Johannes.Hofmann＠gmx.de

On Wed, Mar 23, 2011 at 10:10:35PM +0000, Jeremy Henty wrote: > > Johannes Hofmann wrote: > > > To me the references to style->borderColor.top in drawBorder*() > > other than drawBorderTop() look like a typo, > > I thought so too at first but it's less simple than I realised. The > challenge is rendering borders in fancy styles. Check out the > examples[1]. It is not obvious to me how to choose the right colors. > > The CSS spec does not help[2] - it leaves the choice of colors up to > the user agent. It gives informal descriptions of the border styles > but they really just say "it must look how it should obviously look". Yeah, I also remember something like that, but I made a test case (http://www.dillo.org/css_compat/tests/border-color.html) and it looks wrong when compared e.g. with firefox, so I guess it's a typo. Regards, Johannes

March 24, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

Johannes Hofmann wrote: > To me the references to style->borderColor.top in drawBorder*() > other than drawBorderTop() look like a typo, I thought so too at first but it's less simple than I realised. The challenge is rendering borders in fancy styles. Check out the examples[1]. It is not obvious to me how to choose the right colors. The CSS spec does not help[2] - it leaves the choice of colors up to the user agent. It gives informal descriptions of the border styles but they really just say "it must look how it should obviously look". Regards, Jeremy Henty [1] http://www.dillo.org/css_compat/tests/border-style.html [2] http://www.w3.org/TR/CSS2/box.html - search for "8.5.3 Border style:"

March 23, 2011

[bug]: CSS image crash

by Johannes.Hofmann＠gmx.de

On Tue, Mar 22, 2011 at 04:04:06PM +0000, Jeremy Henty wrote: > > OK, patch attached. Please comment. I just added checks for a NULL > borderColor.top where necessary. I am still not sure if the > drawBorder* functions are doing exactly the right thing but at the > least the patch stops the crash and I don't think it makes the > behaviour any worse. > > Please comment, To me the references to style->borderColor.top in drawBorder*() other than drawBorderTop() look like a typo, but I might be wrong. Jorge, can you please have a look? Cheers, Johannes

March 23, 2011

Test case for a possible fltk1.3 bug

by jcid＠dillo.org

On Wed, Mar 23, 2011 at 03:25:24PM +0000, Jeremy Henty wrote: > Jorge Arellano Cid wrote: > > > AFAIS, by now dillo_port1.3 branch is as usable (or better) as > > fltk2-based dillo. :-) > > Is there going to be another release of dillo-fltk2? Most probably yes. AFAIS there's not much of a point in making it _right now_, as FLTK2 will not be released. I believe a good time to make a dillo-fltk2 release is just after fltk-1.3 is released. That way we can inform users we'll be developing the fltk-1.3-based branch, and point them to the new repo. The big news is that once FLTK-1.3 is released, it will make its way into distros, making dillo accessible via package manager at some not-too-distant point in time. -- Cheers Jorge.-

March 23, 2011

Test case for a possible fltk1.3 bug

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > AFAIS, by now dillo_port1.3 branch is as usable (or better) as > fltk2-based dillo. :-) Is there going to be another release of dillo-fltk2? Regards, Jeremy Henty

March 23, 2011

Test case for a possible fltk1.3 bug

by jcid＠dillo.org

On Tue, Mar 22, 2011 at 04:29:05PM -0300, Jorge Arellano Cid wrote: > On Mon, Mar 21, 2011 at 09:23:37PM +0100, Johannes Hofmann wrote: > > On Mon, Mar 21, 2011 at 08:20:07PM +0100, Johannes Hofmann wrote: > > > Hi Jorge, > > > > > > On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote: > > > > Hi there, > > > > > > > > Please help me with this one. > > > > > > > > Attached goes a small program that shows what may be a bug in > > > > fltk-1.3: > > > > > > > > * resize the window back and forth and both "Group 1" and > > > > "Group 2" keep their heights. OK here. > > > > * With a small window, hide "Group 2" and resize to a big > > > > window, then show "Group 2". It grew while hidden!? > > > > > > > > > > > > My doubts are: > > > > > > > > Is this intended or a bug? > > > > If not a bug, how is the desired behaviour suppossed to be > > > > implemented? > > > > > > > > > > > > I know an ugly way to workaround it (used with the findbar), > > > > but, if it's a bug, I'd prefer to have it fixed, and to keep > > > > the code clean. > > > > > > > > What do you think? > > > > > > Your test program shows even weirder behaviour with dwm here. > > > Initially the buttons are not visible and then scale in strange > > > ways. > > > I think this is because dwm is resizing the window as it is created. > > > > > > I suggest we don't use Fl_Pack and make our own solution. I will try > > > to get something running. > > > > Please check the attached modified version of your test program. > > Does the CustPack class solve your problem? > > It's quite similar to current CustGroup, the good news is that > resizing the hidden widgets to 0,0 avoids Fl_Group resizing them > later! Now we don't have to remove/re-add them to the group. > > This may be our workaround (not as hackish as current code). I > was thinking of fullscreen mode, and having to remove groups of > widgets to avoid the hidden resize. > > I'll forward the email to Matthias Melcher, because I still > can't believe the current resize behaviour is intended. Yesterday I wrote Matthias Melcher, and he told me he was going to review the issue. In the meanwhile (which can be long) I just committed a simple patch to make fullscreen work again (it uses the size(0,0) trick) AFAIS, by now dillo_port1.3 branch is as usable (or better) as fltk2-based dillo. :-) -- Cheers Jorge.-

March 23, 2011

Test case for a possible fltk1.3 bug

by jcid＠dillo.org

On Mon, Mar 21, 2011 at 09:23:37PM +0100, Johannes Hofmann wrote: > On Mon, Mar 21, 2011 at 08:20:07PM +0100, Johannes Hofmann wrote: > > Hi Jorge, > > > > On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > Please help me with this one. > > > > > > Attached goes a small program that shows what may be a bug in > > > fltk-1.3: > > > > > > * resize the window back and forth and both "Group 1" and > > > "Group 2" keep their heights. OK here. > > > * With a small window, hide "Group 2" and resize to a big > > > window, then show "Group 2". It grew while hidden!? > > > > > > > > > My doubts are: > > > > > > Is this intended or a bug? > > > If not a bug, how is the desired behaviour suppossed to be > > > implemented? > > > > > > > > > I know an ugly way to workaround it (used with the findbar), > > > but, if it's a bug, I'd prefer to have it fixed, and to keep > > > the code clean. > > > > > > What do you think? > > > > Your test program shows even weirder behaviour with dwm here. > > Initially the buttons are not visible and then scale in strange > > ways. > > I think this is because dwm is resizing the window as it is created. > > > > I suggest we don't use Fl_Pack and make our own solution. I will try > > to get something running. > > Please check the attached modified version of your test program. > Does the CustPack class solve your problem? It's quite similar to current CustGroup, the good news is that resizing the hidden widgets to 0,0 avoids Fl_Group resizing them later! Now we don't have to remove/re-add them to the group. This may be our workaround (not as hackish as current code). I was thinking of fullscreen mode, and having to remove groups of widgets to avoid the hidden resize. I'll forward the email to Matthias Melcher, because I still can't believe the current resize behaviour is intended. -- Cheers Jorge.-

March 22, 2011

Test case for a possible fltk1.3 bug

by jcid＠dillo.org

On Mon, Mar 21, 2011 at 09:23:37PM +0100, Johannes Hofmann wrote: > On Mon, Mar 21, 2011 at 08:20:07PM +0100, Johannes Hofmann wrote: > > Hi Jorge, > > > > On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > Please help me with this one. > > > > > > Attached goes a small program that shows what may be a bug in > > > fltk-1.3: > > > > > > * resize the window back and forth and both "Group 1" and > > > "Group 2" keep their heights. OK here. > > > * With a small window, hide "Group 2" and resize to a big > > > window, then show "Group 2". It grew while hidden!? > > > > > > > > > My doubts are: > > > > > > Is this intended or a bug? > > > If not a bug, how is the desired behaviour suppossed to be > > > implemented? > > > > > > > > > I know an ugly way to workaround it (used with the findbar), > > > but, if it's a bug, I'd prefer to have it fixed, and to keep > > > the code clean. > > > > > > What do you think? > > > > Your test program shows even weirder behaviour with dwm here. > > Initially the buttons are not visible and then scale in strange > > ways. > > I think this is because dwm is resizing the window as it is created. > > > > I suggest we don't use Fl_Pack and make our own solution. I will try > > to get something running. > > Please check the attached modified version of your test program. > Does the CustPack class solve your problem? Thanks for the code, I'll check it. I also had to resort to a superclass for horizontal groups in the UI (see rearrange()) BTW, I wrote to Michael Sweet (got no answer so far), because I can't believe something so simple as hidding a widget can be as convoluted as it is now. -- Cheers Jorge.-

March 22, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

OK, patch attached. Please comment. I just added checks for a NULL borderColor.top where necessary. I am still not sure if the drawBorder* functions are doing exactly the right thing but at the least the patch stops the crash and I don't think it makes the behaviour any worse. Please comment, Regards, Jeremy Henty

March 22, 2011