- Dillo-dev - lists.mailman3.com

[Dillo-dev]Mailing list search

by Jorge Arellano Cid

Jörgen, and everybody I just noticed that GMANE is forcing javascript to display mailing list searches :(. Well, we have the relevant dillo-dev mail folders, so maybe it's time to provide that service from our web site. There surely are good programs for doing this. Does anyone know of a good candidate? (the problem is: given a set of mailfolders, provide a search engine with an HTML interface to them). -- Cheers Jorge.-

Aug. 12, 2004

[Dillo-dev]urlencoding and the search dialog

by Jorge Arellano Cid

Hi there, A patch for urlencoding what's entered in the search dialog has just been added. A couple of functions in the URL API changed its name. Everything should be OK, but further testing is welcomed. Now you can enter non safe characters in the web search dialog (mainly non ASCII) and have then automatically urlencoded in the query. The FORM submittion routines also use these functions so testing your favorite FORMS is also adviced. Cheers Jorge.-

Aug. 12, 2004

Re: [Dillo-dev]Is IO.txt outdaetd?

by Jorge Arellano Cid

On Mon, Aug 09, 2004 at 03:18:47PM +0800, Calvin Yu wrote: > It says dillo uses threads for DNS querying and reading local > files, and signal driven I/O for TCP connections. When the socket > gets ready for transmission, the data is sent using > g_io_channel_write. But I can't not find the place where > g_io_channel_write is invoked in the code. Ok, I updated it. Beware that it's not an exact explanation of what happens inside Dillo today. Anyway, it continues to be an excellent source of information that describes the theory behind the code. Beware that the plugin system is not described in IO.txt and that the latest patch moved the "file:" protocol to a dpi, so it's not handled with a thread and a pipe inside Dillo anymore. Anyway, the thread and pipe pair is the basis for the generic dpi data stream transfer, so the theory in IO.txt will explain it to some extent. -- Cheers Jorge.-

Aug. 11, 2004

Re: [Dillo-dev]Big Dpi patch: data stream API, and "file:" protocol as a dpi filter

by David McKee

On Wed, 11 Aug 2004, Jorge Arellano Cid wrote: > I've been silent for some time, working on a medium sized patch > that was just commited. Seems to work...the tables mode looks pretty good. I note that if I look at dir/, follow the link to dir/subdir/, switch the rendering mode, and hit back I get dir/ in the original rendering mode, but if I look at dir/, follow the link to dir/subdir/, switch rendering modes, and follw the link to dir/subdir/../ I get the new mode. So, the back button in looking at the cached file, not calling the plugin again. Not a big deal. A refresh always gets the most recently established mode. [In the table bsed file: rendering mode:] > Note that the stripes' slight contrast on the table-based mode > is meant for easy reading of the file names when looking for a > file by its filename. The contrast helps the eye (almost at the > unconcious level) to locate the right row of it, when locating > its type, size or date. Apple uses a similar thing in sufficiently new Finders. They use slightly more contrast, and I find that it helps more. It is, however, more visually intrusive. Cheers, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Aug. 11, 2004

Re: [Dillo-dev]Is IO.txt outdaetd?

by Jorge Arellano Cid

On Mon, Aug 09, 2004 at 03:18:47PM +0800, Calvin Yu wrote: > It says dillo uses threads for DNS querying and reading local > files, and signal driven I/O for TCP connections. When the socket > gets ready for transmission, the data is sent using > g_io_channel_write. But I can't not find the place where > g_io_channel_write is invoked in the code. Yes, once upon a time it used g_io_channel_write, but not anymore. I'll update this doc ASAP and let you know when its ready. > > In previous posts I see > "When using threads and mutexes (pthreads), thread scheduling is > done by a third thread or by the kernel (depends upon the > implementation), and it is preemptive. Now, the address space may > be shared, so the need for mutexes arise, and because of both > reasons, performance is degraded. > Using a pseudo-thread (CCC thread), doesn't require scheduling > by an external process or by the kernel. All is done in the same > process, but there's no preemption." > But I do find a thread is spawned in "a_IO_write_chunk()". > Would you please tell me the reason? Otherwise it wouldn't generate IO signals. > What does pseudo-thread mean? A non-preemptive thread as those handled by CCC. > Is such thread spawned in > "a_IO_write_chunk()" pseudo-thread? No that one is a POSIX thread (or pthread at least ;). -- Cheers Jorge.-

Aug. 11, 2004

[Dillo-dev]Big Dpi patch: data stream API, and "file:" protocol as a dpi filter

by Jorge Arellano Cid

Hi There, I've been silent for some time, working on a medium sized patch that was just commited. From the Changelog: <q> * Designed and implemented a unified API for handling data streams inside dillo plugins. Servers and filters can use it. * Converted the bookmarks server plugin to the new dpiutil API. * Moved the internal support for "file:" URIs into a dpi (filter plugin). * Added TABLE-based rendering of directory listings to the new file dpi. </q> Some time ago Jörgen sent me a crude prototype for a dpi filter for handling the "file:" URIs. The main problem was that it was very, very slow (say 10 times slower). It was all a buffering problem. At the same time I was discussing the idea of extending the API in dpiutil for https (with Garret), and also having in mind the GUI downloads dpi and maybe also turning cookies into a dpi. After a lot of thought I decided to start trying a tentative API, and ported the bookmarks server to it so the new functions could be tested better. Then I picked up the file dpi prototype and also ported it to the new API and polished it a lot. The idea behind was to test the API with different applications (i.e. different requirements) to be more confident about its design. Now it seems to be working OK, so a commit was done. Note that currently the file dpi filter is just an idea to test, it can be reversed or further improved. I want you to try it and make yourselves an impression while using it. It features two rendering modes: with <PRE> and with <TABLE>. The "%" link to the right of the "Parent" directory link makes the rendering mode switch! (it was added for testing's sake). Note that the stripes' slight contrast on the table-based mode is meant for easy reading of the file names when looking for a file by its filename. The contrast helps the eye (almost at the unconcious level) to locate the right row of it, when locating its type, size or date. The table-based mode is not rendering dotfiles at the moment. A very easy patch, I'll burden Jörgen with! :-) Bottom line: Please test it throughly and send some feedback. Cheers Jorge.- PS: Now I'll try to catch up with the latest emails and patches I was sent.

