From dennisn at dennisn.dyndns.org Fri Oct 2 17:38:51 2009 From: dennisn at dennisn.dyndns.org (Dennis Nezic) Date: Fri Oct 2 17:39:40 2009 Subject: [Dillo-dev] textarea multiline input bug Message-ID: <20091002113851.bf85146f.dennisn@dennisn.dyndns.org> In textareas (multiline form input), say for example: http://translate.google.ca/translate_t ... if I first enter the following line into the textarea: yo soy anarco-capitalista ... and after submitting it, I edit it (the previous contents are retained -- although I suspect internally there might be something broken -- not sure where it breaks exactly.), by inserting a newline at the very beginning (pressing enter), then backspacing (removing the newline) to make it appear exactly the same, then resubmitting the form, strange stuff happens. (I remember earlier posting experiences some of my lines getting duplicated, and other strange stuff. I think it only happens when I edit stuff at the beginning.) From corvid at lavabit.com Fri Oct 2 20:52:37 2009 From: corvid at lavabit.com (corvid) Date: Fri Oct 2 20:56:29 2009 Subject: [Dillo-dev] textarea multiline input bug In-Reply-To: <20091002113851.bf85146f.dennisn@dennisn.dyndns.org> References: <20091002113851.bf85146f.dennisn@dennisn.dyndns.org> Message-ID: <20091002185237.GA32483@local.gobigwest.com> Dennis wrote: > In textareas (multiline form input), say for example: > > http://translate.google.ca/translate_t > > ... if I first enter the following line into the textarea: > > yo soy anarco-capitalista > > ... and after submitting it, I edit it (the previous contents are > retained -- although I suspect internally there might be something > broken -- not sure where it breaks exactly.), by inserting a newline at > the very beginning (pressing enter), then backspacing (removing the > newline) to make it appear exactly the same, then resubmitting the > form, strange stuff happens. > > (I remember earlier posting experiences some of my lines getting > duplicated, and other strange stuff. I think it only happens when I > edit stuff at the beginning.) You have found a FLTK bug. I think in the beginning of TextBuffer::text(), where it goes if (!gapstart_ && length_) { buf_[length_+gapend_] = 0; return buf_+gapstart_; } they want if (!gapstart_ && length_) { buf_[length_+gapend_] = 0; return buf_+gapend_; } From corvid at lavabit.com Wed Oct 7 07:26:07 2009 From: corvid at lavabit.com (corvid) Date: Wed Oct 7 07:30:00 2009 Subject: [Dillo-dev] auto/abs sizes in image.cc, auto/abs/per in textblock.cc Message-ID: <20091007052607.GF2529@local.gobigwest.com> At http://naturalhistory.museumwales.ac.uk/sharpshooters/ two of the image tags specify a size for one dimension, giving it as 100%. When one dimension is auto and the other is percentage, it doesn't scale properly. I see that calculation using percentage has to be in textblock because it uses availWidth or availHeight, so... is there a deep need to keep the auto/abs case in Image's sizeRequestImpl instead of Textblock's calcWidgetSize? I was just playing with adding all of the cases to calcWidgetSize and it looked like it was working except that an unloaded image with, e.g., height=100% alt=whatever would end up ridiculously wide because height_of_page / height_of_alt_text * width_of_alt_text is a large number. From akemnade at tzi.de Wed Oct 7 10:39:35 2009 From: akemnade at tzi.de (Andreas Kemnade) Date: Wed Oct 7 10:40:03 2009 Subject: [Dillo-dev] server downtime Message-ID: <20091007103935.69350ed5@kemnade.info> Hi, due to works on the power supply of the building in the early tomorrow morning, there will be a downtime for everything except hg access. As I'm not sure whether I can be there in time, I have to power down this early evening. Things should be up at 07:00 UTC again. Greetings Andreas Kemnade -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available Url : /pipermail/attachments/20091007/ab510888/signature.pgp From corvid at lavabit.com Wed Oct 7 17:55:59 2009 From: corvid at lavabit.com (corvid) Date: Thu Oct 8 09:51:32 2009 Subject: [Dillo-dev] tooltips not clearing properly In-Reply-To: <20091007075345.78240@gmx.net> References: <20090927072950.GF13919@local.gobigwest.com> <20090927184751.GA2293@blob.baaderstrasse.com> <20090927204552.GB26113@local.gobigwest.com> <20091006202206.GA27439@dillo.org> <20091006221750.GE2529@local.gobigwest.com> <20091007075345.78240@gmx.net> Message-ID: <20091007155559.GH2529@local.gobigwest.com> Johannes wrote: > corvid wrote: > > Jorge wrote: > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.31.y.git;a=summary > > > > > > Go to NOMMU, wait for tooltip, scroll with mouse wheel... > > > > I don't have one, although I'll try to look into it anyway. > > Do links show up and disappear from the status bar > > properly with the mouse wheel? > > > > It may also have to do with our scrolling code. Sometimes it looks as if the tooltip > is cleared partially, but some part "sticks". I will have a look when I find some time. Ah, I see it now if I set buffered_drawing to the default value. Luckily I don't know anything at all about the buffering code :) From corvid at lavabit.com Thu Oct 8 15:41:00 2009 From: corvid at lavabit.com (corvid) Date: Thu Oct 8 15:45:13 2009 Subject: [Dillo-dev] auto/abs sizes in image.cc, auto/abs/per in textblock.cc In-Reply-To: <20091007052607.GF2529@local.gobigwest.com> References: <20091007052607.GF2529@local.gobigwest.com> Message-ID: <20091008134100.GJ2529@local.gobigwest.com> I wrote: > At http://naturalhistory.museumwales.ac.uk/sharpshooters/ > two of the image tags specify a size for one dimension, giving > it as 100%. When one dimension is auto and the other is percentage, > it doesn't scale properly. > > I see that calculation using percentage has to be in > textblock because it uses availWidth or availHeight, so... > is there a deep need to keep the auto/abs case in > Image's sizeRequestImpl instead of Textblock's calcWidgetSize? > > I was just playing with adding all of the cases to calcWidgetSize > and it looked like it was working except that an unloaded image > with, e.g., height=100% alt=whatever would end up ridiculously > wide because height_of_page / height_of_alt_text * width_of_alt_text > is a large number. I eventually ran into a page where simplemindedly taking, say, width=50% and expanding the height accordingly was bad. It had an
. Hmph. Web browsers are too complicated; let's make something easy instead :) From jcid at dillo.org Thu Oct 8 18:34:44 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Oct 8 18:35:19 2009 Subject: [Dillo-dev] auto/abs sizes in image.cc, auto/abs/per in textblock.cc In-Reply-To: <20091008134100.GJ2529@local.gobigwest.com> References: <20091007052607.GF2529@local.gobigwest.com> <20091008134100.GJ2529@local.gobigwest.com> Message-ID: <20091008163444.GA31215@dillo.org> On Thu, Oct 08, 2009 at 01:41:00PM +0000, corvid wrote: > > Web browsers are too complicated; let's make something > easy instead :) This is one of the paramount issues in our project. The underlying technologies and web pages were infected with complexity and broken standards, as part of a plan to stiffle and extinguish competition, with the goal of controlling the web market for huge profit. Information gathering for more obscure objectives came into the scene when the web expanded more and more into our lives. Vested interests in this game are huge. Dillo remains as a quixotic quest for those of us that want to browse the web's information as free citizens, trying to avoid the treacherous technologies that usually hide behind a friendly-looking aegis. Others have succeeded in similar quests (e.g. the toolchain, the kernel, a C library, cryptography, etc). AFAIS the goal is to develop a trusty free-platform that doesn't help to enslave us more in this digital era, but on the contrary, that empowers its community to communicate and build upon it, in many areas of human interest (not only technology), and help it grow stronger as they interact with each other. Our particular success with the dillo project depends on our ability to attract more developers that provide the manpower necessary to be able to make it more useful for everyone of us. To attract new developers, we need to show an interesting state that inspires them to look forward. I believe that now we have a big opportunity when dillo makes it into Debian. If we can make it a help browser (by providing a good interface or dpi for instance), lots of people would be looking at it, and that would also give developers the opportunity to consider whether helping dillo grow is a worthy task. @all: Please comment. -- Cheers Jorge.- From corvid at lavabit.com Sat Oct 10 02:44:53 2009 From: corvid at lavabit.com (corvid) Date: Sat Oct 10 02:48:43 2009 Subject: new fltk2 snapshot (Re: [Dillo-dev] textarea multiline input bug) In-Reply-To: <20091002185237.GA32483@local.gobigwest.com> References: <20091002113851.bf85146f.dennisn@dennisn.dyndns.org> <20091002185237.GA32483@local.gobigwest.com> Message-ID: <20091010004453.GL2529@local.gobigwest.com> I wrote: > Dennis wrote: > > In textareas (multiline form input), say for example: > > > > http://translate.google.ca/translate_t > > > > ... if I first enter the following line into the textarea: > > > > yo soy anarco-capitalista > > > > ... and after submitting it, I edit it (the previous contents are > > retained -- although I suspect internally there might be something > > broken -- not sure where it breaks exactly.), by inserting a newline at > > the very beginning (pressing enter), then backspacing (removing the > > newline) to make it appear exactly the same, then resubmitting the > > form, strange stuff happens. > > > > (I remember earlier posting experiences some of my lines getting > > duplicated, and other strange stuff. I think it only happens when I > > edit stuff at the beginning.) > > You have found a FLTK bug. > > I think in the beginning of TextBuffer::text(), > where it goes > > if (!gapstart_ && length_) { > buf_[length_+gapend_] = 0; > return buf_+gapstart_; > } > > they want > > if (!gapstart_ && length_) { > buf_[length_+gapend_] = 0; > return buf_+gapend_; > } The new FLTK2 weekly snapshot has the fix. From Johannes.Hofmann at gmx.de Sun Oct 11 17:58:11 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sun Oct 11 18:00:33 2009 Subject: [Dillo-dev] auto/abs sizes in image.cc, auto/abs/per in textblock.cc In-Reply-To: <20091008163444.GA31215@dillo.org> References: <20091007052607.GF2529@local.gobigwest.com> <20091008134100.GJ2529@local.gobigwest.com> <20091008163444.GA31215@dillo.org> Message-ID: <20091011155811.GB958@blob.baaderstrasse.com> Hi Jorge, On Thu, Oct 08, 2009 at 12:34:44PM -0400, Jorge Arellano Cid wrote: > On Thu, Oct 08, 2009 at 01:41:00PM +0000, corvid wrote: > > > > Web browsers are too complicated; let's make something > > easy instead :) > > This is one of the paramount issues in our project. > > The underlying technologies and web pages were infected with > complexity and broken standards, as part of a plan to stiffle and > extinguish competition, with the goal of controlling the web > market for huge profit. Information gathering for more obscure > objectives came into the scene when the web expanded more and > more into our lives. > > Vested interests in this game are huge. > > Dillo remains as a quixotic quest for those of us that want to > browse the web's information as free citizens, trying to avoid > the treacherous technologies that usually hide behind a > friendly-looking aegis. > > Others have succeeded in similar quests (e.g. the toolchain, > the kernel, a C library, cryptography, etc). AFAIS the goal is to > develop a trusty free-platform that doesn't help to enslave us > more in this digital era, but on the contrary, that empowers its > community to communicate and build upon it, in many areas of > human interest (not only technology), and help it grow stronger > as they interact with each other. I don't have much to add here :) > > Our particular success with the dillo project depends on our > ability to attract more developers that provide the manpower > necessary to be able to make it more useful for everyone of us. > > To attract new developers, we need to show an interesting state > that inspires them to look forward. I believe that now we have a > big opportunity when dillo makes it into Debian. If we can make > it a help browser (by providing a good interface or dpi for > instance), lots of people would be looking at it, and that would > also give developers the opportunity to consider whether helping > dillo grow is a worthy task. I think that cleaning up the code and reducing complexity is the key. That makes it easy and fun to get started. I have two things in mind in particular: * Multiple views in dw/*. Either we find and implement a use case for that feature or we should remove it. Currently it just makes things complicated. * The scrollbar handling is more complicated than needed. I will refresh my old patch that makes scrollbars part of the GUI and put it up for discussion. There is this sticky tooltip bug in the scrolling code lurking, so we need to touch that code anyway. Cheers, Johannes From corvid at lavabit.com Sun Oct 11 20:44:07 2009 From: corvid at lavabit.com (corvid) Date: Sun Oct 11 20:48:14 2009 Subject: [Dillo-dev] auto/abs sizes in image.cc, auto/abs/per in textblock.cc In-Reply-To: <20091011155811.GB958@blob.baaderstrasse.com> References: <20091007052607.GF2529@local.gobigwest.com> <20091008134100.GJ2529@local.gobigwest.com> <20091008163444.GA31215@dillo.org> <20091011155811.GB958@blob.baaderstrasse.com> Message-ID: <20091011184407.GN2529@local.gobigwest.com> Johannes wrote: > * Multiple views in dw/*. Either we find and implement a use case > for that feature or we should remove it. Currently it just makes > things complicated. It does indeed. I wonder about fltkpreview... we keep it in good enough shape to compile, but surely it's accumulated enough rot not to work right, whatever it's supposed to do exactly. > * The scrollbar handling is more complicated than needed. I will > refresh my old patch that makes scrollbars part of the GUI and put > it up for discussion. There is this sticky tooltip bug in the > scrolling code lurking, so we need to touch that code anyway. I like the idea of getting to remove some of the scrolling key bindings code. An article on size and complexity in the case of animals, for anyone with spare time for reading articles: http://jezzmo.com/ancestors/haldane/jbsh/obtrs.html From nst at gersys.de Tue Oct 13 18:48:51 2009 From: nst at gersys.de (Stefan Strobl) Date: Tue Oct 13 18:49:46 2009 Subject: [Dillo-dev] flicker at reload Message-ID: <4AD4AF73.8000001@gersys.de> Hello I'm new to both dillo and fltk. I'm trying to do two things and I'm hoping you can point me in the right directions on how to do it. 1) flicker at reload When doing a reload my screen flickers and I'd like to get rid of that. I first tried the dillorc option buffered_drawing=0/1/2 but that didn't make any difference. I then tried to find the source where the screen is cleared before redrawing the page. I followed the source of redraw() until layout.cc where topLevel->draw() is executed but I cannot find its implementation. Is the flickering an fltk issue or where is the screen cleared? 2) externally trigger reload I'd like to trigger a page reload externally by another application. I searched a bit about IPC mechanisms of fltk but didn't find any. So I'm thinking about using a UNIX fifo or the system signal SIGUSR2. Do you think this is a good approach? Many thanks Stefan. From Johannes.Hofmann at gmx.de Tue Oct 13 19:13:45 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Oct 13 19:16:07 2009 Subject: [Dillo-dev] flicker at reload In-Reply-To: <4AD4AF73.8000001@gersys.de> References: <4AD4AF73.8000001@gersys.de> Message-ID: <20091013171345.GA1889@blob.baaderstrasse.com> Hi Stefan, On Tue, Oct 13, 2009 at 06:48:51PM +0200, Stefan Strobl wrote: > Hello > > I'm new to both dillo and fltk. I'm trying to do two things and I'm > hoping you can point me in the right directions on how to do it. > > 1) flicker at reload > When doing a reload my screen flickers and I'd like to get rid of that. > I first tried the dillorc option buffered_drawing=0/1/2 but that didn't > make any difference. I then tried to find the source where the screen is > cleared before redrawing the page. I followed the source of redraw() > until layout.cc where topLevel->draw() is executed but I cannot find its > implementation. I would recommend to start in FltkViewBase::draw(). Or maybe FltkViewport::draw() if you are interested in scrolling too. > Is the flickering an fltk issue or where is the screen cleared? I'm not sure. It might just be that the freshly loaded page is rendered while it is not 100% loaded, which would blank the screen. Then it is drawn again after loading has completed. I would suggest to put printf()s in FltkViewBase::draw() (the actual draw) and Layout::queueResize() (which requests a complete redraw) to see what is going on. You can also use gdb an breakpoints of course. The flickering is certainly caused by dillo code and is not a general issue of fltk. > > 2) externally trigger reload > I'd like to trigger a page reload externally by another application. I > searched a bit about IPC mechanisms of fltk but didn't find any. So I'm > thinking about using a UNIX fifo or the system signal SIGUSR2. Do you > think this is a good approach? If you just need to trigger a reload, SIGUSR2 might be ok. For a more general remote control fifo's or maybe stdin might be an option. You can check what other browsers do. Cheers, Johannes PS: Please let us know your findings! From corvid at lavabit.com Tue Oct 13 19:48:41 2009 From: corvid at lavabit.com (corvid) Date: Tue Oct 13 19:52:31 2009 Subject: [Dillo-dev] flicker at reload In-Reply-To: <20091013171345.GA1889@blob.baaderstrasse.com> References: <4AD4AF73.8000001@gersys.de> <20091013171345.GA1889@blob.baaderstrasse.com> Message-ID: <20091013174841.GA17622@local.gobigwest.com> Johannes wrote: > On Tue, Oct 13, 2009 at 06:48:51PM +0200, Stefan Strobl wrote: > > 2) externally trigger reload > > I'd like to trigger a page reload externally by another application. I > > searched a bit about IPC mechanisms of fltk but didn't find any. So I'm > > thinking about using a UNIX fifo or the system signal SIGUSR2. Do you > > think this is a good approach? > > If you just need to trigger a reload, SIGUSR2 might be ok. For a > more general remote control fifo's or maybe stdin might be an > option. You can check what other browsers do. I remember Enrico Weigelt talking some on the list last year about using 9P for things like this. I don't think he implemented anything, though. I have no idea whether it would be trivial or a whole lot of work... From jcid at dillo.org Tue Oct 13 21:31:56 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Oct 13 21:32:31 2009 Subject: [Dillo-dev] flicker at reload In-Reply-To: <20091013171345.GA1889@blob.baaderstrasse.com> References: <4AD4AF73.8000001@gersys.de> <20091013171345.GA1889@blob.baaderstrasse.com> Message-ID: <20091013193156.GA10032@dillo.org> On Tue, Oct 13, 2009 at 07:13:45PM +0200, Johannes Hofmann wrote: > Hi Stefan, > > On Tue, Oct 13, 2009 at 06:48:51PM +0200, Stefan Strobl wrote: > > Hello > > > > I'm new to both dillo and fltk. I'm trying to do two things and I'm > > hoping you can point me in the right directions on how to do it. > > > > 1) flicker at reload > > When doing a reload my screen flickers and I'd like to get rid of that. > > I first tried the dillorc option buffered_drawing=0/1/2 but that didn't > > make any difference. I then tried to find the source where the screen is > > cleared before redrawing the page. I followed the source of redraw() > > until layout.cc where topLevel->draw() is executed but I cannot find its > > implementation. > > I would recommend to start in FltkViewBase::draw(). Or maybe > FltkViewport::draw() if you are interested in scrolling too. > > > Is the flickering an fltk issue or where is the screen cleared? > > I'm not sure. It might just be that the freshly loaded page is > rendered while it is not 100% loaded, which would blank the screen. > Then it is drawn again after loading has completed. > I would suggest to put printf()s in FltkViewBase::draw() (the actual > draw) and Layout::queueResize() (which requests a complete redraw) > to see what is going on. You can also use gdb an breakpoints of > course. > The flickering is certainly caused by dillo code and is not a > general issue of fltk. > > > > > 2) externally trigger reload > > I'd like to trigger a page reload externally by another application. I > > searched a bit about IPC mechanisms of fltk but didn't find any. So I'm > > thinking about using a UNIX fifo or the system signal SIGUSR2. Do you > > think this is a good approach? > > If you just need to trigger a reload, SIGUSR2 might be ok. For a > more general remote control fifo's or maybe stdin might be an > option. You can check what other browsers do. Ditto. I have the idea of a remote control dpi for dillo that allows to command it as necessary (think of a help browser). In this case you'd need reload and maybe the ability to send it to other pages or make it cycle or whatever. This feature needs a revision of the dillo plugin protocol (DPIP). I've been working on it for some time now, and hope to commit big changes this month. With regard to using dillo as a display for embedded devices, the idea is feasible and you'd be good testing with SIGUSR2 and reload by now. The golden idea is to use dpip to be able to update individual widgets using DOM. That would be really good. Specially if there was an interested sponsor! ;) -- Cheers Jorge.- From dennisn at dennisn.dyndns.org Wed Oct 14 00:06:56 2009 From: dennisn at dennisn.dyndns.org (Dennis Nezic) Date: Wed Oct 14 00:24:27 2009 Subject: [Dillo-dev] Re: new fltk2 snapshot (Re: textarea multiline input bug) References: <20091002113851.bf85146f.dennisn@dennisn.dyndns.org> <20091002185237.GA32483@local.gobigwest.com> <20091010004453.GL2529@local.gobigwest.com> Message-ID: <20091013180656.da1ca71a.dennisn@dennisn.dyndns.org> On Sat, 10 Oct 2009 00:44:53 +0000, corvid wrote: > I wrote: > > Dennis wrote: > > > In textareas (multiline form input), say for example: > > > > > > http://translate.google.ca/translate_t > > > > > > ... if I first enter the following line into the textarea: > > > > > > yo soy anarco-capitalista > > > > > > ... and after submitting it, I edit it (the previous contents are > > > retained -- although I suspect internally there might be something > > > broken -- not sure where it breaks exactly.), by inserting a > > > newline at the very beginning (pressing enter), then backspacing > > > (removing the newline) to make it appear exactly the same, then > > > resubmitting the form, strange stuff happens. > > > > > > (I remember earlier posting experiences some of my lines getting > > > duplicated, and other strange stuff. I think it only happens when > > > I edit stuff at the beginning.) > > > > You have found a FLTK bug. > > > > I think in the beginning of TextBuffer::text(), > > where it goes > > > > if (!gapstart_ && length_) { > > buf_[length_+gapend_] = 0; > > return buf_+gapstart_; > > } > > > > they want > > > > if (!gapstart_ && length_) { > > buf_[length_+gapend_] = 0; > > return buf_+gapend_; > > } > > The new FLTK2 weekly snapshot has the fix. Thank you! From nst at gersys.de Wed Oct 14 13:34:43 2009 From: nst at gersys.de (Stefan) Date: Wed Oct 14 13:35:41 2009 Subject: [Dillo-dev] flicker at reload In-Reply-To: <20091013171345.GA1889@blob.baaderstrasse.com> References: <4AD4AF73.8000001@gersys.de> <20091013171345.GA1889@blob.baaderstrasse.com> Message-ID: <4AD5B753.5040504@gersys.de> Johannes Hofmann wrote: > On Tue, Oct 13, 2009 at 06:48:51PM +0200, Stefan wrote: >> 1) flicker at reload >> When doing a reload my screen flickers and I'd like to get rid of that. >> I first tried the dillorc option buffered_drawing=0/1/2 but that didn't >> make any difference. I then tried to find the source where the screen is >> cleared before redrawing the page. I followed the source of redraw() >> until layout.cc where topLevel->draw() is executed but I cannot find its >> implementation. > > I'm not sure. It might just be that the freshly loaded page is > rendered while it is not 100% loaded, which would blank the screen. > Then it is drawn again after loading has completed. > I would suggest to put printf()s in FltkViewBase::draw() (the actual > draw) and Layout::queueResize() (which requests a complete redraw) > to see what is going on. You can also use gdb an breakpoints of > course. Thanks for the feedback to all of you. I'll try to find the origin of the flickering. >> 2) externally trigger reload >> I'd like to trigger a page reload externally by another application. I >> searched a bit about IPC mechanisms of fltk but didn't find any. So I'm >> thinking about using a UNIX fifo or the system signal SIGUSR2. Do you >> think this is a good approach? > > If you just need to trigger a reload, SIGUSR2 might be ok. For a > more general remote control fifo's or maybe stdin might be an > option. You can check what other browsers do. Please see below the patch on how I've done it. Two issues: a) The signal() function is ambiguous because there's a namespace lout::signal in lout/signal.hh. I don't know how to tell the compiler to use the correct signal(). I tried std::signal() but that didn't work. If I temporarily rename the lout::signal to something else the patch seems to work. b) Using SIGUSR, do I have to worry about interrupting the main flow of dillo at a bad moment, or is it safe the way I've done it? I think other browsers use IPC mechanisms of the toolkit for things like this, but I think fltk2 doesn't provide some such thing. Many thanks Stefan. ----- diff -r 7cdd8e4f8076 src/uicmd.cc --- a/src/uicmd.cc Sat Oct 10 03:04:12 2009 +0000 +++ b/src/uicmd.cc Wed Oct 14 13:20:04 2009 +0200 @@ -15,6 +15,7 @@ #include #include #include /* for rint */ +#include #include #include @@ -44,6 +45,21 @@ // Handy macro #define BW2UI(bw) ((UI*)((bw)->ui)) + +/* + * sig_usr() + */ +static void sig_usr(int signo) +{ + int i; + if (signo == SIGUSR1) { + for (i=0; icallback(win_cb, new_bw); + /* setup SIGUSR1 for external triggering of reload */ + if (signal(SIGUSR1, sig_usr) == SIG_ERR) + MSG_WARN("can't catch SIGUSR1\n"); + return new_bw; } From jcid at dillo.org Wed Oct 14 15:35:18 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Oct 14 15:35:54 2009 Subject: [Dillo-dev] auto/abs sizes in image.cc, auto/abs/per in textblock.cc In-Reply-To: <20091011155811.GB958@blob.baaderstrasse.com> References: <20091007052607.GF2529@local.gobigwest.com> <20091008134100.GJ2529@local.gobigwest.com> <20091008163444.GA31215@dillo.org> <20091011155811.GB958@blob.baaderstrasse.com> Message-ID: <20091014133517.GA3481@dillo.org> On Sun, Oct 11, 2009 at 05:58:11PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > On Thu, Oct 08, 2009 at 12:34:44PM -0400, Jorge Arellano Cid wrote: > > On Thu, Oct 08, 2009 at 01:41:00PM +0000, corvid wrote: > > > > > > Web browsers are too complicated; let's make something > > > easy instead :) > > > > This is one of the paramount issues in our project. > > > > The underlying technologies and web pages were infected with > > complexity and broken standards, as part of a plan to stiffle and > > extinguish competition, with the goal of controlling the web > > market for huge profit. Information gathering for more obscure > > objectives came into the scene when the web expanded more and > > more into our lives. > > > > Vested interests in this game are huge. > > > > Dillo remains as a quixotic quest for those of us that want to > > browse the web's information as free citizens, trying to avoid > > the treacherous technologies that usually hide behind a > > friendly-looking aegis. > > > > Others have succeeded in similar quests (e.g. the toolchain, > > the kernel, a C library, cryptography, etc). AFAIS the goal is to > > develop a trusty free-platform that doesn't help to enslave us > > more in this digital era, but on the contrary, that empowers its > > community to communicate and build upon it, in many areas of > > human interest (not only technology), and help it grow stronger > > as they interact with each other. > > I don't have much to add here :) I'll happily assume we agree! > > Our particular success with the dillo project depends on our > > ability to attract more developers that provide the manpower > > necessary to be able to make it more useful for everyone of us. > > > > To attract new developers, we need to show an interesting state > > that inspires them to look forward. I believe that now we have a > > big opportunity when dillo makes it into Debian. If we can make > > it a help browser (by providing a good interface or dpi for > > instance), lots of people would be looking at it, and that would > > also give developers the opportunity to consider whether helping > > dillo grow is a worthy task. > > I think that cleaning up the code and reducing complexity is the > key. That makes it easy and fun to get started. My feeling is exactly. Reducing complexity is and had been the key (e.g. on HTPP, HTML, etc). BTW, corvid's suggested article is inspiring in this matter: http://jezzmo.com/ancestors/haldane/jbsh/obtrs.html Now, IIRC, long ago you mentioned the concept of being useful. It's useful for us, let's make it useful more people. This is also key. If we can find the right tradeoffs dillo would be more attractive to both users and developers. Right now, I see these ones very close: 1.- Rendering of floating objects. (very visible for users) 2.- Providing a remote control. (useful for help-browser and embedded apps.) 3.- Better DPIP API and dpi examples. (useful for developers) All of them don't increase the browser size through a boundary, as described in the article. It'd be great to have them when Dillo makes it into Debian again. > I have two things in mind in particular: > > * Multiple views in dw/*. Either we find and implement a use case > for that feature or we should remove it. Currently it just makes > things complicated. Yes. A long time ago I saw Sebastian making some use of it in development code and nothing else. Currently it has no use in dillo, so I agree with the removal. If one day we need it badly, it can be added back. > * The scrollbar handling is more complicated than needed. I will > refresh my old patch that makes scrollbars part of the GUI and put > it up for discussion. There is this sticky tooltip bug in the > scrolling code lurking, so we need to touch that code anyway. Good, I always liked this patch. -- Cheers Jorge.- From corvid at lavabit.com Wed Oct 14 16:53:33 2009 From: corvid at lavabit.com (corvid) Date: Wed Oct 14 16:57:24 2009 Subject: [Dillo-dev] auto/abs sizes in image.cc, auto/abs/per in textblock.cc In-Reply-To: <20091014133517.GA3481@dillo.org> References: <20091007052607.GF2529@local.gobigwest.com> <20091008134100.GJ2529@local.gobigwest.com> <20091008163444.GA31215@dillo.org> <20091011155811.GB958@blob.baaderstrasse.com> <20091014133517.GA3481@dillo.org> Message-ID: <20091014145333.GA19214@local.gobigwest.com> Jorge wrote: > On Sun, Oct 11, 2009 at 05:58:11PM +0200, Johannes Hofmann wrote: > > > * Multiple views in dw/*. Either we find and implement a use case > > for that feature or we should remove it. Currently it just makes > > things complicated. > > Yes. A long time ago I saw Sebastian making some use of it in > development code and nothing else. Currently it has no use in > dillo, so I agree with the removal. If one day we need it badly, > it can be added back. I'll look into removing it. From Johannes.Hofmann at gmx.de Wed Oct 14 19:44:41 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Oct 14 19:47:04 2009 Subject: [Dillo-dev] flicker at reload In-Reply-To: <4AD5B753.5040504@gersys.de> References: <4AD4AF73.8000001@gersys.de> <20091013171345.GA1889@blob.baaderstrasse.com> <4AD5B753.5040504@gersys.de> Message-ID: <20091014174441.GA2138@blob.baaderstrasse.com> On Wed, Oct 14, 2009 at 01:34:43PM +0200, Stefan wrote: > Johannes Hofmann wrote: > > On Tue, Oct 13, 2009 at 06:48:51PM +0200, Stefan wrote: > >> 1) flicker at reload > >> When doing a reload my screen flickers and I'd like to get rid of that. > >> I first tried the dillorc option buffered_drawing=0/1/2 but that didn't > >> make any difference. I then tried to find the source where the screen is > >> cleared before redrawing the page. I followed the source of redraw() > >> until layout.cc where topLevel->draw() is executed but I cannot find its > >> implementation. > > > > I'm not sure. It might just be that the freshly loaded page is > > rendered while it is not 100% loaded, which would blank the screen. > > Then it is drawn again after loading has completed. > > I would suggest to put printf()s in FltkViewBase::draw() (the actual > > draw) and Layout::queueResize() (which requests a complete redraw) > > to see what is going on. You can also use gdb an breakpoints of > > course. > > Thanks for the feedback to all of you. I'll try to find the origin of > the flickering. > > >> 2) externally trigger reload > >> I'd like to trigger a page reload externally by another application. I > >> searched a bit about IPC mechanisms of fltk but didn't find any. So I'm > >> thinking about using a UNIX fifo or the system signal SIGUSR2. Do you > >> think this is a good approach? > > > > If you just need to trigger a reload, SIGUSR2 might be ok. For a > > more general remote control fifo's or maybe stdin might be an > > option. You can check what other browsers do. > > Please see below the patch on how I've done it. Two issues: > a) The signal() function is ambiguous because there's a namespace > lout::signal in lout/signal.hh. I don't know how to tell the compiler to > use the correct signal(). I tried std::signal() but that didn't work. If > I temporarily rename the lout::signal to something else the patch seems > to work. That's a bug. I will fix it. > > b) Using SIGUSR, do I have to worry about interrupting the main flow of > dillo at a bad moment, or is it safe the way I've done it? You should just set a flag in the sighandler and do the actual work from the normal context (when the flag is set). Otherwise strange things will happen depending on what dillo is currently doing when you send the signal. Cheers, Johannes From Johannes.Hofmann at gmx.de Thu Oct 15 20:14:29 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Thu Oct 15 20:16:52 2009 Subject: [Dillo-dev] flicker at reload In-Reply-To: <20091014174441.GA2138@blob.baaderstrasse.com> References: <4AD4AF73.8000001@gersys.de> <20091013171345.GA1889@blob.baaderstrasse.com> <4AD5B753.5040504@gersys.de> <20091014174441.GA2138@blob.baaderstrasse.com> Message-ID: <20091015181429.GA7860@blob.baaderstrasse.com> On Wed, Oct 14, 2009 at 07:44:41PM +0200, Johannes Hofmann wrote: > On Wed, Oct 14, 2009 at 01:34:43PM +0200, Stefan wrote: > > Johannes Hofmann wrote: > > > On Tue, Oct 13, 2009 at 06:48:51PM +0200, Stefan wrote: > > >> 1) flicker at reload > > >> When doing a reload my screen flickers and I'd like to get rid of that. > > >> I first tried the dillorc option buffered_drawing=0/1/2 but that didn't > > >> make any difference. I then tried to find the source where the screen is > > >> cleared before redrawing the page. I followed the source of redraw() > > >> until layout.cc where topLevel->draw() is executed but I cannot find its > > >> implementation. > > > > > > I'm not sure. It might just be that the freshly loaded page is > > > rendered while it is not 100% loaded, which would blank the screen. > > > Then it is drawn again after loading has completed. > > > I would suggest to put printf()s in FltkViewBase::draw() (the actual > > > draw) and Layout::queueResize() (which requests a complete redraw) > > > to see what is going on. You can also use gdb an breakpoints of > > > course. > > > > Thanks for the feedback to all of you. I'll try to find the origin of > > the flickering. > > > > >> 2) externally trigger reload > > >> I'd like to trigger a page reload externally by another application. I > > >> searched a bit about IPC mechanisms of fltk but didn't find any. So I'm > > >> thinking about using a UNIX fifo or the system signal SIGUSR2. Do you > > >> think this is a good approach? > > > > > > If you just need to trigger a reload, SIGUSR2 might be ok. For a > > > more general remote control fifo's or maybe stdin might be an > > > option. You can check what other browsers do. > > > > Please see below the patch on how I've done it. Two issues: > > a) The signal() function is ambiguous because there's a namespace > > lout::signal in lout/signal.hh. I don't know how to tell the compiler to > > use the correct signal(). I tried std::signal() but that didn't work. If > > I temporarily rename the lout::signal to something else the patch seems > > to work. > > That's a bug. I will fix it. It should be fixed now. Please check again with current tip. Cheers, Johannes From corvid at lavabit.com Thu Oct 15 22:11:17 2009 From: corvid at lavabit.com (corvid) Date: Thu Oct 15 22:15:09 2009 Subject: [Dillo-dev] auto/abs sizes in image.cc, auto/abs/per in textblock.cc In-Reply-To: <20091014145333.GA19214@local.gobigwest.com> References: <20091007052607.GF2529@local.gobigwest.com> <20091008134100.GJ2529@local.gobigwest.com> <20091008163444.GA31215@dillo.org> <20091011155811.GB958@blob.baaderstrasse.com> <20091014133517.GA3481@dillo.org> <20091014145333.GA19214@local.gobigwest.com> Message-ID: <20091015201117.GE19214@local.gobigwest.com> I wrote: > Jorge wrote: > > On Sun, Oct 11, 2009 at 05:58:11PM +0200, Johannes Hofmann wrote: > > > > > * Multiple views in dw/*. Either we find and implement a use case > > > for that feature or we should remove it. Currently it just makes > > > things complicated. > > > > Yes. A long time ago I saw Sebastian making some use of it in > > development code and nothing else. Currently it has no use in > > dillo, so I agree with the removal. If one day we need it badly, > > it can be added back. > > I'll look into removing it. Committed. It does touch fltkui.cc enough that you may want to keep an eye on whether forms are submitting what you tell them to. Everything seems right with my form test pages, though... From jcid at dillo.org Fri Oct 16 19:56:32 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Oct 16 19:57:07 2009 Subject: [Dillo-dev] FWD Message-ID: <20091016175632.GA11465@dillo.org> Hi, [Alexandre Berges (alexandre dot berges @ GMAIL) wrote:] > Hello > > I use Dillo and i like it. > I have a littel problem with it it's how to use letter-spacing attribut. I > know this attribut is'nt implemented > Do you know when this attribute will be implemented ? -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Fri Oct 16 20:43:01 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Fri Oct 16 20:45:24 2009 Subject: [Dillo-dev] FWD In-Reply-To: <20091016175632.GA11465@dillo.org> References: <20091016175632.GA11465@dillo.org> Message-ID: <20091016184301.GA2662@blob.baaderstrasse.com> On Fri, Oct 16, 2009 at 02:56:32PM -0300, Jorge Arellano Cid wrote: > Hi, > > [Alexandre Berges (alexandre dot berges @ GMAIL) wrote:] > > > Hello > > > > I use Dillo and i like it. > > I have a littel problem with it it's how to use letter-spacing attribut. I > > know this attribut is'nt implemented > > Do you know when this attribute will be implemented ? I guess it would be pretty straight forward to add if we find out how to change the letter spacing in fltk. Cheers, Johannes From corvid at lavabit.com Fri Oct 16 22:21:13 2009 From: corvid at lavabit.com (corvid) Date: Fri Oct 16 22:25:05 2009 Subject: [Dillo-dev] FWD In-Reply-To: <20091016184301.GA2662@blob.baaderstrasse.com> References: <20091016175632.GA11465@dillo.org> <20091016184301.GA2662@blob.baaderstrasse.com> Message-ID: <20091016202113.GG19214@local.gobigwest.com> Johannes wrote: > On Fri, Oct 16, 2009 at 02:56:32PM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > [Alexandre Berges (alexandre dot berges @ GMAIL) wrote:] > > > > > Hello > > > > > > I use Dillo and i like it. > > > I have a littel problem with it it's how to use letter-spacing attribut. I > > > know this attribut is'nt implemented > > > Do you know when this attribute will be implemented ? > > I guess it would be pretty straight forward to add if we find out > how to change the letter spacing in fltk. I believe we would have to draw each glyph individually. If you implement the css parser part and get the values into style, I think I know what to do in textblock and drawText (famous last words, right? :). It wouldn't work for Chinese/Japanese since we're currently pretending that they're words, but oh well. From Johannes.Hofmann at gmx.de Fri Oct 16 22:42:06 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Fri Oct 16 22:44:29 2009 Subject: [Dillo-dev] FWD In-Reply-To: <20091016202113.GG19214@local.gobigwest.com> References: <20091016175632.GA11465@dillo.org> <20091016184301.GA2662@blob.baaderstrasse.com> <20091016202113.GG19214@local.gobigwest.com> Message-ID: <20091016204206.GA8957@blob.baaderstrasse.com> On Fri, Oct 16, 2009 at 08:21:13PM +0000, corvid wrote: > Johannes wrote: > > On Fri, Oct 16, 2009 at 02:56:32PM -0300, Jorge Arellano Cid wrote: > > > Hi, > > > > > > [Alexandre Berges (alexandre dot berges @ GMAIL) wrote:] > > > > > > > Hello > > > > > > > > I use Dillo and i like it. > > > > I have a littel problem with it it's how to use letter-spacing attribut. I > > > > know this attribut is'nt implemented > > > > Do you know when this attribute will be implemented ? > > > > I guess it would be pretty straight forward to add if we find out > > how to change the letter spacing in fltk. > > I believe we would have to draw each glyph individually. Hm, i would prefer to handle it as a different font. There is this XFT_SPACING flag which could be passed in XftFontOpen() in fltk-2.0.x-r6786/src/x11/Font_xft.cxx If that could be added to fltk, then spacing would just be another Font property. But I don't know what fltk people think about it. Alternatively we could add the spacing attribute just to our Font class and handle the messy glyph by glyph drawing in fltkplatform.cc. That way we could keep the complexity out of textblock.cc which is complex enough already :-) > > If you implement the css parser part and get the values > into style, I think I know what to do in textblock and > drawText (famous last words, right? :). > > It wouldn't work for Chinese/Japanese since we're currently > pretending that they're words, but oh well. > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev From corvid at lavabit.com Sat Oct 17 01:30:52 2009 From: corvid at lavabit.com (corvid) Date: Sat Oct 17 01:34:44 2009 Subject: [Dillo-dev] FWD In-Reply-To: <20091016204206.GA8957@blob.baaderstrasse.com> References: <20091016175632.GA11465@dillo.org> <20091016184301.GA2662@blob.baaderstrasse.com> <20091016202113.GG19214@local.gobigwest.com> <20091016204206.GA8957@blob.baaderstrasse.com> Message-ID: <20091016233052.GH19214@local.gobigwest.com> Johannes wrote: > On Fri, Oct 16, 2009 at 08:21:13PM +0000, corvid wrote: > > Johannes wrote: > > > On Fri, Oct 16, 2009 at 02:56:32PM -0300, Jorge Arellano Cid wrote: > > > > Hi, > > > > > > > > [Alexandre Berges (alexandre dot berges @ GMAIL) wrote:] > > > > > > > > > Hello > > > > > > > > > > I use Dillo and i like it. > > > > > I have a littel problem with it it's how to use letter-spacing attribut. I > > > > > know this attribut is'nt implemented > > > > > Do you know when this attribute will be implemented ? > > > > > > I guess it would be pretty straight forward to add if we find out > > > how to change the letter spacing in fltk. > > > > I believe we would have to draw each glyph individually. > > Hm, i would prefer to handle it as a different font. There is this > XFT_SPACING flag which could be passed in XftFontOpen() in > fltk-2.0.x-r6786/src/x11/Font_xft.cxx > If that could be added to fltk, then spacing would just be another > Font property. > But I don't know what fltk people think about it. Is there something for the non-xft case? > Alternatively we could add the spacing attribute just to our Font > class and handle the messy glyph by glyph drawing in > fltkplatform.cc. > That way we could keep the complexity out of textblock.cc which is > complex enough already :-) Ah, I did mean drawText() in fltkviewbase, but then I didn't think of touching fltkplatform's textWidth(). From onepoint at starurchin.org Sat Oct 17 11:03:47 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sat Oct 17 11:04:43 2009 Subject: [Dillo-dev] auto/abs sizes in image.cc, auto/abs/per in textblock.cc In-Reply-To: <20091015201117.GE19214@local.gobigwest.com> References: <20091007052607.GF2529@local.gobigwest.com> <20091008134100.GJ2529@local.gobigwest.com> <20091008163444.GA31215@dillo.org> <20091011155811.GB958@blob.baaderstrasse.com> <20091014133517.GA3481@dillo.org> <20091014145333.GA19214@local.gobigwest.com> <20091015201117.GE19214@local.gobigwest.com> Message-ID: <20091017090347.GJ3084@omphalos.singularity> corvid wrote: > I wrote: > > Jorge wrote: > > > On Sun, Oct 11, 2009 at 05:58:11PM +0200, Johannes Hofmann > > > wrote: > > > > * Multiple views in dw/*. Either we find and implement a use > > > > case for that feature or we should remove it. ... > > > > > > ... I agree with the removal. ... > > > > I'll look into removing it. > > Committed. It does touch fltkui.cc enough that you may want to keep > an eye on whether forms are submitting what you tell them to. My test forms still work OK, so it can't be *too* badly broken. :-) Regards, Jeremy Henty From Johannes.Hofmann at gmx.de Sat Oct 17 18:06:42 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sat Oct 17 18:09:05 2009 Subject: [Dillo-dev] FWD In-Reply-To: <20091016233052.GH19214@local.gobigwest.com> References: <20091016175632.GA11465@dillo.org> <20091016184301.GA2662@blob.baaderstrasse.com> <20091016202113.GG19214@local.gobigwest.com> <20091016204206.GA8957@blob.baaderstrasse.com> <20091016233052.GH19214@local.gobigwest.com> Message-ID: <20091017160642.GA2475@blob.baaderstrasse.com> On Fri, Oct 16, 2009 at 11:30:52PM +0000, corvid wrote: > Johannes wrote: > > On Fri, Oct 16, 2009 at 08:21:13PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Fri, Oct 16, 2009 at 02:56:32PM -0300, Jorge Arellano Cid wrote: > > > > > Hi, > > > > > > > > > > [Alexandre Berges (alexandre dot berges @ GMAIL) wrote:] > > > > > > > > > > > Hello > > > > > > > > > > > > I use Dillo and i like it. > > > > > > I have a littel problem with it it's how to use letter-spacing attribut. I > > > > > > know this attribut is'nt implemented > > > > > > Do you know when this attribute will be implemented ? > > > > > > > > I guess it would be pretty straight forward to add if we find out > > > > how to change the letter spacing in fltk. > > > > > > I believe we would have to draw each glyph individually. > > > > Hm, i would prefer to handle it as a different font. There is this > > XFT_SPACING flag which could be passed in XftFontOpen() in > > fltk-2.0.x-r6786/src/x11/Font_xft.cxx > > If that could be added to fltk, then spacing would just be another > > Font property. > > But I don't know what fltk people think about it. > > Is there something for the non-xft case? Don't know, plus we would also need something for Windows and MacOS :) > > > Alternatively we could add the spacing attribute just to our Font > > class and handle the messy glyph by glyph drawing in > > fltkplatform.cc. > > That way we could keep the complexity out of textblock.cc which is > > complex enough already :-) > > Ah, I did mean drawText() in fltkviewbase, but then I > didn't think of touching fltkplatform's textWidth(). Yes, that sounds good. textWidth() would have to be adapted as well of course. The css part should be easy btw. I will just add it. Cheers, Johannes From eriol2004 at 163.com Sun Oct 18 05:24:49 2009 From: eriol2004 at 163.com (eriol2004) Date: Sun Oct 18 05:25:32 2009 Subject: [Dillo-dev] How to limit cache in Dillo v2.1.1? Message-ID: <19408220.331311255836289581.JavaMail.coremail@bj163app127.163.com> Hello, I am using Dillo v2.1.1 on my embedded device with limitation of memory usage. How to limit the cache size or set no cache to the image? Many thanks. Best Regards Cyril 09年新晋3D主流网游《天下贰》，网易六年亿资打造 -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20091018/f4fcf612/attachment.html From onepoint at starurchin.org Sun Oct 18 12:35:43 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sun Oct 18 12:36:39 2009 Subject: [Dillo-dev] [patch]: fix w3c_plus_heuristics=NO Message-ID: <20091018103543.GK3084@omphalos.singularity> As I understand it, the purpose of the w3c_plus_heuristics preference is to control whether Dillo will force close some tags when it sees an unmatched close tag. But it seems to have no effect! If you try this HTML:

