- Dillo-dev - lists.mailman3.com

Mouse buttons in keysrc

by jcid＠dillo.org

On Thu, Jun 23, 2011 at 11:25:36PM +0000, corvid wrote: > Alexander wrote: > > I played a bit with the mouse keys in FLTK/Dillo and created a small > > patch which enables the bindings of the mouse buttons 1-9 in keysrc > > Have you noticed anything definitive in FLTK on how many buttons it > can handle? > > FL_BUTTONS appears to expect a limit of 7. > Fl::event_key() appears to think the limit is 8. > FL_Button would have room for 31. > > ..but I only looked for a couple of minutes. I have no clue. :) BTW, I was wondering whether e.g. mouse7 was a real button or some kind of gesture/combination. -- Cheers Jorge.-

June 24, 2011

Quit Button Window Size fixed with latest fltk-1.3.0 release

by jcid＠dillo.org

On Thu, Jun 23, 2011 at 09:07:01PM -0800, Roger wrote: > It appears the latest release of fltk-1.3.0 fixed a problem I was seeing with > the quit window size for Dillo-port-1.3.0 being full size within the DWM > (window manager). > > (Either that, or a patch within dillo-port-1.3 fixed it, but it doesn't appear > so because I don't think I've pulled Dillo-port-1.3.0 dev sources for awhile > here, except for the recent fltk-1.3.0 release upgrade.) It was switched to "modal" in June 10. -- Cheers Jorge.-

June 24, 2011

Quit Button Window Size fixed with latest fltk-1.3.0 release

by rogerx.oss＠gmail.com

It appears the latest release of fltk-1.3.0 fixed a problem I was seeing with the quit window size for Dillo-port-1.3.0 being full size within the DWM (window manager). (Either that, or a patch within dillo-port-1.3 fixed it, but it doesn't appear so because I don't think I've pulled Dillo-port-1.3.0 dev sources for awhile here, except for the recent fltk-1.3.0 release upgrade.) Cheers! -- Roger http://rogerx.freeshell.org/

June 24, 2011

Mouse buttons in keysrc

by corvid＠lavabit.com

Alexander wrote: > I played a bit with the mouse keys in FLTK/Dillo and created a small > patch which enables the bindings of the mouse buttons 1-9 in keysrc Have you noticed anything definitive in FLTK on how many buttons it can handle? FL_BUTTONS appears to expect a limit of 7. Fl::event_key() appears to think the limit is 8. FL_Button would have room for 31. ..but I only looked for a couple of minutes.

June 24, 2011

Mouse buttons in keysrc

by corvid＠lavabit.com

Alexander wrote: > I played a bit with the mouse keys in FLTK/Dillo and created a small > patch which enables the bindings of the mouse buttons 1-9 in keysrc > (see appendix). Now it is possible to write in your keysrc > > button8 = back > button9 = forward > > to use the mouse buttons 8 and 9 to jump backward and forward in the > page history (this the setting which is used e.g. in Firefox). Please > feel free to use it! I haven't tried this out yet, but I was wondering: Are there any issues with having buttons as both keys and modifiers? (Of the two, having them as keys does seem more useful than modifiers.) I wonder whether we will eventually have to bring in some idea of contexts to specify what to do when this key is seen and you're on a link or a tab or whatever, as was alluded to with removing middle_click dillorc options.

June 20, 2011

Mouse buttons in keysrc

by Hole.destructor＠gmx.de

Dear Dillo Developers, I played a bit with the mouse keys in FLTK/Dillo and created a small patch which enables the bindings of the mouse buttons 1-9 in keysrc (see appendix). Now it is possible to write in your keysrc button8 = back button9 = forward to use the mouse buttons 8 and 9 to jump backward and forward in the page history (this the setting which is used e.g. in Firefox). Please feel free to use it! Kind regards, Alexander On Sun, Jun 19, 2011 at 11:30:24AM +0200, Alexander Voigt wrote: > Dear Dillo developers, > > I noticed that the key configuration via keysrc does not recognize > mouse keys. So I am wondering whether anybody already thought about > adding mouse keys? I think for many users something like > > <shift>mouse1 = new-tab > mouse9 = forward > mouse8 = back > > in keysrc would be very convenient. (This would probably make the > options middle_click_opens_new_tab and middle_click_drags_page in > dillorc obsolete.) > > Kind regards, > Alexander > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

June 20, 2011

printer symbols in dillo

by corvid＠lavabit.com

Jorge wrote: > with a comment on its purpose of course :)

June 20, 2011

printer symbols in dillo

by jcid＠dillo.org

On Sun, Jun 19, 2011 at 12:11:37AM +0000, corvid wrote: > I wrote: > > I wrote: > > > I put dillo through nm, and I saw a bunch of > > > Fl_Paged_Device, Fl_PostScript_Printer, T Fl_PostScript_File_Device > > > in there. > > > > > > I didn't pay any attention when they were all enthusiastic about printer > > > support for a while there. Is there a justifiable reason that this gets > > > pulled in, as opposed to an oversight on their part when #ifdef'ing > > > or something? > > > > Turns out there's a > > > > if (Fl_Surface_Device::surface()->class_name() == Fl_Printer::class_id) > > > > in Fl_Text_Display.cxx that pulls it all in. > > I'll have to ask them whether there's a reasonable way for them to > > do something about this someday... > > In http://fltk.org/newsgroups.php?s23982+gfltk.general+v23991+T0 , > Domingo Alvarez Duarte made a suggestion that seems to work fine > for me. Patch attached. > Please commit with a comment on its purpose (to avoid linking in unused code). BTW, it'd be great if we could play a bit with printing to check how close/far we are from having the feature. -- Cheers Jorge.-

June 19, 2011

Mouse buttons in keysrc

by Hole.destructor＠gmx.de

Dear Dillo developers, I noticed that the key configuration via keysrc does not recognize mouse keys. So I am wondering whether anybody already thought about adding mouse keys? I think for many users something like <shift>mouse1 = new-tab mouse9 = forward mouse8 = back in keysrc would be very convenient. (This would probably make the options middle_click_opens_new_tab and middle_click_drags_page in dillorc obsolete.) Kind regards, Alexander

June 19, 2011

printer symbols in dillo

by corvid＠lavabit.com

I wrote: > I wrote: > > I put dillo through nm, and I saw a bunch of > > Fl_Paged_Device, Fl_PostScript_Printer, T Fl_PostScript_File_Device > > in there. > > > > I didn't pay any attention when they were all enthusiastic about printer > > support for a while there. Is there a justifiable reason that this gets > > pulled in, as opposed to an oversight on their part when #ifdef'ing > > or something? > > Turns out there's a > > if (Fl_Surface_Device::surface()->class_name() == Fl_Printer::class_id) > > in Fl_Text_Display.cxx that pulls it all in. > I'll have to ask them whether there's a reasonable way for them to > do something about this someday... In http://fltk.org/newsgroups.php?s23982+gfltk.general+v23991+T0 , Domingo Alvarez Duarte made a suggestion that seems to work fine for me. Patch attached.

June 19, 2011

Time to celebrate!

by rogerx.oss＠gmail.com

Within an hour or so, we pushed a fltk-1.3.0.ebuild into Gentoo's Portage. ;-) Enjoy. Oh, and no pun intended Debian. (lol) > On Fri, Jun 17, 2011 at 12:52:02PM -0300, Fabio Pasini wrote: > Hi Folks, > > > This means a lot to us: ? ? [1]http://fltk.org/articles.php?L1086 > > After read Jorge's email, I sent a message to the Debian FLTK1.3 package > maintainer, and he answered really fast ! > See attached below the answer :) > > Jorge, thanks a lot for the update! > > Best regards, > Fabio Pasini > > 2011/6/17 Aaron M. Ucko <[2]ucko(a)debian.org> > > ??? Fabio Pasini <[3]fabio.pasini(a)gmail.com> writes: > > ??? > FLTK1.3 Final Version was released (Jun 16, 2011), you may the > official post > ??? > at [4]http://fltk.org/articles.php?L1086 , those are the great news > I'd like to > ??? > share :) > > ??? Thank you very much for bringing that news to my attention!? I've been > ??? busy with other matters, but I'll try to get 1.3.0 final into Debian > ??? unstable within the next couple of weeks. > > ??? -- > ??? Aaron M. Ucko, KB1CJC (amu at [5]alum.mit.edu, ucko at [6]debian.org) > ??? [7]http://www.mit.edu/~amu/ | > [8]http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu > > ---------- Forwarded message ---------- > From: Fabio Pasini <[9]fabio.pasini(a)gmail.com> > Date: 2011/6/17 > Subject: Regarding FLTK1.3 at Launchpad and news at [10]fltk.org > To: [11]amu(a)alum.mit.edu, [12]ucko(a)debian.org > > Hi Aaron, > > I got your emails from [13]https://launchpad.net/~ucko, when searching for > FLTK1.3 packages to use with Dillo Browser. > > Are you still maintaining the content at > [14]https://launchpad.net/debian/+source/fltk1.3 ? > > FLTK1.3 Final Version was released (Jun 16, 2011), you may the official > post at [15]http://fltk.org/articles.php?L1086 , those are the great news > I'd like to share :) > > I'm trying to help Dillo to get back to the package repositories,? and > FLTK1.3 is a pre-requisite. If you're not the maintainer for > debian/+source/fltk1.3, can you point someone else, or some other PPA? > > Best regards, and thanks a lot > Tilpa > >References > > Visible links > 1. http://fltk.org/articles.php?L1086 > 2. mailto:ucko@debian.org > 3. mailto:fabio.pasini@gmail.com > 4. http://fltk.org/articles.php?L1086 > 5. http://alum.mit.edu/ > 6. http://debian.org/ > 7. http://www.mit.edu/~amu/ > 8. http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu > 9. mailto:fabio.pasini@gmail.com > 10. http://fltk.org/ > 11. mailto:amu@alum.mit.edu > 12. mailto:ucko@debian.org > 13. https://launchpad.net/~ucko > 14. https://launchpad.net/debian/+source/fltk1.3 > 15. http://fltk.org/articles.php?L1086 >_______________________________________________ >Dillo-dev mailing list >Dillo-dev(a)dillo.org >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- Roger http://rogerx.freeshell.org/

