- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Dillo CVS has no bookmark menu?

by Jorge Arellano Cid

On Fri, 17 Oct 2003, johannes leimbach wrote: > Hi! > > Is it only me, or is the bookmark menu broken in the current cvs version? > It does not show up.. > > Thanks for answer! We've been making sevral changed to dpid lately, but it works! Just make sure you don't have an obsolete dpid on ~/.dillo/ or anywhere in your path. (rm `which dpid`; cd dpid/; strip dpid; cp dpid ~/.dillo) Also make sure the bookmarks dpi binary is accesible. Ah, you may also have an old dpid already running, kill all of the instances and make sure they're gone! ps aux | grep dpi; kill stuff... (kill the dpis first, then dpi. We're working on this). HTH Jorge.-

Oct. 17, 2003

Re: SPAM in the list :(

by Jorge Arellano Cid

On Fri, 17 Oct 2003, Andreas Kemnade wrote: > On Fri, 17 Oct 2003 09:36:44 -0300 (CLST) > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > > Hi Andi, > > > > I just noticed four intances of the "nigerian scam" type of > > SPAM in dillo-dev. I'm worried because usually I also receive > > warning bounces from recipients telling that mail from dillo-dev > > may end being filetered out. > > > spamassassin is attached to dillo-dev now. Every message considered as spam > will be deleted without notice. > > Greetings > Andreas Kemnade Take note guys! If you ever feel unsure about whether a message made its way into the list, just check the archives. Cheers Jorge.- PS: Thanks Andreas.

Oct. 17, 2003

[PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Frank de Lange

Hi'all, The next version (2) of my keyboard navigation patch is ready. See the end of this message for download instructions. Do note that the tab/frame patch already contains this functionality, so there is no need (and no way) to apply this patch on top of that or the other way around. This release does not contain any major new functionality. It solves the problems with Tab, which now does what you'd expect it to do: cycle through form widgets. For more info on what this patch does, see the last message on the list or the doc/Keyboard_Navigation.txt document (after applying the patch, naturally...) Download instructions ===================== There is currently only one version of the patch, made against 20031017/11:26GMT CVS. As always, have a look at the patch website (http://www.geocities.com/ikbenfrank/) for the latest version of the patch. This patch does NOT apply on top of the tab/frame patch, and the tab/frame patch does not apply on top of this one! The tab/frame patch already contains this functionality, so it is not needed. http://www.geocities.com/ikbenfrank/dillo-200310171559-kbnav.patch.gz size: 14494 bytes (gzipped, as downloaded) 64277 bytes (uncompressed) md5sum: 8ebd2450b762a720363346c0c4a7a537 (gzipped, as downloaded) 9538b60172b910e89c993d887b28bc97 (uncompressed) Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 17, 2003

[PATCH] Version 12 of tab/frame/kbnav patch, solves problem with Tab

by Frank de Lange

Hi'all, The next version (12) of my tab/frame/keyboard navigation patch is ready (see bottom of this message for download instructions). No big new features this time, just a useability fix for the Tab key and an update to the latest CVS. Tab now does what you'd expect it to do, cycle through form widgets. I'll spare you the usual list of comments on this release, it would be identical to last release's list anyway... Download instructions ===================== The patch is made against 20031017/11:26GMT CVS. Do not forget to run ./autogen.sh after applying the patch. You can find the patch on the usual (ad-happy, use an ad-blocking proxy or sane browser) site: http://www.geocities.com/ikbenfrank/ More specifically: Dillo 0.8.0-pre (CVS) ===================== http://www.geocities.com/ikbenfrank/dillo-20031017-tabs.patch.gz size: 85658 bytes (gzipped, as downloaded) 373460 bytes (uncompressed) md5sum: be0618ac0136fafd9f7f91ce8a4db142 (gzipped, as downloaded) 41438b3b27bf45f23b6a9069eee37cb6 (uncompressed) As always, check the site for the most recent version Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / \ \ `--| _/ <Hacker for Hire> \ `---' \ +46-734352015 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 17, 2003

/. crap

by Andrew A. Gill

[I'm not subscribed to the list, but I do read it in the archives.] Date: Fri, 17 Oct 2003 11:44:33 -0400 From: Jamie McCarthy <jamie(a)mccarthy.vg> Subject: Re: [secret-list] /. hubris superluser(a)frontiernet.net (Andrew A. Gill) writes: > For a while, users of Dillo (<http://www.dillo.org>) have been > having trouble reading Slashdot (<http://slashdot.org>). Looks > like a misplaced </td></tr> is to blame. Anybody want to > pester Cowboy Neal? Well, this is one of the fun things about working on a public project: I get bug reports through more than just the usual channels. Hi, I'm Jamie, I'm the one who wrote the bug, and I'm the one who will get around to fixing it... eventually. There's no immediately simple way to fix the HTML. What's going on is actually kind of interesting. Slashdot runs on Slash, which is a publicly available project used on hundreds of other websites. The look of Slashdot and its front-page table layout is fairly different under the hood from the layout of "Slashcode," which is the default theme that we ship. These differences are mostly encoded in template files, which are data chunks arranged mostly hierarchically that can be selected in all kinds of interesting ways. That means, sadly, that changing one template has many repercussions. Obviously I know where the buggy HTML output is; that's what that commented-out  tag is doing there. But I have to think about what that change would do not just to Slashdot, but to the Slashcode theme generically, to the sites that use that theme as-is, to the dozen other sites my company runs that have modified that theme, to the who-knows how many other sites that strangers run that have modified that theme, to "light mode," to the three or four separate scripts that use the template, I have to test with the pre-rendering caching, etc., etc. Slashdot's HTML layout has always been broken. Early this year I took it upon myself to fix it and quickly realized that there was no good way to fix just Slashdot, without either breaking Slashcode as well or introducing a large number of copy-and-pasted code as a difference between the two that would have to be maintained. What I did instead was write code for the Template Toolkit that lets these dozens of templates build the HTML tables dynamically. As new <TR> and <TD> tags are laid out, variables are incremented and decremented. By the time we get to the bottom of the page, the code knows how many <TD>s and <TR>s it's got to close, and how, in order to make the HTML all nice and pristine. That way, Slashdot.org and Slashcode.com can have wholly different columnar layouts and the low-level templates don't have to know about any of it. The CPU overhead is minimal, and overall it works great. Except there's one bug. It doesn't keep proper track of the tables it's building. It dumps errors in the log so I know about where it is. But it's difficult to narrow down. In my defense, it was broken before I wrote this code, and while it's still broken now, it's broken *less*. But it's broken *differently* and of course there is one browser that (unlike every other browser ever written) isn't smart enough to handle malformed table tags. <http://www.dillo.org/> This is the part where I rhetorically ask why anyone would write a web browser from scratch, the goal of which is to render 100% syntactically correct webpages really really fast. Are there not enough existing web browsers whose goals are to render pages really really fast? Is it perhaps not widely known that there exists, somewhere on the web, HTML code which just might not be 100% exactly correct? Is it smart to build a nitro-burning funny car dragster to carry your groceries and then complain to mailing lists about the potholes on Main Street? When version 0.7.2 of the funny car handled the potholes just fine, but 0.7.3 explodes on contact, should its designers necessarily be focused entirely on the potholes? And should anyone be surprised that writing a web browser is hard? If I could find a way to ask those questions without sounding like I was shifting the blame off my own fool self, I would. It's one of those things that is probably a nice easy single day of work. But I can't remember the last time I actually had a whole day to work on something. Our new load balancer is choking our webheads with unACK'd SYN's and I'm not sure whose fault it is. (And of course the new load balancer is named "pound," only the most common word in the English language, so good luck Googling for anyone else with the same problems.) Our new sites being launched are extending the code in ways it wasn't built for and we're having to scramble. DB replication on one of those new sites went down this morning, and while we built some kickass code to failover to the master, we hadn't had time to get that running yet. Oh, and either my ISP or my home router/gateway is flaky, so I keep falling off the internet. And of course, the day after I fix the HTML 3.2 table layout bug, I am quite certain my boss will email me to say it's finally time to start working on the switch to XHTML and CSS, which we've been planning for a year and just haven't had time for. So yes, I'd love to fix your bug. I don't like emitting broken HTML code either. I'm a big fan of adhering to standards, and I'm a big fan of not having my code embarrass me in public. I hate feeling like a jackass. But I have other things to worry about, and you have other browsers to choose from that render Slashdot just fine. Meanwhile, your bug sits right here, at Priority 5, where it's sat since we first diagnosed it in April: https://sourceforge.net/tracker/?func=detail&aid=719813&group_id=4421&atid=… -- Jamie McCarthy http://mccarthy.vg/ jamie(a)mccarthy.vg Date: Fri, 17 Oct 2003 12:50:48 -0400 From: Jamie McCarthy <jamie(a)mccarthy.vg> Subject: Re: [secret-list] /. hubris superluser(a)frontiernet.net (Andrew A. Gill) writes: > > Well, this is one of the fun things about working on a public > > project: I get bug reports through more than just the usual > > channels. Hi, I'm Jamie, I'm the one who wrote the bug, and > > I'm the one who will get around to fixing it... eventually. > > Do you mind if I forward this message to the Dillo people? If you do, mention to them that I'm not picking on them. This bug is my fault and I'll fix it. I wish them luck and I'm glad they're doing what they're doing (anyone writing GPL code is OK in my book). It's just that I won't fix it until it gets to the top of my priority list, fact of life, and there's a lot of other things up there... :( A workaround meanwhile is to try light mode, which you can get to past the black window with: http://slashdot.org/index.pl?light=1 http://slashdot.org/users.pl?op=edithome&light=1 and then check the "Light" box, and Save to make that your pref. -- Jamie McCarthy http://mccarthy.vg/ jamie(a)mccarthy.vg

Oct. 17, 2003

Re: [Dillo-dev] Re: gtk2 and dillo ( was FLTK )

by Jorge Arellano Cid

On Fri, 17 Oct 2003, Madis Janson wrote: > > On Fri, 17 Oct 2003, robert w hall wrote: > > > In article <20031016032905.GA12137(a)ws0.localdomain>, Stephen Lewis > > <slewis(a)paradise.net.nz> writes > > >On Tue, Oct 14, 2003 at 10:20:11AM -0300, Jorge Arellano Cid wrote: > > >> > > >> This is also an RFC for information on GTK+2 (speed, size, > > >> linkings etc). > > >> > > >> Please back your opinions with links, docs, facts or with > > >> whatever helps better to understand the point. Maybe a single > > >> email can show there's no way to do it, or maybe not! > > > > > >I've just been playing with the GTK+2 patch, and I've got some > > >numbers (I won't call them fact :), and opinions: > > > > can we assume/hope/plead (in the light of these numbers!) that any move > > to gtk2 is post-dillo-0.8 :-) > > > > Read dillo goals ;) > > I believe that the move to gtk2 will be done only then, when it can be > done without affecting dillo's usability as a light and fast browser. Sure, dillo-0.8.0 will be a GTK1 app. BTW, I foresee almost a month to its release: we still have to sabilize dpi, and study/merge/modify some/all of Frank's patches. Last but not the least, please continue posting on the FLTK thread. It's the same! Cheers Jorge.-

Oct. 17, 2003

Dillo CVS has no bookmark menu?

by johannes leimbach

Hi! Is it only me, or is the bookmark menu broken in the current cvs version? It does not show up.. Thanks for answer! Cheers, johannes

Oct. 17, 2003

RE: [Dillo-dev] FLTK

by Eric GAUDET

I ran my tests again, only with antialiasing disabled this time (for font sizes between 6 and 14). The results of the first run are repeated here, and dillo2n represents the new runs. Please refer to my previous email for a detailed description of the tests. I also experimented with sub-pixel rendering, without antialiasing (dillo2ns) and with antialiasing (dillo2s) First run: ---------- Results: time1 time2 delta/30 prps mem(KB) dillo1 1.36s 1.82s 15ms 67 2516 dillo2 3.10s 6.90s 126ms 8 3624 dillo2s 3.23s 7.16s 131ms 7.6 n/a dillo2n 3.34s 5.33s 66ms 15 3628 dillo2ns 3.16s 4.94s 59ms 17 n/a Conclusion: While disabling antialiasing rendering doesn't seem to change anything for the start time (which was already acceptable, IMHO), it doubles the speed when scrooling entire pages! With this setting, dillo2n became useable. Not quite as snappy as dillo1 (still 4 times slower on redraws), but very acceptable. Turning off antialiasing doesn't change the amount memory used. Turning on sub-pixel rendering doesn't affect the rendering time, but seems to improve the quality only when used with antialiasing. However, my fonts look ugly with gtk-2.0 and I don't seem to be able to find any setting that helps (it seems to scale non-scalable fonts). With gtk-1.2, the font look good. Second run: skipped. Third run: ---------- This is a scaled down version of the second run. I took the same file and kept only the first 2000 line. The test file is 684 KB. Results: time1 time2 mem(KB) dillo1 5.1s 35s 12708 dillo2 31.5s 2m53s 33520 dillo2n 29.9s n/a 33652 Conclusion: Nothing changed here: loading big pages is still painful brings the whole machine down on its knees when swapping starts. For the record, the real time (time2) was 2m10s, but the load on my system was completely different today, so I don't this it compares to yesterdays results. Fourth run: skipped. Fifth run: ---------- This is a free run of internet browsing, to get an overall feeling. No numbers for this one. Includes browsing several sites, open up to 8 windows, switch between them and close them all, click on the floppy disk to save URL. Selecting text was fast. Conclusion: Still feels heavy. Faster on scrolling, acceptable, in fact, but any operation is still taking enough time for me to notice I'm actually waiting for the redraws to occur. Particularly when overlapping redraws occur (X Expose events), like switching from one window to another. Also, as another poster noticed, *closing* windows takes a significant amount of time (this is certainly related to freeing much more memory than dillo1). I timed another operation to give you an idea: I opened and closed (cancel) the save URL dialog 5 times in dillo2n, substracted the start and closing time as usual and divided by 5: 1.4s each time (user time, real time more like 6s). Same experience with dillo1: 0.09s. Now that's what I'm talking about! (could not get any real time, most of it is spent by moving the mouse from one button to another) Final conclusion: ----------------- If we go with gtk-2.0, we absolutely need to document this antialiasing setting: I had a hard time finding that some information was on fontconfig.org! If we also can point to font de-uglyfication of gtk-2.0, that would help a lot. Regardless, like Stephen said, memory usage is a huge problem. I assume this cause by the libraries and the implementation in dillo is the same (i.e: dillo's structure did not grow x2.5 because the the port). Until this problem is solved, I don't think gtk-2.0 is a viable option for dillo. Disabling antialiasing definitely solves most of my concerns about speed: if only I could get the font to be as clean as gtk-1.2, I would be happy. Best, EG PS: the patch is still alpha-quality and has a lot of rendering bugs: font-factor screws-up positionning, text selection hightlights at the wrong place, etc.

Oct. 17, 2003

Re: [Dillo-dev] Development

by Carlos Daniel Ruvalcaba Valenzuela

> > Any comments?, anyone wants the patches? > > Good idea. Wheres the patches? This weekend i'll prepare the patches, i'll setup a site for all the stuff also. The dpi autoloading for dillo is quite safe, it works even with current plugins without much changes (just in the name of dpi executables). For example: We can do this: url = a_Url_new("dpi:/bm/", NULL, 0, 0); a_Nav_push(bw, url); This will load the bookmarks dpi, but it asumes certain format of the dpi exacurable, this can be replaced with a list of dpi executable -> dpi name list on the config file. It will asume dpiname_srv, thus the bookmarks dpi will be bm_srv. The modification dosen't changes the actual cominications of dpi<-->dillo, only adds dpi autoloading. The patches changes only: capi.c a_Capi_open_url() a_Capi_dpi_send_cmd IO/dpi.c a_Dpi_ccc Dpi_launch_server That's all, see ya the weekend. By the way, who is in charge of the Downloads Plugin? I 'm also working on it, soo if i can help on something, just drop a mail. Cheers Carlos Daniel Ruvalcaba Valenzuela _________________________________________________________ Do You Yahoo!? La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

Oct. 17, 2003

Re: [Dillo-dev] Re: gtk2 and dillo ( was FLTK )

by Madis Janson

On Fri, 17 Oct 2003, robert w hall wrote: > In article <20031016032905.GA12137(a)ws0.localdomain>, Stephen Lewis > <slewis(a)paradise.net.nz> writes > >On Tue, Oct 14, 2003 at 10:20:11AM -0300, Jorge Arellano Cid wrote: > >> > >> This is also an RFC for information on GTK+2 (speed, size, > >> linkings etc). > >> > >> Please back your opinions with links, docs, facts or with > >> whatever helps better to understand the point. Maybe a single > >> email can show there's no way to do it, or maybe not! > > > >I've just been playing with the GTK+2 patch, and I've got some > >numbers (I won't call them fact :), and opinions: > > can we assume/hope/plead (in the light of these numbers!) that any move > to gtk2 is post-dillo-0.8 :-) > Read dillo goals ;) I believe that the move to gtk2 will be done only then, when it can be done without affecting dillo's usability as a light and fast browser.

Oct. 17, 2003