- Dillo-dev - lists.mailman3.com

web site partial update
by jcid＠dillo.org Aug. 28, 2008

Aug. 28, 2008

Hi, With a view to prepare our next dillo2 release, the web site has been partially updated. From the links column, these sections: Developers, Users, Related and "Hosted at" are up to date. Even the downloadable alternative icons work, and pages were bug-meter validated too. BTW, what version number should we give to dillo2? 2.0 seems like a good candidate. -- Cheers Jorge.-

2 1

patch: make prefs.c and dillorc2 consistent
by corvid＠lavabit.com Aug. 26, 2008

Aug. 26, 2008

The proposal here is to have everything commented out in the rc by default, and show what the default settings are so that people don't have to spend as much time experimenting when they want to configure their nifty superbrowser. When resolving inconsistencies, I generally picked the rc setting when uncommented, and the prefs one otherwise. Figured it would be a fair approximation of what Jorge might accept... Also, I remember Jorge once saying that maybe it should be named dillo2rc instead of dillorc2. I think so too.

2 4

Re: patch: disallow textarea/button inside select
by jcid＠dillo.org Aug. 25, 2008

Aug. 25, 2008

On Sun, Aug 24, 2008 at 01:25:02AM +0000, corvid wrote: > Putting aside the Stash one for something easy > (with Stash, the html file is like 90K, and it > seems like touching any of it makes the crashing > stop, so...), I find that textarea or button inside > select is bad because close_select assumes that > current input is a select. > > An alternative would be to make close_select > check the current input, but then other > controls aren't supposed to be inside it anyway... > > I feel like we already had this bug and fixed it, > but I must be thinking of whatever specifically made > us add the IN_SELECT test to open_input. We may find a canonical way to implement this constraints in the future (e.g. only OPTION|OPTGROUP in SELECT), maybe inside Html_process_tag()... Committed... -- Cheers Jorge.-

1 0

a list of what dillo2 runs on
by jcid＠dillo.org Aug. 25, 2008

Aug. 25, 2008

On Tue, Aug 19, 2008 at 08:22:54PM +0000, corvid wrote: > > The key is to be informative and that page construction > > and updating is a breeze to do. > > > > > Is it officially obsolete, or should parts of Current Plans > > > migrate over there eventually? > > > > I agree that "current plans" fits the goal better. If you can > > think of a _simple_ way to make it better, go ahead. > > > > This is, in principle I agree that removing the achieved goals > > link, and favouring "Current Plans" improves the site. Now, if we > > find a simple way to keep "Current Plans" up to date and not > > bloated, better. > > I haven't been able to think of anything good... in order to > at least have something, though, how about if I add a link like > "Goals reached since last update" to the bottom of achieved goals, > pointing to current plans? > (where they get migrated over hopefully whenever a release is made, > or at least when they are so old that they can no longer be ignored...) ... or we may switch to this scheme: [Current Plans] // as it is [Changelog Highlights] // for last release [Changelog] // full changelog This looks simple to maintain and understand. (removing achieved goals). -- Cheers Jorge.-

1 0

Problem compiling on FreeBSD
by christopher.illies＠ki.se Aug. 25, 2008

Aug. 25, 2008

Hi, on FreeBSD-7.0-STABLE, fltk-2.0.r6149 from ports I get the following error while compiling the newest dillo from CVS: > cd dw2-cur; ./autogen.sh && ./configure && make aclocal found autoheader found autoconf found automake found [Checks passed] Generating... /usr/local/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE /usr/local/share/aclocal/audiofile.m4:12: run info '(automake)Extending aclocal' /usr/local/share/aclocal/audiofile.m4:12: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal autoheader-2.62: error: AC_CONFIG_HEADERS not found in configure.in checking build system type... i386-unknown-freebsd7.0 [...] g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"dw-testbed\" -DVERSION=\"0.0.43j\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_UIO_H=1 -I. -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include -O2 -fno-strict-aliasing -pipe -I/usr/local/include -Wno-non-virtual-dtor -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wall -MT libDw_fltk_a-fltkflatview.o -MD -MP -MF .deps/libDw_fltk_a-fltkflatview.Tpo -c -o libDw_fltk_a-fltkflatview.o `test -f 'fltkflatview.cc' || echo './'`fltkflatview.cc In file included from fltkflatview.hh:9, from fltkflatview.cc:23: fltkviewbase.hh:25: error: 'time_t' does not name a type fltkviewbase.hh:26: error: 'time_t' does not name a type *** Error code 1 Stop in /home/chris/Storage/Programming/dillo/dw2-cur/dw. *** Error code 1 Stop in /home/chris/Storage/Programming/dillo/dw2-cur. Christopher

2 3

Linksys NSLU2 ARM XScale success report [FWD: Dillo f15 Compatibility List dillo2]
by corvid＠lavabit.com Aug. 25, 2008

Aug. 25, 2008

Holger Paradies wrote: > Hello > succesfully compiled and running dillo2 > cvs20080825 > -build_triplet = armv5tel-unknown-linux-gnu > on linksys-nslu2 266MHZ 32MB RAM > (native build) > debian-lenny_arm gcc version 4.3.1 (Debian 4.3.1-2) > kernel 2.6.25-2-ixp4xx > > and running via ssh -X > > > also success on Debian-Etch x86 > > Greetings Holger

1 0

Re: Broken links on www-site
by jcid＠dillo.org Aug. 19, 2008

Aug. 19, 2008