then the tag is closed no matter what w3c_plus_heuristics is! The bug is in Html_tag_cleanup_at_close() in html.cc, in this code: /* Look for the candidate tag to close */ stack_idx = html->stack->size() - 1; while (stack_idx && (cmp = (new_idx != html->stack->getRef(stack_idx)->tag_idx)) && ((w3c_mode && Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O') || ((!w3c_mode && (Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O')) || Tags[html->stack->getRef(stack_idx)->tag_idx].TagLevel < Tags[new_idx].TagLevel))) { --stack_idx; } The indentation makes it appear that the comparison between the TagLevel fields is bracketed with !w3c_mode but both the indentation and the bracketing are wrong. In fact this code is equivalent to: /* Look for the candidate tag to close */ stack_idx = html->stack->size() - 1; while (stack_idx && (cmp = (new_idx != html->stack->getRef(stack_idx)->tag_idx)) && ((w3c_mode && Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O') || (!w3c_mode && (Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O')) || Tags[html->stack->getRef(stack_idx)->tag_idx].TagLevel < Tags[new_idx].TagLevel)) { --stack_idx; } which is in turn equivalent to /* Look for the candidate tag to close */ stack_idx = html->stack->size() - 1; while (stack_idx && (cmp = (new_idx != html->stack->getRef(stack_idx)->tag_idx)) && (Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O' || Tags[html->stack->getRef(stack_idx)->tag_idx].TagLevel < Tags[new_idx].TagLevel)) { --stack_idx; } so that w3c_mode has no effect. In other words w3c_plus_heuristics is effectively always YES, even if dillorc says otherwise. I have attached a patch that implements (what I *think* is) the correct behaviour. Regards, Jeremy Henty -------------- next part -------------- diff -r a81b528fccef -r e4739dad3c37 src/html.cc --- a/src/html.cc Tue Dec 09 14:28:50 2008 +0000 +++ b/src/html.cc Sun Oct 18 09:03:39 2009 +0100 @@ -1319,12 +1319,10 @@ stack_idx = html->stack->size() - 1; while (stack_idx && (cmp = (new_idx != html->stack->getRef(stack_idx)->tag_idx)) && - ((w3c_mode && - Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O') || - ((!w3c_mode && - (Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O')) || - Tags[html->stack->getRef(stack_idx)->tag_idx].TagLevel < - Tags[new_idx].TagLevel))) { + (Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O' || + (!w3c_mode && + Tags[html->stack->getRef(stack_idx)->tag_idx].TagLevel < + Tags[new_idx].TagLevel))) { --stack_idx; } From Johannes.Hofmann at gmx.de Sun Oct 18 18:47:46 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sun Oct 18 18:50:09 2009 Subject: [Dillo-dev] FWD In-Reply-To: <20091016233052.GH19214@local.gobigwest.com> References: <20091016175632.GA11465@dillo.org> <20091016184301.GA2662@blob.baaderstrasse.com> <20091016202113.GG19214@local.gobigwest.com> <20091016204206.GA8957@blob.baaderstrasse.com> <20091016233052.GH19214@local.gobigwest.com> Message-ID: <20091018164746.GA3001@blob.baaderstrasse.com> On Fri, Oct 16, 2009 at 11:30:52PM +0000, corvid wrote: > Johannes wrote: > > On Fri, Oct 16, 2009 at 08:21:13PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Fri, Oct 16, 2009 at 02:56:32PM -0300, Jorge Arellano Cid wrote: > > > > > Hi, > > > > > > > > > > [Alexandre Berges (alexandre dot berges @ GMAIL) wrote:] > > > > > > > > > > > Hello > > > > > > > > > > > > I use Dillo and i like it. > > > > > > I have a littel problem with it it's how to use letter-spacing attribut. I > > > > > > know this attribut is'nt implemented > > > > > > Do you know when this attribute will be implemented ? > > > > > > > > I guess it would be pretty straight forward to add if we find out > > > > how to change the letter spacing in fltk. > > > > > > I believe we would have to draw each glyph individually. > > > > Hm, i would prefer to handle it as a different font. There is this > > XFT_SPACING flag which could be passed in XftFontOpen() in > > fltk-2.0.x-r6786/src/x11/Font_xft.cxx > > If that could be added to fltk, then spacing would just be another > > Font property. > > But I don't know what fltk people think about it. > > Is there something for the non-xft case? > > > Alternatively we could add the spacing attribute just to our Font > > class and handle the messy glyph by glyph drawing in > > fltkplatform.cc. > > That way we could keep the complexity out of textblock.cc which is > > complex enough already :-) > > Ah, I did mean drawText() in fltkviewbase, but then I > didn't think of touching fltkplatform's textWidth(). Nice! You already implemented it. Cheers, Johannes From jcid at dillo.org Tue Oct 20 18:59:11 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Oct 20 18:59:17 2009 Subject: [Dillo-dev] How to limit cache in Dillo v2.1.1? In-Reply-To: <19408220.331311255836289581.JavaMail.coremail@bj163app127.163.com> References: <19408220.331311255836289581.JavaMail.coremail@bj163app127.163.com> Message-ID: <20091020165911.GB10896@dillo.org> Hi, On Sun, Oct 18, 2009 at 11:24:49AM +0800, eriol2004 wrote: > Hello, > I am using Dillo v2.1.1 on my embedded device with limitation > of memory usage. How to limit the cache size or set no cache to > the image? Currently there's no dillorc setting to do it, but if you look in cache.c you'll find a call to a_Dicache_cleanup(). I'd suggest to add a function afterwards (e.g. a_Cache_image_cleanup()), and make it suit your needs. Please report on what you finally did. -- Cheers Jorge.- From jcid at dillo.org Tue Oct 20 19:30:45 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Oct 20 19:30:51 2009 Subject: [Dillo-dev] [patch]: fix w3c_plus_heuristics=NO In-Reply-To: <20091018103543.GK3084@omphalos.singularity> References: <20091018103543.GK3084@omphalos.singularity> Message-ID: <20091020173045.GC10896@dillo.org> On Sun, Oct 18, 2009 at 11:35:43AM +0100, Jeremy Henty wrote: > > As I understand it, the purpose of the w3c_plus_heuristics preference > is to control whether Dillo will force close some tags when it sees an > unmatched close tag. But it seems to have no effect! If you try this > HTML: > > > > >

>
> > > > then the tag is closed no matter what w3c_plus_heuristics is! > > The bug is in Html_tag_cleanup_at_close() in html.cc, in this code: > > /* Look for the candidate tag to close */ > stack_idx = html->stack->size() - 1; > while (stack_idx && > (cmp = (new_idx != html->stack->getRef(stack_idx)->tag_idx)) && > ((w3c_mode && > Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O') || > ((!w3c_mode && > (Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O')) || > Tags[html->stack->getRef(stack_idx)->tag_idx].TagLevel < > Tags[new_idx].TagLevel))) { > --stack_idx; > } > > The indentation makes it appear that the comparison between the > TagLevel fields is bracketed with !w3c_mode but both the indentation > and the bracketing are wrong. In fact this code is equivalent to: > > /* Look for the candidate tag to close */ > stack_idx = html->stack->size() - 1; > while (stack_idx && > (cmp = (new_idx != html->stack->getRef(stack_idx)->tag_idx)) && > ((w3c_mode && > Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O') || > (!w3c_mode && > (Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O')) || > Tags[html->stack->getRef(stack_idx)->tag_idx].TagLevel < > Tags[new_idx].TagLevel)) { > --stack_idx; > } > > which is in turn equivalent to > > /* Look for the candidate tag to close */ > stack_idx = html->stack->size() - 1; > while (stack_idx && > (cmp = (new_idx != html->stack->getRef(stack_idx)->tag_idx)) && > (Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O' || > Tags[html->stack->getRef(stack_idx)->tag_idx].TagLevel < > Tags[new_idx].TagLevel)) { > --stack_idx; > } > > so that w3c_mode has no effect. In other words w3c_plus_heuristics is > effectively always YES, even if dillorc says otherwise. > > I have attached a patch that implements (what I *think* is) the > correct behaviour. Committed! Thanks Jeremy, that part of the code had always been tricky and the patch looks like a big boolean algebra simplification that makes it much easier to undersatand. -- Cheers Jorge.- From onepoint at starurchin.org Wed Oct 21 22:14:29 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Wed Oct 21 22:15:24 2009 Subject: [Dillo-dev] [patch]: fix w3c_plus_heuristics=NO In-Reply-To: <20091020173045.GC10896@dillo.org> References: <20091018103543.GK3084@omphalos.singularity> <20091020173045.GC10896@dillo.org> Message-ID: <20091021201429.GA32538@omphalos.singularity> Jorge Arellano Cid wrote: > ... that part of the code had always been tricky and the patch looks > like a big boolean algebra simplification that makes it much easier > to undersatand. I think we can do more to make it easier to understand. Here's a patch that separates the code that does the cleaning up from the logic that decides what to do. Regards, Jeremy Henty -------------- next part -------------- diff -r c0c0b4b3e9f8 -r 7f1eb453a3f0 src/html.cc --- a/src/html.cc Tue Dec 09 14:28:50 2008 +0000 +++ b/src/html.cc Tue Oct 20 23:09:06 2009 +0100 @@ -1294,6 +1294,20 @@ Html_eventually_pop_dw(html, hand_over_break); } +static void Html_tag_cleanup_to_idx(DilloHtml *html, int idx) +{ + while (html->stack->size() > idx) { + int toptag_idx = S_TOP(html)->tag_idx; + if (html->stack->size() > idx + 1 && + Tags[toptag_idx].EndTag != 'O') + BUG_MSG(" - forcing close of open tag: <%s>\n", + Tags[toptag_idx].name); + _MSG("Close: %*s%s\n", html->stack->size()," ",Tags[toptag_idx].name); + Tags[toptag_idx].close (html, toptag_idx); + Html_real_pop_tag(html); + } +} + /* * Default close function for tags. * (conditional cleanup of the stack) @@ -1328,21 +1342,7 @@ /* clean, up to the matching tag */ if (cmp == 0 && stack_idx > 0) { - /* There's a valid matching tag in the stack */ - while (html->stack->size() > stack_idx) { - int toptag_idx = S_TOP(html)->tag_idx; - /* Warn when we decide to close an open tag (for !w3c_mode) */ - if (html->stack->size() > stack_idx + 1 && - Tags[toptag_idx].EndTag != 'O') - BUG_MSG(" - forcing close of open tag: <%s>\n", - Tags[toptag_idx].name); - - /* Close this and only this tag */ - _MSG("Close: %*s%s\n", html->stack->size()," ",Tags[toptag_idx].name); - Tags[toptag_idx].close (html, toptag_idx); - Html_real_pop_tag(html); - } - + Html_tag_cleanup_to_idx(html, stack_idx); } else { if (stack_idx == 0) { BUG_MSG("unexpected closing tag: .\n", Tags[new_idx].name); From corvid at lavabit.com Sun Oct 25 00:10:31 2009 From: corvid at lavabit.com (corvid) Date: Sun Oct 25 00:14:31 2009 Subject: [Dillo-dev] Re: link signal emission from layout? In-Reply-To: <20091024174205.GA2176@dillo.org> References: <20091024154855.GB547@local.gobigwest.com> <20091024174205.GA2176@dillo.org> Message-ID: <20091024221031.GC547@local.gobigwest.com> Jorge wrote: > On Sat, Oct 24, 2009 at 03:48:55PM +0000, corvid wrote: > > I never liked all of the connectSignals() for all of the > > textblocks and images and whatever else in html.cc. > > Why not? So much signal connection for the listitems and the tablecells and everything, and all redundant, since it's all going back to the same receiver in html. > > Would you have any opinion about moving the > > (perhaps increasingly-inaccurately-named) > > link signal emission to layout? > > Could be. > > > I was just playing with the idea, and, at least after > > a moment's test :) , it seemed to be working. > > And, as a bonus, it lets me pop up menus when > > pressing button 3 below the bottom of page content. > > I miss this feature. Also being able to popup a menu over > a bare image would be a plus. Random thought: it would nice if there were a mechanism to change the size of images. > > (I left the event emitter alone for the moment, but I > > think the only thing using it right now is plain.cc. > > If so, it would be nice to rip that out in any case, > > even if plain doesn't have "links" exactly...) > > I don't know why it's currently done in html.cc, maybe it's > just grouping by required functionality, maybe not. If the new > approach is simpler and provides the same and more as you > pointed, id say: +1. It's simpler for src/, but the ickiness is preserved for dw/, since what was excised from Widget gets implanted into Layout. > BTW, please move this thread to dillo-dev. From jcid at dillo.org Tue Oct 27 22:14:16 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Oct 27 22:14:52 2009 Subject: [Dillo-dev] Re: NULL for default tag close? In-Reply-To: <20091027170937.GA10349@local.gobigwest.com> References: <20091027170937.GA10349@local.gobigwest.com> Message-ID: <20091027211416.GA12541@dillo.org> On Tue, Oct 27, 2009 at 05:09:37PM +0000, corvid wrote: > Would it be all right if I changed the default_close()s to NULL? > I think it makes Tags[] easier to read, I'd prefer it as is for the same reason! :-) > and testing for NULL would > mean less time calling an empty function anyway... I'd be surprised if the gain is more than 0.1%. BTW, today in one part of the DPIP code I found that avoiding thousands of read() calls made no noticeable difference. With write() it was a different story though. Most probably gcc optimizes out empty functions too. -- Cheers Jorge.- From jcid at dillo.org Wed Oct 28 19:07:40 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Oct 28 19:08:15 2009 Subject: [Dillo-dev] Latest whitespace handling patches Message-ID: <20091028180740.GA2248@dillo.org> Hi, The latest cleanups and whitespace handling patches have come like a fresh breeze removing unnecessary code. They're good for better code clarity. One of the few regressions I've noticed is extra underlining of links (the space before the first word's letter). As in: http://www.dwheeler.com/blog/2009/10/27/#dod-oss-2009 BTW, I'm close to commiting the DPIP changes. Hopefully near this month's end. -- Cheers Jorge.- From corvid at lavabit.com Wed Oct 28 19:31:56 2009 From: corvid at lavabit.com (corvid) Date: Wed Oct 28 19:36:03 2009 Subject: [Dillo-dev] Latest whitespace handling patches In-Reply-To: <20091028180740.GA2248@dillo.org> References: <20091028180740.GA2248@dillo.org> Message-ID: <20091028183156.GC10349@local.gobigwest.com> Jorge wrote: > One of the few regressions I've noticed is extra underlining of > links (the space before the first word's letter). As in: > > http://www.dwheeler.com/blog/2009/10/27/#dod-oss-2009 More like a...shifting of the unpleasantness. We had lots of cases of " word word" that underlined the space following the link. Now we have some "word word" that underline the space preceding the link. I could look at the possible spaces and select the one with the least-decorated style, perhaps. From jcid at dillo.org Wed Oct 28 21:19:29 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Oct 28 21:20:05 2009 Subject: [Dillo-dev] Latest whitespace handling patches In-Reply-To: <20091028183156.GC10349@local.gobigwest.com> References: <20091028180740.GA2248@dillo.org> <20091028183156.GC10349@local.gobigwest.com> Message-ID: <20091028201929.GB2248@dillo.org> On Wed, Oct 28, 2009 at 06:31:56PM +0000, corvid wrote: > Jorge wrote: > > One of the few regressions I've noticed is extra underlining of > > links (the space before the first word's letter). As in: > > > > http://www.dwheeler.com/blog/2009/10/27/#dod-oss-2009 > > More like a...shifting of the unpleasantness. > > We had lots of cases of " word word" > that underlined the space following the link. > Now we have some "word word" > that underline the space preceding the link. I remember thinkering on this bug several times. That's why I'm happy this is getting a cleanup! > I could look at the possible spaces and select the one with > the least-decorated style, perhaps. Now that you have this part of the code in your short-term memory cells ;), please try to make a good link-underline test page. If you can come up with a 100% solution it'd be great. -- Cheers Jorge.- From corvid at lavabit.com Wed Oct 28 23:18:25 2009 From: corvid at lavabit.com (corvid) Date: Wed Oct 28 23:22:25 2009 Subject: [Dillo-dev] Latest whitespace handling patches In-Reply-To: <20091028201929.GB2248@dillo.org> References: <20091028180740.GA2248@dillo.org> <20091028183156.GC10349@local.gobigwest.com> <20091028201929.GB2248@dillo.org> Message-ID: <20091028221825.GD10349@local.gobigwest.com> Jorge wrote: > On Wed, Oct 28, 2009 at 06:31:56PM +0000, corvid wrote: > > I could look at the possible spaces and select the one with > > the least-decorated style, perhaps. > > Now that you have this part of the code in your short-term > memory cells ;), please try to make a good link-underline test > page. If you can come up with a 100% solution it'd be great. I think it'll be a matter of what we want to define the solution as, for instance, whether there is a clear enough choice for word word. If I put a space inside the A, I might want it, and I might not. I'm probably more likely to want it if it's a matter of U, S, or overline, and less likely to want it if it's from an A, but maybe that's too detailed and picky. From jcid at dillo.org Thu Oct 29 14:19:38 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Oct 29 14:20:12 2009 Subject: [Dillo-dev] Latest whitespace handling patches In-Reply-To: <20091028221825.GD10349@local.gobigwest.com> References: <20091028180740.GA2248@dillo.org> <20091028183156.GC10349@local.gobigwest.com> <20091028201929.GB2248@dillo.org> <20091028221825.GD10349@local.gobigwest.com> Message-ID: <20091029131937.GA3849@dillo.org> On Wed, Oct 28, 2009 at 10:18:25PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Oct 28, 2009 at 06:31:56PM +0000, corvid wrote: > > > I could look at the possible spaces and select the one with > > > the least-decorated style, perhaps. > > > > Now that you have this part of the code in your short-term > > memory cells ;), please try to make a good link-underline test > > page. If you can come up with a 100% solution it'd be great. > > I think it'll be a matter of what we want to define the solution as, > for instance, whether there is a clear enough choice for > word word. > If I put a space inside the A, I might want it, and I might not. > I'm probably more likely to want it if it's a matter of > U, S, or overline, and less likely to want it if it's from an A, > but maybe that's too detailed and picky. In this case, the easy solution is to look what Firefox does. For instance try the attached test page. -- Cheers Jorge.- -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20091029/e5761275/space.html From corvid at lavabit.com Thu Oct 29 16:20:10 2009 From: corvid at lavabit.com (corvid) Date: Thu Oct 29 16:24:13 2009 Subject: [Dillo-dev] Latest whitespace handling patches In-Reply-To: <20091029131937.GA3849@dillo.org> References: <20091028180740.GA2248@dillo.org> <20091028183156.GC10349@local.gobigwest.com> <20091028201929.GB2248@dillo.org> <20091028221825.GD10349@local.gobigwest.com> <20091029131937.GA3849@dillo.org> Message-ID: <20091029152010.GA15174@local.gobigwest.com> Jorge wrote: > On Wed, Oct 28, 2009 at 10:18:25PM +0000, corvid wrote: > > Jorge wrote: > > > On Wed, Oct 28, 2009 at 06:31:56PM +0000, corvid wrote: > > > > I could look at the possible spaces and select the one with > > > > the least-decorated style, perhaps. > > > > > > Now that you have this part of the code in your short-term > > > memory cells ;), please try to make a good link-underline test > > > page. If you can come up with a 100% solution it'd be great. > > > > I think it'll be a matter of what we want to define the solution as, > > for instance, whether there is a clear enough choice for > > word word. > > If I put a space inside the A, I might want it, and I might not. > > I'm probably more likely to want it if it's a matter of > > U, S, or overline, and less likely to want it if it's from an A, > > but maybe that's too detailed and picky. > > In this case, the easy solution is to look what Firefox does. > For instance try the attached test page. Firefox seems to follow the original behaviour consistently :( I'm shocked by this because ff surely does whatever ms does, and so people must actually see all of those underlined spaces. It seems to me that if they saw them, they'd take them out. So I'll undo it.