June 17, 2011

Time to celebrate!

by fabio.pasini＠gmail.com

Hi Folks, > This means a lot to us: http://fltk.org/articles.php?L1086 After read Jorge's email, I sent a message to the Debian FLTK1.3 package maintainer, and he answered really fast ! See attached below the answer :) Jorge, thanks a lot for the update! Best regards, Fabio Pasini 2011/6/17 Aaron M. Ucko <ucko(a)debian.org> Fabio Pasini <fabio.pasini(a)gmail.com> writes: > FLTK1.3 Final Version was released (Jun 16, 2011), you may the official post > at http://fltk.org/articles.php?L1086 , those are the great news I'd like to > share :) Thank you very much for bringing that news to my attention! I've been busy with other matters, but I'll try to get 1.3.0 final into Debian unstable within the next couple of weeks. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu ---------- Forwarded message ---------- From: Fabio Pasini <fabio.pasini(a)gmail.com> Date: 2011/6/17 Subject: Regarding FLTK1.3 at Launchpad and news at fltk.org To: amu(a)alum.mit.edu, ucko(a)debian.org Hi Aaron, I got your emails from https://launchpad.net/~ucko, when searching for FLTK1.3 packages to use with Dillo Browser. Are you still maintaining the content at https://launchpad.net/debian/+source/fltk1.3 ? FLTK1.3 Final Version was released (Jun 16, 2011), you may the official post at http://fltk.org/articles.php?L1086 , those are the great news I'd like to share :) I'm trying to help Dillo to get back to the package repositories, and FLTK1.3 is a pre-requisite. If you're not the maintainer for debian/+source/fltk1.3, can you point someone else, or some other PPA? Best regards, and thanks a lot Tilpa

June 17, 2011

Time to celebrate!

by jcid＠dillo.org

Hi, This means a lot to us: http://fltk.org/articles.php?L1086 !! :-) !! -- Cheers Jorge.-

June 17, 2011

Development schedule for version 1.3

by jcid＠dillo.org

