- Dillo-dev - lists.mailman3.com

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

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

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? Cheers, Johannes > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

June 7, 2008

another segfault

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 02:24:09PM +0000, corvid wrote: > Johannes wrote: > > now I've got some more info on that problem. The buffer on which > > Html_write_raw is operating (0x285c8000 in this case) is free'd by > > a_Cache_set_content_type(). I don't understand the details though. > > Do you have an idea? > > Ah! Does this help? > Yes, it does. Excellent! Johannes

June 7, 2008

another segfault

by corvid＠lavabit.com

Johannes wrote: > now I've got some more info on that problem. The buffer on which > Html_write_raw is operating (0x285c8000 in this case) is free'd by > a_Cache_set_content_type(). I don't understand the details though. > Do you have an idea? Ah! Does this help?

June 7, 2008

another segfault

by Johannes.Hofmann＠gmx.de

Hi, now I've got some more info on that problem. The buffer on which Html_write_raw is operating (0x285c8000 in this case) is free'd by a_Cache_set_content_type(). I don't understand the details though. Do you have an idea? (gdb) bt #0 dFree (mem=0x285c8000) at dlib.c:59 #1 0x08071ae7 in dStr_free (ds=0x285c0ed0, all=677150720) at dlib.c:291 #2 0x08058ef1 in a_Cache_set_content_type (url=0x28539500, ctype=0x285d2000 "text/html; charset=us-asci i", force=0 '\0') at cache.c:499 #3 0x08061a82 in Html_tag_open_meta (html=0x28689e00, tag=0x285c80a5 "<META http-equiv=\"Content-Type\" content=\"text/html; charset=us-ascii\">\n </HEAD >\n <BODY BGCOLOR=\"#ffffff\">\n <h1>The Mercurial Archives </h1>\n <p>\n You can get <a h ref=\"http://selenic.com"..., tagsize=70) at html.cc:3995 #4 0x080616c4 in Html_write_raw (html=0x28689e00, buf=0x285c8000 "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2//EN\">\n<HTML>\n <HEAD>\n <title>T he Mercurial Archives</title>\n <META NAME=\"robots\" CONTENT=\"noindex,follow\">\n <META http-e quiv=\"Content-Type\" con"..., bufsize=1119, Eof=0) at html.cc:5653 #5 0x08061af1 in DilloHtml::write (this=0x28689e00, Buf=0x285c8000 "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2//EN\">\n<HTML>\n <HEAD>\n <title>T he Mercurial Archives</title>\n <META NAME=\"robots\" CONTENT=\"noindex,follow\">\n <META http-e quiv=\"Content-Type\" con"..., BufSize=675443204, Eof=0) at html.cc:967 #6 0x080621ba in Html_callback (Op=0, Client=0x28549bc0) at html.cc:5883 #7 0x08058433 in Cache_process_queue (entry=0x285d4200) at cache.c:1075 #8 0x08058d98 in a_Cache_process_dbuf (Op=0, buf=0x285a1000 "HTTP/1.1 200 OK\r\nDate: Sat, 07 Jun 2008 09:35:46 GMT\r\nServer: Apache/1.3.34 (Deb ian) PHP/4.4.4-8+etch6 mod_ssl/2.8.25 OpenSSL/0.9.8c\r\nLast-Modified: Sat, 07 Jun 2008 08:24:59 GMT\r\n ETag: \"271005-41b5-4"..., buf_size=1440, Url=0x28539800) at cache.c:871 #9 0x0805650c in a_Chain_fcb (Op=675443204, Info=0x0, Data1=0x285c0340, Data2=0x80eb382) at chain.c:111 #10 0x08074440 in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x285490c0, Data1=0x2848d5f0, Data2=0x0) at dpi .c:223 #11 0x0805650c in a_Chain_fcb (Op=675443204, Info=0x0, Data1=0x2848d5f0, Data2=0x0) at chain.c:111 #12 0x08074d61 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x28549ac0, Data1=0x285497c0, Data2=0x0) at IO.c :418 #13 0x08074eee in IO_callback (fd=<value optimized out>, io=0x285497c0) at IO.c:205 #14 0x08074fc7 in IO_fd_read_cb (fd=7, data=0xc) at IO.c:291 #15 0x080c2869 in fltk::wait () #16 0x080c2a19 in fltk::run () #17 0x0804e63d in main (argc=0, argv=0x0) at dillo.cc:125 (gdb) Cheers, Johannes

June 7, 2008