- Dillo-dev - lists.mailman3.com

[patch] fix FltkPlatform destructor

by Johannes.Hofmann＠gmx.de

Hi, this fixes a small memory leak in FltkPlatform. Johannes

June 19, 2008

9P

by Johannes.Hofmann＠gmx.de

Hi, On Thu, Jun 19, 2008 at 09:58:43AM -0400, Jorge Arellano Cid wrote: > Hi Enrico, > Hi Everybody, > > It took some time to get back to you, but the topics raised are > non trivial. Let's start with the simpler one: > > > > [Keyboard shortcuts] > > > I believe one of the important things that we could support is > > > custom keyboard shortcuts in dillorc. > > > > ACK. Maybe would should go the way Mutt does: it internally > > works with commands, and keystrokes are mapped to commands. > > Perfect for me. > > If you can patch dillo to do that, it'd be great. > > > > [C++] > > > i. - Increase the development team by adding 6+ new developers. > > > ii.- Getting more involved with other projects. > > > > you can add me, as long as no C++ stuff is involved. > > (don't like it's overhead). > > I also don't like C++ and its complexity! > > FLTK2 is in C++ so we had to interface with it. The idea was to > keep C++ to a minimum set of features. > > OTOH, windowing systems and widgets are quite well suited for > the object oriented approach, and in some places it gets simpler > than dealing directly with inheritance in C (as with GTK1). It's true that C++ projects tend to get over designed complex and bloated - more than C projects. And I really like Linus's famous mail on that topic: http://article.gmane.org/gmane.comp.version-control.git/57918 However fltk and even more dillo-fltk are a perfect example that this is not necessarily the case. If used properly C++ can also help to make the code more maintable. The dillo-fltk code is definately worth a look. There's a lot to be learned from it. Cheers, Johannes

June 19, 2008

[patch] move highlighting data into Textblock

by Johannes.Hofmann＠gmx.de

Hi, as promised here comes a patch to move highlighting information from struct Word into Textblock to save memory. I had to change the semantics of the highlighting API slightly (see comments) to ensure that the highlighted part is always contiguous. Here are some measurements (with load_images=NO): Page dillo-fltk patched_dillo-fltk dillo1 firefox ============================================================== splash 7240K 7236K xslt [1] 15016K 14220K freebsd [2] 70264K 58084K mysql [3] 186M 148M 232M 200M Obviously the difference is mostly visible on large pages. And firefox is pretty close regarding memory usage. However it needed more than 3 minutes to load the local mysql page compared to 6 seconds for dillo-fltk! Please look out for possible highlight related regressions. Cheers, Johannes [1] http://www.w3.org/TR/xslt [2] http://www.freebsd.org/doc/en/books/handbook/book.html [3] http://downloads.mysql.com/docs/refman-6.0-en.html.tar.gz

June 19, 2008

9P

by jcid＠dillo.org

Hi Enrico, Hi Everybody, It took some time to get back to you, but the topics raised are non trivial. Let's start with the simpler one: > [Keyboard shortcuts] > > I believe one of the important things that we could support is > > custom keyboard shortcuts in dillorc. > > ACK. Maybe would should go the way Mutt does: it internally > works with commands, and keystrokes are mapped to commands. Perfect for me. If you can patch dillo to do that, it'd be great. > [C++] > > i. - Increase the development team by adding 6+ new developers. > > ii.- Getting more involved with other projects. > > you can add me, as long as no C++ stuff is involved. > (don't like it's overhead). I also don't like C++ and its complexity! FLTK2 is in C++ so we had to interface with it. The idea was to keep C++ to a minimum set of features. OTOH, windowing systems and widgets are quite well suited for the object oriented approach, and in some places it gets simpler than dealing directly with inheritance in C (as with GTK1). > [Translations] > I'm already working on German translation. Are you working on a generic approach to translations or just German? > [CSS] > > * Planning for CSS, floating objects and TABS. > > (this are important features to a nice browsing experience) > > Missing CSS is really bad. > I'm planning to write an universal but small CSS parser > (as an separate library). You may give a look to RCSS by Raph Levien. > [Dillo as a help system] > I'd like to use Dillo for an help system and control center on an > end-user desktop appliance. Therefore I need it to execute certain > commands. But Dillo itself should not fork/exec itself, instead > send the commands to some special daemon via an 9P channel. I'd like to have Dillo as a help system in Debian! > An simple approach could be coding an dpi which just parses the > requested URL and sends the actual command to the exec server > through 9P. But I have to make absolutely sure that commands > can only be sent when coming from certain pages. > > How can I achieve this ? A simple way is to isolate those "certain pages" into a fixed URL scheme (e.g. localhost:8081/admin file:/etc/read_only_directory/) and to check that signature from the dpi. For this to work, you have to send the "requesting URL" to the dpi by using dpip. > [9P] > You might like have a look at Plan9 and how things are done there. > We can learn really much from it :) I gave a read to some docs. and it looks quite interesting. > [...] > I'd prefer a more generic approach: making everything available > via 9P and let separate programs work on that filesystem. > This also allows lot's other funny things, eg. an HTML external > editor which directly operates on an document within an dillo > viewer ;-) The 9P way of interaction is powerful. I like the idea of interfacing to a Javascript VM with 9P, and reusing a proved protocol instead of having to extend/debug dpip. Now, being a 9P newbie, how much (in LOC or KB) does it add to become a 9P server or client? This is my main concern. I'd like to see a sketch of a Dillo help system design using 9P. Currently dpid would provide a Unix socket to command Dillo, and 9P does something quite similar but more generic. The idea of being able to remote-control Dillo from a simple application/script with a 9P interface is more than interesting. For instance: Load URL, Reload, Stop, Open New window, Back, Forward, images on/off, etc. AFAIS, we'd need to make dillo work internally with commands, and then exposing that interface for the external world. If the dillo help system design looks interesting we can start from there. Obviously you have given it some thought in your project so please share your ideas with us. Obviously using 9P to remote-control dillo seems like an overkill, but when it comes to Javascript, or interfacing to external apps. as an HTML viewer, or serving as a GUI, it looks reasonable. Comments are welcomed. -- Cheers Jorge.-