On Thu, Jun 09, 2011 at 07:50:27PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Jun 05, 2011 at 08:08:15PM +0000, corvid wrote: > > > - tab titles > > > > > > Just cosmetic issues of: They seem too short, the original title of, e.g., > > > ctab5, is suboptimal, and the ones without a title tag are initially blank. > > > > This may be a matter of taste. e.g. Dillo-2.x used "dillo" > > instead of a blank title, and allowed longer labels. I like the > > current behaviour with fixed length tabs. YMMV. > > > > "ctab<n>" as label is weird, and should be changed. > > > > Suggestions? (e.g. tab length, initial string). > > Keep it simple please ;-) > > The case where you open an image. At first the tab title is blank. > Then I click another tab and then return to the image. Now it's the > beginning of the URL (not that "http://..." is terribly meaningful :) Patch committed. -- Cheers Jorge.-

June 15, 2011

Update on segfault issues

by corvid＠lavabit.com

Rob wrote: > I have been playing around with the 1.3 port on my "broken" machine. > Still no luck with sorting out the segfault. I have spent a fair > amount of time in gdb and valgrind trying to track down the source of > the trouble, but no luck. The best I can do when compiling with gcc > is to use -O0, which produces an executable which does not segfault. > I have tried gcc 4.4, 4.5, and 4.6, to no avail. I have wondered if > it was something to do with my architecture; I am running an AMD E-350 > fusion processor in my machine. In light of this, I tried using the > appropriate -march setting with gcc 4.6, but again no luck. Have you tried 1) adding MSG()s to watch interesting variables? 2) Turning on various warning options in gcc for issues that matter when optimization is used (overflow, for instance)?

June 11, 2011

Update on segfault issues

by jcid＠dillo.org

On Fri, Jun 10, 2011 at 11:42:53PM -0400, Rob S wrote: > I have been playing around with the 1.3 port on my "broken" machine. > Still no luck with sorting out the segfault. I have spent a fair > amount of time in gdb and valgrind trying to track down the source of > the trouble, but no luck. The best I can do when compiling with gcc > is to use -O0, which produces an executable which does not segfault. > I have tried gcc 4.4, 4.5, and 4.6, to no avail. I have wondered if > it was something to do with my architecture; I am running an AMD E-350 > fusion processor in my machine. In light of this, I tried using the > appropriate -march setting with gcc 4.6, but again no luck. The only > bright side of all of this was that I decided to compile with Clang, > and it built nicely with only one warning (which I could not see the > reason for): > > > chain.c:189:50: warning: too many arguments in call to 'Chain_debug_msg' > Chain_debug_msg(FuncStr, Op, Branch, Dir, Info); > ~~~~~~~~~~~~~~~ ^ That's simple, just check the last repo! ;) > I will keep playing with this, to see if I can figure out the problem > with gcc, but my hope is fading with regards to finding a solution. Compile with debug info: CFLAGS="-g -O0" CXXFLAGS="-g -O0" ./configure --enable-ssl then run it under gdb: gdb ./dillo when it segfaults, look where it was: bt that's a good point to start. HTH -- Cheers Jorge.-

June 11, 2011

Development schedule for version 1.3

by jcid＠dillo.org

On Fri, Jun 10, 2011 at 08:52:18PM +0000, corvid wrote: > Fabio wrote: > > Guys, how about putting some images from current Dillo with FLTK1.3 into > > another table at //www.dillo.org/screenshots/? > > Once there is no definition about release name, the table title can be > > something like "Dillo with FLTK1.3", plus (maybe) something catchy as > > "Coming Soon". > > For the version number, I initially leaned toward 2.3 a little, but > now I think I'm leaning toward 3.0 because it's simpler to say "3.x uses > 1.3 and runs on [whatever]" than "Starting with 2.3, ..." ... and dillo-3.0 works with fltk-1.3, and in the future with fltk-3.0, at least that's fltk devs' plan by now. -- Cheers Jorge.-

June 11, 2011

Development schedule for version 1.3

by darkspirit5000＠gmail.com

How about dillo 2.1.3? It is a 2 version (fltk, css, ...) with fltk 1.3. Dillo can jump to 3.0 with floating objects :P Diego. 2011/6/11, Reza Farivar <rf.opensource(a)gmail.com>: > > > -Reza > > On Jun 10, 2011, at 3:52 PM, "corvid" <corvid(a)lavabit.com> wrote: > >> Fabio wrote: >>> Guys, how about putting some images from current Dillo with >>> FLTK1.3 into >>> another table at //www.dillo.org/screenshots/? >>> Once there is no definition about release name, the table title can >>> be >>> something like "Dillo with FLTK1.3", plus (maybe) something catchy as >>> "Coming Soon". >> >> For the version number, I initially leaned toward 2.3 a little, but >> now I think I'm leaning toward 3.0 because it's simpler to say "3.x >> uses >> 1.3 and runs on [whatever]" than "Starting with 2.3, ... > > How about dillo 2011? > >> >> It'd be interesting to have some screenshots (mostly if anyone >> contributes >> ones showing native OSX, if that looks any different from using the X >> backend) > > I can take screenshots of the Mac version. It's not that different > though, but at least it shows it's cocoa and not running on X. > > >> once Jorge decides that there won't be any more UI tweaking. >> (e.g., will the sizes of the progress boxes depend on their labels? >> I've >> noticed that the labels don't fit on occasion, but maybe that's >> intended >> to reduce redraws.) >> >> >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev(a)dillo.org >> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

June 11, 2011

Update on segfault issues

by mr_semantics＠hotmail.com

I have been playing around with the 1.3 port on my "broken" machine. Still no luck with sorting out the segfault. I have spent a fair amount of time in gdb and valgrind trying to track down the source of the trouble, but no luck. The best I can do when compiling with gcc is to use -O0, which produces an executable which does not segfault. I have tried gcc 4.4, 4.5, and 4.6, to no avail. I have wondered if it was something to do with my architecture; I am running an AMD E-350 fusion processor in my machine. In light of this, I tried using the appropriate -march setting with gcc 4.6, but again no luck. The only bright side of all of this was that I decided to compile with Clang, and it built nicely with only one warning (which I could not see the reason for): chain.c:189:50: warning: too many arguments in call to 'Chain_debug_msg' Chain_debug_msg(FuncStr, Op, Branch, Dir, Info); ~~~~~~~~~~~~~~~ ^ I will keep playing with this, to see if I can figure out the problem with gcc, but my hope is fading with regards to finding a solution. Rob

