- Dillo-dev - lists.mailman3.com

directory listings?

by bogus＠does.not.exist.com

On Thu, Oct 18, 2007 at 02:27:57PM +0200, Jan Stary wrote: > Hi all, > > dillo-fltk http://stare.cz/~hans/foto/ gives me a directory > listing as it should. It's full of subdirectories, and they > are all the same (just contain JPEGs). > > Now when I click on _some_ of the links, I get a correct directory > listing again (of the subdirectory). When I click on _some_ others > I get nothing, just a blank page (gray). > > [...] Please try the CVS code on this. -- Cheers Jorge.-

Oct. 20, 2007

Scrolling patch!

by bogus＠does.not.exist.com

Hi there, Here's a patch I wanted to add since a long time. Remembering the scroll position in a page. At least for me, it improves web browsing a lot! The dw2 part of the patch is attached to this email, so Sebastian can look at a minor change that looks like a fix for a hidden bug in the code... The patch is complete in CVS. -- Cheers Jorge.-

Oct. 20, 2007

bug: non-ascii characters not displayed correctly in the title bar

by bogus＠does.not.exist.com

On Fri, Oct 19, 2007 at 08:49:48PM +0200, Matthias Franz wrote: > Hi, > > by default, I use Latin1 encoding on my machine, not UTF-8. > Dillo2 does not do UTF-8 -> Latin1 conversion for the title bar. > Here is an example: > > <title>dillô</title> > <body> > dillô > </body> > > You don't get "dill?" in the title bar, but "dill??". Strange, it works for me either with "en" or "latin1". I don't use utf-8 with mrxvt. Can you display special characters in you terminal prompt? e.g.: server$ ??? -- Cheers Jorge.-

Oct. 20, 2007

bug: non-ascii characters not displayed correctly in the title bar

by matthias.franz＠ujf-grenoble.fr

Hi, by default, I use Latin1 encoding on my machine, not UTF-8. Dillo2 does not do UTF-8 -> Latin1 conversion for the title bar. Here is an example: <title>dillô</title> <body> dillô </body> You don't get "dill?" in the title bar, but "dill??". Cheers, -- Matthias Franz

Oct. 19, 2007

dillo crashes on (incorrect) tables

by matthias.franz＠ujf-grenoble.fr

Hi, the following (syntactically incorrect) HTML code makes dillo2 crash on my machine. Dillo1 is fine. <html> <table> <tr></tr> <tr><td colspan="3"></td></tr> <td colspan="3"> </table> </html> Cheers, -- Matthias Franz

Oct. 19, 2007

Re: receiver patch: html page menu working, image menu present but not called.

by place＠gobigwest.com