On Tue, Aug 19, 2008 at 07:58:06PM +0300, Henri Salo wrote: > On Tue, Aug 19, 2008 at 12:21:56PM -0400, Jorge Arellano Cid wrote: > > Good, if you want to help us, welcome aboard! > > > > Please give a read to the just updated: > > > > http://www.dillo.org/8years.html > > > > and update the wiki. In case of doubt, just ask. > > > > BTW, corvid is about to patch that page along these lines: > > > > Jorge.- > > I have been lurking around in mailing lists for a while if you haven't > already noticed so I have read that link already. It was written this morning! > I have also tested > some patches, but I didn't have anything to say about those. I don't > actually like Wiki{pedia,media} anymore, but I can do exception for > Dillo-project. :-) > For you information there are users who would like test dillo2 using > snapshots from CVS. Should we make proper builds and guides for them? No. I'd prefer them to test the next release. Once it's made, packages are welcomed. -- Cheers Jorge.-

1 0

a list of what dillo2 runs on
by jcid＠dillo.org Aug. 19, 2008

Aug. 19, 2008

On Tue, Aug 19, 2008 at 01:36:34AM +0000, corvid wrote: > All right, I came up with: > > * Dillo is a > <a href='http://www.dillo.org/Compatibility.html'>multi-platform</a> > graphical web browser known for its speed and small size. > * Dillo is written in C and C++. > * Dillo is based on <a href='http://www.fltk.org'>FLTK2</a>, the Fast Light > ToolKit. > * Dillo is free software made available under the terms of the GNU General > Public License. > * Dillo strives to be friendly both to users and developers. > * Dillo helps web authors to comply with web standards by using the > <a href='http://www.dillo.org/help/bug_meter.html'>bug meter</a>. OK. (please state GPL3). BTW, I just wrote and updated the "8 years" page: http://www.dillo.org/8years.html -- Cheers Jorge.-

2 2

towards a consistent UI
by Johannes.Hofmann＠gmx.de Aug. 18, 2008

Aug. 18, 2008

Hi, I really like the way Ctrl-l now just selects the current URL in normal mode avoiding a dialog window. In fullscreen mode however, the short switch to normal mode to enter the new URL requires a complete redraw of the page contents. Also the contents "jumps" down for the time the location bar is shown. This can be distracting. Do we really want to kill all uses of dialog windows? We still have "Search the Web" anyway. Also the location of the "IMG ON/OFF" button seems a bit arbitrary. How could a consistent user interface of dillo look like? Here is my proposal - just to start the discussion: * Everything is accessible via the menubar and via keyboard shortcuts. The shortcuts are shown behind the menu entries. * All shortcuts are configurable. * No more img on/off button. One can use a menubar entry or keyboard shortcut instead. * The "Search the Web" button should be just as all the other buttons ("Back", "Forw" ...) and be configurable of course. Perhaps a single config option like: panel_buttons="back, forw, home, reload, save, stop, book" * The "HTML bugs" button in the status bar is ok. It shows the bug-state of the current page. * "Search the Web" opens the start page of the selected search engine (e.g. google.com) and selects the search text field. I'm not sure about that, but it avoids the dialog window and it makes clear to which search engine the query is sent. The additional page load for the empty search page is only required once - then it's cached. * In fullscreen mode "Ctrl-l" opens a dialog window again. Any better solution? Cheers, Johannes

2 2

Dillo in OSX
by higuita7＠yahoo.co.uk Aug. 15, 2008

Aug. 15, 2008

Hi again Found the problem... had some old fltk includes in /usr/local and was installing the cvs to /usr ... so dillo was mixing both includes and breaking the compile. its fixed now, thanks for the help, specially Johannes :) higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

4 4

Please help me on this...
by jcid＠dillo.org Aug. 14, 2008

Aug. 14, 2008

Hi there, Looking to a future dillo2 release for the public, I was wondering about the main drive behind dillo2. I mean, in this years of Facebook, WebKit, Flash, propietary video codecs, etc. what's the main point behind dillo2? From the objectives: 1.- The democratization of internet information access. 2.- Personal security and privacy. 3.- High software efficiency. The first one is interesting to analyze along the lines that dillo allows to search for tons of information spread through the Internet using low HW requirements and low bandwidth as a dialup. This is reassuring as dillo efectively enables information access to any person under such constraints. The second one is partly attained by not writing to HD and by a non-existent scripting support. The third one is the one to brag about. ;-) Since some time, the thought that enabling dillo2 as a help browser could also bring local information (i.e. in HD) closer to the user came as a powerful one. Having an app. that pops-up in a second and that's quick, responsive and easy to use is certainly a strong drive for a person in search of information (that's why I'd like to see it inside Debian as a help system). In the near future, I'd like to have CSS and proper floating text rendering (DIV element), plus an API as a help browser. There're countries where paying Universitary studies is the state's burden. If a citizen doesn't want to study there, it's a choice. I think the same may happen with dillo, once people know about it, they can choose to use it or not. While thinking about it, these comments surprised me: "Slashdot | What Do You Want On Future Browsers?" http://tech.slashdot.org/article.pl?sid=08/06/30/1845201 (yes, give them a read!) (They're talking from a full featured Firefox basis. I don't know how may of them would like to use something like dillo) Behind a project like ours, there're two communities: developers and users. The main factor to push forward the project is developers and their motivations (in a commercial environment what pushes the development is the money invested and the profit margins/strategy sought). That's why I'm asking you to help me with your views, needs visions on the future of dillo2 these days. With regard to the user community, I'd love to have some feedback from them, but I guess we need to release dillo2 first! :-) -- Cheers Jorge.-