June 11, 2011

Development schedule for version 1.3

by rf.opensource＠gmail.com

-Reza On Jun 10, 2011, at 3:52 PM, "corvid" <corvid(a)lavabit.com> wrote: > Fabio wrote: >> Guys, how about putting some images from current Dillo with >> FLTK1.3 into >> another table at //www.dillo.org/screenshots/? >> Once there is no definition about release name, the table title can >> be >> something like "Dillo with FLTK1.3", plus (maybe) something catchy as >> "Coming Soon". > > For the version number, I initially leaned toward 2.3 a little, but > now I think I'm leaning toward 3.0 because it's simpler to say "3.x > uses > 1.3 and runs on [whatever]" than "Starting with 2.3, ... How about dillo 2011? > > It'd be interesting to have some screenshots (mostly if anyone > contributes > ones showing native OSX, if that looks any different from using the X > backend) I can take screenshots of the Mac version. It's not that different though, but at least it shows it's cocoa and not running on X. > once Jorge decides that there won't be any more UI tweaking. > (e.g., will the sizes of the progress boxes depend on their labels? > I've > noticed that the labels don't fit on occasion, but maybe that's > intended > to reduce redraws.) > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

June 11, 2011

Development schedule for version 1.3

by corvid＠lavabit.com

Fabio wrote: > Guys, how about putting some images from current Dillo with FLTK1.3 into > another table at //www.dillo.org/screenshots/? > Once there is no definition about release name, the table title can be > something like "Dillo with FLTK1.3", plus (maybe) something catchy as > "Coming Soon". For the version number, I initially leaned toward 2.3 a little, but now I think I'm leaning toward 3.0 because it's simpler to say "3.x uses 1.3 and runs on [whatever]" than "Starting with 2.3, ..." It'd be interesting to have some screenshots (mostly if anyone contributes ones showing native OSX, if that looks any different from using the X backend) once Jorge decides that there won't be any more UI tweaking. (e.g., will the sizes of the progress boxes depend on their labels? I've noticed that the labels don't fit on occasion, but maybe that's intended to reduce redraws.)

June 10, 2011

Development schedule for version 1.3

by fabio.pasini＠gmail.com

Hi all, >> P.S. Are we going to call Dillo with FLTK1.3 as Dillo3? One >> problem is that on the surface nothing has changed from Dillo2, >> so users will probably get confused. > Probably... Guys, how about putting some images from current Dillo with FLTK1.3 into another table at //www.dillo.org/screenshots/? Once there is no definition about release name, the table title can be something like "Dillo with FLTK1.3", plus (maybe) something catchy as "Coming Soon". My point is, you are all doing a lot of job around FLTK1.3 (Yeah!) and a page update might attract more attention to the project, also helping it to get pushed into distros again :) Best regards, F?bio ps: Great work, folks! 2011/6/9 Jorge Arellano Cid <jcid(a)dillo.org> > On Mon, Jun 06, 2011 at 06:16:58PM -0700, Globe Trotter wrote: > > Do we have features/bugs for each milestone documented > > anywhere? http://www.dillo.org/Plans.html is a bit too high > > level. > > That's the place we have. We can't do much better without more > manpower. BTW, I'm surprised on how accurate it became. > > > What comes after 1.3? > > Floating objects! > And maybe some announcements that may surprise our users. > > The point of fltk-1.3 for the Dillo project is to be back in > the distro's repos. This is paramount to us. > > > > I doubt fltk 1.3 will be released on Wednesday: they have yet > > to release their RC7 which was supposed to be June 1, > > It's hard to know when it'll happen. After +5years waiting for > fltk2, I can only hope fltk-1.3 is released soon. FWIW, > development in this branch is very active so it looks like it > could happen soon. > > IIRC, the first estimated release dates were for December 2010. > > > > > > P.S. Are we going to call Dillo with FLTK1.3 as Dillo3? One > > problem is that on the surface nothing has changed from Dillo2, > > so users will probably get confused. > > Probably... > > And possibly the next fltk release will be fltk-3.0, and we > should be able to link against it. > > > > Btw, it is unfathomable to me why weekly fltk2 updates continue > > to be released...... > > C'mon, that's an easy one! > > > >hopefully, fltk1.3 will not be as much of a > > roadblock in terms of facilitating adoption of dillo as fltk2 > > was. > > Recall that since they never hit stable, distros such as > > Fedora did not go for dillo2 (sticking with dillo 0.8.6). > > That's the sad part of the story. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

June 10, 2011

fonts [Re: [Dillo-dev] Development schedule for version 1.3]

by corvid＠lavabit.com

Johannes wrote: > I committed a slightly modified patch that uses our systemFonts > table also for finding the default ui font. I notice that I only have the italic version of URW Chancery L (and a moment of looking things up suggests italic is the only version that exists). If I set font_sans_serif to use it, it is only used for text that should be italicized, whereas dillo2 would use it for any text. I'm not sure whether that's _bad_, exactly, but if we want to or have to stick with this behaviour, it might not make a good default for font_cursive any longer.

June 9, 2011

Development schedule for version 1.3

by corvid＠lavabit.com

Jorge wrote: > On Sun, Jun 05, 2011 at 08:08:15PM +0000, corvid wrote: > > - tab titles > > > > Just cosmetic issues of: They seem too short, the original title of, e.g., > > ctab5, is suboptimal, and the ones without a title tag are initially blank. > > This may be a matter of taste. e.g. Dillo-2.x used "dillo" > instead of a blank title, and allowed longer labels. I like the > current behaviour with fixed length tabs. YMMV. > > "ctab<n>" as label is weird, and should be changed. > > Suggestions? (e.g. tab length, initial string). > Keep it simple please ;-) The case where you open an image. At first the tab title is blank. Then I click another tab and then return to the image. Now it's the beginning of the URL (not that "http://..." is terribly meaningful :)

June 9, 2011

Development schedule for version 1.3

by jcid＠dillo.org

