June 2008 - Dillo-dev - lists.mailman3.com

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 06:04:07PM +0200, Johannes Hofmann wrote: > On Thu, Jun 05, 2008 at 10:43:36PM +0000, corvid wrote: > > Johannes wrote: > > > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > > > I've seen occasional segfaults in recent weeks, and > > > > twice now I've been able to catch them when I remembered > > > > to have gdb going (and, well, zero times when I remembered > > > > to have ulimit -c unlimited) > > > > > > I had some of these segfaults too. > > > > > > > These two have been nearly identical. Here's the one I just got: > > > > > > > > #0 0x00000048 in ?? () > > > > #1 0x080aa74e in dw::core::Layout::removeFont (this=0x815ca58, > > > > attrs=0x81dfc08) at layout.hh:253 > > > > #2 0x080a8f07 in dw::core::style::Font::remove (this=0x81dfc08, > > > > layout=0x815ca58) at style.cc:287 > > > > #3 0x080aa85a in dw::core::style::Font::unref (this=0x81dfc08, > > > > layout=0x815ca58) at style.hh:587 > > > > #4 0x080aa042 in ~Style (this=0x81d8680) at style.cc:204 > > > > #5 0x0805b123 in dw::core::style::Style::unref (this=0x81d8680) > > > > at style.hh:505 > > > > #6 0x08089359 in ~Textblock (this=0x8249308) at textblock.cc:96 > > > > #7 0x080a52e7 in dw::core::Layout::setWidget (this=0x822f868, > > > > widget=0x827b3b0) at layout.cc:175 > > > > #8 0x0805aea8 in a_Web_dispatch_by_type ( > > > > Type=0x827c480 "text/html; charset=UTF-8", Web=0x824ebc0, Call=0x821d320, > > > > Data=0x821d324) at web.cc:94 > > [snip] > > > > My guess at the problem: > > > > StyleTable will give you back whatever Style matches your attrs, > > > > but maybe that Style was created with a different layout. > > > > > > > > > > I will have a look at that. Maybe the StyleTable should be > > > associated with a layout too. > > > > It looks like style uses layout to get to platform. I wonder whether > > it would go against any dw rules to let style have platform. > > > > My problem is that I don't understand why fontsTable and > colorsTable need to be platform specific in the first place. > As long as their members match they should be sharable - even > if they are used for different platforms. > > I would just make them static members of Font and Color > respectively. That way we would no longer need the layout parameter > in the *::create methods. To make clear what I mean, here comes the patch: http://www.ecademix.com/JohannesHofmann/tmp/layoutless_style.dw2 http://www.ecademix.com/JohannesHofmann/tmp/layoutless_style.dillo2 (they are too large for the list). I'm not sure why Sebastian avoided that possiblity. Maybe the virtual destructors which are needed in this implementation? Comments welcome! I feel a bit uncomfortable proposing a pretty drastic change like this. Cheers, Johannes

June 7, 2008

should zlib be required?

by weigelt＠metux.de

* Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > On Sat, Jun 07, 2008 at 09:33:51PM +0200, Enrico Weigelt wrote: > > If Dillo requires zlib by itself, it should import it propery > > (eg. via pkg-config). > > ...and since when does zlib provide any pkg-config glue? The OSS-QM branch does for quite a long time, and uptream has signalled to include my patch. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

Future of dillo2

by weigelt＠metux.de

* Jorge Arellano Cid <jcid(a)dillo.org> schrieb: Hi, > i. - Increase the development team by adding 6+ new developers. > ii.- Getting more involved with other projects. you can add me, as long as no C++ stuff is involved. (don't like it's overhead). I'm already working on German translation. > * Planning for CSS, floating objects and TABS. > (this are important features to a nice browsing experience) Missing CSS is really bad. I'm planning to write an universal but small CSS parser (as an separate library). cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

should zlib be required?

by joerg.sonnenberger＠web.de

On Sat, Jun 07, 2008 at 09:33:51PM +0200, Enrico Weigelt wrote: > If Dillo requires zlib by itself, it should import it propery > (eg. via pkg-config). ...and since when does zlib provide any pkg-config glue? Joerg

June 7, 2008

should zlib be required?

by weigelt＠metux.de

* corvid <corvid(a)lavabit.com> schrieb: > Should zlib be required? > > I notice that testing for zlib is currently just a part of > deciding whether to enable png. I either need to make configure.in > require it, or make zlib optional with some ifdefs. libpng's zlib-dependency is not Dillo's business. So you should fix configure.in to properly call pkg-config (this was the first thing I did in my branch) If Dillo requires zlib by itself, it should import it propery (eg. via pkg-config). cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

