- Dillo-dev - lists.mailman3.com

[patch] dns.c: missing break in a_Dns_dillohost_to_string

by Johannes.Hofmann＠gmx.de

On Thu, Dec 20, 2012 at 08:20:41PM +0400, p37sitdu at lavabit.com wrote: > Fix is attached. Committed! Thanks, Johannes

Dec. 20, 2012

config.h.in and configure.in

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > On Wed, Dec 19, 2012 at 01:24:21PM +0000, Jeremy Henty wrote: > > > > I thought that we agreed[1] to remove config.h.in from the > > repository and to rename configure.in to configure.ac . Can I > > make these changes or is more discussion needed? > > Go ahead! OK, done. Regards, Jeremy Henty

Dec. 20, 2012

[patch] dns.c: missing break in a_Dns_dillohost_to_string

by p37sitdu＠lavabit.com

Fix is attached.

Dec. 20, 2012

[patch] send_dpip_tag in vsource.c is unused

by p37sitdu＠lavabit.com

Attached patch removes unused function send_dpip_tag. Functions send_plain_text, send_numbered_text and send_html_text are made static.

Dec. 20, 2012

Dpi_connect_socket retry

by p37sitdu＠lavabit.com

On Sun, Dec 16, 2012 at 07:43:19PM -0300, Jorge Arellano Cid wrote: > On Sun, Dec 09, 2012 at 02:58:43PM +0400, p37sitdu at lavabit.com wrote: > > Also, comment says "the server closes sock_fd on error". However, > > sock_fd should still be closed by client to free allocated file > > descriptor. OS don't know if Dillo is going to read from it (in which > > case error such as ECONNRESET should happen) so file descriptor can't > > be reused. > > > > File descriptor should be closed in case of error in a_Dpip_build_cmd > > too. > > The file descriptor is properly closed by its CCC afterwards > (Visible by defining VERBOSE in chain.c). > > The CCC manages the error propagation/handling, in both the > requesting and answer branches. File descriptor is properly closed if there were no errors. But if there is an error in a_Dpip_build_cmd or Dpi_blocking_write, sock_fd should be closed before returning from Dpi_connect_socket. Dpi_connect_socket calls a_Dpip_build_cmd to build command and Dpi_blocking_write to write this command to sock_fd. a_Dpip_build_cmd does not accept sock_fd as its argument so it can't close it. Dpi_blocking_write only writes to fd, but does not close it on error. So if one of these two function fails, Dpi_connect_socket should close sock_fd before returning -1. In the current state it just returns -1 and leave sock_fd open. By the time Dpi_connect_socket returns, sock_fd is lost and will not be closed by any code outside Dpi_connect_socket. Attached patch adds code to close sock_fd in case of error.

Dec. 20, 2012

Patch for xembed (updated for resize)

by podarcis＠lavabit.com

Hi, well the aim would be to contribute to dillo to make it embeddable by X11 applications. If you want to achieve this with "standard" XEMBED protocol only, I am off -that's not my domain... I have tested/debugged the current code with 'tabbed' (as you suggested) and found out, that it works even better if the ClientMessage code (and this is the only relevant code here) is removed. tabbed also showed some glitches with the current code: - dillo's File menu opens at different positions after moving - clicking in the grey space right to dillo's 'Tools' icon seems to crash something... So I removed the whole thing. Did you try my patch? It certainly works not only from FLTK applications. You can verify that, if you try to embed dillo into any window on your desktop e.g. a gnome terminal (use xwininfo to find out its xid). I do not claim that my patch is complete already, but it may at least be used as a starting point. At least it has the advantage, that the embedder does not need to do anything, except passing an xid. If keeping the old code is your only concern, then I can re-integrate it into my patch again - it has no effect on it at all. Cheers chris > Hi, > > On Sat, Dec 15, 2012 at 12:04:35PM +0100, podarcis wrote: >> Hi, >> >> here is an updated version making resize work. >> It still works with tabbed too. >> Note that I have had no knowledge of X or xembed at all, so all >> changes come from experimenting... >> I removed large parts of the existing code, because they did nothing >> in my environment. >> >> Please have a look at it. > > hm, the patch basically removes support for the xembed protocol. Is > it meant as a diagnostic patch to investigate a problem, or meant > for inclusion into the dillo repository? > It won't work for the latter case. You can't just remove code that > is not needed for your specific case. > If you just want to get embedding of dillo into an fltk based window > working, you would need to send the proper xembed X11 event from your > embedding fltk program. Look at what tabbed is doing. > I can also dig into my old stuff, I think I once had a minimal fltk > based embedder working. > > Cheers, > Johannes > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Dec. 20, 2012

Extensions for hyphenation

by corvid＠lavabit.com

The text spills over into the following cell in <table border=1> <tr> <td>W d<whatever>aaaaaaaaaaaa*<br> <td>WW d<whatever>aaaaaaaaaaaa*<br> <td>WWW d<whatever>aaaaaaaaaaaa*<br> <td>WWWW d<whatever>aaaaaaaaaaaa*<br> <td>WWWWW d<whatever>aaaaaaaaaaaa*<br> <td>WWWWWW d<whatever>aaaaaaaaaaaa*<br> </table> if I make the browser window narrowish.

Dec. 20, 2012

config.h.in and configure.in

by jcid＠dillo.org

On Wed, Dec 19, 2012 at 01:24:21PM +0000, Jeremy Henty wrote: > > I thought that we agreed[1] to remove config.h.in from the repository > and to rename configure.in to configure.ac . Can I make these changes > or is more discussion needed? Go ahead! -- Cheers Jorge.-

Dec. 19, 2012

config.h.in and configure.in

by onepoint＠starurchin.org

