- Dillo-dev - lists.mailman3.com

Dillo needs scripting

by onepoint＠starurchin.org

On Tue, Nov 30, 2010 at 12:21:05PM -0300, Jorge Arellano Cid wrote: > For a few years I've entertained the idea of having lua scripting > in dillo. Not only dpi, but also inside. Looks like dpi > filters/servers are a good start. I think Lua is a good match for Dillo - it's designed to be statically embedded and like Dillo it puts a very high premium on being small and fast. My original motivation was thinking of all the work it take to write eg. a proper fully-featured HTTPS dpi and thinking "it would be *so* much easier to do this in a scripting language instead of C/C++". Regards, Jeremy Henty

Nov. 30, 2010

Dillo needs scripting

by jcid＠dillo.org

On Fri, Nov 26, 2010 at 05:05:26PM +0000, Jeremy Henty wrote: > > I thought it would be fun if I could write a DPI filter as easily as > this: > > #!/usr/lib/dillo/bin/lua-dpi > -- -*- lua -*- > > dpi [[ > Content-type: text/html > > <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'> > <html> > <head><title>Hello World - Lua DPI</title></head> > <body> > From inside a Dillo DPI, Lua says "Hello World!". > </body> > </html> > ]] > > Well, now I can! > > http://starurchin.org/dillo/dillo_lua_dpi.png > > It's still just a toy at the moment, but I'm pleased with it. Nice! For a few years I've entertained the idea of having lua scripting in dillo. Not only dpi, but also inside. Looks like dpi filters/servers are a good start. -- Cheers Jorge.-

Nov. 30, 2010

[patch]: fix .hgignore

by jcid＠dillo.org

On Sat, Nov 27, 2010 at 09:25:38PM +0100, Johannes Hofmann wrote: > On Sat, Nov 27, 2010 at 05:01:57PM +0000, corvid wrote: > > Jeremy wrote: > > > On Sat, Nov 27, 2010 at 03:28:36PM +0000, corvid wrote: > > > > Back in July, Jeremy wrote: > > > > > corvid wrote: > > > > > > Jeremy wrote: > > > > > > > The problem was that .hgignore contains a line "dillo", which > > > > > > > ignores every file with the string "dillo" anywhere in its > > > > > > > path. Many other lines in .hgignore are similarly > > > > > > > inappropriate. It looks as though these lines were written to > > > > > > > be interpreted as glob-style patterns, but in fact mercurial > > > > > > > interprets every line as a regexp. > > > > > > > > > > > > Looking in http://www.selenic.com/mercurial/hgignore.5.html it > > > > > > seems that specifying "syntax: glob" is also a possibility. > > > > > > > > > > Yes, glob syntax might well be better, but either way the current > > > > > .hgignore is not working as it should and could do with fixing. > > > > > > > > Just noticed this thread while cleaning out old mail, and we should > > > > come to some kind of decision on this. > > > > > > Heh, I was *just* about to bump this discussion by resubmitting my > > > patch! Is there any reason not to push this? Unless people would > > > prefer glob syntax? > > > > My opinion is: Either syntax, as long as it's fixed... > > Also my opinion. +1 -- Cheers Jorge.-

Nov. 29, 2010

OT: freehg.org gone?

by onepoint＠starurchin.org

Not that it affects us, but did anyone notice that freehg.org has gone? I can't Google anything useful, does anyone know more? Regards, Jeremy Henty

Nov. 29, 2010

[patch]: fix the obsolete usage of AC_OUTPUT

by onepoint＠starurchin.org

While implementing the Lua DPI I saw that configure.in uses AC_OUTPUT in an obsolete way. This patch changes it to use the modern calling convention. (It also puts each of the generated files on a separate line, which makes it much easier to read patches that modify that list.) Regards, Jeremy Henty

Nov. 28, 2010

[patch]: fix .hgignore

by onepoint＠starurchin.org

On Sat, Nov 27, 2010 at 09:25:38PM +0100, Johannes Hofmann wrote: > On Sat, Nov 27, 2010 at 05:01:57PM +0000, corvid wrote: > > Jeremy wrote: > > > On Sat, Nov 27, 2010 at 03:28:36PM +0000, corvid wrote: > > > > Back in July, Jeremy wrote: > > > > > corvid wrote: > > > > > > Jeremy wrote: > > > > > > > The problem was that .hgignore contains a line "dillo", which > > > > > > > ignores every file with the string "dillo" anywhere in its > > > > > > > path. Many other lines in .hgignore are similarly > > > > > > > inappropriate. It looks as though these lines were written to > > > > > > > be interpreted as glob-style patterns, but in fact mercurial > > > > > > > interprets every line as a regexp. > > > > > > > > > > > > Looking in http://www.selenic.com/mercurial/hgignore.5.html it > > > > > > seems that specifying "syntax: glob" is also a possibility. > > > > > > > > > > Yes, glob syntax might well be better, but either way the current > > > > > .hgignore is not working as it should and could do with fixing. > > > > > > > > Just noticed this thread while cleaning out old mail, and we should > > > > come to some kind of decision on this. > > > > > > Heh, I was *just* about to bump this discussion by resubmitting my > > > patch! Is there any reason not to push this? Unless people would > > > prefer glob syntax? > > > > My opinion is: Either syntax, as long as it's fixed... > > Also my opinion. OK, I plan to sit on this for a few more days and then push it if there have been no objections. Regards, Jeremy Henty

Nov. 28, 2010

Dillo needs scripting

by onepoint＠starurchin.org

On Sat, Nov 27, 2010 at 09:28:21PM +0100, Johannes Hofmann wrote: > What's that lua-dpi? It's a small C program that embeds the Lua interpreter and extends its state with a global function called "dpi". I implemented "dpi" by modifying the main() function of the hello DPI filter in the Dillo source. Once lua-dpi has set up the Lua state it takes its first argument as the name of a Lua script which it loads and runs. > Can we have a look at it? It's a patch to the Dillo source. I'm attaching it. I have made it minimally intrusive: the code is in a new directory called dpi/lua and the only changes to existing files are one-liner changes to dpi/Makefile.am (to make the build recurse into the lua subdirectory) and configure.in (to create dpi/lua/Makefile). NB: I have renamed the dpi to "lua" instead of "starurchin", so the URL is now "dpi:/lua/". Also, if you install Dillo to a prefix other than "/usr" you will have to change the #! line of lua.filter.dpi to match (that's a bug that I will fix if this project gets serious). The current API is much too simple to do anything non-trivial. I think the final version will look more like this: dpi(function (request) url = request.url; html = ...; request:reply(html); end); Regards, Jeremy Henty