RFC: removing the search dialog

by weigelt＠metux.de

* corvid <corvid(a)lavabit.com> schrieb: > Justus wrote: > > I hacked up opera (at least I _think_ they do it this way) style search > > engine handling. > > In my dream world, web browsers would have command lines instead of > location bars. That would be really cool. A few days ago I thought of something like that for Gimp: * all important objects are made accessible via 9P * an shell (eg. bash) is extended to support 9P directly * an special terminal (eg. via splitvt) runs both shell and some status like app * user commands can be easily written as shellscript functions cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

RFC: removing the search dialog

by weigelt＠metux.de

* Justus Winter <4winter(a)informatik.uni-hamburg.de> schrieb: Hi, > I hacked up opera (at least I _think_ they do it this way) style search > engine handling. I am not too happy with what I did to the config file > parser, but it works for now :). The parser is beautiful in its > simplicity, but it has its limitations (like not being able to handle > dictionaries). What exactly do you mean w/ "dictionaries" ? An list of values ? Then simply use an extra text file. I'm currently developing an tiny desktop environment for unexperienced users and there I often need hierachical config data (even w/ binary content). The filesystem (plus atoi()+friends) is completely enough for that purpose. Can't imagine anything simpler ;-P All filesystem access runs through my userland vfs library, libmvfs. So it's trivial to use other datasources than the local fs, eg. via 9P. > I am not sure what I would like to see, but for the moment I'd go with > dictionaries and the ability to include other files. Includes and macros can be easily done via cpp. > I was also unsure about the proper way to inform the user of errors and > I believe the reason for this is simply that there is no mechanism to do > this properly. > > I am thinking about using the browser widget to render error pages like > most of the mainstream browsers. Any thoughts on this one? Isn't an simple popup window enough ? <snip> > +# The syntax is > +# > +# search_url="<id>|<url>" > +# > +# This sets the search URL to use with "<id> <keywords>". > +# %s in the URL is replaced with keywords separated by '+'. > + > +search_url="g|http://www.google.com/search?q=%s" > +search_url="ly|http://search.lycos.com/default.asp?query=%s" > +search_url="aw|http://www.alltheweb.com/search?cat=web&query=%s" > +search_url="y|http://search.yahoo.com/search?p=%s" > +search_url="l|http://localhost/cgi-bin/htsearch?words=%s" > +search_url="cc|http://search.creativecommons.org/?q=%s" > +search_url="d|http://www.dict.cc/?s=%s" I'd prefer to have this in an extra file. Separation via whitespace seems to convenient to me. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

Executing commands via URL

by weigelt＠metux.de

Hi folks, I'd like to use Dillo for an help system and control center on an end-user desktop appliance. Therefore I need it to execute certain commands. But Dillo itself should not fork/exec itself, instead send the commands to some special daemon via an 9P channel. An simple approach could be coding an dpi which just parses the requested URL and sends the actual command to the exec server through 9P. But I have to make absolutely sure that commands can only be sent when coming from certain pages. How can I achieve this ? thx -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 04:34:04PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Jun 05, 2008 at 10:43:36PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > > > > I've seen occasional segfaults in recent weeks, and > > > > > twice now I've been able to catch them when I remembered > > > > > to have gdb going (and, well, zero times when I remembered > > > > > to have ulimit -c unlimited) > > > > > > > > I had some of these segfaults too. > > > > > > > > > These two have been nearly identical. Here's the one I just got: > > > > > > > > > > #0 0x00000048 in ?? () > > > > > #1 0x080aa74e in dw::core::Layout::removeFont (this=0x815ca58, > > > > > attrs=0x81dfc08) at layout.hh:253 > > > > > #2 0x080a8f07 in dw::core::style::Font::remove (this=0x81dfc08, > > > > > layout=0x815ca58) at style.cc:287 > > > > > #3 0x080aa85a in dw::core::style::Font::unref (this=0x81dfc08, > > > > > layout=0x815ca58) at style.hh:587 > > > > > #4 0x080aa042 in ~Style (this=0x81d8680) at style.cc:204 > > > > > #5 0x0805b123 in dw::core::style::Style::unref (this=0x81d8680) > > > > > at style.hh:505 > > > > > #6 0x08089359 in ~Textblock (this=0x8249308) at textblock.cc:96 > > > > > #7 0x080a52e7 in dw::core::Layout::setWidget (this=0x822f868, > > > > > widget=0x827b3b0) at layout.cc:175 > > > > > #8 0x0805aea8 in a_Web_dispatch_by_type ( > > > > > Type=0x827c480 "text/html; charset=UTF-8", Web=0x824ebc0, Call=0x821d320, > > > > > Data=0x821d324) at web.cc:94 > > > [snip] > > > > > My guess at the problem: > > > > > StyleTable will give you back whatever Style matches your attrs, > > > > > but maybe that Style was created with a different layout. > > > > > > > > > > > > > I will have a look at that. Maybe the StyleTable should be > > > > associated with a layout too. > > > > > > It looks like style uses layout to get to platform. I wonder whether > > > it would go against any dw rules to let style have platform. > > > > > > > My problem is that I don't understand why fontsTable and > > colorsTable need to be platform specific in the first place. > > As long as their members match they should be sharable - even > > if they are used for different platforms. > > > > I would just make them static members of Font and Color > > respectively. That way we would no longer need the layout parameter > > in the *::create methods. > > > > What am I missing here? > > I may be wrong here, but I think the idea is that the colors or fonts > in the tables are currently FltkColor/FltkFont, but they could in principle > be mixed together with ones from another toolkit. Yes, I also read the comment in platform.hh about Style Resources. But still, if every implementation of Font or Color would handle its caching on its own with a static hash table, it should still work. If there should be a GtkFont class some day, it would have its own static hash table. I would rather see the need for a Font factory in platform that creates the right sort of Font for that platform. > > Hmm. I wonder whether it would break anything to change > a_UIcmd_browser_window_new() to have a single static FltkPlatform... Yeah, I thought about that too. I think apart from the current delete platform; in the Layout destructor that should work. And we could delete platfrom at the level where it was created. But all the platform stuff is difficult to understand as we currently only have one.

