- Dillo-dev - lists.mailman3.com

Problem with page positioning.

by james.from.wellington＠gmail.com

I kept thinking about this, and I think I have some unimplementable poetry for a correct behaviour, and some implementable prose that would do as a substitute. The poetry is: whatever the user is attending to: after the re-render, it should be in the same place on the screen. It's unimplementable because: - we don't know where in the rectangle the user is attending - different parts of the rectangle can move in different directions -- eg folding up navigation links into a side-bar - parts of the rectangle can be forced to move horizontally, in ways that we would not be able to cancel out with scrolling The prose is: however far the (top of the) page is displaced from the anchor position, after the re-render, the top of page should be displaced by the same amount from the new anchor position. Do people think that this prose is a reasonable version of correctness? Regards, James. On 28/02/2015, James C <james.from.wellington at gmail.com> wrote: > Peripheral to the original issue, preserving smooth behavour of a form > across a re-render would be an interesting (possibly in a slightly > hair-pull way) problem. > > The content of fields, cursor position, and keystrokes received during > the re-render, would all have to be preserved. > > I'm not volunteering. > > Regards, > James. > > On 27/02/2015, John Found <johnfound at asm32.info> wrote: >> On Thu, 26 Feb 2015 22:34:45 +0100 >> Andreas Kemnade <andreas at kemnade.info> wrote: >> >>> So a blank screen is your preferred way to fill out forms or should I >>> rather wait some minutes before starting to work on the page? I do not >>> understand your logic. >> >> Waiting for the CSS prior to rendering the page, does not forbid >> switching >> CSS off, as you described. Both features can co-exists without any >> conflict. >> >> My logic is that if the CSS files loads so slow as you describe (I still >> think it is a very, very rare case that can not rule the whole design), >> it >> is not important whether the rendering will happen twice or once - the >> page >> still will be not usable at all and you will need to disable CSS in order >> to >> get some usability at all. Notice, that nothing changes for your >> mentioned >> site, but on the normal, fast web sites, the screen flicker will be >> removed >> at all. >> >> >> -- >> http://fresh.flatassembler.net >> http://asm32.info >> John Found <johnfound at asm32.info> >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev at dillo.org >> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >> >

March 6, 2015

Dillo documentation delivered daily

by eocene＠gmx.com

Jeremy wrote: > My website is up again[1] Great! It's good to hear from you again... > and I have added a daily build of the Dillo > documentation (having noticed that the version on the Dillo site is > over a year old). > > HTML: http://starurchin.org/dillo/doc/html/index.html > tarball: http://starurchin.org/dillo/doc/dillo-doc.tar.gz > > (Note that the tarball has moved from its old location.) Will update links. > Doxygen generates quite a few errors when building the docs. I would > like to fix them (if only to have less noise from my cron jobs). > Would the Dillo devs be interested in the patches? Even though I haven't been dealing with doxygen stuff myself, I would certainly presume so.

March 4, 2015

Dillo documentation delivered daily

by onepoint＠starurchin.org

My website is up again[1] and I have added a daily build of the Dillo documentation (having noticed that the version on the Dillo site is over a year old). HTML: http://starurchin.org/dillo/doc/html/index.html tarball: http://starurchin.org/dillo/doc/dillo-doc.tar.gz (Note that the tarball has moved from its old location.) Doxygen generates quite a few errors when building the docs. I would like to fix them (if only to have less noise from my cron jobs). Would the Dillo devs be interested in the patches? Regards Jeremy Henty [1] Nginx spontaneously decided not to run until I tweaked its configuration. No idea why, but at least it is fixed.

March 4, 2015

a different lines->getRef() segfault

by james.from.wellington＠gmail.com