I thought that we agreed[1] to remove config.h.in from the repository and to rename configure.in to configure.ac . Can I make these changes or is more discussion needed? Regards, Jeremy Henty [1]: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2012-December/009618.html

Dec. 19, 2012

Patch for xembed (updated for resize)

by johannes.hofmann＠gmx.de

Hi, On Sat, Dec 15, 2012 at 12:04:35PM +0100, podarcis wrote: > Hi, > > here is an updated version making resize work. > It still works with tabbed too. > Note that I have had no knowledge of X or xembed at all, so all > changes come from experimenting... > I removed large parts of the existing code, because they did nothing > in my environment. > > Please have a look at it. hm, the patch basically removes support for the xembed protocol. Is it meant as a diagnostic patch to investigate a problem, or meant for inclusion into the dillo repository? It won't work for the latter case. You can't just remove code that is not needed for your specific case. If you just want to get embedding of dillo into an fltk based window working, you would need to send the proper xembed X11 event from your embedding fltk program. Look at what tabbed is doing. I can also dig into my old stuff, I think I once had a minimal fltk based embedder working. Cheers, Johannes

Dec. 19, 2012

dpid patches

by p37sitdu＠lavabit.com

First patch is for removing expired TODO item, just resending it. Second patch is new, for dpid.c. Function fill_services_list has a bug: on line 463 there is a check *services_list != NULL. If it is true, then -1 is returned, but dpidrc_stream is not closed. Error message on line 456 says "popen failed", should be "fopen failed". fill_services_list checks for availability of user_dpidir and sys_dpidir, but after line 449 these variables are not used. They are just dFreed in the end. Looks like code was just copypasted from register_all. fill_services_list is only called from main.c:248 and dpid.c:807 of dpid.c. register_all is called from main.c:235 and dpid.c:806. So fill_services_list is always called after register_all and doing the same check is useless. On line 503 there is a conversion of services_alpha_comp to type (dCompareFunc). I changed the function services_alpha_comp to the usual style of writing comparison functions so no conversion is required. In the current state it is undefined behaviour. [1] [1] http://stackoverflow.com/questions/559581/casting-a-function-pointer-to-ano…

Dec. 18, 2012

[patch] Gopher DPI

by p37sitdu＠lavabit.com

Fixed memory leak related to dGetline.

Dec. 17, 2012

[patch] Gopher DPI

by p37sitdu＠lavabit.com

Small changes - Added 'p' filetype for images (used by some gopher servers) - Use dGetline instead of getline

Dec. 17, 2012

Tooltip bugs revisited

by jcid＠dillo.org

On Tue, Dec 11, 2012 at 04:30:59AM +0000, corvid wrote: > Jorge wrote: > > So far (and despite the warning inside FLTK), I've experimented > > with a custom tooltip handling class, and a couple custom UI > > widgets, that seem to work well together (i.e. solve the problem > > without the workaround :) ). > > I see that this code is derived from the code at > http://seriss.com/people/erco/fltk/#SliderTooltip > I think we should mention that at the tops of the tipwin files and > in AUTHORS. Yes, I wrote to Greg and got his answer stating that all the code there is public domain, and that he'll soon add some lines declaring it so in his "Cheat Page". -- Cheers Jorge.-

Dec. 17, 2012

Dpi_connect_socket retry

by jcid＠dillo.org

Hi, Finally I had the time to review this issue in more detail... On Sun, Dec 09, 2012 at 02:58:43PM +0400, p37sitdu at lavabit.com wrote: > Dpi_connect_socket function from src/IO/dpi.c (also duplicated in > test/cookies.c) has retry argument. It is set to TRUE on first call, > and Dpi_connect_socket calls itself recursively with retry == FALSE in > case of error. > > This retry function is not working. If connection fails, at line 645 > sock_fd is set, but ret is still set to -1. Even if the second attempt > to connect is successful, -1 is returned and conected sock_fd is lost. > > It is possible to fix it by adding "ret = sock_fd", but I think it is > better to just remove retries completely. It is unlikely that > connecting using loopback interface will fail on first try and succeed > on retry. Yes, this code is obsolete now. It was meant for Unix domain sockets (when dpis/dpid used them). Sometimes the filename lingered in the filesystem after a dpi or server crash. With unlink&retry it was possible to recover then. Details in patchset: 7faa2c7a544f (Nov, 2009 ;) Removed in the repo (see below). > Also, comment says "the server closes sock_fd on error". However, > sock_fd should still be closed by client to free allocated file > descriptor. OS don't know if Dillo is going to read from it (in which > case error such as ECONNRESET should happen) so file descriptor can't > be reused. > > File descriptor should be closed in case of error in a_Dpip_build_cmd > too. The file descriptor is properly closed by its CCC afterwards (Visible by defining VERBOSE in chain.c). The CCC manages the error propagation/handling, in both the requesting and answer branches. > Patch to fix this function and its calls in src/IO/dpi.c and > test/cookies.c is attached. No need to fix, it works properly. -- Cheers Jorge.-

Dec. 16, 2012

Extensions for hyphenation

by corvid＠lavabit.com

Sebastian wrote: > On Sat, Dec 08, corvid wrote: > > Sebastian wrote: > > > On Fri, Dec 07, corvid wrote: > > > > For instance, > > > > > > > > dillo -geometry 850x700 http://fltk.org > > > > > > > > makes the names of the snapshots very narrow, and if I try > > > > > > > > penalty_hyphen=inf > > > > > > > > part of the fltk-2 snapshot link is obscured by the image. > > > > I still see this, or at least the penalty_hyphen=inf case. I didn't try > > the default penalty_hyphen case. > > I was finally able to reproduce this, by using "trickle". > > It is fixed now, at least for me; please test it again. It's working :)

