- Dillo-dev - lists.mailman3.com

[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