4 4

Dillo in OSX
by Johannes.Hofmann＠gmx.de Aug. 11, 2008

Aug. 11, 2008

-------- Original-Nachricht -------- > Datum: Mon, 11 Aug 2008 03:32:15 +0100 > Von: higuita <higuita(a)GMX.net> > An: "Johannes Hofmann" <Johannes.Hofmann(a)gmx.de> > Betreff: Re: [Dillo-dev] Dillo in OSX > Hi > > On Sun, 10 Aug 2008 11:36:08 +0200, "Johannes Hofmann" > <Johannes.Hofmann(a)gmx.de> wrote: > > Hm, maybe some stale fltk2 header files? > > i clean up the root dw2 folder and done a new cvs up && autogen.sh && > configure ... but still it failled > > > You could try to add -E to the failing g++ call above to check the > > preprocessed sources. > > in a command line, i added the -E and it build successful > (no error)... > if i force success on that g++ command, i can continue and > build dillo successful and dillo seems to work fine > > bad fltk install? broken compiler? > should i totally remove the dillo2 and do a totally new checkout? > > :) > > thanks in advance for the help I suspect it is somehow related to your fltk2 installation. Perhaps you have one from your distribution and a self compiled version at the same time? Johannes -- GMX Kostenlose Spiele: Einfach online spielen und Spa? haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/61691…

1 0

Dillo in OSX
by higuita7＠yahoo.co.uk Aug. 10, 2008

Aug. 10, 2008

Hi On Mon, 4 Aug 2008 18:50:17 -0400, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Great, committed. > I works, dillo2 runs native in Leopard > There are several glitches but it's quite a good start. 8-) humm... if g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"dw-testbed\" -DVERSION=\"0.0.43j\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_UIO_H=1 -I. -I. -I/usr/local/include -I/usr/include/freetype2 -Wno-non-virtual-dtor -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wall -MT libDw_fltk_a-fltkmisc.o -MD -MP -MF ".deps/libDw_fltk_a-fltkmisc.Tpo" -c -o libDw_fltk_a-fltkmisc.o `test -f 'fltkmisc.cc' || echo './'`fltkmisc.cc; \ then mv -f ".deps/libDw_fltk_a-fltkmisc.Tpo" ".deps/libDw_fltk_a-fltkmisc.Po"; else rm -f ".deps/libDw_fltk_a-fltkmisc.Tpo"; exit 1; fi fltkmisc.cc: In function 'void dw::fltk::misc::warpPointer(int, int)': fltkmisc.cc:45: error: 'warp_mouse' is not a member of 'fltk' make[1]: *** [libDw_fltk_a-fltkmisc.o] Error 1 make[1]: Leaving directory `/home/higuita/build/dillo2/dw2/dw' make: *** [all-recursive] Error 1 i'm using the latest svn from fltk and from dillo... i'm using slamd64 (slackware 64bits) thanks higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

1 0

Re: patch: form controls outside of forms
by jcid＠dillo.org Aug. 6, 2008

Aug. 6, 2008

On Sun, Jul 20, 2008 at 07:38:56PM +0000, corvid wrote: > *remind* *remind* In absence of comment, I decided to commit it. -- Cheers Jorge.-

1 0

Dillo in OSX
by jcid＠dillo.org Aug. 5, 2008

Aug. 5, 2008

Hi Johannes, When trying to compile dillo2 in OSX, FLTK2 compiles OK, dw's fltkviewbase.hh needs an time.h include and I get this error: isc.Tpo -c -o libDw_fltk_a-fltkmisc.o `test -f 'fltkmisc.cc' || echo './'`fltkmisc.cc fltkmisc.cc: In function 'int dw::fltk::misc::screenWidth()': fltkmisc.cc:34: error: 'xdisplay' is not a member of 'fltk' fltkmisc.cc:34: error: 'xscreen' is not a member of 'fltk' fltkmisc.cc:34: error: 'DisplayWidth' was not declared in this scope fltkmisc.cc: In function 'int dw::fltk::misc::screenHeight()': fltkmisc.cc:39: error: 'xdisplay' is not a member of 'fltk' fltkmisc.cc:39: error: 'xscreen' is not a member of 'fltk' fltkmisc.cc:39: error: 'DisplayHeight' was not declared in this scope fltkmisc.cc: In function 'void dw::fltk::misc::warpPointer(int, int)': fltkmisc.cc:44: error: 'xdisplay' is not a member of 'fltk' fltkmisc.cc:44: error: 'None' was not declared in this scope fltkmisc.cc:45: error: 'xdisplay' is not a member of 'fltk' fltkmisc.cc:45: error: 'xscreen' is not a member of 'fltk' fltkmisc.cc:45: error: 'RootWindow' was not declared in this scope fltkmisc.cc:46: error: 'XWarpPointer' was not declared in this scope make[1]: *** [libDw_fltk_a-fltkmisc.o] Error 1 make: *** [all-recursive] Error 1 Do you know the proper solution for this? -- Cheers Jorge.-

2 2

[patch] Another selection redraw fix
by Johannes.Hofmann＠gmx.de July 30, 2008

July 30, 2008

Hi, attached is another selection redraw related fix. Again, when selecting text a too large area was redrawn. Cheers, Johannes PS: This is a resend. The original mail probabely got lost.

2 1

[corvid@lavabit.com: Re: patch: form controls outside of forms]
by jcid＠dillo.org July 30, 2008

July 30, 2008