Dec. 16, 2012

Extensions for hyphenation

by sgeerken＠dillo.org

On Sat, Dec 08, corvid wrote: > Sebastian wrote: > > On Fri, Dec 07, corvid wrote: > > > For instance, > > > > > > dillo -geometry 850x700 http://fltk.org > > > > > > makes the names of the snapshots very narrow, and if I try > > > > > > penalty_hyphen=inf > > > > > > part of the fltk-2 snapshot link is obscured by the image. > > I still see this, or at least the penalty_hyphen=inf case. I didn't try > the default penalty_hyphen case. I was finally able to reproduce this, by using "trickle". It is fixed now, at least for me; please test it again. As far as I see, this is the last bug related to hypenation, at least the last one relevant for the next release. Sebastian

Dec. 16, 2012

[patch] Gopher DPI

by jcid＠dillo.org

On Sun, Dec 16, 2012 at 12:31:19AM +0400, p37sitdu at lavabit.com wrote: > Now search works properly. URL looks like > gopher://gopher.floodgap.com:70/7/v2/vs?query=dillo, but ?query is > replaced with %09 internally. I have not found the way to make > redirect. The patch is ready to be commited and should not break > anything as it is a separate DPI that is only called for gopher URLs. > > I will try to implement search without forms by adding input dialogs > as a separate patch in my patch queue on top of it. User experience > will be similar to lynx: you open the page and then browser asks you > for search query. Are you sure a dialog is better than a simple form (as with bookmarks)? I'll review the patch as soon as I find the necessary time. So far from what I've read in the list, it looks OK. Just some friendly advice: don't rush; you'll find plenty of options along the way, and independent as a dpi is, it looks much like it will make it into the next release. > Also patch for src/IO/dpi.c is attached to make Dpi_parse_token more > robust as I accedently made it segfault during development of gopher > DPI. Yes, there're subtle interactions and assumptions in dpip. That's why I'd like to take the necessary time to review the FD leak patch and then the gopher dpi. -- Cheers Jorge.-

Dec. 15, 2012

[patch] Gopher DPI

by p37sitdu＠lavabit.com

On Sat, Dec 15, 2012 at 09:27:14PM +0100, Johannes Hofmann wrote: I have added setbuf(fp, NULL) instead. Fixed patch is attaced. > Took me quite a while to figure this out ... > Anyway, with these tiny modifications it works nice for me and I'd > like to commit it. Let me know when you think it's ready. I think attached patch is ready to be commited, I will develop code that changes dillo internals (DPI api) as a separate patch.

Dec. 15, 2012

[patch] Gopher DPI

by p37sitdu＠lavabit.com

Now search works properly. URL looks like gopher://gopher.floodgap.com:70/7/v2/vs?query=dillo, but ?query is replaced with %09 internally. I have not found the way to make redirect. The patch is ready to be commited and should not break anything as it is a separate DPI that is only called for gopher URLs. I will try to implement search without forms by adding input dialogs as a separate patch in my patch queue on top of it. User experience will be similar to lynx: you open the page and then browser asks you for search query. Also patch for src/IO/dpi.c is attached to make Dpi_parse_token more robust as I accedently made it segfault during development of gopher DPI.

Dec. 15, 2012

[patch] Gopher DPI

by Johannes.Hofmann＠gmx.de

very cool! To get it working on DragonFlyBSD I had to add a fflush() after the fprintf() on the socket. Also the fdopen() flags had to be changed to w+ (from man page: ``w+'' Open for reading and writing.). Otherwise the fflush() doesn't work. There is the following comment in the fflush code: /* * There is disagreement about the correct behaviour of * fflush() * when passed a file which is not open for reading. * According to * the ISO C standard, the behaviour is undefined. * Under linux, such an fflush returns success and has no * effect; * under Windows, such an fflush is documented as behaving * instead * as fpurge(). * Given that applications may be written with the * expectation of * either of these two behaviours, the only safe * (non-astonishing) * option is to return EBADF and ask that applications be * fixed. */ Took me quite a while to figure this out ... Anyway, with these tiny modifications it works nice for me and I'd like to commit it. Let me know when you think it's ready. Cheers, Johannes

Dec. 15, 2012

[patch] Gopher DPI

by p37sitdu＠lavabit.com

I am trying to make search work. Now (latest version of patch is included) I process type '7' (FullText search) is the same as '1'. So link "Search Veronica-2" on [1]/ is just a link that leads to [2]. Search terms can be added manually, like [3]. It works and it is what gopher URI Scheme RFC4266 says. DPI dialogs don't support text input, though it should not be hard to add. Another option is HTML forms and redirections. [1] gopher://gopherproject.org:70/1/ [2] gopher://gopher.floodgap.com:70/7/v2/vs [3] gopher://gopher.floodgap.com:70/7/v2/vs%09dillo

Dec. 15, 2012

[patch] Gopher DPI

by p37sitdu＠lavabit.com

Updated patch a little to support URLs without path (like gopher://gopher.quux.org) Made functions static, added newlines to messages etc.

Dec. 15, 2012

Fwd: Re: Dillo early exit

by corvid＠lavabit.com

Sebastian wrote: > However, IMO there should be a conversion to clean UTF-8 so that only > a small part of dillo should have to bother about such problems, while > most parts can rely on clean UTF-8. (Something to consider after the > release.) I just checked whether we could get free stripping of non-utf-8 by asking iconv to convert from utf-8 to utf-8 when that's the claimed charset, but unsurprisingly it didn't do anything.

Dec. 15, 2012

[patch] Gopher DPI

by abe＠deuxchevaux.org

Hi, On Sat, Dec 15, 2012 at 07:24:23PM +0400, p37sitdu at lavabit.com wrote: > I implemented basic Gopher support using DPI, patch is attached. It is > already quite usable. Yay, very cool! Looking forward to see it in the next release! :-) Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Dec. 15, 2012

