- Dillo-dev - lists.mailman3.com

[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