- Dillo-dev - lists.mailman3.com

[PATCH] Server Mode (was: commands & auto-reload)

by Melvin Hadasht

Hi, I previously posted a "command" patch as a preliminary for the server mode patch for Dillo. It was about handling the list of commands to be sent to the server. The hereby attached patch already contains that patch slightly modified and adds the ability to eventually switch to server mode or to connect and send the commands to a server This patch does not solve the "reload" bugs. I have a web page (user oriented) at: http://melvin.hadasht.free.fr/home/dillo/server/index.html I finally chose the "straightforward" approach instead of the dpid approach. Two reasons for that: i) I felt it'd introduce more complexity, especially for a client instance that needs to connect to a server and ii) the current dpid allows only one socket per service while it would be needed to have more than one Dillo server. I already explained in another mail that the socket name would need to be parametrized (by the server name, for example). Of course, this patch of mine is just a suggestion, if others feels that the dpid approach is better and more efficient, I'd be happy to see how they implemented it. The "commands" patch could still be used. They just need to handle the server/client connection. The hereby attached patch has the following characteristics: - gtk_init() is never called by a client instance - if the XID option is given, and if the server already has an embedded window with that XID, it will reuse it. - an application can still directly access to the server socket and can keep the connection open until it really does not need it. It has to check whether /tmp/dillo-$USER-$SERVERNAME exists. If not, it should launch "dillo -s $SERVERNAME". Then it should open that Unix Domain Socket. Then it just need to send commands to it, the syntax of the commands being that of the -c options. The commands that are to be sent through the socket must be of the following format: ([COMMAND][NUL])*[CRLF] That is, each COMMAND string must be followed by the terminal NUL byte. The list of commands are buffered by the server command until a [CRLF] ("\r\n" without the terminal \NUL) is sent or until the socket is closed. Then, the list of buffered commands are executed. I'll provide a simple library that could be used by an application to directly use the socket, but for the moment, the most easy and straighforward approach is to set the browser command line to "dillo -s SERVERNAME URL". On a PII266Mhz, starting a dillo client with a single open() command needs only ~0.04 seconds (if gtk_init() were executed before command line parsing and thus if each dillo client had to init the display, it would have needed more than 0.1 seconds). My next plans are to provide a simple library to connect (and eventually start) a server and to sent it commands. Then I will try to fix the "reload" bug when the reload time is too short. -- Melvin Hadasht

Aug. 29, 2003

Rendering

by Jorge Arellano Cid

Hi Sebastian! Hope you're not under a pile of workload... Please review this site: http://cocoon.apache.org/index2.html When loaded slowly (dialup speed) it renders the leftmost column too wide (almost a screen), but Back&Forward fixes it. I you can also give a look at the slashdot problem it'd be great. I'm much more interested in the first though. Regards Jorge.-

Aug. 29, 2003

Re: Tab + frame patch, any progress?

by Jorge Arellano Cid

On Wed, 27 Aug 2003, Frank de Lange wrote: > Any progress on the CSS front by the way? Sometime ago we concluded with Sebastian that it may take near three months of work of both of us. We're focusing on other priorities now. I hope we can review your patch soon with him. Cheers Jorge.-

Aug. 29, 2003

Re: [Dillo-dev] Rendering problem

by Jorge Arellano Cid

On Thu, 28 Aug 2003, Ralph Slooten wrote: > On Thu, 28 Aug 2003 12:57:36 -0400 (EDT) > "Andrew A. Gill" <superluser(a)frontiernet.net> wrote: > > > I've been having a problem with dillo rendering some portions of text. > > For instance, the Google sponsored links always take up vertical space > > before the results. > > > > Normally, this isn't something that I really care about, but now it's > > causing slashdot to be rendered as black-on-black text, thus depriving me > > of my ability to read about the new MD5 sums that the RIAA is using. > > Yes, I'm getting this too since today. It's probably a small html error > somewhere, but it's totally skrewed up dillo's rendering to the fullest here. Unfortunately slashdot is sending awful HTML-like content. The black text can be explained because they explicitly set the background, textcolor and visited links to black! (<BODY ...>). Probably it changes with CSS. > > Since about 2 weeks ago I'm also getting a black border on the right (with > exception to today of course where most of the page is black) which just takes > up valuable space ;-) > > Tried the light mode too like Frank suggests, but I prefer the default layout > myself. Anyway, it's not a dillo problem I think, as I get a total of 530 errors > just on the index page itself!!!!! Check now too if ya want: > http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org%2F Try with "force_my_colors=YES". Now, it still shows several rendering problems. If those are because of lack of implementation of "floats" we should fix it someday. If it's because of bad HTML, you know our policy. OTOH, I believe slashdot webmasters will not pose major problems to fix their HTML if they're emailed with the facts... Please investigate those and report to them. Cheers Jorge.-