[patch] Gopher DPI

by p37sitdu＠lavabit.com

I implemented basic Gopher support using DPI, patch is attached. It is already quite usable. "URL:" links are not supported, but Gopher servers send redirect pages for compatibility. The only major problem is unrecognized file types. I looked at FTP DPI. It sends Content-type: application/octet-stream. This forces Dillo to ask downloads DPI to start download. With gopher it doesn't work as downloads DPI doesn't suppport gopher. So Dillo just says "Content-Type 'application/octet-stream' not viewable.". I left it as it is for now, because I don't think adding support for all known and unknown protocols into downloads.cc is the right solution. Maybe downloads DPI protocol should be changed so Dillo would feed plugin with data it receives as octet-stream and downloads DPI would only save what it receives to disk instead of connecting to server and downloading the file itself.

Dec. 15, 2012

Fwd: Re: Dillo early exit

by sgeerken＠dillo.org

On Fri, Dec 14, Jorge Arellano Cid wrote: > On Fri, Dec 14, 2012 at 04:48:23PM +0100, Sebastian Geerken wrote: > > The HTML parser passes invalid UTF-8 to dw::Textblock. I will make > > nextUtf8Char more robust (of course, dillo should not crash), but > > Jorge's page is HTML, encoded in ISO-8859-1, not UTF-8, as seen here: > > > > 000009b0 34 38 22 3e 2d 20 4b 65 79 73 74 72 6f 6b 65 20 |48">- Keystroke | > > 000009c0 4c 6f 67 67 69 6e 67 20 77 69 74 68 20 42 65 61 |Logging with Bea| > > 000009d0 63 6f 6e 20 ab 20 53 74 72 61 74 65 67 69 63 20 |con . Strategic | > > ^^ > > > > It seems that the Fltk functions do some checks, and sometimes decode > > as ISO-8859-1. > > AFAIR from comments in fltk, some utf8 functions dealt with mixed > latin1, utf8 and some windows codec. > > They got into it because the mix was inevitable for them. I've modified my code so that it works in a similar way, but I've not yet cared about the differences between ISO-8859-1, ISO-8859-15, and Windows-1252. Anyway these differences are marginal. However, IMO there should be a conversion to clean UTF-8 so that only a small part of dillo should have to bother about such problems, while most parts can rely on clean UTF-8. (Something to consider after the release.) Sebastian

Dec. 15, 2012

Fwd: Re: Patch for xembed (updated for resize) FIXED!!

by podarcis＠lavabit.com

Damn, something went wrong with pasting in the patch. Here the complete patch, sorry. --- diff -r 52633c6c3fc6 src/xembed.cc --- a/src/xembed.cc Wed Dec 12 19:40:33 2012 +0000 +++ b/src/xembed.cc Sat Dec 15 11:49:23 2012 +0100 @@ -21,93 +21,49 @@ #ifdef X_PROTOCOL -typedef enum { - XEMBED_EMBEDDED_NOTIFY = 0, - XEMBED_WINDOW_ACTIVATE = 1, - XEMBED_WINDOW_DEACTIVATE = 2, - XEMBED_REQUEST_FOCUS = 3, - XEMBED_FOCUS_IN = 4, - XEMBED_FOCUS_OUT = 5, - XEMBED_FOCUS_NEXT = 6, - XEMBED_FOCUS_PREV = 7, - XEMBED_GRAB_KEY = 8, - XEMBED_UNGRAB_KEY = 9, - XEMBED_MODALITY_ON = 10, - XEMBED_MODALITY_OFF = 11, -} XEmbedMessageType; - -void -Xembed::setXembedInfo(unsigned long flags) -{ - unsigned long buffer[2]; - - Atom xembed_info_atom = XInternAtom (fl_display, "_XEMBED_INFO", false); - - buffer[0] = 1; - buffer[1] = flags; - - XChangeProperty (fl_display, - xid, - xembed_info_atom, xembed_info_atom, 32, - PropModeReplace, - (unsigned char *)buffer, 2); +void Xembed::update_size() { + XWindowAttributes winAttributes; + XGetWindowAttributes( fl_display, xid, &winAttributes ); + int width = winAttributes.width; + int height = winAttributes.height; + update_size(width, height); } -void -Xembed::sendXembedEvent(uint32_t message) { - XClientMessageEvent xclient; - - memset (&xclient, 0, sizeof (xclient)); - xclient.window = xid; - xclient.type = ClientMessage; - xclient.message_type = XInternAtom (fl_display, "_XEMBED", false); - xclient.format = 32; - xclient.data.l[0] = fl_event_time; - xclient.data.l[1] = message; - - XSendEvent(fl_display, xid, False, NoEventMask, (XEvent *)&xclient); - XSync(fl_display, False); +void Xembed::update_size(int width, int height) { + if (w() != width || h() != height) + { + resize(x(), y(), width, height); + redraw(); + } } -int -Xembed::handle(int e) { - if (e == FL_PUSH) - sendXembedEvent(XEMBED_REQUEST_FOCUS); - - return Fl_Window::handle(e); -} - +static Xembed *xembed = 0; static int event_handler(int e, Fl_Window *w) { - Atom xembed_atom = XInternAtom (fl_display, "_XEMBED", false); - - if (fl_xevent->type == ClientMessage) { - if (fl_xevent->xclient.message_type == xembed_atom) { - long message = fl_xevent->xclient.data.l[1]; - - switch (message) { - case XEMBED_WINDOW_ACTIVATE: - // Force a ConfigureNotify message so fltk can get the new - // coordinates after a move of the embedder window. - if (w) - w->resize(0,0, w->w(), w->h()); - break; - case XEMBED_WINDOW_DEACTIVATE: - break; - default: - break; - } + if ( fl_xevent->type == ConfigureNotify ) + { + XConfigureEvent *xcfg = (XConfigureEvent *)fl_xevent; + uint32_t xid = xcfg->window; + if (xembed && xembed->myxid() == xid) + { + xembed->update_size(xcfg->width, xcfg->height); } } - return Fl::handle_(e, w); } // TODO: Implement more XEMBED support; +void Xembed::create() { + xembed = this; + createInternal(xid); + long mask( StructureNotifyMask ); + XSelectInput(fl_display, xid, mask); + Fl::event_dispatch(event_handler); +} + void Xembed::show() { - createInternal(xid); - setXembedInfo(1); - Fl::event_dispatch(event_handler); + Fl_Window::show(); + update_size(); } void Xembed::createInternal(uint32_t parent) { diff -r 52633c6c3fc6 src/xembed.hh --- a/src/xembed.hh Wed Dec 12 19:40:33 2012 +0000 +++ b/src/xembed.hh Sat Dec 15 11:49:23 2012 +0100 @@ -9,15 +9,16 @@ private: uint32_t xid; void createInternal(uint32_t parent); - void setXembedInfo(unsigned long flags); - void sendXembedEvent(uint32_t message); public: Xembed(uint32_t xid, int _w, int _h) : Fl_Window(_w, _h) { - this->xid = xid; + this->xid = xid; create(); }; + uint32_t myxid() const { return xid; } + void create(); void show(); - int handle(int event); + void update_size(); + void update_size( int, int ); }; #endif ---