June 19, 2008

recent style/layout segfaults

by jcid＠dillo.org

On Tue, Jun 10, 2008 at 07:21:35PM +0200, Johannes Hofmann wrote: > On Sat, Jun 07, 2008 at 10:16:14PM +0000, corvid wrote: > > Johannes wrote: > > > Comments welcome! I feel a bit uncomfortable proposing a > > > pretty drastic change like this. > > > > Although obviously I don't know the code well, it seems like an improvement. > > After thinking some more about it, I believe this is the right way to > go. My initial patch had some issues though: It was complete > nonsense of course to make the destructor of the derived class > (FltkFont and FltkColor) virtual. It only worked because Font and > Color are derived from lout::Object which already has a virtual > destructor. So in fact the change does not add any additional > virtual methods. > I also decided to keep the interface to dillo2 as it is (the now > unused layout parameter in Style::create()). > > So attached is my official proposal to fix the style related > segfaults that where introduced by my style caching patch. Committed! -- Cheers Jorge.-

June 18, 2008

patch: view gzipped local files

by jcid＠dillo.org

On Sat, Jun 14, 2008 at 04:13:18PM +0000, corvid wrote: > I'd been considering this for a while, but couldn't > decide whether it had any real value. > > Then it occurred to me that if people are often using > dillo as a local document viewer for minimalist systems, > they may value the ability to compress those documents. > Committed. -- Cheers Jorge.-

June 18, 2008

form.cc: more refactoring

by jcid＠dillo.org

On Sat, Jun 14, 2008 at 04:14:32PM +0100, Jeremy Henty wrote: > > A set of small patches that clean up form.cc , mostly to do with > DilloHtmlSelect . > > * refactor by creating new functions: > - a_Html_parse_stash() > - DilloHtmlSelect::ensureSelection() > - DilloHtmlSelect::addOptionsTo() > - DilloHtmlSelect::appendValuesTo() > - DilloHtmlSelect::getCurrentOption() (cf. other getCurrent* methods) > * make DilloHtmlSelect::options private > * rename DilloHtmlInput::getInputValues() to appendValuesTo() (the new > name is more mnemonic and consistent with the DilloHtmlSelect method > above) Committed, except 00 and 05. 00: The stash buffer may hold a script, in that case parse_stash is not as clear as parse_entities. 05: gives compilation errors: [...] form.cc: In function 'void Html_option_finish(DilloHtml*)': form.cc:184: error: 'lout::misc::SimpleVector<DilloHtmlOption*>* DilloHtmlSelect::options' is private form.cc:1918: error: within this context form.cc:184: error: 'lout::misc::SimpleVector<DilloHtmlOption*>* DilloHtmlSelect::options' is private form.cc:1918: error: within this context -- Cheers Jorge.-

June 18, 2008

About the patch for Style-related crashes: +1 !

by onepoint＠starurchin.org

It's gone a little quiet here, I hope everyone's OK! Anyway I just want to register a yes vote for the patch that was proposed last week to fix crashes from inside Style::unref() when closing windows. These crashes were making Dillo almost unusable for me, but I applied the patch on Sunday and life has been blissful ever since. (I sound like one of those awful TV ads, don't I?) The plan was to wait a week for comments before deciding. I hope it gets committed soon because a fix for these crashes is IMHO vital. Regards, Jeremy Henty

June 18, 2008

patch: view gzipped local files

by corvid＠lavabit.com

I'd been considering this for a while, but couldn't decide whether it had any real value. Then it occurred to me that if people are often using dillo as a local document viewer for minimalist systems, they may value the ability to compress those documents.

June 14, 2008

form.cc: more refactoring

by onepoint＠starurchin.org

A set of small patches that clean up form.cc , mostly to do with DilloHtmlSelect . * refactor by creating new functions: - a_Html_parse_stash() - DilloHtmlSelect::ensureSelection() - DilloHtmlSelect::addOptionsTo() - DilloHtmlSelect::appendValuesTo() - DilloHtmlSelect::getCurrentOption() (cf. other getCurrent* methods) * make DilloHtmlSelect::options private * rename DilloHtmlInput::getInputValues() to appendValuesTo() (the new name is more mnemonic and consistent with the DilloHtmlSelect method above) Regards, Jeremy Henty

June 14, 2008