- Dillo-dev - lists.mailman3.com

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

Re: [Dillo-dev] Rendering problem

by Ralph Slooten

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. 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 Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

Aug. 28, 2003

Re: [Dillo-dev] Problems with tab patch

by Nigel Wilkinson

On Thu, 28 Aug 2003 22:19:29 +0200 Frank de Lange <frank(a)unternet.org> wrote: > You need to cd to the dillo directory before applying the patch: > > Assuming you have dillo CVS in /usr/src/dillo-cvs/dillo, and you do NOT want to apply the patch over the CVS directory itself (good idea, as you might want to update the CVS later...): > > % cd /usr/src/dillo-cvs (or whereever the dillo directory resides) > % cp -rd dillo dillo_tabs (this copies the CVS dir to a new dir) > % cd dillo_tabs (go to the new dir) > % zcat dillo-20030821-tabs.patch.gz | patch -p1 (apply patch) > % ./autogen.sh (generate configure and Makefile.in) > % ./configure (with whatever options you prefer) > % make > % make install > 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. 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' Cheers Nigel

Aug. 28, 2003

Re: [Dillo-dev] Problems with tab patch

by Frank de Lange

On Thu, 28 Aug 2003 20:35:27 +0100 Nigel Wilkinson <nigel(a)waspz.plus.com> wrote: > > Evenin' all > > I'm trying to patch the CVS with the tab patch but I haven't used patch much. The problem I'm haveing is that I don't know which directory to run the path from, it keeps complaining that it can't find the file to patch You need to cd to the dillo directory before applying the patch: Assuming you have dillo CVS in /usr/src/dillo-cvs/dillo, and you do NOT want to apply the patch over the CVS directory itself (good idea, as you might want to update the CVS later...): % cd /usr/src/dillo-cvs (or whereever the dillo directory resides) % cp -rd dillo dillo_tabs (this copies the CVS dir to a new dir) % cd dillo_tabs (go to the new dir) % zcat dillo-20030821-tabs.patch.gz | patch -p1 (apply patch) % ./autogen.sh (generate configure and Makefile.in) % ./configure (with whatever options you prefer) % make % make install Easy, not? 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. 28, 2003

Re: [Dillo-dev] Rendering problem

by Frank de Lange

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. Off Topic, but... slashdot on Dillo works best when you use Slashdot's 'light' mode... No more annoying pictures, colors or other crap, just the 'facts' (if facts and slashdot can be named in the same sentence...). You need to be logged in to use light mode. 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. 28, 2003

Problems with tab patch

by Nigel Wilkinson

Evenin' all I'm trying to patch the CVS with the tab patch but I haven't used patch much. The problem I'm haveing is that I don't know which directory to run the path from, it keeps complaining that it can't find the file to patch Cheers Nigel

Aug. 28, 2003

Rendering problem

by Andrew A. Gill

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. (bug 493) -- |Andrew A. Gill |I posted to Silent-Tristero and| |<superluser(a)frontiernet.net> |all I got was this stupid sig! | |alt.tv.simpsons CBG-FAQ author | | | (Report all obscene mail to Le Maitre Pots)| |Nothing here yet: <http://www.needsfoodbadly.com> Temporary sig: -- But thanks for everything else.

Aug. 28, 2003

Re: [Dillo-dev] Dillo Windows port

by Robin Rowe

Jorge, I have Dillo built now as a native Windows VC++ 6 project and am debugging it. Seems to be my unstable 1.14 version of GTK for Windows that is causing Dillo to hang on load. By the way, I'm the new GTK1 for Windows maintainer. Tor and GIMP for Windows are moving to GTK2, but CinePaint is staying with GTK1. Can we talk about Dillo design portability a bit? 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 Windows. There isn't any pthreads either, but I've written a light emulation library (as yet untested) that calls Windows threads instead. You are using mutex and conditional pthreads together, which seems redundant. Are both needed? Could you use just a mutex? What is that code supposed to do and why? Another call unavailable in Windows is fcntl(). I've conditionally compiled those out, and don't know yet what that may effect. 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? Can you tell me about your internationalization support in Dillo? How is that set up? What is it designed to handle? Thanks, Robin --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Aug. 28, 2003