On Mon, Jun 06, 2011 at 06:16:58PM -0700, Globe Trotter wrote: > Do we have features/bugs for each milestone documented > anywhere??http://www.dillo.org/Plans.html is a bit too high > level. That's the place we have. We can't do much better without more manpower. BTW, I'm surprised on how accurate it became. > What comes after 1.3? Floating objects! And maybe some announcements that may surprise our users. The point of fltk-1.3 for the Dillo project is to be back in the distro's repos. This is paramount to us. > I doubt fltk 1.3 will be released on Wednesday: they have yet > to release their RC7 which was supposed to be June 1, It's hard to know when it'll happen. After +5years waiting for fltk2, I can only hope fltk-1.3 is released soon. FWIW, development in this branch is very active so it looks like it could happen soon. IIRC, the first estimated release dates were for December 2010. > > P.S. Are we going to call Dillo with FLTK1.3 as Dillo3? One > problem is that on the surface nothing has changed from Dillo2, > so users will probably get confused. Probably... And possibly the next fltk release will be fltk-3.0, and we should be able to link against it. > Btw, it is unfathomable to me why weekly fltk2 updates continue > to be released...... C'mon, that's an easy one! >hopefully, fltk1.3 will not be as much of a > roadblock in terms of facilitating adoption of dillo as fltk2 > was. > Recall that since they never hit stable, distros such as > Fedora did not go for dillo2 (sticking with dillo 0.8.6). That's the sad part of the story. -- Cheers Jorge.-

June 9, 2011

Development schedule for version 1.3

by Johannes.Hofmann＠gmx.de

On Tue, Jun 07, 2011 at 10:09:46PM +0000, corvid wrote: > I wrote: > > Johannes wrote: > > > Can you please try attached patch? > > > It seems to work ok with xft enabled and also allows to set e.g: > > > font_sans_serif="helvetica" without xft. > > > Font names in the non-xft case are still a bit odd (e.g. all lower > > > case), but I don't think there's much we can do about that. > > > For non-xft, xlsfonts says that I have, for instance, "new century > > schoolbook", but Dillo doesn't list it. > > I changed it to Fl::set_fonts ("-*-iso10646-1"); to follow the lead of > > if (!xstarname) { > strcpy(buf,"-*-"); strcpy(buf+3,fl_encoding); > xstarname = buf; > } > > and now it can find new century schoolbook. I committed a slightly modified patch that uses our systemFonts table also for finding the default ui font. Cheers, Johannes

June 9, 2011

Development schedule for version 1.3

by jcid＠dillo.org

On Sun, Jun 05, 2011 at 08:08:15PM +0000, corvid wrote: > [...] > - Still missing is the -f command line option (used by claws). > > Jorge was waiting for something to do with FLTK before taking action there. Yes, Matt wrote he planned to solve STR2639 for rc7, but it didn't happen so, I'll commit a patch with workarounds. (FWIW, I would have been surprised with such a change at this stage). > - tab titles > > Just cosmetic issues of: They seem too short, the original title of, e.g., > ctab5, is suboptimal, and the ones without a title tag are initially blank. This may be a matter of taste. e.g. Dillo-2.x used "dillo" instead of a blank title, and allowed longer labels. I like the current behaviour with fixed length tabs. YMMV. "ctab<n>" as label is weird, and should be changed. Suggestions? (e.g. tab length, initial string). Keep it simple please ;-) -- Cheers Jorge.-

June 9, 2011

Table::addCell() leak

by jcid＠dillo.org

Hi there, I'm back from a new machine (still tweaking it, but workable!) On Sun, Jun 05, 2011 at 03:09:35AM +0000, corvid wrote: > > http://starurchin.org/dillo/valgrind/10ca58f617a0693638facdb40bcf319af1bdfc… > has a leak at dw/table.cc:323, and I found a way to trigger it: > > <table border=2> > <tr><td>first<td rowspan=2>tall<td>third > <tr><td colspan=2>wide<td>last > </table> > > Jorge, you might remember a little something about tables. Can we > simply check children->get() before putting anything there, or do > we have to fix things somewhere if part of a span is stolen away? Hmmm, fixing it from the HTML parser would be harder as AFAIR it doesn't know much more than adding rows and cells. Corner cases as this should be easier to handle in the dw-table as you suggest. It looks like an overlooked case, or maybe just paying the "leak cost" of it. ;-) You should review the algorithm to make sure the stolen cell will not be missed elsewhere. -- Cheers Jorge.-

June 9, 2011

Development schedule for version 1.3

by corvid＠lavabit.com

I wrote: > Johannes wrote: > > Can you please try attached patch? > > It seems to work ok with xft enabled and also allows to set e.g: > > font_sans_serif="helvetica" without xft. > > Font names in the non-xft case are still a bit odd (e.g. all lower > > case), but I don't think there's much we can do about that. > For non-xft, xlsfonts says that I have, for instance, "new century > schoolbook", but Dillo doesn't list it. I changed it to Fl::set_fonts ("-*-iso10646-1"); to follow the lead of if (!xstarname) { strcpy(buf,"-*-"); strcpy(buf+3,fl_encoding); xstarname = buf; } and now it can find new century schoolbook.

June 8, 2011

Development schedule for version 1.3

by corvid＠lavabit.com

Johannes wrote: > Can you please try attached patch? > It seems to work ok with xft enabled and also allows to set e.g: > font_sans_serif="helvetica" without xft. > Font names in the non-xft case are still a bit odd (e.g. all lower > case), but I don't think there's much we can do about that. It looks like I have to get the capitalization right for the xft case now. I have a tendency to specify the fonts in lowercase. For non-xft, xlsfonts says that I have, for instance, "new century schoolbook", but Dillo doesn't list it.

June 7, 2011

Development schedule for version 1.3

by Johannes.Hofmann＠gmx.de

On Mon, Jun 06, 2011 at 09:26:03PM +0000, corvid wrote: > I wrote: > > Johannes wrote: > > > On Mon, Jun 06, 2011 at 08:04:37PM +0000, corvid wrote: > > > > PS Do you think we should change the Fl::set_fonts ("-*"); > > > > to specify iso10646-1? > > > > > > Wouldn't that exclude non-UTF-8 fonts which might work fine for > > > people not caring about special chars? > > > > I was thinking of the case where you had a latin1 version and a > > utf-8 version of a font, but I don't know the relevant code well > > enough to know what happens. > > The xft version says: > // Also, for now I'm ignoring the "pattern_name" and just getting everything... > > So I guess there's no point in worrying about it. > Can you please try attached patch? It seems to work ok with xft enabled and also allows to set e.g: font_sans_serif="helvetica" without xft. Font names in the non-xft case are still a bit odd (e.g. all lower case), but I don't think there's much we can do about that. Cheers, Johannes