Nov. 28, 2010

Dillo needs scripting

by Johannes.Hofmann＠gmx.de

On Fri, Nov 26, 2010 at 05:05:26PM +0000, Jeremy Henty wrote: > > I thought it would be fun if I could write a DPI filter as easily as > this: > > #!/usr/lib/dillo/bin/lua-dpi > -- -*- lua -*- > > dpi [[ > Content-type: text/html > > <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'> > <html> > <head><title>Hello World - Lua DPI</title></head> > <body> > From inside a Dillo DPI, Lua says "Hello World!". > </body> > </html> > ]] > > Well, now I can! > > http://starurchin.org/dillo/dillo_lua_dpi.png > > It's still just a toy at the moment, but I'm pleased with it. Hey nice! What's that lua-dpi? Is it a lua script? Can we have a look at it? Cheers, Johannes

Nov. 27, 2010

[patch]: fix .hgignore

by Johannes.Hofmann＠gmx.de

On Sat, Nov 27, 2010 at 05:01:57PM +0000, corvid wrote: > Jeremy wrote: > > On Sat, Nov 27, 2010 at 03:28:36PM +0000, corvid wrote: > > > Back in July, Jeremy wrote: > > > > corvid wrote: > > > > > Jeremy wrote: > > > > > > The problem was that .hgignore contains a line "dillo", which > > > > > > ignores every file with the string "dillo" anywhere in its > > > > > > path. Many other lines in .hgignore are similarly > > > > > > inappropriate. It looks as though these lines were written to > > > > > > be interpreted as glob-style patterns, but in fact mercurial > > > > > > interprets every line as a regexp. > > > > > > > > > > Looking in http://www.selenic.com/mercurial/hgignore.5.html it > > > > > seems that specifying "syntax: glob" is also a possibility. > > > > > > > > Yes, glob syntax might well be better, but either way the current > > > > .hgignore is not working as it should and could do with fixing. > > > > > > Just noticed this thread while cleaning out old mail, and we should > > > come to some kind of decision on this. > > > > Heh, I was *just* about to bump this discussion by resubmitting my > > patch! Is there any reason not to push this? Unless people would > > prefer glob syntax? > > My opinion is: Either syntax, as long as it's fixed... Also my opinion. Cheers, Johannes

Nov. 27, 2010

[patch]: fix .hgignore

by corvid＠lavabit.com

Jeremy wrote: > On Sat, Nov 27, 2010 at 03:28:36PM +0000, corvid wrote: > > Back in July, Jeremy wrote: > > > corvid wrote: > > > > Jeremy wrote: > > > > > The problem was that .hgignore contains a line "dillo", which > > > > > ignores every file with the string "dillo" anywhere in its > > > > > path. Many other lines in .hgignore are similarly > > > > > inappropriate. It looks as though these lines were written to > > > > > be interpreted as glob-style patterns, but in fact mercurial > > > > > interprets every line as a regexp. > > > > > > > > Looking in http://www.selenic.com/mercurial/hgignore.5.html it > > > > seems that specifying "syntax: glob" is also a possibility. > > > > > > Yes, glob syntax might well be better, but either way the current > > > .hgignore is not working as it should and could do with fixing. > > > > Just noticed this thread while cleaning out old mail, and we should > > come to some kind of decision on this. > > Heh, I was *just* about to bump this discussion by resubmitting my > patch! Is there any reason not to push this? Unless people would > prefer glob syntax? My opinion is: Either syntax, as long as it's fixed...

Nov. 27, 2010

[patch]: fix .hgignore

by onepoint＠starurchin.org

On Sat, Nov 27, 2010 at 03:28:36PM +0000, corvid wrote: > Back in July, Jeremy wrote: > > corvid wrote: > > > Jeremy wrote: > > > > The problem was that .hgignore contains a line "dillo", which > > > > ignores every file with the string "dillo" anywhere in its > > > > path. Many other lines in .hgignore are similarly > > > > inappropriate. It looks as though these lines were written to > > > > be interpreted as glob-style patterns, but in fact mercurial > > > > interprets every line as a regexp. > > > > > > Looking in http://www.selenic.com/mercurial/hgignore.5.html it > > > seems that specifying "syntax: glob" is also a possibility. > > > > Yes, glob syntax might well be better, but either way the current > > .hgignore is not working as it should and could do with fixing. > > Just noticed this thread while cleaning out old mail, and we should > come to some kind of decision on this. Heh, I was *just* about to bump this discussion by resubmitting my patch! Is there any reason not to push this? Unless people would prefer glob syntax? Regards, Jeremy Henty

Nov. 27, 2010

[patch]: fix .hgignore

by corvid＠lavabit.com

Back in July, Jeremy wrote: > corvid wrote: > > Jeremy wrote: > > > The problem was that .hgignore contains a line "dillo", which > > > ignores every file with the string "dillo" anywhere in its path. > > > Many other lines in .hgignore are similarly inappropriate. It > > > looks as though these lines were written to be interpreted as > > > glob-style patterns, but in fact mercurial interprets every line > > > as a regexp. > > > > Looking in http://www.selenic.com/mercurial/hgignore.5.html it seems > > that specifying "syntax: glob" is also a possibility. > > Yes, glob syntax might well be better, but either way the current > .hgignore is not working as it should and could do with fixing. Just noticed this thread while cleaning out old mail, and we should come to some kind of decision on this.

Nov. 27, 2010

Dillo needs scripting

by onepoint＠starurchin.org

I thought it would be fun if I could write a DPI filter as easily as this: #!/usr/lib/dillo/bin/lua-dpi -- -*- lua -*- dpi [[ Content-type: text/html <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'> <html> <head><title>Hello World - Lua DPI</title></head> <body> From inside a Dillo DPI, Lua says "Hello World!". </body> </html> ]] Well, now I can! http://starurchin.org/dillo/dillo_lua_dpi.png It's still just a toy at the moment, but I'm pleased with it. Regards, Jeremy Henty

