- Dillo-dev - lists.mailman3.com

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

Re: [Dillo-dev] CinePaint and Windows port

by Jorge Arellano Cid

On Tue, 26 Aug 2003, Robin Rowe wrote: > Hi. I'm the project leader for CinePaint, an open source paint program used > mainly by the motion picture industry. Our code was branched from GIMP in > 1998. Hi! Yes, I knew about your project by the time we were applying to LinuxFund... > > How would the Dillo project feel about Dillo being embedded in another > application as a help browser? Very good. In fact it has been done in the past with the Sylpheed-claws email client: it embeds dillo for secure HTML mail viewing. In fact we're working in a remote control plugin for dillo to allow better support for this kind of functionality. Currently applications can launch Dillo and let the user navigate the help docs without problems. Now, if the app. wants to provide context sensitive help, it needs to end dillo and launch another instance to make it display the required page (quite fast, but not optimal), and here's where we're improving it. > We're looking for a new help system browser and considering Dillo. We are > impressed how compact your implementation is. We only need a limited set of > HTML features: links, images, tables, bullet lists, number lists, headings, > ordinary text, bold, and italic. In these features we need the browser to be > absolutely stable. Any issues there? None! You'll hardly find a browser that's more stable. And for any issue that may arise, you can email us back for support. > > We support all platforms, including Windows. One of the first things I would > intend to do is port Dillo to Windows. I saw in your archives that you had > made some effort in that direction, but it seemed to peter out. What are the > problems? If you need dillo to run on the dark side, take a look at: http://www.hyperborea.org/software/dillo/cygwin.html Cheers Jorge.-

Aug. 28, 2003

Running external Gtk programs under Tabs (fwd)

by Jorge Arellano Cid

---------- 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

Aug. 28, 2003

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

by Jorge Arellano Cid

On Wed, 27 Aug 2003, Madis Janson wrote: > > On Wed, 27 Aug 2003, Melvin Hadasht wrote: > > > [Please, as this thread is on the ML, do not mail me personnaly (nor CC me). I'm subscribed to > > the list and will respond when I have time and when I have something to respond.] > > > > Hi, > > > > > ok, dillo never reloads the images, not even on manual reloads - still > > > showing days old stats. > > > you think that is fixeable soon, for some value of "soon"? > > > > I don't always have time for Dillo. Maybe this weekend, maybe the next. > > > > This patch (although not up-to-date for current dillo version) has > capability to reload things, when it has been requested with > expires/no-cache/cache-control headers. > > http://www.zone.ee/myzz/dillo/dillo-cache-control.diff > > Since the dillo cache has not changed much lately, it probably applies > with minor conflicts. > > Version for dillo 0.7.3+tabs is part of patch described here: > http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz.html > > But it doesn't make dillo reload images, when reload button has been > pressed. imho mozilla/ie doesn't do it eighter by default (you have to > press shift-reload to make them reload images). Believe it or not I've being reviewing the patch these days and it's in my short-term list of duties! A lot of project managing (meetings, conversations, emails, projection requests, etc, etc, etc.) workload has come my way. I expect to be more coding-active next month. Some very good news may happen. Cross fingers! Jorge.-

Aug. 27, 2003

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

by Madis Janson

On Wed, 27 Aug 2003, Melvin Hadasht wrote: > [Please, as this thread is on the ML, do not mail me personnaly (nor CC me). I'm subscribed to > the list and will respond when I have time and when I have something to respond.] > > Hi, > > > ok, dillo never reloads the images, not even on manual reloads - still > > showing days old stats. > > you think that is fixeable soon, for some value of "soon"? > > I don't always have time for Dillo. Maybe this weekend, maybe the next. > This patch (although not up-to-date for current dillo version) has capability to reload things, when it has been requested with expires/no-cache/cache-control headers. http://www.zone.ee/myzz/dillo/dillo-cache-control.diff Since the dillo cache has not changed much lately, it probably applies with minor conflicts. Version for dillo 0.7.3+tabs is part of patch described here: http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz.html But it doesn't make dillo reload images, when reload button has been pressed. imho mozilla/ie doesn't do it eighter by default (you have to press shift-reload to make them reload images).

Aug. 27, 2003

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

by Melvin Hadasht

[Please, as this thread is on the ML, do not mail me personnaly (nor CC me). I'm subscribed to the list and will respond when I have time and when I have something to respond.] Hi, > ok, dillo never reloads the images, not even on manual reloads - still > showing days old stats. > you think that is fixeable soon, for some value of "soon"? I don't always have time for Dillo. Maybe this weekend, maybe the next. Concerning the reload time, I should be able to fix it when I have time. Concerning the cached images, I will need more time. Concerning the "void" input driver, is the coredump due to my patch? -- Melvin Hadasht

Aug. 27, 2003