Jorge wrote: > On Thu, Oct 18, 2007 at 10:56:39PM +0000, place wrote: > > > The fact of the linkblock not being freed in current code (see warning > > > from compiling html.cc) is just because I haven't found the clean & proper > > > place to hook Html_lb_free() (to widget destruction probably). IIRC there > > > was a ...connect_after() hook in GTK that worked ok after deletion of the > > > object (which I haven't yet found an analog in FLTK2). > > > > So I should regard "linkblock" as "the bag of event handling stuff"? Okay. > > It's a bag for links, form data etc... > > I've longed to get rid of it several times, but I don't see a > much cleaner approach. This may be the time, or maybe not. > > For instance, if the linkblock data is put inside the html > struct, and the whole turned into a class, it would look much > cleaner. It would also be clearer in the case of plain text (it > also receives the signal for page menu), and having a separate > linkblock or receiver for it seems odd. > > OTOH, the data that now belongs to the html-struct is freed > when parsing finishes, and it would remain inside the class, > which is a bit untidy, but if we make this part a pointer inside > the shiny new class, it could go NULL at freeing time. This looks > cleaner. Indeed. > > I now have new code for image signals. In an effort not to add an extra argument > > to the signals (which seemed hacky -- either an image_vs_link sort of argument, > > or an image_number sort of argument), I ended up making a vector of image > > receivers, one per image. I can't decide whether that is bad or reasonably > > sensible. If a better solution is obvious to you, please let me know. > > Not obvious, but I think of the case of pages with hundreds or > thousands of images (e.g.): > > http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/… > > Memory consumption for this vector may grow too much. A single > int value working as an index to the proper URL/data from within > a single image signal receiver looks cleaner (from a distance :-) All right. > > So the image menu works, an ugly little button toggles image loading, and > > click-to-load works, though I don't have any placeholder image. > > More than enough for a start! And an opportunity for people who say "I'd love to help dillo, but don't know how to write code" to make a little tiny button... I was going to try having a single patch for all of that, but it was already teetering on the edge between small-enough and too-much. I think I'll try to pull out the menu and the button to send you first, since they're harmless, and then the rest after I redo it. > > (if only forms worked well enough to perform search queries, > > I just about wouldn't need my old dillo around anymore!) > > I know what you mean. Given that, plus the scrolling bug, > search text inside pages and anchors, it'd looks very sexy to me! > > > > BTW, not that it really matters at present, but I discovered that > > in Html_write_raw(), you can get token_start to be greater than bufsize. > > Go through the verbatim part at the top until token_start = buf_index = bufsize, > > then have the isspace() test right below it be true. > > It looks like this is why my iconv buffer code crashed often on me. > > Thanks for the report, I'll look at it when I find some time. > > > BTW, this duscussion is more than worth to have in dillo-dev. > Can I take it there? *cc:s dillo-dev, resists urge to trim quotes*

Oct. 19, 2007

./configure confused about FLTK version

by bogus＠does.not.exist.com

On Fri, Oct 19, 2007 at 03:33:14PM +0200, Johannes Hofmann wrote: > > > > Some time ago they were deciding whether {fltk,fltk2}-config. > > If you're sure they decided for fltk2-config finally, I'd commit. > > Currently it's fltk2-config. They might switch back, but I don't > think this will happen any time soon. OK, I can point at you then! :-) Done. BTW Jan, for the record, did the other patch work? -- Cheers Jorge.-

Oct. 19, 2007

[patch] CPU usage when moving mouse on large page

by Johannes.Hofmann＠gmx.de

