From onepoint at starurchin.org Thu Jan 1 23:38:52 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Thu Jan 1 23:39:29 2009 Subject: [Dillo-dev] We have competition! Message-ID: <20090101223852.GB2938@omphalos.singularity> Linux Weekly News covers Hv3, a Tcl-based lightweight browser. http://lwn.net/Articles/311823/ They refer to Dillo as "perhaps the best known minimalist browser"! It's worth reading the comments to see what people want to see in a lightweight browser and what they don't miss if it's not there. They certainly appreciate the speed. Hv3 claims to support CSS, but I'm not seeing it: Slashdot and the BBC look almost exactly the same as they do in Dillo. Mind you, I'm running it from the latest CVS and getting plagued with Tcl errors too, so maybe it's just temporarily broken. Hv3 is also supposed to support Javascript through SEE, but the SEE site is not responding right now so I can't try it out (and comments suggest that getting it into a source build is broken). Maybe SEE would be a way to support JavaScript in Dillo? Amyway, it looks like 2009 will be an exciting year for Dillo. Jeremy From corvid at lavabit.com Fri Jan 2 00:44:14 2009 From: corvid at lavabit.com (corvid) Date: Fri Jan 2 00:46:15 2009 Subject: [Dillo-dev] We have competition! In-Reply-To: <20090101223852.GB2938@omphalos.singularity> References: <20090101223852.GB2938@omphalos.singularity> Message-ID: <20090101234414.GF7243@local.gobigwest.com> Jeremy wrote: > Hv3 is also supposed to support Javascript through SEE, but the SEE > site is not responding right now so I can't try it out (and comments > suggest that getting it into a source build is broken). Maybe SEE > would be a way to support JavaScript in Dillo? Justus wrote a bit about SEE and others: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005065.html From sas at 321.hu Fri Jan 2 00:48:32 2009 From: sas at 321.hu (=?ISO-8859-1?Q?SZERV=C1C_Attila?=) Date: Fri Jan 2 00:49:05 2009 Subject: [Dillo-dev] We have competition! In-Reply-To: <20090101223852.GB2938@omphalos.singularity> References: <20090101223852.GB2938@omphalos.singularity> Message-ID: Hv3 is slow, Dillo rokz, btw, what about i18n? On Thu, Jan 1, 2009 at 11:38 PM, Jeremy Henty wrote: > > Linux Weekly News covers Hv3, a Tcl-based lightweight browser. > > http://lwn.net/Articles/311823/ > > They refer to Dillo as "perhaps the best known minimalist browser"! > It's worth reading the comments to see what people want to see in a > lightweight browser and what they don't miss if it's not there. They > certainly appreciate the speed. > > Hv3 claims to support CSS, but I'm not seeing it: Slashdot and the BBC -- SZERV?C Attila - zeneszerz? http://google.com/search?q=szerv?c -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20090102/2a845ceb/attachment.htm From onepoint at starurchin.org Fri Jan 2 13:43:55 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Fri Jan 2 13:44:28 2009 Subject: [Dillo-dev] We have competition! In-Reply-To: <20090101234414.GF7243@local.gobigwest.com> References: <20090101223852.GB2938@omphalos.singularity> <20090101234414.GF7243@local.gobigwest.com> Message-ID: <20090102124355.GC2938@omphalos.singularity> On Thu, Jan 01, 2009 at 11:44:14PM +0000, corvid wrote: > Jeremy wrote: > > Maybe SEE would be a way to support JavaScript in Dillo? > > Justus wrote a bit about SEE and others: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005065.html Oh yes, I remembered this but forgot that it discussed SEE. (New Year's resolution: stop trusting my memory!) That's a pretty impressive performance gap! I guess that's the price you pay for being simple. I'll still have a look at SEE once their website is back. Regards, Jeremy Henty From Beartooth at swva.net Fri Jan 2 18:11:21 2009 From: Beartooth at swva.net (me at swva) Date: Fri Jan 2 18:12:01 2009 Subject: [Dillo-dev] We have competition! In-Reply-To: <20090101223852.GB2938@omphalos.singularity> References: <20090101223852.GB2938@omphalos.singularity> Message-ID: On Thu, 1 Jan 2009, Jeremy Henty wrote: > > Linux Weekly News covers Hv3, a Tcl-based lightweight browser. > > http://lwn.net/Articles/311823/ > > They refer to Dillo as "perhaps the best known minimalist browser"! > It's worth reading the comments to see what people want to see in a > lightweight browser and what they don't miss if it's not there. They > certainly appreciate the speed. That sounds like my cue. In case anyone is interested, Dillo has been my default browser for about four or five years -- and almost nothing in this thread nor on the sites mentioned means a thing to me; most of it I never heard of till now. Noticeably often Dillo can't or won't display what I click on -- somewhere between 1 time in 10 and 1 in 100 -- closer to the less frequent end. So be it; that fact alone, or it plus some message the site gives me (e.g., "You need mxzstplk; download it here.") may tell me whether to skip it. If not, I have four or so bigger slower browsers open all the time on other work-spaces, anyway. (Opera, Firefox, Galeon, and usually Epiphany; sometimes Konqueror; occasionally Kazehakase, Midori, or Seamonkey. I use Firefox for NoScript; Opera for redirects (which I dis-automate); and so on.) Having those already launched makes it fast to switch work-spaces, add or overwrite a tab, and try the reject there. (I can usually guess from Dillo and the URL itself which to pick, nearly always on the first try.) The really big things, to at least this one not quite clueless user (who wouldn't know a line of code if it bit me), are what they've always been, and I hope will remain : safety and speed. In particular, I run a couple of small private lists, most of whose subscribers use one form or another of Windows; I don't allow attachments of any sort; and I urge people to send links instead. So I have lots of sites to vet. (Until recently, I ran lists only manually.) For that, Dillo is invaluable. If Dillo displays a site, it's likely to be safe -- and I can guess whether my subscribers will be interested. If not, that one next look will likely tell me what I need to know. In any case, better by far that I, with Dillo, linux (Fedora 10), hard & soft firewalls, etc., should look -- rather than some poor soul with negligible defenses. I hope this helps. -- Beartooth Staffwright, Neo-Redneck Not Quite Clueless Power User I have precious (very precious!) little idea where up is. I try to be paranoid, but I just can't keep up. From jcid at dillo.org Fri Jan 2 19:34:13 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Jan 2 19:33:48 2009 Subject: [Dillo-dev] Best wishes for 2009! Message-ID: <20090102183413.GB27551@dillo.org> Hi there, Please receive my best wishes for this new year 2009! We've come a long way since dillo restarted, and progress in several fronts has improved the browser a lot. Thanks to you all for the good work!!! > Amyway, it looks like 2009 will be an exciting year for Dillo. In the hope of it coming true, I just sent Johannes an image handling patch series for CSS to work properly with stylesheet loading. Just wait for his signal after he commits to download and enjoy the new code. Note: I'm still working on it, but it's quite usable "as is". -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jcid at dillo.org Fri Jan 2 20:30:38 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Jan 2 20:30:11 2009 Subject: [Dillo-dev] [patch]: refactor Auth_parse_auth_basic() In-Reply-To: <20081229133705.GB28461@omphalos.singularity> References: <20081229133705.GB28461@omphalos.singularity> Message-ID: <20090102193038.GD27551@dillo.org> On Mon, Dec 29, 2008 at 01:37:05PM +0000, Jeremy Henty wrote: > > This patch implements a previous suggestion to break up > Auth_parse_auth_basic() into smaller functions and eliminate gotos. > Please comment. Committed. It's much easier to understand/maintain with short functions. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jcid at dillo.org Fri Jan 2 21:05:20 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Jan 2 21:04:54 2009 Subject: [Dillo-dev] [patch]: fix dialog callback In-Reply-To: <20081228195655.GA28461@omphalos.singularity> References: <20081228195655.GA28461@omphalos.singularity> Message-ID: <20090102200520.GE27551@dillo.org> On Sun, Dec 28, 2008 at 07:56:55PM +0000, Jeremy Henty wrote: > > Dialog_user_password_cb() should not use VOIDP2INT, because the (void > *) argument was originally an (int *), not an int or long. This bug > makes the dialog always call its callback even when the user presses > the Cancel button. As a result it is futile to cancel the Basic > Authentication dialog: the page reloads and the dialog pops up again. Ooops! Committed with minor modifications and a fix for some unrelated missing INT2VOIDP. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From Johannes.Hofmann at gmx.de Fri Jan 2 22:55:52 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Fri Jan 2 23:03:21 2009 Subject: [Dillo-dev] Best wishes for 2009! In-Reply-To: <20090102183413.GB27551@dillo.org> References: <20090102183413.GB27551@dillo.org> Message-ID: <20090102215552.GA25710@blob.baaderstrasse.com> On Fri, Jan 02, 2009 at 03:34:13PM -0300, Jorge Arellano Cid wrote: > Hi there, > > Please receive my best wishes for this new year 2009! > > We've come a long way since dillo restarted, and progress > in several fronts has improved the browser a lot. > > Thanks to you all for the good work!!! > > > > Amyway, it looks like 2009 will be an exciting year for Dillo. > > In the hope of it coming true, I just sent Johannes an image > handling patch series for CSS to work properly with stylesheet > loading. Just wait for his signal after he commits to download > and enjoy the new code. > > Note: I'm still working on it, but it's quite usable "as is". I've just pushed Jorge's work to the css-prototype repository. It works fine for me so far :-) Happy new year, Johannes From onepoint at starurchin.org Fri Jan 2 23:05:23 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Fri Jan 2 23:06:00 2009 Subject: [Dillo-dev] [patch]: use the dlib dStr* functions everywhere Message-ID: <20090102220523.GD2938@omphalos.singularity> This is a small consistency cleanup. Most of the Dillo source uses dlib's dStr* functions for string operations. This patch fixes the few places that do not. Jeremy Henty -------------- next part -------------- diff -r 1fb0b96a52b8 ChangeLog --- a/ChangeLog Fri Jan 02 17:04:10 2009 -0300 +++ b/ChangeLog Fri Jan 02 22:01:35 2009 +0000 @@ -49,6 +49,8 @@ - Fixed the parser not to call Html_tag_close_* functions twice. !- Started code cleanup of the image code mainly in dicache.c. Patches: Jorge Arellano Cid ++- Ensure that the dlib dStr* functions are used everywhere. + Patch: Jeremy Henty. dw diff -r 1fb0b96a52b8 dpi/downloads.cc --- a/dpi/downloads.cc Fri Jan 02 17:04:10 2009 -0300 +++ b/dpi/downloads.cc Fri Jan 02 22:01:35 2009 +0000 @@ -294,7 +294,7 @@ char *p, *esc_url; if (pipe(LogPipe) < 0) { - MSG("pipe, %s\n", strerror(errno)); + MSG("pipe, %s\n", dStrerror(errno)); return; } /* Set FD to background */ @@ -685,7 +685,7 @@ /* Update curr_size */ if (stat(fullname, &ss) == -1) { - MSG("stat, %s\n", strerror(errno)); + MSG("stat, %s\n", dStrerror(errno)); return; } update_size((int)ss.st_size); @@ -833,7 +833,7 @@ while (st < 0 && errno == EINTR); if (st == -1) - MSG("readline, %s\n", strerror(errno)); + MSG("readline, %s\n", dStrerror(errno)); dStr_truncate(*msg, 0); if (st > 0) @@ -888,7 +888,7 @@ new_socket = accept(req_fd, (struct sockaddr *) &clnt_addr, &csz); } while (new_socket == -1 && errno == EINTR); if (new_socket == -1) { - MSG("accept, %s fd=%d\n", strerror(errno), req_fd); + MSG("accept, %s fd=%d\n", dStrerror(errno), req_fd); return; } diff -r 1fb0b96a52b8 dpi/file.c --- a/dpi/file.c Fri Jan 02 17:04:10 2009 -0300 +++ b/dpi/file.c Fri Jan 02 22:01:35 2009 +0000 @@ -673,7 +673,7 @@ * calling exit() */ if (st == -1) { MSG("ERROR while reading from file \"%s\", error was \"%s\"\n", - filename, strerror(errno)); + filename, dStrerror(errno)); exit(1); } diff -r 1fb0b96a52b8 dpi/ftp.c --- a/dpi/ftp.c Fri Jan 02 17:04:10 2009 -0300 +++ b/dpi/ftp.c Fri Jan 02 22:01:35 2009 +0000 @@ -187,7 +187,7 @@ int DataPipe[2]; if (pipe(DataPipe) < 0) { - MSG("pipe, %s\n", strerror(errno)); + MSG("pipe, %s\n", dStrerror(errno)); return 0; } diff -r 1fb0b96a52b8 src/auth.c --- a/src/auth.c Fri Jan 02 17:04:10 2009 -0300 +++ b/src/auth.c Fri Jan 02 22:01:35 2009 +0000 @@ -234,7 +234,7 @@ /* is this value the realm? */ set_realm = auth_parse->realm == NULL && - strncasecmp(realm_token,token,token_size) == 0 && + dStrncasecmp(realm_token,token,token_size) == 0 && strlen(realm_token) == token_size; return Auth_parse_quoted_string(auth_parse, set_realm, auth); @@ -275,7 +275,7 @@ static void Auth_parse_auth(AuthParse_t *auth_parse, char *auth) { _MSG("auth.c: Auth_parse_auth: auth = '%s'\n", auth); - if (strncasecmp(auth, "Basic ", 6) == 0) { + if (dStrncasecmp(auth, "Basic ", 6) == 0) { auth += 6; Auth_parse_auth_basic(auth_parse, &auth); } else { From jcid at dillo.org Fri Jan 2 23:20:21 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Jan 2 23:19:54 2009 Subject: [Dillo-dev] [patch]: use the dlib dStr* functions everywhere In-Reply-To: <20090102220523.GD2938@omphalos.singularity> References: <20090102220523.GD2938@omphalos.singularity> Message-ID: <20090102222021.GG27551@dillo.org> On Fri, Jan 02, 2009 at 10:05:23PM +0000, Jeremy Henty wrote: > > This is a small consistency cleanup. Most of the Dillo source uses > dlib's dStr* functions for string operations. This patch fixes the > few places that do not. Good! Committed. BTW, you already have a patch entry in the Changelog. Please reuse it instead of adding a new one. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From sandshrew at gmail.com Sat Jan 3 12:48:42 2009 From: sandshrew at gmail.com (Tomas R) Date: Sat Jan 3 12:48:45 2009 Subject: [Dillo-dev] Re: We have competition! Message-ID: <20090103134842.26f34f54@ubuntu> Sorry to disappoint you, but hv3 is officially unmaintained already for almost a year and SEE has LOTS of problems... -- Brain: an apparatus with which we think we think. - A. Bierce From Hole.destructor at gmx.de Sat Jan 3 16:36:06 2009 From: Hole.destructor at gmx.de (Hole.destructor@gmx.de) Date: Sat Jan 3 16:36:39 2009 Subject: [Dillo-dev] open new tab Message-ID: <495F85E6.1070206@gmx.de> Hi Dillo team, I have a simple question concerning the new tabbed browsing feature in Dillo2: The only way to open a link in a new tab seems to be a click with the middle mouse button. Since there are some people, who don't have a mouse (for example on Laptops, MacBooks etc.) and therefore must find this middle-click very unhandy, I was wondering whether it is possible to open a link within a new tab by using another method, for example the common - combination? If this is currently not possible, could you introduce it in a future version of dillo? (I think the inofficial Dillo version, which is currently shipped with Debian/Ubuntu knows this alternative combination.) Many thanks in advance for your help, Alexander From onepoint at starurchin.org Sat Jan 3 22:14:05 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sat Jan 3 22:15:05 2009 Subject: [Dillo-dev] Re: We have competition! In-Reply-To: <20090103134842.26f34f54@ubuntu> References: <20090103134842.26f34f54@ubuntu> Message-ID: <20090103211405.GF2938@omphalos.singularity> On Sat, Jan 03, 2009 at 01:48:42PM +0200, Tomas R wrote: > Sorry to disappoint you, but hv3 is officially unmaintained already > for almost a year and SEE has LOTS of problems... That *is* disappointing. It would be good to have a simple, maintained JavaScript engine to study. It's odd the article didn't mention any of this; it made it sound as though both projects were active. Thanks for the update, Jeremy Henty From jcid at dillo.org Sat Jan 3 23:05:39 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sat Jan 3 23:05:11 2009 Subject: [Dillo-dev] Re: We have competition! In-Reply-To: <20090103211405.GF2938@omphalos.singularity> References: <20090103134842.26f34f54@ubuntu> <20090103211405.GF2938@omphalos.singularity> Message-ID: <20090103220539.GI27551@dillo.org> On Sat, Jan 03, 2009 at 09:14:05PM +0000, Jeremy Henty wrote: > On Sat, Jan 03, 2009 at 01:48:42PM +0200, Tomas R wrote: > > > Sorry to disappoint you, but hv3 is officially unmaintained already > > for almost a year and SEE has LOTS of problems... > > That *is* disappointing. It would be good to have a simple, > maintained JavaScript engine to study. It's odd the article didn't > mention any of this; it made it sound as though both projects were > active. > > Thanks for the update, Sometime ago I read this: http://www.freesoftwaremagazine.com/columns/h3v_web_browser_it_dillo_killer What a headline! but the comments there give a different idea... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From onepoint at starurchin.org Sun Jan 4 07:04:02 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sun Jan 4 07:04:48 2009 Subject: [Dillo-dev] Re: We have competition! In-Reply-To: <20090103220539.GI27551@dillo.org> References: <20090103134842.26f34f54@ubuntu> <20090103211405.GF2938@omphalos.singularity> <20090103220539.GI27551@dillo.org> Message-ID: <20090104060402.GG2938@omphalos.singularity> On Sat, Jan 03, 2009 at 07:05:39PM -0300, Jorge Arellano Cid wrote: > http://www.freesoftwaremagazine.com/columns/h3v_web_browser_it_dillo_killer > > What a headline! Yes, it's flattering that Dillo is considered to be the one to beat! > but the comments there give a different idea... Indeed, it looks as thought H3w and SEE are dead projects. That's a shame. Jeremy Henty From sandshrew at gmail.com Sun Jan 4 16:02:18 2009 From: sandshrew at gmail.com (Tomas R) Date: Sun Jan 4 16:03:20 2009 Subject: [Dillo-dev] Re: We have competition! Message-ID: <20090104170218.63c464e7@ubuntu> > http://www.freesoftwaremagazine.com/columns/h3v_web_browser_it_dillo_killer > > What a headline! I was testing hv3 for quite awhile when the project was still active and would like to point out some stupid mistakes made in the article: 1) it's NOT h3v or h3w - it's hv3 (Html Viewer 3)! 2) it's written primarily in TCL, not in C; 3) both dillo and hv3 do support SSL (hv3 requires TLS for that and TLS is incorporated in the startkits, provided in the official website) 4) in both articles it is said "developerS". Actually 99% of the code (some parts were borrowed from another TCL browser called "BrowseX"(http://wiki.tcl.tk/2136)) was written by one genius named Daniel Kennedy. 5) Dillo actually launches a lot faster than hv3, but hv3 renders pages really fast too. And few comments from my side... Hv3 has a lot better bookmark manager when compared to dillo. Furthermore, in addition to bookmark, setting and cookie saving it can save history and has autocompletion. It has highly advanced css support - it even passes ACID2 test (something what microsoft with their internet exploiter was trying achieve for quite awhile...). As it's primarily written in TCL, it's platform independent, doesn't require any external dependencies, can run straight from USB flash memory (it can also save its db there too). Unlike dillo, hv3 also supports frames. Finally, even it's considered to be alpha state software, at least when javascript support is disabled, it is pretty stable. If you'd like to know something more about hv3, I think, you should still be able to contact Daniel - danielk1977 AT gmail DOT com. BTW, I don't know the current status of SEE project, I just know that the last time I checked (half a year ago or so) it had really many problems. SEE: http://www.adaptive-enterprises.com.au/~d/software/see/ -- Brain: an apparatus with which we think we think. - A. Bierce From jcid at dillo.org Mon Jan 5 18:51:03 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Jan 5 18:50:38 2009 Subject: [Dillo-dev] Strange valgrind complain Message-ID: <20090105175103.GO27551@dillo.org> Hi there, With Johannes, we're trying to find out why valgrind complains on the newest CSS branch with a certain URL: $ valgrind --tool=memcheck --leak-check=yes \ ./dillo http://selenic.com/pipermail/mercurial/ &>out $ less out There're several "Invalid read of size 1". It doesn't complain with a local file, nor after repush. It seems the timing is important, and maybe the decoder... Please help us, it's important to stabilize this branch before merging into main. -- BTW, after we merge CSS into the main branch, it seems like floating objects will be the highest priority. Dillo rendering would improve a lot by using both! -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From corvid at lavabit.com Mon Jan 5 20:26:12 2009 From: corvid at lavabit.com (corvid) Date: Mon Jan 5 20:28:12 2009 Subject: [Dillo-dev] Strange valgrind complain In-Reply-To: <20090105175103.GO27551@dillo.org> References: <20090105175103.GO27551@dillo.org> Message-ID: <20090105192612.GC17125@local.gobigwest.com> Jorge wrote: > With Johannes, we're trying to find out why valgrind complains > on the newest CSS branch with a certain URL: > > $ valgrind --tool=memcheck --leak-check=yes \ > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > $ less out > > There're several "Invalid read of size 1". > > It doesn't complain with a local file, nor after repush. It > seems the timing is important, and maybe the decoder... > > Please help us, it's important to stabilize this branch before > merging into main. And it doesn't happen with main? From jcid at dillo.org Mon Jan 5 20:50:55 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Jan 5 20:50:21 2009 Subject: [Dillo-dev] Strange valgrind complain In-Reply-To: <20090105192612.GC17125@local.gobigwest.com> References: <20090105175103.GO27551@dillo.org> <20090105192612.GC17125@local.gobigwest.com> Message-ID: <20090105195055.GQ27551@dillo.org> On Mon, Jan 05, 2009 at 07:26:12PM +0000, corvid wrote: > Jorge wrote: > > With Johannes, we're trying to find out why valgrind complains > > on the newest CSS branch with a certain URL: > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > $ less out > > > > There're several "Invalid read of size 1". > > > > It doesn't complain with a local file, nor after repush. It > > seems the timing is important, and maybe the decoder... > > > > Please help us, it's important to stabilize this branch before > > merging into main. > > And it doesn't happen with main? Yes, main works OK. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From Johannes.Hofmann at gmx.de Tue Jan 6 13:37:10 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Jan 6 13:44:44 2009 Subject: [Dillo-dev] Strange valgrind complain In-Reply-To: <20090105175103.GO27551@dillo.org> References: <20090105175103.GO27551@dillo.org> Message-ID: <20090106123710.GA16709@blob.baaderstrasse.com> On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > Hi there, > > With Johannes, we're trying to find out why valgrind complains > on the newest CSS branch with a certain URL: > > $ valgrind --tool=memcheck --leak-check=yes \ > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > $ less out > > There're several "Invalid read of size 1". > > It doesn't complain with a local file, nor after repush. It > seems the timing is important, and maybe the decoder... The problem seems to be that at cache.c:1149 data is assigned entry->UTF8Data, then during Html_callback() a_Cache_set_content_type() get's called which since revision 48029b8a5478 frees entry->UTF8Data. That also explains why the earlier read of start went ok. I don't really now how to fix that though... Cheers, Johannes From jcid at dillo.org Tue Jan 6 15:24:49 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Jan 6 15:24:57 2009 Subject: [Dillo-dev] Strange valgrind complain In-Reply-To: <20090106123710.GA16709@blob.baaderstrasse.com> References: <20090105175103.GO27551@dillo.org> <20090106123710.GA16709@blob.baaderstrasse.com> Message-ID: <20090106142449.GA20533@dillo.org> On Tue, Jan 06, 2009 at 01:37:10PM +0100, Johannes Hofmann wrote: > On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > > Hi there, > > > > With Johannes, we're trying to find out why valgrind complains > > on the newest CSS branch with a certain URL: > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > $ less out > > > > There're several "Invalid read of size 1". > > > > It doesn't complain with a local file, nor after repush. It > > seems the timing is important, and maybe the decoder... > > The problem seems to be that at cache.c:1149 data is assigned > entry->UTF8Data, then during Html_callback() > a_Cache_set_content_type() get's called which since revision > 48029b8a5478 frees entry->UTF8Data. > That also explains why the earlier read of start went ok. Good catch! I made those changes (48029b8a5478) not knowing exactly how the whole process goes. What I don't understand now is: * The Hg CSS repo from freehg (tip: f9099e82be08) has the problem, but it doesn't have the "Free UTF8Data" patch (48029b8a5478). Anyway, it seems the bug is related to setting the new decoder. As a matter of fact, the main branch of dillo doesn't show the same problem, but it *has* a problem: Nav_open_url: new url='http://selenic.com/pipermail/mercurial/' Dns_server [0]: selenic.com is 66.93.16.53 Connecting to 66.93.16.53 ==29247== Invalid read of size 4 ==29247== at 0x8061926: Cache_process_queue (cache.c:1151) ==29247== by 0x8061232: a_Cache_process_dbuf (cache.c:900) ==29247== by 0x80645C8: a_Capi_ccc (capi.c:597) ==29247== by 0x805D30B: a_Chain_fcb (chain.c:112) ==29247== by 0x8081760: Dpi_parse_token (dpi.c:219) ==29247== by 0x80819E8: Dpi_process_dbuf (dpi.c:278) ==29247== by 0x808290A: a_Dpi_ccc (dpi.c:668) ==29247== by 0x805D30B: a_Chain_fcb (chain.c:112) ==29247== by 0x8083668: a_IO_ccc (IO.c:414) ==29247== by 0x8083041: IO_read (IO.c:201) ==29247== by 0x808319D: IO_callback (IO.c:266) ==29247== by 0x808321E: IO_fd_read_cb (IO.c:287) ==29247== Address 0x480644c is 4 bytes inside a block of size 12 free'd ==29247== at 0x4024B4A: free (vg_replace_malloc.c:323) ==29247== by 0x807E466: dFree (dlib.c:60) ==29247== by 0x807EAA4: dStr_free (dlib.c:293) ==29247== by 0x8060381: a_Cache_set_content_type (cache.c:513) ==29247== by 0x8063F13: a_Capi_set_content_type (capi.c:427) ==29247== by 0x806DF45: _ZL18Html_tag_open_metaP9DilloHtmlPKci (html.cc:3020) ==29247== by 0x806D2E6: _ZL16Html_process_tagP9DilloHtmlPci (html.cc:3538) ==29247== by 0x806D970: _ZL14Html_write_rawP9DilloHtmlPcii (html.cc:3876) ==29247== by 0x806DAEC: DilloHtml::write(char*, int, int) (html.cc:667) ==29247== by 0x806DB7F: _ZL13Html_callbackiP12_CacheClient (html.cc:3767) ==29247== by 0x8061915: Cache_process_queue (cache.c:1149) ==29247== by 0x8061232: a_Cache_process_dbuf (cache.c:900) Nav_open_url: new url='http://selenic.com/pipermail/mercurial/' a_Nav_expect_done: repush! Well, so far I managed to get rid of the complain in my local CSS tree, by changing the way the decoder is engaged, but I want to understand it better before sharing it. There's also a segfault I have to chase... > I don't really now how to fix that though... I assume backing out 48029b8a5478 doesn't make it... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From corvid at lavabit.com Tue Jan 6 18:49:35 2009 From: corvid at lavabit.com (corvid) Date: Tue Jan 6 18:51:33 2009 Subject: [Dillo-dev] Strange valgrind complain In-Reply-To: <20090106142449.GA20533@dillo.org> References: <20090105175103.GO27551@dillo.org> <20090106123710.GA16709@blob.baaderstrasse.com> <20090106142449.GA20533@dillo.org> Message-ID: <20090106174935.GE17125@local.gobigwest.com> Jorge wrote: > As a matter of fact, the main branch of dillo doesn't show > the same problem, but it *has* a problem: > > Nav_open_url: new url='http://selenic.com/pipermail/mercurial/' > Dns_server [0]: selenic.com is 66.93.16.53 > Connecting to 66.93.16.53 > ==29247== Invalid read of size 4 > ==29247== at 0x8061926: Cache_process_queue (cache.c:1151) > ==29247== by 0x8061232: a_Cache_process_dbuf (cache.c:900) > ==29247== by 0x80645C8: a_Capi_ccc (capi.c:597) > ==29247== by 0x805D30B: a_Chain_fcb (chain.c:112) > ==29247== by 0x8081760: Dpi_parse_token (dpi.c:219) > ==29247== by 0x80819E8: Dpi_process_dbuf (dpi.c:278) > ==29247== by 0x808290A: a_Dpi_ccc (dpi.c:668) > ==29247== by 0x805D30B: a_Chain_fcb (chain.c:112) > ==29247== by 0x8083668: a_IO_ccc (IO.c:414) > ==29247== by 0x8083041: IO_read (IO.c:201) > ==29247== by 0x808319D: IO_callback (IO.c:266) > ==29247== by 0x808321E: IO_fd_read_cb (IO.c:287) > ==29247== Address 0x480644c is 4 bytes inside a block of size 12 free'd > ==29247== at 0x4024B4A: free (vg_replace_malloc.c:323) > ==29247== by 0x807E466: dFree (dlib.c:60) > ==29247== by 0x807EAA4: dStr_free (dlib.c:293) > ==29247== by 0x8060381: a_Cache_set_content_type (cache.c:513) > ==29247== by 0x8063F13: a_Capi_set_content_type (capi.c:427) > ==29247== by 0x806DF45: _ZL18Html_tag_open_metaP9DilloHtmlPKci (html.cc:3020) > ==29247== by 0x806D2E6: _ZL16Html_process_tagP9DilloHtmlPci (html.cc:3538) > ==29247== by 0x806D970: _ZL14Html_write_rawP9DilloHtmlPcii (html.cc:3876) > ==29247== by 0x806DAEC: DilloHtml::write(char*, int, int) (html.cc:667) > ==29247== by 0x806DB7F: _ZL13Html_callbackiP12_CacheClient (html.cc:3767) > ==29247== by 0x8061915: Cache_process_queue (cache.c:1149) > ==29247== by 0x8061232: a_Cache_process_dbuf (cache.c:900) > Nav_open_url: new url='http://selenic.com/pipermail/mercurial/' > a_Nav_expect_done: repush! If you give the a_UIcmd_set_page_prog() Cache_data(entry)->len, does the problem go away? From Johannes.Hofmann at gmx.de Tue Jan 6 19:23:26 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Jan 6 19:30:59 2009 Subject: [Dillo-dev] Re: Added a right-click menu to the form submit button (allows to show hiddens) Message-ID: <20090106182326.GA4379@blob.baaderstrasse.com> this is cool! Johannes From corvid at lavabit.com Tue Jan 6 22:00:34 2009 From: corvid at lavabit.com (corvid) Date: Tue Jan 6 22:03:00 2009 Subject: [Dillo-dev] Strange valgrind complain In-Reply-To: <20090106142449.GA20533@dillo.org> References: <20090105175103.GO27551@dillo.org> <20090106123710.GA16709@blob.baaderstrasse.com> <20090106142449.GA20533@dillo.org> Message-ID: <20090106210034.GG17125@local.gobigwest.com> Jorge wrote: > On Tue, Jan 06, 2009 at 01:37:10PM +0100, Johannes Hofmann wrote: > > On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > With Johannes, we're trying to find out why valgrind complains > > > on the newest CSS branch with a certain URL: > > > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > > > $ less out > > > > > > There're several "Invalid read of size 1". > > > > > > It doesn't complain with a local file, nor after repush. It > > > seems the timing is important, and maybe the decoder... > > > > The problem seems to be that at cache.c:1149 data is assigned > > entry->UTF8Data, then during Html_callback() > > a_Cache_set_content_type() get's called which since revision > > 48029b8a5478 frees entry->UTF8Data. > > That also explains why the earlier read of start went ok. > > Good catch! > > I made those changes (48029b8a5478) not knowing exactly > how the whole process goes. What I don't understand now is: > > * The Hg CSS repo from freehg (tip: f9099e82be08) has the problem, > but it doesn't have the "Free UTF8Data" patch (48029b8a5478). > > Anyway, it seems the bug is related to setting the new decoder. Now that I see 48029b8a5478, I'm curious about it: Is there an unref missing somewhere that caused UTF8Data to need to be freed in those cases? From corvid at lavabit.com Wed Jan 7 01:22:44 2009 From: corvid at lavabit.com (corvid) Date: Wed Jan 7 01:25:12 2009 Subject: [Dillo-dev] default search engine Message-ID: <20090107002244.GH17125@local.gobigwest.com> I was thinking about the news that was going around last month about yahoo making its data retention period shorter (with exceptions to let them get away with whatever they want, but that's par for the course). e.g. http://www.theregister.co.uk/2008/12/17/yahoo_anonymization_explained/ It seems like a good idea to set the search_url default to whoever is the...let's say "least bad" in terms of privacy at a given time. From jcid at dillo.org Wed Jan 7 17:19:38 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Jan 7 19:16:49 2009 Subject: [Dillo-dev] Strange valgrind complain In-Reply-To: <20090106123710.GA16709@blob.baaderstrasse.com> References: <20090105175103.GO27551@dillo.org> <20090106123710.GA16709@blob.baaderstrasse.com> Message-ID: <20090107161938.GD20533@dillo.org> On Tue, Jan 06, 2009 at 01:37:10PM +0100, Johannes Hofmann wrote: > On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > > Hi there, > > > > With Johannes, we're trying to find out why valgrind complains > > on the newest CSS branch with a certain URL: > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > $ less out > > > > There're several "Invalid read of size 1". > > > > It doesn't complain with a local file, nor after repush. It > > seems the timing is important, and maybe the decoder... > > The problem seems to be that at cache.c:1149 data is assigned > entry->UTF8Data, then during Html_callback() > a_Cache_set_content_type() get's called which since revision > 48029b8a5478 frees entry->UTF8Data. > That also explains why the earlier read of start went ok. > > I don't really now how to fix that though... Good news: now I have a big cleanup patch that gets rid of every valgrind complain on that page! jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ diffstat try2.diff cache.c | 157 ++++++++++++++++++++++++++++------------------------------------ cache.h | 3 - capi.c | 5 -- capi.h | 3 - html.cc | 22 ++++++-- 5 files changed, 89 insertions(+), 101 deletions(-) Let me polish it a bit more before you review and test it. -- Cheers Jorge.- From jcid at dillo.org Wed Jan 7 19:56:55 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Jan 7 19:57:06 2009 Subject: [Dillo-dev] Strange valgrind complain In-Reply-To: <20090107161938.GD20533@dillo.org> References: <20090105175103.GO27551@dillo.org> <20090106123710.GA16709@blob.baaderstrasse.com> <20090107161938.GD20533@dillo.org> Message-ID: <20090107185655.GE20533@dillo.org> On Wed, Jan 07, 2009 at 01:19:38PM -0300, Jorge Arellano Cid wrote: > On Tue, Jan 06, 2009 at 01:37:10PM +0100, Johannes Hofmann wrote: > > On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > With Johannes, we're trying to find out why valgrind complains > > > on the newest CSS branch with a certain URL: > > > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > > > $ less out > > > > > > There're several "Invalid read of size 1". > > > > > > It doesn't complain with a local file, nor after repush. It > > > seems the timing is important, and maybe the decoder... > > > > The problem seems to be that at cache.c:1149 data is assigned > > entry->UTF8Data, then during Html_callback() > > a_Cache_set_content_type() get's called which since revision > > 48029b8a5478 frees entry->UTF8Data. > > That also explains why the earlier read of start went ok. > > > > I don't really now how to fix that though... > > Good news: now I have a big cleanup patch that gets rid of > every valgrind complain on that page! > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ diffstat try2.diff > cache.c | 157 ++++++++++++++++++++++++++++------------------------------------ > cache.h | 3 - > capi.c | 5 -- > capi.h | 3 - > html.cc | 22 ++++++-- > 5 files changed, 89 insertions(+), 101 deletions(-) > > Let me polish it a bit more before you review and test it. Here go the patches attached. For test, review & commments. Please apply styleengine-init-values first. -- Cheers Jorge.- -------------- next part -------------- # HG changeset patch # User Jorge Arellano Cid # Date 1231175700 10800 # Node ID 7dc8813b269087da2767b3b246c0623b023830aa # Parent 5303e1f5de3d2ff308d78c455f760b080a76e555 Added a couple missing initial values to the styleengine's stack. diff -r 5303e1f5de3d -r 7dc8813b2690 src/styleengine.cc --- a/src/styleengine.cc Mon Jan 05 12:05:24 2009 -0300 +++ b/src/styleengine.cc Mon Jan 05 14:15:00 2009 -0300 @@ -37,7 +37,9 @@ style_attrs.font = Font::create (layout, &font_attrs); style_attrs.color = Color::create (layout, 0); style_attrs.backgroundColor = Color::create (layout, 0xffffff); - + + n->styleAttribute = NULL; + n->inheritBackgroundColor = false; n->style = Style::create (layout, &style_attrs); n->wordStyle = NULL; n->pseudo = NULL; -------------- next part -------------- # HG changeset patch # User Jorge Arellano Cid # Date 1231354399 10800 # Node ID 94119bf06b2246176c0be7934f08539b56cb5f52 # Parent 7dc8813b269087da2767b3b246c0623b023830aa Cleanup of cache.c WRT charset decoders. This patch gets rid of a series of valgrind complains with this page: http://selenic.com/pipermail/mercurial/ diff -r 7dc8813b2690 -r 94119bf06b22 ChangeLog --- a/ChangeLog Mon Jan 05 14:15:00 2009 -0300 +++ b/ChangeLog Wed Jan 07 15:53:19 2009 -0300 @@ -48,6 +48,7 @@ - Allowed the rc parser to skip whitespace around the equal sign. - Fixed the parser not to call Html_tag_close_* functions twice. - Implemented CSS Stylesheet loading. + - Made a big cleanup of cache.c WRT charset decoding (fixes bugs). Patches: Jorge Arellano Cid dw diff -r 7dc8813b2690 -r 94119bf06b22 src/cache.c --- a/src/cache.c Mon Jan 05 14:15:00 2009 -0300 +++ b/src/cache.c Wed Jan 07 15:53:19 2009 -0300 @@ -485,40 +485,33 @@ * Change Content-Type for cache entry found by url. * Return new content type. */ -const char *a_Cache_set_content_type(const DilloUrl *url, const char *ctype, - bool_t force) +const char *a_Cache_set_content_type(const DilloUrl *url, const char *ctype) { + char *charset; const char *curr; CacheEntry_t *entry = Cache_entry_search_with_redirect(url); - if (!entry) - return NULL; + dReturn_val_if_fail (entry != NULL, NULL); + + MSG("a_Cache_set_content_type {%s} {%s}\n", ctype, URL_STR(url)); curr = Cache_current_content_type(entry); - if (entry->TypeMeta && (force == FALSE)) { - /* it's already been set */ - return curr; - } - - if (a_Misc_content_type_cmp(curr, ctype)) { - char *charset; - - dFree(entry->TypeMeta); + if (entry->TypeMeta) { + /* Type is already been set. Do nothing. + * Multiple META elements? */ + } else if (a_Misc_content_type_cmp(curr, ctype)) { + /* TypeMeta not set, and META gives one different from default */ curr = entry->TypeMeta = dStrdup(ctype); - if (entry->CharsetDecoder) a_Decode_free(entry->CharsetDecoder); a_Misc_parse_content_type(ctype, NULL, NULL, &charset); entry->CharsetDecoder = a_Decode_charset_init(charset); dFree(charset); + /* Invalidate UTF8Data */ dStr_free(entry->UTF8Data, 1); - if (entry->CharsetDecoder && entry->DataRefcount > 0) - entry->UTF8Data = a_Decode_process(entry->CharsetDecoder, - entry->Data->str, - entry->Data->len); - else - entry->UTF8Data = NULL; + entry->UTF8Data = NULL; + } return curr; @@ -634,7 +627,7 @@ static void Cache_parse_header(CacheEntry_t *entry) { char *header = entry->Header->str; - char *Length, *Type, *location_str, *encoding, *charset; + char *Length, *Type, *location_str, *encoding; #ifndef DISABLE_COOKIES Dlist *Cookies; #endif @@ -642,6 +635,8 @@ Dlist *warnings; void *data; int i; + + MSG("Cache_parse_header\n"); if (entry->Header->len > 12) { if (header[9] == '1' && header[10] == '0' && header[11] == '0') { @@ -753,20 +748,11 @@ MSG_HTTP("Server didn't send Content-Type in header.\n"); } } else { + /* This HTTP Content-Type is not trusted. It's checked against real data + * in Cache_process_queue(); only then CA_GotContentType becomes true. */ entry->TypeHdr = Type; - _MSG("Content-Type {%s} {%s}\n", Type, URL_STR(entry->Url)); - /* This Content-Type is not trusted. It's checked against real data - * in Cache_process_queue(); only then CA_GotContentType becomes true. - */ - a_Misc_parse_content_type(Type, NULL, NULL, &charset); - if (charset) { - entry->CharsetDecoder = a_Decode_charset_init(charset); - if (entry->CharsetDecoder) { - dStr_free(entry->UTF8Data, 1); - entry->UTF8Data = dStr_new(""); - } - dFree(charset); - } + MSG("TypeHdr {%s} {%s}\n", Type, URL_STR(entry->Url)); + MSG("TypeMeta {%s}\n", entry->TypeMeta); } } @@ -816,15 +802,60 @@ void a_Cache_process_dbuf(int Op, const char *buf, size_t buf_size, const DilloUrl *Url) { - int offset = 0; - int len; + int offset, len; const char *str; + Dstr *dstr1, *dstr2, *dstr3; CacheEntry_t *entry = Cache_entry_search(Url); /* Assert a valid entry (not aborted) */ dReturn_if_fail (entry != NULL); - if (Op == IOClose) { + MSG("__a_Cache_process_dbuf__\n"); + + if (Op == IORead) { + /* + * Cache_get_header() will set CA_GotHeader if it has a full header, and + * Cache_parse_header() will unset it if the header ends being + * merely an informational response from the server (i.e., 100 Continue) + */ + for (offset = 0; !(entry->Flags & CA_GotHeader) && + (len = Cache_get_header(entry, buf + offset, buf_size - offset)); + Cache_parse_header(entry) ) { + offset += len; + } + + if (entry->Flags & CA_GotHeader) { + str = buf + offset; + len = buf_size - offset; + entry->TransferSize += len; + dstr1 = dstr2 = dstr3 = NULL; + + /* Decode arrived data (<= 3 stages) */ + if (entry->TransferDecoder) { + dstr1 = a_Decode_process(entry->TransferDecoder, str, len); + str = dstr1->str; + len = dstr1->len; + } + if (entry->ContentDecoder) { + dstr2 = a_Decode_process(entry->ContentDecoder, str, len); + str = dstr2->str; + len = dstr2->len; + } + dStr_append_l(entry->Data, str, len); + if (entry->CharsetDecoder && entry->UTF8Data) { + dstr3 = a_Decode_process(entry->CharsetDecoder, str, len); + dStr_append_l(entry->UTF8Data, dstr3->str, dstr3->len); + } + dStr_free(dstr1, 1); + dStr_free(dstr2, 1); + dStr_free(dstr3, 1); + + if (entry->Data->len) + entry->Flags &= ~CA_IsEmpty; + + Cache_process_queue(entry); + } + } else if (Op == IOClose) { if ((entry->Flags & CA_GotLength) && (entry->ExpectedSize != entry->TransferSize)) { MSG_HTTP("Content-Length does NOT match message body,\n" @@ -847,61 +878,11 @@ if (entry->Flags & CA_GotHeader) { Cache_unref_data(entry); } - return; + } else if (Op == IOAbort) { /* unused */ MSG("a_Cache_process_dbuf Op = IOAbort; not implemented!\n"); - return; } - - /* - * Cache_get_header() will set CA_GotHeader if it has a full header, and - * Cache_parse_header() will unset it if the header turns out to have been - * merely an informational response from the server (i.e., 100 Continue) - */ - while (!(entry->Flags & CA_GotHeader) && - (len = Cache_get_header(entry, buf + offset, buf_size - offset))) { - offset += len; - /* Let's scan, allocate, and set things according to header info */ - Cache_parse_header(entry); - } - - if (!(entry->Flags & CA_GotHeader)) - return; - - str = buf + offset; - len = buf_size - offset; - entry->TransferSize += len; - - if (entry->TransferDecoder) { - Dstr *dbuf = a_Decode_process(entry->TransferDecoder, str, len); - str = dbuf->str; - len = dbuf->len; - dStr_free(dbuf, 0); - } - if (entry->ContentDecoder) { - Dstr *dbuf = a_Decode_process(entry->ContentDecoder, str, len); - if (entry->TransferDecoder) - dFree((char *)str); - str = dbuf->str; - len = dbuf->len; - dStr_free(dbuf, 0); - } - dStr_append_l(entry->Data, str, len); - - if (entry->UTF8Data) { - Dstr *dbuf = a_Decode_process(entry->CharsetDecoder, str, len); - dStr_append_l(entry->UTF8Data, dbuf->str, dbuf->len); - dStr_free(dbuf, 1); - } - - if (entry->TransferDecoder || entry->ContentDecoder) - dFree((char *)str); - - if (entry->Data->len) - entry->Flags &= ~CA_IsEmpty; - - Cache_process_queue(entry); } /* diff -r 7dc8813b2690 -r 94119bf06b22 src/cache.h --- a/src/cache.h Mon Jan 05 14:15:00 2009 -0300 +++ b/src/cache.h Wed Jan 07 15:53:19 2009 -0300 @@ -62,8 +62,7 @@ int a_Cache_get_buf(const DilloUrl *Url, char **PBuf, int *BufSize); void a_Cache_unref_buf(const DilloUrl *Url); const char *a_Cache_get_content_type(const DilloUrl *url); -const char *a_Cache_set_content_type(const DilloUrl *url, const char *ctype, - bool_t force); +const char *a_Cache_set_content_type(const DilloUrl *url, const char *ctype); uint_t a_Cache_get_flags(const DilloUrl *url); void a_Cache_process_dbuf(int Op, const char *buf, size_t buf_size, const DilloUrl *Url); diff -r 7dc8813b2690 -r 94119bf06b22 src/capi.c --- a/src/capi.c Mon Jan 05 14:15:00 2009 -0300 +++ b/src/capi.c Wed Jan 07 15:53:19 2009 -0300 @@ -421,10 +421,9 @@ /* * Set the Content-Type for the URL. */ -const char *a_Capi_set_content_type(const DilloUrl *url, const char *ctype, - bool_t force) +const char *a_Capi_set_content_type(const DilloUrl *url, const char *ctype) { - return a_Cache_set_content_type(url, ctype, force); + return a_Cache_set_content_type(url, ctype); } /* diff -r 7dc8813b2690 -r 94119bf06b22 src/capi.h --- a/src/capi.h Mon Jan 05 14:15:00 2009 -0300 +++ b/src/capi.h Wed Jan 07 15:53:19 2009 -0300 @@ -26,8 +26,7 @@ int a_Capi_get_buf(const DilloUrl *Url, char **PBuf, int *BufSize); void a_Capi_unref_buf(const DilloUrl *Url); const char *a_Capi_get_content_type(const DilloUrl *url); -const char *a_Capi_set_content_type(const DilloUrl *url, const char *ctype, - bool_t force); +const char *a_Capi_set_content_type(const DilloUrl *url, const char *ctype); int a_Capi_get_flags(const DilloUrl *Url); int a_Capi_dpi_send_cmd(DilloUrl *url, void *bw, char *cmd, char *server, int flags); diff -r 7dc8813b2690 -r 94119bf06b22 src/html.cc --- a/src/html.cc Mon Jan 05 14:15:00 2009 -0300 +++ b/src/html.cc Wed Jan 07 15:53:19 2009 -0300 @@ -583,7 +583,15 @@ char *buf = Buf + Start_Ofs; int bufsize = BufSize - Start_Ofs; + MSG("DilloHtml::write BufSize=%d Start_Ofs=%d\n", BufSize, Start_Ofs); +#if 0 + char *aux = dStrndup(Buf, BufSize); + MSG(" {%s}\n", aux); + dFree(aux); +#endif + dReturn_if_fail (dw != NULL); + dReturn_if_fail (stop_parser == FALSE); Start_Buf = Buf; token_start = Html_write_raw(this, buf, bufsize, Eof); @@ -1583,6 +1591,7 @@ if (html->repush_after_head) { html->stop_parser = true; + MSG(" [html->stop_parser = true]\n"); a_Nav_repush(html->bw); } } @@ -2789,9 +2798,8 @@ } else if (!dStrcasecmp(equiv, "content-type") && (content = a_Html_get_attr(html, tag, tagsize, "content"))) { if (a_Misc_content_type_cmp(html->content_type, content)) { - const bool_t force = FALSE; const char *new_content = - a_Capi_set_content_type(html->page_url, content, force); + a_Capi_set_content_type(html->page_url, content); /* Cannot ask cache whether the content type was changed, as * this code in another bw might have already changed it for us. */ @@ -2934,7 +2942,7 @@ } } -static void Html_tag_open_default(DilloHtml *html, const char *tag, int tagsize) +static void Html_tag_open_default(DilloHtml *html,const char *tag,int tagsize) { } @@ -3311,6 +3319,8 @@ char *start = tag + 1; /* discard the '<' */ int IsCloseTag = (*start == '/'); + dReturn_if_fail ( html->stop_parser == false ); + ni = a_Html_tag_index(start + IsCloseTag); if (ni == -1) { /* TODO: doctype parsing is a bit fuzzy, but enough for the time being */ @@ -3391,9 +3401,8 @@ } /* Call the open function for this tag */ + _MSG("Open : %s\n", Tags[ni].name); Tags[ni].open (html, tag, tagsize); - if (html->stop_parser) - break; /* Request inmediate close for elements with forbidden close tag. */ /* TODO: XHTML always requires close tags. A simple implementation @@ -3413,6 +3422,7 @@ (strchr(" \"'", tag[tagsize-3]) || /* [ "']/> */ (size_t)tagsize == strlen(Tags[ni].name) + 3))) { /* */ + _MSG("Close: %s\n", Tags[ni].name); Html_tag_cleanup_at_close(html, ni); /* This was a close tag */ html->ReqTagClose = false; From corvid at lavabit.com Wed Jan 7 20:27:13 2009 From: corvid at lavabit.com (corvid) Date: Wed Jan 7 20:29:13 2009 Subject: [Dillo-dev] Strange valgrind complain In-Reply-To: <20090107185655.GE20533@dillo.org> References: <20090105175103.GO27551@dillo.org> <20090106123710.GA16709@blob.baaderstrasse.com> <20090107161938.GD20533@dillo.org> <20090107185655.GE20533@dillo.org> Message-ID: <20090107192713.GI17125@local.gobigwest.com> The purpose of "force" was for users setting content type (or at least character encoding) through a dialog or menu or whatever. From Johannes.Hofmann at gmx.de Wed Jan 7 21:07:19 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Jan 7 21:15:25 2009 Subject: [Dillo-dev] Strange valgrind complain In-Reply-To: <20090107185655.GE20533@dillo.org> References: <20090105175103.GO27551@dillo.org> <20090106123710.GA16709@blob.baaderstrasse.com> <20090107161938.GD20533@dillo.org> <20090107185655.GE20533@dillo.org> Message-ID: <20090107200719.GA4349@blob.baaderstrasse.com> Hi Jorge, On Wed, Jan 07, 2009 at 03:56:55PM -0300, Jorge Arellano Cid wrote: > On Wed, Jan 07, 2009 at 01:19:38PM -0300, Jorge Arellano Cid wrote: > > On Tue, Jan 06, 2009 at 01:37:10PM +0100, Johannes Hofmann wrote: > > > On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > > > > Hi there, > > > > > > > > With Johannes, we're trying to find out why valgrind complains > > > > on the newest CSS branch with a certain URL: > > > > > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > > > > > $ less out > > > > > > > > There're several "Invalid read of size 1". > > > > > > > > It doesn't complain with a local file, nor after repush. It > > > > seems the timing is important, and maybe the decoder... > > > > > > The problem seems to be that at cache.c:1149 data is assigned > > > entry->UTF8Data, then during Html_callback() > > > a_Cache_set_content_type() get's called which since revision > > > 48029b8a5478 frees entry->UTF8Data. > > > That also explains why the earlier read of start went ok. > > > > > > I don't really now how to fix that though... > > > > Good news: now I have a big cleanup patch that gets rid of > > every valgrind complain on that page! > > > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ diffstat try2.diff > > cache.c | 157 ++++++++++++++++++++++++++++------------------------------------ > > cache.h | 3 - > > capi.c | 5 -- > > capi.h | 3 - > > html.cc | 22 ++++++-- > > 5 files changed, 89 insertions(+), 101 deletions(-) > > > > Let me polish it a bit more before you review and test it. > > Here go the patches attached. For test, review & commments. > Please apply styleengine-init-values first. This patch fixes these crashes for me. I think we should reintroduce the force parameter given corvid's comment. Thanks, Johannes From jcid at dillo.org Wed Jan 7 21:52:22 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Jan 7 21:52:27 2009 Subject: [Dillo-dev] Strange valgrind complain In-Reply-To: <20090107200719.GA4349@blob.baaderstrasse.com> References: <20090105175103.GO27551@dillo.org> <20090106123710.GA16709@blob.baaderstrasse.com> <20090107161938.GD20533@dillo.org> <20090107185655.GE20533@dillo.org> <20090107200719.GA4349@blob.baaderstrasse.com> Message-ID: <20090107205222.GF20533@dillo.org> On Wed, Jan 07, 2009 at 09:07:19PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Wed, Jan 07, 2009 at 03:56:55PM -0300, Jorge Arellano Cid wrote: > > On Wed, Jan 07, 2009 at 01:19:38PM -0300, Jorge Arellano Cid wrote: > > > On Tue, Jan 06, 2009 at 01:37:10PM +0100, Johannes Hofmann wrote: > > > > On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > > > > > Hi there, > > > > > > > > > > With Johannes, we're trying to find out why valgrind complains > > > > > on the newest CSS branch with a certain URL: > > > > > > > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > > > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > > > > > > > $ less out > > > > > > > > > > There're several "Invalid read of size 1". > > > > > > > > > > It doesn't complain with a local file, nor after repush. It > > > > > seems the timing is important, and maybe the decoder... > > > > > > > > The problem seems to be that at cache.c:1149 data is assigned > > > > entry->UTF8Data, then during Html_callback() > > > > a_Cache_set_content_type() get's called which since revision > > > > 48029b8a5478 frees entry->UTF8Data. > > > > That also explains why the earlier read of start went ok. > > > > > > > > I don't really now how to fix that though... > > > > > > Good news: now I have a big cleanup patch that gets rid of > > > every valgrind complain on that page! > > > > > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ diffstat try2.diff > > > cache.c | 157 ++++++++++++++++++++++++++++------------------------------------ > > > cache.h | 3 - > > > capi.c | 5 -- > > > capi.h | 3 - > > > html.cc | 22 ++++++-- > > > 5 files changed, 89 insertions(+), 101 deletions(-) > > > > > > Let me polish it a bit more before you review and test it. > > > > Here go the patches attached. For test, review & commments. > > Please apply styleengine-init-values first. > > This patch fixes these crashes for me. > I think we should reintroduce the force parameter given corvid's > comment. Yes, sure. It was stripped because it wasn't used. Good to know it works! -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Wed Jan 7 21:59:22 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Jan 7 22:07:00 2009 Subject: [Dillo-dev] one more crash Message-ID: <20090107205922.GA5046@blob.baaderstrasse.com> Sorry, but I'm seeing one more crash with current css-prototype. I think it has to do with abdae95b1c9e. I get it often - but not always e.g. on www.spiegel.de. Somehow layout is not set properly in the Image widget. Below is the stack. Cheers, Johannes Program terminated with signal 11, Segmentation fault. #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) at ../dw/layout.hh:241 241 return platform->createImgbuf (type, width, height); (gdb) bt #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) at ../dw/layout.hh:241 #1 0x0805f016 in a_Dicache_set_parms (url=0x28fa2a00, version=1, Image=0x2952d040, width=140, height=80, type=DILLO_IMG_TYPE_RGB) at dicache.c:268 #2 0x08072f2e in Jpeg_write (jpeg=0x28f85000, Buf=0x28f97000, BufSize=8000) at jpeg.c:299 #3 0x08072df4 in Jpeg_callback (Op=0, Client=0x297b4e20) at jpeg.c:246 #4 0x0805f407 in a_Dicache_callback (Op=0, Client=0x297b4e20) at dicache.c:396 #5 0x0805de7a in Cache_process_queue (entry=0x2952d080) at cache.c:1134 #6 0x0805d624 in a_Cache_process_dbuf (Op=0, buf=0x2955d000 "Z121\034\002\n", buf_size=7930, Url=0x2952d200) at cache.c:856 #7 0x08060af9 in a_Capi_ccc (Op=2, Branch=2, Dir=1, Info=0x294d6b40, Data1=0x286bb5b0, Data2=0x80fb16c) at capi.c:596 #8 0x08059f38 in a_Chain_fcb (Op=2, Info=0x294d6740, Data1=0x286bb5b0, Data2=0x80fb16c) at chain.c:112 #9 0x080794d2 in Dpi_parse_token (conn=0x2952d240) at dpi.c:219 #10 0x080797b2 in Dpi_process_dbuf (Op=0, Data1=0x286bbca0, conn=0x2952d240) at dpi.c:278 #11 0x0807a545 in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x294d6740, Data1=0x286bbca0, Data2=0x0) at dpi.c:668 #12 0x08059f38 in a_Chain_fcb (Op=2, Info=0x294d6fa0, Data1=0x286bbca0, Data2=0x0) at chain.c:112 #13 0x0807b197 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x294d6fa0, Data1=0x294d6560, Data2=0x0) at IO.c:414 #14 0x0807abdd in IO_read (io=0x294d6560) at IO.c:201 #15 0x0807acf7 in IO_callback (io=0x294d6560) at IO.c:266 #16 0x0807ad80 in IO_fd_read_cb (fd=64, data=0x8e) at IO.c:287 #17 0x080c8c99 in fltk::wait () #18 0x080c8e49 in fltk::run () #19 0x0804f19c in main (argc=1, argv=Cannot access memory at address 0x3c ) at dillo.cc:334 (gdb) From jcid at dillo.org Wed Jan 7 23:08:35 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Jan 7 23:08:40 2009 Subject: [Dillo-dev] one more crash In-Reply-To: <20090107205922.GA5046@blob.baaderstrasse.com> References: <20090107205922.GA5046@blob.baaderstrasse.com> Message-ID: <20090107220835.GG20533@dillo.org> On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > Sorry, but I'm seeing one more crash with > current css-prototype. I think it has to do with abdae95b1c9e. > I get it often - but not always e.g. on www.spiegel.de. > Somehow layout is not set properly in the Image widget. > Below is the stack. Hmm, I haven't been able to reproduce it yet... Do you mean it never crashes without abdae95b1c9e? -- Cheers Jorge.- From jcid at dillo.org Wed Jan 7 23:54:51 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Jan 7 23:55:00 2009 Subject: [Dillo-dev] one more crash In-Reply-To: <20090107205922.GA5046@blob.baaderstrasse.com> References: <20090107205922.GA5046@blob.baaderstrasse.com> Message-ID: <20090107225451.GH20533@dillo.org> On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > Sorry, but I'm seeing one more crash with > current css-prototype. Thanks for the politeness. It's good to be testing. I've long forgotten the mess that image processing code became. That's why I've taken the time to try to push code cleanups... > Program terminated with signal 11, Segmentation fault. > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > at ../dw/layout.hh:241 > 241 return platform->createImgbuf (type, width, height); > (gdb) bt > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > at ../dw/layout.hh:241 > #1 0x0805f016 in a_Dicache_set_parms (url=0x28fa2a00, version=1, Image=0x2952d040, width=140, height=80, > type=DILLO_IMG_TYPE_RGB) at dicache.c:268 > #2 0x08072f2e in Jpeg_write (jpeg=0x28f85000, Buf=0x28f97000, BufSize=8000) at jpeg.c:299 > #3 0x08072df4 in Jpeg_callback (Op=0, Client=0x297b4e20) at jpeg.c:246 > #4 0x0805f407 in a_Dicache_callback (Op=0, Client=0x297b4e20) at dicache.c:396 The layout belongs to the bw, so it shouldn't dissappear with repush. It looks like Image is already freed. Let's see: jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_ref image.cc:void a_Image_ref(DilloImage *Image) image.hh:void a_Image_ref(DilloImage *Image); gif.c: a_Image_ref(web->Image); jpeg.c: a_Image_ref(web->Image); png.c: a_Image_ref(web->Image); jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_unref html.cc: a_Image_unref(li->image); image.cc:void a_Image_unref(DilloImage *Image) image.cc: a_Image_unref(Image); image.hh:void a_Image_unref(DilloImage *Image); web.cc: a_Image_unref(web->Image); this looks like unbalanced ref/unref for the Image. Gif/Jpeg/Png match with image.cc The initial Ref=1 matches web.cc html.cc matches ?? Please test with one or two extra a_Image_ref() at dicache.c:269, or at your choice, on the proper place! :-) -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Thu Jan 8 13:37:26 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Thu Jan 8 13:45:04 2009 Subject: [Dillo-dev] one more crash In-Reply-To: <20090107225451.GH20533@dillo.org> References: <20090107205922.GA5046@blob.baaderstrasse.com> <20090107225451.GH20533@dillo.org> Message-ID: <20090108123726.GA23125@blob.baaderstrasse.com> On Wed, Jan 07, 2009 at 07:54:51PM -0300, Jorge Arellano Cid wrote: > On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > > Sorry, but I'm seeing one more crash with > > current css-prototype. > > Thanks for the politeness. > It's good to be testing. > > I've long forgotten the mess that image processing code became. > That's why I've taken the time to try to push code cleanups... > > > > Program terminated with signal 11, Segmentation fault. > > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > > at ../dw/layout.hh:241 > > 241 return platform->createImgbuf (type, width, height); > > (gdb) bt > > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > > at ../dw/layout.hh:241 > > #1 0x0805f016 in a_Dicache_set_parms (url=0x28fa2a00, version=1, Image=0x2952d040, width=140, height=80, > > type=DILLO_IMG_TYPE_RGB) at dicache.c:268 > > #2 0x08072f2e in Jpeg_write (jpeg=0x28f85000, Buf=0x28f97000, BufSize=8000) at jpeg.c:299 > > #3 0x08072df4 in Jpeg_callback (Op=0, Client=0x297b4e20) at jpeg.c:246 > > #4 0x0805f407 in a_Dicache_callback (Op=0, Client=0x297b4e20) at dicache.c:396 > > The layout belongs to the bw, so it shouldn't dissappear with > repush. It looks like Image is already freed. > > Let's see: > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_ref > image.cc:void a_Image_ref(DilloImage *Image) > image.hh:void a_Image_ref(DilloImage *Image); > gif.c: a_Image_ref(web->Image); > jpeg.c: a_Image_ref(web->Image); > png.c: a_Image_ref(web->Image); > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_unref > html.cc: a_Image_unref(li->image); > image.cc:void a_Image_unref(DilloImage *Image) > image.cc: a_Image_unref(Image); > image.hh:void a_Image_unref(DilloImage *Image); > web.cc: a_Image_unref(web->Image); > > this looks like unbalanced ref/unref for the Image. > Gif/Jpeg/Png match with image.cc > The initial Ref=1 matches web.cc > html.cc matches ?? > > Please test with one or two extra a_Image_ref() > at dicache.c:269, or at your choice, on the proper place! :-) That didn't help. Backing out abdae95b1c9e however helps so far. Cheers, Johannes From r00t at constancy.org Thu Jan 8 15:15:42 2009 From: r00t at constancy.org (Thorben Thuermer) Date: Thu Jan 8 15:15:49 2009 Subject: [Dillo-dev] dillo about to be dropped from debian Message-ID: <20090108151542.3073099a.r00t@constancy.org> FYI: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=510348 it seems that dillo is about to be dropped from debian, because * ssl lacks proper certificate verification * it still uses gtk1.2 (personally, the first never bothered me, and i consider the second a _feature_) Greetings, Thorben Thuermer From jcid at dillo.org Thu Jan 8 17:31:13 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Jan 8 17:31:21 2009 Subject: [Dillo-dev] one more crash In-Reply-To: <20090108123726.GA23125@blob.baaderstrasse.com> References: <20090107205922.GA5046@blob.baaderstrasse.com> <20090107225451.GH20533@dillo.org> <20090108123726.GA23125@blob.baaderstrasse.com> Message-ID: <20090108163113.GI20533@dillo.org> On Thu, Jan 08, 2009 at 01:37:26PM +0100, Johannes Hofmann wrote: > On Wed, Jan 07, 2009 at 07:54:51PM -0300, Jorge Arellano Cid wrote: > > On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > > > Sorry, but I'm seeing one more crash with > > > current css-prototype. > > > > Thanks for the politeness. > > It's good to be testing. > > > > I've long forgotten the mess that image processing code became. > > That's why I've taken the time to try to push code cleanups... > > > > > > > Program terminated with signal 11, Segmentation fault. > > > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > > > at ../dw/layout.hh:241 > > > 241 return platform->createImgbuf (type, width, height); > > > (gdb) bt > > > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > > > at ../dw/layout.hh:241 > > > #1 0x0805f016 in a_Dicache_set_parms (url=0x28fa2a00, version=1, Image=0x2952d040, width=140, height=80, > > > type=DILLO_IMG_TYPE_RGB) at dicache.c:268 > > > #2 0x08072f2e in Jpeg_write (jpeg=0x28f85000, Buf=0x28f97000, BufSize=8000) at jpeg.c:299 > > > #3 0x08072df4 in Jpeg_callback (Op=0, Client=0x297b4e20) at jpeg.c:246 > > > #4 0x0805f407 in a_Dicache_callback (Op=0, Client=0x297b4e20) at dicache.c:396 > > > > The layout belongs to the bw, so it shouldn't dissappear with > > repush. It looks like Image is already freed. > > > > Let's see: > > > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_ref > > image.cc:void a_Image_ref(DilloImage *Image) > > image.hh:void a_Image_ref(DilloImage *Image); > > gif.c: a_Image_ref(web->Image); > > jpeg.c: a_Image_ref(web->Image); > > png.c: a_Image_ref(web->Image); > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_unref > > html.cc: a_Image_unref(li->image); > > image.cc:void a_Image_unref(DilloImage *Image) > > image.cc: a_Image_unref(Image); > > image.hh:void a_Image_unref(DilloImage *Image); > > web.cc: a_Image_unref(web->Image); > > > > this looks like unbalanced ref/unref for the Image. > > Gif/Jpeg/Png match with image.cc > > The initial Ref=1 matches web.cc > > html.cc matches ?? > > > > Please test with one or two extra a_Image_ref() > > at dicache.c:269, or at your choice, on the proper place! :-) > > That didn't help. Backing out abdae95b1c9e however helps so far. OK, let's back it out and see if it becomes stable again. -- Cheers Jorge.- From jcid at dillo.org Thu Jan 8 20:02:01 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Jan 8 20:02:43 2009 Subject: [Dillo-dev] Dillo in Debian Message-ID: <20090108190201.GJ20533@dillo.org> Hi Wookey, A post in dillo-dev made me aware of this thread: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=510348 Thanks for your comment ;-) Some technical facts (all available from dillo.org): * dillo-0.8.x is unmaintained * dillo-2.x is the official stable branch * dillo-2.x uses FLTK2 not GTK2 as stated in the thread IMHO it'd be good to have dillo-0.8.x in Lenny, at least until dillo-2.x makes its way into Debian. We've been working on this branch for more than a year and it's way better than the former (details in the website). I'm aware of the problem distros have with including statically linked packages, and it looks like dillo-2.x will be left out of them until this issue is solved. Unfortunately FLTK-2.0 is stalled and an official release of it is nowhere near in the future. OTOH, an active set of developers is pushing FLTK-1.3.x very fast. This branch provides more or less the same FLTK-2.0 does. It's being actively developed, is less buggy and more stable, and will most probably be released soon (I'm yet to ask the team about dates). At some point in time we'll be migrating to FLTK-1.3.x (it has almost the same API), and hopefully then it'll be easier to include dillo in Debian. If you make progress with the certificate patch, please let us know. We're fully devoted to CSS now, and have no SSL expert in the team :( -- On a personal level, I'd love to have Dillo used in Debian as a help browser. This is, since a long time ago I've noticed applications come with almost no help (F1 button in the old days) and help drives you to an "About" window. But OTOH they have very good HTML docs (usually in usr/share/), that could provide for accurate context-sensitive help pages. The problem is they don't hook a web browser to the help button because a bloated app. that takes a long time to start, only to crawl the computer afterwards, is the last thing a developer hopes as her end user experience. There's the possibility of having a simple API to remote control the browser so the same instance is used. Dillo is fast, lean, and low on library dependencies. Any doubts, just don't hesitate to ask. -- Cheers Jorge.- From akemnade at tzi.de Thu Jan 8 22:53:24 2009 From: akemnade at tzi.de (Andreas Kemnade) Date: Thu Jan 8 22:54:03 2009 Subject: [Dillo-dev] Dillo in Debian In-Reply-To: <20090108190201.GJ20533@dillo.org> References: <20090108190201.GJ20533@dillo.org> Message-ID: <20090108225324.3686c106@kemnade.info> Hi, a status update: I just got a notice from the official dillo package maintainer that fltk2 will be added to debian. So I think the chances for dillo 2.0 to go into debian (not lenny) will be good. Greetings Andreas Kemnade -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available Url : /pipermail/attachments/20090108/1bf03c6a/signature.pgp From Johannes.Hofmann at gmx.de Fri Jan 9 12:47:45 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Fri Jan 9 12:55:22 2009 Subject: [Dillo-dev] one more crash In-Reply-To: <20090108163113.GI20533@dillo.org> References: <20090107205922.GA5046@blob.baaderstrasse.com> <20090107225451.GH20533@dillo.org> <20090108123726.GA23125@blob.baaderstrasse.com> <20090108163113.GI20533@dillo.org> Message-ID: <20090109114745.GB27551@blob.baaderstrasse.com> On Thu, Jan 08, 2009 at 01:31:13PM -0300, Jorge Arellano Cid wrote: > On Thu, Jan 08, 2009 at 01:37:26PM +0100, Johannes Hofmann wrote: > > On Wed, Jan 07, 2009 at 07:54:51PM -0300, Jorge Arellano Cid wrote: > > > On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > > > > Sorry, but I'm seeing one more crash with > > > > current css-prototype. > > > > > > Thanks for the politeness. > > > It's good to be testing. > > > > > > I've long forgotten the mess that image processing code became. > > > That's why I've taken the time to try to push code cleanups... > > > > > > > > > > Program terminated with signal 11, Segmentation fault. > > > > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > > > > at ../dw/layout.hh:241 > > > > 241 return platform->createImgbuf (type, width, height); > > > > (gdb) bt > > > > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > > > > at ../dw/layout.hh:241 > > > > #1 0x0805f016 in a_Dicache_set_parms (url=0x28fa2a00, version=1, Image=0x2952d040, width=140, height=80, > > > > type=DILLO_IMG_TYPE_RGB) at dicache.c:268 > > > > #2 0x08072f2e in Jpeg_write (jpeg=0x28f85000, Buf=0x28f97000, BufSize=8000) at jpeg.c:299 > > > > #3 0x08072df4 in Jpeg_callback (Op=0, Client=0x297b4e20) at jpeg.c:246 > > > > #4 0x0805f407 in a_Dicache_callback (Op=0, Client=0x297b4e20) at dicache.c:396 > > > > > > The layout belongs to the bw, so it shouldn't dissappear with > > > repush. It looks like Image is already freed. > > > > > > Let's see: > > > > > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_ref > > > image.cc:void a_Image_ref(DilloImage *Image) > > > image.hh:void a_Image_ref(DilloImage *Image); > > > gif.c: a_Image_ref(web->Image); > > > jpeg.c: a_Image_ref(web->Image); > > > png.c: a_Image_ref(web->Image); > > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_unref > > > html.cc: a_Image_unref(li->image); > > > image.cc:void a_Image_unref(DilloImage *Image) > > > image.cc: a_Image_unref(Image); > > > image.hh:void a_Image_unref(DilloImage *Image); > > > web.cc: a_Image_unref(web->Image); > > > > > > this looks like unbalanced ref/unref for the Image. > > > Gif/Jpeg/Png match with image.cc > > > The initial Ref=1 matches web.cc > > > html.cc matches ?? > > > > > > Please test with one or two extra a_Image_ref() > > > at dicache.c:269, or at your choice, on the proper place! :-) > > > > That didn't help. Backing out abdae95b1c9e however helps so far. > > OK, let's back it out and see if it becomes stable again. It's been very stable for me after the backout, so I pushed that to css-prototype. We can come back to this later, if someone figures out the root of the problem. Cheers, Johannes From jcid at dillo.org Fri Jan 9 18:00:20 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Jan 9 18:04:32 2009 Subject: [Dillo-dev] IMG ratio Message-ID: <20090109170020.GK20533@dillo.org> Hi Johannes, Now that I have the image process mostly in my head, I'd like to hook correct image ratio scaling when only one of width/height is given. I see scaling done with the styleengine in a_Html_add_new_image but 'props' goes away when popping the tag. How do I handle this? Do I have to preserve props in the stack until I have the final data, or is there another way? Please explain. -- Cheers Jorge.- From devidfil at gmail.com Fri Jan 9 18:06:43 2009 From: devidfil at gmail.com (Devid Antonio Filoni) Date: Fri Jan 9 18:06:47 2009 Subject: [Dillo-dev] RE: Dillo in Debian Message-ID: <64a208ca0901090906w55f3a8b8xccd52c1d17a84df5@mail.gmail.com> Hi, I'm the current dillo Debian maintainer. I know, dillo 2.0 isn't in Debian right now but it isn't caused by me, fltk2 package is missing in Debian so I can't upload the 2.0 version right now. However I've done the fltk2 package for Debian and if all is ok it will uploaded (and accepted) in Debian as soon as possible (but it won't be in Lenny). If you will switch dillo to fltk1.3 then the problem will be the same because actually Debian doesn't have the 1.3 version of fltk (only 1.1) so I will need to work on a new package for fltk1.3 and this will require time (there is no a good documentation about how to work on a static lib package). So please continue to use fltk2. I'm sorry for the delay. Devid Antonio Filoni From Johannes.Hofmann at gmx.de Fri Jan 9 18:04:09 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Fri Jan 9 18:11:49 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090109170020.GK20533@dillo.org> References: <20090109170020.GK20533@dillo.org> Message-ID: <20090109170409.GA2081@blob.baaderstrasse.com> Hi Jorge, On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > Now that I have the image process mostly in my head, I'd like > to hook correct image ratio scaling when only one of width/height > is given. > > I see scaling done with the styleengine in a_Html_add_new_image > but 'props' goes away when popping the tag. How do I handle this? > > Do I have to preserve props in the stack until I have the > final data, or is there another way? Please explain. What about just setting the data that is available (width, height, or both) and let the image do the rest? It already handles the case where neither width nor height are given. So it should be possible to make it work with just width or height too. Am I missing something? Cheers, Johannes From jcid at dillo.org Fri Jan 9 20:11:36 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Jan 9 20:11:57 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090109170409.GA2081@blob.baaderstrasse.com> References: <20090109170020.GK20533@dillo.org> <20090109170409.GA2081@blob.baaderstrasse.com> Message-ID: <20090109191136.GL20533@dillo.org> On Fri, Jan 09, 2009 at 06:04:09PM +0100, Hofmann Johannes wrote: > Hi Jorge, > > On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > Now that I have the image process mostly in my head, I'd like > > to hook correct image ratio scaling when only one of width/height > > is given. > > > > I see scaling done with the styleengine in a_Html_add_new_image > > but 'props' goes away when popping the tag. How do I handle this? > > > > Do I have to preserve props in the stack until I have the > > final data, or is there another way? Please explain. > > What about just setting the data that is available (width, height, > or both) and let the image do the rest? > It already handles the case where neither width nor height are > given. > So it should be possible to make it work with just width or > height too. Am I missing something? Yes, the problem is when only one of the dimenssions is given, bacause the other one is only known at image arrival time (much later). i.e. Only once the real dimenssions of the image are known it is possible to calculate the missing one. At this time, props is long gone, and thus the question. -- Cheers Jorge.- From jcid at dillo.org Fri Jan 9 20:32:33 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Jan 9 20:32:38 2009 Subject: [Dillo-dev] CSS freeze Message-ID: <20090109193232.GM20533@dillo.org> Hi, Current and former CSS protos freeze on this page: http://www.instantfundas.com/2007/12/5-opera-tricks-you-did-not-know-about.html -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Fri Jan 9 20:27:17 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Fri Jan 9 20:34:54 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090109191136.GL20533@dillo.org> References: <20090109170020.GK20533@dillo.org> <20090109170409.GA2081@blob.baaderstrasse.com> <20090109191136.GL20533@dillo.org> Message-ID: <20090109192717.GA886@blob.baaderstrasse.com> On Fri, Jan 09, 2009 at 04:11:36PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 09, 2009 at 06:04:09PM +0100, Hofmann Johannes wrote: > > Hi Jorge, > > > > On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > > > Hi Johannes, > > > > > > Now that I have the image process mostly in my head, I'd like > > > to hook correct image ratio scaling when only one of width/height > > > is given. > > > > > > I see scaling done with the styleengine in a_Html_add_new_image > > > but 'props' goes away when popping the tag. How do I handle this? > > > > > > Do I have to preserve props in the stack until I have the > > > final data, or is there another way? Please explain. > > > > What about just setting the data that is available (width, height, > > or both) and let the image do the rest? > > It already handles the case where neither width nor height are > > given. > > So it should be possible to make it work with just width or > > height too. Am I missing something? > > Yes, the problem is when only one of the dimenssions is given, > bacause the other one is only known at image arrival time (much > later). > > i.e. Only once the real dimenssions of the image are known it > is possible to calculate the missing one. At this time, props is > long gone, and thus the question. Yes, props is gone, but - if not overridden - it's data will have made it into the style object associated with the image. I guess the calculation of the missing dimension could be done in Image::sizeRequestImpl() or Image::sizeAllocateImpl() but I haven't looked at it enough to know exactly. Cheers, Johannes From Johannes.Hofmann at gmx.de Fri Jan 9 20:40:49 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Fri Jan 9 20:49:02 2009 Subject: [Dillo-dev] CSS freeze In-Reply-To: <20090109193232.GM20533@dillo.org> References: <20090109193232.GM20533@dillo.org> Message-ID: <20090109194049.GB886@blob.baaderstrasse.com> Hi Jorge, On Fri, Jan 09, 2009 at 04:32:33PM -0300, Jorge Arellano Cid wrote: > Hi, > > Current and former CSS protos freeze on this page: > > http://www.instantfundas.com/2007/12/5-opera-tricks-you-did-not-know-about.html I know that one... It is looping in the CSS parser. table td, { margin: 0em } is enough to reproduce the problem. Fixes welcome. The whole CSS parsing code is a bit fragile and it would be nice to make sure somehow that it never loops on any input. Fixes and suggestions welcome :-) Cheers, Johannes From Johannes.Hofmann at gmx.de Fri Jan 9 20:40:49 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Fri Jan 9 20:49:02 2009 Subject: [Dillo-dev] CSS freeze In-Reply-To: <20090109193232.GM20533@dillo.org> References: <20090109193232.GM20533@dillo.org> Message-ID: <20090109194049.GB886@blob.baaderstrasse.com> Hi Jorge, On Fri, Jan 09, 2009 at 04:32:33PM -0300, Jorge Arellano Cid wrote: > Hi, > > Current and former CSS protos freeze on this page: > > http://www.instantfundas.com/2007/12/5-opera-tricks-you-did-not-know-about.html I know that one... It is looping in the CSS parser. table td, { margin: 0em } is enough to reproduce the problem. Fixes welcome. The whole CSS parsing code is a bit fragile and it would be nice to make sure somehow that it never loops on any input. Fixes and suggestions welcome :-) Cheers, Johannes From jcid at dillo.org Fri Jan 9 22:53:12 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Jan 9 22:53:16 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090109192717.GA886@blob.baaderstrasse.com> References: <20090109170020.GK20533@dillo.org> <20090109170409.GA2081@blob.baaderstrasse.com> <20090109191136.GL20533@dillo.org> <20090109192717.GA886@blob.baaderstrasse.com> Message-ID: <20090109215311.GN20533@dillo.org> On Fri, Jan 09, 2009 at 08:27:17PM +0100, Hofmann Johannes wrote: > On Fri, Jan 09, 2009 at 04:11:36PM -0300, Jorge Arellano Cid wrote: > > On Fri, Jan 09, 2009 at 06:04:09PM +0100, Hofmann Johannes wrote: > > > Hi Jorge, > > > > > > On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > > > > Hi Johannes, > > > > > > > > Now that I have the image process mostly in my head, I'd like > > > > to hook correct image ratio scaling when only one of width/height > > > > is given. > > > > > > > > I see scaling done with the styleengine in a_Html_add_new_image > > > > but 'props' goes away when popping the tag. How do I handle this? > > > > > > > > Do I have to preserve props in the stack until I have the > > > > final data, or is there another way? Please explain. > > > > > > What about just setting the data that is available (width, height, > > > or both) and let the image do the rest? > > > It already handles the case where neither width nor height are > > > given. > > > So it should be possible to make it work with just width or > > > height too. Am I missing something? > > > > Yes, the problem is when only one of the dimenssions is given, > > bacause the other one is only known at image arrival time (much > > later). > > > > i.e. Only once the real dimenssions of the image are known it > > is possible to calculate the missing one. At this time, props is > > long gone, and thus the question. > > Yes, props is gone, but - if not overridden - it's data will have > made it into the style object associated with the image. How do I get to the style object of a dw::Image? (once endElement has been called on it) > I guess the calculation of the missing dimension could be done in > Image::sizeRequestImpl() or Image::sizeAllocateImpl() but I haven't > looked at it enough to know exactly. I guess we're in a situation were you know easily the style part and I know how to hook the rest, hence the conversation! :-) The HTML-requested size can be stored in the DilloImage structure, and updated in a_Image_set_parms(). The latter is called by the dicache when the original width and height are known. So at this point we have the requested size, original size and dw:Image well defined. -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Fri Jan 9 23:58:54 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Jan 10 00:06:33 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090109215311.GN20533@dillo.org> References: <20090109170020.GK20533@dillo.org> <20090109170409.GA2081@blob.baaderstrasse.com> <20090109191136.GL20533@dillo.org> <20090109192717.GA886@blob.baaderstrasse.com> <20090109215311.GN20533@dillo.org> Message-ID: <20090109225853.GA895@blob.baaderstrasse.com> On Fri, Jan 09, 2009 at 06:53:12PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 09, 2009 at 08:27:17PM +0100, Hofmann Johannes wrote: > > On Fri, Jan 09, 2009 at 04:11:36PM -0300, Jorge Arellano Cid wrote: > > > On Fri, Jan 09, 2009 at 06:04:09PM +0100, Hofmann Johannes wrote: > > > > Hi Jorge, > > > > > > > > On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > > > > > Hi Johannes, > > > > > > > > > > Now that I have the image process mostly in my head, I'd like > > > > > to hook correct image ratio scaling when only one of width/height > > > > > is given. > > > > > > > > > > I see scaling done with the styleengine in a_Html_add_new_image > > > > > but 'props' goes away when popping the tag. How do I handle this? > > > > > > > > > > Do I have to preserve props in the stack until I have the > > > > > final data, or is there another way? Please explain. > > > > > > > > What about just setting the data that is available (width, height, > > > > or both) and let the image do the rest? > > > > It already handles the case where neither width nor height are > > > > given. > > > > So it should be possible to make it work with just width or > > > > height too. Am I missing something? > > > > > > Yes, the problem is when only one of the dimenssions is given, > > > bacause the other one is only known at image arrival time (much > > > later). > > > > > > i.e. Only once the real dimenssions of the image are known it > > > is possible to calculate the missing one. At this time, props is > > > long gone, and thus the question. > > > > Yes, props is gone, but - if not overridden - it's data will have > > made it into the style object associated with the image. > > How do I get to the style object of a dw::Image? > (once endElement has been called on it) > > > I guess the calculation of the missing dimension could be done in > > Image::sizeRequestImpl() or Image::sizeAllocateImpl() but I haven't > > looked at it enough to know exactly. > > I guess we're in a situation were you know easily the style > part and I know how to hook the rest, hence the conversation! :-) > > The HTML-requested size can be stored in the DilloImage structure, > and updated in a_Image_set_parms(). The latter is called by the dicache > when the original width and height are known. So at this point we have > the requested size, original size and dw:Image well defined. I think the html part needs not be changed. Everything is available in style already. I've attached a quick patch that seems to work for fixed sizes. It does not handle something like width="50%" however. Cheers, Johannes -------------- next part -------------- diff -r cdfdb006f193 dw/image.cc --- a/dw/image.cc Mon Jan 05 17:12:43 2009 -0300 +++ b/dw/image.cc Fri Jan 09 23:55:50 2009 +0100 @@ -144,9 +144,21 @@ Image::~Image() void Image::sizeRequestImpl (core::Requisition *requisition) { if (buffer) { - requisition->width = buffer->getRootWidth (); - requisition->ascent = buffer->getRootHeight (); - requisition->descent = 0; + if (core::style::isAbsLength (getStyle ()->width)) { + requisition->width = core::style::absLengthVal (getStyle ()->width); + requisition->ascent = buffer->getRootHeight () * + requisition->width / buffer->getRootWidth (); + requisition->descent = 0; + } else if (core::style::isAbsLength (getStyle ()->height)) { + requisition->ascent = core::style::absLengthVal (getStyle ()->height); + requisition->width = buffer->getRootWidth () * + requisition->ascent / buffer->getRootHeight (); + requisition->descent = 0; + } else { + requisition->width = buffer->getRootWidth (); + requisition->ascent = buffer->getRootHeight (); + requisition->descent = 0; + } } else { if(altText && altText[0]) { if (altTextWidth == -1) From Johannes.Hofmann at gmx.de Sat Jan 10 14:07:57 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Jan 10 14:15:38 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090109225853.GA895@blob.baaderstrasse.com> References: <20090109170020.GK20533@dillo.org> <20090109170409.GA2081@blob.baaderstrasse.com> <20090109191136.GL20533@dillo.org> <20090109192717.GA886@blob.baaderstrasse.com> <20090109215311.GN20533@dillo.org> <20090109225853.GA895@blob.baaderstrasse.com> Message-ID: <20090110130756.GA1150@blob.baaderstrasse.com> On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > On Fri, Jan 09, 2009 at 06:53:12PM -0300, Jorge Arellano Cid wrote: > > On Fri, Jan 09, 2009 at 08:27:17PM +0100, Hofmann Johannes wrote: > > > On Fri, Jan 09, 2009 at 04:11:36PM -0300, Jorge Arellano Cid wrote: > > > > On Fri, Jan 09, 2009 at 06:04:09PM +0100, Hofmann Johannes wrote: > > > > > Hi Jorge, > > > > > > > > > > On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > > > > > > Hi Johannes, > > > > > > > > > > > > Now that I have the image process mostly in my head, I'd like > > > > > > to hook correct image ratio scaling when only one of width/height > > > > > > is given. > > > > > > > > > > > > I see scaling done with the styleengine in a_Html_add_new_image > > > > > > but 'props' goes away when popping the tag. How do I handle this? > > > > > > > > > > > > Do I have to preserve props in the stack until I have the > > > > > > final data, or is there another way? Please explain. > > > > > > > > > > What about just setting the data that is available (width, height, > > > > > or both) and let the image do the rest? > > > > > It already handles the case where neither width nor height are > > > > > given. > > > > > So it should be possible to make it work with just width or > > > > > height too. Am I missing something? > > > > > > > > Yes, the problem is when only one of the dimenssions is given, > > > > bacause the other one is only known at image arrival time (much > > > > later). > > > > > > > > i.e. Only once the real dimenssions of the image are known it > > > > is possible to calculate the missing one. At this time, props is > > > > long gone, and thus the question. > > > > > > Yes, props is gone, but - if not overridden - it's data will have > > > made it into the style object associated with the image. > > > > How do I get to the style object of a dw::Image? > > (once endElement has been called on it) > > > > > I guess the calculation of the missing dimension could be done in > > > Image::sizeRequestImpl() or Image::sizeAllocateImpl() but I haven't > > > looked at it enough to know exactly. > > > > I guess we're in a situation were you know easily the style > > part and I know how to hook the rest, hence the conversation! :-) > > > > The HTML-requested size can be stored in the DilloImage structure, > > and updated in a_Image_set_parms(). The latter is called by the dicache > > when the original width and height are known. So at this point we have > > the requested size, original size and dw:Image well defined. > > I think the html part needs not be changed. Everything is available > in style already. > I've attached a quick patch that seems to work for fixed sizes. > It does not handle something like width="50%" however. As the patch works rather well for me and improves the current behaviour, I've cleaned it up a bit (avoiding a possible division by 0) for inclusion into main. Cheers, Johannes -------------- next part -------------- diff -r cdfdb006f193 dw/image.cc --- a/dw/image.cc Mon Jan 05 17:12:43 2009 -0300 +++ b/dw/image.cc Sat Jan 10 14:06:12 2009 +0100 @@ -144,8 +144,24 @@ Image::~Image() void Image::sizeRequestImpl (core::Requisition *requisition) { if (buffer) { - requisition->width = buffer->getRootWidth (); - requisition->ascent = buffer->getRootHeight (); + if (getStyle ()->height == core::style::LENGTH_AUTO && + core::style::isAbsLength (getStyle ()->width) && + buffer->getRootWidth () > 0) { + // preserve aspect ratio when only width is given + requisition->width = core::style::absLengthVal (getStyle ()->width); + requisition->ascent = buffer->getRootHeight () * + requisition->width / buffer->getRootWidth (); + } else if (getStyle ()->width == core::style::LENGTH_AUTO && + core::style::isAbsLength (getStyle ()->height) && + buffer->getRootHeight () > 0) { + // preserve aspect ratio when only height is given + requisition->ascent = core::style::absLengthVal (getStyle ()->height); + requisition->width = buffer->getRootWidth () * + requisition->ascent / buffer->getRootHeight (); + } else { + requisition->width = buffer->getRootWidth (); + requisition->ascent = buffer->getRootHeight (); + } requisition->descent = 0; } else { if(altText && altText[0]) { From jcid at dillo.org Sat Jan 10 15:33:48 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sat Jan 10 15:34:15 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090110130756.GA1150@blob.baaderstrasse.com> References: <20090109170020.GK20533@dillo.org> <20090109170409.GA2081@blob.baaderstrasse.com> <20090109191136.GL20533@dillo.org> <20090109192717.GA886@blob.baaderstrasse.com> <20090109215311.GN20533@dillo.org> <20090109225853.GA895@blob.baaderstrasse.com> <20090110130756.GA1150@blob.baaderstrasse.com> Message-ID: <20090110143348.GQ20533@dillo.org> On Sat, Jan 10, 2009 at 02:07:57PM +0100, Hofmann Johannes wrote: > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > On Fri, Jan 09, 2009 at 06:53:12PM -0300, Jorge Arellano Cid wrote: > > > On Fri, Jan 09, 2009 at 08:27:17PM +0100, Hofmann Johannes wrote: > > > > On Fri, Jan 09, 2009 at 04:11:36PM -0300, Jorge Arellano Cid wrote: > > > > > On Fri, Jan 09, 2009 at 06:04:09PM +0100, Hofmann Johannes wrote: > > > > > > Hi Jorge, > > > > > > > > > > > > On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > > > > > > > Hi Johannes, > > > > > > > > > > > > > > Now that I have the image process mostly in my head, I'd like > > > > > > > to hook correct image ratio scaling when only one of width/height > > > > > > > is given. > > > > > > > > > > > > > > I see scaling done with the styleengine in a_Html_add_new_image > > > > > > > but 'props' goes away when popping the tag. How do I handle this? > > > > > > > > > > > > > > Do I have to preserve props in the stack until I have the > > > > > > > final data, or is there another way? Please explain. > > > > > > > > > > > > What about just setting the data that is available (width, height, > > > > > > or both) and let the image do the rest? > > > > > > It already handles the case where neither width nor height are > > > > > > given. > > > > > > So it should be possible to make it work with just width or > > > > > > height too. Am I missing something? > > > > > > > > > > Yes, the problem is when only one of the dimenssions is given, > > > > > bacause the other one is only known at image arrival time (much > > > > > later). > > > > > > > > > > i.e. Only once the real dimenssions of the image are known it > > > > > is possible to calculate the missing one. At this time, props is > > > > > long gone, and thus the question. > > > > > > > > Yes, props is gone, but - if not overridden - it's data will have > > > > made it into the style object associated with the image. > > > > > > How do I get to the style object of a dw::Image? > > > (once endElement has been called on it) > > > > > > > I guess the calculation of the missing dimension could be done in > > > > Image::sizeRequestImpl() or Image::sizeAllocateImpl() but I haven't > > > > looked at it enough to know exactly. > > > > > > I guess we're in a situation were you know easily the style > > > part and I know how to hook the rest, hence the conversation! :-) > > > > > > The HTML-requested size can be stored in the DilloImage structure, > > > and updated in a_Image_set_parms(). The latter is called by the dicache > > > when the original width and height are known. So at this point we have > > > the requested size, original size and dw:Image well defined. > > > > I think the html part needs not be changed. Everything is available > > in style already. > > I've attached a quick patch that seems to work for fixed sizes. > > It does not handle something like width="50%" however. > > As the patch works rather well for me and improves the current > behaviour, I've cleaned it up a bit (avoiding a possible division by > 0) for inclusion into main. Committed! I'm stuck chasing what looks like a weird bug in the image code... (not from this patch). -- Cheers Jorge.- From corvid at lavabit.com Sun Jan 11 02:00:14 2009 From: corvid at lavabit.com (corvid) Date: Sun Jan 11 02:02:17 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090110130756.GA1150@blob.baaderstrasse.com> References: <20090109170020.GK20533@dillo.org> <20090109170409.GA2081@blob.baaderstrasse.com> <20090109191136.GL20533@dillo.org> <20090109192717.GA886@blob.baaderstrasse.com> <20090109215311.GN20533@dillo.org> <20090109225853.GA895@blob.baaderstrasse.com> <20090110130756.GA1150@blob.baaderstrasse.com> Message-ID: <20090111010013.GA26330@local.gobigwest.com> Johannes wrote: > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > I think the html part needs not be changed. Everything is available > > in style already. > > I've attached a quick patch that seems to work for fixed sizes. > > It does not handle something like width="50%" however. > > As the patch works rather well for me and improves the current > behaviour, I've cleaned it up a bit (avoiding a possible division by > 0) for inclusion into main. Loading an image scales properly for me, but I still see lack of scaling when I leave a page and come back. Is that supposed to work now? From jcid at dillo.org Sun Jan 11 13:00:51 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Jan 11 13:00:51 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090111010013.GA26330@local.gobigwest.com> References: <20090109170020.GK20533@dillo.org> <20090109170409.GA2081@blob.baaderstrasse.com> <20090109191136.GL20533@dillo.org> <20090109192717.GA886@blob.baaderstrasse.com> <20090109215311.GN20533@dillo.org> <20090109225853.GA895@blob.baaderstrasse.com> <20090110130756.GA1150@blob.baaderstrasse.com> <20090111010013.GA26330@local.gobigwest.com> Message-ID: <20090111120051.GT20533@dillo.org> On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > Johannes wrote: > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > I think the html part needs not be changed. Everything is available > > > in style already. > > > I've attached a quick patch that seems to work for fixed sizes. > > > It does not handle something like width="50%" however. > > > > As the patch works rather well for me and improves the current > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > 0) for inclusion into main. > > Loading an image scales properly for me, but I still see > lack of scaling when I leave a page and come back. > Is that supposed to work now? Yes, it is supposed to work. Altough now that you mention it, I have problems the *first* time a only-one-dimension-specified image tag is loaded. Once coming back it works OK. This is because the second time the image dimensions are known from the dicache. Patch 8f7293125059 from main fixes this. Johannes: please test and merge. -- Cheers Jorge.- From onepoint at starurchin.org Sun Jan 11 14:18:48 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sun Jan 11 14:19:24 2009 Subject: [Dillo-dev] Blimey, when was this fixed? Selections are fast! Message-ID: <20090111131848.GA2966@omphalos.singularity> I used to complain that drawing the text selection was desperately slow when I dragged the mouse across the contents of a table with two columns and very many rows. Today I suddenly realised that this hadn't bothered me for a while, so I checked the problem page and indeed the selection now draws itself as fast I can drag the mouse. Big thanks to whoever fixed this performance bug! Regards, Jeremy Henty From Johannes.Hofmann at gmx.de Sun Jan 11 17:32:17 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sun Jan 11 17:40:00 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090111120051.GT20533@dillo.org> References: <20090109170020.GK20533@dillo.org> <20090109170409.GA2081@blob.baaderstrasse.com> <20090109191136.GL20533@dillo.org> <20090109192717.GA886@blob.baaderstrasse.com> <20090109215311.GN20533@dillo.org> <20090109225853.GA895@blob.baaderstrasse.com> <20090110130756.GA1150@blob.baaderstrasse.com> <20090111010013.GA26330@local.gobigwest.com> <20090111120051.GT20533@dillo.org> Message-ID: <20090111163217.GA922@blob.baaderstrasse.com> On Sun, Jan 11, 2009 at 09:00:51AM -0300, Jorge Arellano Cid wrote: > On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > > Johannes wrote: > > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > > I think the html part needs not be changed. Everything is available > > > > in style already. > > > > I've attached a quick patch that seems to work for fixed sizes. > > > > It does not handle something like width="50%" however. > > > > > > As the patch works rather well for me and improves the current > > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > > 0) for inclusion into main. > > > > Loading an image scales properly for me, but I still see > > lack of scaling when I leave a page and come back. > > Is that supposed to work now? > > Yes, it is supposed to work. > > Altough now that you mention it, I have problems the *first* > time a only-one-dimension-specified image tag is loaded. Once coming back > it works OK. This is because the second time the image dimensions > are known from the dicache. > > Patch 8f7293125059 from main fixes this. > > Johannes: please test and merge. Done. corvid, can you please verify that this fixes the issue you were seeing? Cheers, Johannes From corvid at lavabit.com Sun Jan 11 17:45:27 2009 From: corvid at lavabit.com (corvid) Date: Sun Jan 11 17:47:48 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090111163217.GA922@blob.baaderstrasse.com> References: <20090109170020.GK20533@dillo.org> <20090109170409.GA2081@blob.baaderstrasse.com> <20090109191136.GL20533@dillo.org> <20090109192717.GA886@blob.baaderstrasse.com> <20090109215311.GN20533@dillo.org> <20090109225853.GA895@blob.baaderstrasse.com> <20090110130756.GA1150@blob.baaderstrasse.com> <20090111010013.GA26330@local.gobigwest.com> <20090111120051.GT20533@dillo.org> <20090111163217.GA922@blob.baaderstrasse.com> Message-ID: <20090111164527.GB26330@local.gobigwest.com> Johannes wrote: > On Sun, Jan 11, 2009 at 09:00:51AM -0300, Jorge Arellano Cid wrote: > > On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > > > Johannes wrote: > > > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > > > I think the html part needs not be changed. Everything is available > > > > > in style already. > > > > > I've attached a quick patch that seems to work for fixed sizes. > > > > > It does not handle something like width="50%" however. > > > > > > > > As the patch works rather well for me and improves the current > > > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > > > 0) for inclusion into main. > > > > > > Loading an image scales properly for me, but I still see > > > lack of scaling when I leave a page and come back. > > > Is that supposed to work now? > > > > Yes, it is supposed to work. > > > > Altough now that you mention it, I have problems the *first* > > time a only-one-dimension-specified image tag is loaded. Once coming back > > it works OK. This is because the second time the image dimensions > > are known from the dicache. > > > > Patch 8f7293125059 from main fixes this. > > > > Johannes: please test and merge. > > Done. > > corvid, can you please verify that this fixes the issue you were > seeing? Same problem for me still. It turns out that in isolation works fine, but doesn't. From corvid at lavabit.com Sun Jan 11 18:09:24 2009 From: corvid at lavabit.com (corvid) Date: Sun Jan 11 18:11:43 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090111164527.GB26330@local.gobigwest.com> References: <20090109170409.GA2081@blob.baaderstrasse.com> <20090109191136.GL20533@dillo.org> <20090109192717.GA886@blob.baaderstrasse.com> <20090109215311.GN20533@dillo.org> <20090109225853.GA895@blob.baaderstrasse.com> <20090110130756.GA1150@blob.baaderstrasse.com> <20090111010013.GA26330@local.gobigwest.com> <20090111120051.GT20533@dillo.org> <20090111163217.GA922@blob.baaderstrasse.com> <20090111164527.GB26330@local.gobigwest.com> Message-ID: <20090111170924.GC26330@local.gobigwest.com> I wrote: > Johannes wrote: > > On Sun, Jan 11, 2009 at 09:00:51AM -0300, Jorge Arellano Cid wrote: > > > On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > > > > I think the html part needs not be changed. Everything is available > > > > > > in style already. > > > > > > I've attached a quick patch that seems to work for fixed sizes. > > > > > > It does not handle something like width="50%" however. > > > > > > > > > > As the patch works rather well for me and improves the current > > > > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > > > > 0) for inclusion into main. > > > > > > > > Loading an image scales properly for me, but I still see > > > > lack of scaling when I leave a page and come back. > > > > Is that supposed to work now? > > > > > > Yes, it is supposed to work. > > > > > > Altough now that you mention it, I have problems the *first* > > > time a only-one-dimension-specified image tag is loaded. Once coming back > > > it works OK. This is because the second time the image dimensions > > > are known from the dicache. > > > > > > Patch 8f7293125059 from main fixes this. > > > > > > Johannes: please test and merge. > > > > Done. > > > > corvid, can you please verify that this fixes the issue you were > > seeing? > > Same problem for me still. > It turns out that > > > > in isolation works fine, but > > > > > > doesn't. Ah, it works for me with css-prototype but not with main. I didn't realize there would be any difference. Sorry for any confusion... From Johannes.Hofmann at gmx.de Sun Jan 11 18:36:16 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sun Jan 11 18:44:13 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090111170924.GC26330@local.gobigwest.com> References: <20090109191136.GL20533@dillo.org> <20090109192717.GA886@blob.baaderstrasse.com> <20090109215311.GN20533@dillo.org> <20090109225853.GA895@blob.baaderstrasse.com> <20090110130756.GA1150@blob.baaderstrasse.com> <20090111010013.GA26330@local.gobigwest.com> <20090111120051.GT20533@dillo.org> <20090111163217.GA922@blob.baaderstrasse.com> <20090111164527.GB26330@local.gobigwest.com> <20090111170924.GC26330@local.gobigwest.com> Message-ID: <20090111173616.GB922@blob.baaderstrasse.com> On Sun, Jan 11, 2009 at 05:09:24PM +0000, corvid wrote: > I wrote: > > Johannes wrote: > > > On Sun, Jan 11, 2009 at 09:00:51AM -0300, Jorge Arellano Cid wrote: > > > > On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > > > > > I think the html part needs not be changed. Everything is available > > > > > > > in style already. > > > > > > > I've attached a quick patch that seems to work for fixed sizes. > > > > > > > It does not handle something like width="50%" however. > > > > > > > > > > > > As the patch works rather well for me and improves the current > > > > > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > > > > > 0) for inclusion into main. > > > > > > > > > > Loading an image scales properly for me, but I still see > > > > > lack of scaling when I leave a page and come back. > > > > > Is that supposed to work now? > > > > > > > > Yes, it is supposed to work. > > > > > > > > Altough now that you mention it, I have problems the *first* > > > > time a only-one-dimension-specified image tag is loaded. Once coming back > > > > it works OK. This is because the second time the image dimensions > > > > are known from the dicache. > > > > > > > > Patch 8f7293125059 from main fixes this. > > > > > > > > Johannes: please test and merge. > > > > > > Done. > > > > > > corvid, can you please verify that this fixes the issue you were > > > seeing? > > > > Same problem for me still. > > It turns out that > > > > > > > > in isolation works fine, but > > > > > > > > > > > > doesn't. > > Ah, it works for me with css-prototype but not with main. > I didn't realize there would be any difference. There shouldn't be any difference... > Sorry for any confusion... I'm confused now. Cheers, Johannes From corvid at lavabit.com Sun Jan 11 19:31:35 2009 From: corvid at lavabit.com (corvid) Date: Sun Jan 11 19:33:34 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090111173616.GB922@blob.baaderstrasse.com> References: <20090109192717.GA886@blob.baaderstrasse.com> <20090109215311.GN20533@dillo.org> <20090109225853.GA895@blob.baaderstrasse.com> <20090110130756.GA1150@blob.baaderstrasse.com> <20090111010013.GA26330@local.gobigwest.com> <20090111120051.GT20533@dillo.org> <20090111163217.GA922@blob.baaderstrasse.com> <20090111164527.GB26330@local.gobigwest.com> <20090111170924.GC26330@local.gobigwest.com> <20090111173616.GB922@blob.baaderstrasse.com> Message-ID: <20090111183135.GD26330@local.gobigwest.com> Johannes wrote: > On Sun, Jan 11, 2009 at 05:09:24PM +0000, corvid wrote: > > I wrote: > > > Johannes wrote: > > > > On Sun, Jan 11, 2009 at 09:00:51AM -0300, Jorge Arellano Cid wrote: > > > > > On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > > > > > > Johannes wrote: > > > > > > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > > > > > > I think the html part needs not be changed. Everything is available > > > > > > > > in style already. > > > > > > > > I've attached a quick patch that seems to work for fixed sizes. > > > > > > > > It does not handle something like width="50%" however. > > > > > > > > > > > > > > As the patch works rather well for me and improves the current > > > > > > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > > > > > > 0) for inclusion into main. > > > > > > > > > > > > Loading an image scales properly for me, but I still see > > > > > > lack of scaling when I leave a page and come back. > > > > > > Is that supposed to work now? > > > > > > > > > > Yes, it is supposed to work. > > > > > > > > > > Altough now that you mention it, I have problems the *first* > > > > > time a only-one-dimension-specified image tag is loaded. Once coming back > > > > > it works OK. This is because the second time the image dimensions > > > > > are known from the dicache. > > > > > > > > > > Patch 8f7293125059 from main fixes this. > > > > > > > > > > Johannes: please test and merge. > > > > > > > > Done. > > > > > > > > corvid, can you please verify that this fixes the issue you were > > > > seeing? > > > > > > Same problem for me still. > > > It turns out that > > > > > > > > > > > > in isolation works fine, but > > > > > > > > > > > > > > > > > > doesn't. > > > > Ah, it works for me with css-prototype but not with main. > > I didn't realize there would be any difference. > > There shouldn't be any difference... main works for you, then? Hmm. It gets the size of the box right, but then the rgb data inside it isn't scaled. (...which is the behaviour I've always seen with fltk-era dillo when returning to pages. On the original load, I would get stretched images, but that's been fixed now.) From jcid at dillo.org Sun Jan 11 19:38:04 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Jan 11 19:38:02 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090111183135.GD26330@local.gobigwest.com> References: <20090109215311.GN20533@dillo.org> <20090109225853.GA895@blob.baaderstrasse.com> <20090110130756.GA1150@blob.baaderstrasse.com> <20090111010013.GA26330@local.gobigwest.com> <20090111120051.GT20533@dillo.org> <20090111163217.GA922@blob.baaderstrasse.com> <20090111164527.GB26330@local.gobigwest.com> <20090111170924.GC26330@local.gobigwest.com> <20090111173616.GB922@blob.baaderstrasse.com> <20090111183135.GD26330@local.gobigwest.com> Message-ID: <20090111183804.GU20533@dillo.org> On Sun, Jan 11, 2009 at 06:31:35PM +0000, corvid wrote: > Johannes wrote: > > On Sun, Jan 11, 2009 at 05:09:24PM +0000, corvid wrote: > > > I wrote: > > > > Johannes wrote: > > > > > On Sun, Jan 11, 2009 at 09:00:51AM -0300, Jorge Arellano Cid wrote: > > > > > > On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > > > > > > > Johannes wrote: > > > > > > > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > > > > > > > I think the html part needs not be changed. Everything is available > > > > > > > > > in style already. > > > > > > > > > I've attached a quick patch that seems to work for fixed sizes. > > > > > > > > > It does not handle something like width="50%" however. > > > > > > > > > > > > > > > > As the patch works rather well for me and improves the current > > > > > > > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > > > > > > > 0) for inclusion into main. > > > > > > > > > > > > > > Loading an image scales properly for me, but I still see > > > > > > > lack of scaling when I leave a page and come back. > > > > > > > Is that supposed to work now? > > > > > > > > > > > > Yes, it is supposed to work. > > > > > > > > > > > > Altough now that you mention it, I have problems the *first* > > > > > > time a only-one-dimension-specified image tag is loaded. Once coming back > > > > > > it works OK. This is because the second time the image dimensions > > > > > > are known from the dicache. > > > > > > > > > > > > Patch 8f7293125059 from main fixes this. > > > > > > > > > > > > Johannes: please test and merge. > > > > > > > > > > Done. > > > > > > > > > > corvid, can you please verify that this fixes the issue you were > > > > > seeing? > > > > > > > > Same problem for me still. > > > > It turns out that > > > > > > > > > > > > > > > > in isolation works fine, but > > > > > > > > > > > > > > > > > > > > > > > > doesn't. > > > > > > Ah, it works for me with css-prototype but not with main. > > > I didn't realize there would be any difference. > > > > There shouldn't be any difference... > > main works for you, then? Hmm. It works for me. > It gets the size of the box right, but > then the rgb data inside it isn't scaled. > > (...which is the behaviour I've always seen > with fltk-era dillo when returning to pages. > On the original load, I would get stretched > images, but that's been fixed now.) If main doesn't work for you, please share the sample HTML/img code that faults? -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Sun Jan 11 19:36:32 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sun Jan 11 19:44:14 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090111183135.GD26330@local.gobigwest.com> References: <20090109215311.GN20533@dillo.org> <20090109225853.GA895@blob.baaderstrasse.com> <20090110130756.GA1150@blob.baaderstrasse.com> <20090111010013.GA26330@local.gobigwest.com> <20090111120051.GT20533@dillo.org> <20090111163217.GA922@blob.baaderstrasse.com> <20090111164527.GB26330@local.gobigwest.com> <20090111170924.GC26330@local.gobigwest.com> <20090111173616.GB922@blob.baaderstrasse.com> <20090111183135.GD26330@local.gobigwest.com> Message-ID: <20090111183632.GC922@blob.baaderstrasse.com> On Sun, Jan 11, 2009 at 06:31:35PM +0000, corvid wrote: > Johannes wrote: > > On Sun, Jan 11, 2009 at 05:09:24PM +0000, corvid wrote: > > > I wrote: > > > > Johannes wrote: > > > > > On Sun, Jan 11, 2009 at 09:00:51AM -0300, Jorge Arellano Cid wrote: > > > > > > On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > > > > > > > Johannes wrote: > > > > > > > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > > > > > > > I think the html part needs not be changed. Everything is available > > > > > > > > > in style already. > > > > > > > > > I've attached a quick patch that seems to work for fixed sizes. > > > > > > > > > It does not handle something like width="50%" however. > > > > > > > > > > > > > > > > As the patch works rather well for me and improves the current > > > > > > > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > > > > > > > 0) for inclusion into main. > > > > > > > > > > > > > > Loading an image scales properly for me, but I still see > > > > > > > lack of scaling when I leave a page and come back. > > > > > > > Is that supposed to work now? > > > > > > > > > > > > Yes, it is supposed to work. > > > > > > > > > > > > Altough now that you mention it, I have problems the *first* > > > > > > time a only-one-dimension-specified image tag is loaded. Once coming back > > > > > > it works OK. This is because the second time the image dimensions > > > > > > are known from the dicache. > > > > > > > > > > > > Patch 8f7293125059 from main fixes this. > > > > > > > > > > > > Johannes: please test and merge. > > > > > > > > > > Done. > > > > > > > > > > corvid, can you please verify that this fixes the issue you were > > > > > seeing? > > > > > > > > Same problem for me still. > > > > It turns out that > > > > > > > > > > > > > > > > in isolation works fine, but > > > > > > > > > > > > > > > > > > > > > > > > doesn't. > > > > > > Ah, it works for me with css-prototype but not with main. > > > I didn't realize there would be any difference. > > > > There shouldn't be any difference... > > main works for you, then? Hmm. > > It gets the size of the box right, but > then the rgb data inside it isn't scaled. Ok, I'm seeing the problem now with main and the example you have provided. css-prototype indeed seems to work fine. Not sure why :-) Cheers, Johannes From Johannes.Hofmann at gmx.de Sun Jan 11 19:40:20 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sun Jan 11 19:48:06 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090111183804.GU20533@dillo.org> References: <20090109225853.GA895@blob.baaderstrasse.com> <20090110130756.GA1150@blob.baaderstrasse.com> <20090111010013.GA26330@local.gobigwest.com> <20090111120051.GT20533@dillo.org> <20090111163217.GA922@blob.baaderstrasse.com> <20090111164527.GB26330@local.gobigwest.com> <20090111170924.GC26330@local.gobigwest.com> <20090111173616.GB922@blob.baaderstrasse.com> <20090111183135.GD26330@local.gobigwest.com> <20090111183804.GU20533@dillo.org> Message-ID: <20090111184020.GD922@blob.baaderstrasse.com> On Sun, Jan 11, 2009 at 03:38:04PM -0300, Jorge Arellano Cid wrote: > On Sun, Jan 11, 2009 at 06:31:35PM +0000, corvid wrote: > > Johannes wrote: > > > On Sun, Jan 11, 2009 at 05:09:24PM +0000, corvid wrote: > > > > I wrote: > > > > > Johannes wrote: > > > > > > On Sun, Jan 11, 2009 at 09:00:51AM -0300, Jorge Arellano Cid wrote: > > > > > > > On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > > > > > > > > Johannes wrote: > > > > > > > > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > > > > > > > > I think the html part needs not be changed. Everything is available > > > > > > > > > > in style already. > > > > > > > > > > I've attached a quick patch that seems to work for fixed sizes. > > > > > > > > > > It does not handle something like width="50%" however. > > > > > > > > > > > > > > > > > > As the patch works rather well for me and improves the current > > > > > > > > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > > > > > > > > 0) for inclusion into main. > > > > > > > > > > > > > > > > Loading an image scales properly for me, but I still see > > > > > > > > lack of scaling when I leave a page and come back. > > > > > > > > Is that supposed to work now? > > > > > > > > > > > > > > Yes, it is supposed to work. > > > > > > > > > > > > > > Altough now that you mention it, I have problems the *first* > > > > > > > time a only-one-dimension-specified image tag is loaded. Once coming back > > > > > > > it works OK. This is because the second time the image dimensions > > > > > > > are known from the dicache. > > > > > > > > > > > > > > Patch 8f7293125059 from main fixes this. > > > > > > > > > > > > > > Johannes: please test and merge. > > > > > > > > > > > > Done. > > > > > > > > > > > > corvid, can you please verify that this fixes the issue you were > > > > > > seeing? > > > > > > > > > > Same problem for me still. > > > > > It turns out that > > > > > > > > > > > > > > > > > > > > in isolation works fine, but > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > doesn't. > > > > > > > > Ah, it works for me with css-prototype but not with main. > > > > I didn't realize there would be any difference. > > > > > > There shouldn't be any difference... > > > > main works for you, then? Hmm. > > It works for me. Try going to: then hit the bookmark button and then go back to the above page. First time scaling works, but when going back it's not scaled anymore. Cheers, Johannes From jcid at dillo.org Sun Jan 11 20:05:06 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Jan 11 20:05:06 2009 Subject: [Dillo-dev] IMG ratio In-Reply-To: <20090111184020.GD922@blob.baaderstrasse.com> References: <20090110130756.GA1150@blob.baaderstrasse.com> <20090111010013.GA26330@local.gobigwest.com> <20090111120051.GT20533@dillo.org> <20090111163217.GA922@blob.baaderstrasse.com> <20090111164527.GB26330@local.gobigwest.com> <20090111170924.GC26330@local.gobigwest.com> <20090111173616.GB922@blob.baaderstrasse.com> <20090111183135.GD26330@local.gobigwest.com> <20090111183804.GU20533@dillo.org> <20090111184020.GD922@blob.baaderstrasse.com> Message-ID: <20090111190506.GV20533@dillo.org> On Sun, Jan 11, 2009 at 07:40:20PM +0100, Hofmann Johannes wrote: > On Sun, Jan 11, 2009 at 03:38:04PM -0300, Jorge Arellano Cid wrote: > > On Sun, Jan 11, 2009 at 06:31:35PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sun, Jan 11, 2009 at 05:09:24PM +0000, corvid wrote: > > > > > I wrote: > > > > > > Johannes wrote: > > > > > > > On Sun, Jan 11, 2009 at 09:00:51AM -0300, Jorge Arellano Cid wrote: > > > > > > > > On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > > > > > > > > > Johannes wrote: > > > > > > > > > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > > > > > > > > > I think the html part needs not be changed. Everything is available > > > > > > > > > > > in style already. > > > > > > > > > > > I've attached a quick patch that seems to work for fixed sizes. > > > > > > > > > > > It does not handle something like width="50%" however. > > > > > > > > > > > > > > > > > > > > As the patch works rather well for me and improves the current > > > > > > > > > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > > > > > > > > > 0) for inclusion into main. > > > > > > > > > > > > > > > > > > Loading an image scales properly for me, but I still see > > > > > > > > > lack of scaling when I leave a page and come back. > > > > > > > > > Is that supposed to work now? > > > > > > > > > > > > > > > > Yes, it is supposed to work. > > > > > > > > > > > > > > > > Altough now that you mention it, I have problems the *first* > > > > > > > > time a only-one-dimension-specified image tag is loaded. Once coming back > > > > > > > > it works OK. This is because the second time the image dimensions > > > > > > > > are known from the dicache. > > > > > > > > > > > > > > > > Patch 8f7293125059 from main fixes this. > > > > > > > > > > > > > > > > Johannes: please test and merge. > > > > > > > > > > > > > > Done. > > > > > > > > > > > > > > corvid, can you please verify that this fixes the issue you were > > > > > > > seeing? > > > > > > > > > > > > Same problem for me still. > > > > > > It turns out that > > > > > > > > > > > > > > > > > > > > > > > > in isolation works fine, but > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > doesn't. > > > > > > > > > > Ah, it works for me with css-prototype but not with main. > > > > > I didn't realize there would be any difference. > > > > > > > > There shouldn't be any difference... > > > > > > main works for you, then? Hmm. > > > > It works for me. > > Try going to: > > > > > > then hit the bookmark button and then go back to the above page. > First time scaling works, but when going back it's not scaled > anymore. Got it! Thxs. -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Mon Jan 12 13:25:40 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Mon Jan 12 13:33:20 2009 Subject: [Dillo-dev] CSS freeze In-Reply-To: <20090109193232.GM20533@dillo.org> References: <20090109193232.GM20533@dillo.org> Message-ID: <20090112122540.GA41305@blob.baaderstrasse.com> On Fri, Jan 09, 2009 at 04:32:33PM -0300, Jorge Arellano Cid wrote: > Hi, > > Current and former CSS protos freeze on this page: > > http://www.instantfundas.com/2007/12/5-opera-tricks-you-did-not-know-about.html I've made some adjustments to the CSS parser that fix the problem for me. Please retest. Cheers, Johannes From Johannes.Hofmann at gmx.de Tue Jan 13 09:49:31 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Tue Jan 13 09:57:10 2009 Subject: [Dillo-dev] CSS speed Message-ID: <20090113084931.GA7153@blob.baaderstrasse.com> Hi, pages with complex CSS feel a bit slow with the current css-prototype and gprof shows a huge number of CssSelector::match() calls. Attached is a patch that tries to improve that by: * putting CssSelectors into hashtables so that we only need to match against a small subset of CssSelectors. * avoiding repeated matches of CssSimpleSelectors against the same part of the doctree. Please test and report if there is a real world speedup. Cheers, Johannes -------------- next part -------------- diff --git a/src/css.cc b/src/css.cc --- a/src/css.cc +++ b/src/css.cc @@ -51,6 +51,7 @@ selectorList = new lout::misc::SimpleVector (1); selectorList->increase (); + selectorList->getRef (0)->notMatchingBefore = -1; top ()->element = element; top ()->klass = klass; top ()->pseudo = pseudo; @@ -64,7 +65,8 @@ bool CssSelector::match (Doctree *docTree) { CssSimpleSelector *sel; Combinator comb; - const DoctreeNode *node = docTree->top (); + int *notMatchingBefore; + const DoctreeNode *n, *node = docTree->top (); assert (selectorList->size () > 0); @@ -76,6 +78,7 @@ for (int i = selectorList->size () - 2; i >= 0; i--) { sel = &selectorList->getRef (i)->selector; comb = selectorList->getRef (i + 1)->combinator; + notMatchingBefore = &selectorList->getRef (i + 1)->notMatchingBefore; node = docTree->parent (node); if (node == NULL) @@ -87,10 +90,19 @@ return false; break; case DESCENDENT: + n = node; while (!sel->match (node)) { + if (node->num < *notMatchingBefore) { + *notMatchingBefore = n->num; + return false; + } + node = docTree->parent (node); - if (node == NULL) + + if (node == NULL) { + *notMatchingBefore = n->num; return false; + } } break; default: @@ -107,6 +119,7 @@ selectorList->increase (); selectorList->getRef (selectorList->size () - 1)->combinator = c; + selectorList->getRef (selectorList->size () - 1)->notMatchingBefore = -1; top ()->element = element; top ()->klass = klass; top ()->pseudo = pseudo; @@ -157,7 +170,6 @@ } CssRule::CssRule (CssSelector *selector, CssPropertyList *props) { - refCount = 0; this->selector = selector; this->selector->ref (); this->props = props; @@ -181,31 +193,53 @@ CssStyleSheet::CssStyleSheet () { for (int i = 0; i < ntags; i++) - ruleTable[i] = new lout::misc::SimpleVector (1); + elementTable[i] = new RuleList (); + + idTable = new RuleMap (); + classTable = new RuleMap (); + anyTable = new RuleList (); } CssStyleSheet::~CssStyleSheet () { - for (int i = 0; i < ntags; i++) { - for (int j = 0; j < ruleTable[i]->size (); j++) - ruleTable[i]->get (j)->unref (); - - delete ruleTable[i]; - } + for (int i = 0; i < ntags; i++) + delete elementTable[i]; + delete idTable; + delete classTable; + delete anyTable; } void CssStyleSheet::addRule (CssRule *rule) { - int topElement = rule->selector->top ()->element; + CssSimpleSelector *top = rule->selector->top (); + RuleList *ruleList = NULL; + lout::object::ConstString *string; + + if (top->id) { + string = new lout::object::ConstString (top->id); + ruleList = idTable->get (string); + if (ruleList == NULL) { + ruleList = new RuleList (); + idTable->put (string, ruleList); + } else { + delete string; + } + } else if (top->klass) { + string = new lout::object::ConstString (top->klass); + ruleList = classTable->get (string); + if (ruleList == NULL) { + ruleList = new RuleList; + classTable->put (string, ruleList); + } else { + delete string; + } + } else if (top->element >= 0 && top->element < ntags) { + ruleList = elementTable[top->element]; + } else if (top->element == CssSimpleSelector::ELEMENT_ANY) { + ruleList = anyTable; + } - if (topElement == CssSimpleSelector::ELEMENT_ANY) { - for (int i = 0; i < ntags; i++) { - ruleTable[i]->increase (); - *ruleTable[i]->getRef (ruleTable[i]->size () - 1) = rule; - rule->ref (); - } - } else if (topElement >= 0 && topElement < ntags) { - ruleTable[topElement]->increase (); - *ruleTable[topElement]->getRef (ruleTable[topElement]->size()-1) = rule; - rule->ref (); + if (ruleList) { + ruleList->increase (); + *ruleList->getRef (ruleList->size() - 1) = rule; } } @@ -215,11 +249,44 @@ } void CssStyleSheet::apply (CssPropertyList *props, Doctree *docTree) { - lout::misc::SimpleVector *ruleList; + RuleList *ruleList[4] = {NULL, NULL, NULL, NULL}; + const DoctreeNode *top = docTree->top (); + + if (top->id) { + lout::object::String idString (top->id); - ruleList = ruleTable[docTree->top ()->element]; - for (int i = 0; i < ruleList->size (); i++) - ruleList->get (i)->apply (props, docTree); + ruleList[3] = idTable->get (&idString); + } + + if (top->klass) { + lout::object::String classString (top->klass); + + ruleList[2] = classTable->get (&classString); + } + + ruleList[1] = elementTable[docTree->top ()->element]; + ruleList[0] = anyTable; + +#if 0 + fprintf(stderr, "==> "); + for (int j = 0; j < 4; j++) + fprintf(stderr, "%d ", ruleList[j]?ruleList[j]->size():0); + fprintf(stderr, "\n"); +#endif + + for (int i = 0;; i++) { + int n = 0; + + for (int j = 0; j < 4; j++) { + if (ruleList[j] && ruleList[j]->size () > i) { + ruleList[j]->get (i)->apply (props, docTree); + n++; + } + } + + if (n == 0) + break; + } } CssStyleSheet *CssContext::userAgentStyle; diff --git a/src/css.hh b/src/css.hh --- a/src/css.hh +++ b/src/css.hh @@ -223,6 +223,7 @@ private: struct CombinatorAndSelector { + int notMatchingBefore; // used for optimizing CSS selector matching Combinator combinator; CssSimpleSelector selector; }; @@ -255,7 +256,6 @@ */ class CssRule { private: - int refCount; CssPropertyList *props; public: @@ -265,8 +265,6 @@ ~CssRule (); void apply (CssPropertyList *props, Doctree *docTree); - inline void ref () { refCount++; } - inline void unref () { if(--refCount == 0) delete this; } void print (); }; @@ -276,8 +274,32 @@ */ class CssStyleSheet { private: + class RuleList : public lout::misc::SimpleVector , + public lout::object::Object { + public: + RuleList () : lout::misc::SimpleVector (1) {}; + ~RuleList () { + for (int i = 0; i < size (); i++) + delete get (i); + }; + + bool equals (lout::object::Object *other) { return this == other; }; + int hashValue () { return (intptr_t) this; }; + }; + + class RuleMap : public lout::container::typed::HashTable + { + public: + RuleMap () : lout::container::typed::HashTable + (true, true, 256) {}; + }; + static const int ntags = 90; // \todo replace 90 - lout::misc::SimpleVector *ruleTable[ntags]; + RuleList *elementTable[ntags]; + + RuleMap *idTable; + RuleMap *classTable; + RuleList *anyTable; public: CssStyleSheet(); diff --git a/src/doctree.hh b/src/doctree.hh --- a/src/doctree.hh +++ b/src/doctree.hh @@ -3,6 +3,7 @@ class DoctreeNode { public: + int num; // unique ascending id int depth; int element; const char *klass; diff --git a/src/styleengine.cc b/src/styleengine.cc --- a/src/styleengine.cc +++ b/src/styleengine.cc @@ -23,6 +23,7 @@ stack = new lout::misc::SimpleVector (1); cssContext = new CssContext (); this->layout = layout; + num = 0; stack->increase (); Node *n = stack->getRef (stack->size () - 1); @@ -37,7 +38,8 @@ style_attrs.font = Font::create (layout, &font_attrs); style_attrs.color = Color::create (layout, 0); style_attrs.backgroundColor = Color::create (layout, 0xffffff); - + + n->num = num++; n->style = Style::create (layout, &style_attrs); n->wordStyle = NULL; n->pseudo = NULL; @@ -62,6 +64,7 @@ stack->increase (); Node *n = stack->getRef (stack->size () - 1); + n->num = num++; n->style = NULL; n->wordStyle = NULL; n->depth = stack->size () - 1; diff --git a/src/styleengine.hh b/src/styleengine.hh --- a/src/styleengine.hh +++ b/src/styleengine.hh @@ -19,6 +19,7 @@ dw::core::Layout *layout; lout::misc::SimpleVector *stack; CssContext *cssContext; + int num; dw::core::style::Style *style0 (CssPropertyList *nonCssHints = NULL); dw::core::style::Style *wordStyle0 (CssPropertyList *nonCssHints = NULL); From Johannes.Hofmann at gmx.de Tue Jan 13 14:03:33 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Tue Jan 13 14:11:38 2009 Subject: [Dillo-dev] focus after closing tab Message-ID: <20090113130333.GC1708@blob.baaderstrasse.com> Hi, sometimes when closing a tab it feels that dillo focuses the "wrong" tab. Therefore I made a patch that puts the focus back to the tab from which a tab was opened. That way I always get back to the "base page" when closing a tab. Howerver I'm not sure that this is always right, e.g. when opening multiple tabs from one base page, one might want to read one after the other without going back to the base page. What do you think, which page should be focused when closing a tab: * the tab from which the closed one was opened? * the tab to the left of the closed one? * the most recently opened one? Cheers, Johannes From corvid at lavabit.com Tue Jan 13 21:00:37 2009 From: corvid at lavabit.com (corvid) Date: Tue Jan 13 21:02:38 2009 Subject: [Dillo-dev] CSS speed In-Reply-To: <20090113084931.GA7153@blob.baaderstrasse.com> References: <20090113084931.GA7153@blob.baaderstrasse.com> Message-ID: <20090113200037.GE26330@local.gobigwest.com> Johannes wrote: > pages with complex CSS feel a bit slow with the current css-prototype > and gprof shows a huge number of CssSelector::match() calls. > Attached is a patch that tries to improve that by: > > * putting CssSelectors into hashtables so that we only need to match > against a small subset of CssSelectors. > > * avoiding repeated matches of CssSimpleSelectors against the same > part of the doctree. > > Please test and report if there is a real world speedup. Wow! In the past, my best example had been pages on reddit.com that had at least maybe 300 comments. They had been unusably slow--although this would encourage a person not to waste time looking at reddit. Quite usable now. From jcid at dillo.org Tue Jan 13 22:55:50 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Jan 13 22:55:56 2009 Subject: [Dillo-dev] CSS freeze In-Reply-To: <20090112122540.GA41305@blob.baaderstrasse.com> References: <20090109193232.GM20533@dillo.org> <20090112122540.GA41305@blob.baaderstrasse.com> Message-ID: <20090113215550.GW20533@dillo.org> On Mon, Jan 12, 2009 at 01:25:40PM +0100, Hofmann Johannes wrote: > On Fri, Jan 09, 2009 at 04:32:33PM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > Current and former CSS protos freeze on this page: > > > > http://www.instantfundas.com/2007/12/5-opera-tricks-you-did-not-know-about.html > > I've made some adjustments to the CSS parser that fix the problem > for me. Please retest. Good! Multiple return points within a function is asking for trouble. Good you removed them with the patch. It works OK here. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From Johannes.Hofmann at gmx.de Wed Jan 14 08:50:43 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Wed Jan 14 08:58:24 2009 Subject: [Dillo-dev] CSS speed In-Reply-To: <20090113200037.GE26330@local.gobigwest.com> References: <20090113084931.GA7153@blob.baaderstrasse.com> <20090113200037.GE26330@local.gobigwest.com> Message-ID: <20090114075043.GA884@blob.baaderstrasse.com> On Tue, Jan 13, 2009 at 08:00:37PM +0000, corvid wrote: > Johannes wrote: > > pages with complex CSS feel a bit slow with the current css-prototype > > and gprof shows a huge number of CssSelector::match() calls. > > Attached is a patch that tries to improve that by: > > > > * putting CssSelectors into hashtables so that we only need to match > > against a small subset of CssSelectors. > > > > * avoiding repeated matches of CssSimpleSelectors against the same > > part of the doctree. > > > > Please test and report if there is a real world speedup. > > Wow! > > In the past, my best example had been pages on reddit.com that had > at least maybe 300 comments. They had been unusably slow--although > this would encourage a person not to waste time looking at reddit. > > Quite usable now. Great. reddit.com is looking strange though. There is this weird blue circle... From corvid at lavabit.com Wed Jan 14 16:40:23 2009 From: corvid at lavabit.com (corvid) Date: Wed Jan 14 16:42:22 2009 Subject: [Dillo-dev] CSS speed In-Reply-To: <20090114075043.GA884@blob.baaderstrasse.com> References: <20090113084931.GA7153@blob.baaderstrasse.com> <20090113200037.GE26330@local.gobigwest.com> <20090114075043.GA884@blob.baaderstrasse.com> Message-ID: <20090114154023.GF26330@local.gobigwest.com> Johannes wrote: > On Tue, Jan 13, 2009 at 08:00:37PM +0000, corvid wrote: > > Johannes wrote: > > > pages with complex CSS feel a bit slow with the current css-prototype > > > and gprof shows a huge number of CssSelector::match() calls. > > > Attached is a patch that tries to improve that by: > > > > > > * putting CssSelectors into hashtables so that we only need to match > > > against a small subset of CssSelectors. > > > > > > * avoiding repeated matches of CssSimpleSelectors against the same > > > part of the doctree. > > > > > > Please test and report if there is a real world speedup. > > > > Wow! > > > > In the past, my best example had been pages on reddit.com that had > > at least maybe 300 comments. They had been unusably slow--although > > this would encourage a person not to waste time looking at reddit. > > > > Quite usable now. > > Great. reddit.com is looking strange though. There is this weird > blue circle... I think it's an iframe's bullet hypertrophied by #ad-frame { border: 0px; overflow: hidden; width: 300px; height: 300px; } From corvid at lavabit.com Wed Jan 14 17:48:45 2009 From: corvid at lavabit.com (corvid) Date: Wed Jan 14 17:50:42 2009 Subject: [Dillo-dev] patch: focus URL opened from command line Message-ID: <20090114164844.GG26330@local.gobigwest.com> I see there's a new entry in the bug tracker reporting that after opening multiple URLs from the command line, shift-right and shift-left do not work immediately. What do you think of something like the attached patch? The downside is that it wastes cycles when you click on a link, but I was reluctant to let dillo.cc know about this UI stuff. -------------- next part -------------- diff -r e90b1adb768b src/dillo.cc --- a/src/dillo.cc Mon Jan 12 21:05:22 2009 +0000 +++ b/src/dillo.cc Wed Jan 14 16:34:40 2009 +0000 @@ -325,7 +325,7 @@ int main(int argc, char **argv) a_UIcmd_open_url_nw(bw, start_url); } } else { - a_Nav_push(bw, start_url); + a_UIcmd_open_url(bw, start_url); } a_Url_free(start_url); } diff -r e90b1adb768b src/uicmd.cc --- a/src/uicmd.cc Mon Jan 12 21:05:22 2009 +0000 +++ b/src/uicmd.cc Wed Jan 14 16:34:41 2009 +0000 @@ -365,6 +365,7 @@ void a_UIcmd_open_url(BrowserWindow *bw, void a_UIcmd_open_url(BrowserWindow *bw, const DilloUrl *url) { a_Nav_push(bw, url); + BW2UI(bw)->tabs()->selected_child()->take_focus(); } /* From xentalion at gmail.com Thu Jan 15 03:00:42 2009 From: xentalion at gmail.com (Colin Jones) Date: Thu Jan 15 03:01:44 2009 Subject: [Dillo-dev] Dillo 2 in Tiny Core Linux Message-ID: <77623db0901141800j794a7ddei40f9f80566920b5d@mail.gmail.com> Hello, Just wanted to let you that I've built a package of Dillo 2 for Tiny Core Linux. http://www.tinycorelinux.com/ It is now in the repositories for Tiny Core. :D Dillo 2 doesn't use any OpenGL does it? I compiled FLTK 2 without OpenGL support, and I didn't know if that would be a problem. Thanks, Colin -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20090114/a8b17e99/attachment.html From corvid at lavabit.com Thu Jan 15 05:28:42 2009 From: corvid at lavabit.com (corvid) Date: Thu Jan 15 05:30:45 2009 Subject: [Dillo-dev] Dillo 2 in Tiny Core Linux In-Reply-To: <77623db0901141800j794a7ddei40f9f80566920b5d@mail.gmail.com> References: <77623db0901141800j794a7ddei40f9f80566920b5d@mail.gmail.com> Message-ID: <20090115042842.GH26330@local.gobigwest.com> Colin wrote: > Dillo 2 doesn't use any OpenGL does it? I compiled FLTK 2 without OpenGL > support, and I didn't know if that would be a problem. Nope. I normally configure fltk without gl. It's a little bit annoying that fltk2 still tries to compile its tests that use OpenGL, but not a big deal... PS I was trying to list my idea of dependencies in the FAQ recently because one of my pet peeves is when I want to try some software but it turns out that it won't compile unless I get a ton of libraries...which in turn each require a ton of libraries...and then I typically cut my losses and delete it all. From onepoint at starurchin.org Thu Jan 15 07:03:28 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Thu Jan 15 07:04:04 2009 Subject: [Dillo-dev] focus after closing tab In-Reply-To: <20090113130333.GC1708@blob.baaderstrasse.com> References: <20090113130333.GC1708@blob.baaderstrasse.com> Message-ID: <20090115060328.GK10178@omphalos.singularity> On Tue, Jan 13, 2009 at 02:03:33PM +0100, Hofmann Johannes wrote: > What do you think, which page should be focused when closing a tab: > * the most recently opened one? +1 . It would certainly be better than the current behaviour. Regards, Jeremy Henty From Johannes.Hofmann at gmx.de Thu Jan 15 10:10:08 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Thu Jan 15 10:17:55 2009 Subject: [Dillo-dev] CSS speed In-Reply-To: <20090114154023.GF26330@local.gobigwest.com> References: <20090113084931.GA7153@blob.baaderstrasse.com> <20090113200037.GE26330@local.gobigwest.com> <20090114075043.GA884@blob.baaderstrasse.com> <20090114154023.GF26330@local.gobigwest.com> Message-ID: <20090115091008.GA5297@blob.baaderstrasse.com> On Wed, Jan 14, 2009 at 03:40:23PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Jan 13, 2009 at 08:00:37PM +0000, corvid wrote: > > > Johannes wrote: > > > > pages with complex CSS feel a bit slow with the current css-prototype > > > > and gprof shows a huge number of CssSelector::match() calls. > > > > Attached is a patch that tries to improve that by: > > > > > > > > * putting CssSelectors into hashtables so that we only need to match > > > > against a small subset of CssSelectors. > > > > > > > > * avoiding repeated matches of CssSimpleSelectors against the same > > > > part of the doctree. > > > > > > > > Please test and report if there is a real world speedup. > > > > > > Wow! > > > > > > In the past, my best example had been pages on reddit.com that had > > > at least maybe 300 comments. They had been unusably slow--although > > > this would encourage a person not to waste time looking at reddit. > > > > > > Quite usable now. > > > > Great. reddit.com is looking strange though. There is this weird > > blue circle... > > I think it's an iframe's bullet hypertrophied by > > #ad-frame { > border: 0px; > overflow: hidden; > width: 300px; > height: 300px; > } > > Ah right. We should probabely disable style processing for content that dillo generates on its own (e.g. or <(i)frame> replacements). Cheers, Johannes From jcid at dillo.org Thu Jan 15 12:42:22 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Jan 15 12:42:29 2009 Subject: [Dillo-dev] focus after closing tab In-Reply-To: <20090115060328.GK10178@omphalos.singularity> References: <20090113130333.GC1708@blob.baaderstrasse.com> <20090115060328.GK10178@omphalos.singularity> Message-ID: <20090115114222.GY20533@dillo.org> On Thu, Jan 15, 2009 at 06:03:28AM +0000, Jeremy Henty wrote: > On Tue, Jan 13, 2009 at 02:03:33PM +0100, Hofmann Johannes wrote: > > > What do you think, which page should be focused when closing a tab: > > > * the most recently opened one? > > +1 . It would certainly be better than the current behaviour. Current behaviour is a bug. Without experience on the subject I'd say let's follow firefox bahaviour on this. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From sandshrew at gmail.com Thu Jan 15 13:08:59 2009 From: sandshrew at gmail.com (Tomas R) Date: Thu Jan 15 13:09:36 2009 Subject: [Dillo-dev] Re: focus after closing tab Message-ID: <20090115140859.3eeadfeb@ubuntu> I would vote for "the most recently opened one" too. -- Brain: an apparatus with which we think we think. - A. Bierce From jcid at dillo.org Thu Jan 15 14:41:59 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Jan 15 14:42:06 2009 Subject: [Dillo-dev] Re: A couple of patches In-Reply-To: <20090115090737.GA5006@blob.baaderstrasse.com> References: <20090114220700.GX20533@dillo.org> <20090115090737.GA5006@blob.baaderstrasse.com> Message-ID: <20090115134159.GZ20533@dillo.org> Hi Johannes, On Thu, Jan 15, 2009 at 10:07:37AM +0100, Hofmann Johannes wrote: > Hi Jorge, > > On Wed, Jan 14, 2009 at 07:07:00PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > Here go couple of patches. Please test and apply. > > Thanks, applied. > > > > > Note: the image background support is partial. It works well > > when coming back to a page. AFAIS the right solution is to decode > > transparent images to RGBA and let FLTK handle it. > > Yes, I think that would be the correct way to do it. > > > > > BTW, the CSS prototype seems stable enough to consider a merge. > > What do you think? > > Yes, it feels pretty stable and now that there is an option to > disable remote stylesheet loading, I think we can consider making > css-prototype the main branch of dillo. > However I'd like to have some issues fixed: > > * should load_stylesheets=NO only disable remote style-sheet loading > (as it does now), or should it disable all remote style processing > (e.g. style given in )? We can add a "parse_embedded_css" option. That way there's no ambiguity. My next task is to add the toolbox button mentioned in: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-December/005531.html It may hold CSS options akin to: [Tb Icon] .-------------------. .---------. | Change charset >|--------------------------------->| UTF-8 | | CSS >|-->.---------------. | Cp 1250 | | Free memory >|-. |* remote CSS | | ... | '-------------------' | |* embedded CSS | '---------' | |* use my CSS | | |* no CSS at all| | '---------------' | .------------------. '->| Images | | Local Files | | Everything unused | '-------------------' Note: '*' means a toggle option Note2: "use my CSS" replaces "Force my colors" We can polish from there. > * form.cc is not yet converted to the new style handling and widget > coloring is broken. OK. > * css-prototype displays e.g. table borders in the current color not > in shaded background-color as dillo-main does. > This is because CSS 2.1 states: > "If an element's border color is not specified with a border > property, user agents must use the value of the element's 'color' > property as the computed value for the border color. " > (http://www.w3.org/TR/CSS21/box.html#border-color-properties) > firefox however also uses a shaded background color. > I'd don't know how to deal with that at the moment. I'd say leave it as the standard says until it becomes an issue. In that case we can follow FF or decide better. > Then there is of course tons of issues with CSS, but we can improve > on that gradually. That's the idea. BTW, I have a question. How can a minimal font size be specified? Currently I have: body {font-size: 18px !important} in style.css, but often pages come with smaller fonts. e.g. http://www.linux.org.uk/Portaloo.cs For me is important because I have a problems reading tiny fonts, and my working laptop has a high screen resolution. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From Johannes.Hofmann at gmx.de Thu Jan 15 15:25:58 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Thu Jan 15 15:33:40 2009 Subject: [Dillo-dev] Re: A couple of patches In-Reply-To: <20090115134159.GZ20533@dillo.org> References: <20090114220700.GX20533@dillo.org> <20090115090737.GA5006@blob.baaderstrasse.com> <20090115134159.GZ20533@dillo.org> Message-ID: <20090115142558.GA895@blob.baaderstrasse.com> On Thu, Jan 15, 2009 at 10:41:59AM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Thu, Jan 15, 2009 at 10:07:37AM +0100, Hofmann Johannes wrote: > > Hi Jorge, > > > > On Wed, Jan 14, 2009 at 07:07:00PM -0300, Jorge Arellano Cid wrote: > > > Hi Johannes, > > > > > > Here go couple of patches. Please test and apply. > > > > Thanks, applied. > > > > > > > > Note: the image background support is partial. It works well > > > when coming back to a page. AFAIS the right solution is to decode > > > transparent images to RGBA and let FLTK handle it. > > > > Yes, I think that would be the correct way to do it. > > > > > > > > BTW, the CSS prototype seems stable enough to consider a merge. > > > What do you think? > > > > Yes, it feels pretty stable and now that there is an option to > > disable remote stylesheet loading, I think we can consider making > > css-prototype the main branch of dillo. > > However I'd like to have some issues fixed: > > > > * should load_stylesheets=NO only disable remote style-sheet loading > > (as it does now), or should it disable all remote style processing > > (e.g. style given in )? > > We can add a "parse_embedded_css" option. That way there's no > ambiguity. > > My next task is to add the toolbox button mentioned in: > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-December/005531.html > > It may hold CSS options akin to: > > [Tb Icon] > .-------------------. .---------. > | Change charset >|--------------------------------->| UTF-8 | > | CSS >|-->.---------------. | Cp 1250 | > | Free memory >|-. |* remote CSS | | ... | > '-------------------' | |* embedded CSS | '---------' > | |* use my CSS | > | |* no CSS at all| > | '---------------' > | .------------------. > '->| Images | > | Local Files | > | Everything unused | > '-------------------' > > Note: '*' means a toggle option > Note2: "use my CSS" replaces "Force my colors" > > We can polish from there. Ok, but I think we can reduce the CSS part to * remote CSS - meaning separate stylesheets * embedded CSS - meaning CSS in or style="" attribute I think we should always use "my CSS" if it exists. "no CSS at all" would be the same as no .dillo/style.css and "remote CSS" and "embedded CSS" switched off. > > > > * form.cc is not yet converted to the new style handling and widget > > coloring is broken. > > OK. > > > * css-prototype displays e.g. table borders in the current color not > > in shaded background-color as dillo-main does. > > This is because CSS 2.1 states: > > "If an element's border color is not specified with a border > > property, user agents must use the value of the element's 'color' > > property as the computed value for the border color. " > > (http://www.w3.org/TR/CSS21/box.html#border-color-properties) > > firefox however also uses a shaded background color. > > I'd don't know how to deal with that at the moment. > > I'd say leave it as the standard says until it becomes an issue. > In that case we can follow FF or decide better. The problem is that I'm not sure I understand the standard properly. Firefox is generally pretty standard compliant. But it's not a big issue anyway. > > > > Then there is of course tons of issues with CSS, but we can improve > > on that gradually. > > That's the idea. > > > BTW, I have a question. How can a minimal font size be specified? > Currently I have: > > body {font-size: 18px !important} The problem is that this can be overridden e.g. by later elements. * {font-size: 18px !important} should fix the font size to 18px. However we probabely want an non-CSS option in dillorc to set a minimum font size. > > in style.css, but often pages come with smaller fonts. e.g. > http://www.linux.org.uk/Portaloo.cs > > For me is important because I have a problems reading tiny fonts, > and my working laptop has a high screen resolution. css-prototype seems to use pretty small fonts generally. This may be a bug. Cheers, Johannes From Johannes.Hofmann at gmx.de Thu Jan 15 16:34:10 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Thu Jan 15 16:41:50 2009 Subject: [Dillo-dev] focus after closing tab In-Reply-To: <20090115114222.GY20533@dillo.org> References: <20090113130333.GC1708@blob.baaderstrasse.com> <20090115060328.GK10178@omphalos.singularity> <20090115114222.GY20533@dillo.org> Message-ID: <20090115153410.GA1615@blob.baaderstrasse.com> On Thu, Jan 15, 2009 at 08:42:22AM -0300, Jorge Arellano Cid wrote: > On Thu, Jan 15, 2009 at 06:03:28AM +0000, Jeremy Henty wrote: > > On Tue, Jan 13, 2009 at 02:03:33PM +0100, Hofmann Johannes wrote: > > > > > What do you think, which page should be focused when closing a tab: > > > > > * the most recently opened one? > > > > +1 . It would certainly be better than the current behaviour. > > Current behaviour is a bug. Without experience on the subject I'd > say let's follow firefox bahaviour on this. As far as I can tell firefox always switches to the right most tab which should for us be equivalent to the most recently opened one (as we do not allow to reorder tabs). Attached patchlet implements this behaviour for dillo. Cheers, Johannes -------------- next part -------------- diff -r 8f7293125059 src/uicmd.cc --- a/src/uicmd.cc Sun Jan 11 08:50:21 2009 -0300 +++ b/src/uicmd.cc Thu Jan 15 16:30:38 2009 +0100 @@ -290,6 +290,7 @@ void a_UIcmd_close_bw(void *vbw) delete(layout); if (ui->tabs()) { ui->tabs()->remove(ui); + ui->tabs()->value(ui->tabs()->children() - 1); if (ui->tabs()->value() != -1) ui->tabs()->selected_child()->take_focus(); else From Johannes.Hofmann at gmx.de Thu Jan 15 19:40:28 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Thu Jan 15 19:48:13 2009 Subject: [Dillo-dev] Re: A couple of patches In-Reply-To: <20090115134159.GZ20533@dillo.org> References: <20090114220700.GX20533@dillo.org> <20090115090737.GA5006@blob.baaderstrasse.com> <20090115134159.GZ20533@dillo.org> Message-ID: <20090115184028.GA7347@blob.baaderstrasse.com> On Thu, Jan 15, 2009 at 10:41:59AM -0300, Jorge Arellano Cid wrote: * snip* > > BTW, I have a question. How can a minimal font size be specified? > Currently I have: > > body {font-size: 18px !important} > > in style.css, but often pages come with smaller fonts. e.g. > http://www.linux.org.uk/Portaloo.cs > > For me is important because I have a problems reading tiny fonts, > and my working laptop has a high screen resolution. I've just made a change that uses the existing prefs.font_factor value to scale the base font. However this only applies to relative font sizes. If someone specifies "font-size: 10px" you will still get 10px, but I think this is correct anyway. In addition we can add some minimal_fontsize option in the future. Cheers, Johannes From jcid at dillo.org Thu Jan 15 22:18:16 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Jan 15 22:18:23 2009 Subject: [Dillo-dev] focus after closing tab In-Reply-To: <20090115153410.GA1615@blob.baaderstrasse.com> References: <20090113130333.GC1708@blob.baaderstrasse.com> <20090115060328.GK10178@omphalos.singularity> <20090115114222.GY20533@dillo.org> <20090115153410.GA1615@blob.baaderstrasse.com> Message-ID: <20090115211816.GB9969@dillo.org> On Thu, Jan 15, 2009 at 04:34:10PM +0100, Hofmann Johannes wrote: > On Thu, Jan 15, 2009 at 08:42:22AM -0300, Jorge Arellano Cid wrote: > > On Thu, Jan 15, 2009 at 06:03:28AM +0000, Jeremy Henty wrote: > > > On Tue, Jan 13, 2009 at 02:03:33PM +0100, Hofmann Johannes wrote: > > > > > > > What do you think, which page should be focused when closing a tab: > > > > > > > * the most recently opened one? > > > > > > +1 . It would certainly be better than the current behaviour. > > > > Current behaviour is a bug. Without experience on the subject I'd > > say let's follow firefox bahaviour on this. > > As far as I can tell firefox always switches to the right most tab > which should for us be equivalent to the most recently opened one > (as we do not allow to reorder tabs). > > Attached patchlet implements this behaviour for dillo. Committed. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jcid at dillo.org Fri Jan 16 18:50:43 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Jan 16 18:50:47 2009 Subject: [Dillo-dev] CSS branch merged! Message-ID: <20090116175043.GG9969@dillo.org> Hi there, The CSS branch was merged back into main! It has been stabilized and we can continue working from this basis towards our next release. I want to thank all of you involved in helping this happen. Having basic CSS support merged in, is quite an achievement! :-) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From furaisanjin at gmail.com Sat Jan 17 08:07:05 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Sat Jan 17 08:07:10 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <20090116175043.GG9969@dillo.org> References: <20090116175043.GG9969@dillo.org> Message-ID: <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> Hi all. I just tried this and noticed that I wasn't able to change font by dillorc. It seems that all fonts are decided in css.c - buildUserAgentStyle. Regards, furaisanjin From corvid at lavabit.com Sat Jan 17 08:33:37 2009 From: corvid at lavabit.com (corvid) Date: Sat Jan 17 08:35:40 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> References: <20090116175043.GG9969@dillo.org> <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> Message-ID: <20090117073337.GC23795@local.gobigwest.com> furaisanjin wrote: > I just tried this and noticed that I wasn't able to change font by > dillorc. It seems that all fonts are decided in css.c - > buildUserAgentStyle. For now you could override them in .dillo/style.css From Johannes.Hofmann at gmx.de Sat Jan 17 09:18:12 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Jan 17 09:25:56 2009 Subject: [Dillo-dev] Re: patch: some consts In-Reply-To: <20090117010912.GB23795@local.gobigwest.com> References: <20090117010912.GB23795@local.gobigwest.com> Message-ID: <20090117081812.GA896@blob.baaderstrasse.com> On Sat, Jan 17, 2009 at 01:09:12AM +0000, corvid wrote: > (and an unrelated static) > It was time for my occasional running of nm... > committed! Thanks, Johannes From furaisanjin at gmail.com Sat Jan 17 09:47:19 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Sat Jan 17 09:47:27 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <20090117073337.GC23795@local.gobigwest.com> References: <20090116175043.GG9969@dillo.org> <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> <20090117073337.GC23795@local.gobigwest.com> Message-ID: <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> Thank you, now I can change my favorite font in much easier way. I have one more question. Is there any way to specify default font if the font specified in style sheet doesn't exist on local machine? For example, when style sheet contains body { font-family: MS Gothic, Osaka, monospace; } but I don't have none of them but I have VL Gothic. In this case I want to use VL Gothic as backup. Regards, furaisanjin 2009/1/17 corvid : > furaisanjin wrote: >> I just tried this and noticed that I wasn't able to change font by >> dillorc. It seems that all fonts are decided in css.c - >> buildUserAgentStyle. > > For now you could override them in .dillo/style.css > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > From Johannes.Hofmann at gmx.de Sat Jan 17 10:16:31 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Jan 17 10:24:43 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> References: <20090116175043.GG9969@dillo.org> <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> <20090117073337.GC23795@local.gobigwest.com> <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> Message-ID: <20090117091630.GA869@blob.baaderstrasse.com> On Sat, Jan 17, 2009 at 05:47:19PM +0900, furaisanjin wrote: > Thank you, now I can change my favorite font in much easier way. I > have one more question. Is there any way to specify default font if > the font specified in style sheet doesn't exist on local machine? > > For example, when style sheet contains > > body { font-family: MS Gothic, Osaka, monospace; } In this case dillo should try the three fonts given. At least "monospace" should exist and be mapped to some default monospace font. This part of the font selection is just not implemented yet. > > but I don't have none of them but I have VL Gothic. In this case I > want to use VL Gothic as backup. It might be possible to map font names at the X11 level, i.e. in .fonts.conf. But I don't know the details. Regards, Johannes From onepoint at starurchin.org Sat Jan 17 11:38:22 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sat Jan 17 11:38:59 2009 Subject: [Dillo-dev] [patch]: add copyright and license declaration to cssparser.cc Message-ID: <20090117103822.GA20726@omphalos.singularity> There's no copyright or license in cssparser.cc . Patch attached. Regards, Jeremy Henty -------------- next part -------------- # HG changeset patch # User Jeremy Henty # Date 1232188142 0 # Node ID 499c39e744429213b53e5793960d8067f1a31210 # Parent 19b91909aa9807e84344c32612353b90b0bcd541 [mq]: add-cssparser-copyright diff --git a/ChangeLog b/ChangeLog --- a/ChangeLog +++ b/ChangeLog @@ -32,6 +32,7 @@ - Cleaned up and normalized D_SUN_LEN usage. - Fixed incorrect use of VOIDP2INT in Dialog_user_password_cb(). - Ensure that the dlib dStr* functions are used everywhere. + - Add missing copyright/license declarations. Patches: Jeremy Henty +- Implemented Basic authentication! Patch: Jeremy Henty, Jorge Arellano Cid diff --git a/src/cssparser.cc b/src/cssparser.cc --- a/src/cssparser.cc +++ b/src/cssparser.cc @@ -1,3 +1,14 @@ +/* + * File: cssparser.cc + * + * Copyright 2008 Jorge Arellano Cid + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 3 of the License, or + * (at your option) any later version. + */ + #include #include #include From onepoint at starurchin.org Sat Jan 17 12:09:01 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sat Jan 17 12:09:35 2009 Subject: [Dillo-dev] [patch]: add copyright and license declarations to dpid sources Message-ID: <20090117110901.GB20726@omphalos.singularity> I checked all the *.{c,cc} files and found that a couple of the dpid/ files were missing copyrights too. Patch attached. Regards, Jeremy Henty -------------- next part -------------- # HG changeset patch # User Jeremy Henty # Date 1232189955 0 # Node ID 5d6b2931d791b5a83042cfff617f714b82559f5d # Parent 5452efea6bb9344773714db17e5b32874ac3d0a5 [mq]: add-dpid-copyright diff --git a/dpid/dpid_common.c b/dpid/dpid_common.c --- a/dpid/dpid_common.c +++ b/dpid/dpid_common.c @@ -1,3 +1,14 @@ +/* + * File: dpid_common.c + * + * Copyright 2008 Jorge Arellano Cid + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 3 of the License, or + * (at your option) any later version. + */ + #include #include #include diff --git a/dpid/misc_new.c b/dpid/misc_new.c --- a/dpid/misc_new.c +++ b/dpid/misc_new.c @@ -1,3 +1,14 @@ +/* + * File: misc_new.c + * + * Copyright 2008 Jorge Arellano Cid + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 3 of the License, or + * (at your option) any later version. + */ + #include #include #include From Johannes.Hofmann at gmx.de Sat Jan 17 12:15:54 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Jan 17 12:23:36 2009 Subject: [Dillo-dev] [patch]: add copyright and license declaration to cssparser.cc In-Reply-To: <20090117103822.GA20726@omphalos.singularity> References: <20090117103822.GA20726@omphalos.singularity> Message-ID: <20090117111554.GA1124@blob.baaderstrasse.com> On Sat, Jan 17, 2009 at 10:38:22AM +0000, Jeremy Henty wrote: > > There's no copyright or license in cssparser.cc . Patch attached. That's because cssparser.cc is mostly taken from dillo-0.8.0-css-3 which was written by Sebastian. We are still trying to contact him regarding the copyright. Cheers, Johannes From onepoint at starurchin.org Sat Jan 17 12:37:45 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sat Jan 17 12:38:18 2009 Subject: [Dillo-dev] [patch]: add copyright and license declaration to cssparser.cc In-Reply-To: <20090117111554.GA1124@blob.baaderstrasse.com> References: <20090117103822.GA20726@omphalos.singularity> <20090117111554.GA1124@blob.baaderstrasse.com> Message-ID: <20090117113745.GC20726@omphalos.singularity> On Sat, Jan 17, 2009 at 12:15:54PM +0100, Hofmann Johannes wrote: > On Sat, Jan 17, 2009 at 10:38:22AM +0000, Jeremy Henty wrote: > > > > There's no copyright or license in cssparser.cc . Patch attached. > > That's because cssparser.cc is mostly taken from dillo-0.8.0-css-3 > which was written by Sebastian. We are still trying to contact him > regarding the copyright. Ah, I didn't know that. Thanks for the update. Jeremy Henty From jcid at dillo.org Sat Jan 17 13:45:07 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sat Jan 17 13:45:15 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <20090117091630.GA869@blob.baaderstrasse.com> References: <20090116175043.GG9969@dillo.org> <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> <20090117073337.GC23795@local.gobigwest.com> <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> <20090117091630.GA869@blob.baaderstrasse.com> Message-ID: <20090117124506.GJ9969@dillo.org> On Sat, Jan 17, 2009 at 10:16:31AM +0100, Hofmann Johannes wrote: > On Sat, Jan 17, 2009 at 05:47:19PM +0900, furaisanjin wrote: > > Thank you, now I can change my favorite font in much easier way. I > > have one more question. Is there any way to specify default font if > > the font specified in style sheet doesn't exist on local machine? > > > > For example, when style sheet contains > > > > body { font-family: MS Gothic, Osaka, monospace; } > > In this case dillo should try the three fonts given. At least > "monospace" should exist and be mapped to some default monospace > font. > This part of the font selection is just not implemented yet. > > > > > but I don't have none of them but I have VL Gothic. In this case I > > want to use VL Gothic as backup. > > It might be possible to map font names at the X11 level, i.e. in > .fonts.conf. But I don't know the details. BTW, is it possible to force a single font in style.css? this is, even when the page specified font exists in the machine. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jcid at dillo.org Sat Jan 17 13:49:21 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sat Jan 17 13:49:26 2009 Subject: [Dillo-dev] [patch]: add copyright and license declarations to dpid sources In-Reply-To: <20090117110901.GB20726@omphalos.singularity> References: <20090117110901.GB20726@omphalos.singularity> Message-ID: <20090117124921.GK9969@dillo.org> On Sat, Jan 17, 2009 at 11:09:01AM +0000, Jeremy Henty wrote: > > I checked all the *.{c,cc} files and found that a couple of the dpid/ > files were missing copyrights too. Patch attached. Committed. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From corvid at lavabit.com Sat Jan 17 16:20:45 2009 From: corvid at lavabit.com (corvid) Date: Sat Jan 17 16:22:46 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <20090117124506.GJ9969@dillo.org> References: <20090116175043.GG9969@dillo.org> <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> <20090117073337.GC23795@local.gobigwest.com> <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> <20090117091630.GA869@blob.baaderstrasse.com> <20090117124506.GJ9969@dillo.org> Message-ID: <20090117152045.GD23795@local.gobigwest.com> Jorge wrote: > On Sat, Jan 17, 2009 at 10:16:31AM +0100, Hofmann Johannes wrote: > > On Sat, Jan 17, 2009 at 05:47:19PM +0900, furaisanjin wrote: > > > Thank you, now I can change my favorite font in much easier way. I > > > have one more question. Is there any way to specify default font if > > > the font specified in style sheet doesn't exist on local machine? > > > > > > For example, when style sheet contains > > > > > > body { font-family: MS Gothic, Osaka, monospace; } > > > > In this case dillo should try the three fonts given. At least > > "monospace" should exist and be mapped to some default monospace > > font. > > This part of the font selection is just not implemented yet. > > > > > > > > but I don't have none of them but I have VL Gothic. In this case I > > > want to use VL Gothic as backup. > > > > It might be possible to map font names at the X11 level, i.e. in > > .fonts.conf. But I don't know the details. > > BTW, is it possible to force a single font in style.css? > this is, even when the page specified font exists in the machine. I'm not sure whether it's working for the right reason, but I haven't seen any Courier since I put code, tt, pre, samp, kbd {font-family: mono !important} in mine. BTW, are bold and italic supposed to work? From Johannes.Hofmann at gmx.de Sat Jan 17 16:20:17 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Jan 17 16:28:00 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <20090117124506.GJ9969@dillo.org> References: <20090116175043.GG9969@dillo.org> <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> <20090117073337.GC23795@local.gobigwest.com> <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> <20090117091630.GA869@blob.baaderstrasse.com> <20090117124506.GJ9969@dillo.org> Message-ID: <20090117152017.GA946@blob.baaderstrasse.com> On Sat, Jan 17, 2009 at 09:45:07AM -0300, Jorge Arellano Cid wrote: > On Sat, Jan 17, 2009 at 10:16:31AM +0100, Hofmann Johannes wrote: > > On Sat, Jan 17, 2009 at 05:47:19PM +0900, furaisanjin wrote: > > > Thank you, now I can change my favorite font in much easier way. I > > > have one more question. Is there any way to specify default font if > > > the font specified in style sheet doesn't exist on local machine? > > > > > > For example, when style sheet contains > > > > > > body { font-family: MS Gothic, Osaka, monospace; } > > > > In this case dillo should try the three fonts given. At least > > "monospace" should exist and be mapped to some default monospace > > font. > > This part of the font selection is just not implemented yet. > > > > > > > > but I don't have none of them but I have VL Gothic. In this case I > > > want to use VL Gothic as backup. > > > > It might be possible to map font names at the X11 level, i.e. in > > .fonts.conf. But I don't know the details. > > BTW, is it possible to force a single font in style.css? > this is, even when the page specified font exists in the machine. * {font-family: helvetica !important} should do that. Cheers, Johannes From Johannes.Hofmann at gmx.de Sat Jan 17 16:22:24 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Jan 17 16:30:05 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <144aa14b0901170604j3e4bc0bbn7967c11fb9caa947@mail.gmail.com> References: <20090116175043.GG9969@dillo.org> <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> <20090117073337.GC23795@local.gobigwest.com> <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> <20090117091630.GA869@blob.baaderstrasse.com> <144aa14b0901170604j3e4bc0bbn7967c11fb9caa947@mail.gmail.com> Message-ID: <20090117152224.GC946@blob.baaderstrasse.com> On Sat, Jan 17, 2009 at 11:04:12PM +0900, furaisanjin wrote: > 2009/1/17 Hofmann Johannes : > > In this case dillo should try the three fonts given. At least > > "monospace" should exist and be mapped to some default monospace > > font. > > I don't have such font which name is "monospace" on my machine. > fc-list command doesn't show such name. What is the default mono space > font in the current CSS implementation? None. That part is not yet implemented. > > Because some pages written in Japanese contain fonts that I don't have > at all, I can't read such pages. See my answer to Jorge's mail on how to force a fixed font-family. Regards, Johannes From Johannes.Hofmann at gmx.de Sat Jan 17 16:24:06 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Jan 17 16:31:46 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <144aa14b0901170651m20c31e18j49be2fcd37780e3e@mail.gmail.com> References: <20090116175043.GG9969@dillo.org> <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> <20090117073337.GC23795@local.gobigwest.com> <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> <20090117091630.GA869@blob.baaderstrasse.com> <144aa14b0901170604j3e4bc0bbn7967c11fb9caa947@mail.gmail.com> <144aa14b0901170651m20c31e18j49be2fcd37780e3e@mail.gmail.com> Message-ID: <20090117152406.GD946@blob.baaderstrasse.com> On Sat, Jan 17, 2009 at 11:51:37PM +0900, furaisanjin wrote: > Sorry, I mixed up 2 things. I guess default font is something I > specified in ~/.dillo/style.css if dillo can't find any fonts > specified in style. It seems that there is some timing issue when the > page is loaded. The first time somehow the page is unreadable but if I > goto to bookmark page and come back to the page, the page is readable. Argh, timing issues are bad. Can you please point me to a page where this happens? > > Another issue is that if style sheet specified none Japanese font and > the font exists on my machine, then of course the page isn't readable > at all. This isn't dillo problem but style sheet problem. Do you have an example? How does firefox handle these pages? Regards, Johannes From Johannes.Hofmann at gmx.de Sat Jan 17 16:25:28 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Jan 17 16:33:11 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <20090117152045.GD23795@local.gobigwest.com> References: <20090116175043.GG9969@dillo.org> <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> <20090117073337.GC23795@local.gobigwest.com> <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> <20090117091630.GA869@blob.baaderstrasse.com> <20090117124506.GJ9969@dillo.org> <20090117152045.GD23795@local.gobigwest.com> Message-ID: <20090117152528.GE946@blob.baaderstrasse.com> On Sat, Jan 17, 2009 at 03:20:45PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Jan 17, 2009 at 10:16:31AM +0100, Hofmann Johannes wrote: > > > On Sat, Jan 17, 2009 at 05:47:19PM +0900, furaisanjin wrote: > > > > Thank you, now I can change my favorite font in much easier way. I > > > > have one more question. Is there any way to specify default font if > > > > the font specified in style sheet doesn't exist on local machine? > > > > > > > > For example, when style sheet contains > > > > > > > > body { font-family: MS Gothic, Osaka, monospace; } > > > > > > In this case dillo should try the three fonts given. At least > > > "monospace" should exist and be mapped to some default monospace > > > font. > > > This part of the font selection is just not implemented yet. > > > > > > > > > > > but I don't have none of them but I have VL Gothic. In this case I > > > > want to use VL Gothic as backup. > > > > > > It might be possible to map font names at the X11 level, i.e. in > > > .fonts.conf. But I don't know the details. > > > > BTW, is it possible to force a single font in style.css? > > this is, even when the page specified font exists in the machine. > > I'm not sure whether it's working for the right reason, > but I haven't seen any Courier since I put > code, tt, pre, samp, kbd {font-family: mono !important} > in mine. > > BTW, are bold and italic supposed to work? Yes, where are you seeing problems? Cheers, Johannes From corvid at lavabit.com Sat Jan 17 16:43:30 2009 From: corvid at lavabit.com (corvid) Date: Sat Jan 17 16:45:29 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <20090117152528.GE946@blob.baaderstrasse.com> References: <20090116175043.GG9969@dillo.org> <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> <20090117073337.GC23795@local.gobigwest.com> <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> <20090117091630.GA869@blob.baaderstrasse.com> <20090117124506.GJ9969@dillo.org> <20090117152045.GD23795@local.gobigwest.com> <20090117152528.GE946@blob.baaderstrasse.com> Message-ID: <20090117154330.GE23795@local.gobigwest.com> Johannes wrote: > On Sat, Jan 17, 2009 at 03:20:45PM +0000, corvid wrote: > > BTW, are bold and italic supposed to work? > > Yes, where are you seeing problems? I don't see them at all. From Johannes.Hofmann at gmx.de Sat Jan 17 16:51:35 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Jan 17 16:59:16 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <20090117154330.GE23795@local.gobigwest.com> References: <20090116175043.GG9969@dillo.org> <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> <20090117073337.GC23795@local.gobigwest.com> <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> <20090117091630.GA869@blob.baaderstrasse.com> <20090117124506.GJ9969@dillo.org> <20090117152045.GD23795@local.gobigwest.com> <20090117152528.GE946@blob.baaderstrasse.com> <20090117154330.GE23795@local.gobigwest.com> Message-ID: <20090117155135.GA1107@blob.baaderstrasse.com> On Sat, Jan 17, 2009 at 03:43:30PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Jan 17, 2009 at 03:20:45PM +0000, corvid wrote: > > > BTW, are bold and italic supposed to work? > > > > Yes, where are you seeing problems? > > I don't see them at all. Hm, do you have a user stylesheet set? For me Hello World dillo works ok. Cheers, Johannes From corvid at lavabit.com Sat Jan 17 17:29:37 2009 From: corvid at lavabit.com (corvid) Date: Sat Jan 17 17:31:36 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <20090117155135.GA1107@blob.baaderstrasse.com> References: <20090116175043.GG9969@dillo.org> <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> <20090117073337.GC23795@local.gobigwest.com> <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> <20090117091630.GA869@blob.baaderstrasse.com> <20090117124506.GJ9969@dillo.org> <20090117152045.GD23795@local.gobigwest.com> <20090117152528.GE946@blob.baaderstrasse.com> <20090117154330.GE23795@local.gobigwest.com> <20090117155135.GA1107@blob.baaderstrasse.com> Message-ID: <20090117162936.GF23795@local.gobigwest.com> Johannes wrote: > On Sat, Jan 17, 2009 at 03:43:30PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Jan 17, 2009 at 03:20:45PM +0000, corvid wrote: > > > > BTW, are bold and italic supposed to work? > > > > > > Yes, where are you seeing problems? > > > > I don't see them at all. > > Hm, do you have a user stylesheet set? > > For me > > > Hello World > dillo > > > works ok. It was breaking with or without a user stylesheet, but now I have found that adding * {font-family: sans !important} makes them appear properly. My system must not like Helvetica or something... I wonder whether there's a way to specify something like code, tt, pre, samp, kbd {font-family: mono !important} * {font-family: sans !important} but have sans only for elements not otherwise specified. From Johannes.Hofmann at gmx.de Sat Jan 17 18:05:42 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Jan 17 18:13:24 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <20090117162936.GF23795@local.gobigwest.com> References: <144aa14b0901162307t42084314s5035c1276223b32e@mail.gmail.com> <20090117073337.GC23795@local.gobigwest.com> <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> <20090117091630.GA869@blob.baaderstrasse.com> <20090117124506.GJ9969@dillo.org> <20090117152045.GD23795@local.gobigwest.com> <20090117152528.GE946@blob.baaderstrasse.com> <20090117154330.GE23795@local.gobigwest.com> <20090117155135.GA1107@blob.baaderstrasse.com> <20090117162936.GF23795@local.gobigwest.com> Message-ID: <20090117170542.GA2284@blob.baaderstrasse.com> On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Jan 17, 2009 at 03:43:30PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sat, Jan 17, 2009 at 03:20:45PM +0000, corvid wrote: > > > > > BTW, are bold and italic supposed to work? > > > > > > > > Yes, where are you seeing problems? > > > > > > I don't see them at all. > > > > Hm, do you have a user stylesheet set? > > > > For me > > > > > > Hello World > > dillo > > > > > > works ok. > > It was breaking with or without a user stylesheet, > but now I have found that adding > * {font-family: sans !important} > makes them appear properly. > My system must not like Helvetica or something... Currently font handling is more or less not existing. Whatever we get from CSS as font-family is passed directly to fltk - even if it is a comma separated list. > > > I wonder whether there's a way to specify something like > code, tt, pre, samp, kbd {font-family: mono !important} > * {font-family: sans !important} > but have sans only for elements not otherwise specified. > According to http://www.w3.org/TR/CSS21/cascade.html#specificity the first rule should overrule the second one if it matches. So this should work. Note, that the specificity stuff is not fully implemented yet, but it should be sufficient for the example above. Cheers, Johannes From onepoint at starurchin.org Sat Jan 17 19:53:13 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sat Jan 17 19:53:52 2009 Subject: [Dillo-dev] [patch]: fix DBG build of table.cc Message-ID: <20090117185313.GD20726@omphalos.singularity> If you uncomment the #define of DBG in table.cc it won't compile. It looks as though most of the DBG code was fixed not to use the non-existent "result" variable, but one instance was left unchanged. Patch attached. Regards, Jeremy Henty -------------- next part -------------- # HG changeset patch # User Jeremy Henty # Date 1232218073 0 # Node ID 4ee0c83b1694ff3b1c3c3a6bd3e57376d7c78202 # Parent 49735e57803910d92ec235c5f1b65aa1033d8722 imported patch fix-table-dbg-build diff --git a/dw/table.cc b/dw/table.cc --- a/dw/table.cc +++ b/dw/table.cc @@ -947,7 +947,7 @@ #ifdef DBG MSG("APP_P, result = { "); for (int col = 0; col < numCols; col++) - MSG("%d ", result->get(col)); + MSG("%d ", colWidths->get(col)); MSG("}\n"); #endif From onepoint at starurchin.org Sat Jan 17 19:57:55 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sat Jan 17 19:58:28 2009 Subject: [Dillo-dev] [patch]: control lout's MSG from the preferences Message-ID: <20090117185755.GE20726@omphalos.singularity> This patch makes the dillorc show_msg preference control lout's MSG macros as well as dillo's. Please comment. Regards, Jeremy Henty -------------- next part -------------- # HG changeset patch # User Jeremy Henty # Date 1232218073 0 # Node ID 733de5e43a21b4270eb0baef6b7c83541161af43 # Parent 4ee0c83b1694ff3b1c3c3a6bd3e57376d7c78202 imported patch prefs-control-lout-msg diff --git a/lout/Makefile.am b/lout/Makefile.am --- a/lout/Makefile.am +++ b/lout/Makefile.am @@ -12,4 +12,6 @@ object.hh \ signal.cc \ signal.hh \ - msg.h + msg.h \ + message.hh \ + message.cc diff --git a/lout/message.cc b/lout/message.cc new file mode 100644 --- /dev/null +++ b/lout/message.cc @@ -0,0 +1,21 @@ +/* + * Copyright 2009 Jeremy Henty + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#include "message.hh" + +int lout::message::show_ = 1; diff --git a/lout/message.hh b/lout/message.hh new file mode 100644 --- /dev/null +++ b/lout/message.hh @@ -0,0 +1,14 @@ +#ifndef __MESSAGE_H__ +#define __MESSAGE_H__ + +namespace lout { +class message { +private: + static int show_; +public: + static int show() { return show_; } + static void show(int s) { show_ = s; } +}; +} + +#endif /* __MESSAGE_H__ */ diff --git a/lout/msg.h b/lout/msg.h --- a/lout/msg.h +++ b/lout/msg.h @@ -2,9 +2,7 @@ #define __MSG_H__ #include - -/*#include "prefs.h"*/ -#define prefs_show_msg 1 +#include "message.hh" #define D_STMT_START do #define D_STMT_END while (0) @@ -19,7 +17,7 @@ #define MSG(...) \ D_STMT_START { \ - if (prefs_show_msg){ \ + if (lout::message::show()){ \ printf(__VA_ARGS__); \ fflush (stdout); \ } \ @@ -27,13 +25,13 @@ #define MSG_WARN(...) \ D_STMT_START { \ - if (prefs_show_msg) \ + if (lout::message::show()) \ printf("** WARNING **: " __VA_ARGS__); \ } D_STMT_END #define MSG_ERR(...) \ D_STMT_START { \ - if (prefs_show_msg) \ + if (lout::message::show()) \ printf("** ERROR **: " __VA_ARGS__); \ } D_STMT_END diff --git a/src/dillo.cc b/src/dillo.cc --- a/src/dillo.cc +++ b/src/dillo.cc @@ -29,6 +29,8 @@ #include #include +#include "lout/message.hh" + #include "msg.h" #include "dir.h" #include "uicmd.hh" @@ -280,6 +282,8 @@ prefs.ypos = ypos; } + lout::message::show(prefs.show_msg); + // Sets WM_CLASS hint on X11 fltk::Window::xclass("dillo"); From corvid at lavabit.com Sat Jan 17 20:17:53 2009 From: corvid at lavabit.com (corvid) Date: Sat Jan 17 20:19:54 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <20090117170542.GA2284@blob.baaderstrasse.com> References: <20090117073337.GC23795@local.gobigwest.com> <144aa14b0901170047w8c31191wfb9e0fb91080a4d9@mail.gmail.com> <20090117091630.GA869@blob.baaderstrasse.com> <20090117124506.GJ9969@dillo.org> <20090117152045.GD23795@local.gobigwest.com> <20090117152528.GE946@blob.baaderstrasse.com> <20090117154330.GE23795@local.gobigwest.com> <20090117155135.GA1107@blob.baaderstrasse.com> <20090117162936.GF23795@local.gobigwest.com> <20090117170542.GA2284@blob.baaderstrasse.com> Message-ID: <20090117191753.GG23795@local.gobigwest.com> Johannes wrote: > On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > > I wonder whether there's a way to specify something like > > code, tt, pre, samp, kbd {font-family: mono !important} > > * {font-family: sans !important} > > but have sans only for elements not otherwise specified. > > > > According to http://www.w3.org/TR/CSS21/cascade.html#specificity > the first rule should overrule the second one if it matches. > So this should work. > Note, that the specificity stuff is not fully implemented yet, but > it should be sufficient for the example above. Does it work for you? Also, is supposed to work? From akemnade at tzi.de Sat Jan 17 20:52:00 2009 From: akemnade at tzi.de (Andreas Kemnade) Date: Sat Jan 17 20:52:40 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <20090116175043.GG9969@dillo.org> References: <20090116175043.GG9969@dillo.org> Message-ID: <20090117205200.36481628@kemnade.info> Hi, On Fri, 16 Jan 2009 14:50:43 -0300 Jorge Arellano Cid wrote: > Hi there, > > The CSS branch was merged back into main! > > It has been stabilized and we can continue working from this > basis towards our next release. I want to thank all of you > involved in helping this happen. Having basic CSS support merged > in, is quite an achievement! > nice. But.. the second page I opened causes dillo to crash. That was http://www.wetteronline.de/ (gdb) bt #0 0x080a3a85 in dw::core::Widget::queueResize (this=0x9bc1db0, ref=0, extremesChanged=true) at widget.cc:347 #1 0x080a41c3 in dw::core::Widget::setStyle (this=0x9bc1db0, style=0x9bc26f0) at widget.cc:520 #2 0x08072646 in Html_tag_open_input (html=0x9b45020, tag=0x9b90149 "\n", ' ' , "\n", ' ' ..., tagsize=150) at form.cc:1954 #3 0x0806c403 in Html_write_raw (html=0x9b45020, buf=0x9b8e4c1 "\n PASS 4) quit dillo 5) dillo www.blisty.cz 6) --> FAIL Can anyone, please, have a look at this and say whether is it reproducible and, perhaps, fix it? :) Thanks, -- Regards, Michal Nowak From Johannes.Hofmann at gmx.de Sat Jan 31 23:09:31 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Jan 31 23:17:22 2009 Subject: [Dillo-dev] CSS branch merged! In-Reply-To: <20090131211550.GK5972@dillo.org> References: <20090117162936.GF23795@local.gobigwest.com> <20090117170542.GA2284@blob.baaderstrasse.com> <20090117191753.GG23795@local.gobigwest.com> <20090117221129.GA935@blob.baaderstrasse.com> <20090117224236.GI23795@local.gobigwest.com> <20090117230831.GB2971@blob.baaderstrasse.com> <20090117233904.GJ23795@local.gobigwest.com> <20090118083745.GA904@blob.baaderstrasse.com> <20090130213518.GB6419@blob.baaderstrasse.com> <20090131211550.GK5972@dillo.org> Message-ID: <20090131220931.GA4124@blob.baaderstrasse.com> On Sat, Jan 31, 2009 at 06:15:50PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 30, 2009 at 10:35:18PM +0100, Hofmann Johannes wrote: > > On Sun, Jan 18, 2009 at 09:37:45AM +0100, Hofmann Johannes wrote: > > > On Sat, Jan 17, 2009 at 11:39:04PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Sat, Jan 17, 2009 at 10:42:36PM +0000, corvid wrote: > > > > > > Johannes wrote: > > > > > > > On Sat, Jan 17, 2009 at 07:17:53PM +0000, corvid wrote: > > > > > > > > Johannes wrote: > > > > > > > > > On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > > > > > > > > > > I wonder whether there's a way to specify something like > > > > > > > > > > code, tt, pre, samp, kbd {font-family: mono !important} > > > > > > > > > > * {font-family: sans !important} > > > > > > > > > > but have sans only for elements not otherwise specified. > > > > > > > > > > > > > > > > > > > > > > > > > > > > According to http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > > > > > the first rule should overrule the second one if it matches. > > > > > > > > > So this should work. > > > > > > > > > Note, that the specificity stuff is not fully implemented yet, but > > > > > > > > > it should be sufficient for the example above. > > > > > > > > > > > > > > > > Does it work for you? > > > > > > > > > > > > > > Yes, I tried: > > > > > > > > > > > > > > code, tt, pre, samp, kbd {color: green !important} > > > > > > > * {color: red !important} > > > > > > > > > > > > > > on http://www.dillo.org/CSS.html and it seemed to work ok. > > > > > > > > > > > > All red for me. > > > > > > > > > > > > I tried reverting to the official tip, even I don't have anything > > > > > > much except forms code in my tree right now. > > > > > > Still all red. > > > > > > > > > > > > How strange that we would see different behaviour here... > > > > > > I guess I'll have to dive into the code myself... > > > > > > > > > > Please check again with attached patch. > > > > > > > > It's working! > > > > Thanks! Excellent customer service :) > > > > > > It's not the proper solution though. > > > Here's the plan to apply rules according to > > > http://www.w3.org/TR/CSS21/cascade.html#specificity: > > > > > > * For each CssRule compute the specificity according to > > > http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > > * Store the rules in RuleList sorted by this specificity. > > > > > > * In CssStyleSheet::apply() merge-sort the 4 ruleLists with > > > potentially matching rules and apply them in the order given by > > > their specificity. > > > > > > If anyone feels like implementing it - go ahead :) > > > > Just implemented that. Please test. > > I don't know what to test but there're > rendering differences with this page: > > http://www.thefreedictionary.com/unneeded > > (comparing with 83d840739a0e as tip) > > HTH. Well, rendering differences are the point here :) For example on cnn.com you can now read the "Home" white on red background, which was red on red before. Thanks for testing, Johannes