- Dillo-dev - lists.mailman3.com

Puppy Linux 0.9.1 has Dillo, works fine

by Barry Kauler

Hi guys, Just a comment because I started a thread a little while ago, that never got resolved. The 0.8.x series of Puppy Linux had all the apps compiled against uClibc, which saved about 1M but caused various compatibility problems. One of those was the Dillo plugins not working right. That problem never got resolved, however it is now academic as far as Puppy is concerned, as I recompiled everything against glibc, for Puppy 0.9.0 (using Mandrake 9.2 as the host). Having finished with that, I wish to make one further interesting comment. Puppy is a tiny distro, the live-CD is only 49M, designed to fit on a business-card-size CD, and easily install to usb pen drive or Zip drive. The widget libraries used are only GTK 1.2, Xaw95 and Tk/tix/bwidget. I also installed the gdkxft package, which is a fairly small library that bolts font antialising onto GTK 1.2 apps. I wish to report that it works brilliantly with Dillo. The latest Puppy. v0.9.1, has Dillo with font antialiasing and it sure looks good. Note that one interesting thing about gdkxft, for anyone else interested in trying it, is that it can be applied on a per-application basis, without recompiling the app. You just install libgdkxft.so, then do this when launching Dillo: LD_PRELOAD=/usr/lib/libgdkxft.so dillo There is a config file, /etc/gdkxftrc I think it's called, and all you do is put a single "*" in it, which means apply antialiasing to all fonts. Puppy home page: http://www.goosee.com/puppy News page: http://www.goosee.com/puppy/news.htm Regards, Barry Kauler

July 14, 2004

Re: [Dillo-dev] Puppy Linux 0.9.1 has Dillo, works fine

by Garrett Kajmowicz

> Hi guys, > Just a comment because I started a thread a little while ago, that never > got resolved. > > The 0.8.x series of Puppy Linux had all the apps compiled against uClibc, > which saved about 1M but caused various compatibility problems. > One of those was the Dillo plugins not working right. > > That problem never got resolved, however it is now academic as far as Puppy > is concerned, as I recompiled everything against glibc, for Puppy 0.9.0 > (using Mandrake 9.2 as the host). That is too bad. My development system for Dillo is a chroot environment running off of uClibc. Regular glib and gtk were installed. If you are looking for a good distro to base your Linux distro off of, check out uwoody at www.uclibc.org - Garrett Kajmowicz

July 14, 2004

[Dillo-dev]Re: HTTPS

by Jorge Arellano Cid

Hi Garret, I just finished uploading my patches to the dpis (those that were independent from your code but that required a merge) and the tarball tree you sent me. It comes with some minor modifications ... > Let me know what you think of the coding style, etc. Very clean and compliant with our Naming&Coding in general. I did minor changes, like keeping it inside 80 columns and switching "if(" to "if (" (not a requirement but just to be consistent with the rest of Dillo). Only in one function I needed to reindent to 3 spaces... Unto less trivial stuff, Makefile.am was modified so dpiutil.h gets in the tarball produced with `make dist`. It would be great if you can add some SSL library detection routine to configure.in so https.c uses the no_ssl_support() function when the libarry is not present (or detected). > Also, if you could give me some direction on how to implement the prompt for > unverified certificates (and the code/location to save them to), it would be > greatly appreciated. I'm working on this. Maybe tomorrow... For those that feel curious, you can get the latest CVS and test the new dpis. Just remember to install them after typing make! :-) More seriously, kill dpid and any running dpi before: 'make install' (or 'make install-strip'). Best Jorge.- PS: great start for 0.8.3-pre!

July 13, 2004

Re: Fwd: Re: [Dillo-dev]Plugin infrastructure

by Jorge Arellano Cid

