- Dillo-dev - lists.mailman3.com

patch: widget scrolling

by place＠gobigwest.com

I've had lots of trouble with widgets disappearing because my machine is too slow to keep up. But today I had the good fortune to happen to stumble upon updateCanvasWidgets()... Johannes, are there any unintended consequences to this fix?

March 28, 2008

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by onepoint＠starurchin.org

On Fri, Mar 28, 2008 at 09:57:10AM -0400, Jorge Arellano Cid wrote: > > On Wed, Mar 26, 2008 at 10:23:48PM +0000, Jeremy Henty wrote: > > > > If the page contains a meta tag that changes the Content-Type then > > Dillo re-opens the URL. This calls Layout::removeWidget(), which > > in turn calls Layout::setAnchor(NULL). Ouch! If the URL > > contained a fragment then the anchor is lost. Worse, the anchor > > doesn't get restored because the URL is flagged as "just > > reloading" before it is reopened. The result is that the anchor > > mysteriously stops working. > > > > Commenting out the call to Layout::setAnchor(NULL) in > > Layout::removeWidget() fixes the bug and doesn't seem to break > > anything else, but I'm not convinced it's the right thing to do. > > In fact, repush is an after thought, and some parts of nav also > need some re-work. The API, IIRC pushing #fragment URLs to the stack > has some anomalies too. It'd be good to find/design a single path to > handle it (experience shows multiple paths is asking for trouble :). > I've looked at it and it seems like deep analysis is required. Thanks for explaining this. I'll keep running with Layout::setAnchor(NULL) commented out for the moment and see how it goes. (Still no breakage yet.) I hope to be able to spend time looking at this further. If I have any thoughts about a good way to do all this I will post them. Unfortunately I have had to devote more time to earning a living recently (sigh) so I've spent less time looking at Dillo code than I would have liked. Regards, Jeremy Henty

March 28, 2008

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by jcid＠dillo.org

Hi Jeremy, On Wed, Mar 26, 2008 at 10:23:48PM +0000, Jeremy Henty wrote: > > OK, I've figured out the problem and (as usual) my first thoughts were > completely wrong. I'm not sure what the fix is, though. > > If the page contains a meta tag that changes the Content-Type then > Dillo re-opens the URL. This calls Layout::removeWidget(), which in > turn calls Layout::setAnchor(NULL). Ouch! If the URL contained a > fragment then the anchor is lost. Worse, the anchor doesn't get > restored because the URL is flagged as "just reloading" before it is > reopened. The result is that the anchor mysteriously stops working. > > Commenting out the call to Layout::setAnchor(NULL) in > Layout::removeWidget() fixes the bug and doesn't seem to break > anything else, but I'm not convinced it's the right thing to do. If > it's not then I don't know what is: I already tried tweaking things so > that the reload goes down the same code path as the initial load, but > that just caused crashes everywhere. > > I'd really like to fix this as it regularly breaks pages for me, but I > don't know the code well enough to sure I've got it right. Thanks for all the information. In fact, repush is an after thought, and some parts of nav also need some re-work. The API, IIRC pushing #fragment URLs to the stack has some anomalies too. It'd be good to find/design a single path to handle it (experience shows multiple paths is asking for trouble :). I've looked at it and it seems like deep analysis is required. I'm reviewing a few patches now. I'll work on it again when I find some time. -- Cheers Jorge.-

March 28, 2008

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by onepoint＠starurchin.org

OK, I've figured out the problem and (as usual) my first thoughts were completely wrong. I'm not sure what the fix is, though. If the page contains a meta tag that changes the Content-Type then Dillo re-opens the URL. This calls Layout::removeWidget(), which in turn calls Layout::setAnchor(NULL). Ouch! If the URL contained a fragment then the anchor is lost. Worse, the anchor doesn't get restored because the URL is flagged as "just reloading" before it is reopened. The result is that the anchor mysteriously stops working. Commenting out the call to Layout::setAnchor(NULL) in Layout::removeWidget() fixes the bug and doesn't seem to break anything else, but I'm not convinced it's the right thing to do. If it's not then I don't know what is: I already tried tweaking things so that the reload goes down the same code path as the initial load, but that just caused crashes everywhere. I'd really like to fix this as it regularly breaks pages for me, but I don't know the code well enough to sure I've got it right. Jeremy Henty

March 26, 2008

ComplexButton crashing

by place＠gobigwest.com

Johannes wrote: > Ahh, now I understand. layout is a new layout specific to the > button. It is created in ComplexButton::init (). > So the purpose of ComplexButton is to create buttons that can have arbitrary > HTML rendered on them. > > I wonder if we really need to duplicate the button code from fltk > for this. > > For now I think your fix is good. Perhaps we can make the whole > stuff simpler in the future. > > Did you already manage to add an dw::Image to a ComplexButton? Yes. The two problems that remained were: Small images were only visible when the control panel was not visible. The recurring problem of dw's idea of offsets being different than that of fltk. And big images were usually (but not always -- some timing thing) offset inside their buttons by an amount that seemed to depend on the size of the alt text.

