- Dillo-dev - lists.mailman3.com

fltk dead key problem

by matthias.franz＠ujf-grenoble.fr

On Sat, Oct 27, 2007 at 08:13:11PM +0200, Matthias Franz wrote: > - 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. The following patch fixes this. (It's not against the latest version of fltk, but the relevant file hasn't changed since.) ### start patch ### --- fltk-2.0.x-r5917/src/compose.cxx 2006-06-25 08:11:31.000000000 +0200 +++ fltk-new/src/compose.cxx 2007-11-08 07:38:01.000000000 +0100 @@ -345,19 +345,8 @@ bool fltk::compose(int& del) { for (const char *p = compose_pairs; *p; p += 2) if (p[0] == ascii || p[1] == ascii) { compose_state = ascii; - // prefer the single-character versions: - if (p[1] == ' ') { - int code = (p-compose_pairs)/2+0xA0; - // convert code to utf8: - e_text = textbuffer; - textbuffer[0] = 0xc0 | code>>6; - textbuffer[1] = 0x80 | (code & 0x3f); - textbuffer[2] = 0; - plen = e_length = 2; - return true; - } + return true; } - if (compose_state != 1) return true; #if 0 // The right-hand ctrl and any letter "quotes" the control character: @@ -386,6 +375,24 @@ bool fltk::compose(int& del) { } } + // prefer the single-character versions: + if (ascii == ' ') { + e_text = textbuffer; + if (c1 & 0x80) { + // convert c1 to utf8: + textbuffer[0] = 0xc0 | c1>>6; + textbuffer[1] = 0x80 | (c1 & 0x3f); + textbuffer[2] = 0; + plen = e_length = 2; + } else { + textbuffer[0] = c1; + textbuffer[1] = 0; + plen = e_length = 1; + } + compose_state = 0; + return true; + } + } #if USE_X11 ### end patch ### > 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. I'm getting more and more convinced of this opinion. Why does one specify key mapping in XKB files if each application processes them on its own? BTW, I've noticed another bug in fltk compose key processing: I use the Windoze menu key for composing. Although it has the right keysym (0xff20), it is ignored, probably because it is also considered to be a META key, and these keys are handled by fltk in a special way. I'll send an email to fltk-bugs as well. Cheers, -- Matthias Franz

Nov. 8, 2007

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