- Dillo-dev - lists.mailman3.com

Commands on Dillo

by marcos-escola＠outlook.com

Hi; I'm not sure if this happens only on my device, but, I can't Copy and Paste in Dillo (3.0.2 and 3.0.5). There is a way to enable this commands, or it's going to be available in a future version? Thanks; Marcos D. Twitter: @marcos_5000

April 21, 2016

Dillo_grows merged

by nick＠linicks.net

On 18/04/16 17:16, Sebastian Geerken wrote: > Hi! > > The dillo_grows repository has just been merged into the main > repository at <http://hg.dillo.org/dillo>. > > Hopefully, this will mean that all these changes will soon make it > into a new release. OK, with a few of the *fixes* in place, I can't believe that Dillo could get any faster ~ but it does! Great job, thank you! Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

April 19, 2016

Dillo_grows merged

by nick＠linicks.net

On 18/04/16 20:34, higuita wrote: > On Mon, 18 Apr 2016 17:45:54 +0100, Nick Warne <nick at linicks.net> wrote: >> The forums previously mentioned still get stuck at the front with no >> scrolling available: >> >> http://forums.thinkbroadband.com > > This one, if we disable embedded CSS, it will revert back to the > old style Thanks! I am a fool for not thinking to try that. OK, dillo-dev can be used and tested by me at least :) Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

April 19, 2016

Dillo_grows merged

by nick＠linicks.net

On 18/04/16 21:10, Sebastian Geerken wrote: > On Mon, Apr 18, 2016, higuita wrote: >> On Mon, 18 Apr 2016 17:45:54 +0100, Nick Warne <nick at linicks.net> wrote: >> > The forums previously mentioned still get stuck at the front with no >> > scrolling available: >> > >> > http://forums.thinkbroadband.com >> >> This one, if we disable embedded CSS, it will revert back to the >> old style > > If you put the line > > div, table { height: auto !important } > > into ~/.dillo/style.css, then both <http://forums.thinkbroadband.com> > and <https://linicks.net/AnAdIc/> will be rendered as by dillo 3.0.5. > > This is not a solution, of course, but shows the root of the problem. > Actually, it may be an option to turn of CSS `height` for some > elements (for which dillo 3.0.5 does not support `height`) and work on > this issue for the release after 3.1. OK, great. The other solution for the broadband forums is even better - so good stuff. Thanks! Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

April 19, 2016

Dillo_grows merged

by johannes.hofmann＠gmx.de

On Mon, Apr 18, 2016 at 10:16:48PM +0200, Sebastian Geerken wrote: > On Mo, Apr 18, 2016, Johannes Hofmann wrote: > > the Google issue can be reproduced with > > > > <div> > > <div style="float:left;display:inline-block">dillo</div> > > <div style="float:left;display:inline-block">dillo</div> > > <div style="float:left;display:inline-block">dillo</div> > > </div> > > > > which did render one block next to the other in dillo 3.0.5 and > > now renders each block below each other. > > Yes, floats are always positioned one below the other, never side by > side, as most other browsers do. I've plans to implement the latter, > but is is nothing to be done for the short term. > > It is interesting that dillo 3.0.5 shows them side by side (actually > like an inline element), although `display:inline-block` is not > supported before 3.1. Is there some workaround? inline-block was treated as inline in dillo 3.0.5 which happens to look "ok" for the google case. Johannes

April 19, 2016

Dillo_grows merged

by eocene＠gmx.com