June 7, 2011

Development schedule for version 1.3

by itsme_410＠yahoo.com

Do we have features/bugs for each milestone documented anywhere??http://www.dillo.org/Plans.html is a bit too high level. What comes after 1.3? I doubt fltk 1.3 will be released on Wednesday: they have yet to release their RC7 which was supposed to be June 1, P.S. Are we going to call Dillo with FLTK1.3 as Dillo3? One problem is that on the surface nothing has changed from Dillo2, so users will probably get confused. How about call it dillo2.3? Btw, it is unfathomable to me why weekly fltk2 updates continue to be released......hopefully, fltk1.3 will not be as much of a roadblock in terms of facilitating adoption of dillo as fltk2 was. Recall that since they never hit stable, distros such as Fedora did not go for dillo2 (sticking with dillo 0.8.6).

June 7, 2011

Development schedule for version 1.3

by corvid＠lavabit.com

I wrote: > Johannes wrote: > > On Mon, Jun 06, 2011 at 08:04:37PM +0000, corvid wrote: > > > PS Do you think we should change the Fl::set_fonts ("-*"); > > > to specify iso10646-1? > > > > Wouldn't that exclude non-UTF-8 fonts which might work fine for > > people not caring about special chars? > > I was thinking of the case where you had a latin1 version and a > utf-8 version of a font, but I don't know the relevant code well > enough to know what happens. The xft version says: // Also, for now I'm ignoring the "pattern_name" and just getting everything... So I guess there's no point in worrying about it.

June 6, 2011

Development schedule for version 1.3

by corvid＠lavabit.com

Johannes wrote: > On Mon, Jun 06, 2011 at 08:04:37PM +0000, corvid wrote: > > PS Do you think we should change the Fl::set_fonts ("-*"); > > to specify iso10646-1? > > Wouldn't that exclude non-UTF-8 fonts which might work fine for > people not caring about special chars? I was thinking of the case where you had a latin1 version and a utf-8 version of a font, but I don't know the relevant code well enough to know what happens.

June 6, 2011

Development schedule for version 1.3

by Johannes.Hofmann＠gmx.de

On Mon, Jun 06, 2011 at 08:04:37PM +0000, corvid wrote: > Johannes wrote: > > I just committed something to get the preferred font stuff working > > on fltk-1.3. Please give it a try. > > Does it work for you with xft disabled? > I set font_sans_serif to "helvetica", and got > ** WARNING **: preferred sans-serif font "helvetica" not found. No, doesn't seem to work here either. This is a general problem of the font handling code in fltkplatform.cc and fltk13... I will look into it. > > PS Do you think we should change the Fl::set_fonts ("-*"); > to specify iso10646-1? Wouldn't that exclude non-UTF-8 fonts which might work fine for people not caring about special chars? Cheers, Johannes

June 6, 2011

Development schedule for version 1.3

by corvid＠lavabit.com

Johannes wrote: > I just committed something to get the preferred font stuff working > on fltk-1.3. Please give it a try. Does it work for you with xft disabled? I set font_sans_serif to "helvetica", and got ** WARNING **: preferred sans-serif font "helvetica" not found. PS Do you think we should change the Fl::set_fonts ("-*"); to specify iso10646-1?

June 6, 2011

Development schedule for version 1.3

by Johannes.Hofmann＠gmx.de

On Sun, Jun 05, 2011 at 08:08:15PM +0000, corvid wrote: > reza wrote: > > It seems that FLTK will release their final 1.3 version next week on June > > 8th. Are we waiting on that to release our own dillo 1.3? The reason I'm > > asking is that as you know I'm preparing an installable Mac OS package, > > which I hope to go on dillo's download page (and hopefully introduce dillo > > to many non-developer users). So I'd like to know if we are just waiting on > > that final release of FLTK 1.3, or whether there are still open bugs > > remaining for our next release? > > Right now, I'm aware of: > > - the preferred font code in src/dillo.cc. > > The other day, I put a few minutes into setting, e.g., > FL_HELVETICA to prefs.font_sans_serif > FL_HELVETICA_BOLD to prefs.font_sans_serif " bold" > etc. > ..which seemed to be working for XFT but not with it disabled. Maybe the > latter wanted the -*-*-*-*-style strings, and I'd meant to ask Johannes > whether this was all the right direction to go in, anyway, since he'd done > the fonts work in dw/ for this port. I just committed something to get the preferred font stuff working on fltk-1.3. Please give it a try. Cheers, Johannes

June 6, 2011

Development schedule for version 1.3

by rf.opensource＠gmail.com

On Sun, Jun 5, 2011 at 3:08 PM, corvid <corvid(a)lavabit.com> wrote: > reza wrote: > > It seems that FLTK will release their final 1.3 version next week on June > > 8th. Are we waiting on that to release our own dillo 1.3? The reason I'm > > asking is that as you know I'm preparing an installable Mac OS package, > > which I hope to go on dillo's download page (and hopefully introduce > dillo > > to many non-developer users). So I'd like to know if we are just waiting > on > > that final release of FLTK 1.3, or whether there are still open bugs > > remaining for our next release? > > Right now, I'm aware of: > > - the preferred font code in src/dillo.cc. > > The other day, I put a few minutes into setting, e.g., > FL_HELVETICA to prefs.font_sans_serif > FL_HELVETICA_BOLD to prefs.font_sans_serif " bold" > etc. > ..which seemed to be working for XFT but not with it disabled. Maybe the > latter wanted the -*-*-*-*-style strings, and I'd meant to ask Johannes > whether this was all the right direction to go in, anyway, since he'd done > the fonts work in dw/ for this port. > > - tab titles > > Just cosmetic issues of: They seem too short, the original title of, e.g., > ctab5, is suboptimal, and the ones without a title tag are initially blank. > > - Still missing is the -f command line option (used by claws). > > Jorge was waiting for something to do with FLTK before taking action there. > > > Do we have features/bugs for each milestone documented anywhere? http://www.dillo.org/Plans.html is a bit too high level. What comes after 1.3? P.S. Are we going to call Dillo with FLTK1.3 as Dillo3? One problem is that on the surface nothing has changed from Dillo2, so users will probably get confused. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

