- Dillo-dev - lists.mailman3.com

A Dillo-Win32 update

by obeythepenguin＠gmail.com

On Sat, 02 Oct 2010 15:27:30 -0400, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > I like them and actually there is no way around it. One great > feature of dillo is that you can fire up multiple processes very > fast and still have access to the same bookmarks and cookies. (1) Can't that be implemented without a separate server process? (2) Is there any reason to run multiple Dillo processes, anyway? (3) How does that affect other protocols (FTP, HTTPS, local file browsing?) >> >>On a related note, is there any reason not to cut DPI out of the >> >>download system, i.e. just invoke a separate downloader process >> >>directly? I'm considering implementing that at least as a temporary >> >>solution, using my own self-contained download tool. >> > >> > The default downloader is a separate process. Before it, we >> >used a call to wget from a separate process too. You're welcomed >> >to hook your own preferred application, that's the idea of dpi. >> >> Well, I meant that more in the sense of "since the downloader's a >> separate process anyway, why go through DPI at all?" > > Well, we have all the infrastucture for DPI already, why use a new > mechanism? What's the advantage to doing it through DPI, besides that the infrastructure's already there? Despite its perceived redundancy, my mechanism is ultimately simpler, since there's no interprocess communication involved. It's also a bit more efficient, since it cuts out the middleman (dpid). I think, by the way, there *are* clear advantages to a separate downloader: among other things, it allows downloads to continue after the user exits the browser. On the other hand, I don't see why the user would need cookies after the browser has exited. >> >>Or is something more passed through than just a URL? >> > >> > Maybe the target directory&savename. I don't remember well... >> >You can make the dpip functions log the messages to a file >> >without much hassle, and see what actually happens. >> >> I wrote my own downloader, and patched Dillo so it calls my program >> directly, bypassing DPI. (It also bypasses the Dillo file dialogs, >> since my program displays its own.) So far everything seems to be >> working nicely. >> >> I've only implemented the patch for Windows so far, and it needs a >> bit of cleanup, but if you're curious you can see it here: >> http://dillo-win32.sourceforge.net/files/dillo-r1705-dlgui-20100930.diff >> >> and the downloader itself: >> http://dillo-win32.sourceforge.net/dlgui.html >> >> I'm tempted to port Dillo to libcurl now, since it works so nicely >> in my own program, and seems like it would be much more portable >> (and stable, on Windows) than the current implementation. It would >> also allow for easier implementation of other protocols, like HTTPS >> and FTP. Any thoughts? > > Hm, sounds like a massive change in a core component, but feel free to > experiment. Well, I've already done one of those with dsock, so why not another? :-) ~Benjamin

Oct. 2, 2010

A Dillo-Win32 update

by Johannes.Hofmann＠gmx.de