Aug. 11, 2004

[Dillo-dev]Thanks, but keep working

by John Summerfield

I'm glad to have found Dillo, I'd been hoping to find a light-weight browser for use on (small) servers where it's necessary to configure routers, firewalls and printers using their http interfaces. I really do not want to install Mozilla or such for these uses, they are far too enormous. I could use lynx, elinks, links or w3m, except that none of them works well either, and none has a pretty face:-). I don't mind installing a lightweight GUI desktop so as to be able to use GUI configuration tools. Dillo shows promise, but before it is useful it to me has to support 1. Basic authentication. This is essential. 2. Javascript. Some features of Billion 741GE ADSL routers require it 3. Frames. Probably not essential, but it surely will improve navigation. -- Cheers John Summerfield

Aug. 9, 2004

[Dillo-dev]Is IO.txt outdaetd?

by Calvin Yu

It says dillo uses threads for DNS querying and reading local files, and signal driven I/O for TCP connections. When the socket gets ready for transmission, the data is sent using g_io_channel_write. But I can't not find the place where g_io_channel_write is invoked in the code. In previous posts I see "When using threads and mutexes (pthreads), thread scheduling is done by a third thread or by the kernel (depends upon the implementation), and it is preemptive. Now, the address space may be shared, so the need for mutexes arise, and because of both reasons, performance is degraded. Using a pseudo-thread (CCC thread), doesn't require scheduling by an external process or by the kernel. All is done in the same process, but there's no preemption." But I do find a thread is spawned in "a_IO_write_chunk()". Would you please tell me the reason? What does pseudo-thread mean? Is such thread spawned in "a_IO_write_chunk()" pseudo-thread? Thanks a lot!

Aug. 9, 2004

[Dillo-dev]why must FLTK?

by Calvin Yu

hello everyone: In order to support double-byte characters, we must port GUI from gtk+1.2 to others, right? The FAQ tells me that the developers are planning to port GUI to FLTK. Who is so kind to tell me any alternatives? I hear FLTK is very complex and not stable. By the way, has anyone taken gtk+-directfb into account? I complied it and ran some example applications. It looked pretty. If we port GUI to gtk+-directfb, we don't need X server any more. It would save a lot of resources. Futhermore, the work will be much less because of similar APIs between gtk-1.2 and gtk-2.x. Best Regards From Calvin Yu

Aug. 6, 2004

[Dillo-dev]what can i do for dillo?

by Calvin Yu

dillo-devOn Mon, Aug 02, 2004 at 07:41:33PM +0800, Calvin Yu wrote: > Dear Jorge Arellano Cid: > I'm very thankul for your advice and help. Good. > > I'm a student of colloge in China. My advicer gave me a project > of linux light-weight browser as my project for graduation. After > reviewing several open-source linux browsers, I think Dillo is a > good choice. For it is small and fast, especially fit for > embedded linux device. But there are some flaws with it. For > example, it doesn't support Chinese and JavaScript. I think these > functions are important for a browser. So I hope I can add those > functions to Dillo. As I told you before, Javascript is very complex to add. Not only the current Dw system is not ready for it, but also Javascript poses a big security threat that needs to be addressed in detail. > You told me that many persons want to make Dillo render > chinese, but they don't collaborate with you. Yes it is possbile. > I think most of them want to do such work because of their own > interest, not necessary mission. When they meet with difficulties > they will give up and disappear... I understand. > But now I have to do some work on Dillo (If I choose it as my > prototype system). I hope I can resolve those problems. Rendering chinese, alone, is more than a challenging task for a graduation project. As you know, we plan to port Dillo to FLTK, once that's done, rendering Chinese would require two things: a) Add the glyph logic module for Chinese to FLTK. b) Make sure Dillo works OK with it (FORMS, etc). You can also help us with the port to FLTK. > By the way, would you please tell me what documention should I > read if I want to do those work? I can't find enough documents on > www.dillo.org. Now I'm reading the code of Dillo. The new FAQ in our site will suggest several links (that's plenty of documentation, only for the i18n subject). Then follow the whole thread on FLTK. It shows the feasibility analysis. Please note that it's an abridgement, not all the emails we exchanged with the FLTK team are there! It was a large work. Beware that one of the worst mistakes to do in SW projects is to underestimate the complexity. My advice for you is to try Chinese rendering. That is: a) Add the glyph logic module for Chinese to FLTK. b) Make sure Dillo works OK with it (FORMS, etc). c) Help us with the port to FLTK. Cheers Jorge.-

Aug. 6, 2004