June 5, 2011

Development schedule for version 1.3

by Johannes.Hofmann＠gmx.de

On Sun, Jun 05, 2011 at 08:08:15PM +0000, corvid wrote: > reza wrote: > > It seems that FLTK will release their final 1.3 version next week on June > > 8th. Are we waiting on that to release our own dillo 1.3? The reason I'm > > asking is that as you know I'm preparing an installable Mac OS package, > > which I hope to go on dillo's download page (and hopefully introduce dillo > > to many non-developer users). So I'd like to know if we are just waiting on > > that final release of FLTK 1.3, or whether there are still open bugs > > remaining for our next release? > > Right now, I'm aware of: > > - the preferred font code in src/dillo.cc. > > The other day, I put a few minutes into setting, e.g., > FL_HELVETICA to prefs.font_sans_serif > FL_HELVETICA_BOLD to prefs.font_sans_serif " bold" > etc. > ..which seemed to be working for XFT but not with it disabled. Maybe the > latter wanted the -*-*-*-*-style strings, and I'd meant to ask Johannes > whether this was all the right direction to go in, anyway, since he'd done > the fonts work in dw/ for this port. I already played with using the Platform::fontExists() interface here, but it somehow didn't work immediately and I got distracted... I can take another look at it. Cheers, Johannes

June 5, 2011

Development schedule for version 1.3

by corvid＠lavabit.com

reza wrote: > It seems that FLTK will release their final 1.3 version next week on June > 8th. Are we waiting on that to release our own dillo 1.3? The reason I'm > asking is that as you know I'm preparing an installable Mac OS package, > which I hope to go on dillo's download page (and hopefully introduce dillo > to many non-developer users). So I'd like to know if we are just waiting on > that final release of FLTK 1.3, or whether there are still open bugs > remaining for our next release? Right now, I'm aware of: - the preferred font code in src/dillo.cc. The other day, I put a few minutes into setting, e.g., FL_HELVETICA to prefs.font_sans_serif FL_HELVETICA_BOLD to prefs.font_sans_serif " bold" etc. ..which seemed to be working for XFT but not with it disabled. Maybe the latter wanted the -*-*-*-*-style strings, and I'd meant to ask Johannes whether this was all the right direction to go in, anyway, since he'd done the fonts work in dw/ for this port. - tab titles Just cosmetic issues of: They seem too short, the original title of, e.g., ctab5, is suboptimal, and the ones without a title tag are initially blank. - Still missing is the -f command line option (used by claws). Jorge was waiting for something to do with FLTK before taking action there.

June 5, 2011

Ignore a command line option (for Mac OS bundles)

by obeythepenguin＠gmail.com

On Sun, 05 Jun 2011 15:54:56 -0400, corvid <corvid(a)lavabit.com> wrote: > reza wrote: >> Now most of the plugins seem to work, at least bookmarks work fine. >> >> There is still a problem remaining though. In the target machine, I >> cannot >> open sites that require SSL (for example www.gmail.com, >> mail.yahoo.com) I'm >> not sure why it happens. Is there any library that helps in SSL >> connections >> that I forgot copying over? > > openssl? libssl and libcrypto (and Dillo needs to be compiled with --enable-ssl) ~Benjamin

June 5, 2011

Ignore a command line option (for Mac OS bundles)

by corvid＠lavabit.com

reza wrote: > Now most of the plugins seem to work, at least bookmarks work fine. > > There is still a problem remaining though. In the target machine, I cannot > open sites that require SSL (for example www.gmail.com, mail.yahoo.com) I'm > not sure why it happens. Is there any library that helps in SSL connections > that I forgot copying over? openssl?

June 5, 2011

Development schedule for version 1.3

by rf.opensource＠gmail.com

Hi guys, It seems that FLTK will release their final 1.3 version next week on June 8th. Are we waiting on that to release our own dillo 1.3? The reason I'm asking is that as you know I'm preparing an installable Mac OS package, which I hope to go on dillo's download page (and hopefully introduce dillo to many non-developer users). So I'd like to know if we are just waiting on that final release of FLTK 1.3, or whether there are still open bugs remaining for our next release? Thanks, Reza

June 5, 2011

Ignore a command line option (for Mac OS bundles)

by rf.opensource＠gmail.com

On Sun, Jun 5, 2011 at 11:31 AM, corvid <corvid(a)lavabit.com> wrote: > > I could use a bit of advice though. In my preliminary experiments, > > I'm having a bit of problem with the dpi related dynamic libraries. > > I can get dillo to run on another machine with libpng, libjpeg and > > zlib copied over to /usr/local/lib, but none of the plugins work. I > > have copied the usr/local/lib/dillo folder too, and also > > /usr/local/bin/dpid and /usr/local/bin/dpic, but still the plugins > > do not work in the target system. Any files I forgot to copy over? > > How about dpidrc? > > > Thanks, yes it works. I had forgotten the following: /usr/local/etc/dillo/dillorc /usr/local/etc/dillo/dpidrc /usr/local/etc/dillo/ Now most of the plugins seem to work, at least bookmarks work fine. There is still a problem remaining though. In the target machine, I cannot open sites that require SSL (for example www.gmail.com, mail.yahoo.com) I'm not sure why it happens. Is there any library that helps in SSL connections that I forgot copying over? BTW, I tried following Makefile to see what happens for make install, but since it is autogenerated by autoconf it's a bit too complex to follow manually :(

June 5, 2011

Table::addCell() leak

by corvid＠lavabit.com

http://starurchin.org/dillo/valgrind/10ca58f617a0693638facdb40bcf319af1bdfc… has a leak at dw/table.cc:323, and I found a way to trigger it: <table border=2> <tr><td>first<td rowspan=2>tall<td>third <tr><td colspan=2>wide<td>last </table> Jorge, you might remember a little something about tables. Can we simply check children->get() before putting anything there, or do we have to fix things somewhere if part of a span is stolen away?

June 5, 2011

Ignore a command line option (for Mac OS bundles)

by rf.opensource＠gmail.com

