- Dillo-dev - lists.mailman3.com

[jcid@dillo.org: CSS merge looks great!]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Nov. 21, 2008

a list of what dillo2 runs on

by corvid＠lavabit.com

Jorge wrote: > I'm thinking in the "inbuf_t" wrongly detected for a BSD flavour, > that has a patch in CVS, and AFAIR hasn't been acknowledged to work yet. I think it was gentoo that was having an inbuf_t detection problem.

Nov. 20, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by onepoint＠starurchin.org

On Thu, Nov 20, 2008 at 09:14:56AM -0300, Jorge Arellano Cid wrote: > On Thu, Nov 20, 2008 at 02:42:19AM +0000, Jeremy Henty wrote: > > > > Is this a good way to do it or is there a smarter way? All > > comments and advice are welcome. > > It looks OK. Good! > I wonder why a dpi is deemed necessary for this. I don't know whether it is necessary. That's why I asked for comments. I just thought that HTTP authentication looked rather "cookie-ish" and decided to copy and modify the cookies implementation. I'm new to this part of Dillo so I am following established practice. I already have a dummy auth dpi running and hooked into the main Dillo program, so I think that the dpi part of things is by far the easiest bit. The most work is actually implementing authentication! > Isn't an implementation of a_Dialog_user_passwd() enough to solve > it? It certainly appears to be the missing link, in the sense that everything else that authentication needs is the kind of thing that the cookies dpi already does and therefore counts as a solved problem already. I plan to continue with the dpi-based implementation on the grounds that the biggest part of the task is implementing authentication and a_Dialog_user_passwd(), and that code will not depend on whether we do authentication in the dillo main program or a dpi. If we decide to move authentication out of the dpi and into dillo itself then I will just move the authentication code around and delete some dpi wrapper code, which won't be much work. At least that's how I expect it will work. Stay tuned, and please comment further. Jeremy Henty

Nov. 20, 2008

a list of what dillo2 runs on

by ljmoore＠wightman.ca

On Thu, Nov 20, 2008 at 09:12:35AM -0300, Jorge Arellano Cid wrote: > On Wed, Nov 19, 2008 at 08:01:49PM -0500, Larry Moore wrote: > > My system isn't representative of any mainstream (debian on a m68k ) but > > will download from cvs, compile and soforth when prompted. > > What system do you have? > > I'm thinking in the "inbuf_t" wrongly detected for a BSD flavour, > that has a patch in CVS, and AFAIR hasn't been acknowledged to work yet. > > -- > Cheers > Jorge.- It's a Macintosh Quadra 610 which has been running debian since the woody release At the moment, the unofficial etch-m68k with some lenny packages. As I said, rather non-standard. -- "I don't think I've found God, but I may have seen where gods come from." Terry Pratchett

Nov. 20, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by jcid＠dillo.org

On Thu, Nov 20, 2008 at 02:42:19AM +0000, Jeremy Henty wrote: > > I'm implementing an HTTP AUTH dpi (based on the cookies dpi) and I'd > appreciate comments on how I'm doing it. > > (Motivation: (a) I'm tired of the irony of having to use Firefox to > log on to the FLTK Trac Wiki to update the Dillo page, (b) this will > be a useful primer for hacking on the https dpi.) > > The problem is that the dpi must prompt the user for a username and > password but src/dialog.cc only supports dialogs that present a choice > of buttons. > > I think I'll have to add a_Dialog_user_passwd() to src/dialog.cc to > create a modal dialog, return the clicked button and write the > contents of the dialog entries into a struct. Then I can add a > wrapper for it to src/dpiapi.c and hook it into a_Capi_ccc(). That > will let the dpi query the user. > > Is this a good way to do it or is there a smarter way? All comments > and advice are welcome. It looks OK. I wonder why a dpi is deemed necessary for this. Isn't an implementation of a_Dialog_user_passwd() enough to solve it? -- Cheers Jorge.-

Nov. 20, 2008

a list of what dillo2 runs on

by jcid＠dillo.org

On Wed, Nov 19, 2008 at 08:01:49PM -0500, Larry Moore wrote: > On Tue, Aug 26, 2008 at 05:52:43PM +0000, corvid wrote: > > Christopher Illies wrote: > > > On Mon, Aug 25, 2008 at 04:14:34PM +0000, corvid wrote: > > > > I wonder whether we could get someone for each system who > > > > would have the responsibility (or, let's say "_glory_" :) > > > > of responding to "Hey, we changed [some configuration stuff] > > > > in the latest CVS. Does it work fine on your system?" messages. > > > > > > I can take that part for FreeBSD for now and will respond when such > > > messages are posted to this list. Also, I can do a fresh compile every > > > two weeks or so. > > > > Cool! > > > > > My system isn't representative of any mainstream (debian on a m68k ) but > will download from cvs, compile and soforth when prompted. What system do you have? I'm thinking in the "inbuf_t" wrongly detected for a BSD flavour, that has a patch in CVS, and AFAIR hasn't been acknowledged to work yet. -- Cheers Jorge.-

Nov. 20, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by onepoint＠starurchin.org

I'm implementing an HTTP AUTH dpi (based on the cookies dpi) and I'd appreciate comments on how I'm doing it. (Motivation: (a) I'm tired of the irony of having to use Firefox to log on to the FLTK Trac Wiki to update the Dillo page, (b) this will be a useful primer for hacking on the https dpi.) The problem is that the dpi must prompt the user for a username and password but src/dialog.cc only supports dialogs that present a choice of buttons. I think I'll have to add a_Dialog_user_passwd() to src/dialog.cc to create a modal dialog, return the clicked button and write the contents of the dialog entries into a struct. Then I can add a wrapper for it to src/dpiapi.c and hook it into a_Capi_ccc(). That will let the dpi query the user. Is this a good way to do it or is there a smarter way? All comments and advice are welcome. Regards, Jeremy Henty