On Mon, 12 Jul 2004, Garrett Kajmowicz wrote: >> In the discussions before introduction of dpi was the point UI could >> entierely be done using standart html, rendered by dillo itself. >> >> Maybe we could use this here. >> >> I would see two (new) dpi commands: >> -Pop a new dillo window (maybe with some args: modal, no toolbar, no >> addressbar..., set its size, url) >> -Make a window reload >> >> So dpi could make a window pop for asking anything about certificates, >> with a standart html form in it. It would allow to change window title >> (through <title>) and make the gui customisable for future needs, and >> even be portable for gtk->other toolkit change. >> >> I thought of the 'reload window' feature not directly for https, but for >> download dpi. This would allow us to update the status of current >> downloads; shown in a dedicated window, somewhat ala Firefox, but again, >> entierely in html. Yes Nicolas, the html interface is an important part of the dpip feature set. Now, each dpi is different and that's why flexibility is important. I mean, for bookmarks and preferences (and probably for general purpose applications like the dillo-based control center of DSL linux), HTML is perfect. For the downloads, a native GUI inside the dpi, is an easier approach, and in the https case, dialog windows through Dillo by means of a dpip request seem to be the most adequate. > > That is very interesting, but causes two problems. First of all, from what I > have seen , it looks like it would be difficult to implement modal dialog > boxes. This is important for security warnings so that they are not hidden > or confused with other Dillo warnings. > > Secondly, this approach causes some problems. I am approaching this from the > perspective of the https filter dpi, but I assume that the same problem would > apply to any other related dpi. > > Firstly, a filter dpi runs in its own process for each call, not as a server. > Thus every time a call is made to the https filter dpi, it runs in its > entirety. This makes it difficult to handle a response from the user because > the dpi is then required to write a web server capable of at the very least > parsing http GET requests, which means opening up a socket and so forth. > Needless to say, handling that is somewhat of a challenge from a filter dpi > perspective. > > Secondly, for the https application, cookie/post/get datais likely to be > sent, which means that any rerequest would have to be able to pass that data > on exactly. > > Third, the https verification needs to be done after the ssl session is > estabilshed, but before the http request is made (for security reasons). > Thus any complicated scheme could result in multiple connections being made. > > Fourthly, I don't like it. That's the most important one of all :-) It's important to notice that coding the https dpi as a server (instead of a filter) has some advantages. BTW, this is what we have in mind with Madis. A server https dpi can more easily manage session caching and certificate management (remembering, saving, loading, ...). A single instance that forks or launches threads to do the work while keeping a common central management. BTW, we agree that implementing and testing with a filter dpi before turning it into a server dpi is a good approach. > > The html prompt window isn't a bad idea, but causes a lot of coding headaches > on the dpi other end. But that's just my thought. If you think that an > html prompt window would work, I'd appreciate a modified "hello" filter dpi > as an example from which I could implement the required code. In this case we'll try the dialog window with dpip... I foresee this tasks (by my side): 1.- Merge the https into the CVS so you can sync from there. 2.- implement a dpip command to provide for a simple dialog. (so handle_certificate_problem() can be filled in). 3.- Polish the common API for developing dpis and adjust the dpi set to the new functions. 4.- Implement a dpip_build_command() function into the lib and make the dpi set use it. 5.- Merge my new patches for bookmarks, downloads, and interface inside dillo. 6.- Review the file dpi. I hope to have this done and uploaded by Friday (1 to 5). Now, only 1.- and 2.- constitute a bottle neck for https, so I'll try to push them first (hopefully by Wednesday). The idea is to remove the bottleneck so you can keep on working and testing the https dpi. Cheers Jorge.-

July 13, 2004

[Dillo-dev]0.8.2 - No PNG support, but config cound PNG available (attachment)

by Geek

Hi, I just compiled and installed 0.8.2 on my Debian stable and gave it a shakedown. It doesn't display PNG images. 0.8.1 and earlier, no problems. I have attached the config.log file Thanks for any assistance. -- Gregg t3h g33k http://geek.scorpiorising.ca

July 13, 2004

RE: [Dillo-dev]Plugin infrastructure

by Eric Gaudet

Dillo's html rendering capabilities are what we should use for advanced forms. We don't want to duplicate the form widgets into a native-gtk version like mozilla does with xul. The pageflow, the forms, images etc ought to be in html, even if it's a dpi serving them. Having a login/password modal box seems to be what people are used to, so I can see why we'd like to have that. I can imagine dpis other than https needing a login/password box, but I'm not sure I can imagine that for non-login purposes. In any case, anything more complicated than one string, one or two text boxes with lables (possibly hidden for passwords) and 1 or 2 buttons certainly belongs to a dedicated html page the dpi would build. I could live with an intermediate html login page for https or any other dpi myself. Best, EG > -----Original Message----- > From: dillo-dev-admin(a)auriga.wearlab.de > [mailto:dillo-dev-admin@auriga.wearlab.de] On Behalf Of > Garrett Kajmowicz > Sent: Monday, July 12, 2004 3:26 PM > To: dillo-dev(a)auriga.wearlab.de > Subject: Re: [Dillo-dev]Plugin infrastructure > > > I just came up with two other dialog box types we might need: > > A window with alterable caption/message text and either one > or two text boxes > with associated labels. One or both of the boxes should be > able to be set in > "password" mode. > > I'm not sure if that counts as one or two, so I'm inflating > my estimates to > look more impressive :-) > > - Garrett Kajmowicz > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-> bin/mailman/listinfo/dillo-dev > >

July 12, 2004

Re: [Dillo-dev]Plugin infrastructure

by Nicolas Pouillon