Hi, After the WearLab outage (web site, email, ssh, cvs, mailing list, smoke signals...), let's try to resume from where we were. Jeremy: please review the "form controls outside of forms" patch (to commit afterwards). Michal wrote: > Some nice fable, had to do something regarding this :). Which one?! *please* 8-) Evrerybody: Does anybody know what happened with the WearLab? -- Cheers Jorge.-

2 1

[patch] reduce redraw overhead when selecting text
by Johannes.Hofmann＠gmx.de July 30, 2008

July 30, 2008

Hi, here is a small bugfix that reduces the area that gets redrawn when selecting text. The improvement is mostly noticable when running dillo in a remote X11 session. Cheers, Johannes

2 1

CVS problems
by onepoint＠starurchin.org July 30, 2008

July 30, 2008

I have not been able to "cvs update" for a few days now. I get "cvs [update aborted]: connect to auriga.wearlab.de(134.102.206.165):2401 failed: Connection timed out". Does anyone else see this? What's the problem? Regards, Jeremy Henty

2 2

[patch] selecting multibyte glyphs
by Johannes.Hofmann＠gmx.de July 17, 2008

July 17, 2008

Hi, here is a patch to fix selection of multibyte glyphs as discussed earlier. Cheers, Johannes

3 2

selecting multi-byte characters
by Johannes.Hofmann＠gmx.de July 13, 2008

July 13, 2008

Hi, as you may have noticed, there is a problem with selecting multi-byte characters. If you enlarge the selection so that e.g. '?' is at the edge of the selected text, the character changes in weird ways. This is due to the Textblock::sendSelectionEvent() code that simply uses charPos++, and charPos-- whereas it should do something like utf8fwd() or utf8back() from fltk. The problem here is that we can't simply use fltk functions in textblock.cc as it is independent of the GUI toolkit. Any ideas how to solve this? I thought about adding wrappers to fltkmisc.cc but that's also a bit ugly... Cheers, Johannes

2 2

Navigation popups
by jcid＠dillo.org July 12, 2008

July 12, 2008

Hi, Finally I found a simple way to make the navigation history popups discern the clicking mouse button. Now you can open a new window by middle clicking on history popups. A feature I missed a lot since dillo1. -- Cheers Jorge.-

1 0

patch: (any Solarians in the audience?) rm nanosleep solaris workaround
by corvid＠lavabit.com July 5, 2008

July 5, 2008

It seems that there was a nanosleep() in src/IO/dpi.c long ago, but I can't find any nanosleep()s anywhere anymore, so...

4 5

Attention subscribers
by jcid＠dillo.org July 5, 2008

July 5, 2008

Hi subscribers, For those that subscribed long ago but couldn't get your messages across, your accounts have been cleared for posting. Sorry for the inconvinience, the dillo project is slowly getting into full pace again... -- Cheers Jorge.-

2 1

iterator related bugs
by Johannes.Hofmann＠gmx.de July 4, 2008

July 4, 2008

Hi, while looking for the reason of the rare selection related crashes I found something that seems like a severe bunch of bugs in the iterator code. It might be related to the crash, but I'm not 100% sure yet. There is this innocent comment in front of the DeepIterator constructor in iterator.cc: If you want to continue using \em it, pass it->cloneIterator(). This means, that the DeepIterator constructor eats up the Iterator it get's passed a pointer to! The evil thing is that every method that passes one of it's arguments to the DeepIterator constructor inherits this property, e.g: DeepIterator::createVariant() and as a consequence also: SelectionState::switchLinkToSelection() and SelectionState::adjustSelection() In Iterator::scrollTo() Iterators that are used after being passed to the DeepIterator constructor. In SelectionState::buttonRelease() an iterator that has been passed to switchLinkToSelection() might be used afterwards as argument to adjustSelection(). I would propose to change the behaviour of the DeepIterator constructor and always clone its input Iterator. Better be safe than sorry and the fact that there is already several bugs related to this shows, that the current behaviour - even if it's documented - is really dangerous. What do you think? Cheers, Johannes

2 5

[patch] cleanup ZoneAllocator
by Johannes.Hofmann＠gmx.de July 4, 2008

July 4, 2008

Hi, here comes me ZoneAllocator cleanup again. This time without the questionable strlen() stuff. Cheers, Johannes

3 3

9P
by jcid＠dillo.org July 4, 2008

July 4, 2008

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.-

3 2

[patch] use delete[] where necessary
by Johannes.Hofmann＠gmx.de July 3, 2008

July 3, 2008

Hi, attached patch uses delete[] for deleting arrays as required by C++. Cheers, Johannes

2 3

Re: patch: rm unused dw configure.in options]
by corvid＠lavabit.com July 3, 2008

July 3, 2008

Jorge accidentally applied my dw2 configure.in change (sent off-list) to dillo2 instead, so let's put the libjpeg stuff back in case anyone needs it:

2 1

[patch] fix findtext for single char searches
by Johannes.Hofmann＠gmx.de July 2, 2008

July 2, 2008

Hi, attached patch fixes a segfault when searching for single characters. Cheers, Johannes

1 0

what's next
by Johannes.Hofmann＠gmx.de June 30, 2008

June 30, 2008

Hi, for me dillo-fltk is pretty stable, fast, and generally a joy to use. I still see the following issues: * In rare cases the screen contents is not properly redrawn due to the redraw optimization. I'm looking for a way to reproduce it. Anyone else seeing this? * The cursor is not always updated properly when over a link. This happens while page is rendered and also when drag-scrolling with the middle mouse button. * The bus error I had posted about is still there and I have seen it once as a segafault with similar stack trace on a Linux box. I still don't have a way to reproduce it though. Any other problems or missing features? Jorge, what do you think about officially releasing what we have in the near future? Or do you prefer to wait for the big stuff (like CSS)? Cheers, Johannes