Hi, here is another patch regarding the performance of dillo-fltk. It addresses the high CPU usage when moving the cursor on a large page especially if it contains many links and images. See http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/… as an example. Note, that also dillo1 uses quite some CPU when moving the mouse on that page. The patch moves Layout::getWidgetAtPoint0() to Widget::getWidgetAtPoint() and makes it virtual so that widgets can provide an own optimzed version of that method. For the Textblock widget an optimized version is implemented that uses findLineIndex(). This patch is a bit more invasive than the scroll-patch, so I would appreciate comments from the dw author(s). Johannes diff --git a/dw/layout.cc b/dw/layout.cc --- a/dw/layout.cc +++ b/dw/layout.cc @@ -703,47 +703,6 @@ void Layout::leaveNotify (View *view, Bu } } -/** - * \brief Search recursively through widget. - * - * Used by dw::core::Layout:getWidgetAtPoint. - */ -Widget *Layout::getWidgetAtPoint0 (Widget *widget, int x, int y, int level) -{ - Iterator *it; - Widget *childAtPoint; - - //_MSG ("%*s-> examining the %s %p (%d, %d, %d x (%d + %d))\n", - // 3 * level, "", gtk_type_name (GTK_OBJECT_TYPE (widget)), widget, - // widget->allocation.x, widget->allocation.y, - // widget->allocation.width, widget->allocation.ascent, - // widget->allocation.descent); - - if (x >= widget->allocation.x && - y >= widget->allocation.y && - x <= widget->allocation.x + widget->allocation.width && - y <= widget->allocation.y + widget->getHeight ()) { - //_MSG ("%*s -> inside\n", 3 * level, ""); - /* - * Iterate over the children of this widget. Test recursively, whether - * the point is within the child (or one of its children...). If there - * is such a child, it is returned. Otherwise, this widget is returned. - */ - childAtPoint = NULL; - it = widget->iterator (Content::WIDGET, false); - - while (childAtPoint == NULL && it->next ()) - childAtPoint = getWidgetAtPoint0 (it->getContent()->widget, - x, y, level + 1); - - if (childAtPoint) - return childAtPoint; - else - return widget; - } else - return NULL; -} - /* * Return the widget at position (x, y). Return NULL, if there is no widget. */ @@ -752,7 +711,7 @@ Widget *Layout::getWidgetAtPoint (int x, //_MSG ("------------------------------------------------------------\n"); //_MSG ("widget at (%d, %d)\n", x, y); if (topLevel) - return getWidgetAtPoint0 (topLevel, x, y, 0); + return topLevel->getWidgetAtPoint (x, y, 0); else return NULL; } diff --git a/dw/layout.hh b/dw/layout.hh --- a/dw/layout.hh +++ b/dw/layout.hh @@ -87,7 +87,6 @@ private: enum ButtonEventType { BUTTON_PRESS, BUTTON_RELEASE, MOTION_NOTIFY }; - Widget *getWidgetAtPoint0 (Widget *widget, int x, int y, int level); Widget *getWidgetAtPoint (int x, int y); void moveToWidget (Widget *newWidgetAtPoint, ButtonState state); diff --git a/dw/textblock.cc b/dw/textblock.cc --- a/dw/textblock.cc +++ b/dw/textblock.cc @@ -1730,6 +1730,50 @@ void Textblock::addLinebreak (core::styl wordWrap (words->size () - 1); } + +/** + * \brief Search recursively through widget. + * + * This is an optimized version of the general + * dw::core::Widget::getWidgetAtPoint method. + */ +core::Widget *Textblock::getWidgetAtPoint(int x, int y, int level) +{ + int lineIndex, wordIndex; + Line *line; + + if (x < allocation.x || + y < allocation.y || + x > allocation.x + allocation.width || + y > allocation.y + getHeight ()) { + return NULL; + } + + lineIndex = findLineIndex (y - allocation.y); + + if (lineIndex < 0 || lineIndex >= lines->size ()) { + return this; + } + + line = lines->getRef (lineIndex); + + for (wordIndex = line->firstWord; wordIndex < line->lastWord; wordIndex++) { + Word *word = words->getRef (wordIndex); + + if (word->content.type == core::Content::WIDGET) { + core::Widget * childAtPoint; + childAtPoint = word->content.widget->getWidgetAtPoint (x, y, + level + 1); + if (childAtPoint) { + return childAtPoint; + } + } + } + + return this; +} + + /** * This function "hands" the last break of a page "over" to a parent * page. This is used for "collapsing spaces". diff --git a/dw/textblock.hh b/dw/textblock.hh --- a/dw/textblock.hh +++ b/dw/textblock.hh @@ -366,6 +366,7 @@ public: void addParbreak (int space, core::style::Style *style); void addLinebreak (core::style::Style *style); + core::Widget *getWidgetAtPoint (int x, int y, int level); void handOverBreak (core::style::Style *style); void changeLinkColor (int link, int newColor); void changeWordStyle (int from, int to, core::style::Style *style, diff --git a/dw/widget.cc b/dw/widget.cc --- a/dw/widget.cc +++ b/dw/widget.cc @@ -676,6 +676,48 @@ Widget *Widget::getNearestCommonAncestor } +/** + * \brief Search recursively through widget. + * + * Used by dw::core::Layout:getWidgetAtPoint. + */ +Widget *Widget::getWidgetAtPoint (int x, int y, int level) +{ + Iterator *it; + Widget *childAtPoint; + + //_MSG ("%*s-> examining the %s %p (%d, %d, %d x (%d + %d))\n", + // 3 * level, "", gtk_type_name (GTK_OBJECT_TYPE (widget)), widget, + // allocation.x, allocation.y, + // allocation.width, allocation.ascent, + // allocation.descent); + + if (x >= allocation.x && + y >= allocation.y && + x <= allocation.x + allocation.width && + y <= allocation.y + getHeight ()) { + //_MSG ("%*s -> inside\n", 3 * level, ""); + /* + * Iterate over the children of this widget. Test recursively, whether + * the point is within the child (or one of its children...). If there + * is such a child, it is returned. Otherwise, this widget is returned. + */ + childAtPoint = NULL; + it = iterator (Content::WIDGET, false); + + while (childAtPoint == NULL && it->next ()) + childAtPoint = it->getContent()->widget->getWidgetAtPoint (x, y, + level + 1); + + if (childAtPoint) + return childAtPoint; + else + return this; + } else + return NULL; +} + + void Widget::scrollTo (HPosition hpos, VPosition vpos, int x, int y, int width, int height) { diff --git a/dw/widget.hh b/dw/widget.hh --- a/dw/widget.hh +++ b/dw/widget.hh @@ -405,6 +405,8 @@ public: inline Layout *getLayout () { return layout; } + virtual Widget *getWidgetAtPoint (int x, int y, int level); + void scrollTo (HPosition hpos, VPosition vpos, int x, int y, int width, int height);

Oct. 19, 2007

./configure confused about FLTK version

by Johannes.Hofmann＠gmx.de

> > Some time ago they were deciding whether {fltk,fltk2}-config. > If you're sure they decided for fltk2-config finally, I'd commit. Currently it's fltk2-config. They might switch back, but I don't think this will happen any time soon. Johannes

Oct. 19, 2007

./configure confused about FLTK version

by bogus＠does.not.exist.com

On Thu, Oct 18, 2007 at 06:29:27PM +0200, Johannes Hofmann wrote: > On Thu, Oct 18, 2007 at 11:46:06AM -0300, Johannes Hofmann wrote: > > On Thu, Oct 18, 2007 at 03:53:25PM +0200, Jan Stary wrote: > > > Hi all, > > > > > > it seems that the ./configure script as generated by ./autogen.sh of > > > current cvs tree will happily go with fltk < 2, giving compilation > > > errors later. > > > > > > Jan > > > > Try this: > > > > - else if sh -c "fltk-config --version" >/dev/null 2>&1 > > + else if sh -c "fltk-config --version|grep ^2" >/dev/null 2>&1 > > All newer fltk2 builds install fltk2-config so I think we could drop the > check for fltk-config alltogether, i.e for dw-testbed: > > diff -r 67316fad7af1 configure.in > --- a/configure.in Thu Oct 18 16:23:15 2007 +0200 > +++ b/configure.in Thu Oct 18 18:27:20 2007 +0200 > @@ -38,14 +38,8 @@ then AC_MSG_RESULT(yes) > LIBFLTK_CXXFLAGS=`fltk2-config --cxxflags` > LIBFLTK_CFLAGS=`fltk2-config --cflags` > LIBFLTK_LIBS=`fltk2-config --use-images --ldflags` > -else if sh -c "fltk-config --version" >/dev/null 2>&1 > - then AC_MSG_RESULT(yes) > - LIBFLTK_CXXFLAGS=`fltk-config --cxxflags` > - LIBFLTK_CFLAGS=`fltk-config --cflags` > - LIBFLTK_LIBS=`fltk-config --ldflags` > - else AC_MSG_RESULT(no) > - AC_ERROR(FLTK2 must be installed!) > - fi > +else AC_MSG_RESULT(no) > + AC_ERROR(FLTK2 must be installed!) > fi Some time ago they were deciding whether {fltk,fltk2}-config. If you're sure they decided for fltk2-config finally, I'd commit. -- Cheers Jorge.-

Oct. 18, 2007