Re: [Dillo-dev]authentification From: Alexey F. Bekish - 2001-05-31 17:09 How from all it nsubscribe???? ----- Original Message ----- From: "Didier Bretin" To: Sent: Thursday, May 31, 2001 6:32 PM Subject: [Dillo-dev]authentification > Hello, > > Dillo looks good :o). Go on !!!! > Have you planned to deal with authentification ? > > Regards > -- > .------------------------------------------------. > .^. | Didier Bretin, France | dbr@in... | > /V\ |-----------------------| http://www.informactis.com | > // \\ | `------------------------| > /( )\ | Visit: http://www.linuxfr.org/ | > ^^-^^ `------------------------------------------------' > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@li... > http://lists.so....net/lists/listinfo/dillo-dev > [Dillo-dev]authentification From: Didier Bretin - 2001-05-31 14:32 Hello, Dillo looks good :o). Go on !!!! Have you planned to deal with authentification ? Regards -- .------------------------------------------------. .^. | Didier Bretin, France | dbr@in... | /V\ |-----------------------| http://www.informactis.com | // \\ | `------------------------| /( )\ | Visit: http://www.linuxfr.org/ | ^^-^^ `------------------------------------------------' [Dillo-dev]0.5.1 release From: Jorge Arellano Cid - 2001-05-30 18:40 Hi! dillo-0.5.1 is ready for download! Note that this version doesn't have tables (delayed to 0.6.0), but it carries a bunch of enhancements that make it worth a download. Good luck Jorge.- Re: [Dillo-dev]Tables! From: Sebastian Geerken - 2001-05-28 14:59 On Sun, May 27, I wrote: > [...] > A major bug is that image maps often don't work, there will > have to be some changes in the structure of DwPage and DilloHtml (see > my posting "Image Maps" some weeks ago), this is what I'll do next. Oh, and the find function does not work, it has to search recursively. Another reason to deactivate tables ... :-( Sebastian [Dillo-dev]Tables! From: Sebastian Geerken - 2001-05-27 11:07 Hi all. A first version of table implementation is in the CVS! As promised, it is completely incremental, no waiting for huge-page-layout-tables is necessary. It is still incomplete, especially borders, colors etc. are not supported at all, read the comments at the beginning of dw_table.c. Furthermore, there are few pages which do not render as expected. A major bug is that image maps often don't work, there will have to be some changes in the structure of DwPage and DilloHtml (see my posting "Image Maps" some weeks ago), this is what I'll do next. All table parsing is currently done within #ifdef directives, so you can simply deactivates tables by commenting the line "#define USE_TABLES" at the beginning of html.c. Sebastian [Dillo-dev]M17n (was: Re: Hi.) From: Sebastian Geerken - 2001-05-26 11:16 On Fri, May 25, Jorge Arellano Cid wrote: > [...] > Some time ago, I received a small patch to enable Korean!, but > it required a True Type X server, and the proper fonts intalled. > Most probably it doesn't work with forms. The patch won't work for dillo >= 0.5.0. You'll have to change Dw_style_font_realize in dw_style.c. It should be simple to adjust, but I cannot test it since I only have latin fonts installed. > [...] > Dillo is small browser, and adding support for every single > posibility is certainly not its goal. When it comes to character > sets, the situation is: if there's a simple way of supporting at > least a certain range, it will most probably be done. Since Gtk+ 2.0 depends anyway on Pango, there should be no problem to use it. I haven't looked at it at all, but as I've understood, Gtk+ 2.0 plus Pango will provide an abstraction layer to handle all problems (encoding, rendering, text direction etc.) as simple as possible. There are some changes necessary, perhaps in the html parser, and definitely in the rendering (e.g. text directions). My first idea is to use Pango as much as possible, and otherwise, copy ideas from Pango and Gtk+ 2.0. BTW, there is Gtk+ 1.3, which is (AFAIK) feature frozen, so you can already start with it. Sebastian Re: [Dillo-dev]Hi. From: Jorge Arellano Cid - 2001-05-25 18:37 Hi folks! On Wed, 23 May 2001, Michael Govorun wrote: > > > > I'm Korean. Do you know Korea? > > > Korea is in asia. > > > Of course, my charset is 'euc-kr' > > > It is 2 byte. > > Hi, I'm Russian. Of course, I'm not using 2-byte charset, but I'm also > interesting in ability to work with international content in Dillo. > > I made some minor changes to Dillo and it work nicely with most of > russian sites. But all of my changes are hacks. There has to be more > universal scheme. Yes, probably the best solution is to write a single universal solution for it. Character encoding is not a simple matter, and very often becomes a nightmare in e-mail. I tend to think as Sebastian, and let the lower layers or libraries handle the problem. As you can see, GTK will work with Pango someday... An although I'm not an expert in character encodings, it seems that sometimes a True Type enabled X server is also required for some fonts. I've also had problems with Netscape on Japanese sites! And I don't want to bundle dillo with a huge font set as the do... > What I did: > > 1. First of all, I've inserted "Accept-Charset: koi8-r" in request > headers. After that step most of russian sites gives me pages in > koi8-r. > > 2. I have koi8-r fonts installed in X before others and Dillo renders > good russian text for me. > > 3. I encounter a problem inputing russian text in forms. Then I've > inserted gtk_set_locale(); before gtk_init(&argc, &argv); > in main(). And it works for me. > > But there is some problems at least with russian sites: > A. Some sites sending windows-1251 pages despite of my Accept-Charset > and such behavior is not RFC violation. > B. There is some broken sites sending me pages with charset not > corresponding to specified one. Many russian sites not specify > charset at all. > C. In russia we have more than 5 different charsets and (in theory) > each can be used by web-server. Oh. Some time ago, I received a small patch to enable Korean!, but it required a True Type X server, and the proper fonts intalled. Most probably it doesn't work with forms. (The patch is appended to this mail, just in case it proves useful for someone. The author is Yong-iL Joh, and can be reached at: tolkien __ mizi.com. He wasn't very wordy when I asked though, but he pointed me to: http://www.li18nux.org/) :) > I'm not a gtk+ expert :( and just started to learn it (with problem > N3). Also I'm newbie in Linux C programming. And I had no C/C++ > programming practice for 3 years. (Last time PHP mostly). So I can't > solve all problems right now by myself quickly and in the best > universal way :( I believe the best way to go is, first, to check what GTK has to offer us (i.e. Pango), go there, read the docs, find out the whats and whys, and then reconsider the problem. In the short term, a hacked dillo may be the fastest solution. > Charset-related problems are not in "primary concerns" and not in > "Future Goals". What Dillo developers think about it? Just that! > Is it will be > easy to solve them in the future without reconstructing of Dillo > internals? I'm meaning all charsets, including CJK. Wouldn't it be > simplier to make some steps now? Or this question requires study? Dillo is small browser, and adding support for every single posibility is certainly not its goal. When it comes to character sets, the situation is: if there's a simple way of supporting at least a certain range, it will most probably be done. Jorge.- PS: patch follows: --- dillo.orig/src/dw_page.c Mon Mar 5 23:38:06 2001 +++ dillo/src/dw_page.c Tue Mar 13 12:23:34 2001 @@ -1403,12 +1403,12 @@ while (current && (font->font == NULL)) { comma = strchr(current, ','); if (comma) *comma = 0; - sprintf(fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-*-*", + sprintf(fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-*-*,-*-gulim-medium-*-*-*-12-*-*-*-*-*-ksc5601.1987-*", font->name, font->bold ? "bold" : "medium", font->italic ? ItalicChar : "r", font->size); - font->font = gdk_font_load(fontname); + font->font = gdk_fontset_load(fontname); if (comma) { current = comma + 1; @@ -1419,22 +1419,22 @@ g_free(name); if (font->font == NULL && font->italic) { - sprintf(fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-*-*", + sprintf(fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-*-*,-*-gulim-medium-*-*-*-12-*-*-*-*-*-ksc5601.1987-*", font->name, font->bold ? "bold" : "medium", (*ItalicChar == 'o') ? "i" : "o", font->size); - font->font = gdk_font_load(fontname); + font->font = gdk_fontset_load(fontname); } if (font->font == NULL) { /* Can't load the font - substitute the default instead. */ font->font = - gdk_font_load("-adobe-helvetica-medium-r-normal--*-100-*-*-*-*-*-*"); + gdk_fontset_load("-adobe-helvetica-medium-r-normal--*-100-*-*-*-*-*-*,-*-gulim-medium-*-*-*-12-*-*-*-*-*-ksc5601.1987-*"); } if (font->font == NULL) { /* Try another platform-font that should be available. (iPaq) */ font->font = - gdk_font_load("-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso8859-1"); + gdk_fontset_load("-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso8859-1,-*-gulim-medium-*-*-*-12-*-*-*-*-*-ksc5601.1987-*"); } if (font->font == NULL) { g_print("Can't load any fonts!\n"); [Dillo-dev]dillo 0.5.0 configure problem From: Finlay Dobbie - 2001-05-24 20:10 [ note: i am not subscribed to the list, any replies will have to go directly back to me :-) ] configure ignores with --with-jpeg-inc parameter. I have a tree of software inside /sw, and setting --with-jpeg-inc=/sw/include still doesn't find the headers. they ARE there. Also, it says *** disabling jpeg support, and goes ahead to compile it in anyways. it then dies with a link error later on because it didn't add -ljpeg to the linker flags. so, basically, 2 errors. 1) --with-jpeg-inc ignored, 2) jpeg support disablement doesn't actually work. my quick fix is this patch: diff -ru dillo-0.5.0/configure.in dillo-0.5.0-patched/configure.in --- dillo-0.5.0/configure.in Sat Apr 21 23:46:44 2001 +++ dillo-0.5.0-patched/configure.in Thu May 24 20:38:57 2001 @@ -48,10 +48,11 @@ if test -z "$LIBJPEG_LIB"; then AC_CHECK_LIB(jpeg, jpeg_destroy_decompress, jpeg_ok=yes, jpeg_ok=no AC_MSG_WARN(*** JPEG support will not be included ***)) - if test "$jpeg_ok" = yes; then - AC_CHECK_HEADERS(jpeglib.h jconfig.h jerror.h jmorecfg.h, - jpeg_ok=yes, jpeg_ok=no) - fi +dnl *** THIS IS BROKEN *** +dnl if test "$jpeg_ok" = yes; then +dnl AC_CHECK_HEADERS(jpeglib.h jconfig.h jerror.h jmorecfg.h, +dnl jpeg_ok=yes, jpeg_ok=no) +dnl fi AC_MSG_RESULT($jpeg_ok) if test "$jpeg_ok" = yes; then JPEG='jpeg'; LIBJPEG_LIB='-ljpeg' which then works, but that's of no use to you, obviously :) -- Finlay Re: [Dillo-dev]Which space is available in a table cell? From: Sebastian Geerken - 2001-05-23 13:24 Michael, I think I'll freeze the discussion at this point. I'll start with a simple implementation, which will halfway usable, and later check it for compliance with the HTML spec. In the future, "width" and "height" attributes will be equivalent to the CSS attributes, so I'll check this, too. But this will probably take a while. Thanks for your ideas. Sebastian Re: [Dillo-dev]Killed Bug #160 (memory leak detection) From: Sebastian Geerken - 2001-05-23 13:24 On Tue, May 22, Jorge Arellano Cid wrote: > This doesn't happen with cached images! So it is probably in > the DwPage code. It *does* also happen with plain text pages, so it could be either DwPage, or DwStyle (DwImage has no style when the URL is the image itself). I looked at all g_new, g_free, and friends in dw_page.c and dw_style.h, and fixed one leak in Dw_style_font_remove. Anything else seems ok, although there is no code opposed to gdk_color_alloc, but AFAIK, only X resources are allocated in this case. However, when I repeated the test with plain texts, the differences in memory usage remained the same, before and after the fix (Dw_style_font_remove was probably not called). Sebastian Re: [Dillo-dev]Hi. From: Kim Jonguk - 2001-05-23 13:23 On Wed, 23 May 2001, Michael Govorun wrote: > Hi, I'm Russian. Of course, I'm not using 2-byte charset, but I'm also > interesting in ability to work with international content in Dillo. > Nice to meet you. > I'm not a gtk+ expert :( and just started to learn it (with problem > N3). Also I'm newbie in Linux C programming. And I had no C/C++ > programming practice for 3 years. (Last time PHP mostly). So I can't > solve all problems right now by myself quickly and in the best > universal way :( You are better than me. I'm novice at gtk+ & os.. (I'm a FreeBSD user. I've heard FreeBSD is popuar in Russia. is it true?) I have no power. So, I request that dillo-developers take care of charset problem. Thank you very much. -- end. -- Kim Jonguk. Korea. /--) --- /_ --- Band Jinsil Leader. /___) ) /\ ) /_) Ajou Univ. CS. THiS. Re: [Dillo-dev]Hi. From: Michael Govorun - 2001-05-23 08:31 > > I'm Korean. Do you know Korea? > > Korea is in asia. > > Of course, my charset is 'euc-kr' > > It is 2 byte. Hi, I'm Russian. Of course, I'm not using 2-byte charset, but I'm also interesting in ability to work with international content in Dillo. I made some minor changes to Dillo and it work nicely with most of russian sites. But all of my changes are hacks. There has to be more universal scheme. What I did: 1. First of all, I've inserted "Accept-Charset: koi8-r" in request headers. After that step most of russian sites gives me pages in koi8-r. 2. I have koi8-r fonts installed in X before others and Dillo renders good russian text for me. 3. I encounter a problem inputing russian text in forms. Then I've inserted gtk_set_locale(); before gtk_init(&argc, &argv); in main(). And it works for me. But there is some problems at least with russian sites: A. Some sites sending windows-1251 pages despite of my Accept-Charset and such behavior is not RFC violation. B. There is some broken sites sending me pages with charset not corresponding to specified one. Many russian sites not specify charset at all. C. In russia we have more than 5 different charsets and (in theory) each can be used by web-server. Oh. I'm not a gtk+ expert :( and just started to learn it (with problem N3). Also I'm newbie in Linux C programming. And I had no C/C++ programming practice for 3 years. (Last time PHP mostly). So I can't solve all problems right now by myself quickly and in the best universal way :( Anyway I'm trying to expirement with charset recoding now. I've added charset pointer to DilloHtml struct. I wrote function for charset extraction from Content-Type header and I've inserted this extraction to a_Html_text(). Next version of Glib will contain g_convert() function for charset recoding. But now I'm using iconv(). I've inserted recoding to Html_write() function, only from windows-1251 to koi8-r. It works nicely. Now I recieved next problem with forms: some servers don't properly recode my input. > > > > I saw that dillo will be able to show us frame & table. > > but, I could not see that dillo will be able to show me multibyte > > characters. > > There is no font selection.... > > > > Can you help me? > > Personally, I'd like it if dillo could be able to render different > character sets, this will increase the amount of possible users quite > much :-). In Gtk+ 1.2, this is quite hard to implement, but Gtk+ 2.0 > will depend on the Pango library, which purpose is to handle all > different kinds of languages. I haven't taken a look at it yet, but I > think that using Pango is indeed an option. As I understand GTK+ 2.0 should come out before the end of the year. Is it true? Charset-related problems are not in "primary concerns" and not in "Future Goals". What Dillo developers think about it? Is it will be easy to solve them in the future without reconstructing of Dillo internals? I'm meaning all charsets, including CJK. Wouldn't it be simplier to make some steps now? Or this question requires study? -- -Michael Govorun [Dillo-dev]More leaks (Html linkblock) From: Livio Baldini Soares - 2001-05-23 06:36 Hello! I think I've found a couple of more of leaks in the html linkblock codes. The main problem is that html->linkblock isn't freed automatically (on Html_close), because the info for FORMS and their respective callbacks need to be around in case the form is used (i.e. clicked). On the other hand, they *do* need to be expunged at some time... After hours of experimenting a best solution, I think I've found a very stable and "clean" one. Also there was a small leak in Html_close (it wasn't freeing linkblock->base_url). Finally I removed a check from a_Web_free():web.c, which (to me) doesn't make sense. Since the patch has more than 20 lines, I'm not sending it attached, but you can get it at: http://www.linux.ime.usp.br/~livio/dillo/linkblock_leak.diff The good news os that on pages with forms it leaks less than it used to, but the bad news is Dillo is still not 100% consistent with it's memory management. I'll keep hunting for more... (but not tonight :-) best regards to all! -- Livio Re: [Dillo-dev]Which space is available in a table cell? From: Michael Govorun - 2001-05-22 22:19 > and DwTable. But what about this example: > > > > > > >
> At first I wrote here the letter about normalizing that has to be there. But then I understand that there must be no limit to viewport size! And no normalizing at all. Some sites use horizontal scrolling scheme and they need to rule it! 100%+100% must be 200% and there has to be horizontal scrolling in this case. One use 100%+100% in case of: 1. He need it. 2. He made mistake. > In this case, it makes more sense that both images get 50% of the > viewport width (I think so). > > I've played with the code, and changed Dw_page_extremes to return (so > to say) infinity as maximal width in this case (equivalent to 1fil in > Tex), and got indeed this result: > > ,---------------------. > | |<- viewport > |########## ##########| > |########## ##########<-- images > |########## ##########| > | | > `---------------------' there has to be ,---------------------. | image 1 | image 2 |#####################|##################### |#####################|##################### |#####################|##################### | | `---------------------' <=---- scroller ---=> > > The following: > > > > > > >
> > will result in > > ,- empty space > ,-----|---------------. > | | | > |# V ##########| > |# ##########| > |# ##########| > | | > `---------------------' and there has to be: ,---------------------. | | |# ###################|# |# ###################|# |# ###################|# | | `---------------------' <=---- scroller ---=> -- -Michael Govorun Re: [Dillo-dev]Killed Bug #160 (memory leak detection) From: Sebastian Geerken - 2001-05-22 16:56 On Tue, May 22, Jorge Arellano Cid wrote: > [memory leaks] > On Apr 18, Sebatian wrote > > "Soon" has taken a bit longer, but at least the interface and the > > modifications of html.c and dw_page.c are finished. The implementation > > of styles (which are currently mainly the same) is still buggy (but > > stable, mainly only memory leaks), and I'll test several variations of > > implementation details for speed and memory usage. > > So this is the place to start hunting. I just fixed one (GCs were not freed) :-), but the problem is still there, and I meant something different in the mail you quoted. DwStyle has a built-in check for memory leaks, all structures are either stored in a hashtable, or counted. a_Dw_style_freeall tests if some are not removed properly, and prints a warning in this case. From time to time, I get this warning; fonts and colors are always ok (note that the remaining styles hold references on them), only styles are left. From the leaks I fixed in the last time, most were referred to widgets, so I guess that this is still buggy. However, this occurs rather rarely, and the problem also arises if all styles are removed properly. Sebastian Re: [Dillo-dev]Hi. From: Sebastian Geerken - 2001-05-22 16:56 Hi Kim, On Wed, May 23, Kim Jonguk wrote: > [...] > I installed 'Dillo-0.4.0'. 5 min before. I'd suggest to install 0.5.0, it provides some advantages. There are no "instable" versions of dillo. > [...] > I'm Korean. Do you know Korea? > Korea is in asia. > Of course, my charset is 'euc-kr' > It is 2 byte. > > I saw that dillo will be able to show us frame & table. > but, I could not see that dillo will be able to show me multibyte > characters. > There is no font selection.... > > Can you help me? Personally, I'd like it if dillo could be able to render different character sets, this will increase the amount of possible users quite much :-). In Gtk+ 1.2, this is quite hard to implement, but Gtk+ 2.0 will depend on the Pango library, which purpose is to handle all different kinds of languages. I haven't taken a look at it yet, but I think that using Pango is indeed an option. Sebastian Re: [Dillo-dev]Killed Bug #160 (memory leak detection) From: Jorge Arellano Cid - 2001-05-22 15:36 Hi there! > Hello people! > > After long hours of bug hunting, I've finally found bug #160 (dillo > caches the same file more than once). Well, is doesn't! > [...] > So here's the tiny patch , which fixes a big problem: > [...] > Have I missed something? > > It seems that Dillo's memory usage has become a lot better now, but > I fear some more leaks are still around :-( Yes they are. > Does anyone know of a good/usable library or tool for memory profiling > or memory leak detection? I've heard of libsafe from AmayaLabs, but it > seems to be designed for buffer overflow detection. And I'be also > heard of others like mpatrol, memprof, Electric Fence, ccmalloc, and > even glib is supposed to support memory profiling, but I've never > worked with any of them (and it's about time I do :-). So before I > choose one, I'd like to here your opinions on these. Hopefully using > one these will make make leak chasing a lot easier. I'll be glad to > here any suggestions! We can use g_mem_check and g_mem_profile among others. BTW: there's code in dillo modules for freeing their resources in order to make more sense out of this functions. Anyway, you can use what suits better to you. Regarding the memory leak problem, a small leak remains: if you go BACK and then FORWARD on a page, it will show. Just try: 'ps aux | grep dillo' to check it. This doesn't happen with cached images! So it is probably in the DwPage code. Even more: On Apr 18, Sebatian wrote > "Soon" has taken a bit longer, but at least the interface and the > modifications of html.c and dw_page.c are finished. The implementation > of styles (which are currently mainly the same) is still buggy (but > stable, mainly only memory leaks), and I'll test several variations of > implementation details for speed and memory usage. So this is the place to start hunting. Cheers Jorge.- [Dillo-dev]Hi. From: Kim Jonguk - 2001-05-22 15:02 Nice to meet you. First. understand my poor english. I'm Korean. This is my first mail to you. I installed 'Dillo-0.4.0'. 5 min before. It's very nice & fast. Because my computer is very slow, I become to favor. but... I'm Korean. Do you know Korea? Korea is in asia. Of course, my charset is 'euc-kr' It is 2 byte. I saw that dillo will be able to show us frame & table. but, I could not see that dillo will be able to show me multibyte characters. There is no font selection.... Can you help me? Thank you for reading my mail. Enjoy my poor english. :) -- end. -- Kim Jonguk. Korea. /--) --- /_ --- Band Jinsil Leader. /___) ) /\ ) /_) Ajou Univ. CS. THiS. Re: [Dillo-dev]Which space is available in a table cell? From: Sebastian Geerken - 2001-05-22 14:20 On Tue, May 22, Michael Govorun wrote: > > At toplevel: yes (the latter). The width of the viewport is passed as > > width hint to the DwPage. This width is used by DwPage for (i) word > > wrapping, and (ii) for calculating percentages. The real width of the > > page is, of course, different in most cases. The question is how to > > calculate (ii) in further nested widgets. > > introduce "available_space" parameter (available_width) > and pass it with hint from parent to child. It can be used in cases: > 1. to calculate percentages when there is no defined width. > 2. for word wraping when there is no defined width. > > in our lovely example there is no self-referring: > available_width=600 (from parent) > > > >
available_width=600 (-border -margins) > available_width=600 (-padding) => width=600 >
This available_width already exists, look at the definitions of DwPage and DwTable. But what about this example:
In this case, it makes more sense that both images get 50% of the viewport width (I think so). I've played with the code, and changed Dw_page_extremes to return (so to say) infinity as maximal width in this case (equivalent to 1fil in Tex), and got indeed this result: ,---------------------. | |<- viewport |########## ##########| |########## ##########<-- images |########## ##########| | | `---------------------' The following:
will result in ,- empty space ,-----|---------------. | | | |# V ##########| |# ##########| |# ##########| | | `---------------------' This seems halfway plausible, IMHO. The code I sent you will instead show nothing. Sebastian Re: [Dillo-dev]Which space is available in a table cell? From: Michael Govorun - 2001-05-22 11:22 > At toplevel: yes (the latter). The width of the viewport is passed as > width hint to the DwPage. This width is used by DwPage for (i) word > wrapping, and (ii) for calculating percentages. The real width of the > page is, of course, different in most cases. The question is how to > calculate (ii) in further nested widgets. introduce "available_space" parameter (available_width) and pass it with hint from parent to child. It can be used in cases: 1. to calculate percentages when there is no defined width. 2. for word wraping when there is no defined width. in our lovely example there is no self-referring: available_width=600 (from parent)
available_width=600 (-border -margins) available_width=600 (-padding) => width=600
-- -Michael Govorun Re: [Dillo-dev]Which space is available in a table cell? From: Sebastian Geerken - 2001-05-21 20:12 Hi Michael, I fear this has become more complicated than really needed ... ;-) First of all, widgets are mostly resized from top to down. There are only few exceptions (e.g. if an image has an unspecified size which gets known later), but this is also delivered to the toplevel widget. Of course, the parent widget may honor size requests of the child. On Mon, May 21, Michael Govorun wrote: > [...] > > However, for calculating the column widths, the minimal and maximal > > width has to be known (this is done by an additional function, for > > efficiency), and if an image is embedded in the page, with a size of > > 100%, the maximal width is of course infinitive, but this would > > confuse the algorithm. Furthermore, n1 * infinity equals n2 * > > infinity, also if n1 and n2 are different. A good solution would > > perhaps to adapt the idea how TeX deals with different "levels" of > > infinity. I meant this "fil" could be useful as a "mathematical unit". > I think percentage means "Look at size of parent". And so if we have > percentage in size of child we should get it's maximum > width from it's parent. The problem is, that this is often self-referring. *Maximum* could be an option. I'll think about it. > As I understand, there has to be two ways of size info interchange: > from parent to child when we have undefined child size, and way to > calculate size of parent when we have undefined parent size and know > sizes of childs. Yes, see above. But this case (and most other cases) is the first you mentioned. > [...] > How can we pass what we don't know yet!!? We can only pass info about > the fact that width of DwPage [1] is not defined yet. Or(and?) pass > default maximum (it can be size of visible area or whatever?). At toplevel: yes (the latter). The width of the viewport is passed as width hint to the DwPage. This width is used by DwPage for (i) word wrapping, and (ii) for calculating percentages. The real width of the page is, of course, different in most cases. The question is how to calculate (ii) in further nested widgets. Sebastian Re: [Dillo-dev]Which space is available in a table cell? From: Michael Govorun - 2001-05-21 17:25 Hi Sebastian > I haven't uploaded anything until now. My current work is very > unstable, and committing it to the CVS would disturb developers > working on other parts. However, I can send a patch to anyone who is > interested. Yes, I'm interesting. > The table structure in short: > > - The HTML parser is extended to write text into different DwPage > widgets. > > - There is a new widget DwTable, embedding other DwPage > widgets. (So you have a widget structure halfway close to the > document structure, see also my other posting, "Ideas on CSS".) > > - The DwPage widget gets a new mode to deal with embedded widgets. > > A widget can define how to deal with "size hints". Currently, the > viewport size is used to set the size of the toplevel DwPage widget > _by_hints_ (by the set_... functions), not directly (this would be > done by size_allocate), and DwPage uses this to recalculate its size > (returned by size_request). There is some documentation in the doc/ > directory, start with Dw.txt. > > DwPage knows two modes now how to deal with children: > > - For simple widgets, like images, the size is set directly via > size_allocate. > > - For more complex images, like tables, hints are used. > > The DwTable widget itself calculates the column widths from the hinted > width, and passes them further to the child widgets. > > However, for calculating the column widths, the minimal and maximal > width has to be known (this is done by an additional function, for > efficiency), and if an image is embedded in the page, with a size of > 100%, the maximal width is of course infinitive, but this would > confuse the algorithm. Furthermore, n1 * infinity equals n2 * > infinity, also if n1 and n2 are different. A good solution would > perhaps to adapt the idea how TeX deals with different "levels" of > infinity. I think percentage means "Look at size of parent". And so if we have percentage in size of child we should get it's maximum width from it's parent. As I understand, there has to be two ways of size info interchange: from parent to child when we have undefined child size, and way to calculate size of parent when we have undefined parent size and know sizes of childs. > > (BTW, the algorithm to calculate the column widths is quite > uninteresting, I've already modified it a few times.) > > About the examples: The first one will result in > > DwPage [1] > `-DwTable > `-DwPage [2] > `-DwImage > > where the DwPage [1] passes its width as a hint to DwTable, but How can we pass what we don't know yet!!? We can only pass info about the fact that width of DwPage [1] is not defined yet. Or(and?) pass default maximum (it can be size of visible area or whatever?). Then when we reach last child and if there is still indefinite size of parent - we can use it. Otherwize, if we need to start rendering earlier than all sizes will be set we can use that default maximum (or minimum?) and later do resizing. What do you think about it? > DwTable does not know what width DwPage [2] should have. The second > will look like > > DwPage [1] > _____`-DwTable [1]_________ > `-DwPage [2] > `-DwTable [2] > `-DwPage [3] > `-DwImage > > and DwTable [1] will probably pass 70% of its width (received by > DwPage [1]) to DwPage [2]. So the problem is equivalent, the part > below the line equals the example above. > I haven't looked at the CSS spec in detail, but it contains much more > about this problem. I'll have to take a more comprehensive look at it. > > BTW, I plan indeed to implement any attributes, which are deprecated > and will replaced by CSS equivalents, quite close to the CSS spec. In > the near future (i.e. before starting with CSS implementation), I'll > extend more and more the structure DwStyle for this. Later, it becomes > a fundamental structure for CSS. Deprecated attributes will only > mapped on the CSS implementation. I think, it is good plan. -- -Michael Govorun Re: [Dillo-dev]Killed Bug #160 (memory leak detection) From: Sebastian Geerken - 2001-05-21 15:10 On Mon, May 21, Livio Baldini Soares wrote: > [...] > So here's the tiny patch , which fixes a big problem: > [...] Done, together with another leak (page->shapes[i].data.poly). Sebastian Re: [Dillo-dev]Which space is available in a table cell? From: Sebastian Geerken - 2001-05-21 14:42 Hi Michael, On Mon, May 21, Michael Govorun wrote: > > Hi, > > > > I wonder how to calculate lengths, specified by percentages, within > > table cells, e.g. for images. The HTML spec only says that it should > > be calculated from the "available space". > > > > Currently, such lengths are calculated from the viewport > > size. Calculating element sizes from the sizes of the containing > > elements is self-referring, and so hardly defined. E.g. in > > > > > > > >
> > > > I think we should calculate it from available space in next outer layer > (img->td->table->...->viewport) where it defined. > In the example above it defined at viewport level. > > But in this example: > > >
> > >
>
> > > available space for image defined in level of the outer table, but in > turn, width of the outer table must be calculated from viewport width. There is currently no support for the width attribute (I've just started), but this will (probably) result in the same problem, see below. > I can contribute my ideas of full algoritm, but I have no info about > current table structure :( > and I'm pretty new to dillo development I haven't uploaded anything until now. My current work is very unstable, and committing it to the CVS would disturb developers working on other parts. However, I can send a patch to anyone who is interested. The table structure in short: - The HTML parser is extended to write text into different DwPage widgets. - There is a new widget DwTable, embedding other DwPage widgets. (So you have a widget structure halfway close to the document structure, see also my other posting, "Ideas on CSS".) - The DwPage widget gets a new mode to deal with embedded widgets. A widget can define how to deal with "size hints". Currently, the viewport size is used to set the size of the toplevel DwPage widget _by_hints_ (by the set_... functions), not directly (this would be done by size_allocate), and DwPage uses this to recalculate its size (returned by size_request). There is some documentation in the doc/ directory, start with Dw.txt. DwPage knows two modes now how to deal with children: - For simple widgets, like images, the size is set directly via size_allocate. - For more complex images, like tables, hints are used. The DwTable widget itself calculates the column widths from the hinted width, and passes them further to the child widgets. However, for calculating the column widths, the minimal and maximal width has to be known (this is done by an additional function, for efficiency), and if an image is embedded in the page, with a size of 100%, the maximal width is of course infinitive, but this would confuse the algorithm. Furthermore, n1 * infinity equals n2 * infinity, also if n1 and n2 are different. A good solution would perhaps to adapt the idea how TeX deals with different "levels" of infinity. (BTW, the algorithm to calculate the column widths is quite uninteresting, I've already modified it a few times.) About the examples: The first one will result in DwPage [1] `-DwTable `-DwPage [2] `-DwImage where the DwPage [1] passes its width as a hint to DwTable, but DwTable does not know what width DwPage [2] should have. The second will look like DwPage [1] _____`-DwTable [1]_________ `-DwPage [2] `-DwTable [2] `-DwPage [3] `-DwImage and DwTable [1] will probably pass 70% of its width (received by DwPage [1]) to DwPage [2]. So the problem is equivalent, the part below the line equals the example above. > > the image can have any width. The same with other examples. > > > > Should we refer to the CSS specification? > My opinion: yes, and we should take into account all margins, > paddings, borders, etc. I haven't looked at the CSS spec in detail, but it contains much more about this problem. I'll have to take a more comprehensive look at it. BTW, I plan indeed to implement any attributes, which are deprecated and will replaced by CSS equivalents, quite close to the CSS spec. In the near future (i.e. before starting with CSS implementation), I'll extend more and more the structure DwStyle for this. Later, it becomes a fundamental structure for CSS. Deprecated attributes will only mapped on the CSS implementation. Sebastian [Dillo-dev]Killed Bug #160 (memory leak detection) From: Livio Baldini Soares - 2001-05-21 14:24 Hello people! After long hours of bug hunting, I've finally found bug #160 (dillo caches the same file more than once). Well, is doesn't! Actually it's a (not so small ;-) memory leak in dw_page.c (Dw_page_destroy). The patch actually is very simple. (It's impressive how *after* hunting a bug with a small patch, it seems soooo easy and obvious :-) So here's the tiny patch , which fixes a big problem: ******************** --- dillo/src/dw_page.c Mon May 21 10:35:03 2001 +++ dillo.new/src/dw_page.c Mon May 21 10:52:26 2001 @@ -277,7 +277,7 @@ static void Dw_page_destroy (GtkObject * g_free(page->lines); page->num_words = 0; /* make sure we don't own widgets anymore */ - + g_free(page->words); g_free(page->shapes); for (link_index = 0; link_index < page->num_links; link_index++) { ************************ Have I missed something? It seems that Dillo's memory usage has become a lot better now, but I fear some more leaks are still around :-( Does anyone know of a good/usable library or tool for memory profiling or memory leak detection? I've heard of libsafe from AmayaLabs, but it seems to be designed for buffer overflow detection. And I'be also heard of others like mpatrol, memprof, Electric Fence, ccmalloc, and even glib is supposed to support memory profiling, but I've never worked with any of them (and it's about time I do :-). So before I choose one, I'd like to here your opinions on these. Hopefully using one these will make make leak chasing a lot easier. I'll be glad to here any suggestions! best regards to all, -- Livio [Dillo-dev]Which space is available in a table cell? From: Michael Govorun - 2001-05-21 12:39 > Hi, > > I wonder how to calculate lengths, specified by percentages, within > table cells, e.g. for images. The HTML spec only says that it should > be calculated from the "available space". > > Currently, such lengths are calculated from the viewport > size. Calculating element sizes from the sizes of the containing > elements is self-referring, and so hardly defined. E.g. in > > > >
> I think we should calculate it from available space in next outer layer (img->td->table->...->viewport) where it defined. In the example above it defined at viewport level. But in this example:
available space for image defined in level of the outer table, but in turn, width of the outer table must be calculated from viewport width. I can contribute my ideas of full algoritm, but I have no info about current table structure :( and I'm pretty new to dillo development > the image can have any width. The same with other examples. > > Should we refer to the CSS specification? My opinion: yes, and we should take into account all margins, paddings, borders, etc. -- -Michael Govorun Re: [Dillo-dev]Bug in IO_read's From: Jorge Arellano Cid - 2001-05-21 06:47 Livio, > > I've discovered some more about this... > > [...] > > IO_read ERROR: Resource temporarily unavailable > > > > Not only has this error been systematic but now causes a Segv on my > > system, because when it happens while `reading', we get thrown into > > a_Cache_ccc with OpAbort (and since we're reading, we're in Branch > > 2... as I see it writing is Branch 1 and reading Branch 2, right > > Jorge?). From there we get thrown into a_Cache_callback(IOAbort, > > NULL). And in a_Cache_callback, we do: const DilloUrl * Url = > > io->CbData... except io is NULL :-( > > Ok, this error seems to manifest itself only on SMP systems, and not > in UP systems. The patch I sent (in the previous e-mail) definately > fixes this misbehaviour. For the unbeliever I have copied a compiled > copy (*with* debugging symbols, i.e. not stripped) to > shell.so....net (usw-pr-shell1.so....net is a SMP, with 2 > CPUs). Actually, the problem MAY manifest on single processors too, that depends on several things. The EAGAIN error, or EWOULDBLOCK on BSDs, is meant for a temporary delay on the operation (for instance while the kernel waits for a stopped HD to resume its available condition --this may vary on different OSs though...). I was thinking that threads in the detached state, freeing their allocated resources upon end, may be temporarily blocking file descriptors activity. That's good, the problem was that the code was not handling EAGAIN, as the 'todo:' stated! I'll check the code after fixing the new Url handling issues. Good research Livio, that will surely improve dillo's stability Jorge.- Re: [Dillo-dev]Cache question (about process queue) From: Jorge Arellano Cid - 2001-05-21 06:47 Livio, > Hello! > > Does anybody know why {a_}Cache_open_url(), uses > Cache_delayed_process_queue(), instead of calling > Cache_process_queue()? Yes man: a_Cache_open_url returns a client-key (identifier) to the calling function. The caller MUST receive the key before the client queue is processed. That's the delay for. > I mean, is there any use in making a 1 second > timeout before retrieving the desired data, besides making the user > wait longer? ;-) No, there's no need for the 1 second wait! (except for what's stated above) > Can anybody help me? Keep on reading... > I tried to get rid of it, and Dillo "feels" faster (root-url and > images seem to load faster). The only reason I can guess the delay is > there is to avoid concurrency in ClientQueue, but I don't think that > that's a good way to do it. If that's the reason then we can device a > better way to eliminate concurrency. I made a "hack" for this, which > seems better then what we have now, but maybe a better solution can be > discussed? Any ideas? Thinking twice about it, and assuming that the GTK idle functions are processed in the main GTK cycle, after all the other "normal" functions are done, and considering that delayed processing is used only for cached answers, using a plain idle function seems to be a good solution. Jorge.- [Dillo-dev]Which space is available in a table cell? From: Sebastian Geerken - 2001-05-20 16:49 Hi, I wonder how to calculate lengths, specified by percentages, within table cells, e.g. for images. The HTML spec only says that it should be calculated from the "available space". Currently, such lengths are calculated from the viewport size. Calculating element sizes from the sizes of the containing elements is self-referring, and so hardly defined. E.g. in
the image can have any width. The same with other examples. Should we refer to the CSS specification? I'm hoping on hints and ideas. Sebastian [Dillo-dev]Ideas on CSS From: Sebastian Geerken - 2001-05-20 14:45 Hi all, although I'm currently working mainly on tables, I've tried to summarize my ideas on an implementation of CSS. It is not a detailed design, but only a collection of vague ideas. Any kind of comments are welcome. Sebastian ---------------------------------------------------------------------- Ideas on an Implementation of CSS ================================= Document Tree, Widget Tree, Document-Widget Interface ----------------------------------------------------- The HTML parser is extended to build a tree, which should be consistent all the time (i.e. between two calls of Html_write). Furthermore, there will be an interface to the Dw widget structure, mapping document elements on lists of widgets or parts of widgets. A simple, incomplete example could look like this: HTML Document Widget Structure Simple Example ----------------------> DwPage

Simple Example

----> { +- DwPageWord { +- DwPageWord -------------------> `- DwTable | --------> +- DwPage | `- ... --------> +- DwPage | `- ... | | --------> +- DwPage | `- ... --------> `- DwPage `- ...
No. 1No. 2
No. 3No. 4
[This is very incomplete, this interface has to be worked out completely.] Note that the interface also includes _parts_ of a widget, because this may make more efficient implementations possible (example: DwPageWord instead of a widget DwWord). Widgets get consistent interface to access parts of a widget, e.g. referencing and applying style attributes. (Idea: perhaps this can be simplified, by making widgets a special case of widget parts.) CSS --- Of course, there is the need for a CSS parser. It can be as simple as possible (e.g. generated by yacc), there is no need for an incremental parser, as used for HTML. Instead, the CSS text can be written into a buffer, and then parsed as a whole. In this text, "CSS" means the internal representation of the CSS text, after parsing. Styles and Blocks ----------------- There is already now the structure DwStyle, used as a uniform structure for presentation attributes of widgets and parts of widgets. It is extended, by attributes, as well as by general rendering functions for borders, backgrounds etc. (Although the DwStyle structure is uniform, it is probably not possible to achieve the same for the code.) A CSS block is represented by a style and a bit mask containing specified attributes. The CSS module will provide a function for calculating the style of a specific HTML element, by evaluating rules and combining blocks, to get a DwStyle. Applying a CSS to the Document/Widget Tree ------------------------------------------ There are two methods necessary: 1. Incrementally, while the HTML document is read. In this case, the styles are calculated, when the widgets/widget parts are created. 2. Instantly, by applying styles to all widgets/widget parts of the (currently existing) document/widget tree. Each HTML document has a CSS. Initially, it is the user defined one. The HTML parser will modify it in two cases: - When