Aug. 29, 2003

Re: [Dillo-dev] Running external Gtk programs under Tabs (fwd)

by Lars Segerlund

very cool ! :-D BIG SMILEY Jorge Arellano Cid wrote: > > ---------- Forwarded message ---------- > Date: Wed, 27 Aug 2003 23:48:14 -0700 > From: t <loveall(a)qwest.net> > To: Jorge Arellano Cid <jcid(a)softhome.net> > Subject: Running external Gtk programs under Tabs > > Jorge, > > Please forward this to the dillo/dev mailing list unless you think it is not > appropriate. > > Nice job on dillo, guys! Have been using it since at least 0.2.1. > > Nice work on the tabs, Frank. They have added a whole new dimension to dillo. > > Recently, while working on a multi-media project, noticed that I had way too > many instances of a text editor open. Couldn't easily find the desired > file. > > About then Frank put up the tab/frame patch. Spent a day or so getting > external Gtk apps to run in a tabbed window. This turned dillo into an MDI > interface with built-in file picker and HTML help file viewer. > > This has been working for me in a stable manner, e.g. no seg faults, for about > two weeks under heavy use. Which means it will only take someone else about 5 > minutes to induce a failure:-). > > Have modified a file manager, my personal text editor and the erwin HTML > editor to run as client Gtk apps, just like dillo. As a matter of fact, dillo > can run itself as an external Gtk app in a tabbed window. The patch file for > the tab/frame patched version of dillo is set up to do this as a working > example. You can download it from: > http://www.users.qwest.net/~loveall/xid8-patch.gz > > !!!! NOTE !!!! > This patch is valid only on dillo-0.7.3 patched with Franks version 9 > tab/frame patch: > http://www.geocities.com/ikbenfrank/dillo-0.7.3-20030821-tabs.patch.gz > > To modify a typical Gtk app to act as a client requires just the following: > > In function main(), add these lines at the beginning just after the data > declarations: > > guint32 xid = 0; > int i = 1; > > if (i < argc-1 && !strcmp(argv[i++],"-x")){ > xid = strtol(argv[i], NULL, 10); > argc -= 2; > argv += 2; > if(xid == LONG_MIN || xid == LONG_MAX) xid = 0; > } > > This requires that the first two args when calling dillo be '-x <Xid number>'. > > Find and replace the (typically) single line: > > main_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); > > with: > if(!xid) > main_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); > else > main_window = gtk_plug_new (xid); > > See also the working source which references 'xid' in dillo.c and interface.c. > > Thanks again, to the dillo crew. You guys are awesome. > > Regards, > Terry Loveall > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Aug. 29, 2003

Re: [Dillo-dev] Problems with tab patch

by Frank de Lange

On Thu, 28 Aug 2003 22:00:26 +0100 Nigel Wilkinson <nigel(a)waspz.plus.com> wrote: > Great, worked a treat but just for my info where was I going wrong in the following > > 1. I was gunzipping the patch file > 2. I was useing 'patch < dillo-20030821-tabs.patch' > if my CVS source was in ~/Source/dillo I tried this from ~/Source, ~/Source/dillo, and ~/Source/dillo/src > I also tried the above as 'patch -p1 < dillo-20030821-tabs.patch' as > well as -p2, -p3 etc > > The command 'patch < dillo-20030821-tabs.patch' came from the man page > so I just wondered why it didn't work. Well, this should also work: (on a clean, non-patched, not even partly patched source tree) cd ~/Source/dillo patch -p1 < /path/to/dillo-20030821-tabs.patch If it did not, either your source or uncompressed patch is not what it should be. Or you forgot to give the exact path to the patch file? > If I understand things correctly in the command 'zcat > dillo-20030821-tabs.patch.gz | patch -p1' > that worked zcat decompresses the zipped dillo patch and pipes it to > patch. Why is this different from > 'patch -p1 < dillo-20030821-tabs.patch' There is no real difference (zcat is more practical, as you do not have to uncompress the patch). Both commands should have the same results. If not, something weird is happening. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Aug. 29, 2003