Here's a segfault backtrace that I just got: #0 0x080ab83d in dw::Textblock::sizeRequestReference (this=0x955e260, index=-1224641713) at textblock.cc:423 #1 0x080bcd63 in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::numParts ( this=0x9e446a8, sectionIndex=-1, numContentsInFlow=0) at oofawarewidget_iterator.cc:84 #2 0x080bcc0e in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::OOFAwareWidgetIterator (this=0x9e446a8, widget=0x9484458, mask=108, atEnd=true, numContentsInFlow=0) at oofawarewidget_iterator.cc:46 #3 0x080b40a3 in dw::Textblock::TextblockIterator::TextblockIterator ( this=0x9e446a8, textblock=0x9484458, mask=108, atEnd=true) at textblock_iterator.cc:36 #4 0x080ad18a in dw::Textblock::iterator (this=0x9484458, mask=108, atEnd=true) at textblock.cc:1172 #5 0x080d092f in dw::core::DeepIterator::prev (this=0x923c848) at iterator.cc:711 #6 0x080d099f in dw::core::DeepIterator::prev (this=0x923c848) at iterator.cc:723 #7 0x080d0dc6 in dw::core::CharIterator::prev (this=0x9e446d8) at iterator.cc:825 #8 0x080cf0ab in dw::core::FindtextState::search0 (this=0x91554fc, backwards=true, firstTrial=false) at findtext.cc:273 #9 0x080ceaf8 in dw::core::FindtextState::search (this=0x91554fc, key=0x94e9dd0 "rows ", caseSens=false, backwards=true) at findtext.cc:113 #10 0x0805aa01 in dw::core::Layout::search (this=0x9155430, str=0x94e9dd0 "rows ", caseSens=false, backwards=1) at ../dw/layout.hh:431 #11 0x0805a703 in a_UIcmd_findtext_search (bw=0x91550a0, key=0x94e9dd0 "rows ", case_sens=0, backward=1) at uicmd.cc:1484 #12 0x08090973 in Findbar::searchBackwards_cb (vfb=0x914afa8) at findbar.cc:100 #13 0xb75e8500 in Fl_Widget::do_callback(Fl_Widget*, void*) () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #14 0xb7592d33 in Fl_Button::handle(int) () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #15 0x08052f03 in TipWinButton::handle (this=0x9154dd8, e=12) at tipwin.cc:158 #16 0x08053070 in CustButton::handle (this=0x9154dd8, e=12) at tipwin.cc:194 #17 0xb75a29b4 in ?? () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #18 0xb75a3256 in Fl_Group::handle(int) () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #19 0x08090eae in Findbar::handle (this=0x914afa8, event=12) at findbar.cc:192 #20 0xb75a29b4 in ?? () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #21 0xb75a3256 in Fl_Group::handle(int) () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #22 0x08055b2d in UI::handle (this=0x914d698, event=12) at ui.cc:790 #23 0xb758a62b in ?? () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #24 0xb758b732 in Fl::handle_(int, Fl_Window*) () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #25 0xb758b9bc in Fl::handle(int, Fl_Window*) () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #26 0xb758b75f in Fl::handle_(int, Fl_Window*) () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #27 0xb758b9bc in Fl::handle(int, Fl_Window*) () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #28 0xb75edd40 in fl_handle(_XEvent const&) () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #29 0xb75ef486 in ?? () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #30 0xb75ef6b6 in fl_wait(double) () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #31 0xb758c567 in Fl::wait(double) () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #32 0xb758c6de in Fl::run() () from /usr/lib/i386-linux-gnu/libfltk.so.1.3 #33 0x08052443 in main (argc=1, argv=0xbff0d434) at dillo.cc:578

April 19, 2016

Dillo_grows merged

by sgeerken＠dillo.org

On Mo, Apr 18, 2016, Johannes Hofmann wrote: > the Google issue can be reproduced with > > <div> > <div style="float:left;display:inline-block">dillo</div> > <div style="float:left;display:inline-block">dillo</div> > <div style="float:left;display:inline-block">dillo</div> > </div> > > which did render one block next to the other in dillo 3.0.5 and > now renders each block below each other. Yes, floats are always positioned one below the other, never side by side, as most other browsers do. I've plans to implement the latter, but is is nothing to be done for the short term. It is interesting that dillo 3.0.5 shows them side by side (actually like an inline element), although `display:inline-block` is not supported before 3.1. Is there some workaround? Sebastian

April 18, 2016

Dillo_grows merged

by sgeerken＠dillo.org

On Mon, Apr 18, 2016, higuita wrote: > On Mon, 18 Apr 2016 17:45:54 +0100, Nick Warne <nick at linicks.net> wrote: > > The forums previously mentioned still get stuck at the front with no > > scrolling available: > > > > http://forums.thinkbroadband.com > > This one, if we disable embedded CSS, it will revert back to the > old style If you put the line div, table { height: auto !important } into ~/.dillo/style.css, then both <http://forums.thinkbroadband.com> and <https://linicks.net/AnAdIc/> will be rendered as by dillo 3.0.5. This is not a solution, of course, but shows the root of the problem. Actually, it may be an option to turn of CSS `height` for some elements (for which dillo 3.0.5 does not support `height`) and work on this issue for the release after 3.1. Sebastian

April 18, 2016

Dillo_grows merged

by Johannes.Hofmann＠gmx.de

the Google issue can be reproduced with <div> <div style="float:left;display:inline-block">dillo</div> <div style="float:left;display:inline-block">dillo</div> <div style="float:left;display:inline-block">dillo</div> </div> which did render one block next to the other in dillo 3.0.5 and now renders each block below each other. Cheers, Johannes

April 18, 2016

Dillo_grows merged

by higuita7＠yahoo.co.uk

On Mon, 18 Apr 2016 17:45:54 +0100, Nick Warne <nick at linicks.net> wrote: > The forums previously mentioned still get stuck at the front with no > scrolling available: > > http://forums.thinkbroadband.com This one, if we disable embedded CSS, it will revert back to the old style 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

April 18, 2016