- Dillo-dev - lists.mailman3.com

forms related segfault

by Johannes.Hofmann＠gmx.de

Hello, when I go to e.g. www.google.com enter a search, click submit and then when the result page shows up hit Enter, I always get a segfault: Program received signal SIGSEGV, Segmentation fault. loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, argc=2, argv=0xbfbff2dc) at container.hh:93 93 inline Iterator iterator() { Iterator it(createIterator()); return it; } (gdb) bt #0 loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, argc=2, argv=0xbfbff2dc) at container.hh:93 #1 0x08084367 in dw::core::ui::Resource::ActivateEmitter::emitActivate ( this=0x28661208, resource=0x28661200) at ui.cc:109 #2 0x080909d3 in fltk::Widget::do_callback (this=0x28661280) at Widget.h:125 #3 0x080ab6d1 in fltk::Input::handle_key (this=0x28661280) at Input.cxx:1267 #4 0x080abe42 in fltk::Input::handle (this=0x28661280, event=8, r=@0xbfbff414) at Input.cxx:1469 #5 0x080ac66b in fltk::Input::handle (this=0x28661280, event=8) at Input.cxx:1384 #6 0x080dfac2 in fltk::Widget::send (this=0x28661280, event=8) at Widget.cxx:805 #7 0x080be6dd in fltk::handle (event=8, window=0x28540000) at run.cxx:1287 #8 0x080c4bf4 in fltk::handle () at run.cxx:1947 #9 0x080c4c38 in do_queued_events () at run.cxx:396 #10 0x080c4f52 in fl_wait (time_to_wait=1.00000002e+20) at run.cxx:456 #11 0x080c4fed in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:457 #12 0x080c5104 in fltk::run () at run.cxx:393 #13 0x0804e714 in main (argc=Error accessing memory address 0x0: Bad address. ) at dillo.cc:107 I think it has to do with the input form of the previous page somehow still being activ. Jorge, do you know what happens to the fltk widgets like buttons or inputs, when a new page gets loaded? Are the deleted, and if so where in the code does this happen? Cheers, Johannes

Nov. 8, 2007

PATCH: adds the ' entity

by jcid＠dillo.org

On Wed, Nov 07, 2007 at 06:36:58PM +0000, Jeremy Henty wrote: > On Wed, Nov 07, 2007 at 02:58:32PM -0300, Jorge Arellano Cid wrote: > > On Sun, Nov 04, 2007 at 09:07:20AM +0000, Jeremy Henty wrote: > > > > > > Is it dillo's policy to include *only* HTML 4.01 entities. > > > > Yes, our current policy is only HTML 4.01 entities. > > The spirit of the idea is similar to: > > > > http://fishbowl.pastiche.org/2003/07/01/the_curse_of_apos > > Thanks for the link. I see that ' *is* valid XML. Is that > relevant to dillo? Yes, but in the future. To parse xhtml, we have to validate the page, and that is currently not implemented in the parser. > > Of course sometimes standards are so badly violated that we can't > > but end supporting bad HTML (but raising a warning). > > Yes, I'm very aware that parsing real-life HTML is a thankless task. :-P -- Cheers Jorge.-

Nov. 7, 2007

Re: new browser windows slower than first one

by Johannes.Hofmann＠gmx.de

Hi Jorge, I fully agree with your comments on my buffering patch. We should focus on the real solution, which is to fix the fltk library and then use their code for offscreen drawing. Whoever needs it can apply the patch manually. Regarding the frequent redraws I made the following observations: * Redraw requests are accumulated by fltk and then result in a single redraw when fltk thinks it should actually do the drawing. * Current code issues a full redraw request even if only part of the screen needs redrawing. This is a commented deficiancy and can be fixed quite easily. However there are so many full redraw requests, that one will hardly see any difference by that change. * Most full redraw requests come from Layout::queueResize() which in turn causes Layout::resizeIdle() to be called when fltk is idle for a moment. Every change of the size of a widget may change the whole layout on the screen and therefore require a complete redraw. If I understand the code correctly this is the similar in dillo1. So what can we do? For the second point I can provide a patch that accumulates screen regions that need redrawing until fltk actually redraws. The last point is more difficult to improve. For example think of a long page containing just text. Every time a new chunk comes in over the net, dillo creates a redraw request for the whole screen, even though there is already enough text to fill the screen so that the new data does not actually change the layout of the part that is currently visible. But how can we know, whether new data changes the layout of the currently visible part or not? The only rather simple improvement I can think of is that we could use the image sizes provided in the <img/> tags and only issue a Layout::queueResize() if the image proves to be of a different size. Currently there is a Layout::queueResize() for every image as it gets loaded. Regards, Johannes

Nov. 7, 2007

PATCH: adds the ' entity

by onepoint＠starurchin.org

On Wed, Nov 07, 2007 at 02:58:32PM -0300, Jorge Arellano Cid wrote: > On Sun, Nov 04, 2007 at 09:07:20AM +0000, Jeremy Henty wrote: > > > > Is it dillo's policy to include *only* HTML 4.01 entities. > > Yes, our current policy is only HTML 4.01 entities. > The spirit of the idea is similar to: > > http://fishbowl.pastiche.org/2003/07/01/the_curse_of_apos Thanks for the link. I see that ' *is* valid XML. Is that relevant to dillo? > Of course sometimes standards are so badly violated that we can't > but end supporting bad HTML (but raising a warning). Yes, I'm very aware that parsing real-life HTML is a thankless task. Regards, Jeremy Henty

Nov. 7, 2007

PATCH: adds the ' entity

by jcid＠dillo.org

On Sun, Nov 04, 2007 at 09:07:20AM +0000, Jeremy Henty wrote: > > Is it dillo's policy to include *only* HTML 4.01 entities. If not, > here's a patch to add the ' entity, which appears all over the > place despite not being official HTML 4.01. Yes, our current policy is only HTML 4.01 entities. The spirit of the idea is similar to: http://fishbowl.pastiche.org/2003/07/01/the_curse_of_apos Of course sometimes standards are so badly violated that we can't but end supporting bad HTML (but raising a warning). -- Cheers Jorge.-

Nov. 7, 2007

Re: Accept-Encoding: gzip

by jcid＠dillo.org

Hi, On Mon, Nov 05, 2007 at 10:46:09PM +0000, place wrote: > What would you think of something like the code I have attached? I'd like to have gzip decoding in dillo2. > I had looked at the gzip portion of the i18n patch, just intending to put it > in my own copy, but it was unsatisfactory in some ways, so I ended up > changing the whole thing and this was the result. It looks quite advanced and that giving it a second pass on simplicity/elegance it'd be ready. > > Bad: 1. I stuck an awful lot of things into CacheEntry_t. Yes. IMO, having only: Dstr *EncodedData; char *Encoding; added to CacheEntry_t is cleaner. (we can add a Dstr_get_size() if necessary). > 2. During the downloading/decoding process, there is Data and > DecodedData. It gets fixed up afterward, but it means that things like > trying to view source during downloading does not work. I imagine the > fix being something like changing Data to RawData, DecodedData to Data, > freeing RawData after download is complete, and looking at all of the > current references to Data to figure out which of those they should > use. But I'll leave that for after I find out what you think of what I > have so far. From a design point of view, I'd prefer the decoding functions in a separate source file, that way, new decoders may be added easily and decoding complexity gets out of the cache part (the decoding internal state moves from the Cache entry to the decoding module, and decoding functions can be reused or extended). If we think of decoding as one part in a pipeline, null-decoding is what we have now, and gzip-decoding what we'd make for gzip. That way we can keep only one path for the data stream, and null-decode or gzip-decode into 'Data' when we need it. This solves the problem of using 'Data' while decoding naturally, because it is perceived as it always was (new-bytes from a stream), the only difference being they now come pushed from a decoder instead of the net (quite transparent). > Good: 1. Faster! > > 2. Faster! Yes. I can't wait to try it under a telephone line modem next week. :-) BTW, do you plan to make the linkblock/callback patch for html.cc (analog to plain.cc) or do you prefer me to work on it? -- Cheers Jorge.-

Nov. 7, 2007

Re: new browser windows slower than first one

by jcid＠dillo.org