Dec. 15, 2012

Patch for xembed (updated for resize)

by podarcis＠lavabit.com

Hi, here is an updated version making resize work. It still works with tabbed too. Note that I have had no knowledge of X or xembed at all, so all changes come from experimenting... I removed large parts of the existing code, because they did nothing in my environment. Please have a look at it. Cheers, podarcis ----- diff -r 52633c6c3fc6 src/xembed.cc --- a/src/xembed.cc Wed Dec 12 19:40:33 2012 +0000 +++ b/src/xembed.cc Sat Dec 15 11:49:23 2012 +0100 @@ -21,93 +21,49 @@ #ifdef X_PROTOCOL -typedef enum { - XEMBED_EMBEDDED_NOTIFY = 0, - XEMBED_WINDOW_ACTIVATE = 1, - XEMBED_WINDOW_DEACTIVATE = 2, - XEMBED_REQUEST_FOCUS = 3, - XEMBED_FOCUS_IN = 4, - XEMBED_FOCUS_OUT = 5, - XEMBED_FOCUS_NEXT = 6, - XEMBED_FOCUS_PREV = 7, - XEMBED_GRAB_KEY = 8, - XEMBED_UNGRAB_KEY = 9, - XEMBED_MODALITY_ON = 10, - XEMBED_MODALITY_OFF = 11, -} XEmbedMessageType; - -void -Xembed::setXembedInfo(unsigned long flags) -{ - unsigned long buffer[2]; - - Atom xembed_info_atom = XInternAtom (fl_display, "_XEMBED_INFO", false); - - buffer[0] = 1; - buffer[1] = flags; - - XChangeProperty (fl_display, - xid, - xembed_info_atom, xembed_info_atom, 32, - PropModeReplace, - (unsigned char *)buffer, 2); +void Xembed::update_size() { + XWindowAttributes winAttributes; + XGetWindowAttributes( fl_display, xid, &winAttributes ); + int width = winAttributes.width; + int height = winAttributes.height; + update_size(width, height); } -void -Xembed::sendXembedEvent(uint32_t message) { - XClientMessageEvent xclient; - - memset (&xclient, 0, sizeof (xclient)); - xclient.window = xid; - xclient.type = ClientMessage; - xclient.message_type = XInternAtom (fl_display, "_XEMBED", false); - xclient.format = 32; - xclient.data.l[0] = fl_event_time; - xclient.data.l[1] = message; - - XSendEvent(fl_display, xid, False, NoEventMask, (XEvent *)&xclient); - XSync(fl_display, False); +void Xembed::update_size(int width, int height) { + if (w() != width || h() != height) + { + resize(x(), y(), width, height); + redraw(); + } } -int -Xembed::handle(int e) { - if (e == FL_PUSH) - sendXembedEvent(XEMBED_REQUEST_FOCUS); - - return Fl_Window::handle(e); -} - +static Xembed *xembed = 0; static int event_handler(int e, Fl_Window *w) { - Atom xembed_atom = XInternAtom (fl_display, "_XEMBED", false); - - if (fl_xevent->type == ClientMessage) { - if (fl_xevent->xclient.message_type == xembed_atom) { - long message = fl_xevent->xclient.data.l[1]; - - switch (message) { - case XEMBED_WINDOW_ACTIVATE: - // Force a ConfigureNotify message so fltk can get the new - // coordinates after a move of the embedder window. - if (w) - w->resize(0,0, w->w(), w->h()); - break; - case XEMBED_WINDOW_DEACTIVATE: - break; - default: - break; - } ---- Here the simplified FLTK test 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 --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(); } ---

Dec. 15, 2012

config.h.in

by jcid＠dillo.org