2 1

Should --enable-ansi be removed?
by corvid＠lavabit.com June 30, 2008

June 30, 2008

I tried enabling it out of curiosity, and I see that the code doesn't come close to compiling with it. Since it complains a lot about the various MSG(...) macros (warning: anonymous variadic macros were introduced in C99), I'm guessing that the answer will be yes.

3 3

[patch] use prefs.vw_fontname
by Johannes.Hofmann＠gmx.de June 27, 2008

June 27, 2008

Hi, attached patch uses prefs.vw_fontname instead of hardcoded "Bitstream Charter" in web.cc. Thereby it avoids opening "Bitstream Charter" if it is not selected in dillorc. This saves about 500k in initial startup size with --disable-xft It hardly saves anything in the xft case. I don't know why. I would have expected it the other way round.... Cheers, Johannes

2 2

Memory usage
by jcid＠dillo.org June 26, 2008

June 26, 2008

Hi there, I've been reviewing memory usage these days, and found some weird numbers that I'd like to understand. Taking the huge mysql page (13MB), I made the following memory measures (with ps). Load a bare dillo, load the simple directory where the huge page is located, then the huge page, then back, then forward, back, forward and back. I did this for dillo2.19Jun, dillo2.21Jun, dillo-fltk (with zone allocators) and dillo1. All in GNU/Linux with image_off. Here are the numbers: ----------- Memory test ----------- %MEM VSZ RSS TTY STAT START TIME COMMAND 0.1 9672 4144 pts/10 S+ 09:37 0:00 ./dillo-fltk.19Jun bare 0.2 10376 4756 pts/10 S+ 09:37 0:00 ./dillo-fltk.19Jun dir list 6.9 176176 144776 pts/10 S+ 09:37 0:02 ./dillo-fltk.19Jun huge page 5.4 123556 113216 pts/10 S+ 09:37 0:02 ./dillo-fltk.19Jun back 7.0 176176 146240 pts/10 S+ 09:37 0:05 ./dillo-fltk.19Jun forward 5.6 127020 117720 pts/10 S+ 09:37 0:05 ./dillo-fltk.19Jun back 7.0 176172 146240 pts/10 S+ 09:37 0:07 ./dillo-fltk.19Jun forward 5.6 127016 117716 pts/10 S+ 09:37 0:08 ./dillo-fltk.19Jun back %MEM VSZ RSS TTY STAT START TIME COMMAND 0.1 9672 4140 pts/10 S+ 09:26 0:00 ./dillo-fltk.21Jun bare 0.2 10376 4760 pts/10 S+ 09:26 0:00 ./dillo-fltk.21Jun dir list 5.9 147904 123988 pts/10 S+ 09:31 0:02 ./dillo-fltk.21Jun huge page 4.9 111668 101944 pts/10 S+ 09:31 0:02 ./dillo-fltk.21Jun back 6.0 147780 124792 pts/10 S+ 09:31 0:05 ./dillo-fltk.21Jun forward 5.0 115008 105780 pts/10 S+ 09:31 0:05 ./dillo-fltk.21Jun back 6.0 147780 124856 pts/10 S+ 09:31 0:07 ./dillo-fltk.21Jun forward 5.1 115008 105844 pts/10 S+ 09:31 0:07 ./dillo-fltk.21Jun back %MEM VSZ RSS TTY STAT START TIME COMMAND 0.1 9676 4084 pts/10 S+ 11:16 0:00 ./dillo-fltk bare 0.2 10464 4768 pts/10 S+ 11:17 0:00 ./dillo-fltk dir list 5.4 136960 112920 pts/10 S+ 11:17 0:04 ./dillo-fltk huge page 4.3 100724 90864 pts/10 S+ 11:17 0:04 ./dillo-fltk back 5.4 136952 113756 pts/10 S+ 11:17 0:09 ./dillo-fltk forward 4.5 104180 94744 pts/10 S+ 11:17 0:09 ./dillo-fltk back 5.4 136888 113776 pts/10 S+ 11:17 0:13 ./dillo-fltk forward 4.5 104116 94764 pts/10 S+ 11:17 0:14 ./dillo-fltk back %MEM VSZ RSS TTY STAT START TIME COMMAND 0.1 8408 3524 pts/10 S+ 10:59 0:00 ./dillo1 bare 0.1 24788 3564 pts/10 S+ 11:01 0:00 ./dillo1 dir list 8.7 226996 182220 pts/10 S+ 11:01 0:07 ./dillo1 huge page 6.8 165880 141792 pts/10 S+ 11:01 0:09 ./dillo1 back 8.8 226952 184176 pts/10 S+ 11:01 0:17 ./dillo1 forward 6.9 166264 144024 pts/10 S+ 11:01 0:18 ./dillo1 back 8.8 226968 184216 pts/10 S+ 11:01 0:26 ./dillo1 forward 6.9 166264 144060 pts/10 S+ 11:01 0:27 ./dillo1 back Besides showing clearly a sane memory usage reduction pattern, there's a strange fact I don't understand. Once back from the huge page, I'd expect memory usage to drop to what it was before plus the 13MB of cached data, plus some KB of overhead, BUT the RSS keeps near 90MB. This happens with dillo1 too. My thoughts: * If this memory is not freed, it'd be great to find the huge leak. * If it's freed but not returned to the OS., dillo would consume as much memory as the biggest page it has loaded. Clearly not a desirable situation. * It may be that the O.S. knows it can claim back this memory when necessary but prefers to keep it assigned to the same process until it finds better use for it. ------------------------------------------- Huge page with different memory allocators: ------------------------------------------- %MEM VSZ RSS TTY STAT START TIME COMMAND 5.4 134912 113740 pts/17 S+ 18:56 0:02 ./dillo-fltk step: 2x 5.4 134916 113752 pts/17 S+ 18:57 0:02 ./dillo-fltk step: 2x 5.4 134828 113660 pts/17 S+ 18:58 0:02 ./dillo-fltk step: 2x 5.0 114940 105432 pts/17 S+ 18:53 0:02 ./dillo-fltk step: 1 5.0 111976 105488 pts/17 S+ 18:54 0:03 ./dillo-fltk step: 1 5.0 114872 105416 pts/17 S+ 18:54 0:02 ./dillo-fltk step: 1 5.1 117796 106436 pts/17 S+ 18:59 0:02 ./dillo-fltk step: cst 5.1 117568 106404 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst 5.1 117820 106460 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst This data comes from a memory usage reduction by tunning the simpleVector memory allocator. The first is the current one, which allocates in chunks of 2*numAlloc, the second allocates one by one and the third is a custom one I made. The 1-allocator is the best memory usage reducer but it's slower (roughly 20%). The cst-allocator reduces a bit less but is almost as fast as the 2x-allocator (2% slower or so). Memory reduction: VSZ RSS ----------------------------- 1-allocator 15% 7.3% cst-allocator 13% 6.5% ----------------------------- Well, compared with the 1000% "leak" above... :-) -- Cheers Jorge.-

