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.-
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
* Jorge Arellano Cid <jcid@dillo.org> schrieb:
It took some time to get back to you, but the topics raised are non trivial. Let's start with the simpler one:
What exactly does it make so complex ? BTW: on Plan9 even the whole web access runs via its own fileserver (webfs). IMHO we should keep that in mind and someday go that way.
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.
I'm currently too occupied, but you may trigger me in about a month ago :)
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.
Does it really have to be fltk2 ? Aren't there enough other widget toolkits (in plain-C) out there ?
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).
hmm, does gtk2 make it better ?
[Translations] I'm already working on German translation.
Are you working on a generic approach to translations or just German?
I just added a new transled the .po file.
[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.
Okay, I'll have a look at if time allows.
[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!
Well, that's a bit similar :)
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.
hmm, we could introduce a new exec:// url scheme and filter by Referer-Header.
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.
:) Maybe be we even could replace the whole dpip stuff by 9P.
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.
Quite minimal. Have a look at: svn://svn.metux.de/public/9exec svn://svn.metux.de/public/9p-mixerfs svn://svn.metux.de/public/9p-sysdb_fs The libs used: svn://svn.metux.de/public/libmixp svn://svn.metux.de/public/libmixpsrv And an vfs library that supports 9p: svn://svn.metux.de/public/libmvfs (authenticate with anonymous:anonymous to svn)
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.
Yep :) With libmixpsrv you can easily provide access to variables or commands through an filesystem. No more additional protocol needed - everything just sits in an hierachy with an simple and uniform access model.
For instance: Load URL, Reload, Stop, Open New window, Back, Forward, images on/off, etc.
Right, settings are just files (one file per setting). Actions are performed by writing to certain files. Let's say, some viewer is in the subdir /viewers/1/, you just write to /viewers/1/url to load a new page.
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.
I'll summarize evrything as soon as I've got more time. (currently in jack-bauer-mode ;-))
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.
Right, because in that case we need some command protocol nevertheless, so the additional complexity is required. When using 9P (via libmixpsrv), most of the things are already done :) cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------
participants (3)
-
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
weigelt＠metux.de