Nov. 26, 2010

[patch]: @media support

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > + dStrcasecmp(tval, "media") == 0) > > Should that be "screen"? <headdesk/> :-) . Good call! Updated patch attached. Regards, Jeremy Henty

Nov. 22, 2010

[patch]: @media support

by corvid＠lavabit.com

Jeremy wrote: > + dStrcasecmp(tval, "media") == 0) Should that be "screen"?

Nov. 22, 2010

[patch]: @media support

by Johannes.Hofmann＠gmx.de

On Mon, Nov 22, 2010 at 08:29:03PM +0000, Jeremy Henty wrote: > > Does what it says on the tin. Please review and comment. I'm going > to road-test this at home for a few days before pushing it. Naturally > I won't push it if people have objections or corrections. But it does > fix this site[1]! Heh, nice! After your last patch I was already tempted to ask whether you wanted to look into this :-) Feel free to commit when you think it's ready. Cheers, Johannes

Nov. 22, 2010

[patch]: @media support

by onepoint＠starurchin.org

Does what it says on the tin. Please review and comment. I'm going to road-test this at home for a few days before pushing it. Naturally I won't push it if people have objections or corrections. But it does fix this site[1]! Regards, Jeremy Henty [1]: http://www.psychologicalscience.org/onlyhuman/2009/01/paradox-of-temptation…

Nov. 22, 2010

[patch]: ignore unknown @-rules in CSS

by onepoint＠starurchin.org

On Sun, Nov 21, 2010 at 08:52:58PM +0100, Johannes Hofmann wrote: > On Sat, Nov 20, 2010 at 12:31:55PM +0000, Jeremy Henty wrote: > > > > So, here are two patches that make Dillo ignore @-rules that it > > does not recognise. > > Looks good to me. Please commit! Done! Regards, Jeremy Henty

Nov. 21, 2010

[patch]: ignore unknown @-rules in CSS

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Sat, Nov 20, 2010 at 12:31:55PM +0000, Jeremy Henty wrote: > > Currently Dillo tries to parse every @-rule in the same way (with > CssParser::parseImport()). This causes problems, particularly with > @media. Here[1] part of the style is missing so that the line size is > smaller than the text. I have also attached a small test case where a > @media rule causes the red style to go missing. > > So, here are two patches that make Dillo ignore @-rules that it does > not recognise. The first patch just moves the test for the import > keyword from CssParser::parseImport() into the main parser loop. > Because it changes indentation it looks much more radical than it is. > The second patch reworks the main parser loop so that > CssParser::parseImport() is only called for @import and other @-rules > are skipped. > > Please review and comment. I will push the patches if you think they > are good. Looks good to me. Please commit! Thanks, Johannes

Nov. 21, 2010

[patch]: ignore unknown @-rules in CSS

by onepoint＠starurchin.org

Currently Dillo tries to parse every @-rule in the same way (with CssParser::parseImport()). This causes problems, particularly with @media. Here[1] part of the style is missing so that the line size is smaller than the text. I have also attached a small test case where a @media rule causes the red style to go missing. So, here are two patches that make Dillo ignore @-rules that it does not recognise. The first patch just moves the test for the import keyword from CssParser::parseImport() into the main parser loop. Because it changes indentation it looks much more radical than it is. The second patch reworks the main parser loop so that CssParser::parseImport() is only called for @import and other @-rules are skipped. Please review and comment. I will push the patches if you think they are good. Regards, Jeremy Henty [1]http://johannhari.com//2010/11/19/we-should-not-tolerate-religious-excuse…

Nov. 20, 2010

patch: text-indent

by Johannes.Hofmann＠gmx.de

On Fri, Nov 19, 2010 at 06:15:45PM +0000, corvid wrote: > I wrote: > > However, with > > <div style="text-indent: 1em; border: 1px solid"> > > <table border=1> > > <tr><td>I'm<td>a<td>table > > </table> > > text > > </div> > > firefox doesn't indent the text in the cells, and I don't know why > > not. The property inherits. Guess I have some deeper spec reading > > in my immediate future. > > Ah, http://davidwalsh.name/firefox-internal-rendering-css > shows > table { > .. > text-indent: 0; > } Yeah tables seem to reset some CSS values traditionally. There is already a related comment in css.cc with the following link: http://developer.mozilla.org/En/Fixing_Table_Inheritance_in_Quirks_Mode Cheers, Johannes

Nov. 19, 2010

patch: text-indent

by corvid＠lavabit.com

I wrote: > However, with > <div style="text-indent: 1em; border: 1px solid"> > <table border=1> > <tr><td>I'm<td>a<td>table > </table> > text > </div> > firefox doesn't indent the text in the cells, and I don't know why > not. The property inherits. Guess I have some deeper spec reading > in my immediate future. Ah, http://davidwalsh.name/firefox-internal-rendering-css shows table { .. text-indent: 0; }

Nov. 19, 2010

patch: text-indent

by corvid＠lavabit.com

Committed a change. I see that tables still don't work properly with it. <table border=1 style="text-indent: 1em"> <tr><td>I'm<td>a<td>table </table> doesn't make the cells big enough, but that's simply because I haven't looked into it yet. However, with <div style="text-indent: 1em; border: 1px solid"> <table border=1> <tr><td>I'm<td>a<td>table </table> text </div> firefox doesn't indent the text in the cells, and I don't know why not. The property inherits. Guess I have some deeper spec reading in my immediate future.

Nov. 19, 2010

fatal error while compiling fltk

by lolveley＠yahoo.fr