[Mon, 12 Jul 2004 09:33:55 -0400] Garrett Kajmowicz <gkajmowi(a)tbaytel.net> eut le bonheur d'écrire: > Something with the DPI instrastructure needs to be considered - what > to do if a plugin needs to prompt the user for some information. [...] In the discussions before introduction of dpi was the point UI could entierely be done using standart html, rendered by dillo itself. Maybe we could use this here. I would see two (new) dpi commands: -Pop a new dillo window (maybe with some args: modal, no toolbar, no addressbar..., set its size, url) -Make a window reload So dpi could make a window pop for asking anything about certificates, with a standart html form in it. It would allow to change window title (through <title>) and make the gui customisable for future needs, and even be portable for gtk->other toolkit change. I thought of the 'reload window' feature not directly for https, but for download dpi. This would allow us to update the status of current downloads; shown in a dedicated window, somewhat ala Firefox, but again, entierely in html. -- Nipo

July 12, 2004

Re: [Dillo-dev]Plugin infrastructure

by Garrett Kajmowicz

I just came up with two other dialog box types we might need: A window with alterable caption/message text and either one or two text boxes with associated labels. One or both of the boxes should be able to be set in "password" mode. I'm not sure if that counts as one or two, so I'm inflating my estimates to look more impressive :-) - Garrett Kajmowicz

July 12, 2004

Fwd: Re: [Dillo-dev]Plugin infrastructure

by Garrett Kajmowicz

> In the discussions before introduction of dpi was the point UI could > entierely be done using standart html, rendered by dillo itself. > > Maybe we could use this here. > > I would see two (new) dpi commands: > -Pop a new dillo window (maybe with some args: modal, no toolbar, no > addressbar..., set its size, url) > -Make a window reload > > So dpi could make a window pop for asking anything about certificates, > with a standart html form in it. It would allow to change window title > (through <title>) and make the gui customisable for future needs, and > even be portable for gtk->other toolkit change. > > I thought of the 'reload window' feature not directly for https, but for > download dpi. This would allow us to update the status of current > downloads; shown in a dedicated window, somewhat ala Firefox, but again, > entierely in html. That is very interesting, but causes two problems. First of all, from what I have seen , it looks like it would be difficult to implement modal dialog boxes. This is important for security warnings so that they are not hidden or confused with other Dillo warnings. Secondly, this approach causes some problems. I am approaching this from the perspective of the https filter dpi, but I assume that the same problem would apply to any other related dpi. Firstly, a filter dpi runs in its own process for each call, not as a server. Thus every time a call is made to the https filter dpi, it runs in its entirety. This makes it difficult to handle a response from the user because the dpi is then required to write a web server capable of at the very least parsing http GET requests, which means opening up a socket and so forth. Needless to say, handling that is somewhat of a challenge from a filter dpi perspective. Secondly, for the https application, cookie/post/get datais likely to be sent, which means that any rerequest would have to be able to pass that data on exactly. Third, the https verification needs to be done after the ssl session is estabilshed, but before the http request is made (for security reasons). Thus any complicated scheme could result in multiple connections being made. Fourthly, I don't like it. That's the most important one of all :-) The html prompt window isn't a bad idea, but causes a lot of coding headaches on the dpi other end. But that's just my thought. If you think that an html prompt window would work, I'd appreciate a modified "hello" filter dpi as an example from which I could implement the required code. Thanks for the feedback - Garrett Kajmowicz -------------------------------------------------------

July 12, 2004

Re: [Dillo-dev]Plugin infrastructure

by Garrett Kajmowicz

> In the https case, it seems we only need (by now) a yes/no > answer for a certificate that can't be verified. > > Please send me the list for all the question/generic dialogs > you foresee. > If we are going to allow dialogs we need to have something generic enough that developers will not feel straightjacketed, which concrete enough that it isn't a nightmare to implement. Ideally it will not be tied to the underlying widget library so that we can switch widget libraries(if need be) without having to rewrite plugins in the future. There are a few dialog types that I see as being useful. The first is the file save-as dialog. This might simplify some of the FTP code (I haven't looked at the core app side of things). Next, a generic dialog which supports a custom message, as well as customizable text on up to three buttons. Custom caption for the window is nice. I think we can assume that it's a modal dialog box. This will allow the programmer to deal with almost any situation needed. In the https example, consider the options of: trusting indefinitely, trusting for this connection only, or refusing the connection. That requires three buttons. The indefinite trust is required to deal with self-signed sites that we don't want to have to click "yes" to for every file. These are the two which come to mind immediately. I would avoid limiting the possabilities so that when we come up with something we had not anticipated we will not run into any problems. > The question dialog through dpip for continuing or aborting > over non-verifiable certificates, is the bottle-neck now. I'll > start coding it ASAP. Thanks. Please let me know what you are doing so that I can follow everything. This will make it easier for me to contribute. You noted that you had made some changes to what I sent you. Have you commited the changed to CVS? If so, I'll blow away my current tarball tree and pull everything down from CVS. If not, please let me know where you are going so I can adjust my development accordingly. Thanks. - Garrett Kajmowicz

July 12, 2004