On Tue, Jun 02, 2009 at 09:43:57PM +0200, Johannes Hofmann wrote:
On Sun, May 31, 2009 at 09:26:57PM -0400, Jorge Arellano Cid wrote:
On Mon, Jun 01, 2009 at 12:17:23AM +0200, Johannes Hofmann wrote:
On Sun, May 31, 2009 at 06:08:23PM -0400, Jorge Arellano Cid wrote:
On Sun, May 31, 2009 at 07:55:27PM +0000, corvid wrote:
annoyed by the slow source view widget I'd like to play with a source viewer dpi (Jorge, I think you suggested to use a dpi instead of coding it in dillo directly). However I want to avoid to reload the page from the dpi, as I want to be able to view the source exactly as it is currently displayed.
How should I pass the html document from dillo to the dpi? Any ideas?
Can you borrow the start_send_page stuff used to send local files to dillo?
That's the idea.
You have to pass the source to the dpi to create a table with the line number. That way you have the handy line number and find text functionality.
Something like:
<table> <tr><td>1 <td> LINE_CONTENT_HERE <tr><td>2 <td> LINE_CONTENT_HERE ... </table>
Yes, that will be the fun part :) I also think about an option to pass the html to tidy to make it more readable. However first I need to get the html from dillo to the dpi. Is the start_send_page already working in that direction or is a new equivalent method needed?
From the top of my head (because I haven't worked there in a long time): start_send_page is the canonical way to send a page to dillo from a dpi. The missing part may be how to send the page to the dpi first. I remember making a short and funny dialog for adding bookmarks to illustrate how bidirectional data exchange could be done; it's still in the code! (take a look in a_Bookmarks_chat_add())
If it gets unclear, please let me know to allocate some time to help on it.
Here are two questions already :)
* the DPIs seem to send <cmd='start_send_page' url='dpi:/hello/' '> before sending the actual html page. Note the quote in front of '>'. Is this intended? At least it doesn't seem to work when I remove it.
Absolutely! You can find a detailed explanation in dpip/dpip.c
* What is the reason for the SockHandler stuff. Why are DPIs not just using plain printf and friends?
There were some problems. e.g. The stream functions block when reading. Dpis also can be filters (stdin/stdout) or servers using a single socket (stdin/stdin) for read and write, and the sock handler unifies this with common code and a single interface. Dpis handle different tasks and transfer sizes so buffering becomes important, and all that is unified in a single layer (as now) instead of a myriad of approaches that break sometimes for no clear reason (as before. e.g. different default buffering across OS). -- Cheers Jorge.-