2 5

[patch] Region is no Shape
by Johannes.Hofmann＠gmx.de June 23, 2008

June 23, 2008

Hi, attached patch cleans up Region. It no longer derives from Shape. Region has grown pretty specialize for handling redraws. Also it was never used as Shape object anyway. Cheers, Johannes

2 1

form.cc: more refactoring
by onepoint＠starurchin.org June 23, 2008

June 23, 2008

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

2 5

back to that SELECT segfault
by corvid＠lavabit.com June 23, 2008

June 23, 2008

In SELECT, if standard_widget_colors is set, color and backgroundColor are set to NULL. This tells FltkResource::setWidgetStyle() to leave the colors on the widget alone. If an inline element inside a SELECT calls style->color->getColor() or style->backgroundColor->getColor(), we get that crash. This currently means FONT and IMG. OBJECT and A would as well if that a_Color_vc code were uncommented. options: - four IN_SELECT tests. - letting Html_stack_cleanup_at_open() be called for inline elements in order to close the SELECT or something if IN_SELECT and the new tag isn't OPTION or OPTGROUP. - generating our own standard widget colors to put into color and backgroundColor. I don't like the first one because someone innocently adding a getColor somewhere in the future will never know about this danger. (a good example would be adding the a_Color_vc to open_frame())

3 5

Textblock::addText()
by jcid＠dillo.org June 22, 2008

June 22, 2008

Hi there, - Changed Textblock::addText() to internally allocate its text string, making the memory handling opaque to the caller. Does anybody remmeber the topic of addText() deleting a malloc'ed block of memory? I decided to make the change for API cleanliness/correctness and set the Textblock do the whole memory handling (i.e. now the Textblock is the one that allocates/deallocates the text string). The HTML parser was adjusted a bit to keep its old performance. -- Cheers Jorge.-

2 9

Splitting html.cc: what next?
by onepoint＠starurchin.org June 21, 2008

June 21, 2008

Off the top of my head, some suggestions for more files that could usefully be split out from html.cc: - table.cc , handles <table> , <tr> , <td> , <th> - list.cc , handles <ul> , <ol> , <li> , <dl> , <dt> , <dd> - text.cc , handles , , , , <strike> - paragraph.cc , handles , <blockquote> , <center> , <address> - page.cc , handles <html> , <head> , <title> , <meta> , <body> Thoughts? Regards, Jeremy Henty

3 7

occasional bus errors
by Johannes.Hofmann＠gmx.de June 20, 2008

June 20, 2008