fine! I compiled fltk without the text "glut" near DIRS, and then dillo, all this without errors. and now I have HTML support in claws-mail. thanks! olivier Le Thu, 18 Nov 2010 19:25:48 +0000, James Lovejoy <jameslovejoy(a)tiscali.co.uk> a ?crit : > Right, well it seems to me it's just building tests. So open > "Makefile" and delete the word "glut" from the DIRS variable. I > haven't tested it but it should work. > > On 18 Nov 2010, at 19:05, olivier SAINT-EVE <lolveley(a)yahoo.fr> wrote: > > > Hello, > > > > here is the result of the compilation of fltk: > > ******************************************************************** > > lolveley@linux-f5pi:~/bin/claws/fltk-2.0.x-r7725> make > > === making src === > > === making images/libjpeg === > > === making images/libpng === > > === making images === > > === making OpenGL === > > === making fluid === > > === making glut === > > Linking glpuzzle... > > glpuzzle.o: In function `redraw()': > > glpuzzle.cxx:(.text+0xbe7): undefined reference to `gluPerspective' > > glpuzzle.o: In function `selectPiece(int, int)': > > glpuzzle.cxx:(.text+0x12a6): undefined reference to `gluPickMatrix' > > glpuzzle.cxx:(.text+0x12da): undefined reference to `gluPerspective' > > collect2: ld returned 1 exit status > > make[1]: *** [glpuzzle] Erreur 1 > > make: *** [all] Erreur 2 > > ******************************************************************* > > I tried to compile glut and I have an error too. > > can give you this if you want. > > > > olivier > > > > Le 18/11/2010 19:56, James Lovejoy a ?crit : > >> Hi, > >> > >> Could you post the error because I think I got this error when > >> compiling fltk but I can't remember how I fixed it. Maybe it will > >> jog my memory. > >> > >> James > >> > >> On 18 Nov 2010, at 16:45, olivier SAINT-EVE <lolveley(a)yahoo.fr> > >> wrote: > >> > >> > >>> well, I tried to install mesa, but it is already installed, and > >>> the compilation with "--disable-gl" fails with an error while > >>> compiling glut. > >>> > >>> seems I will have HTML support in a long time, if so! > >>> > >>> olivier > >>> > >>> Le Thu, 18 Nov 2010 11:21:20 -0300, > >>> Jorge Arellano Cid <jcid(a)dillo.org> a ?crit : > >>> > >>> > >>>> On Thu, Nov 18, 2010 at 12:32:49PM +0100, Joerg Sonnenberger > >>>> wrote: > >>>> > >>>>> On Thu, Nov 18, 2010 at 12:16:40PM +0100, olivier SAINT-EVE > >>>>> wrote: > >>>>> > >>>>>> sounds like GLU is missing, but an internet search didn't help > >>>>>> me to find libglu-mesa, or libglu, or glu, in a rpm format. > >>>>>> > >>>>> Try Mesa. > >>>>> > >>>> You can install mesa GL, or you may try: > >>>> > >>>> ./configure --disable-gl ... > >>>> > >>>> when compiling FLTK. > >>>> > >>>> Disclaimer: I haven't tried it, but assume it should work. > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Dillo-dev mailing list > >>> Dillo-dev(a)dillo.org > >>> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > >>> > >> > >

Nov. 18, 2010

patch: text-indent

by Johannes.Hofmann＠gmx.de

On Thu, Nov 18, 2010 at 06:44:57PM +0000, corvid wrote: > Johannes wrote: > > -----Urspr?ngliche Nachricht----- > > An: dillo-dev(a)dillo.org; > > Von: corvid <corvid(a)lavabit.com> > > Gesendet: Do 11.11.2010 02:43 > > Betreff: Re: [Dillo-dev] patch: text-indent > > > Johannes wrote: > > > > We probabely want some isBlockLevelWidget() function... > > > > > > Using Widget::Flags, perhaps, or would you think it best generally > > > to save the flags for state that changes during a widget's life? > > > > > > > I was just thinking about something simple like > > > > bool isBlockLevelWidget(Widget *w) { > > return widget->instanceOf (Textblock::CLASS_ID) || widget->instanceOf (Table::CLASS_ID) ... ); > > } > > > > in textblock.cc to explain to the code reader why we are testing > > for exactly these widget types. > > Plus we might have to reuse at some point. > > Textblock doesn't know what Table and Ruler are, though. Hm, I see. In that case your proposal of using the widget flags sounds just fine to me. Cheers, Johannes

Nov. 18, 2010

fatal error while compiling fltk

by lolveley＠yahoo.fr

Le 18/11/2010 20:05, olivier SAINT-EVE a ?crit : > Hello, > > here is the result of the compilation of fltk: > ******************************************************************** > lolveley@linux-f5pi:~/bin/claws/fltk-2.0.x-r7725> make > === making src === > === making images/libjpeg === > === making images/libpng === > === making images === > === making OpenGL === > === making fluid === > === making glut === > Linking glpuzzle... > glpuzzle.o: In function `redraw()': > glpuzzle.cxx:(.text+0xbe7): undefined reference to `gluPerspective' > glpuzzle.o: In function `selectPiece(int, int)': > glpuzzle.cxx:(.text+0x12a6): undefined reference to `gluPickMatrix' > glpuzzle.cxx:(.text+0x12da): undefined reference to `gluPerspective' > collect2: ld returned 1 exit status > make[1]: *** [glpuzzle] Erreur 1 > make: *** [all] Erreur 2 > ******************************************************************* > I tried to compile glut and I have an error too. > can give you this if you want. > > olivier > > Le 18/11/2010 19:56, James Lovejoy a ?crit : > >> Hi, >> >> Could you post the error because I think I got this error when compiling fltk but I can't remember how I fixed it. Maybe it will jog my memory. >> >> James >> >> On 18 Nov 2010, at 16:45, olivier SAINT-EVE <lolveley(a)yahoo.fr> wrote: >> >> >> >>> well, I tried to install mesa, but it is already installed, and the >>> compilation with "--disable-gl" fails with an error while compiling >>> glut. >>> >>> seems I will have HTML support in a long time, if so! >>> >>> olivier >>> >>> Le Thu, 18 Nov 2010 11:21:20 -0300, >>> Jorge Arellano Cid <jcid(a)dillo.org> a ?crit : >>> >>> >>> >>>> On Thu, Nov 18, 2010 at 12:32:49PM +0100, Joerg Sonnenberger wrote: >>>> >>>> >>>>> On Thu, Nov 18, 2010 at 12:16:40PM +0100, olivier SAINT-EVE wrote: >>>>> >>>>> >>>>>> sounds like GLU is missing, but an internet search didn't help me >>>>>> to find libglu-mesa, or libglu, or glu, in a rpm format. >>>>>> >>>>>> >>>>> Try Mesa. >>>>> >>>>> >>>> You can install mesa GL, or you may try: >>>> >>>> ./configure --disable-gl ... >>>> >>>> when compiling FLTK. >>>> >>>> Disclaimer: I haven't tried it, but assume it should work. >>>> >>>> >>>> >>> _______________________________________________ >>> Dillo-dev mailing list >>> Dillo-dev(a)dillo.org >>> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >>> >>> >> >> >