Hi Johannes, On Tue, Nov 06, 2007 at 08:51:15PM +0100, Johannes Hofmann wrote: > Hi, > > here is a patch to avoid the flickering even with > clear_double_buffer() as currently in CVS. It uses a self-made > double buffering for those drawing operations that need it (as it was > done in dillo1). The main advantage over generally switching on > double buffering, is that we need only one buffer for all > windows, which saves X-server side memory and avoids slowdowns with > many open windows. Yes, and it works much better than what we have now... > However this approach has some drawbacks: > > * The newly introduced FltkOffscreen class contains X11 specific > code and it would be better if this could be done by fltk. > But unfortunately there is an open bug > (http://www.fltk.org/str.php?L1042) Yes. One of the main advanteges of relying completely on fltk2 for drawing is that porting fltk2 to a new backend, makes dillo2 automatically work there too. Some people long for OpenGl, others the framebuffer, etc. > * When you compile fltk with the --disable-xft option you now need > to do "export CPPFLAGS=-DNO_XFT" before configuring dw-testbed. `fltk2-config --ldflags` reports on "-lXft". Maybe it can be used in configure.in as a test and thus, set CPPFLAGS automatically. > * It makes the redraws invisible again, which we might want to > reduce by other means. Yes, this is the key point. The main reason of leaving double buffering out is to remember that drawing needs an urgent fix. The number of redraws is not acceptable, and double buffering conceals it. I understand the need to reduce the annoying flickering, and huge memory footprint, but hesitate to commit the patch as is because it could stop people from porting fltk2 to a new backend when they need a browser. If you can add it as a compile time option (e.g. --with-internal-buffering) and automate the CPPFLAGS setting from configure, I'd commit. Now, what I'd really like is to reduce the number of redraws (an ugly bug) and to have an fltk2 means to make calls to X11. If you can work on the first task, it's more than welcomed. For the second one we need to coordinate with the fltk2 team. What do you think of this? > > Jorge, regardless of whether you want to apply this patch, could you > please apply the > > @@ -225,15 +239,7 @@ void FltkViewBase::queueDraw (core::Rect > { > /** \bug Inefficient */ > > - push_clip( > - translateCanvasXToViewX (area->x), > - translateCanvasYToViewY (area->y), > - area->width, > - area->height); > - > redraw (DAMAGE_EXPOSE); > - > - pop_clip(); > } > > > part, which removes some calls added with my initial scrolling > patch. These calls are just wrong. push_clip/pop_clip can only be > called from within the draw() method. Out of place push/pop pair removal, commited. -- Cheers Jorge.-

Nov. 7, 2007

Re: new browser windows slower than first one

by Johannes.Hofmann＠gmx.de

Hi, here is a patch to avoid the flickering even with clear_double_buffer() as currently in CVS. It uses a self-made double buffering for those drawing operations that need it (as it was done in dillo1). The main advantage over generally switching on double buffering, is that we need only one buffer for all windows, which saves X-server side memory and avoids slowdowns with many open windows. However this approach has some drawbacks: * The newly introduced FltkOffscreen class contains X11 specific code and it would be better if this could be done by fltk. But unfortunately there is an open bug (http://www.fltk.org/str.php?L1042) * When you compile fltk with the --disable-xft option you now need to do "export CPPFLAGS=-DNO_XFT" before configuring dw-testbed. * It makes the redraws invisible again, which we might want to reduce by other means. Jorge, regardless of whether you want to apply this patch, could you please apply the @@ -225,15 +239,7 @@ void FltkViewBase::queueDraw (core::Rect { /** \bug Inefficient */ - push_clip( - translateCanvasXToViewX (area->x), - translateCanvasYToViewY (area->y), - area->width, - area->height); - redraw (DAMAGE_EXPOSE); - - pop_clip(); } part, which removes some calls added with my initial scrolling patch. These calls are just wrong. push_clip/pop_clip can only be called from within the draw() method. Regards, Johannes diff --git a/dw/Makefile.am b/dw/Makefile.am --- a/dw/Makefile.am +++ b/dw/Makefile.am @@ -45,7 +45,9 @@ libDw_fltk_a_SOURCES = \ fltkviewbase.cc \ fltkviewbase.hh \ fltkviewport.cc \ - fltkviewport.hh + fltkviewport.hh \ + fltkoffscreen.cc \ + fltkoffscreen.hh libDw_fltk_a_CXXFLAGS = @LIBFLTK_CXXFLAGS@ diff --git a/dw/fltkoffscreen.cc b/dw/fltkoffscreen.cc new file mode 100644 --- /dev/null +++ b/dw/fltkoffscreen.cc @@ -0,0 +1,104 @@ +/* + * Dillo Widget + * + * Copyright 2005-2007 Sebastian Geerken <sgeerken(a)dillo.org> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + + +#include <fltk/x11.h> + +#ifndef NO_XFT +#include <X11/Xft/Xft.h> +#endif + + +#include "fltkoffscreen.hh" + +using namespace fltk; + +namespace dw { +namespace fltk { + +FltkOffscreen::FltkOffscreen () { + w = 0; + h = 0; + pixmap = 0; + this->xftc = NULL; +} + + +FltkOffscreen::~FltkOffscreen () { + if (pixmap) { + XFreePixmap(xdisplay, pixmap); + } +#ifndef NO_XFT + if (this->xftc) { + XftDrawDestroy((XftDraw*) this->xftc); + } +#endif +} + + +void FltkOffscreen::begin (int w, int h) { + gsave = new GSave(); + + if (!pixmap || w > this->w || h > this->h) { + if (pixmap) { + XFreePixmap (xdisplay, pixmap); + } + pixmap = XCreatePixmap (xdisplay, xwindow, w, h, xvisual->depth); + +#ifndef NO_XFT + if (!this->xftc) { + this->xftc = XftDrawCreate(xdisplay, pixmap, + xvisual->visual, xcolormap); + } else { + XftDrawChange ((XftDraw*) this->xftc, pixmap); + } +#endif + + this->w = w; + this->h = h; + } + + saveWindow = xwindow; + xwindow = pixmap; +#ifndef NO_XFT + saveXftc = ::fltk::xftc; + ::fltk::xftc = (XftDraw*) this->xftc; +#endif + push_no_clip(); +} + + +void FltkOffscreen::end () { + pop_clip(); + xwindow = saveWindow; +#ifndef NO_XFT + ::fltk::xftc = (XftDraw*) saveXftc; +#endif + delete gsave; +} + + +void FltkOffscreen::draw (const ::fltk::Rectangle &area, int srcx, int srcy) { + XCopyArea(xdisplay, pixmap, xwindow, gc, srcx, srcy, + area.w(), area.h(), area.x(), area.y()); +} + +} // namespace fltk +} // namespace dw diff --git a/dw/fltkoffscreen.hh b/dw/fltkoffscreen.hh new file mode 100644 --- /dev/null +++ b/dw/fltkoffscreen.hh @@ -0,0 +1,34 @@ +#ifndef __DW_FLTKOFFSCREEN_HH__ +#define __DW_FLTKOFFSCREEN_HH__ + +#include <fltk/Rectangle.h> +#include <fltk/draw.h> + +namespace dw { +namespace fltk { + +class FltkOffscreen +{ +private: + int w; + int h; + unsigned long pixmap; + unsigned long saveWindow; + void *xftc; /* void* to avoid to include Xft/Xft.h */ + void *saveXftc; + ::fltk::GSave *gsave; + +public: + FltkOffscreen (); + ~FltkOffscreen (); + + void begin (int w, int h); + void end (); + void draw (const ::fltk::Rectangle &area, int srcx, int srcy); +}; + +} // namespace fltk +} // namespace dw + +#endif // __DW_FLTKOFFSCREEN_HH__ + diff --git a/dw/fltkviewbase.cc b/dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc +++ b/dw/fltkviewbase.cc @@ -18,15 +18,12 @@ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ - - #include "fltkviewport.hh" #include <fltk/draw.h> #include <fltk/damage.h> #include <fltk/events.h> #include <fltk/Cursor.h> - #include <stdio.h> using namespace fltk; @@ -36,12 +33,19 @@ namespace dw { namespace dw { namespace fltk { +FltkOffscreen *FltkViewBase::backBuffer; + FltkViewBase::FltkViewBase (int x, int y, int w, int h, const char *label): Group (x, y, w, h, label) { canvasWidth = 1; canvasHeight = 1; bgColor = WHITE; + + if (!backBuffer) { + backBuffer = new FltkOffscreen(); + } + } FltkViewBase::~FltkViewBase () @@ -50,14 +54,19 @@ FltkViewBase::~FltkViewBase () void FltkViewBase::draw () { - Group::draw (); - + int d = damage(); ::fltk::Rectangle rect (x(), y(), w(), h()); /* fltk-clipping seems not to use widget coordinates */ ::fltk::intersect_with_clip(rect); rect.x(rect.x() - x()); rect.y(rect.y() - y()); + + if (!(d & DAMAGE_SCROLL)) { + backBuffer->begin(rect.w(), rect.h()); + + translate(-rect.x()-x() , -rect.y()-y() ); + } setcolor (bgColor); fillrect (rect); @@ -68,6 +77,11 @@ void FltkViewBase::draw () area.width = rect.w(); area.height = rect.h(); theLayout->expose (this, &area); + + if (!(d & DAMAGE_SCROLL)) { + backBuffer->end(); + backBuffer->draw(Rectangle(rect.x() + x(), rect.y() + y(), rect.w(), rect.h()), 0, 0); + } } core::ButtonState getDwButtonState () @@ -162,7 +176,7 @@ void FltkViewBase::setCanvasSize (int wi void FltkViewBase::setCursor (core::style::Cursor cursor) { - static Cursor *mapDwToFltk[] = { + static ::fltk::Cursor *mapDwToFltk[] = { CURSOR_CROSS, CURSOR_ARROW, CURSOR_HAND, @@ -225,15 +239,7 @@ void FltkViewBase::queueDraw (core::Rect { /** \bug Inefficient */ - push_clip( - translateCanvasXToViewX (area->x), - translateCanvasYToViewY (area->y), - area->width, - area->height); - redraw (DAMAGE_EXPOSE); - - pop_clip(); } void FltkViewBase::queueDrawTotal () diff --git a/dw/fltkviewbase.hh b/dw/fltkviewbase.hh --- a/dw/fltkviewbase.hh +++ b/dw/fltkviewbase.hh @@ -5,7 +5,7 @@ #include <fltk/Scrollbar.h> #include "fltkcore.hh" -#include "fltkcore.hh" +#include "fltkoffscreen.hh" namespace dw { namespace fltk { @@ -14,6 +14,7 @@ class FltkViewBase: public FltkView, pub { private: int bgColor; + static FltkOffscreen *backBuffer; protected: core::Layout *theLayout;

Nov. 6, 2007

"signal" name collision

by Johannes.Hofmann＠gmx.de

Hello, > > > [Johannes wrote] > > > * the namespace "signal" in dw-testbed/lout/signal.hh conflicts with > > > the declaration in /usr/include/sys/signal.h: > > > __sighandler_t *signal (int, __sighandler_t *); > > > I renamed the namespace to loutsignal. > > > > Johannes: please send me the patch for this. > > As only I seem to have these problems it might well be a problem of > DragonFly BSD. So I would like to check that first before changing > the nice an simple names in the lout library. > I just looked into this issue once again and it seems that in principle the problem exists on Linux too. If you try to compile: #include <signal.h> namespace signal {} e.g. with "g++ -c namespace.cc", I get an error on Linux too. It's just that only DragonFly happens to (indirectly) include signal.h in the current dillo sources and Linux does not. So as soon as we need to include signal.h directly, we will have the problem on all platforms. I don't really understand the use of namespaces in the lout library. Instead of wrapping each class / feature in it's own namespace, I would have expected a single "lout" namespace containing classes like signal, container etc. This would also solve the name clash with signal.h. However Sebastian has certainly had his reasons for the current setup, so I don't want to make a patch for a drastic change like that without his comments. Regards, Johannes

Nov. 6, 2007

Crashes on OpenBSD

by jcid＠dillo.org

On Mon, Nov 05, 2007 at 05:51:17PM +0100, Johannes Hofmann wrote: > Ok, here is a patch that removes the LIBC5 special case and > uses getaddrinfo() also if --disable-threaded-dns is specified. > As far as I could see there were no real differences other than > logging between Dns_server() and Dns_blocking_server(), or am I > missing something? Commited. They're basically the same, but Dns_server runs in a thread and doesn't block the browser (with a max. of 4). The other blocks until the resolving function returns. It looks ok. -- Cheers Jorge.-

Nov. 5, 2007

dillo hogs during text selection

by matthias.franz＠ujf-grenoble.fr

Hi, I have observed that dillo2 may hog during text selection. For example, take the page http://www-fourier.ujf-grenoble.fr/~franz/convex/doc/current/ . Go to some place in the table of contents, press the left mouse button and move the cursor around quickly so that the selected text changes all the time. After less a second, dillo becomes unresponsive and consumes all CPU time. This page also shows two additional issues: - There is no spacing between list items when the second item has less indentation than the first. (Look at the lines "mat - matrices" and "Types for affine ...".) - When the window size is increased, the vertical scroll bar suddenly disappears at a certain width and reappears below that width. (On my screen, this happens between 835 to 836 pixels.) In fact, the scroll bar is still there in the sense that line breaking leaves enough space for the bar. (I have reported this issue already before.) Cheers, -- Matthias Franz

Nov. 5, 2007

Crashes on OpenBSD

by Johannes.Hofmann＠gmx.de

Ok, here is a patch that removes the LIBC5 special case and uses getaddrinfo() also if --disable-threaded-dns is specified. As far as I could see there were no real differences other than logging between Dns_server() and Dns_blocking_server(), or am I missing something? Cheers, Johannes diff --git a/src/dns.c b/src/dns.c --- a/src/dns.c +++ b/src/dns.c @@ -39,11 +39,6 @@ * Uncomment the following line for debugging or gprof profiling. */ /* #undef D_DNS_THREADED */ - -/* - * Uncomment the following line for libc5 optimization - */ -/* #define LIBC5 */ /* Maximum dns resolving threads */ @@ -224,22 +219,8 @@ void a_Dns_init(void) /* * Allocate a host structure and add it to the list */ -static void Dns_note_hosts(Dlist *list, int af, struct hostent *host) -{ - int i; - if (host->h_length > DILLO_ADDR_MAX) - return; - for (i = 0; host->h_addr_list[i]; i++) { - DilloHost *dh = dNew0(DilloHost, 1); - dh->af = af; - dh->alen = host->h_length; - memcpy(&dh->data[0], host->h_addr_list[i], (size_t)host->h_length); - dList_append(list, dh); - } -} - -static void Dns_note_hosts2(Dlist *list, struct addrinfo *res0) +static void Dns_note_hosts(Dlist *list, struct addrinfo *res0) { struct addrinfo *res; DilloHost *dh; @@ -282,7 +263,6 @@ static void Dns_note_hosts2(Dlist *list, } } -#ifdef D_DNS_THREADED /* * Server function (runs on its own thread) */ @@ -314,7 +294,7 @@ static void *Dns_server(void *data) else if (h_errno == EAI_FAIL) MSG("DNS error: NO_RECOVERY\n"); } else { - Dns_note_hosts2(hosts, res0); + Dns_note_hosts(hosts, res0); dns_server[channel].status = 0; freeaddrinfo(res0); } @@ -334,67 +314,7 @@ static void *Dns_server(void *data) return NULL; /* (avoids a compiler warning) */ } -#endif -#ifndef D_DNS_THREADED -/* - * Blocking server-function (it doesn't use threads) - */ -static void Dns_blocking_server(void) -{ - int channel = 0; - struct hostent *host = NULL; - Dlist *hosts = dList_new(2); -#ifdef LIBC5 - int h_err; -#endif - - DEBUG_MSG(3, "Dns_blocking_server: starting...\n"); - DEBUG_MSG(3, "Dns_blocking_server: dns_server[%d].hostname = %s\n", - channel, dns_server[channel].hostname); - -#ifdef ENABLE_IPV6 - if (ipv6_enabled) { - host = gethostbyname2(dns_server[channel].hostname, AF_INET6); - if (host) { - Dns_note_hosts(hosts, AF_INET6, host); - } - } -#endif - -#ifdef LIBC5 - host = gethostbyname_r(dns_server[channel].hostname, &sh, buff, - sizeof(buff), &h_err); -#else - host = gethostbyname(dns_server[channel].hostname); -#endif - - if (!host) { -#ifdef LIBC5 - dns_server[channel].status = h_err; -#else - dns_server[channel].status = h_errno; -#endif - } else { - Dns_note_hosts(hosts, AF_INET, host); - } - if (dList_length(hosts) > 0) { - /* at least one entry on the list is ok */ - dns_server[channel].status = 0; - } else { - dList_free(hosts); - hosts = NULL; - } - - /* write IP to server data channel */ - DEBUG_MSG(3, "Dns_blocking_server: IP of %s is %p\n", - dns_server[channel].hostname, hosts); - dns_server[channel].addr_list = hosts; - dns_server[channel].ip_ready = TRUE; - - DEBUG_MSG(3, "Dns_blocking_server: leaving...\n"); -} -#endif /* * Request function (spawn a server and let it handle the request) @@ -426,7 +346,7 @@ static void Dns_server_req(int channel, pthread_create(&dns_server[channel].th1, &thrATTR, Dns_server, INT2VOIDP(dns_server[channel].channel)); #else - Dns_blocking_server(); + Dns_server(0); #endif }

Nov. 5, 2007

Crashes on OpenBSD

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Mon, Nov 05, 2007 at 12:38:16PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Sun, Nov 04, 2007 at 01:48:50PM +0100, Johannes Hofmann wrote: > > Hello, > > > > as I'm also using a BSD system, I converted the D_DNS_THREADED code > > to use the inherently thread-safe getaddrinfo(3) interface that also has > > some other advantages (e.g. a predictable ordering of the returned > > addresses). > > Jorge, what do you think about this? Are there supported platforms > > that do not have getaddrinfo? Should we add a compile option for > > this? > > I gave it a look. > > AFAIS there're a few ways to do it. > > Considering that getaddrinfo is thread-safe by definition and also > inside POSIX, it's a good candidate. The gethostbyname* family is > thread-safe in glibc2, but who knows in other libraries. > > dns.c has too much #defines for my taste (yes, I wrote it! ;-), > and getting rid of the libc5 lines may also help simplicity. Exactly. > > I'd say, get the current CVS (patch applied), please also convert > Dns_blocking_server to getaddrinfo, and get rid of libc5 lines. > That way we end with a cleaner dns.c and will know for sure who still > may need the missing lines, because they can ask in dillo-dev. Ok, I will do that. I also think we should keep the Dns_blocking_server for now. > > OTOH, if we provide all the options at compile time, we may end > not knowing whether they're still used or not. Very true. Cheers, Johannes

Nov. 5, 2007

Crashes on OpenBSD

by jcid＠dillo.org

Hi Johannes, On Sun, Nov 04, 2007 at 01:48:50PM +0100, Johannes Hofmann wrote: > Hello, > > as I'm also using a BSD system, I converted the D_DNS_THREADED code > to use the inherently thread-safe getaddrinfo(3) interface that also has > some other advantages (e.g. a predictable ordering of the returned > addresses). > Jorge, what do you think about this? Are there supported platforms > that do not have getaddrinfo? Should we add a compile option for > this? I gave it a look. AFAIS there're a few ways to do it. Considering that getaddrinfo is thread-safe by definition and also inside POSIX, it's a good candidate. The gethostbyname* family is thread-safe in glibc2, but who knows in other libraries. dns.c has too much #defines for my taste (yes, I wrote it! ;-), and getting rid of the libc5 lines may also help simplicity. I'd say, get the current CVS (patch applied), please also convert Dns_blocking_server to getaddrinfo, and get rid of libc5 lines. That way we end with a cleaner dns.c and will know for sure who still may need the missing lines, because they can ask in dillo-dev. OTOH, if we provide all the options at compile time, we may end not knowing whether they're still used or not. -- Cheers Jorge.-

Nov. 5, 2007

Quick question about font_factor in dillorc2

by jcid＠dillo.org

On Mon, Nov 05, 2007 at 12:44:30PM +0000, Jeremy Henty wrote: > On Mon, Nov 05, 2007 at 09:28:25AM -0300, Jorge Arellano Cid wrote: > > On Sun, Nov 04, 2007 at 08:01:48AM +0000, Jeremy Henty wrote: > > > > Just out of interest, is there any reason why the default dillorc2 > > > sets font_factor to 1.5? > > > > Yes. It slipped out of my dillorc (I'm using a high resolution > > laptop). > > Ah, I wondered if that was it! > > > I think 1.2 is better, but hope the current 1.0 to bring comments! > > I think 1.0 is fine (1280 x 1024 desktop on a 17 inch monitor). It's > a little small, and I might increase font_factor if I started getting > eyestrain or the monitor was poorer quality. On a 1440x900 14 inch LCD, 1.5 is fine for me. It looks like 1.2 is a good default. -- Cheers Jorge.-

Nov. 5, 2007

Re: patch: hiding widgets

by jcid＠dillo.org

On Sun, Nov 04, 2007 at 01:03:51AM +0000, place wrote: > I made this customize() pretty much a copy of the 0.8.x customize(). Commited. > In testing, I saw that playing with the panel_cb a lot makes things crashy > (that is, equally crashy with and without this code). Is that general area > of the UI permanent enough for there to be any point in taking notice of it? The idea was to test on-the-fly resizing. Hoping for FLTK2-savvy guys to come later with some advice on how its done. -- Cheers Jorge.-

Nov. 5, 2007

Quick question about font_factor in dillorc2

by onepoint＠starurchin.org

On Mon, Nov 05, 2007 at 09:28:25AM -0300, Jorge Arellano Cid wrote: > On Sun, Nov 04, 2007 at 08:01:48AM +0000, Jeremy Henty wrote: > > Just out of interest, is there any reason why the default dillorc2 > > sets font_factor to 1.5? > > Yes. It slipped out of my dillorc (I'm using a high resolution > laptop). Ah, I wondered if that was it! > I think 1.2 is better, but hope the current 1.0 to bring comments! I think 1.0 is fine (1280 x 1024 desktop on a 17 inch monitor). It's a little small, and I might increase font_factor if I started getting eyestrain or the monitor was poorer quality. Regards, Jeremy Henty

Nov. 5, 2007

Quick question about font_factor in dillorc2

by jcid＠dillo.org

On Sun, Nov 04, 2007 at 08:01:48AM +0000, Jeremy Henty wrote: > Just out of interest, is there any reason why the default dillorc2 > sets font_factor to 1.5? Yes. It slipped out of my dillorc (I'm using a high resolution laptop). :-) > It seems unreasonably large to me, and I > personally much prefer to comment it out. Anyone else have feelings > one way or the other? Now it's set to 1.0. I think 1.2 is better, but hope the current 1.0 to bring comments! ;-) -- Cheers Jorge.-

Nov. 5, 2007

Crashes on OpenBSD

by Christian.Kellermann＠nefkom.net

* Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [071104 14:50]: > Hello, > > as I'm also using a BSD system, I converted the D_DNS_THREADED code > to use the inherently thread-safe getaddrinfo(3) interface that also has > some other advantages (e.g. a predictable ordering of the returned > addresses). Thanks, I will try this. Is you git repo public? Regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Nov. 4, 2007

Re: image loading from menus

by jcid＠dillo.org

Hi, On Sat, Nov 03, 2007 at 11:18:36PM +0000, place wrote: > Jorge wrote: > > After some study and a reimplentation of plain.cc with classes > > (getting rid of its linkblock and hooking a callback for memory > > handling), it looks simpler and better. It looks like the same > > may be done with html.cc. > > I was just wondering how you weigh the options of adding a callback > vs. adding a signal. I had experimented with a destroy signal in > my tree recently. It seemed more consistent to me, although I suspect > the various child widgets were wasting cycles on signal emission code > when they didn't have any receivers... I'd say that for me, the key is simplicity, and elegance. In a sense, accurately captured by this quote: "The key to performance is elegance, not batalions of special cases" -- Jon Bentley and Doug McIlroy In the case of Dillo, I've seen several times the simplicity pay off. When code gets simpler, debugging and improving accelerates. With complexity it stagnates. Elegance helps to keep the design simple and flexible. Having flexibilty in the design, helps to tackle unforeseen problems at the design level, without workarounds, reducing complexity and special cases. -- Cheers Jorge.-

Nov. 4, 2007

Crashes on OpenBSD

by Johannes.Hofmann＠gmx.de

Hello, as I'm also using a BSD system, I converted the D_DNS_THREADED code to use the inherently thread-safe getaddrinfo(3) interface that also has some other advantages (e.g. a predictable ordering of the returned addresses). Jorge, what do you think about this? Are there supported platforms that do not have getaddrinfo? Should we add a compile option for this? Johannes diff --git a/src/dns.c b/src/dns.c --- a/src/dns.c +++ b/src/dns.c @@ -239,58 +239,86 @@ static void Dns_note_hosts(Dlist *list, } } +static void Dns_note_hosts2(Dlist *list, struct addrinfo *res0) +{ + struct addrinfo *res; + DilloHost *dh; + + for (res = res0; res; res = res->ai_next) { + + if (res->ai_family == AF_INET) { + struct sockaddr_in *in_addr; + + if (res->ai_addrlen < sizeof(struct sockaddr_in)) { + continue; + } + + dh = dNew0(DilloHost, 1); + dh->af = AF_INET; + + in_addr = (struct sockaddr_in*) res->ai_addr; + dh->alen = sizeof (struct in_addr); + memcpy(&dh->data[0], &in_addr->sin_addr.s_addr, dh->alen); + + dList_append(list, dh); +#ifdef ENABLE_IPV6 + } else if (res->ai_family == AF_INET6) { + struct sockaddr_in6 *in6_addr; + + if (res->ai_addrlen < sizeof(struct sockaddr_in6)) { + continue; + } + + dh = dNew0(DilloHost, 1); + dh->af = AF_INET6; + + in6_addr = (struct sockaddr_in6*) res->ai_addr; + dh->alen = sizeof (struct in6_addr); + memcpy(&dh->data[0], &in6_addr->sin6_addr.s6_addr, dh->alen); + + dList_append(list, dh); +#endif + } + } +} + #ifdef D_DNS_THREADED /* * Server function (runs on its own thread) */ static void *Dns_server(void *data) { - struct hostent *host; int channel = VOIDP2INT(data); -#ifdef LIBC5 - int h_err; - char buff[1024]; - struct hostent sh; -#endif + struct addrinfo hints, *res0; + int error; + + memset(&hints, 0, sizeof(hints)); + hints.ai_family = PF_INET; + hints.ai_socktype = SOCK_STREAM; + Dlist *hosts = dList_new(2); DEBUG_MSG(3, "Dns_server: starting...\n ch: %d host: %s\n", channel, dns_server[channel].hostname); -#ifdef ENABLE_IPV6 - if (ipv6_enabled) { - host = gethostbyname2(dns_server[channel].hostname, AF_INET6); - if (host) { - Dns_note_hosts(hosts, AF_INET6, host); - } - } -#endif - -#ifdef LIBC5 - host = gethostbyname_r(dns_server[channel].hostname, &sh, buff, - sizeof(buff), &h_err); -#else - host = gethostbyname(dns_server[channel].hostname); -#endif - - if (!host) { -#ifdef LIBC5 - dns_server[channel].status = h_err; -#else - dns_server[channel].status = h_errno; - if (h_errno == HOST_NOT_FOUND) + error = getaddrinfo(dns_server[channel].hostname, NULL, &hints, &res0); + + if (error != 0) { + dns_server[channel].status = error; + if (error == EAI_NONAME) MSG("DNS error: HOST_NOT_FOUND\n"); - else if (h_errno == TRY_AGAIN) + else if (error == EAI_AGAIN) MSG("DNS error: TRY_AGAIN\n"); - else if (h_errno == NO_RECOVERY) - MSG("DNS error: NO_RECOVERY\n"); - else if (h_errno == NO_ADDRESS) + else if (error == EAI_NODATA) MSG("DNS error: NO_ADDRESS\n"); -#endif - } else { + else if (h_errno == EAI_FAIL) + MSG("DNS error: NO_RECOVERY\n"); + } else { + Dns_note_hosts2(hosts, res0); dns_server[channel].status = 0; - Dns_note_hosts(hosts, AF_INET, host); - } + freeaddrinfo(res0); + } + if (dList_length(hosts) > 0) { dns_server[channel].status = 0; } else { diff --git a/src/dns.h b/src/dns.h --- a/src/dns.h +++ b/src/dns.h @@ -1,5 +1,7 @@ #ifndef __DNS_H__ #define __DNS_H__ + +#include <netinet/in.h> #include "chain.h" @@ -14,7 +16,7 @@ void a_Dns_freeall(void); void a_Dns_freeall(void); void a_Dns_resolve(const char *hostname, DnsCallback_t cb_func, void *cb_data); -#define DILLO_ADDR_MAX 16 +#define DILLO_ADDR_MAX sizeof(struct in6_addr) typedef struct _DilloHost {

Nov. 4, 2007

PATCH: adds the ' entity

by onepoint＠starurchin.org

Is it dillo's policy to include *only* HTML 4.01 entities. If not, here's a patch to add the ' entity, which appears all over the place despite not being official HTML 4.01. Regards, Jeremy Henty Only in dillo2: CVS Only in dillo2-cur: Makefile Only in dillo2-cur: Makefile.in Only in dillo2-cur: aclocal.m4 Only in dillo2-cur: autom4te.cache Only in dillo2-cur: config.guess Only in dillo2-cur: config.h Only in dillo2-cur: config.log Only in dillo2-cur: config.status Only in dillo2-cur: config.sub Only in dillo2-cur: configure Only in dillo2-cur: d_size.h Only in dillo2-cur: depcomp Only in dillo2-cur/dlib: .deps Only in dillo2/dlib: CVS Only in dillo2-cur/dlib: Makefile Only in dillo2-cur/dlib: Makefile.in Only in dillo2-cur/dlib: dlib.o Only in dillo2-cur/dlib: libDlib.a Only in dillo2/doc: CVS Only in dillo2-cur/doc: Makefile Only in dillo2-cur/doc: Makefile.in Only in dillo2-cur/dpi: .deps Only in dillo2/dpi: CVS Only in dillo2-cur/dpi: Makefile Only in dillo2-cur/dpi: Makefile.in Only in dillo2-cur/dpi: bookmarks.dpi Only in dillo2-cur/dpi: bookmarks.o Only in dillo2-cur/dpi: cookies.dpi Only in dillo2-cur/dpi: cookies.o Only in dillo2-cur/dpi: datauri.filter.dpi Only in dillo2-cur/dpi: datauri.o Only in dillo2-cur/dpi: downloads.dpi Only in dillo2-cur/dpi: downloads.o Only in dillo2-cur/dpi: dpiutil.o Only in dillo2-cur/dpi: file.dpi Only in dillo2-cur/dpi: file.o Only in dillo2-cur/dpi: ftp.filter.dpi Only in dillo2-cur/dpi: ftp.o Only in dillo2-cur/dpi: hello.filter.dpi Only in dillo2-cur/dpi: hello.o Only in dillo2-cur/dpi: https.filter.dpi Only in dillo2-cur/dpi: https.o Only in dillo2-cur/dpid: .deps Only in dillo2/dpid: CVS Only in dillo2-cur/dpid: Makefile Only in dillo2-cur/dpid: Makefile.in Only in dillo2-cur/dpid: dpi.o Only in dillo2-cur/dpid: dpi_service.o Only in dillo2-cur/dpid: dpi_socket_dir.o Only in dillo2-cur/dpid: dpid Only in dillo2-cur/dpid: dpid.o Only in dillo2-cur/dpid: dpid_common.o Only in dillo2-cur/dpid: main.o Only in dillo2-cur/dpid: misc_new.o Only in dillo2-cur/dpip: .deps Only in dillo2/dpip: CVS Only in dillo2-cur/dpip: Makefile Only in dillo2-cur/dpip: Makefile.in Only in dillo2-cur/dpip: dpip.o Only in dillo2-cur/dpip: libDpip.a Only in dillo2-cur: install-sh Only in dillo2-cur: missing Only in dillo2-cur/src: .deps Only in dillo2/src: CVS Only in dillo2-cur/src/IO: .deps Only in dillo2/src/IO: CVS Only in dillo2-cur/src/IO: IO.o Only in dillo2-cur/src/IO: Makefile Only in dillo2-cur/src/IO: Makefile.in Only in dillo2-cur/src/IO: about.o Only in dillo2-cur/src/IO: dpi.o Only in dillo2-cur/src/IO: http.o Only in dillo2-cur/src/IO: iowatch.o Only in dillo2-cur/src/IO: libDiof.a Only in dillo2-cur/src/IO: mime.o Only in dillo2-cur/src/IO: proto.o Only in dillo2-cur/src: Makefile Only in dillo2-cur/src: Makefile.in Only in dillo2-cur/src: bitvec.o Only in dillo2-cur/src: bookmark.o Only in dillo2-cur/src: bw.o Only in dillo2-cur/src: cache.o Only in dillo2-cur/src: capi.o Only in dillo2-cur/src: chain.o Only in dillo2-cur/src: colors.o Only in dillo2-cur/src: cookies.o Only in dillo2-cur/src: dialog.o Only in dillo2-cur/src: dicache.o Only in dillo2-cur/src: dillo-fltk Only in dillo2-cur/src: dillo.o Only in dillo2-cur/src: dir.o Only in dillo2-cur/src: dns.o Only in dillo2-cur/src: dpiapi.o Only in dillo2-cur/src: form.o Only in dillo2-cur/src: gif.o Only in dillo2-cur/src: history.o diff -pru -- dillo2/src/html.cc dillo2-cur/src/html.cc --- dillo2/src/html.cc 2007-11-03 22:16:26.000000000 +0000 +++ dillo2-cur/src/html.cc 2007-11-04 08:44:02.000000000 +0000 @@ -814,7 +814,7 @@ typedef struct { int isocode; } Ent_t; -#define NumEnt 252 +#define NumEnt 253 static const Ent_t Entities[NumEnt] = { {"AElig",0306}, {"Aacute",0301}, {"Acirc",0302}, {"Agrave",0300}, {"Alpha",01621},{"Aring",0305}, {"Atilde",0303}, {"Auml",0304}, @@ -833,7 +833,9 @@ static const Ent_t Entities[NumEnt] = { {"Yacute",0335},{"Yuml",0570}, {"Zeta",01626}, {"aacute",0341}, {"acirc",0342}, {"acute",0264}, {"aelig",0346}, {"agrave",0340}, {"alefsym",020465},{"alpha",01661},{"amp",38}, {"and",021047}, - {"ang",021040}, {"aring",0345}, {"asymp",021110},{"atilde",0343}, + {"ang",021040}, + {"apos",39}, /* not in HTML 4.01 */ + {"aring",0345}, {"asymp",021110},{"atilde",0343}, {"auml",0344}, {"bdquo",020036},{"beta",01662}, {"brvbar",0246}, {"bull",020042},{"cap",021051}, {"ccedil",0347}, {"cedil",0270}, {"cent",0242}, {"chi",01707}, {"circ",01306}, {"clubs",023143}, Only in dillo2-cur/src: html.o Only in dillo2-cur/src: image.o Only in dillo2-cur/src: jpeg.o Only in dillo2-cur/src: klist.o Only in dillo2-cur/src: menu.o Only in dillo2-cur/src: misc.o Only in dillo2-cur/src: nav.o Only in dillo2-cur/src: plain.o Only in dillo2-cur/src: png.o Only in dillo2-cur/src: prefs.o Only in dillo2-cur/src: timeout.o Only in dillo2-cur/src: ui.o Only in dillo2-cur/src: uicmd.o Only in dillo2-cur/src: url.o Only in dillo2-cur/src: web.o Only in dillo2-cur: stamp-h1

Nov. 4, 2007

Quick question about font_factor in dillorc2

by onepoint＠starurchin.org

Just out of interest, is there any reason why the default dillorc2 sets font_factor to 1.5? It seems unreasonably large to me, and I personally much prefer to comment it out. Anyone else have feelings one way or the other? Regards, Jeremy Henty

Nov. 4, 2007

Re: image loading from menus

by place＠gobigwest.com

Jorge wrote: > After some study and a reimplentation of plain.cc with classes > (getting rid of its linkblock and hooking a callback for memory > handling), it looks simpler and better. It looks like the same > may be done with html.cc. I was just wondering how you weigh the options of adding a callback vs. adding a signal. I had experimented with a destroy signal in my tree recently. It seemed more consistent to me, although I suspect the various child widgets were wasting cycles on signal emission code when they didn't have any receivers...

Nov. 4, 2007

Re: image loading from menus

by jcid＠dillo.org

Hi, On Fri, Nov 02, 2007 at 02:32:49PM +0000, place wrote: > > > Now I have to send a linkblock ptr around. > > > > Where, what are you working on? > > Please give me more background. > > The right-click menus. I am giving them the linkblock ptr via > a_UIcmd_*_popup so that they can call Html_load_images > (well, a_Html_load_images now, by way of a_UIcmd_load_images -- > if that's the right way to route it.) After some study and a reimplentation of plain.cc with classes (getting rid of its linkblock and hooking a callback for memory handling), it looks simpler and better. It looks like the same may be done with html.cc. Please check out the CVS. Comments are welcomed. Although the patch is already in CVS, I'm attaching the dw2 patch text so Sebastian can review it easily when he has time. -- Cheers Jorge.-

Nov. 3, 2007

Re: patch: images: working menu, deferred loading; page menu works

by jcid＠dillo.org

On Fri, Nov 02, 2007 at 07:45:01PM +0000, place wrote: > > BTW, the "reload" button does not reload the current page, but the > > most recent one in the history list. This is not the same if you have > > gone back one or more pages. > > I've attached a small patch that appears to work for me. > This bug is just one in a set, but it has a simple solution: diff -pru dillo2/src/nav.c dillo2-cur/src/nav.c --- dillo2/src/nav.c 2007-10-25 17:18:04.000000000 -0300 +++ dillo2-cur/src/nav.c 2007-11-02 19:14:03.000000000 -0300 @@ -70,7 +70,7 @@ int a_Nav_get_top_uidx(BrowserWindow *bw { nav_stack_item *nsi; - nsi = dList_nth_data (bw->nav_stack, a_Nav_stack_size(bw) - 1); + nsi = dList_nth_data (bw->nav_stack, a_Nav_stack_ptr(bw)); return (nsi) ? nsi->url_idx : -1; } Commited. ;) -- Cheers Jorge.-

Nov. 2, 2007

Another handy patch.

by jcid＠dillo.org

Hi, + Enabled vertical mouse wheel scrolling. -- Cheers Jorge.-

Nov. 2, 2007

Re: patch: images: working menu, deferred loading; page menu works

by place＠gobigwest.com

> BTW, the "reload" button does not reload the current page, but the > most recent one in the history list. This is not the same if you have > gone back one or more pages. I've attached a small patch that appears to work for me.

Nov. 2, 2007

Re: patch: images: working menu, deferred loading; page menu works

by matthias.franz＠ujf-grenoble.fr

On Thu, Nov 01, 2007 at 03:03:31PM -0300, Jorge Arellano Cid wrote: > On Thu, Nov 01, 2007 at 04:53:48PM +0000, place wrote: > > Are you saying that you would prefer that it be moved to the menu anyway? > > I've been using left click to load for years now, and I would find > > it significantly less convenient to use the menu for every image... > > The point is that it may be handy to follow an image-link without > loading the image (I'm not sure how useful though). I think it's definitely useful, for example when you have a slow internet connection. Moreover, text browsers link elinks show that browsing without images has its uses. BTW, the "reload" button does not reload the current page, but the most recent one in the history list. This is not the same if you have gone back one or more pages. Cheers, -- Matthias Franz

Nov. 2, 2007

Re: patch: images: working menu, deferred loading; page menu works

by jcid＠dillo.org

On Thu, Nov 01, 2007 at 04:53:48PM +0000, place wrote: > > Note that with the current patch, images that are also links > > are not working (i.e. clicking on them loads the image but > > doesn't follow the link). I understand that left-clicking to load > > an image is quite handy. Now, FLTK2 has a nice feature with > > popups and it's that they can remember a menuitem position. If we > > make the right click popup remember the "load image" item, the > > same easeness of user interface may be attained (you may look in > > the test/menu program inside fltk2 sources). > > Oops! Images that are links work in my personal tree, but I overlooked > in when making the patch... The first click loads the image, and subsequent > ones follow the link. > > Are you saying that you would prefer that it be moved to the menu anyway? > I've been using left click to load for years now, and I would find > it significantly less convenient to use the menu for every image... The point is that it may be handy to follow an image-link without loading the image (I'm not sure how useful though). The idea is to try how does it work with the right-click-popup + item preselection. This is you right click (don't move the mouse), and the "load image" item is right there, and thus you can just right-click to load an image and also right click + move mouse for other options. If this is not as useful as the former, we can go back (or make it a preference), but I see some value in trying, because that way, the orthogonality of the UI, as a whole, is preserved. -- Cheers Jorge.-

Nov. 1, 2007

Re: patch: images: working menu, deferred loading; page menu works

by place＠gobigwest.com

> Note that with the current patch, images that are also links > are not working (i.e. clicking on them loads the image but > doesn't follow the link). I understand that left-clicking to load > an image is quite handy. Now, FLTK2 has a nice feature with > popups and it's that they can remember a menuitem position. If we > make the right click popup remember the "load image" item, the > same easeness of user interface may be attained (you may look in > the test/menu program inside fltk2 sources). Oops! Images that are links work in my personal tree, but I overlooked in when making the patch... The first click loads the image, and subsequent ones follow the link. Are you saying that you would prefer that it be moved to the menu anyway? I've been using left click to load for years now, and I would find it significantly less convenient to use the menu for every image...

Nov. 1, 2007

Re: patch: images: working menu, deferred loading; page menu works

by jcid＠dillo.org

Hi, On Mon, Oct 29, 2007 at 11:18:21PM +0000, place wrote: > (I could have sworn that I sent you a patch making the page menu work, > but since I didn't realize that it wasn't in the main tree until I > was preparing this patch, it's included here. I'll likely end > up separating it out as we go through the process of refining the rest > of this patch...) > > This has an extra argument in the link signals, as you recommended, > instead of the array of image handlers that my previous version used. > > I had to add an x_img to style. > > The link block stores the Image and the url until loading is requested. Great! I made an extensive revision of the patch and commited it with some minor changes (attached so you can review and sync more easily). Urbi et orbi, this patch set more or less is: - Added code for the image menu and hooked it to dw2 signals. - Hooked the page and link menus. - Added code for optional image loading (nice interface) very advanced! - Fixed the position of the Bug Meter popup menu. - Added an extra argument in the link signals - Aded an x_img camp to style (an image array index, like x_link). > Although there's no placeholder, if there's anything to click on, left click > loads instances of that image and middle click loads all images on the page. > The latter should probably be in the page menu instead. The patch is very advanced and here go my comments: Yes, a place holder is the next step (sometimes image size is provided as attributes in the IMG element, some others not; in which case we can use a standard size). Note that with the current patch, images that are also links are not working (i.e. clicking on them loads the image but doesn't follow the link). I understand that left-clicking to load an image is quite handy. Now, FLTK2 has a nice feature with popups and it's that they can remember a menuitem position. If we make the right click popup remember the "load image" item, the same easeness of user interface may be attained (you may look in the test/menu program inside fltk2 sources). I also agree that "load all images" naturally belongs to the page menu. BTW, with regard to the toggle button, in the past I thought of a toolbox icon with a popup holding things like: "Load images" // toggle item "Force my colors" // toggle item "Restrict width" // toggle item ... It looks lilke a good idea to me, but I don't know whether in practice this is as convenient as it looks. Comments welcomed. -- Cheers Jorge.-

Nov. 1, 2007

Test: are my posting problems fixed

by onepoint＠starurchin.org

Just checking whether Jorge has fixed whatever was stopping my messages getting through. Regards, Jeremy Henty

Nov. 1, 2007

Crashes on OpenBSD

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [071029 23:20]: > > Good timing you have (as Yoda says). > > I've been working on this a couple of days. Just test latest CVS and > let me know if it works for you (same for Jan S.). AH! Yes, dillo has become usable now. Sites are rendered (and redrawn alot but this is another issue to be addressed) but the race condition seems to be gone now. Thanks! Another thing: Actually what is the dw-testbed for? Will the code from there slowly merge into dillo2? Or am I missing something... Cheers, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Oct. 30, 2007

Crashes on OpenBSD

by jcid＠dillo.org

On Mon, Oct 29, 2007 at 09:31:06PM +0100, Christian Kellermann wrote: > Dear List, > > this project seems to gain some speed again and I am very happy > seeing the patches flowing around. I won't step back. Good! > For I am running on a BSD I configured dillo2 with > --disable-threaded-dns. > > This won't compile because of this typo: > > RCS file: /sfhome/cvs/dillo/dillo2/src/dns.c,v > retrieving revision 1.2 > diff -b -u -p -r1.2 dns.c > --- dns.c 11 Oct 2007 18:55:13 -0000 1.2 > +++ dns.c 29 Oct 2007 20:32:04 -0000 > @@ -316,7 +316,7 @@ static void Dns_blocking_server(void) > { > int channel = 0; > struct hostent *host = NULL; > - dList *hosts = dList_new(2); > + Dlist *hosts = dList_new(2); > #ifdef LIBC5 > int h_err; > #endif Commited. > > Also I experience crashes every time I try to open a URL. See the > backtrace attached to this message. In this example I am using a > privoxy http proxy. The crashes occur independendly from this. Can > someone point me to the right direction? I am using the stock > dillorc2 and OpenBSD-4.1 on a i386. > > Thanks for your hints! > > Thank you Jorge! Good timing you have (as Yoda says). I've been working on this a couple of days. Just test latest CVS and let me know if it works for you (same for Jan S.). -- Cheers Jorge.-

Oct. 29, 2007

Crashes on OpenBSD

by Christian.Kellermann＠nefkom.net

Skipped content of type multipart/mixed

Oct. 29, 2007

some more bugs

by jcid＠dillo.org

On Mon, Oct 29, 2007 at 06:02:22PM +0100, Matthias Franz wrote: > On Sat, Oct 27, 2007 at 08:13:11PM +0200, Matthias Franz wrote: > > - Pressing "@" anytime quits Dillo immediately. > > (I guess that was made on purpose during development.) > > On my (German) keyboard I have to press AltGr + "q" to get "@". > Alt + "q" quits dillo as well. (I didn't know that before.) > Could that be an unintended interference? Fixed in CVS! I have a keyboard with '@' in the same key combination, now quit is restricted to LeftAltKey. -- Cheers Jorge.-

Oct. 29, 2007

some more bugs

by matthias.franz＠ujf-grenoble.fr

On Sat, Oct 27, 2007 at 08:13:11PM +0200, Matthias Franz wrote: > - Pressing "@" anytime quits Dillo immediately. > (I guess that was made on purpose during development.) On my (German) keyboard I have to press AltGr + "q" to get "@". Alt + "q" quits dillo as well. (I didn't know that before.) Could that be an unintended interference? -- Matthias Franz

Oct. 29, 2007

Re: yet another patch: forms. activateReceiver

by jcid＠dillo.org

Hi, After a rescue operation (and re-trainning of my bogofilter), there were this emails/patches in the SPAM bin: place (5.6K) patch: just the not-hooked-up image menu place (6.8K) patch: image loading toggle button + preference place (4.2K) patch: plain page menu place (2.6K) yet another patch: forms. activateReceiver All of them were commited with only minor changes. > I assumed I was going to have to _understand_ forms or resources, and here > I find out that all I have to do is hook A to B. At least to make the forms > I use regularly work... I wonder whether you guys left the easy stuff for > whoever comes along just so that it would be easy for them to feel rewarded > for their efforts... :-) We were trying with Sebastian to check that FLTK2, was providing everything we needed to complete the port. Thus, if something worked, but needed lots of hooks thorough the code, only the first one was made (and the rest left for the future), so we could advance to the next case. In the case of forms, while I was porting the html parser the resources for forms were not yet developed, so I had to comment and skip some hooks to make it compile. Later I started joining some dots... > I didn't patch the rc to mention the preference, though. I did. > A slavish copy of linkblock, which, since there certainly weren't any links > involved, ended up named 'eventdata'... In general, do you plan to make the rest of the patches (e.g. hook the image menu, the image loading toggle), or want some help here? BTW, with regard to the linkblock (and my past comments on it), I can try to check how it looks without linkblock, and decide what to make of it afterwards while you work on the part II of the above patches. Just let me know. -- Cheers Jorge.-

Oct. 29, 2007

some more bugs

by jcid＠dillo.org

On Sat, Oct 27, 2007 at 07:12:57PM +0000, place wrote: > Matthias Franz wrote: > > > - The tag <hr> does not produce a horizontal line, but only a small dot. > > My tree has (once again) become far too hacked up for me to generate proper > patches, but the line will be the proper width if you add > > style_attrs.width = Html_parse_length (html, width_ptr); > > to Html_tag_open_hr() Done! -- Cheers Jorge.-

Oct. 28, 2007

some more bugs

by place＠gobigwest.com

Matthias Franz wrote: > - The tag <hr> does not produce a horizontal line, but only a small dot. My tree has (once again) become far too hacked up for me to generate proper patches, but the line will be the proper width if you add style_attrs.width = Html_parse_length (html, width_ptr); to Html_tag_open_hr()

Oct. 27, 2007

some more bugs

by matthias.franz＠ujf-grenoble.fr

Hi everybody, here are some more bugs I've discovered. (I'm sorry that testing usually leads to postings about problems ... Thanks to all who have volunteered to fix them so far!) - The tag <hr> does not produce a horizontal line, but only a small dot. - Pressing "@" anytime quits Dillo immediately. (I guess that was made on purpose during development.) - The bookmark page looks very funny. The columns for the sections and the bookmarks are much to narrow and together use only about one third of the window width. - A problem which is already present in the fltk2 program test/input: Pressing a dead key and then a letter (e.g., "^" and "o") works fine. Pressing a dead key followed by space only sometimes gives the accent (as it should) and sometimes just a space. What you get seems to be random; it changes even while the program is running. I understand that fltk2 processes dead keys on its own. For us, it would probably be easier if the keyboard was used in a "cooked" mode based on the X keyboard settings. Cheers, -- Matthias Franz

Oct. 27, 2007

Test (for posting problems), please ignore

by onepoint＠starurchin.org

Lets see if Jorge has has fixed whatever it was that stopped my posts getting through... Jeremy Henty

Oct. 27, 2007

Re: new browser windows slower than first one

by Johannes.Hofmann＠gmx.de

On Thu, Oct 25, 2007 at 05:34:30PM -0300, Jorge Arellano Cid wrote: > On Thu, Oct 25, 2007 at 07:42:30PM +0000, place wrote: > > I think my biggest problem is that I can't read a page until it's finished > > downloading because it's spending the whole time redrawing, redrawing, > > redrawing. > > For me it's no problem to comment clear_double_buffer() in ui.cc, as long > as we remember to fix the excess of redrawing. I don't mind either, it's just one line anyway. And I think that dillo1 also has frequent redraws but they are not as apparent as the rendering is done to a pixmap and the result is copied. Can others please add the following debug messages to see how often dillo1 rerenders a certain page compared to dillo2 on their machines? dillo1: --- dillo-0.8.6/src/dw_gtk_viewport.c.orig 2007-10-25 22:36:44 +0200 +++ dillo-0.8.6/src/dw_gtk_viewport.c 2007-10-23 19:52:02 +0200 @@ -333,6 +333,7 @@ static void Dw_gtk_viewport_paint (GtkWi /* Widgets draw in backing pixmap. */ p_Dw_widget_draw (viewport->child, &intersection, event); /* Copy backing pixmap into window. */ +fprintf(stderr, "====> DRAW ======\n"); gdk_draw_pixmap (layout->bin_window, widget->style->black_gc, viewport->back_pixmap, area->x, area->y, area->x, area->y, area->width, area->height); dillo2: diff -r 31fd33cfb784 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Wed Oct 24 22:25:25 2007 +0200 +++ b/dw/fltkviewbase.cc Thu Oct 25 22:51:11 2007 +0200 @@ -50,6 +50,7 @@ FltkViewBase::~FltkViewBase () void FltkViewBase::draw () { +fprintf(stderr, "====> DRAW ======\n"); Group::draw (); ::fltk::Rectangle rect (x(), y(), w(), h()); Johannes

Oct. 25, 2007

Re: new browser windows slower than first one

by jcid＠dillo.org

On Thu, Oct 25, 2007 at 07:42:30PM +0000, place wrote: > I think my biggest problem is that I can't read a page until it's finished > downloading because it's spending the whole time redrawing, redrawing, > redrawing. For me it's no problem to comment clear_double_buffer() in ui.cc, as long as we remember to fix the excess of redrawing. -- Cheers Jorge.-

Oct. 25, 2007

Scrolling patch!

by jcid＠dillo.org

On Thu, Oct 25, 2007 at 08:15:24PM +0200, Matthias Franz wrote: > On Wed, Oct 24, 2007 at 05:27:42PM -0300, Jorge Arellano Cid wrote: > > > I see this in two parts: > > > > > > 1.- Remembering the scroll position in each bw's nav_stack > > > 2.- Making fragments push a new page (and not just jump like now). > > > > Number 1.- is commited! > > Hi Jorge, > > I think it's a good idea to split this into two parts. If people have > different preferences about (2), one could make this configurable. > > Here is a problem with the current version: > > Create two (long) pages. At the bottom of each page make a link to > the other one. Now do the following: Start dillo2 with page 1. > The top of the page is shown. Scroll to the bottom, click on the link. > Now page 2 opens (at the top). Scroll to the bottom, click on the link. > Now page 1 opens (at the top). Scroll to the bottom. > Go back to page 2. The bottom is shown. Go forward to page 1. > Now the top is shown, although you left the page at the bottom. > > Can you reproduce this? Yes, and as a bonus I get hit by the not-completely-rendered-yet scrolling offset bug! :-) It was a lapsus of mine. Small patch commited. You can debug with (e.g.): ./dillo-fltk /tmp/page1.html |grep -e ^Nav -- Cheers Jorge.-

Oct. 25, 2007

Re: new browser windows slower than first one

by place＠gobigwest.com

I think my biggest problem is that I can't read a page until it's finished downloading because it's spending the whole time redrawing, redrawing, redrawing.

Oct. 25, 2007

Re: new browser windows slower than first one

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Thu, Oct 25, 2007 at 04:10:12PM -0300, Jorge Arellano Cid wrote: > Hi, > > On Mon, Oct 22, 2007 at 06:39:09PM +0000, place wrote: > > Turning off double buffering means that the default code from the tree > > is unusably slow and annoying on my ancient(*) computer. This might dissuade > > someone who comes along at the wrong time intending to give the fltk dillo > > a look. > > > > Though admittedly it might be my configuration... > > When testing in a Pentium I, 233Mhz, 96MB ram, the results were > mixed, varied and confusing to me! > > For instance with dillo2-noDB, I get faster scrolling in a > down-arrow-always-pressed-test, varying from 25% to 95% more or > less of CPU depending on what is to be rendered and the X > server's internal memory usage. Mouse drag-scrolling sometimes is > better, some others worst and others the same !? > > With dillo2-DB, sometimes I get faster mouse drag-scrolling, > others the same. Down-arrow-always-pressed-test is consistently > worst, but sometimes pages render much faster and others the > same. > > Frankly, I don't understand what this means. Yes, the performance is pretty confusing sometimes. The main drawback for me of standard DB dillo is that CPU usage and server side memory consumption gets horrible on my laptop when I open 5 or more windows. > > Ah, I also noticed that in a fast machine dillo2-noDB is much > better than dillo2-DB (but annoying at flickering). I think, we need something like DB for drawing. Dillo1 also draws to a backbuffer and then copies the result to the screen - please correct me if I'm wrong. As dillo first draws the background and then the text/images on top, we will always see annoying flickering if we draw directly to the screen, especially with frequent redraws during incremental page rendering while the page is loaded (which is a great feature of dillo btw). However, I hope that we can do better than switch on DB generally. As dillo is single threaded even for multiple windows, we could use a single backbuffer for all windows. I've got this working, but unfortunately currently only if XFT is disabled. Johannes

Oct. 25, 2007

Re: new browser windows slower than first one

by jcid＠dillo.org

Hi, On Mon, Oct 22, 2007 at 06:39:09PM +0000, place wrote: > Turning off double buffering means that the default code from the tree > is unusably slow and annoying on my ancient(*) computer. This might dissuade > someone who comes along at the wrong time intending to give the fltk dillo > a look. > > Though admittedly it might be my configuration... When testing in a Pentium I, 233Mhz, 96MB ram, the results were mixed, varied and confusing to me! For instance with dillo2-noDB, I get faster scrolling in a down-arrow-always-pressed-test, varying from 25% to 95% more or less of CPU depending on what is to be rendered and the X server's internal memory usage. Mouse drag-scrolling sometimes is better, some others worst and others the same !? With dillo2-DB, sometimes I get faster mouse drag-scrolling, others the same. Down-arrow-always-pressed-test is consistently worst, but sometimes pages render much faster and others the same. Frankly, I don't understand what this means. Ah, I also noticed that in a fast machine dillo2-noDB is much better than dillo2-DB (but annoying at flickering). -- Cheers Jorge.-

Oct. 25, 2007

Scrolling patch!

by matthias.franz＠ujf-grenoble.fr

On Wed, Oct 24, 2007 at 05:27:42PM -0300, Jorge Arellano Cid wrote: > > I see this in two parts: > > > > 1.- Remembering the scroll position in each bw's nav_stack > > 2.- Making fragments push a new page (and not just jump like now). > > Number 1.- is commited! Hi Jorge, I think it's a good idea to split this into two parts. If people have different preferences about (2), one could make this configurable. Here is a problem with the current version: Create two (long) pages. At the bottom of each page make a link to the other one. Now do the following: Start dillo2 with page 1. The top of the page is shown. Scroll to the bottom, click on the link. Now page 2 opens (at the top). Scroll to the bottom, click on the link. Now page 1 opens (at the top). Scroll to the bottom. Go back to page 2. The bottom is shown. Go forward to page 1. Now the top is shown, although you left the page at the bottom. Can you reproduce this? Cheers, -- Matthias Franz

Oct. 25, 2007