On Fri, Dec 14, 2012 at 06:46:16PM +0000, corvid wrote: > p37sitdu wrote: > > On Fri, Dec 14, 2012 at 05:36:42PM +0000, corvid wrote: > > > p37sitdu wrote: > > > > By the way, configure.in is named configure.ac now. [1] autoconf shows > > > > a warning each time it sees configure.in. > > > > > > > > [1] https://www.gnu.org/software/autoconf/manual/autoconf.html#Writing-Autoconf… > > > > > > I believe there was some discussion of this in the past, with some concern > > > about still working with old versions of autoconf that one could reasonably > > > expect someone to still have around somewhere. When was the renaming done? > > > > Tue, 17 Jul 2001 07:53:06 > > > > http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=f0478c4702efe… > > I, for one, would feel okay with changing it, then... +1 -- Cheers Jorge.-

Dec. 14, 2012

config.h.in

by corvid＠lavabit.com

p37sitdu wrote: > On Fri, Dec 14, 2012 at 05:36:42PM +0000, corvid wrote: > > p37sitdu wrote: > > > By the way, configure.in is named configure.ac now. [1] autoconf shows > > > a warning each time it sees configure.in. > > > > > > [1] https://www.gnu.org/software/autoconf/manual/autoconf.html#Writing-Autoconf… > > > > I believe there was some discussion of this in the past, with some concern > > about still working with old versions of autoconf that one could reasonably > > expect someone to still have around somewhere. When was the renaming done? > > Tue, 17 Jul 2001 07:53:06 > > http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=f0478c4702efe… I, for one, would feel okay with changing it, then...

Dec. 14, 2012

config.h.in

by p37sitdu＠lavabit.com

On Fri, Dec 14, 2012 at 05:36:42PM +0000, corvid wrote: > p37sitdu wrote: > > By the way, configure.in is named configure.ac now. [1] autoconf shows > > a warning each time it sees configure.in. > > > > [1] https://www.gnu.org/software/autoconf/manual/autoconf.html#Writing-Autoconf… > > I believe there was some discussion of this in the past, with some concern > about still working with old versions of autoconf that one could reasonably > expect someone to still have around somewhere. When was the renaming done? Tue, 17 Jul 2001 07:53:06 http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=f0478c4702efe…

Dec. 14, 2012

config.h.in

by corvid＠lavabit.com

p37sitdu wrote: > By the way, configure.in is named configure.ac now. [1] autoconf shows > a warning each time it sees configure.in. > > [1] https://www.gnu.org/software/autoconf/manual/autoconf.html#Writing-Autoconf… I believe there was some discussion of this in the past, with some concern about still working with old versions of autoconf that one could reasonably expect someone to still have around somewhere. When was the renaming done?

Dec. 14, 2012

valgrind log entry hyphenation related?

by corvid＠lavabit.com

Sebastian wrote: > Somehow, fl_utf8fwd has got problems, especially with strings, which > are not 0-terminated. OTOH, I agreed with Johannes some time ago that > the UTF-8 related methods should not be part dw::core::Platform, since > UTF-8 handling is not platform dependant. > > For fl_utf8fwd (or, Platform::nextGlyph, respectively), there is a > replacement, lout::unicode::nextUtf8Char. Anything else could be > completed after the release (unless there are severe problems). Parts > of Fltk can be copied: the respective code is in the public domain. Which bits are in the public domain?

Dec. 14, 2012

Fwd: Re: Dillo early exit

by jcid＠dillo.org

On Fri, Dec 14, 2012 at 04:48:23PM +0100, Sebastian Geerken wrote: > Somehow this post got lost ... > Date: Fri, 14 Dec 2012 15:43:41 +0100 > From: Sebastian Geerken <sgeerken at dillo.org> > Subject: Re: [Dillo-dev] Dillo early exit > To: Dillo mailing list <dillo-dev at dillo.org> > Mail-Followup-To: Sebastian Geerken <sgeerken at dillo.org>, Dillo mailing > list <dillo-dev at dillo.org> > > On Fri, Dec 14, Jorge Arellano Cid wrote: > > Just noticed this: > > > > Nav_open_url: new url='http://news.bress.net/search.php?feed=149' > > Dns_server [0]: news.bress.net is 67.205.59.213 > > Connecting to 67.205.59.213 > > NumPendingStyleSheets=1 > > *** [dillo/3.0.2] This should not happen! *** > > Aborted > > > > > > This is new, as dillo from Nov 14 doesn't exit. > > Any clues? > > Debugging shows the same issue as Alexander's problem: > > On Fri, Dec 14, Alexander Voigt wrote: > > with the current Dillo development version 2672:4d0bdcf10ee7 (Fri Dec > > 14 12:24:54 2012 +0100) I get a segfault when I try to access the > > Dillo bug database. > > > > [...] > > #3 _nextUtf8Char (s=<value optimized out>) at unicode.cc:92 > > #4 0x000000000047163c in lout::unicode::nextUtf8Char (s=0x98d10c "\267", > > len=1) at unicode.cc:114 > > #5 0x000000000044e8d0 in dw::Textblock::addText (this=<value optimized out>, > > text=0x98d10c "\267", len=<value optimized out>, > > style=<value optimized out>) at textblock.cc:1430 > > The HTML parser passes invalid UTF-8 to dw::Textblock. I will make > nextUtf8Char more robust (of course, dillo should not crash), but > Jorge's page is HTML, encoded in ISO-8859-1, not UTF-8, as seen here: > > 000009b0 34 38 22 3e 2d 20 4b 65 79 73 74 72 6f 6b 65 20 |48">- Keystroke | > 000009c0 4c 6f 67 67 69 6e 67 20 77 69 74 68 20 42 65 61 |Logging with Bea| > 000009d0 63 6f 6e 20 ab 20 53 74 72 61 74 65 67 69 63 20 |con . Strategic | > ^^ > > It seems that the Fltk functions do some checks, and sometimes decode > as ISO-8859-1. AFAIR from comments in fltk, some utf8 functions dealt with mixed latin1, utf8 and some windows codec. They got into it because the mix was inevitable for them. -- Cheers Jorge.-