June 7, 2008

recent style/layout segfaults

by corvid＠lavabit.com

Johannes wrote: > On Thu, Jun 05, 2008 at 10:43:36PM +0000, corvid wrote: > > Johannes wrote: > > > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > > > I've seen occasional segfaults in recent weeks, and > > > > twice now I've been able to catch them when I remembered > > > > to have gdb going (and, well, zero times when I remembered > > > > to have ulimit -c unlimited) > > > > > > I had some of these segfaults too. > > > > > > > These two have been nearly identical. Here's the one I just got: > > > > > > > > #0 0x00000048 in ?? () > > > > #1 0x080aa74e in dw::core::Layout::removeFont (this=0x815ca58, > > > > attrs=0x81dfc08) at layout.hh:253 > > > > #2 0x080a8f07 in dw::core::style::Font::remove (this=0x81dfc08, > > > > layout=0x815ca58) at style.cc:287 > > > > #3 0x080aa85a in dw::core::style::Font::unref (this=0x81dfc08, > > > > layout=0x815ca58) at style.hh:587 > > > > #4 0x080aa042 in ~Style (this=0x81d8680) at style.cc:204 > > > > #5 0x0805b123 in dw::core::style::Style::unref (this=0x81d8680) > > > > at style.hh:505 > > > > #6 0x08089359 in ~Textblock (this=0x8249308) at textblock.cc:96 > > > > #7 0x080a52e7 in dw::core::Layout::setWidget (this=0x822f868, > > > > widget=0x827b3b0) at layout.cc:175 > > > > #8 0x0805aea8 in a_Web_dispatch_by_type ( > > > > Type=0x827c480 "text/html; charset=UTF-8", Web=0x824ebc0, Call=0x821d320, > > > > Data=0x821d324) at web.cc:94 > > [snip] > > > > My guess at the problem: > > > > StyleTable will give you back whatever Style matches your attrs, > > > > but maybe that Style was created with a different layout. > > > > > > > > > > I will have a look at that. Maybe the StyleTable should be > > > associated with a layout too. > > > > It looks like style uses layout to get to platform. I wonder whether > > it would go against any dw rules to let style have platform. > > > > My problem is that I don't understand why fontsTable and > colorsTable need to be platform specific in the first place. > As long as their members match they should be sharable - even > if they are used for different platforms. > > I would just make them static members of Font and Color > respectively. That way we would no longer need the layout parameter > in the *::create methods. > > What am I missing here? I may be wrong here, but I think the idea is that the colors or fonts in the tables are currently FltkColor/FltkFont, but they could in principle be mixed together with ones from another toolkit. Hmm. I wonder whether it would break anything to change a_UIcmd_browser_window_new() to have a single static FltkPlatform...

June 7, 2008