- Dillo-dev - lists.mailman3.com

[patch] Scrollbar thickness from dillorc

by corvid＠lavabit.com

podarcis wrote: > Scrollbars currently have the hardcoded thickness 15. This can be too > small to operate dillo on large screens or with fingers on a touch > screen. > > The supplied patch does the following: > > - Adds the prefence "scrollbar_tickness" to dillorc. > > - Reads the value into the prefences > (Note: added a type UINT32 to prefsparse.cc) > > - Sets this value to the FltkViewport with the new > method FltkViewport::setScrollbarThickness(). > > Note: I deliberately did no check for value 0, which can therefore be > used to make the scrollbars invisible. Scrolling can then still be > achieved with the cursor keys. This could be called a feature. Just curious whether you've experimented with incorporating Fl::scrollbar_size() into this. Aside: A few years ago, there was a little bit of discussion now and then about improving the UI for touch, but unfortunately it would all die down without us getting much further than "Hmm, that's an interesting idea..."

Jan. 20, 2013

[patch] Scrollbar thickness from dillorc

by podarcis＠lavabit.com

Scrollbars currently have the hardcoded thickness 15. This can be too small to operate dillo on large screens or with fingers on a touch screen. The supplied patch does the following: - Adds the prefence "scrollbar_tickness" to dillorc. - Reads the value into the prefences (Note: added a type UINT32 to prefsparse.cc) - Sets this value to the FltkViewport with the new method FltkViewport::setScrollbarThickness(). Note: I deliberately did no check for value 0, which can therefore be used to make the scrollbars invisible. Scrolling can then still be achieved with the cursor keys. This could be called a feature. Cheers, podarcis

Jan. 20, 2013

drawing highlighting

by corvid＠lavabit.com

For highlighting in a single word:

Jan. 19, 2013

[patch] disable SSLv2 support

by Johannes.Hofmann＠gmx.de

On Fri, Jan 18, 2013 at 01:57:49AM +0400, p37sitdu at lavabit.com wrote: > http://www.inventati.org/noname/dillo/https-no-SSLv2.patch > > I have found HTTPS server that Dillo was unable to connect to. > > After defining SILENT to 0 in https.c I found that SSL_connect > failed. Adding ERR_print_errors_fp(stderr) showed error > "SSL23_GET_SERVER_HELLO:unknown protocol". > > Disabling SSLv2 support fixed the problem for me. And SSLv2 is > insecure so it must be disabled anyway. committed! Thanks, Johannes

Jan. 18, 2013

[patch] dWrite

by p37sitdu＠lavabit.com

http://www.inventati.org/noname/dillo/dwrite.patch Removed Dpi_blocking_write from src/IO/dpi.c and moved similar code to dlib. Also fixes ckd_write in dpid/dpid_common.c: it handled EINTR, but did not handle situation when number of bytes written is less then requested. Now it uses dWrite.

Jan. 18, 2013

[patch] disable SSLv2 support

by p37sitdu＠lavabit.com

http://www.inventati.org/noname/dillo/https-no-SSLv2.patch I have found HTTPS server that Dillo was unable to connect to. After defining SILENT to 0 in https.c I found that SSL_connect failed. Adding ERR_print_errors_fp(stderr) showed error "SSL23_GET_SERVER_HELLO:unknown protocol". Disabling SSLv2 support fixed the problem for me. And SSLv2 is insecure so it must be disabled anyway.

Jan. 17, 2013

chain.c cleanup

by p37sitdu＠lavabit.com

http://www.inventati.org/noname/dillo/chain-cleanup.patch 1. Replaced dNew with dMalloc and dNew0 with dMalloc0. This way it is possible to use (sizeof *var) instead of repeating variable type. By the way, when 'count' is constant, dMalloc is easier to use, and when count is not constant, integer overflow can happen in dNew during multiplication. It looks like there are no such errors, but I think check should be added or, better, dCalloc can be introduced so libc checks for such cases. 2. Replaced #defines with enums and made them uppercase so it is easier to distinguish them from variables. This style is already used in most modules. IO should be fixed too, probably. 3. Moved duplicate code from a_Chain_fcb and a_Chain_bcb to Chain_cb. Anonymous structures for connections (forward or backward) are introduced in ChainLink structure for this purpose. 4. Removed unused a_Chain_unlink function. Chain links are just dFreed instead. Anyway, there is no function to connect existing links back, so disconnected link can only be dFreed. 5. Replaced AtoB_branch and BtoA_branch parameters of a_Chain_link_new with single Branch parameter. They were always equal anyway, and using different branch identifiers for one connection makes no sense, as branch ID is used to distinguish between Answer and Query chains. Branch parameter can be eliminated completely by separating existing CCC callbacks into answer and query callbacks. Currently instead of two functions we have one with if (Branch == 1) { ... } else { ... }

Jan. 17, 2013

CustChoice

by corvid＠lavabit.com

I was looking into why the search dialog would no longer let me tab to the search engine list and press down arrow to switch between them... It seems that, once Jorge added a CustChoice in fltkui.cc, the dialog code started to use _that_ one and not its own. (I would've expected something to complain about there being two CustChoice::handle()s in that case...) Would it be considered incorrect in any way if fltkui.cc's CustChoice and CustInput2 were put inside dw::fltk::ui?

Jan. 16, 2013

[patch] a_Dpip_send_cmd

by p37sitdu＠lavabit.com

I have fixed the patch and reread it. Link is the same: http://www.inventati.org/noname/dillo/dpip-send-cmd.patch

Jan. 15, 2013

tooltip in the way when typing

by corvid＠lavabit.com

With fltk's built-in tooltip system, Fl::handle_(), upon receipt of a FL_KEYBOARD event, calls Fl_Tooltip::enter((Fl_Widget*)0); to hide the tooltip. Once in a while, after giving a text input focus, I'm careless with the mouse, moving it away and then back over the input, putting a tooltip over what I'm typing. (And presumably textareas could have that happen as well...) Here's one way that it could be dealt with:

Jan. 15, 2013