Hi Benjamin, On Sat, Oct 02, 2010 at 02:48:06PM -0400, Benjamin Johnson wrote: > I meant to reply sooner, and got sidetracked with other things... > > On Thu, 30 Sep 2010 07:28:39 -0400, Jorge Arellano Cid > <jcid(a)dillo.org> wrote: > > >On Wed, Sep 29, 2010 at 10:57:30PM -0400, Benjamin Johnson wrote: > >>On Wed, 29 Sep 2010 21:22:43 -0400, Jorge Arellano Cid > >><jcid(a)dillo.org> wrote: > >> > >>> The dpi framework works with isolated processes. A third option > >>>could be to make an alternative implementation that works in Win. > >>>For instance, is there a dbus port running in Win*? > >>> > >> > >>There is, although I have a couple reservations. I'm not sure how > >>cleanly it could be packaged, or whether it would run on Windows 9x > >>(one of my goals is to support all the way back to Windows 95). I > >>also have some personal dislike for it, after dealing with much > >>dbus-related breakage in my Linux development days. > >> > >>I do appreciate the suggestion, though, and if you think it could > >>work, I will certainly look into it. > > > > I haven't used dbus, but it's used in GNU/Linux by some big > >players so I guess it stabilized [1]. Any inter process message- > >passing lib will work, but implementing it well is a hard task, > >that's why I suggested dbus (it has undergone lots of testing). > >Probably there's a better candidate in the embedded area. > > > >[1] http://www.freedesktop.org/wiki/Software/DbusProjects > > My problem with dbus isn't so much stability, as complexity. It's > been a while since I've run Linux, but I vaguely remember dbus's > internal security/permissions were a nightmare. I also vote against dbus. It would be a new dependency and the size of the dbus tarball is currently more than twice the size of dillo-2.2.tar.bz2! > > I'll admit, I'm not the biggest fan of DPI anyway -- relying on > complex interprocess communication even for such simple things as > local file browsing seems like more trouble than it's worth. It's > better than the other way around, re-implementing operating system > functionality inside the browser (as a certain search giant has), > but I'm not yet convinced the advantages truly outweigh the > implementation hassles. I like them and actually there is no way around it. One great feature of dillo is that you can fire up multiple processes very fast and still have access to the same bookmarks and cookies. > > >>On a related note, is there any reason not to cut DPI out of the > >>download system, i.e. just invoke a separate downloader process > >>directly? I'm considering implementing that at least as a temporary > >>solution, using my own self-contained download tool. > > > > The default downloader is a separate process. Before it, we > >used a call to wget from a separate process too. You're welcomed > >to hook your own preferred application, that's the idea of dpi. > > Well, I meant that more in the sense of "since the downloader's a > separate process anyway, why go through DPI at all?" Well, we have all the infrastucture for DPI already, why use a new mechanism? > > >>Or is something more passed through than just a URL? > > > > Maybe the target directory&savename. I don't remember well... > >You can make the dpip functions log the messages to a file > >without much hassle, and see what actually happens. > > I wrote my own downloader, and patched Dillo so it calls my program > directly, bypassing DPI. (It also bypasses the Dillo file dialogs, > since my program displays its own.) So far everything seems to be > working nicely. > > I've only implemented the patch for Windows so far, and it needs a > bit of cleanup, but if you're curious you can see it here: > http://dillo-win32.sourceforge.net/files/dillo-r1705-dlgui-20100930.diff > > and the downloader itself: > http://dillo-win32.sourceforge.net/dlgui.html > > I'm tempted to port Dillo to libcurl now, since it works so nicely > in my own program, and seems like it would be much more portable > (and stable, on Windows) than the current implementation. It would > also allow for easier implementation of other protocols, like HTTPS > and FTP. Any thoughts? Hm, sounds like a massive change in a core component, but feel free to experiment. Cheers, Johannes

Oct. 2, 2010

A Dillo-Win32 update

by obeythepenguin＠gmail.com

I meant to reply sooner, and got sidetracked with other things... On Thu, 30 Sep 2010 07:28:39 -0400, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Wed, Sep 29, 2010 at 10:57:30PM -0400, Benjamin Johnson wrote: >> On Wed, 29 Sep 2010 21:22:43 -0400, Jorge Arellano Cid >> <jcid(a)dillo.org> wrote: >> >> > The dpi framework works with isolated processes. A third option >> >could be to make an alternative implementation that works in Win. >> >For instance, is there a dbus port running in Win*? >> > >> >> There is, although I have a couple reservations. I'm not sure how >> cleanly it could be packaged, or whether it would run on Windows 9x >> (one of my goals is to support all the way back to Windows 95). I >> also have some personal dislike for it, after dealing with much >> dbus-related breakage in my Linux development days. >> >> I do appreciate the suggestion, though, and if you think it could >> work, I will certainly look into it. > > I haven't used dbus, but it's used in GNU/Linux by some big > players so I guess it stabilized [1]. Any inter process message- > passing lib will work, but implementing it well is a hard task, > that's why I suggested dbus (it has undergone lots of testing). > Probably there's a better candidate in the embedded area. > > [1] http://www.freedesktop.org/wiki/Software/DbusProjects My problem with dbus isn't so much stability, as complexity. It's been a while since I've run Linux, but I vaguely remember dbus's internal security/permissions were a nightmare. I'll admit, I'm not the biggest fan of DPI anyway -- relying on complex interprocess communication even for such simple things as local file browsing seems like more trouble than it's worth. It's better than the other way around, re-implementing operating system functionality inside the browser (as a certain search giant has), but I'm not yet convinced the advantages truly outweigh the implementation hassles. >> On a related note, is there any reason not to cut DPI out of the >> download system, i.e. just invoke a separate downloader process >> directly? I'm considering implementing that at least as a temporary >> solution, using my own self-contained download tool. > > The default downloader is a separate process. Before it, we > used a call to wget from a separate process too. You're welcomed > to hook your own preferred application, that's the idea of dpi. Well, I meant that more in the sense of "since the downloader's a separate process anyway, why go through DPI at all?" >> Or is something more passed through than just a URL? > > Maybe the target directory&savename. I don't remember well... > You can make the dpip functions log the messages to a file > without much hassle, and see what actually happens. I wrote my own downloader, and patched Dillo so it calls my program directly, bypassing DPI. (It also bypasses the Dillo file dialogs, since my program displays its own.) So far everything seems to be working nicely. I've only implemented the patch for Windows so far, and it needs a bit of cleanup, but if you're curious you can see it here: http://dillo-win32.sourceforge.net/files/dillo-r1705-dlgui-20100930.diff and the downloader itself: http://dillo-win32.sourceforge.net/dlgui.html I'm tempted to port Dillo to libcurl now, since it works so nicely in my own program, and seems like it would be much more portable (and stable, on Windows) than the current implementation. It would also allow for easier implementation of other protocols, like HTTPS and FTP. Any thoughts? ~Benjamin

