December 2012 - Dillo-dev - lists.mailman3.com

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