- Dillo-dev - lists.mailman3.com

website FAQ update

by corvid＠lavabit.com

Jorge wrote: > > [...] (and dillorc2 -> dillorc) > > We need a way to distinguish among the rc for dillo1 and dillo2. > > Currently you can have both dillo1 and dillo2 installed, sharing > cookies and bookmarks (because we have a single ~/.dillo directory). > > Ideas are welcomed, including dillorc2 -> dillo2rc :-) I was thinking that one was just a superset of the other, but that's because I forgot that the fonts would be different.

May 19, 2008

Uncluttering dillos UI - getting rid of the dialog boxes

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jorge Arellano Cid wrote: > On Sun, May 18, 2008 at 07:15:11PM +0200, Johannes Hofmann wrote: >> shouldn't window resizing be done by the window manager? > > Yes, AFAIS. > >> Do we really need to implement this inside dillo? > > I'd let the WM do it. (e.g. ALT+F11 in Xfce). The problem with this is that we cannot switch to fullwindow mode the moment the windowmanager maximizes our window since fltk does not expose whether our window is in fullscreen mode or not. And we cannot do things like start in fullscreen mode (would be nice for presentations etc). In x11-land there is a NetWM property for this: $ xprop | grep _NET_WM_STATE _NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN We could - listen for XPropertyEvents inside of dillo (ugly) - modify fltk to expose those events (nice) But what about the two other major platforms? The homepage states that one of dillos objectives is to be platform independent. I doubt that there's a fullscreen functionality for windows apps, and I have no idea about osx. This seems like a lot of work for a functionality that works (at least it should work) across all three major platforms with a ~30 lines of code patch. What's the problem besides "on x11 the wm should take care of this"? It doesn't break anything, does it? Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIMbiVoPmwNWhsaZYRAs2MAJ955OOtsLhdC3NVyNRUC0kkOd6hbgCeMCnd Sd4ofspcJb/5MfbgF83xzTw= =aQ+g -----END PGP SIGNATURE-----

May 19, 2008

[patch] dillo and huge pages

by Johannes.Hofmann＠gmx.de

On Mon, May 19, 2008 at 01:18:01PM -0400, Jorge Arellano Cid wrote: > On Mon, May 19, 2008 at 06:23:11PM +0200, Johannes Hofmann wrote: > > Hi, > > > > to test how dillo behaves on huge pages, I downloaded the mysql > > manual as a single html page: > > http://downloads.mysql.com/docs/refman-5.1-en.html.tar.gz > > > > With this page I noticed that the drawRegion in FltkViewBase can > > grow pretty large which slows down loading the page. Attached patch > > limits the size of the drawRegion to 16 rectangles. > > > > With this patch (and HUGE_FILESIZE in cache.c increased to 16M) > > dillo works pretty well on this huge page. Better than dillo1 and > > firefox! > > Great! > > Committed. > > BTW, this is one of the important points whe should list in the > dillo2 features page. Please somebody remember this! > > > > One problem is that clicking on anchor links (to anchors within the > > page) reloads the page which take some time. > > Some time ago, we had anchors hooked with direct scroll jumps. > It was instantaneous, but the navigation stack wasn't modified > and thus BACK didn't go to the original place. > > It can be hooked to jump again, but in that case, the > navigation stack needs to be modified accordingly. This creates > two paths for the same logic operation inside dillo (which > increases the mantainability costs). That said, if there's a > simple way to do it, I agree. I will have a look at this. > > > > Also memory usage gets pretty high (250M with images disabled). > > I'm experimenting with reducing the size of struct Word in > > textblock.hh by moving the highlight stuff out of struct Word and > > into Textblock. This brings memory usage down to 199M. > > However, I don't know the highlighting stuff enough to be sure I > > don't break anything. This probabely falls into the > > "premature optimization" category anyway. > > Not at all. > > I'd say the important part is to know whether that optimization > can be done without breaking the underlying model for everything > else (a question Sebastian is the most knowledgeable person to > answer in the case of dw2). Ok, I will cleanup what I have and send a patch to the list for review. It would be really great, if Sebastian could have a look at it. Cheers, Johannes