Dec. 14, 2012

Fwd: Re: Dillo early exit

by sgeerken＠dillo.org

Somehow this post got lost ...

Dec. 14, 2012

Dillo early exit

by sgeerken＠dillo.org

On Fri, Dec 14, Sebastian Geerken wrote: > The HTML parser passes invalid UTF-8 to dw::Textblock. I will make > nextUtf8Char more robust (of course, dillo should not crash), ... Done. Both pages work now. Sebastian

Dec. 14, 2012

config.h.in

by p37sitdu＠lavabit.com

On Fri, Dec 14, 2012 at 10:34:13AM -0300, Jorge Arellano Cid wrote: > On Fri, Dec 14, 2012 at 01:10:11PM +0000, Jeremy Henty wrote: > > > > p37sitdu at lavabit.com wrote: > > > > > ^config\. is in .hgignore, bug config.h.in is tracked. It is > > > autogenerated, shouldn't it be removed from repo? > > > > Yes, it should. > > I'm not sure (my fault ;), but in practice: > > If removing it from the repo doesn't prevent "autogen.sh", > from building "configure"; and the "./configure; make" dance works > as usual, it should be ok to remove. On top of config.h.in there is a comment that says "Generated from configure.in by autoheader". "./autogen.sh; ./configure; make" works after removing config.h.in. By the way, configure.in is named configure.ac now. [1] autoconf shows a warning each time it sees configure.in. [1] https://www.gnu.org/software/autoconf/manual/autoconf.html#Writing-Autoconf…

Dec. 14, 2012

config.h.in

by jcid＠dillo.org

On Fri, Dec 14, 2012 at 01:10:11PM +0000, Jeremy Henty wrote: > > p37sitdu at lavabit.com wrote: > > > ^config\. is in .hgignore, bug config.h.in is tracked. It is > > autogenerated, shouldn't it be removed from repo? > > Yes, it should. I'm not sure (my fault ;), but in practice: If removing it from the repo doesn't prevent "autogen.sh", from building "configure"; and the "./configure; make" dance works as usual, it should be ok to remove. -- Cheers Jorge.-

Dec. 14, 2012

Segfault when opening Dillo bugs database

by Hole.destructor＠gmx.de

Dear Dillo developers, with the current Dillo development version 2672:4d0bdcf10ee7 (Fri Dec 14 12:24:54 2012 +0100) I get a segfault when I try to access the Dillo bug database. How to reproduce ================ 1. open www.dillo.org/bugtrack/Dquery.html 2. press the "Find it!" button in the "Bug type search" section 3. segfault gdb output and backtrace ======================== Nav_open_url: new url='http://www.dillo.org/cgi-bin/bugtrack/Dillo_query.cgi?what=all&Submit=Find+…' Connecting to 134.102.206.165 *** [dillo/3.0.2] This should not happen! *** Program received signal SIGABRT, Aborted. 0x00007ffff5eed1b5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden. in ../nptl/sysdeps/unix/sysv/linux/raise.c Current language: auto The current source language is "auto; currently c". (gdb) bt #0 0x00007ffff5eed1b5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff5eeffc0 in *__GI_abort () at abort.c:92 #2 0x0000000000471616 in assertNotReached (s=<value optimized out>) at misc.hh:38 #3 _nextUtf8Char (s=<value optimized out>) at unicode.cc:92 #4 0x000000000047163c in lout::unicode::nextUtf8Char (s=0x98d10c "\267", len=1) at unicode.cc:114 #5 0x000000000044e8d0 in dw::Textblock::addText (this=<value optimized out>, text=0x98d10c "\267", len=<value optimized out>, style=<value optimized out>) at textblock.cc:1430 #6 0x000000000042ee54 in Html_process_word (html=0x933960, buf=<value optimized out>, bufsize=<value optimized out>, Eof=<value optimized out>) at html.cc:1216 #7 Html_write_raw (html=0x933960, buf=<value optimized out>, bufsize=<value optimized out>, Eof=<value optimized out>) at html.cc:3923 #8 0x000000000042f6bc in DilloHtml::write (this=0x1bcb, Buf=<value optimized out>, BufSize=<value optimized out>, Eof=-1) at html.cc:531 #9 0x0000000000419fd3 in Cache_process_queue (entry=0x847120) at cache.c:1214 #10 0x00000000004167c9 in a_Chain_fcb (Op=7115, Info=<value optimized out>, Data1=<value optimized out>, Data2=<value optimized out>) at chain.c:114 #11 0x0000000000441cd3 in Dpi_parse_token (Op=<value optimized out>, ---Type <return> to continue, or q <return> to quit--- Branch=<value optimized out>, Dir=<value optimized out>, Info=<value optimized out>, Data1=<value optimized out>, Data2=0x0) at dpi.c:220 #12 Dpi_process_dbuf (Op=<value optimized out>, Branch=<value optimized out>, Dir=<value optimized out>, Info=<value optimized out>, Data1=<value optimized out>, Data2=0x0) at dpi.c:339 #13 a_Dpi_ccc (Op=<value optimized out>, Branch=<value optimized out>, Dir=<value optimized out>, Info=<value optimized out>, Data1=<value optimized out>, Data2=0x0) at dpi.c:735 #14 0x00000000004167c9 in a_Chain_fcb (Op=7115, Info=<value optimized out>, Data1=<value optimized out>, Data2=<value optimized out>) at chain.c:114 #15 0x000000000044223f in a_IO_ccc (Op=2, Branch=<value optimized out>, Dir=1, Info=0x7576a0, Data1=0x883af0, Data2=0x0) at IO.c:428 #16 0x000000000044246d in IO_read (io=0x883af0) at IO.c:197 #17 0x00000000004424ed in IO_callback (io=0x883af0) at IO.c:262 #18 0x00000000004425ec in IO_fd_read_cb (fd=8, data=<value optimized out>) at IO.c:283 #19 0x0000000000496932 in fl_wait(double) () #20 0x000000000047306b in Fl::wait(double) () #21 0x00000000004730db in Fl::run() () #22 0x000000000040810d in main (argc=1, argv=0x7fffffffe3d8) at dillo.cc:451 Could you please have a look at this issue? Kind regards, Alex