Nov. 18, 2010

fatal error while compiling fltk

by jcid＠dillo.org

On Thu, Nov 18, 2010 at 05:45:33PM +0100, olivier SAINT-EVE wrote: > well, I tried to install mesa, but it is already installed, and the > compilation with "--disable-gl" fails with an error while compiling > glut. > > seems I will have HTML support in a long time, if so! FWIW, in Ubuntu, I have: i A libgl1-mesa-dev - A free implementation of the OpenGL API -- i A libgl1-mesa-dri - A free implementation of the OpenGL API -- i A libgl1-mesa-glx - A free implementation of the OpenGL API -- i A libglu1-mesa - The OpenGL utility library (GLU) i libglu1-mesa-dev - The OpenGL utility library -- development i A mesa-common-dev - Developer documentation for Mesa -- Cheers Jorge.-

Nov. 18, 2010

patch: text-indent

by corvid＠lavabit.com

Johannes wrote: > -----Urspr?ngliche Nachricht----- > An: dillo-dev(a)dillo.org; > Von: corvid <corvid(a)lavabit.com> > Gesendet: Do 11.11.2010 02:43 > Betreff: Re: [Dillo-dev] patch: text-indent > > Johannes wrote: > > > We probabely want some isBlockLevelWidget() function... > > > > Using Widget::Flags, perhaps, or would you think it best generally > > to save the flags for state that changes during a widget's life? > > > > I was just thinking about something simple like > > bool isBlockLevelWidget(Widget *w) { > return widget->instanceOf (Textblock::CLASS_ID) || widget->instanceOf (Table::CLASS_ID) ... ); > } > > in textblock.cc to explain to the code reader why we are testing > for exactly these widget types. > Plus we might have to reuse at some point. Textblock doesn't know what Table and Ruler are, though.

Nov. 18, 2010

fatal error while compiling fltk

by lolveley＠yahoo.fr

well, I tried to install mesa, but it is already installed, and the compilation with "--disable-gl" fails with an error while compiling glut. seems I will have HTML support in a long time, if so! olivier Le Thu, 18 Nov 2010 11:21:20 -0300, Jorge Arellano Cid <jcid(a)dillo.org> a ?crit : > On Thu, Nov 18, 2010 at 12:32:49PM +0100, Joerg Sonnenberger wrote: > > On Thu, Nov 18, 2010 at 12:16:40PM +0100, olivier SAINT-EVE wrote: > > > sounds like GLU is missing, but an internet search didn't help me > > > to find libglu-mesa, or libglu, or glu, in a rpm format. > > > > Try Mesa. > > You can install mesa GL, or you may try: > > ./configure --disable-gl ... > > when compiling FLTK. > > Disclaimer: I haven't tried it, but assume it should work. >

Nov. 18, 2010

fatal error while compiling fltk

by jcid＠dillo.org

On Thu, Nov 18, 2010 at 12:32:49PM +0100, Joerg Sonnenberger wrote: > On Thu, Nov 18, 2010 at 12:16:40PM +0100, olivier SAINT-EVE wrote: > > sounds like GLU is missing, but an internet search didn't help me to > > find libglu-mesa, or libglu, or glu, in a rpm format. > > Try Mesa. You can install mesa GL, or you may try: ./configure --disable-gl ... when compiling FLTK. Disclaimer: I haven't tried it, but assume it should work. -- Cheers Jorge.-

Nov. 18, 2010

fatal error while compiling fltk

by joerg.sonnenberger＠web.de

On Thu, Nov 18, 2010 at 12:16:40PM +0100, olivier SAINT-EVE wrote: > sounds like GLU is missing, but an internet search didn't help me to > find libglu-mesa, or libglu, or glu, in a rpm format. Try Mesa. Joerg

Nov. 18, 2010

fatal error while compiling fltk

by lolveley＠yahoo.fr

hello, thank you for your answer. I installed the package and now I have this error: ************************************************************* === making src === === making images/libjpeg === === making images/libpng === === making images === === making OpenGL === === making fluid === === making glut === Linking glpuzzle... glpuzzle.o: In function `redraw()': glpuzzle.cxx:(.text+0xbe7): undefined reference to `gluPerspective' glpuzzle.o: In function `selectPiece(int, int)': glpuzzle.cxx:(.text+0x12a6): undefined reference to `gluPickMatrix' glpuzzle.cxx:(.text+0x12da): undefined reference to `gluPerspective' collect2: ld returned 1 exit status make[1]: *** [glpuzzle] Erreur 1 make: *** [all] Erreur 2 ************************************************************ sounds like GLU is missing, but an internet search didn't help me to find libglu-mesa, or libglu, or glu, in a rpm format. can you help me a new time? olivier. Le Wed, 17 Nov 2010 21:07:18 -0500, "Benjamin Johnson" <obeythepenguin(a)gmail.com> a ?crit : > It sounds like you're missing your X11 development packages. Google > tells me you want xorg-x11-devel, but I'm not an opensuse user myself. > > Cheers, > ~Benjamin > > On Wed, 17 Nov 2010 19:59:55 -0500, olivier SAINT-EVE > <lolveley(a)yahoo.fr> wrote: > > > hello, > > > > I have opensuse 11.3 with gnome, and claws-mail. > > in order to view html content on claws-mail, I had to compile dillo. > > so I went to the site, downloaded fltk and tried to compile it > > (fltk-2.0.x-r7725). > > > > but after entering "make", I had this error : > > > > ******************************************************************** > > === making src === > > Compiling addarc.cxx... > > In file included from ../fltk/x.h:38:0, > > from addarc.cxx:32: > > ../fltk/x11.h:65:38: fatal error: X11/extensions/XInput.h: Aucun > > fichier ou dossier de ce type compilation terminated. > > make[1]: *** [addarc.o] Erreur 1 > > make: *** [all] Erreur 2 > > ******************************************************************** > > > > can you tell me if a peculiar software is missing? > > I searched with google (X11,RPMs of dillo) but in vain. > > > > thanks, > > > > Olivier. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 18, 2010