May 19, 2008

[patch] dillo and huge pages

by jcid＠dillo.org

On Mon, May 19, 2008 at 06:23:11PM +0200, Johannes Hofmann wrote: > Hi, > > to test how dillo behaves on huge pages, I downloaded the mysql > manual as a single html page: > http://downloads.mysql.com/docs/refman-5.1-en.html.tar.gz > > With this page I noticed that the drawRegion in FltkViewBase can > grow pretty large which slows down loading the page. Attached patch > limits the size of the drawRegion to 16 rectangles. > > With this patch (and HUGE_FILESIZE in cache.c increased to 16M) > dillo works pretty well on this huge page. Better than dillo1 and > firefox! Great! Committed. BTW, this is one of the important points whe should list in the dillo2 features page. Please somebody remember this! > One problem is that clicking on anchor links (to anchors within the > page) reloads the page which take some time. Some time ago, we had anchors hooked with direct scroll jumps. It was instantaneous, but the navigation stack wasn't modified and thus BACK didn't go to the original place. It can be hooked to jump again, but in that case, the navigation stack needs to be modified accordingly. This creates two paths for the same logic operation inside dillo (which increases the mantainability costs). That said, if there's a simple way to do it, I agree. > Also memory usage gets pretty high (250M with images disabled). > I'm experimenting with reducing the size of struct Word in > textblock.hh by moving the highlight stuff out of struct Word and > into Textblock. This brings memory usage down to 199M. > However, I don't know the highlighting stuff enough to be sure I > don't break anything. This probabely falls into the > "premature optimization" category anyway. Not at all. I'd say the important part is to know whether that optimization can be done without breaking the underlying model for everything else (a question Sebastian is the most knowledgeable person to answer in the case of dw2). -- Cheers Jorge.-

May 19, 2008

website FAQ update

by jcid＠dillo.org

On Fri, May 16, 2008 at 09:01:18PM +0000, corvid wrote: > Jorge wrote: > > Please try to contact J?rgen. If he doesn't answer, leave dillo-dev > > as the only contact until we find somebody else. > > His dillo address redirects to an address where I get User Unknown. > I found a telia.com address, but that also gave me User Unknown. The let's point to "dillo-dev" until somebody volunteers. ;) Although the problem of dillo-dev is that it needs subscription. -- Cheers Jorge.-

May 19, 2008

website FAQ update

by jcid＠dillo.org

On Fri, May 16, 2008 at 09:54:06PM +0000, corvid wrote: > Justus wrote: > > Jorge Arellano Cid wrote: > > > On Fri, May 16, 2008 at 08:21:25PM +0000, corvid wrote: > > >> Are "dillo1" and "dillo2" official names? If so, I'll add in some text to > > >> make it clear what's what. > > > > > > They're not official, but good mnemonics! > > > > > > When there was GTK1 dillo only, there was no confusion. > > > Currently the CVS is using dillo-fltk, but I'd much prefer > > > to have a binary named "dillo2". > > > > > > Probably this is a good choice. Let's hear what dillo-dev > > > people say. Here's the proposal: > > > > > > * call the new binary "dillo2", and refer to the old 0.8.x series > > > as dillo1. > > > > I think it's problematic to have a digit in the official name (or in the > > name of the binary) since people will think it's the version. I'd > > suggest something along these lines: > > > > * Dillo is the name of the brand > > * dillo2 is the codename for the fltk branch > > * for marketing reasons sell any snapshots / upcoming releases of that > > branch as the all new dillo version 2.x.y with tons of new features > > * the binary is called dillo (it's what people expect to type in to > > start the lightweight web browser thingie [at least I tried to run > > $PREFIX/bin/dillo a couple of times now...]) > > I also prefer to have a binary named dillo. OK. > [...] (and dillorc2 -> dillorc) We need a way to distinguish among the rc for dillo1 and dillo2. Currently you can have both dillo1 and dillo2 installed, sharing cookies and bookmarks (because we have a single ~/.dillo directory). Ideas are welcomed, including dillorc2 -> dillo2rc :-) -- Cheers Jorge.-