Re: [Dillo-dev] Dillo Windows port IO_submit

by Madis Janson

On Thu, 28 Aug 2003, Robin Rowe wrote: > Hi. The IO_submit code isn't portable to Windows. Unlike unix, Windows > offers only blocking io on pipes. The usual way to deal with this is to spin > off read or write into another thread where it can block without hanging the > program. Your io scheme is complicated enough that it isn't immediately > obvious how best to do that. > > Can somebody offer more insight into the code below or offer any > suggestions? How long does an IO_submit operation stay open and what data is > transmitted normally? What dialog is expected across the pipe? Use two connected sockets instead of the pipe. You can create such pair for example by listening random port (bind to port 0) and connecting to address found out using getsockname.

Aug. 28, 2003

Re: [Dillo-dev] Dillo Windows port

by Andreas Schweitzer

Hi, although I'm not a main developer, I think I can answer a bit. > I have Dillo built now as a native Windows VC++ 6 project and am debugging > it. cool ! > Dillo uses pthreads and fork. Wouldn't it be better to use one multi-process > API? Shouldn't it be all pthreads? Of course, there is no fork under In the current CVS version I only found one reference to fork and it was to start a plugin. Currently, this is no longer used and is dead code. However, some way of starting the dpid automatically will most likely return - for the current CVS version this dpid has to be started manually. But either way, the plugins and the dpid are totally seperate programs. dpid is designed to only be started once. This functionality should be reproducable in Windows, I'd say :-) The other fork's are within the plugin framework when the dpid actually starts the requested plugin. You probably can delay that framework. Dillo will still work - with limited functionality. > Although Berkeley sockets are available in Windows, the AF_LOCAL protocol > doesn't seem to be. I've faked that out to get Dillo to compile but more > work may be needed there. Why are you using AF_LOCAL? What does that code do > and why? It's again related to plugins :-) ... dillo talks to its plugins via unix domain sockets. And that's what this code relates to. If you only need a help browser, you can ignore the plugin framework I would say. That way you will get no bookmarks, though. And the preferences are also planned to be done via a plugin. Or at least delay the plugin stuff until it matured. That's the cool part about the plugin design :-) I hope that helps, Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Aug. 28, 2003

Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads)

by Melvin Hadasht

> there are two small problems: > -if you specify a small reload time, and by that time is over before > the page is actually loaded -> coredump Does not core dump for me. Where does it core dump? I tried "dillo -r 1 http://freshmeat.net" and it reloads the page before it is finished loading. Or by "actually loaded" you mean "did not *start* to load" ?

Aug. 28, 2003

Re: [Dillo-dev] Dillo Windows port IO_submit

by Robin Rowe

Hi. The IO_submit code isn't portable to Windows. Unlike unix, Windows offers only blocking io on pipes. The usual way to deal with this is to spin off read or write into another thread where it can block without hanging the program. Your io scheme is complicated enough that it isn't immediately obvious how best to do that. Can somebody offer more insight into the code below or offer any suggestions? How long does an IO_submit operation stay open and what data is transmitted normally? What dialog is expected across the pipe? Thanks, Robin /* * Receive an IO request (IORead | IOWrite | IOWrites), * Set the GIOChannel and let it flow! */ static void IO_submit(IOData_t *r_io) { /* Insert this IO in ValidIOs */ IO_ins(r_io); #ifdef WIN32 /* Launch thread? */ #else /* Set FD to background and to close on exec. */ fcntl(r_io->FD, F_SETFL, O_NONBLOCK | fcntl(r_io->FD, F_GETFL)); fcntl(r_io->FD, F_SETFD, FD_CLOEXEC | fcntl(r_io->FD, F_GETFD)); #endif if ( r_io->Op == IORead ) { g_io_add_watch(r_io->GioCh, G_IO_IN | G_IO_ERR | G_IO_HUP, IO_callback, GINT_TO_POINTER (r_io->Key)); g_io_channel_unref(r_io->GioCh); } else if ( r_io->Op == IOWrite || r_io->Op == IOWrites ) { g_io_add_watch(r_io->GioCh, G_IO_OUT | G_IO_ERR, IO_callback, GINT_TO_POINTER (r_io->Key)); g_io_channel_unref(r_io->GioCh); } } --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Aug. 28, 2003