March 26, 2008

ComplexButton crashing

by Johannes.Hofmann＠gmx.de

On Wed, Mar 26, 2008 at 04:42:16PM +0000, place wrote: > Johannes wrote: > > place wrote: > > > In FltkComplexButtonResource::createNewWidget, the button's child is a view. > > > When the button is destroyed, since the button is a Group, its children > > > get destroyed. > > > Later on, the layout is being destroyed, and it deletes TopLevel. > > > The toplevel widget destructor calls layout->removeWidget(), which tries > > > to iterate through the views. > > > > Ok I'm just trying to understand the ComplexButton button stuff > > - rather good class name btw :-) > > Why is there a view as child of the button? > > What is this view supposed to display? > > I have no idea whether it's necessary. Maybe the layout in the button > doesn't get shown otherwise? > > > Anyway, first I'd suggest: > > > > diff -r f1f343e2c024 dw/fltkui.cc > > --- a/dw/fltkui.cc Tue Mar 18 18:05:51 2008 +0100 > > +++ b/dw/fltkui.cc Wed Mar 26 16:57:13 2008 +0100 > > @@ -423,13 +423,15 @@ > > if (!relief) > > button->box(::fltk::FLAT_BOX); > > > > - button->begin (); > > lastFlatView = > > new FltkFlatView (allocation->x + reliefXThickness (), > > allocation->y + reliefYThickness (), > > allocation->width - 2 * reliefXThickness (), > > allocation->ascent + allocation->descent > > - 2 * reliefYThickness ()); > > + > > + button->add (lastFlatView); > > + > > if (layout) > > layout->attachView (lastFlatView); > > return button; > > > > > > > > because this begin () / end () stuff is rather ugly, especially if > > the matching end () is missing. > > Yes! At first, without the end(), I assumed the begin() was extraneous. > > > Sounds reasonable, but I'd really like to understand that > > ComplexButton stuff first. Is there something in doc/ I did not see? > > How did you know it is supposed to be used for image inputs? > > In dw/ui.hh, it says > > * <tr><td>image <td>dw::core::ui::ComplexButtonResource > * <td>dw::core::ui::ResourceFactory::createComplexButtonResource, > * width a dw::Image inside and relief = false. > Ahh, now I understand. layout is a new layout specific to the button. It is created in ComplexButton::init (). So the purpose of ComplexButton is to create buttons that can have arbitrary HTML rendered on them. I wonder if we really need to duplicate the button code from fltk for this. For now I think your fix is good. Perhaps we can make the whole stuff simpler in the future. Did you already manage to add an dw::Image to a ComplexButton? Cheers, Johannes

March 26, 2008

patch: URL data as a Dstr

by place＠gobigwest.com

This is part one in a series for file inputs. Parts two and three are written. Parts four and five are contemplated. Maybe a part six if I feel like it. Part three is the one that makes it at least appear to work, though I'll need help in testing at that point. HTTPS note: If https does remain a dpi, somebody will have to decide what they want to do with Capi_dpi_build_cmd() if http_query can contain NULLs.

March 26, 2008

ComplexButton crashing

by place＠gobigwest.com

Johannes wrote: > place wrote: > > In FltkComplexButtonResource::createNewWidget, the button's child is a view. > > When the button is destroyed, since the button is a Group, its children > > get destroyed. > > Later on, the layout is being destroyed, and it deletes TopLevel. > > The toplevel widget destructor calls layout->removeWidget(), which tries > > to iterate through the views. > > Ok I'm just trying to understand the ComplexButton button stuff > - rather good class name btw :-) > Why is there a view as child of the button? > What is this view supposed to display? I have no idea whether it's necessary. Maybe the layout in the button doesn't get shown otherwise? > Anyway, first I'd suggest: > > diff -r f1f343e2c024 dw/fltkui.cc > --- a/dw/fltkui.cc Tue Mar 18 18:05:51 2008 +0100 > +++ b/dw/fltkui.cc Wed Mar 26 16:57:13 2008 +0100 > @@ -423,13 +423,15 @@ > if (!relief) > button->box(::fltk::FLAT_BOX); > > - button->begin (); > lastFlatView = > new FltkFlatView (allocation->x + reliefXThickness (), > allocation->y + reliefYThickness (), > allocation->width - 2 * reliefXThickness (), > allocation->ascent + allocation->descent > - 2 * reliefYThickness ()); > + > + button->add (lastFlatView); > + > if (layout) > layout->attachView (lastFlatView); > return button; > > > > because this begin () / end () stuff is rather ugly, especially if > the matching end () is missing. Yes! At first, without the end(), I assumed the begin() was extraneous. > Sounds reasonable, but I'd really like to understand that > ComplexButton stuff first. Is there something in doc/ I did not see? > How did you know it is supposed to be used for image inputs? In dw/ui.hh, it says * <tr><td>image <td>dw::core::ui::ComplexButtonResource * <td>dw::core::ui::ResourceFactory::createComplexButtonResource, * width a dw::Image inside and relief = false. PS I subscribed to the list under a new address, but my first msg is still awaiting moderator approval, so the old address lives on a bit longer...