Oct. 2, 2010

A Dillo-Win32 update

by jcid＠dillo.org

On Wed, Sep 29, 2010 at 10:57:30PM -0400, Benjamin Johnson wrote: > On Wed, 29 Sep 2010 21:22:43 -0400, Jorge Arellano Cid > <jcid(a)dillo.org> wrote: > > > The dpi framework works with isolated processes. A third option > >could be to make an alternative implementation that works in Win. > >For instance, is there a dbus port running in Win*? > > > > There is, although I have a couple reservations. I'm not sure how > cleanly it could be packaged, or whether it would run on Windows 9x > (one of my goals is to support all the way back to Windows 95). I > also have some personal dislike for it, after dealing with much > dbus-related breakage in my Linux development days. > > I do appreciate the suggestion, though, and if you think it could > work, I will certainly look into it. I haven't used dbus, but it's used in GNU/Linux by some big players so I guess it stabilized [1]. Any inter process message- passing lib will work, but implementing it well is a hard task, that's why I suggested dbus (it has undergone lots of testing). Probably there's a better candidate in the embedded area. [1] http://www.freedesktop.org/wiki/Software/DbusProjects > On a related note, is there any reason not to cut DPI out of the > download system, i.e. just invoke a separate downloader process > directly? I'm considering implementing that at least as a temporary > solution, using my own self-contained download tool. The default downloader is a separate process. Before it, we used a call to wget from a separate process too. You're welcomed to hook your own preferred application, that's the idea of dpi. > Or is something more passed through than just a URL? Maybe the target directory&savename. I don't remember well... You can make the dpip functions log the messages to a file without much hassle, and see what actually happens. -- Cheers Jorge.-

Sept. 30, 2010

A Dillo-Win32 update

by obeythepenguin＠gmail.com

On Wed, 29 Sep 2010 21:22:43 -0400, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > The dpi framework works with isolated processes. A third option > could be to make an alternative implementation that works in Win. > For instance, is there a dbus port running in Win*? > There is, although I have a couple reservations. I'm not sure how cleanly it could be packaged, or whether it would run on Windows 9x (one of my goals is to support all the way back to Windows 95). I also have some personal dislike for it, after dealing with much dbus-related breakage in my Linux development days. I do appreciate the suggestion, though, and if you think it could work, I will certainly look into it. On a related note, is there any reason not to cut DPI out of the download system, i.e. just invoke a separate downloader process directly? I'm considering implementing that at least as a temporary solution, using my own self-contained download tool. Or is something more passed through than just a URL? Thanks again, ~Benjamin

Sept. 30, 2010

A Dillo-Win32 update

by jcid＠dillo.org