On Sat, Jun 4, 2011 at 5:19 PM, corvid <corvid(a)lavabit.com> wrote: > reza wrote: > > I'm trying to create a Mac OS executable bundle for dillo. This will be > > immensely helpful in increasing the reach of dillo to Mac users, as > majority > > of them shudder and run away when they hear they have to download, > (compile > > and) install the following: > > > > 1. Xcode 3 (which is a 4GB download!) > > 2. FLTK > > 3. libjpeg > > 4. libpng > > 5. zlib > > > > I've so far managed to cross compile both 32 bit and 64 bit binaries of > > dillo (same with fltk, libjpeg, libpng, zlib), create a bundle (which > fixes > > the icon problem) and almost get it to run on another machine. I have a > > small problem however and can use some help. > > > > It turns out Mac OS passes a command line argument to applications when > it > > runs them as a bundle. The command line option is something like > > -psn_0_25790615, where the latter part of the number is different in each > > run. Dillo of course freaks out when it sees it, prints out the help text > > (correct usage and whatnot) and exits. > > > > Can you please add a case to the command line parsing code to ignore an > > option if it includes text "-psn_0"? I could give it a shot but chances > are > > I'll break something else. Something like this should work: > > > > if (string(argv[1]).find("-psn_") == 0) { > > _MSG("Apparently a mac bundle", 0); > > _MSG(argv[1], 0); > > //ignore this option and move to the next; > > > > (Code sample from > > > https://svn.janelia.org/penglab/projects/v3d/trunk/v3d_main/v3d/v3d_command… > ) > > Perhaps a relatively clean solution would be for you to have a wrapper -- > whatever the moral equivalent of a shell script might be under these > circumstances -- that removes the argument and then calls Dillo. > > > Unfortunately by the time the first executable of the bundle (my script) gets to run, the current working directory is somehow reset to /, and I don't know how to retrieve the runtime bundle directory. I still think that my suggested solution is an easier one to implement without wrestling with the Mac OS bundle execution policy, even though I concur your solution is more elegant. _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

June 5, 2011

Ignore a command line option (for Mac OS bundles)

by corvid＠lavabit.com

reza wrote: > I'm trying to create a Mac OS executable bundle for dillo. This will be > immensely helpful in increasing the reach of dillo to Mac users, as majority > of them shudder and run away when they hear they have to download, (compile > and) install the following: > > 1. Xcode 3 (which is a 4GB download!) > 2. FLTK > 3. libjpeg > 4. libpng > 5. zlib > > I've so far managed to cross compile both 32 bit and 64 bit binaries of > dillo (same with fltk, libjpeg, libpng, zlib), create a bundle (which fixes > the icon problem) and almost get it to run on another machine. I have a > small problem however and can use some help. > > It turns out Mac OS passes a command line argument to applications when it > runs them as a bundle. The command line option is something like > -psn_0_25790615, where the latter part of the number is different in each > run. Dillo of course freaks out when it sees it, prints out the help text > (correct usage and whatnot) and exits. > > Can you please add a case to the command line parsing code to ignore an > option if it includes text "-psn_0"? I could give it a shot but chances are > I'll break something else. Something like this should work: > > if (string(argv[1]).find("-psn_") == 0) { > _MSG("Apparently a mac bundle", 0); > _MSG(argv[1], 0); > //ignore this option and move to the next; > > (Code sample from > https://svn.janelia.org/penglab/projects/v3d/trunk/v3d_main/v3d/v3d_command…) Perhaps a relatively clean solution would be for you to have a wrapper -- whatever the moral equivalent of a shell script might be under these circumstances -- that removes the argument and then calls Dillo.

June 5, 2011

Ignore a command line option (for Mac OS bundles)

by rf.opensource＠gmail.com

I'm trying to create a Mac OS executable bundle for dillo. This will be immensely helpful in increasing the reach of dillo to Mac users, as majority of them shudder and run away when they hear they have to download, (compile and) install the following: 1. Xcode 3 (which is a 4GB download!) 2. FLTK 3. libjpeg 4. libpng 5. zlib I've so far managed to cross compile both 32 bit and 64 bit binaries of dillo (same with fltk, libjpeg, libpng, zlib), create a bundle (which fixes the icon problem) and almost get it to run on another machine. I have a small problem however and can use some help. It turns out Mac OS passes a command line argument to applications when it runs them as a bundle. The command line option is something like -psn_0_25790615, where the latter part of the number is different in each run. Dillo of course freaks out when it sees it, prints out the help text (correct usage and whatnot) and exits. Can you please add a case to the command line parsing code to ignore an option if it includes text "-psn_0"? I could give it a shot but chances are I'll break something else. Something like this should work: if (string(argv[1]).find("-psn_") == 0) { _MSG("Apparently a mac bundle", 0); _MSG(argv[1], 0); //ignore this option and move to the next; (Code sample from https://svn.janelia.org/penglab/projects/v3d/trunk/v3d_main/v3d/v3d_command…) Thanks, Reza

June 4, 2011

Invitation to connect on LinkedIn

by sdliyong＠gmail.com

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Yong Yong Li platform software engineer at Hewlett-Packard China Confirm that you know Yong Li https://www.linkedin.com/e/m1sm8i-gofifhm7-1e/isd/2018522004/2K69vPKA/ -- (c) 2011, LinkedIn Corporation

June 2, 2011

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

Concurrency bugs are the worst type, thinking about it I can't think of a harder to debug class of bugs. Kudos for finding the bug 5 years ago in linux flyk, and double kudos for relating this one back to the old bug. -Reza On Jun 1, 2011, at 11:53 AM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Wed, Jun 01, 2011 at 03:47:32PM +0000, corvid wrote: >> >> How do you think that bug eluded detection for so many years? >> I was very surprised by it all... > > I) Very special conditions are necessary to trigger the bug, so > the code works for most cases, hiding the bug (e.g. the test case > in fltk works). > > It is a race condition where you need: > > - Multiple file descriptors being watched. > - Some of them being closed while others remain in activity. > - The closing being in such a way that the fd with the higher > number is closed before the others. > > > and on top of it there's also a semantic problem, which is very > hard to spot while reviewing the code: > > [in remove_fd():] > ... > if (n == _maxfd) _maxfd--; > ... > > It looks quite correct, but a callback may be pending in > the queue, and if so, it will not be honoured. > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

June 2, 2011