March 26, 2008

ComplexButton crashing

by Johannes.Hofmann＠gmx.de

On Thu, Mar 20, 2008 at 03:12:15PM +0000, place wrote: > For you dw people... > I am working on getting ComplexButton to work (image inputs), Great! > and it would segfault when I'd close the bw. > > In FltkComplexButtonResource::createNewWidget, the button's child is a view. > When the button is destroyed, since the button is a Group, its children > get destroyed. > Later on, the layout is being destroyed, and it deletes TopLevel. > The toplevel widget destructor calls layout->removeWidget(), which tries > to iterate through the views. Ok I'm just trying to understand the ComplexButton button stuff - rather good class name btw :-) Why is there a view as child of the button? What is this view supposed to display? Anyway, first I'd suggest: diff -r f1f343e2c024 dw/fltkui.cc --- a/dw/fltkui.cc Tue Mar 18 18:05:51 2008 +0100 +++ b/dw/fltkui.cc Wed Mar 26 16:57:13 2008 +0100 @@ -423,13 +423,15 @@ if (!relief) button->box(::fltk::FLAT_BOX); - button->begin (); lastFlatView = new FltkFlatView (allocation->x + reliefXThickness (), allocation->y + reliefYThickness (), allocation->width - 2 * reliefXThickness (), allocation->ascent + allocation->descent - 2 * reliefYThickness ()); + + button->add (lastFlatView); + if (layout) layout->attachView (lastFlatView); return button; because this begin () / end () stuff is rather ugly, especially if the matching end () is missing. > > To make the problem go away, I added: > fltkcomplexbutton.hh: ~ComplexButton() {remove_all();} > but I don't know any of this code well enough to know what _should_ > be going on. Sounds reasonable, but I'd really like to understand that ComplexButton stuff first. Is there something in doc/ I did not see? How did you know it is supposed to be used for image inputs? Cheers, Johannes

March 26, 2008

removeIdle: *** [unknown] This should not happen! *** Aborted

by jcid＠dillo.org

On Tue, Mar 25, 2008 at 07:10:57PM +0100, Johannes Hofmann wrote: > On Thu, Mar 20, 2008 at 07:44:52PM +0000, place wrote: > > I think I mentioned this problem some time ago, but playing with > > ComplexButton makes it much worse (when meta charset causes a repush). > > > > The backtrace shows that it's unhappy because IdleFunc doesn't have an equals(). > > > > To make the problem go away, I changed the remove in FltkPlatform::removeIdle() > > to a removeRef, but, again, I don't know this code well enough to know what > > should be going on. > > > > #0 0x40344c81 in kill () from /lib/libc.so.6 > > #1 0x401b04a1 in pthread_kill () from /lib/libpthread.so.0 > > #2 0x401b087b in raise () from /lib/libpthread.so.0 > > #3 0x403448f8 in raise () from /lib/libc.so.6 > > #4 0x40345f00 in abort () from /lib/libc.so.6 > > #5 0x0809e054 in misc::assertNotReached () at misc.hh:67 > > #6 0x080ad6f1 in object::Object::equals (this=0x81ab118, other=0x81ab118) > > at object.cc:49 > > #7 0x080aa182 in container::untyped::List::remove0 (this=0x81c1b90, > > element=0x81ab118, compare=true, doNotDeleteAtAll=false) > > at container.cc:254 > > #8 0x080891c7 in container::untyped::List::remove (this=0x81c1b90, > > element=0x81ab118) at ../lout/container.hh:169 > > #9 0x080891eb in container::typed::List<dw::fltk::FltkPlatform::IdleFunc>::remo > > ve (this=0x81c1960, element=0x81ab118) at ../lout/container.hh:376 > > #10 0x08086968 in dw::fltk::FltkPlatform::removeIdle (this=0x81c1b68, idleId=1) > > at fltkplatform.cc:319 > > #11 0x0809feaa in ~Layout (this=0x81c1bf8) at layout.cc:117 > > > > > > As far as I can see it should be removeRef () here, as you > suggest. While looking at it, I found a buglet in layout.cc. Committed both. -- Cheers Jorge.-

March 26, 2008