[Long] dillo server mode/remote control (was: Re: dillo / time-controlled reloads)

by Melvin Hadasht

Hi, > A simple flag, maybe in the DilloUrl or in the cache entry. In the posted patch, I just added a reload_timeout in DilloUrl and a reload_timeout_tag in BrowserWindow. When viewing a DilloUrl with a non-zero DilloUrl::reload_timeout, BrowserWindow will start a single shot timer which tag is saved in BrowserWindow::reload_timeout_tag. This timer will trigger a reload (as if the user hit the reload button). The reload will restart the timer. If another DilloUrl is viewed, any pending timer is stopped (and the new DilloUrl is again tested for a non-zero DilloUrl::reload_timeout). I also added a_Url_set_reload() to set/unset that reload_timeout. > > - add a "-r, --reload-every" command line option that calls that function. > > In fact, when I finish implementing the "(remote-)command" option, it would be > > something like: "-c open(URL, refresh=60)" (that is if I finally decide that > > supporting commands with more than one argument is worth the work). > > Hmmm, I think a simple cli switch to tell dillo to listen to > the reloads.dpi is enough: > > dillo -reloads Internally, the command line options are translated to a linked list of commands, which are executed by the running instance, or sent to a running server. So I implemented both. The advantage of the "-c" option is that commands could support parameters as in: "open(URL newwindow reload=50)". It adds flexibility. > > > > The first duty is to define what is required for a good, > > > > general purpose, kind of reloading dpi. The next one is to reduce > > > > the features to a minimum working set, then implement! I think it is easier to implement a remote command dpi than implementing a "reload dpi". The "reload" should only be one of the remote commands that a server must understand. > fprintf(reloads_dpi_socket, > "push http://localhost/someurl visible\n"); > > may be all the client program needs to know. Unfortunatly, fprintf does not work with Unix Domain Sockets but with pipes. Pipes have a limitation: if more than a client access to the pipe, the server could get mixed-up commands if the clients commands are larger than a system specific buffer size. For robustness, I will use UDS. If a client program wants to use dillo server capability, then we'd better provide a lib or a small C file. > Note that it may be good to integrate the remote control > functionality into the same dpi (and maybe call it remote.dpi?). Yes, I agree, the reload (and other functions) should be served by the remote control functionality. Whether it should be a plugin, I am not completly convinced, because it adds a little more complexity: At the current state of the dpid, we cannot run more than one dillo server (if we make exclusive use of the dpid framework). This is because for each service, there is only one socket. I think it is more flexible to have the possibility to have different dillo servers, each one with a distinct name provided by the user (or the application). For that, dpid should accept an additional parameter which is used to parametrize the socket name, e.g.: <dpi cmd="start_plugin" msg="dillo" param="cinepaint_help"> dpid will then look if a socket named: "/tmp/$USER-$RAND/dillo-server-$PARAM" ($PARAM being the value of the param tag) exist. If it does not exist, it would start the plugin with a special command line option: dillo -s $PARAM. This will require a way to tell the dpid how to call a parametrized plugin. Thus, relying on dpid to create the socket and run the server plugin would need some changes to dpid. An alternative solution, is to not rely on dpid but on dillo itself to start a server and to create the socket. The socket will be independent from the dpi_dir, and would be /tmp/dillo-$USER-$SERVERNAME. Subsequent communications could still use dpid's I/O functions. > This means adding a simple and useful API for help programs to > use. For instance to let them push new URLs into the same > instance of dillo (and not having to start a new dillo per > requested page). (if the application never starts a dillo instance, then there is no guarantee that there is a dpid running. Or you meant the API should take care of this, too?)

Aug. 28, 2003