On Wed, Sep 29, 2010 at 04:51:27PM -0400, Benjamin Johnson wrote: > The browser patch is about as stable as I can get it, so I thought > I'd send it in for your consideration. First the patch, then my > comments: > > http://dillo-win32.sourceforge.net/files/dillo-r1705-win32-20100913-merge.d… > > I'd consider this "merge-ready" in terms of completeness, though I > haven't much tested stability, and I'd need your opinion on coding > style. This is a long patch (~1740 lines), with a lot of separate > but closely-interconnected changes. I'd split it into smaller > subpatches, but I'm not really sure how practical (or possible) that > would be, so my apologies in advance for the length. > > I've run into a major impasse with DPI. Simply put, DPI is not > portable to non-Unix systems. Specifically, there are two main > problems as far as Windows is concerned: (1) lack of Unix signals, > and (2) non-interchangeability of file and socket descriptors. > Since I'm aiming for a native port, an emulation layer such as > Cygwin is absolutely not an option. > > I'm faced with a bit of a dilemma here. The two options I see are > to either redesign DPI, or ditch it altogether; and I don't think > anyone is too keen on either idea. I've considered a fork, but I'm > opposed to the idea on both practical and philosophical grounds (my > goal's to help, not to hurt upstream). Any suggestions? The dpi framework works with isolated processes. A third option could be to make an alternative implementation that works in Win. For instance, is there a dbus port running in Win*? -- Cheers Jorge.-

Sept. 30, 2010

A Dillo-Win32 update

by obeythepenguin＠gmail.com

The browser patch is about as stable as I can get it, so I thought I'd send it in for your consideration. First the patch, then my comments: http://dillo-win32.sourceforge.net/files/dillo-r1705-win32-20100913-merge.d… I'd consider this "merge-ready" in terms of completeness, though I haven't much tested stability, and I'd need your opinion on coding style. This is a long patch (~1740 lines), with a lot of separate but closely-interconnected changes. I'd split it into smaller subpatches, but I'm not really sure how practical (or possible) that would be, so my apologies in advance for the length. I've run into a major impasse with DPI. Simply put, DPI is not portable to non-Unix systems. Specifically, there are two main problems as far as Windows is concerned: (1) lack of Unix signals, and (2) non-interchangeability of file and socket descriptors. Since I'm aiming for a native port, an emulation layer such as Cygwin is absolutely not an option. I'm faced with a bit of a dilemma here. The two options I see are to either redesign DPI, or ditch it altogether; and I don't think anyone is too keen on either idea. I've considered a fork, but I'm opposed to the idea on both practical and philosophical grounds (my goal's to help, not to hurt upstream). Any suggestions? Thanks & cheers, ~Benjamin

Sept. 29, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

yOn Sun, Sep 26, 2010 at 12:04:06AM +0000, corvid wrote: > Johannes wrote: > > Ok here http://flpsed.org/tmp/html_element_style.diff is the updated > > patch. It brings back the bg_color dillorc option. Please give it a try. > > I'm getting an assertion failure with: > > <html> > <head> > <head> > </head> > <body> > </body> > </html> Oh, good point. This needs some thought...

Sept. 26, 2010

[bug]: ignored CSS attributes on html element

by corvid＠lavabit.com

Johannes wrote: > Ok here http://flpsed.org/tmp/html_element_style.diff is the updated > patch. It brings back the bg_color dillorc option. Please give it a try. I'm getting an assertion failure with: <html> <head> <head> </head> <body> </body> </html>

Sept. 26, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

On Tue, Sep 21, 2010 at 10:20:27PM +0200, Johannes Hofmann wrote: > On Tue, Sep 21, 2010 at 01:39:47PM -0400, Jorge Arellano Cid wrote: > > On Sun, Sep 19, 2010 at 08:51:25PM +0200, Johannes Hofmann wrote: > > > On Sat, Sep 18, 2010 at 10:06:54PM -0400, Jorge Arellano Cid wrote: > > > > On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote: > > > > > On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote: > > > > > > Johannes wrote: > > > > > > > Please test attached patch. It is a bit more involved than I had > > > > > > > hoped, but it seems necessary after looking at the spec. > > > > > > > > > > > > en.wikipedia (with remote css off) gives me > > > > > > "** WARNING **: No background color found!" msgs. > > > > > > > > > > > > > > > > Yes, I think this is because I had to remove the > > > > > background-color property from the user-agent style in css.cc. > > > > > It's a bit weird: > > > > > The spec says, that the canvas color should either be the background color > > > > > assigned to the <html> tag, or if that has no background color, it > > > > > should be the background color of the <body> tag. > > > > > So we can't no longer set a background color in the user-agent > > > > > style. > > > > > If we assign it to the <html> tag, we will see a weird frame if page > > > > > authors set a background-color on the <body> tag. > > > > > If we assign it to the <body> tag, pages that set the > > > > > background-color for the <html> tag will have a frame. > > > > > > > > > > So maybe we need to reintroduce the bg_color dillorc option to set a > > > > > background-color if the page has no background-color on neither the > > > > > <html> nor the <body> tag. > > > > > Opinions? > > > > > > > > Can't we set both <html> and <body> ? > > > > > > Unfortunately no. > > > If we do that and the page sets background-color for body, we would > > > have a frame with our background-color and a box (for <body>) with > > > the background-color defined in the page. > > > Also if the page sets a background-color for <html>, we have a frame > > > with the pages background-color and a box with our color. > > > > I see... > > > > IMHO, having just one place for setting the appearance is an > > important asset (simplicity/orthogonality). > > > > If we can keep this feature without introducing an ugly hack > > I'd go for it. Now, as you know much better the implementation > > details, I leave it for you to decide. > > I fully agree, but currently I don't see any way to set the > background color from the user-agent-, or user-stylesheet such that it > works for pages that set background-color on the <html> element and > for pages that set background-color on the <body> element. > > I will prepare the patch and sleep some nights over it. Then we can > decide whether we commit it. Ok here http://flpsed.org/tmp/html_element_style.diff is the updated patch. It brings back the bg_color dillorc option. Please give it a try. Cheers, Johannes

Sept. 25, 2010