Dec. 14, 2012

config.h.in

by onepoint＠starurchin.org

p37sitdu at lavabit.com wrote: > ^config\. is in .hgignore, bug config.h.in is tracked. It is > autogenerated, shouldn't it be removed from repo? Yes, it should. Regards, Jeremy Henty

Dec. 14, 2012

Dillo early exit

by jcid＠dillo.org

Hi there, Just noticed this: Nav_open_url: new url='http://news.bress.net/search.php?feed=149' Dns_server [0]: news.bress.net is 67.205.59.213 Connecting to 67.205.59.213 NumPendingStyleSheets=1 *** [dillo/3.0.2] This should not happen! *** Aborted This is new, as dillo from Nov 14 doesn't exit. Any clues? -- Cheers Jorge.-

Dec. 14, 2012

config.h.in

by p37sitdu＠lavabit.com

^config\. is in .hgignore, bug config.h.in is tracked. It is autogenerated, shouldn't it be removed from repo?

Dec. 14, 2012

valgrind log entry hyphenation related?

by sgeerken＠dillo.org

On Sat, Dec 01, corvid wrote: > http://starurchin.org/dillo/valgrind/5eaf94da6ca698708497c27cd3d3a50730f6f9… I hope this is fixed now. Somehow, fl_utf8fwd has got problems, especially with strings, which are not 0-terminated. OTOH, I agreed with Johannes some time ago that the UTF-8 related methods should not be part dw::core::Platform, since UTF-8 handling is not platform dependant. For fl_utf8fwd (or, Platform::nextGlyph, respectively), there is a replacement, lout::unicode::nextUtf8Char. Anything else could be completed after the release (unless there are severe problems). Parts of Fltk can be copied: the respective code is in the public domain. Sebastian

Dec. 14, 2012

BUG#1108

by jcid＠dillo.org

Hi there, This bug is a feature request: Bug: 1108 Impact: feature fault At: run time Type: other Comments: 3.0.2 Dillo goes to last viewed tab when closing a tab but when we use focus_new_tab=NO then we would like an option for when closing current tab Dillo would go to last *opened* tab (because we open tabs in the background). HTReproduce: ? focus_new_tab=NO in dillorc ? Open tab1 then a new tab2 and go to tab2 ? Open tabs in the background (tab3, tab4, tab5) with middle-clicks on links ? Close current tab2 ? Dillo focuses tab1 instead of tab5 ? new option: close_tab_focus=last_opened I just pushed a patch that sets this behaviour as default. The question is: Is it worth adding a dillorc option for this? -- Cheers Jorge.-

Dec. 14, 2012

Patch for xembed (text corrected)

by Johannes.Hofmann＠gmx.de

Hi, I test xembed support with the claws mail dillo plugin[1] and tabbed[2]. My guess is that the embedder needs to send some X events to the embedded program (dillo in this case) to make it work properly. Even with your patch dillo doesn't resize properly for me when I change the embedding window. I would look into the tabbed source code[2], which is pretty minimal. Cheers, Johannes [1] http://www.claws-mail.org/plugin.php?plugin=dillo [2] http://tools.suckless.org/tabbed/ On Mon, Dec 10, 2012 at 02:12:34PM +0100, podarcis wrote: > 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 > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 11, 2012

Tooltip bugs revisited

by corvid＠lavabit.com

Jorge wrote: > So far (and despite the warning inside FLTK), I've experimented > with a custom tooltip handling class, and a couple custom UI > widgets, that seem to work well together (i.e. solve the problem > without the workaround :) ). I see that this code is derived from the code at http://seriss.com/people/erco/fltk/#SliderTooltip I think we should mention that at the tops of the tipwin files and in AUTHORS.

Dec. 11, 2012

complex button layout and bgColor

by corvid＠lavabit.com

All of the copies of dillo that I happen to have around from the dillo3 era break on: <body text=white bgcolor=purple> <form> <button style="margin-top:200px">inside</button> </form> </body> I can get the purple if I add diff -r 0c1b7af7bf72 dw/ui.cc --- a/dw/ui.cc Mon Dec 10 22:55:07 2012 +0000 +++ b/dw/ui.cc Tue Dec 11 01:24:32 2012 +0000 @@ -285,6 +285,7 @@ layout = new Layout (createPlatform ()); setLayout (layout); layout->setWidget (widget); + layout->setBgColor (widget->getStyle()->backgroundColor); layout->connect (&layoutReceiver); } but I don't know how this is supposed to fit together.

Dec. 11, 2012

Patch for xembed (text corrected)

by podarcis＠lavabit.com

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

Dec. 10, 2012

Patch for xembed

by podarcis＠lavabit.com

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: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I do not know enough of the embedding stuff, but I wonder if the static int event_handler~~~~~~~~~~~~~~~ #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. podarcis

Dec. 10, 2012