Nov. 20, 2008

a list of what dillo2 runs on

by ljmoore＠wightman.ca

On Tue, Aug 26, 2008 at 05:52:43PM +0000, corvid wrote: > Christopher Illies wrote: > > On Mon, Aug 25, 2008 at 04:14:34PM +0000, corvid wrote: > > > I wonder whether we could get someone for each system who > > > would have the responsibility (or, let's say "_glory_" :) > > > of responding to "Hey, we changed [some configuration stuff] > > > in the latest CVS. Does it work fine on your system?" messages. > > > > I can take that part for FreeBSD for now and will respond when such > > messages are posted to this list. Also, I can do a fresh compile every > > two weeks or so. > > Cool! > > My system isn't representative of any mainstream (debian on a m68k ) but will download from cvs, compile and soforth when prompted. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- People who think they know everything are a great annoyance to those of us who do. Isaac Asimov

Nov. 20, 2008

Feature Request

by jcid＠dillo.org

On Tue, Nov 18, 2008 at 10:32:13AM -0500, me at swva wrote: > On Tue, 18 Nov 2008, Jorge Arellano Cid wrote: > >> >> On Fri, Nov 14, 2008 at 01:21:17PM -0500, me at swva wrote: >>>> >>>> The URL viewer is taken from .mailcap. When set properly, it >>>> works (at least here it works with Ubuntu 8.04.1, so it's not an >>>> alpine issue). >>> >>> OK, good; but you're over my head. I don't find anything named >>> .mailcap on my machine. Neither does my search function. >>> >>> Since I've been running Pine for years, I have a .pinerc rather >>> than an .alpinerc; but I don't find anything like what you say there, >>> either. >> >> You can create it in your home account. >> >> nano -w ~/.mailcap >> >> then put the long line there, and see what happens. > > I did, and it didn't; but I may have the long line wrong, since it's > formatted into two here. I tried it (on my own machine here, not the > remote one yet) both with and without a space between the backslash and > "test=test" (having done c&p on the two pieces). Are there really > supposed to be two spaces between the last semicolon and "nametemplate"? The backslash doesn't go in the line. It's a convention to mark a single line when split in two. The .mailcap should go in the same machine where alpine runs. -- Cheers Jorge.-

Nov. 18, 2008

Feature Request

by Beartooth＠swva.net

On Tue, 18 Nov 2008, Jorge Arellano Cid wrote: > > On Fri, Nov 14, 2008 at 01:21:17PM -0500, me at swva wrote: >>> >>> The URL viewer is taken from .mailcap. When set properly, it >>> works (at least here it works with Ubuntu 8.04.1, so it's not an >>> alpine issue). >> >> OK, good; but you're over my head. I don't find anything >> named .mailcap on my machine. Neither does my search function. >> >> Since I've been running Pine for years, I have a .pinerc >> rather than an .alpinerc; but I don't find anything like what you >> say there, either. > > You can create it in your home account. > > nano -w ~/.mailcap > > then put the long line there, and see what happens. I did, and it didn't; but I may have the long line wrong, since it's formatted into two here. I tried it (on my own machine here, not the remote one yet) both with and without a space between the backslash and "test=test" (having done c&p on the two pieces). Are there really supposed to be two spaces between the last semicolon and "nametemplate"? >>> If you have something like this in your mailcap: >>> (all in one line) >>> >>> text/html; /usr/local/bin/dillo -l -f '%s'; description=HTML Text; \ >>> test=test -n "$DISPLAY"; nametemplate=%s.html >>> >>> it works with dillo1. >> >> About now, I should probably mention that I do my email >> different ways from different addresses. The main one is remote. >> It does open links that include "http://" -- in dillo *here*, not >> on the remote machine -- but not ones without. The same is also >> true when I run Alpine against the address I'm using at this >> moment. > > Probably you use something like: > > ssh -X <remote_machine> > > it should work OK. > I'll try that next. >>> Something like: >>> >>> text/html; /usr/local/bin/dillo -l -f -x XID '%s'; description=HTML Text; \ >>> test=test -n "$DISPLAY"; nametemplate=%s.html >> >> I'm guessing that I should c&p that into my .pinerc >> somewhere, or into the interface Alpine gives me by typing M > S >> > C (Main menu to Setup to Configure); but I don't know where. [....] >> Now you're way to Helen Gone over my head. Sorry. > > Never mind, just try the .mailcap suggestion above. -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

Nov. 18, 2008