This page: http://www.3news.co.nz/nznews/fantasy-football-match-marks-christmas-truce-… reliably (under my conditions of delay) exercises the findLineIndexWhenAllocated assertion. On 22/01/2015, James C <james.from.wellington at gmail.com> wrote: > This, on commit 553bbaa, may be a dup or related. > > It was exercised by loading this: > http://www.inkcartridges.co.nz/brother-hl5350dn-laser-printer > > (On OSX 10.6.8, as is usual from me.) > > Regards, > James. > > =================== > > Assertion failed: (wasAllocated ()), function > findLineIndexWhenAllocated, file textblock.cc, line 1634. > > Program received signal SIGABRT, Aborted. > 0x00007fff82c490b6 in __kill () > (gdb) bt > #0 0x00007fff82c490b6 in __kill () > #1 0x00007fff82ce99f6 in abort () > #2 0x00007fff82cd69bc in __assert_rtn () > #3 0x00000001000647bc in dw::Textblock::findLineIndexWhenAllocated > (this=0x11dc7f200, y=0) at textblock.cc:1634 > #4 0x0000000100069a63 in dw::Textblock::draw (this=0x11dc7f200, > view=0x11dc7f7c0, area=0x7fff5fbfd3b0) at textblock.cc:1791 > #5 0x000000010008c4a9 in dw::core::Layout::draw (this=0x11dc7f9c0, > view=0x11dc7f7c0, area=0x7fff5fbfd4a0) at layout.cc:696 > #6 0x0000000100083ef1 in dw::core::Layout::expose (this=0x11dc7f9c0, > view=0x11dc7f7c0, area=0x7fff5fbfd4a0) at layout.hh:317 > #7 0x0000000100083652 in dw::fltk::FltkViewBase::draw > (this=0x11dc7f7c0, rect=0x7fff5fbfd510, > type=dw::fltk::FltkViewBase::DRAW_CLIPPED) at fltkviewbase.cc:174 > #8 0x0000000100083843 in dw::fltk::FltkViewBase::draw > (this=0x11dc7f7c0) at fltkviewbase.cc:126 > #9 0x00000001000bc529 in Fl_Widget::clear_damage () at > /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:772 > #10 0x00000001000bc529 in Fl_Group::draw_child (this=<value > temporarily unavailable, due to optimizations>, widget=@0x11dc7f7c8) > at Fl_Group.cxx:773 > #11 0x0000000100074334 in dw::fltk::ui::ComplexButton::draw > (this=0x11dc7f710) at fltkcomplexbutton.cc:53 > #12 0x00000001000bc529 in Fl_Widget::clear_damage () at > /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:772 > #13 0x00000001000bc529 in Fl_Group::draw_child (this=<value > temporarily unavailable, due to optimizations>, widget=@0x11dc7f710) > at Fl_Group.cxx:773 > #14 0x0000000100081e25 in dw::fltk::FltkWidgetView::drawFltkWidget > (this=0x102230a60, widget=0x11dc7f710, area=0x7fff5fbfd730) at > fltkviewbase.cc:731 > #15 0x000000010007a553 in dw::fltk::ui::FltkResource::draw > (this=0x11dc7f640, view=0x102230a60, area=0x7fff5fbfd730) at > fltkui.cc:230 > #16 0x000000010007eedb in > dw::fltk::ui::FltkSpecificResource<dw::core::ui::ComplexButtonResource>::draw > (this=0x11dc7f5e0, view=0x102230a60, area=0x7fff5fbfd730) at > fltkui.cc:329 > #17 0x0000000100099da0 in dw::core::ui::Embed::draw (this=0x11dc7fcc0, > view=0x102230a60, area=0x7fff5fbfd730) at ui.cc:137 > #18 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dc7ed10, > line=0x11dc7ddd0, view=0x102230a60, area=0x7fff5fbfd860) at > textblock.cc:1569 > #19 0x0000000100069abd in dw::Textblock::draw (this=0x11dc7ed10, > view=0x102230a60, area=0x7fff5fbfd860) at textblock.cc:1799 > #20 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dca0f10, > line=0x11dc7f0b0, view=0x102230a60, area=0x7fff5fbfd990) at > textblock.cc:1569 > #21 0x0000000100069abd in dw::Textblock::draw (this=0x11dca0f10, > view=0x102230a60, area=0x7fff5fbfd990) at textblock.cc:1799 > #22 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dc4d460, > line=0x11dca1730, view=0x102230a60, area=0x7fff5fbfda90) at > textblock.cc:1569 > #23 0x0000000100069abd in dw::Textblock::draw (this=0x11dc4d460, > view=0x102230a60, area=0x7fff5fbfda90) at textblock.cc:1799 > #24 0x0000000100061446 in dw::Table::draw (this=0x11dc183f0, > view=0x102230a60, area=0x7fff5fbfdb20) at table.cc:383 > #25 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dc17fd0, > line=0x11dca90e0, view=0x102230a60, area=0x7fff5fbfdc50) at > textblock.cc:1569 > #26 0x0000000100069abd in dw::Textblock::draw (this=0x11dc17fd0, > view=0x102230a60, area=0x7fff5fbfdc50) at textblock.cc:1799 > #27 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dc48cf0, > line=0x10059c490, view=0x102230a60, area=0x7fff5fbfdd80) at > textblock.cc:1569 > #28 0x0000000100069abd in dw::Textblock::draw (this=0x11dc48cf0, > view=0x102230a60, area=0x7fff5fbfdd80) at textblock.cc:1799 > #29 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dca8410, > line=0x10243a560, view=0x102230a60, area=0x7fff5fbfdeb0) at > textblock.cc:1569 > #30 0x0000000100069abd in dw::Textblock::draw (this=0x11dca8410, > view=0x102230a60, area=0x7fff5fbfdeb0) at textblock.cc:1799 > #31 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dca7c70, > line=0x11dca8030, view=0x102230a60, area=0x7fff5fbfdfe0) at > textblock.cc:1569 > #32 0x0000000100069abd in dw::Textblock::draw (this=0x11dca7c70, > view=0x102230a60, area=0x7fff5fbfdfe0) at textblock.cc:1799 > #33 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dca5e70, > line=0x11dca7e60, view=0x102230a60, area=0x7fff5fbfe0e0) at > textblock.cc:1569 > #34 0x0000000100069abd in dw::Textblock::draw (this=0x11dca5e70, > view=0x102230a60, area=0x7fff5fbfe0e0) at textblock.cc:1799 > #35 0x0000000100061446 in dw::Table::draw (this=0x11dcf4460, > view=0x102230a60, area=0x7fff5fbfe170) at table.cc:383 > #36 0x0000000100069738 in dw::Textblock::drawLine (this=0x10235e1c0, > line=0x11dc64c30, view=0x102230a60, area=0x7fff5fbfe2c0) at > textblock.cc:1569 > #37 0x0000000100069abd in dw::Textblock::draw (this=0x10235e1c0, > view=0x102230a60, area=0x7fff5fbfe2c0) at textblock.cc:1799 > #38 0x000000010008c4a9 in dw::core::Layout::draw (this=0x1022a7170, > view=0x102230a60, area=0x7fff5fbfe3b0) at layout.cc:696 > #39 0x0000000100083ef1 in dw::core::Layout::expose (this=0x1022a7170, > view=0x102230a60, area=0x7fff5fbfe3b0) at layout.hh:317 > #40 0x0000000100083652 in dw::fltk::FltkViewBase::draw > (this=0x102230a60, rect=0x7fff5fbfe420, > type=dw::fltk::FltkViewBase::DRAW_CLIPPED) at fltkviewbase.cc:174 > #41 0x0000000100083843 in dw::fltk::FltkViewBase::draw > (this=0x102230a60) at fltkviewbase.cc:126 > #42 0x0000000100084d53 in dw::fltk::FltkViewport::draw_area > (data=0x102230a60, x=0, y=44, w=1185, h=636) at fltkviewport.cc:187 > #43 0x0000000100084f63 in dw::fltk::FltkViewport::draw > (this=0x102230a60) at fltkviewport.cc:213 > #44 0x00000001000bc529 in Fl_Widget::clear_damage () at > /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:772 > #45 0x00000001000bc529 in Fl_Group::draw_child (this=<value > temporarily unavailable, due to optimizations>, widget=@0x102230a68) > at Fl_Group.cxx:773 > #46 0x00000001000bd631 in Fl_Group::draw_children (this=0x10225a6a0) > at Fl_Group.cxx:728 > #47 0x00000001000bc529 in Fl_Widget::clear_damage () at > /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:772 > #48 0x00000001000bc529 in Fl_Group::draw_child (this=<value > temporarily unavailable, due to optimizations>, widget=@0x10225a6a0) > at Fl_Group.cxx:773 > #49 0x00000001000bc529 in Fl_Group::draw_child (this=<value > temporarily unavailable, due to optimizations>, widget=@0x10053c4a0) > at Fl_Group.cxx:772 > #50 0x00000001000bd631 in Fl_Group::draw_children (this=0x10053d9f0) > at Fl_Group.cxx:728 > #51 0x00000001000ddc40 in Fl_Window::draw (this=0x10053d9f0) at > Fl_Window_shape.cxx:369 > #52 0x00000001000a862e in Fl_X::flush (this=0x1024119a0) at > Fl_cocoa.mm:2499 > #53 0x00000001000a8703 in -[FLView drawRect:] (self=0x102214ea0, > _cmd=<value temporarily unavailable, due to optimizations>, > rect={origin = {x = 0, y = 0}, size = {width = 1200, height = 700}}) > at Fl_cocoa.mm:2028 > #54 0x00007fff8901acc5 in -[NSView _drawRect:clip:] () > #55 0x00007fff89019938 in -[NSView > _recursiveDisplayAllDirtyWithLockFocus:visRect:] () > #56 0x00007fff8901800a in -[NSView > _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] > () > #57 0x00007fff890143de in -[NSView > _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] > () > #58 0x00007fff8918ee77 in -[NSView displayIfNeededIgnoringOpacity] () > #59 0x00000001000a8685 in Fl_X::flush (this=0x1024119a0) at > Fl_cocoa.mm:2509 > #60 0x00000001000aff1f in Fl_Widget::clear_damage () at > /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:762 > #61 0x00000001000aff1f in Fl::flush () at Fl.cxx:762 > #62 0x00000001000ad23c in fl_mac_flush_and_wait (time_to_wait=0) at > Fl_cocoa.mm:812 > #63 0x00000001000b0025 in Fl::run () at Fl.cxx:589 > #64 0x00000001000044c5 in main (argc=1, argv=0x7fff5fbff3f8) at > dillo.cc:588 > (gdb) > > > On 20/01/2015, eocene <eocene at gmx.com> wrote: >> >> A new page was just coming in -- seems like the same sort of problem as >> last time. >> >> (gdb) bt >> #0 0xb77bb424 in __kernel_vsyscall () >> #1 0xb72f9661 in *__GI_raise (sig=6) >> at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 >> #2 0xb72fca92 in *__GI_abort () at abort.c:92 >> #3 0xb72f2878 in *__GI___assert_fail ( >> assertion=0x8151afe "i >= 0 && this->num - i > 0", >> file=0x8151aee "../lout/misc.hh", line=167, >> function=0x8151ba0 "T* lout::misc::SimpleVector<T>::getRef(int) const >> [with T = dw::Textblock::Line]") at assert.c:81 >> #4 0x080a9040 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( >> this=0x953b618, i=-1) at ../lout/misc.hh:167 >> #5 0x080a2786 in dw::Textblock::sendSelectionEvent (this=0x916c610, >> eventType=dw::core::SelectionState::BUTTON_RELEASE, event=0xbfbb8180) >> at textblock.cc:1093 >> #6 0x080a24c3 in dw::Textblock::buttonReleaseImpl (this=0x916c610, >> event=0xbfbb8180) at textblock.cc:1008 >> #7 0x080d8910 in dw::core::Widget::buttonRelease (this=0x916c610, >> event=0xbfbb8180) at widget.cc:1027 >> #8 0x080cd617 in dw::core::Layout::processMouseEvent (this=0x90fc058, >> event=0xbfbb8180, type=dw::core::Layout::BUTTON_RELEASE) at >> layout.cc:1234 >> #9 0x080cd00e in dw::core::Layout::buttonEvent (this=0x90fc058, >> type=dw::core::Layout::BUTTON_RELEASE, view=0x90f9f60, numPressed=1, >> x=127, y=180, state=0, button=1) at layout.cc:1023 >> #10 0x080c46ae in dw::core::Layout::buttonRelease (this=0x90fc058, >> view=0x90f9f60, numPressed=1, x=127, y=180, state=0, button=1) >> at layout.hh:345 >> #11 0x080c33f7 in dw::fltk::FltkViewBase::handle (this=0x90f9f60, >> event=2) >> at fltkviewbase.cc:319 >> #12 0x080c5e8a in dw::fltk::FltkViewport::handle (this=0x90f9f60, >> event=2) >> at fltkviewport.cc:331 >> #13 0x080ded22 in send(int, Fl_Widget*, Fl_Window*) () >> #14 0x080dfbaf in Fl::handle_(int, Fl_Window*) () >> #15 0x080dff0e in Fl::handle(int, Fl_Window*) () >> #16 0x08107e9d in fl_handle(_XEvent const&) () >> #17 0x08107fbc in do_queued_events() () >> #18 0x0810822a in fl_wait(double) () >> #19 0x080e08af in Fl::wait(double) () >> #20 0x080e099d in Fl::run() () >> #21 0x08052f7a in main (argc=1, argv=0xbfbb8854) at dillo.cc:588 >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev at dillo.org >> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >> >