Hi is anyone else seeing these rare bus errors? This is not new and happens every now and then. I'm trying to track it down, but it would be helpful to have a method to reliably reproduce it. Cheers, Johannes BTW: It's currently the only type of crash I noticed. Program terminated with signal 10, Bus error. #0 0x28595b1a in ?? () (gdb) bt #0 0x28595b1a in ?? () #1 0x0808ec51 in ~DeepIterator (this=0x28565720) at iterator.cc:515 #2 0x08091dc8 in dw::core::SelectionState::resetSelection (this=0x2850a47c) at selection.cc:85 #3 0x08091e20 in dw::core::SelectionState::reset (this=0x2850a47c) at selection.cc:75 #4 0x08091809 in dw::core::Layout::removeWidget (this=0x2850a400) at layout.cc:167 #5 0x080970ff in ~Widget (this=0x285aaf00) at widget.cc:269 #6 0x0807d554 in ~Textblock (this=0x285aaf00) at textblock.cc:117 #7 0x080916c7 in dw::core::Layout::setWidget (this=0x2850a400, widget=0x285b0300) at layout.cc:175 #8 0x08056ddc in a_Web_dispatch_by_type (Type=0x285a4560 "text/html; charset=us-ascii", Web=0x285659c0, Call=0x285958d0, Data=0x285958d4) at web.cc:94 #9 0x08058583 in Cache_process_queue (entry=0x28582400) at cache.c:1042 #10 0x08058d3c in a_Cache_process_dbuf (Op=0, buf=0x2873c000 "HTTP/1.1 200 OK\r\nDate: Fri, 20 Jun 2008 15:51:22 GMT\r\nServer: Apache/1.3.34 (Debian) PHP/4.4.4-8+etch6 mod_ssl/2.8.25 OpenSSL/0.9.8c\r\nCache-control: no-cache\r\nConnection: close\r\nTransfer-Encoding: chu"..., buf_size=1440, Url=0x285a1d00) at cache.c:871 #11 0x080564b8 in a_Chain_fcb (Op=134802368, Info=0x285a2e80, Data1=0x285c9ac0, Data2=0x80eb3e3) at chain.c:111 #12 0x080743dc in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x28595b40, Data1=0x285c9200, Data2=0x0) at dpi.c:223 #13 0x080564b8 in a_Chain_fcb (Op=134802368, Info=0x285a2e80, Data1=0x285c9200, Data2=0x0) at chain.c:111 #14 0x08074cfd in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x28595ba0, Data1=0x28595e00, Data2=0x0) at IO.c:418 #15 0x08074e8a in IO_callback (fd=<value optimized out>, io=0x28595e00) at IO.c:205 #16 0x08074f63 in IO_fd_read_cb (fd=4, data=0x20e) at IO.c:291 #17 0x080c28cd in fltk::wait () #18 0x080c2a7d in fltk::run () #19 0x0804e63d in main (argc=-1958539068, argv=0x58390446) at dillo.cc:125

4 4

[patch] move highlighting data into Textblock
by Johannes.Hofmann＠gmx.de June 20, 2008

June 20, 2008

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

3 8

easy way to get many root certificates?
by corvid＠lavabit.com June 20, 2008

June 20, 2008

I'm tired of clicking on the "remote certificate cannot be verified" message. I added a couple of lines to https.c so that it would save certificates. When I encountered the next https page, "openssl x509 -text -in [certificate]" showed that Equifax was the issuer. I got their root certificate, stuck it in .dillo/certs, found the hash value with "openssl x509 -hash -in [certificate]", and linked it to [hash].0. And, hey, no more message! But I don't want to do that over and over for all of the common root certificates. It seems that you can get the certificates out of firefox if you have some program called certutil, but, so far as I can tell, this requires getting a bunch of mozilla code known as NSS that is something like six megs of source. This is nowhere near worth the headaches that would surely result from trying to compile such a thing. So, does anyone happen to know an easy and convenient way to deal with this?

3 5

[patch] fix FltkPlatform destructor
by Johannes.Hofmann＠gmx.de June 19, 2008

June 19, 2008

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

2 1

recent style/layout segfaults
by corvid＠lavabit.com June 18, 2008

June 18, 2008

I've seen occasional segfaults in recent weeks, and twice now I've been able to catch them when I remembered to have gdb going (and, well, zero times when I remembered to have ulimit -c unlimited) These two have been nearly identical. Here's the one I just got: #0 0x00000048 in ?? () #1 0x080aa74e in dw::core::Layout::removeFont (this=0x815ca58, attrs=0x81dfc08) at layout.hh:253 #2 0x080a8f07 in dw::core::style::Font::remove (this=0x81dfc08, layout=0x815ca58) at style.cc:287 #3 0x080aa85a in dw::core::style::Font::unref (this=0x81dfc08, layout=0x815ca58) at style.hh:587 #4 0x080aa042 in ~Style (this=0x81d8680) at style.cc:204 #5 0x0805b123 in dw::core::style::Style::unref (this=0x81d8680) at style.hh:505 #6 0x08089359 in ~Textblock (this=0x8249308) at textblock.cc:96 #7 0x080a52e7 in dw::core::Layout::setWidget (this=0x822f868, widget=0x827b3b0) at layout.cc:175 #8 0x0805aea8 in a_Web_dispatch_by_type ( Type=0x827c480 "text/html; charset=UTF-8", Web=0x824ebc0, Call=0x821d320, Data=0x821d324) at web.cc:94 .. The layout in frame 3 was: p *layout $7 = {<> = {<No data fields>}, emitter = {<> = {<No data fields>}, <No data fields>}, platform = 0x814c0f0, views = 0x815cb78, topLevel = 0x0, widgetAtPoint = 0x0, bgColor = 0x823a278, cursor = dw::core::style::CURSOR_DEFAULT, canvasWidth = 0, canvasAscent = 0, canvasDescent = 0, usesViewport = true, scrollX = 0, scrollY = 0, viewportWidth = 680, viewportHeight = 482, canvasHeightGreater = true, hScrollbarThickness = 15, vScrollbarThickness = 15, scrollTargetHpos = dw::core::HPOS_LEFT, scrollTargetVpos = dw::core::VPOS_TOP, scrollTargetX = 0, scrollTargetY = 0, scrollTargetWidth = 0, scrollTargetHeight = 0, requestedAnchor = 0x0, scrollIdleId = -1, resizeIdleId = -1, asapResizeIdle = true, scrollIdleNotInterrupted = true, anchorsTable = 0x815cba0, selectionState = { doubleClickEmitter = {<> = {<No data fields>}, <No data fields>}, layout = 0x815ca58, selectionState = dw::core::SelectionState::NONE, from = 0x0, to = 0x0, fromChar = 1, toChar = 1, linkState = dw::core::SelectionState::LINK_NONE, linkButton = 3, link = 0x0, linkChar = 3, linkNumber = 13}, findtextState = {key = 0x0, caseSens = 32, nexttab = 0x0, widget = 0x0, iterator = 0x0, hlIterator = 0x0}} and the layout in frame 7 was: p *this $8 = {<> = {<No data fields>}, emitter = {<> = {<No data fields>}, <No data fields>}, platform = 0x8281808, views = 0x8246f38, topLevel = 0x8249308, widgetAtPoint = 0x0, bgColor = 0x823a278, cursor = dw::core::style::CURSOR_DEFAULT, canvasWidth = 665, canvasAscent = 5, canvasDescent = 11564, usesViewport = true, scrollX = 0, scrollY = 8854, viewportWidth = 680, viewportHeight = 482, canvasHeightGreater = true, hScrollbarThickness = 15, vScrollbarThickness = 15, scrollTargetHpos = dw::core::HPOS_LEFT, scrollTargetVpos = dw::core::VPOS_TOP, scrollTargetX = 0, scrollTargetY = 0, scrollTargetWidth = 0, scrollTargetHeight = 0, requestedAnchor = 0x0, scrollIdleId = -1, resizeIdleId = -1, asapResizeIdle = true, scrollIdleNotInterrupted = true, anchorsTable = 0x81e4078, selectionState = { doubleClickEmitter = {<> = {<No data fields>}, <No data fields>}, layout = 0x822f868, selectionState = dw::core::SelectionState::NONE, from = 0x0, to = 0x0, fromChar = 3, toChar = 3, linkState = dw::core::SelectionState::LINK_NONE, linkButton = 136509888, link = 0x0, linkChar = 136509920, linkNumber = 0}, findtextState = { key = 0x0, caseSens = 16, nexttab = 0x0, widget = 0x8249308, iterator = 0x0, hlIterator = 0x0}} Both look fairly layoutish. I only had one bw open at the time of crash. My guess at the problem: StyleTable will give you back whatever Style matches your attrs, but maybe that Style was created with a different layout.

