August 2011 - Dillo-dev - lists.mailman3.com

Horizontal scrolling with mouse buttons
by jcid＠dillo.org 07 Aug '12

07 Aug '12

On Mon, Aug 15, 2011 at 02:18:33PM -0400, saulgoode(a)flashingtwelve.brickfilms.com wrote: > Quoting Jorge Arellano Cid <jcid(a)dillo.org>: > > > Please try dillo-3.0-pre, following these directions [1]. > >Then report back how it goes. > > > > [1] http://www.dillo.org/source.html > > With that build, the horizontal scroll buttons are inactive. To my > mind this is satisfactory behavior as it does not interfere with the > vertical scrolling of the mouse wheel (previously the only way to > restore vertical wheel scrolling was to restart the program). Good! This looks like an issue with fltk-1.3. FWIW, inside fltk-1.3 src/Fl_x.cxx:1443, there's no code to handle those buttons. Having something like the following may be worth a try (if you're a coder): if (xevent.xbutton.button == Button4) { Fl::e_dy = -1; // Up event = FL_MOUSEWHEEL; } else if (xevent.xbutton.button == Button5) { Fl::e_dy = +1; // Down event = FL_MOUSEWHEEL; + } else if (xevent.xbutton.button == Button6) { + Fl::e_dx = -1; // Left + event = FL_MOUSEWHEEL; + } else if (xevent.xbutton.button == Button7) { + Fl::e_dx = +1; // Right + event = FL_MOUSEWHEEL; } else { Fl::e_state |= (FL_BUTTON1 << (xevent.xbutton.button-1)); event = FL_PUSH; checkdouble(); } > Thank you for your response. :) -- Cheers Jorge.-

3 2

Mouse Wheel 80-90% slower then Seamonkey?
by rogerx.oss＠gmail.com 26 Sep '11

26 Sep '11

Anybody else notice the mouse wheel is slow within Dillo? Comparing dillo_port1.3 to Seamonkey, dillo_port1.3 is almost 80-90% slower compared to Seamonkey. Comparing dillo_port1.3 to dillo, dillo_port1.3 is slower by approx. 50%. -- Roger http://rogerx.freeshell.org/

3 7

dillo-3.0-rc2 is out
by jcid＠dillo.org 16 Sep '11

16 Sep '11