March 2, 2015

what's currently broken in dillo

by james.from.wellington＠gmail.com

I'm not sure when it started, but I'm getting this: [dpip]: [Dpip_dsh_write] Broken pipe [dpip]: [Dpip_dsh_write] Broken pipe [dpip]: [Dpip_dsh_write] Broken pipe [dpip]: [Dpip_dsh_write] Broken pipe [cookies dpi]: (pid 27897): Got DpiBye. [cookies dpi]: Cookies saved: 0. [cookies dpi]: cleanup [dpid]: terminated normally (0) with no obvious preamble. I'm running the hack-up that I sent to the list, with a new parser for dpidrc, which prevents it from timing out on the normal time-scale. Regards, James. On 15/02/2015, eocene <eocene at gmx.com> wrote: > > from my notes. I think all of this was mentioned on list: > > > --local ... reload turns off URL_SpamSafe, but there it is again upon > repush. > > >> I found that shift+arrows in the url bar is doing nothing instead >> of selecting the text. Ctrl+shift+arrows work fine. > > > dd search url not removed when dillorc has search urls. > > > background image oddities Jan 15 > > > jan 17 edge.org page > > > parbreak issue > > > another lines->getRef segfault > > > Jorge's slashdot hang > > > the interlaced gif on forum.thinkpads.com > > > feb 10 news.sciencemag.org hangs > > > As for speed, I'd spent enough time with dillo being pretty slow before > those optimizations were made in the past month or two that I've somewhat > lost my feel for how fast dillo is supposed to be... > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Feb. 28, 2015

