July 2003 - Dillo-dev - lists.mailman3.com

dillo size is 1.2mb ?

by Nagaraja

Hi All, I got dillo compiled on arm with natively build toolchain, when I check the size of dillo it is 1.2mb. my configure option is: ./configure --with-gtk-prefix=/etc/gtk --x-includes=/usr/X11R6/include --x-libraries=/opt/toolchain/arm-linux/lib/X11 --with-jpeg-lib=/opt/toolchain/arm-linux/lib when I do file dillo ....... I am getting. dillo: ELF 32-bit LSB executable, Advanced RISC Machines ARM, version 1, dynamically linked (uses shared libs), stripped nothing seems satically linked. could any one please tell me what could be the cause..... Thanks and regards Nags

July 14, 2003

Re: [Dillo-dev] Re: Some news...

by TheStar

On Mon, 14 Jul 2003 10:18 am, Diego Sáenz wrote: > I have see the dpi code and think that it is a very good approach. Only > one think: how do you integrate a plug-in without patch dillo? I known > that dpi is not finished, but i am impatient. If the PIs can add menu > entries to dillo menus it can be easy to start/call a PI when a menu > entrie is clicked and the PI can ask some dillo state(like url below the > mouse) or open a save dialog or etc using a dpi tag. A cfg file can > asociate prefix(ftp://), sufix(.swf) and menu entries with PIs. It can > be modified on PI install or be generated. There must be some code for > dinamics menus in dillo for history yet. About PIs that render to a zone > in a web page it can be done like Sylpheed-claws integrate dillo in > it(GTK X sockets or something that i think). I hope to help something > even if nobody ask. > > Diego. > Also, would the dpi code also allow shockwave, java, client-side scripts, and other plugins to be added, if re-written (ie, utilising kaffe for java). I know that the plugins themselves will take a LOT of work, but I'm asking about the actual dpi...

July 14, 2003

Re: [Dillo-dev] Re: Some news...

by Diego Sáenz

I have see the dpi code and think that it is a very good approach. Only one think: how do you integrate a plug-in without patch dillo? I known that dpi is not finished, but i am impatient. If the PIs can add menu entries to dillo menus it can be easy to start/call a PI when a menu entrie is clicked and the PI can ask some dillo state(like url below the mouse) or open a save dialog or etc using a dpi tag. A cfg file can asociate prefix(ftp://), sufix(.swf) and menu entries with PIs. It can be modified on PI install or be generated. There must be some code for dinamics menus in dillo for history yet. About PIs that render to a zone in a web page it can be done like Sylpheed-claws integrate dillo in it(GTK X sockets or something that i think). I hope to help something even if nobody ask. Diego. El Mon, 7 Jul 2003 15:35:30 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> escribio: > > Hi! > > > > > This has been a very busy week. I didn't anticipate how much > > work the dpid (dpi daemon) integration could take. Don't panic > > though!, the code that binds it all is running (to some extent) > > in my machine. The time consuming problem is that while making > > the integration, a lot of design matters spring in, and they take > > a lot of time to solve. > > > > The good news is that it all starts to shape into a more clear > > design (the code is still hackish at parts, but it is clear what, > > where and how to fix it). > > > > While working the gory details of it, I realized it'd be a good > > idea to make the 0.7.3 release with what we have now (plus a > > little bug fix we're working on with Sebastian). That way, > > there'll be less pressure on us while polishing the new dpid > > implementation, and hey!, it's been a long time since our last > > release. > > > > I'll keep the CVS free of the dpid code until the 0.7.3 release > > is done. For the meanwhile, I'll provide a tarball to the new > > code. (and if I can't wrap the new code before Monday, I'll > > provide a link to the latest dpid testing tarball I have). > > > First, the final code for the 0.7.3 is on the CVS (unless you > find a bug in it). It will be released by Wednesday, so please > give it a hard test today and tomorrow! > > With regard to 0.8.0-pre (aka dillo with dpid), here's the good > news: > > * Finally I have a tarball that does bookmarks and downloads > with dpid (using wget)! It can handle multiple plugins and is > working smoothly. > > I want to add one more plugin (at least) and update the > documentation before commiting it to the CVS (after releasing > 0.7.3 of course). > > For those very interested in studying it, please review: > > http://dillo.org/download/dpid4.tgz > > (not my tarball but the dpid testing suite itself) > > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

July 14, 2003

Re: [Dillo-dev] Another delay for 0.7.3 :(

by Sebastian Geerken

On Sun, Jul 13, Joe Crayne wrote: > Does this fix it? > > > --- source.cvs/src/dw_page.c 2003-07-12 14:17:12.000000000 -0400 > +++ source.fix/src/dw_page.c 2003-07-13 00:16:32.000000000 -0400 > @@ -451,7 +451,7 @@ static void Dw_page_get_extremes (DwWidg > /* no rewrap necessary -> values in lines are up to date */ > line = &page->lines[page->num_lines - 1]; > if (page->words[line->first_word].style->nowrap) > - extremes->min_width = MAX (line->max_word_min, line->par_min); > + extremes->min_width = MAX (line->max_line_width, line->par_min); > else > extremes->min_width = line->max_word_min; > extremes->max_width = MAX (line->max_par_max, line->par_max); No, you cannot compare minimal widths (line->par_min) with actual widths (line->max_line_width), the problem is another one. I've just committed a fix, I'll summarize it here. The first part is: @@ -450,10 +450,11 @@ static void Dw_page_get_extremes (DwWidg } else if (page->wrap_ref == -1) { /* no rewrap necessary -> values in lines are up to date */ line = &page->lines[page->num_lines - 1]; - if (page->words[line->first_word].style->nowrap) - extremes->min_width = MAX (line->max_word_min, line->par_min); - else - extremes->min_width = line->max_word_min; + /* Historical note: The former distinction between lines with and without + * words[first_word]->nowrap set is no longer necessary, since + * Dw_page_real_word_wrap sets max_word_min to the correct value in any + * case. */ + extremes->min_width = line->max_word_min; extremes->max_width = MAX (line->max_par_max, line->par_max); } else { /* Calculate the extremes, based on the values in the line from Why it is not neccessary anymore, is clear from the second part (simplified): @@ -907,9 +916,15 @@ static void Dw_page_real_word_wrap (DwPa if (!new_par) last_line->par_max += last_space; if (word->style->nowrap) { last_line->par_min += word_extremes.min_width; + /* This may also increase the accumulated minimum word width. */ + last_line->max_word_min = + MAX (last_line->max_word_min, last_line->par_min); + /* NOTE: Most code relies on that all values of nowrap are equal for all + * words within one line. */ } else /* Simple case. */ last_line->max_word_min = MAX (last_line->max_word_min, word_extremes.min_width); Actually, this bug has existed for a longer time, what I assume (but did not investigate further) is that the fixed code was never used before, i.e. instead of handling this case: } else if (page->wrap_ref == -1) { /* no rewrap necessary -> values in lines are up to date */ [...] this case: } else { /* Calculate the extremes, based on the values in the line from where a rewrap is necessary. */ [...] was *always* handled, due to the rewrapping bug I fixed some time ago. So this bug was hid by another one. There is still another bug: At http://bbs.archlinux.org/viewtopic.php?t=771 the text is not rewapped sometimes. I'm working on it. Sebastain

July 13, 2003

Re: [Dillo-dev] Another delay for 0.7.3 :(

by Joe Crayne

On Thu, Jul 10, 2003 at 01:27:48PM -0400, Jorge Arellano Cid wrote: > > So the 0.7.3 release will be held until I have some news about > this bug. (Jorge, sorry for the double emails, I meant to send to the list before.) Does this fix it? --- source.cvs/src/dw_page.c 2003-07-12 14:17:12.000000000 -0400 +++ source.fix/src/dw_page.c 2003-07-13 00:16:32.000000000 -0400 @@ -451,7 +451,7 @@ static void Dw_page_get_extremes (DwWidg /* no rewrap necessary -> values in lines are up to date */ line = &page->lines[page->num_lines - 1]; if (page->words[line->first_word].style->nowrap) - extremes->min_width = MAX (line->max_word_min, line->par_min); + extremes->min_width = MAX (line->max_line_width, line->par_min); else extremes->min_width = line->max_word_min; extremes->max_width = MAX (line->max_par_max, line->par_max);

July 13, 2003

Re: [Dillo-dev] selection segfault again

by Sebastian Geerken

I wrote: > FYI: I seem to have fixed the bug, expect it to be committed > today. Those interested should look at the differences in the code, it > is only a simple coding bug, nothing very interesting. (Has been committed.) Something I forgot: The fix does not work perfectly, when, in the test page, you start select within the text, and then move the pointer below the text, the selection starts at the beginning. This is a known bug, and it won't be fixed for 0.7.3. Sebastian

July 12, 2003

Re: [Dillo-dev] selection segfault again

by Sebastian Geerken

On Sat, Jul 12, Jamin W. Collins wrote: > On Sat, Jul 12, 2003 at 04:58:42PM +0200, Sebastian Geerken wrote: > > > Since the </table> tag is mandatory, we are not obliged to handle > > this. Anyway, a missing </table> tag will leave a well-defined widget > > tree, which the selection must be able to handle. > > While not required to handle it, the application should *never* segfault > when provided bad data. Dillo does not segfault anymore ;-) (Fix has been committed.) The problem is unrelated to the missing </table>, there may be *valid* pages which would have caused dillo to segfault due to the same bug. Sebastian

July 12, 2003

Re: [Dillo-dev] selection segfault again

by Jamin W. Collins

On Sat, Jul 12, 2003 at 04:58:42PM +0200, Sebastian Geerken wrote: > Since the </table> tag is mandatory, we are not obliged to handle > this. Anyway, a missing </table> tag will leave a well-defined widget > tree, which the selection must be able to handle. While not required to handle it, the application should *never* segfault when provided bad data. -- Jamin W. Collins Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo

July 12, 2003

Re: [Dillo-dev] selection segfault again

by Sebastian Geerken

Hi, FYI: I seem to have fixed the bug, expect it to be committed today. Those interested should look at the differences in the code, it is only a simple coding bug, nothing very interesting. On Fri, Jul 11, Joe Crayne wrote: > <html> <title>Selection Bug</title> > <body> > > <table> > <tr><td></td></tr> > > <tr><td> > Select beyond the end of the text and > Dillo segfaults. > </td></tr> >  > > </body> > </html> The reason, why the missing </table> tag matters, is that Html_close_tag_table() will insert a break after the table, which makes iterators behave different. > [...] > I see 3 possible attacks on this one: > > 1. Add a check for NULL on the return value of > a_Dw_ext_iterator_new_variant(). a_Dw_ext_iterator_new() returns NULL, if the page does not contain any non-widget contents. After it one succeeded, it should always succeed. That it does not, was a bug, and is fixed now. BTW: Actually, this is only true, as long as no contents is *removed* from the page, which does not yet happen. If it happens, the selection will anyway get more complicated, a check in this case would not make much sense. > 2. Do that special empty DwExtIterator idea you > mentioned. Yes, this will probably part of 0.7.4. But in this case, you would have to compare empty with non-empty iterators ;-) > 3. Make html.c clean up the <table> tag better. > The missing closer probably shouldn't make a > difference in this example, but the segfault only > happens if the closer is missing. Since the </table> tag is mandatory, we are not obliged to handle this. Anyway, a missing </table> tag will leave a well-defined widget tree, which the selection must be able to handle. Sebastian

July 12, 2003

Re: [Dillo-dev] Some news...

by Ferdi Franceschini

Lars Segerlund wrote: > I have been looking at the dpid, and from what I can see it looks > good, it would be a piece of cake to whip up some usefull dpi's now :-) That's great! > ... I will however dig a bit more, the issue that I am concearned is if > it prohibits some action to be implemented, ( workarounds are ok for me > :-) ). dpid does not prohibit anything, it simply starts a plugin on demand (similar to inetd). > I also have a related question about the dpi's, whith the new > interface, how it fx. a https dpi supposed to work ? and would it be > possible to make fw a svg dpi ? ( thus enabling the dpi to do the > rendering ? I don't think dillo supports https (other than to check that it is used for cookies), and I don't know what plans there are for https support. Can you explain what "fw" and "svg" stand for. For now, just have the dpi open its own window for rendering, we'll worry about how to integrate this with dillo later, you will also need to do this for GUI controls. > Anyhow, for my stumbling attempts whith dpi's it seems to be fully > adequat. That's good. If you have any further questions please let us know. I plan to make a new version of dpid which supports a dpi directory structure in a few days. Regards Ferdi

July 12, 2003