3 11

patch: view gzipped local files
by corvid＠lavabit.com June 18, 2008

June 18, 2008

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.

2 1

About the patch for Style-related crashes: +1 !
by onepoint＠starurchin.org June 18, 2008

June 18, 2008

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

1 0

Valgrind: hashing StyleAttr objects accesses uninitialized data
by onepoint＠starurchin.org June 13, 2008

June 13, 2008

Ever since StyleAttr objects were cached in a hash to promote sharing, valgrind has reported nearly 1000 branches dependent on uninitialised data when dillo renders the splash page. These all come from StyleAttrs::hashValue() and StyleAttrs::equals() : if I hack hashValue() to return ((intptr_t) this) and equals() to return (this == otherAttrs) then the warnings disappear. Is this a problem? If these methods are accessing uninitialised data members then what happens when that data is initialised? The return values of hashValue() and equals() could change, which sounds like a potential source of bugs. Even if it's not a bug, if the value of hashValue() is unpredictable then we might not be sharing StyleAttr objects as much as we could and so we could be wasting memory. If it is correct to have code that raises these warnings, perhaps there could be a "#define VALGRIND" switch so developers could easily compile a dillo that doesn't raise them? (It's possible to silence them with a valgrind suppression file but that is tedious and risks hiding other warnings. It would be much more straightforward to have a valgrind-clean version of the code.) Comments are welcome, Jeremy Henty

3 6

form.cc: refactor DilloHtmlForm::eventHandler()
by onepoint＠starurchin.org June 11, 2008

June 11, 2008

Three small patches that clean up form event handling: 1: refactor file loading into DilloHtmlInput::readFile() 2: refactor form submission into DilloHtmlForm::submit() 3: refactor the input logic into DilloHtmlInput::activate() Regards, Jeremy Henty

2 1

RFC: removing the search dialog
by 4winter＠informatik.uni-hamburg.de June 11, 2008

June 11, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey :) I hacked up opera (at least I _think_ they do it this way) style search engine handling. I am not too happy with what I did to the config file parser, but it works for now :). The parser is beautiful in its simplicity, but it has its limitations (like not being able to handle dictionaries). I am not sure what I would like to see, but for the moment I'd go with dictionaries and the ability to include other files. This way we could ship some config files (think browser personalities) and the user could include the one he likes best and fine tune the settings in his personal dillorc. I was also unsure about the proper way to inform the user of errors and I believe the reason for this is simply that there is no mechanism to do this properly. I am thinking about using the browser widget to render error pages like most of the mainstream browsers. Any thoughts on this one? 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 iD8DBQFIN4EQoPmwNWhsaZYRAn93AJ9cVSrlojFB7rcRfDuuysS+iF9MrwCfY5rB Be/P/5ORephsPhmdBcyk+MM= =1rOv -----END PGP SIGNATURE-----

5 7

form.cc: select and option classes
by onepoint＠starurchin.org June 10, 2008

June 10, 2008

Two patches here. The first patch turns DilloHtmlSelect and DilloHtmlOption into classes and implements their constructors and destructors. It also makes DilloHtmlInput::DilloHtmlInput() responsible for creating the select object if necessary (as determined by examining the input type) and removes the select argumentfrom DilloHtmlInput::DilloHtmlInput() and DilloHtmlForm::addInput() . The second patch is a small followup that simplifies select handling elsewhere: instead of checking the input type we check if the input's select is non-NULL. Regards, Jeremy Henty

2 1