Problem with page positioning.

by james.from.wellington＠gmail.com

Peripheral to the original issue, preserving smooth behavour of a form across a re-render would be an interesting (possibly in a slightly hair-pull way) problem. The content of fields, cursor position, and keystrokes received during the re-render, would all have to be preserved. I'm not volunteering. Regards, James. On 27/02/2015, John Found <johnfound at asm32.info> wrote: > On Thu, 26 Feb 2015 22:34:45 +0100 > Andreas Kemnade <andreas at kemnade.info> wrote: > >> So a blank screen is your preferred way to fill out forms or should I >> rather wait some minutes before starting to work on the page? I do not >> understand your logic. > > Waiting for the CSS prior to rendering the page, does not forbid switching > CSS off, as you described. Both features can co-exists without any > conflict. > > My logic is that if the CSS files loads so slow as you describe (I still > think it is a very, very rare case that can not rule the whole design), it > is not important whether the rendering will happen twice or once - the page > still will be not usable at all and you will need to disable CSS in order to > get some usability at all. Notice, that nothing changes for your mentioned > site, but on the normal, fast web sites, the screen flicker will be removed > at all. > > > -- > http://fresh.flatassembler.net > http://asm32.info > John Found <johnfound at asm32.info> > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Feb. 28, 2015

Problem with page positioning.