May 19, 2008

website FAQ update

by jcid＠dillo.org

On Fri, May 16, 2008 at 11:34:57PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jorge Arellano Cid wrote: > > On Fri, May 16, 2008 at 08:21:25PM +0000, corvid wrote: > >> Are "dillo1" and "dillo2" official names? If so, I'll add in some text to > >> make it clear what's what. > > > > They're not official, but good mnemonics! > > > > When there was GTK1 dillo only, there was no confusion. > > Currently the CVS is using dillo-fltk, but I'd much prefer > > to have a binary named "dillo2". > > > > Probably this is a good choice. Let's hear what dillo-dev > > people say. Here's the proposal: > > > > * call the new binary "dillo2", and refer to the old 0.8.x series > > as dillo1. > > I think it's problematic to have a digit in the official name (or in the > name of the binary) since people will think it's the version. I'd > suggest something along these lines: > > * Dillo is the name of the brand > * dillo2 is the codename for the fltk branch > * for marketing reasons sell any snapshots / upcoming releases of that > branch as the all new dillo version 2.x.y with tons of new features > * the binary is called dillo (it's what people expect to type in to > start the lightweight web browser thingie [at least I tried to run > $PREFIX/bin/dillo a couple of times now...]) Well, that's the canonical way of doing it (no pun intended). OK, let's do it that way then, and let's talk about "dillo2" in the FAQ. -- Cheers Jorge.-

May 19, 2008

patch: dw configure args: rtfl and doublebuffer

by jcid＠dillo.org

On Sun, May 18, 2008 at 08:34:38PM +0000, corvid wrote: > I saw in the bug tracker that --disable-rtfl still turns on rtfl msgs. > > Did some reading. > The third argument to AC_ARG_ENABLE is always run if the option was > specified, regardless of the value. If the option is not specified, > the fourth argument is run. > > --disable-FEATURE just becomes --enable-FEATURE=no. > > (I'll send a separate patch to Jorge to allow compilation with rtfl.) Committed. -- Cheers Jorge.-

May 19, 2008

[patch] dillo and huge pages

by Johannes.Hofmann＠gmx.de

Hi, to test how dillo behaves on huge pages, I downloaded the mysql manual as a single html page: http://downloads.mysql.com/docs/refman-5.1-en.html.tar.gz With this page I noticed that the drawRegion in FltkViewBase can grow pretty large which slows down loading the page. Attached patch limits the size of the drawRegion to 16 rectangles. With this patch (and HUGE_FILESIZE in cache.c increased to 16M) dillo works pretty well on this huge page. Better than dillo1 and firefox! One problem is that clicking on anchor links (to anchors within the page) reloads the page which take some time. Also memory usage gets pretty high (250M with images disabled). I'm experimenting with reducing the size of struct Word in textblock.hh by moving the highlight stuff out of struct Word and into Textblock. This brings memory usage down to 199M. However, I don't know the highlighting stuff enough to be sure I don't break anything. This probabely falls into the "premature optimization" category anyway. Cheers, Johannes

May 19, 2008

patch: dw configure args: rtfl and doublebuffer

by corvid＠lavabit.com

I saw in the bug tracker that --disable-rtfl still turns on rtfl msgs. Did some reading. The third argument to AC_ARG_ENABLE is always run if the option was specified, regardless of the value. If the option is not specified, the fourth argument is run. --disable-FEATURE just becomes --enable-FEATURE=no. (I'll send a separate patch to Jorge to allow compilation with rtfl.)

May 18, 2008