January 2013 - Dillo-dev - lists.mailman3.com

dereferencing type-punned pointer warning
by Johannes.Hofmann＠gmx.de 22 Jan '13

22 Jan '13

Hi, line 135 in lout object.cc: return ((int*)&value)[0] ^ ((int*)&value)[1]; causes the following error on 64bit systems for me: warning: dereferencing type-punned pointer will break strict-aliasing rules Can we replace it like this: diff -r dd6f2d1eb15a lout/object.cc --- a/lout/object.cc Mon Jan 14 10:26:37 2013 -0300 +++ b/lout/object.cc Mon Jan 14 21:56:46 2013 +0100 @@ -21,6 +21,7 @@ #include "object.hh" #include <stdio.h> +#include <stdint.h> #include <config.h> namespace lout { @@ -132,7 +133,7 @@ // Combine both parts of the pointer value *itself*, not what it // points to, by first referencing it (operator "&"), then // dereferencing it again (operator "[]"). - return ((int*)&value)[0] ^ ((int*)&value)[1]; + return ((intptr_t)value >> 32) ^ ((intptr_t)value); #endif } Cheers, Johannes

2 1

[patch] Scrollbar thickness from dillorc
by podarcis＠lavabit.com 21 Jan '13

21 Jan '13

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

3 4

drawing highlighting
by corvid＠lavabit.com 19 Jan '13

19 Jan '13

I was looking at draw() calls for the view, and I saw how there was a call for every time that the mouse moved when highlighting even though the text highlighted didn't necessarily change. Here's quick code to demonstrate that there are plenty of redundant ones. I don't know the iterator code well enough to know whether that's the right place to do anything about it, though...

2 2

[patch] disable SSLv2 support
by p37sitdu＠lavabit.com 18 Jan '13

18 Jan '13

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.

2 1

[patch] dWrite
by p37sitdu＠lavabit.com 18 Jan '13

18 Jan '13

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.

1 0

[patch] a_Dpip_send_cmd
by p37sitdu＠lavabit.com 15 Jan '13

15 Jan '13

http://www.inventati.org/noname/dillo/dpip-send-cmd.patch Patch adds a_Dpip_send_cmd and helper function a_Dpip_vbuild_cmd. This way common pattern d_cmd = a_Dpip_build_cmd(format, ...); st = a_Dpip_dsh_write_str(sh, flush, d_cmd); dFree(d_cmd); can be replaced with st = a_Dpip_send_cmd(sh, flush, format, ...);

2 2

tooltip in the way when typing
by corvid＠lavabit.com 15 Jan '13

15 Jan '13

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:

1 0

mare patches for dpid
by p37sitdu＠lavabit.com 14 Jan '13

14 Jan '13

http://www.inventati.org/noname/dillo/dpid-dclose.patch http://www.inventati.org/noname/dillo/dpid-no_dotfiles.patch

2 1

Patch for xembed (text corrected)
by podarcis＠lavabit.com 14 Jan '13

14 Jan '13

Hi all, Here is a patch to make embedding dillo into an X-window work. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff -r 9bad41ea1dde src/xembed.cc --- a/src/xembed.cc Wed Dec 05 13:03:04 2012 +0100 +++ b/src/xembed.cc Sun Dec 09 10:12:36 2012 +0100 // TODO: Implement more XEMBED support; -void Xembed::show() { +void Xembed::create() { createInternal(xid); setXembedInfo(1); Fl::event_dispatch(event_handler); diff -r 9bad41ea1dde src/xembed.hh --- a/src/xembed.hh Wed Dec 05 13:03:04 2012 +0100 +++ b/src/xembed.hh Sun Dec 09 10:12:36 2012 +0100 @@ -14,10 +14,11 @@ public: Xembed(uint32_t xid, int _w, int _h) : Fl_Window(_w, _h) { - this->xid = xid; + this->xid = xid; create(); }; - void show(); + void create(); int handle(int event); + void resize(int x, int y, int w, int h); }; #endif ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ tested with this FLTK program: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #include <FL/Fl.H> #include <FL/Fl_Window.H> #include <FL/x.H> #include <cstdio> #include <iostream> #include <sstream> #include <string> using namespace std; int main( int argc_, char *argv_[] ) { Fl_Window dw( 800, 600, "dillo embedded" ); dw.resizable( &dw ); dw.show(); cout << "dw.xid = " << (unsigned long)fl_xid(&dw) << endl; ostringstream cmd; cmd << "dillo -f -g " << dw.w() << "x" << dw.h() << " --xid " << (unsigned long)fl_xid(&dw); if ( argc_ > 1 ) cmd << " " << argv_[1]; cmd << " &"; cout << "system '" << cmd.str() << "'" << endl; system( cmd.str().c_str() ); return Fl::run(); } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ What does NOT work is automatic resizing of the embedded dillo window, when the size is changed. This would be nice to have. I do not know enough of the embedding stuff, but I wonder if the static int event_handler() ever gets called with type ClientMessage - at least I could not make it get there.. podarcis

4 11

ui colors again
by corvid＠lavabit.com 13 Jan '13

13 Jan '13

Today I dug up the old ui colors patch from last September, ripped out the part that used system colors as defaults that was a problem*, and played around with it a little. I really like configurable colors, so, since I haven't heard anyone say anything like feature freeze yet, I'll make another push for this thing. One difference from the previous code is that I'm using inactive() on the images for inactive toolbar buttons because our gray pixmaps tend not to look so good with different UI colors. It might be good to pull it somewhat closer to the background color, but I'm not sure yet. * Under X, FLTK tries to "Read colors that KDE writes to the xrdb database", which may or may not work fine for those people running KDE, but...

3 20