by johnfound＠asm32.info

On Thu, 26 Feb 2015 22:34:45 +0100 Andreas Kemnade <andreas at kemnade.info> wrote: > So a blank screen is your preferred way to fill out forms or should I rather wait some minutes before starting to work on the page? I do not understand your logic. Waiting for the CSS prior to rendering the page, does not forbid switching CSS off, as you described. Both features can co-exists without any conflict. My logic is that if the CSS files loads so slow as you describe (I still think it is a very, very rare case that can not rule the whole design), it is not important whether the rendering will happen twice or once - the page still will be not usable at all and you will need to disable CSS in order to get some usability at all. Notice, that nothing changes for your mentioned site, but on the normal, fast web sites, the screen flicker will be removed at all. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 26, 2015

Problem with page positioning.

by eocene＠gmx.com

Andreas wrote: > Forms are disabled so that you cannot enter data when there is still css to load. So I have to disable CSS if I do not want to wait ages in theese cases. BTW: What was the reason for that behaviour? Here's the relevant thread: http://lists.dillo.org/pipermail/dillo-dev/2009-April/006310.html

Feb. 26, 2015

Problem with page positioning.

by andreas＠kemnade.info

Hi, On Thu, 26 Feb 2015 21:03:18 +0200 John Found <johnfound at asm32.info> wrote: > > well, that depends on the situation and available bandwidth, In many cases I even disabled the css because I wanted to use some forms before css is loaded. I prefer the way it is now. > > Your logic is wrong here. If the current implementation is fine, you should not disable CSS, but you could work on these forms on the first rendered screen (without CSS) and to continue to work transparently when the page refreshes after the CSS get Forms are disabled so that you cannot enter data when there is still css to load. So I have to disable CSS if I do not want to wait ages in theese cases. BTW: What was the reason for that behaviour? > loaded. Your need to disable CSS proves exactly my theory: The first, fast, CSS-less rendering is useless at all and only provides screen flickering. So a blank screen is your preferred way to fill out forms or should I rather wait some minutes before starting to work on the page? I do not understand your logic. As you write in your other mail, some more intelligent solution might help, like wait 2 seconds and if css is not there, display what is displayable, so no flickering with good internet connection and no site problems. Greetings Andreas Kemnade

Feb. 26, 2015

Problem with page positioning.

by johnfound＠asm32.info

On Thu, 26 Feb 2015 19:39:54 +0100 Andreas Kemnade <andreas at kemnade.info> wrote: > well, that depends on the situation and available bandwidth, In many cases I even disabled the css because I wanted to use some forms before css is loaded. I prefer the way it is now. Your logic is wrong here. If the current implementation is fine, you should not disable CSS, but you could work on these forms on the first rendered screen (without CSS) and to continue to work transparently when the page refreshes after the CSS get loaded. Your need to disable CSS proves exactly my theory: The first, fast, CSS-less rendering is useless at all and only provides screen flickering. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 26, 2015