- Dillo-dev - lists.mailman3.com

[patch] minor memory reduction

by Johannes.Hofmann＠gmx.de

Hi, attached is a small patch to improve memory usage. It creates a single word for a sequence of spaces in PRE mode instead of one word per character. The second part is just a minor simplification. Cheers, Johannes

May 20, 2008

Horizontal scrolling

by jcid＠dillo.org

On Sat, May 17, 2008 at 11:17:01PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Huhu there :) > > attached is a tiny patch that enables the horizontal scrolling of the > content of the main dillo widget. Unfortunately fltk supports this up to > now (r6129) only on OSX. I do have a patch for fltk that enables this on > x11, let's see if I can slip it in ;) Committed. BTW, please send patched with "diff -pru". -- Cheers Jorge.-

May 19, 2008

Keyboard shortcuts & fullscreen button

by jcid＠dillo.org

On Sat, May 17, 2008 at 06:09:19PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The UI constructor creates a button for the fullscreen mode, but it is > not added to anything: > > // Make the full screen button (to be attached to the viewport later) > // TODO: attach to the viewport > FullScreen = new HighlightButton(0,0,15,15); > [...] > > Any idea why this was postponed? Should it be enabled now? The idea is that there's a gadget in the viewport (i.e. a small button in the lower right corner that shows even when in fullwindow mode). This was to be used to enable/disable full window mode. Now, thinking twice, maybe is not a bad idea to hook a right-click fullscreen to this button. Leaving left-click for fullwindow mode. ...but for that, the gadget code needs to be enabled. > Also I noticed, that the way events are handled is somewhat lax with > respect to modifier keys. The code just checks if ctrl is pressed, not > if ctrl but none of the other modifiers are pressed. This makes ctrl-l > equivalent with ctrl-shift-alt-l. I'd like to hear your opinions, is > this a bug or a feature? Bug I think. The UI was coded in a hurry to get it running. Lax parts need polish. -- Cheers Jorge.-

May 19, 2008

Uncluttering dillos UI - getting rid of the dialog boxes

by jcid＠dillo.org

On Sat, May 17, 2008 at 05:46:26PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I thought about dillos fullscreen mode, which is not a fullscreen mode > at all but a "get rid of those panels"-mode. So I decided to rename > those functions and variables accordingly (00-*) Committed. With the addition that when the Location is already focused, the text is also selected. This helps as a visual clue and also to quickly get rid of the old URL. Note: I used a trick in ::handle() to do it. If you know a better way, please send a patch. BTW, it'd be great if we can get rid of the findtext window, and place it as an horizontal widget near the bottom (i.e as FF). > to make it possible to implement a real fullscreen mode (01-*). Not committed yet. More on this in my next post... -- Cheers Jorge.-

May 19, 2008

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