Dillo-Win32 patches - yet another update

by obeythepenguin＠gmail.com

After noticing some weird performance/stability issues in the latest Win32 build, I went back and noticed there was a bug in the dFcntl implementation, where non-blocking socket IO was never actually activated on Win32 (Unix and other platforms weren't affected). So I've updated the patches to fix that and a few other small things I discovered. First, the link: http://dillo-win32.sourceforge.net/patches.html Other changes: I've numbered the patches to reflect the dependency order, as much for my own sanity as anything. I've also removed the Html_css_repush_callback patch, since it breaks CSS streaming, though I've kept a copy on the off-chance there's ever a legitimate issue after all. I also have an updated testing build (binary and source) online if anyone wants to play with it. My build is still based on revision 1755, but that's only because the latest rendering code in hg's being worked on -- the patch applies, builds, and runs fine with the newest code as well. Johannes: I have not yet updated the DNS patch, but I intend to this weekend if I have the time. Thanks again for everyone's help and suggestions with this. I hope I have more to contribute in the future :-) Cheers, ~Benjamin

Nov. 18, 2010

fatal error while compiling fltk

by obeythepenguin＠gmail.com

It sounds like you're missing your X11 development packages. Google tells me you want xorg-x11-devel, but I'm not an opensuse user myself. Cheers, ~Benjamin On Wed, 17 Nov 2010 19:59:55 -0500, olivier SAINT-EVE <lolveley(a)yahoo.fr> wrote: > hello, > > I have opensuse 11.3 with gnome, and claws-mail. > in order to view html content on claws-mail, I had to compile dillo. > so I went to the site, downloaded fltk and tried to compile it > (fltk-2.0.x-r7725). > > but after entering "make", I had this error : > > ******************************************************************** > === making src === > Compiling addarc.cxx... > In file included from ../fltk/x.h:38:0, > from addarc.cxx:32: > ../fltk/x11.h:65:38: fatal error: X11/extensions/XInput.h: Aucun > fichier ou dossier de ce type compilation terminated. > make[1]: *** [addarc.o] Erreur 1 > make: *** [all] Erreur 2 > ******************************************************************** > > can you tell me if a peculiar software is missing? > I searched with google (X11,RPMs of dillo) but in vain. > > thanks, > > Olivier.

Nov. 18, 2010

fatal error while compiling fltk

by lolveley＠yahoo.fr

hello, I have opensuse 11.3 with gnome, and claws-mail. in order to view html content on claws-mail, I had to compile dillo. so I went to the site, downloaded fltk and tried to compile it (fltk-2.0.x-r7725). but after entering "make", I had this error : ******************************************************************** === making src === Compiling addarc.cxx... In file included from ../fltk/x.h:38:0, from addarc.cxx:32: ../fltk/x11.h:65:38: fatal error: X11/extensions/XInput.h: Aucun fichier ou dossier de ce type compilation terminated. make[1]: *** [addarc.o] Erreur 1 make: *** [all] Erreur 2 ******************************************************************** can you tell me if a peculiar software is missing? I searched with google (X11,RPMs of dillo) but in vain. thanks, Olivier.

Nov. 18, 2010

AW: [Dillo-dev] patch: text-indent

by johannes.hofmann＠gmx.de

-----Urspr?ngliche Nachricht----- An: dillo-dev(a)dillo.org; Von: corvid <corvid(a)lavabit.com> Gesendet: Do 11.11.2010 02:43 Betreff: Re: [Dillo-dev] patch: text-indent > Johannes wrote: > > We probabely want some isBlockLevelWidget() function... > > Using Widget::Flags, perhaps, or would you think it best generally > to save the flags for state that changes during a widget's life? > I was just thinking about something simple like bool isBlockLevelWidget(Widget *w) { return widget->instanceOf (Textblock::CLASS_ID) || widget->instanceOf (Table::CLASS_ID) ... ); } in textblock.cc to explain to the code reader why we are testing for exactly these widget types. Plus we might have to reuse at some point. Cheers, Johannes

Nov. 17, 2010

[bug]: CssParser::{nextToken, skipString}() skip an extra character.

by onepoint＠starurchin.org

On Mon, Nov 15, 2010 at 11:01:48PM +0100, Johannes Hofmann wrote: > Should be fixed in the repo now. Thanks for tracking this down! Yes, vanilla Dillo renders my test correctly now. Thank *you* for fixing this! Regards, Jeremy Henty

Nov. 16, 2010

[bug]: CssParser::{nextToken, skipString}() skip an extra character.

by Johannes.Hofmann＠gmx.de

On Sun, Nov 14, 2010 at 12:28:54PM +0000, Jeremy Henty wrote: > > The CssParser class has an unfortunate interaction between nextToken() > and skipString(): they are both eager to call getChar(). The result > is that when skipString() succeeds it has already getChar()-ed the > character immediately after the string to be skipped, but nextToken() > insists on calling getChar() again. This means that the character > after the skipped string is also skipped. This causes two bugs. > > Firstly, if there is a completely empty CSS comment, ie. '/**/', then > the closing '*/' is ignored (because it has already been partly > skipped over). This generally causes most or all of the style to be > ignored as the parser searches for the end of the comment. You can > see this in the wild[1]! > > Secondly, if a token starts immediately after a CSS comment, then its > first character is lost. > > The attached example shows both bugs. The first bug stops the red > style from being applied to the <p> element, and the second bug > applies the blue style to the <i> element instead of the <li> element. > > The quick fix is for skipString() to call ungetChar() before returning > successfully (patch attached). Luckily only nextToken() calls > skipString(). Should I push this, or is there a better way to do it? Should be fixed in the repo now. Thanks for tracking this down! Cheers, Johannes

Nov. 15, 2010

[bug]: CssParser::{nextToken, skipString}() skip an extra character.

by jcid＠dillo.org

On Sun, Nov 14, 2010 at 02:35:20PM +0100, Johannes Hofmann wrote: > Hi Jeremy, > > On Sun, Nov 14, 2010 at 12:28:54PM +0000, Jeremy Henty wrote: > > > > The CssParser class has an unfortunate interaction between nextToken() > > and skipString(): they are both eager to call getChar(). The result > > is that when skipString() succeeds it has already getChar()-ed the > > character immediately after the string to be skipped, but nextToken() > > insists on calling getChar() again. This means that the character > > after the skipped string is also skipped. This causes two bugs. > > > > Firstly, if there is a completely empty CSS comment, ie. '/**/', then > > the closing '*/' is ignored (because it has already been partly > > skipped over). This generally causes most or all of the style to be > > ignored as the parser searches for the end of the comment. You can > > see this in the wild[1]! > > > > Secondly, if a token starts immediately after a CSS comment, then its > > first character is lost. > > > > The attached example shows both bugs. The first bug stops the red > > style from being applied to the <p> element, and the second bug > > applies the blue style to the <i> element instead of the <li> element. > > > > The quick fix is for skipString() to call ungetChar() before returning > > successfully (patch attached). Luckily only nextToken() calls > > skipString(). Should I push this, or is there a better way to do it? > > Let me have a deeper look at the issue. I remember that there are > some quite subtle corner cases. BTW, comments that remark hidden complexities are very valuable Even with my own code, after some time passes, I can't remember all the implementation details. ;) -- Cheers Jorge.-

Nov. 15, 2010

Dillo-Win32 patches - dillo-r1755.dns.diff

by obeythepenguin＠gmail.com

On Sun, 14 Nov 2010 09:48:40 -0500, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > On Fri, Nov 12, 2010 at 11:05:38PM +0100, Joerg Sonnenberger wrote: >> On Fri, Nov 12, 2010 at 09:41:53PM +0000, corvid wrote: >> > I thought I'd at least look into the inet_ntop() -> getnameinfo() bit, >> > and I see that the latter is posix 2001. >> >> It is relatively easy to emulate the ipv4 part of getnameinfo(), but a >> lot harder to properly support IPv6 without using it. >> >> > Do we have an official position on posix 2001? > > Regarding the use of getnameinfo(), I'd be pragmatic. It's supported > by glibc, all Free-, Net-, and OpenBSD and also Android's libc. ...not to mention Microsoft's runtime library (inet_ntop wasn't added until Windows Vista, IIRC). So pretty much a win-win, then? > The memcpy however looks like it would create a stack overflow when > used with IPv6 addresses. What about using struct sockaddr_storage > and maybe even an additional assert() to make sure it doesn't overrun? I'll trust your judgment on this one. I was more or less learning the sockets interface as I went along, so I just went with the first thing that compiled and ran. I'm sure that's not the worst piece of code in there... > The "undef D_DNS_THREADED" would be more appropriate in the WIN32 > specific section of configure. Sounds good to me. That bit was coded before the autoconf stuff, so that's my excuse for not doing it sooner. :-) > Plus I'd skip the more "correct" thing in the comment, but that's > just my personal feeling. Fine with me. That wasn't really intended to stay, anyway; I just figured there should be some justification for the change. I will try to fix that patch as soon as possible. In the meantime I'll await further feedback Cheers, ~Benjamin