Hi there, After: [ok] moveToWidget(). Jorge has code for this. [ok] downloads dpi string escaping. [ok] alt text wrapping (which looks like a nice feature). [ok] remove large panel. [ok] https dialog storm (BUG#868). [ok] The findbar input doesn't know about Ctrl+{a,e,d,k}. [ok] something other than "ctab%d" for initial tab label. [ok] single close tab button with tooltip. [ok] valgrind logs: close window [ok] valgrind logs: cancel expected url [ok] segfault with Ctrl-s (web search) [ok] UI_TEMPORARILY_SHOW_PANELS [ok] leave link into a native FLTK widget [ok] remove pointeronlink(), panelmode_cb_i() [ok] the panel problems when resizing from very small. [ok] resize problems when tabs overflow [ok] URL_ILLEGAL_CHARS [ok] Fixed CustLightButton "light" color deactivation. [ok] hoverTooltip glitch (tooltip linger when going into a child DIV). [ok] tab overflow (code a handler) [ok] valgrind error for first tab close, then resize(). [ok] update the Changelog [ok] default search engine [ok] new-tab and window title [ok] CSS adjacent sibling selectors [ok] margin-bottom + some margin collapse [ok] fix doctree leak Today the rc2 was packaged. Please get it here: http://dillo.org/download/dillo-3.0-pre.tar.bz2 // tarball http://dillo.org/download/dillo-3.0-pre.tar.bz2.asc // signature The idea is to test the package in different OS/HW-Platforms and to report how the build process went, and how it works. Hopefully it'll become dillo-3.0. Afterall, it has been for a long enough time in testing phase. TIA for your feedback. -- Last but not the least: [ok] valgrind logs: cancel expected url I can't reproduce this anymore (after the committed fix). If somebody can still reproduce it, please report it. Details are in this thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008810.html (the "expected url" is the one you've asked for but whose data bytes haven't started to arrive. If during this period of time you stop the request --e.g. by pressing Stop or clicking another URL, it's cancelled--). -- Cheers Jorge.-

9 29

dillo close dialog and fluxbox on dual head
by higuita7＠yahoo.co.uk 08 Sep '11

08 Sep '11

Hi i dont know if this is a problem with dillo or with fluxbox, but when i try to close a dillo with several tabs, i get always the close dialog (title is Choice5) on my secondary X11 head. If i try to setup fluxbox to force the dialog to open on head 1, it still opens on head 2. if i do the same thing for all other dillo dialogs, like open file, search (title ask), etc , i fluxbox puts the window in the configured head. If i try to set the position and head, fluxbox puts the dialog in the right position, but in the wrong head. If i try to run the fltk-1.3/test/message test, i can setup the head of those messages without any problem. i'm using the latest dillo3 "hg version" with the latest fltk1.3 svn , running on a slackware64 with Fluxbox 1.3.1 and a dual head setup. The main head (1) is right, secondary head (2) is left. They are setup with xrandr on a ati r600 card: xrandr --output DVI-0 --auto --primary --dpi 96 --output VGA-0 --left-of DVI-0 --auto --dpi 96 xrandr --output DVI-0 --primary --set underscan off As dillo is the only app i found with this problem, and even other dillo windows work fine, i suspect something in dillo3 or in fltk1.3 that is forcing the Choice5 dialog to stay on head 2... probably just because is on the left (so closer to the 0,0 X11 virtual display corner), instead of using the virtual position of each head. What you think? should i open a bug in fluxbox, in fltk or is this a dillo problem? Thanks in advance for the help and thanks for dillo 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

3 8

valgrind still unhappy despite expect changes
by jcid＠dillo.org 02 Sep '11

02 Sep '11

On Sun, Aug 28, 2011 at 06:53:54PM +0000, corvid wrote: > > I can't reproduce this with valgrind-3.6.1 on wheezy. > > > > No valgrind error report before or after these debug messages: > > > > a_Nav_cancel_expect_if_eq:: calling a_Nav_cancel_expect > > Dillo: normal exit! > > > > I tested by pushing a remote URL on CLI and closing the window > > before the page data starts flowing (i.e. to cancel the > > "expect"), and also with the cancelled download code path. > > Neither one produced an error. > > I saw that there was another log entry the other day > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > Do you think something sneaky could be going on, or does it seem > like it must come down to configuration differences somehow? AFAIS, either one is possible... Me not being able to reproduce it says it's most probably be OK for the codepaths I tested (FWIW, the ones I can see). If there's an untested codepath, well... OTOH, valgrind produces some false positives (its docs say it) and gcc optimization can also play a role... So, I'd try to find a simple test case that produces the log. Then, test this problematic codepath here, and see what comes out of the exercise. Can you reproduce the bug? Do you have a simple test case? -- Cheers Jorge.-

4 16

valgrind doctree leak
by corvid＠lavabit.com 28 Aug '11

28 Aug '11

(from Jeremy's logs) ==2186== 928 (32 direct, 896 indirect) bytes in 1 blocks are definitely lost in loss record 815 of 958 ==2186== at 0x40275CC: operator new(unsigned int) (vg_replace_malloc.c:255) ==2186== by 0x806E258: Doctree::push() (doctree.hh:67) ==2186== by 0x806C1FC: StyleEngine::startElement(int) (styleengine.cc:93) ==2186== by 0x8076DB8: Html_process_tag(DilloHtml*, char*, int) (html.cc:3507) ==2186== by 0x8077A33: Html_write_raw(DilloHtml*, char*, int, int) (html.cc:3822) ==2186== by 0x8070543: DilloHtml::write(char*, int, int) (html.cc:552) ==2186== by 0x80775BD: Html_callback(int, _CacheClient*) (html.cc:3725) ==2186== by 0x80627AD: Cache_process_queue (cache.c:1195) ==2186== by 0x80629A2: Cache_delayed_process_queue_callback (cache.c:1260) ==2186== by 0x40C0876: Fl::wait(double) (in /usr/lib/libfltk.so.1.3) ==2186== by 0x40C0A30: Fl::run() (in /usr/lib/libfltk.so.1.3) ==2186== by 0x804F08A: main (dillo.cc:436)

2 1

problems with very long alt text
by jcid＠dillo.org 28 Aug '11

28 Aug '11

On Fri, Aug 26, 2011 at 07:29:21PM +0200, hiro wrote: > With tinycorelinux and Xorg-7.5 i915 on 1024x768 I get a completely > garbled screen and unresponsive system, CPU ran hot and I had to > reboot. > I can reboot into VESA if you want. [later hiro wrote:] > Ok I don't get the bug with Xvesa, tinycorelinux' default Xserver. Excellent! This proves the point (AFAICS). Thank you very much. -- Cheers Jorge.-

1 1

margin-bottom counted twice
by johannes.hofmann＠gmx.de 27 Aug '11

27 Aug '11

Hi, I found that current dillo uses twice the given margin-bottom: value. See attached margin_bottom.html. It is related to commented out code in textblock.cc. Attached patch tries to fix it while not breaking the test cases in http://www.dillo.org/test/img/ I'm not 100% sure about removing the "if" in Textblock::wordWrap(), but why shouldn't a widget's top margin count in the first line of a paragraph? Cheers, Johannes

4 5

What's pending for RC2
by jcid＠dillo.org 26 Aug '11

26 Aug '11

Hi there, So far we have: [ok] moveToWidget(). Jorge has code for this. [ok] downloads dpi string escaping. [ok] alt text wrapping (which looks like a nice feature). [ok] remove large panel. [ok] https dialog storm (BUG#868). [ok] The findbar input doesn't know about Ctrl+{a,e,d,k}. [ok] something other than "ctab%d" for initial tab label. [ok] single close tab button with tooltip. [ok] valgrind logs: close window [ok] valgrind logs: cancel expected url [ok] segfault with Ctrl-s (web search) [ok] UI_TEMPORARILY_SHOW_PANELS [ok] leave link into a native FLTK widget [ok] remove pointeronlink(), panelmode_cb_i() [ok] the panel problems when resizing from very small. [ok] resize problems when tabs overflow [ok] URL_ILLEGAL_CHARS [ok] Fixed CustLightButton "light" color deactivation. [ok] hoverTooltip glitch (tooltip linger when going into a child DIV). [ok] tab overflow (code a handler) [ok] valgrind error for first tab close, then resize(). [ok] update the Changelog [ ] default search engine [ ] new-tab and window title [ ] CSS adjacent sibling selectors I'd like to comment some: [ok] tab overflow (code a handler) Please send feedback on how it works. Remember that polish and eye candy was left for the next release. [ok] update the Changelog Corvid and Johannes may have some pending items to add. BTW, at this point the Changelog has a summary of user-visible changes, which reduces clutter given that the full history is in hg. Please vote. me: +1 on keeping it this way. [ ] default search engine I've been using search_url="http://duckduckgo.com/lite/?kp=-1&q=%s" and it works quite well for me. Please vote. me: +1 for making it the default Also I'd like to add some default search engines. For instance, this one is very useful for me: search_url="Free Dictionary http://www.thefreedictionary.com/%s" Comments/suggestions? [ ] new-tab and window title This is a simple deatail that I'll look into quickly. [ ] CSS adjacent sibling selectors Johannes has to decide on this. -- Cheers Jorge.-

3 3

problems with very long alt text
by corvid＠lavabit.com 26 Aug '11

26 Aug '11

With remote stylesheets off and images off, opening http://www.dillo.org/test/long_alt_text.html and dragging the horizontal scrollbar left and right for a little while will make my machine suddenly start to page madly. from what I could see from valgrind and top, nothing looked amiss in dillo or X, but even after dillo can finally close (if it can), too many resources are tied up somehow and I need to restart X to have a really usable system. I changed the alt text back to using drawText(), and it didn't matter much that I could see. I tried using a width of 16K instead of the 25K or so that was the real value. This didn't seem to help either.

6 17