Nov. 14, 2010

Dillo-Win32 patches - dillo-r1755.dns.diff

by Johannes.Hofmann＠gmx.de

On Fri, Nov 12, 2010 at 11:05:38PM +0100, Joerg Sonnenberger wrote: > On Fri, Nov 12, 2010 at 09:41:53PM +0000, corvid wrote: > > I thought I'd at least look into the inet_ntop() -> getnameinfo() bit, > > and I see that the latter is posix 2001. > > It is relatively easy to emulate the ipv4 part of getnameinfo(), but a > lot harder to properly support IPv6 without using it. > > > Do we have an official position on posix 2001? Regarding the use of getnameinfo(), I'd be pragmatic. It's supported by glibc, all Free-, Net-, and OpenBSD and also Android's libc. So I don't see a problem using it. The memcpy however looks like it would create a stack overflow when used with IPv6 addresses. What about using struct sockaddr_storage and maybe even an additional assert() to make sure it doesn't overrun? The "undef D_DNS_THREADED" would be more appropriate in the WIN32 specific section of configure. Plus I'd skip the more "correct" thing in the comment, but that's just my personal feeling. Cheers, Johannes

Nov. 14, 2010

Dillo-Win32 patches, split and ready to merge

by Johannes.Hofmann＠gmx.de

Hi Benjamin, On Thu, Nov 11, 2010 at 06:44:47PM -0500, Benjamin Johnson wrote: > Here are the split Dillo-Win32 patches, ready to merge into the > upstream tree: > http://dillo-win32.sourceforge.net/patches.html > > I've cleaned up the code somewhat, such as removing the ugly > conditionals from dsock.h. This version no longer includes the > infamous "timeout kludge"; however, it must be built against a > patched FLTK2 library, as the upstream implementation is still very > badly broken. (The necessary patch is available from the > Dillo-Win32 SourceForge site.) > > These patches produce a working ./src/dillo.exe. DPI has not yet > been ported, as I presently have neither the time nor interest to do > so. I'll probably get a binary package and installer up sometime in > the next few days for anyone who wants to play around with the > latest and greatest. > > Let me know if I need to double-check anything. Thanks for taking the time to split and cleanup your patch. This way it will be easier to digest. I think we should discuss the individual patches in separate threads. Cheers, Johannes

Nov. 14, 2010

[bug]: CssParser::{nextToken, skipString}() skip an extra character.

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Sun, Nov 14, 2010 at 12:28:54PM +0000, Jeremy Henty wrote: > > The CssParser class has an unfortunate interaction between nextToken() > and skipString(): they are both eager to call getChar(). The result > is that when skipString() succeeds it has already getChar()-ed the > character immediately after the string to be skipped, but nextToken() > insists on calling getChar() again. This means that the character > after the skipped string is also skipped. This causes two bugs. > > Firstly, if there is a completely empty CSS comment, ie. '/**/', then > the closing '*/' is ignored (because it has already been partly > skipped over). This generally causes most or all of the style to be > ignored as the parser searches for the end of the comment. You can > see this in the wild[1]! > > Secondly, if a token starts immediately after a CSS comment, then its > first character is lost. > > The attached example shows both bugs. The first bug stops the red > style from being applied to the <p> element, and the second bug > applies the blue style to the <i> element instead of the <li> element. > > The quick fix is for skipString() to call ungetChar() before returning > successfully (patch attached). Luckily only nextToken() calls > skipString(). Should I push this, or is there a better way to do it? Let me have a deeper look at the issue. I remember that there are some quite subtle corner cases. Cheers, Johannes

Nov. 14, 2010

[bug]: CssParser::{nextToken, skipString}() skip an extra character.

by onepoint＠starurchin.org

The CssParser class has an unfortunate interaction between nextToken() and skipString(): they are both eager to call getChar(). The result is that when skipString() succeeds it has already getChar()-ed the character immediately after the string to be skipped, but nextToken() insists on calling getChar() again. This means that the character after the skipped string is also skipped. This causes two bugs. Firstly, if there is a completely empty CSS comment, ie. '/**/', then the closing '*/' is ignored (because it has already been partly skipped over). This generally causes most or all of the style to be ignored as the parser searches for the end of the comment. You can see this in the wild[1]! Secondly, if a token starts immediately after a CSS comment, then its first character is lost. The attached example shows both bugs. The first bug stops the red style from being applied to the <p> element, and the second bug applies the blue style to the <i> element instead of the <li> element. The quick fix is for skipString() to call ungetChar() before returning successfully (patch attached). Luckily only nextToken() calls skipString(). Should I push this, or is there a better way to do it? [1] http://layscience.net/node/1120

Nov. 14, 2010

Dillo-Win32 patches, split and ready to merge

by obeythepenguin＠gmail.com

On Fri, 12 Nov 2010 18:03:31 -0500, corvid <corvid(a)lavabit.com> wrote: > Joerg wrote: >> Primary issue with depending on certain C99 stuff is that Microsoft >> still hasn't managed to support it in the runtime library or insists on >> doing it in incompatible ways. E.g. %lld doesn't work on Windows. > > Yeah, I see that on http://en.wikipedia.org/wiki/C99#Implementations , > level of support is generally 'mostly' or 'partial'. I was thinking that > it might be valuable to decide on what subset is all right (which, > admittedly, "Using gcc and not seeing any warnings" can be regarded as, > after a fashion. :) -- even if only to bring awareness of "Oh, this is > a C99ism; I hadn't realized." > The dillo site does spell out, for instance, that for C++, "We also try > to keep the C++ relatively simple. Dillo does use inheritance and > templates, > but that's about all." I'm not sure how formal our guidelines would need to be, but if the main problem is Windows support, whatever subset we're currently using is just fine. The only problems I've encountered are upstream FLTK bugs (their Windows version is frankly abysmal), and explicit Unix-isms, mostly involving inter-process communication. For what it's worth I'm using gcc-3.4.6 from MinGW 5.1.6. A little outdated, I know, but it's the last version with a coherent installer. ~Benjamin

Nov. 13, 2010

Dillo-Win32 patches, split and ready to merge

by corvid＠lavabit.com

Joerg wrote: > On Fri, Nov 12, 2010 at 09:41:53PM +0000, corvid wrote: > > I thought I'd at least look into the inet_ntop() -> getnameinfo() bit, > > and I see that the latter is posix 2001. > > It is relatively easy to emulate the ipv4 part of getnameinfo(), but a > lot harder to properly support IPv6 without using it. I remember Justus doing some work on IPv6. Is it not complete? > > Do we have an official position on posix 2001? > > > > And, for that matter, C99? > > Primary issue with depending on certain C99 stuff is that Microsoft > still hasn't managed to support it in the runtime library or insists on > doing it in incompatible ways. E.g. %lld doesn't work on Windows. Yeah, I see that on http://en.wikipedia.org/wiki/C99#Implementations , level of support is generally 'mostly' or 'partial'. I was thinking that it might be valuable to decide on what subset is all right (which, admittedly, "Using gcc and not seeing any warnings" can be regarded as, after a fashion. :) -- even if only to bring awareness of "Oh, this is a C99ism; I hadn't realized." The dillo site does spell out, for instance, that for C++, "We also try to keep the C++ relatively simple. Dillo does use inheritance and templates, but that's about all."

Nov. 13, 2010

Dillo-Win32 patches, split and ready to merge

by joerg.sonnenberger＠web.de

On Fri, Nov 12, 2010 at 09:41:53PM +0000, corvid wrote: > I thought I'd at least look into the inet_ntop() -> getnameinfo() bit, > and I see that the latter is posix 2001. It is relatively easy to emulate the ipv4 part of getnameinfo(), but a lot harder to properly support IPv6 without using it. > Do we have an official position on posix 2001? > > And, for that matter, C99? Primary issue with depending on certain C99 stuff is that Microsoft still hasn't managed to support it in the runtime library or insists on doing it in incompatible ways. E.g. %lld doesn't work on Windows. Joerg

Nov. 12, 2010

Dillo-Win32 patches, split and ready to merge

by corvid＠lavabit.com

I thought I'd at least look into the inet_ntop() -> getnameinfo() bit, and I see that the latter is posix 2001. Do we have an official position on posix 2001? And, for that matter, C99? There at least used to be a bit in decode.c where I was discouraged from using a Unicode string because it was C99, but we also had a thread http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-June/004634.html on the fact that --enable-ansi is no good because we use too many C99isms. (I'd forgotten all about that thread, actually. I vote again for removing the option, since I can't imagine the variadic macros going away, for instance.)

Nov. 12, 2010

Dillo-Win32 patches, split and ready to merge

by obeythepenguin＠gmail.com

Here are the split Dillo-Win32 patches, ready to merge into the upstream tree: http://dillo-win32.sourceforge.net/patches.html I've cleaned up the code somewhat, such as removing the ugly conditionals from dsock.h. This version no longer includes the infamous "timeout kludge"; however, it must be built against a patched FLTK2 library, as the upstream implementation is still very badly broken. (The necessary patch is available from the Dillo-Win32 SourceForge site.) These patches produce a working ./src/dillo.exe. DPI has not yet been ported, as I presently have neither the time nor interest to do so. I'll probably get a binary package and installer up sometime in the next few days for anyone who wants to play around with the latest and greatest. Let me know if I need to double-check anything. Cheers, ~Benjamin

Nov. 12, 2010

patch: text-indent

by corvid＠lavabit.com

Johannes wrote: > We probabely want some isBlockLevelWidget() function... Using Widget::Flags, perhaps, or would you think it best generally to save the flags for state that changes during a widget's life?

Nov. 11, 2010