Something with the DPI instrastructure needs to be considered - what to do if a plugin needs to prompt the user for some information. The need for this first came about while developping the https plugin - there needs to be a way to prompt the user in the event that the foreign system isn't trusted. This can currently be done through the use of direct calls to Gtk (I assume), but this is not the best result. It requires that everybody who needs to do user prompting write their own dialogs. It creates additional dependancies for the dpis. And it makes code upgrades more difficult - Should Dillo switch to another toolkit in the future for whatever reason (perhaps Gtk2?), all of the DPIs need to be rewritten. And in the event of multiple instances of Dillo running, it becomes impossible to determine which instance the prompt is for. My proposed solution to this problem is to create a new dpi command which is used to prompt the user for what to do. It should allow (require/default?) modal dialog boxes so that the prompt is associated with the Dillo instance the plugin is using. I am suggesting that the dpi command be 'prompt_user'. There would be one manditory field, 'type' which would indicate the type of prompt to use. Example values might be 'dialog' or 'file_save'. These types would be extensible. From there, additional tags would be allocated based on the type of prompt. For example, a 'file_save' prompt might have a default_filename tag. A 'dialog' would likely have a title, a message, and up to 3 button texts. In all cases, the responce should be a dpi message of type 'user_response' with a 'response' tag holding the value of the user input. At least this is my proposal. I'd like some feedback on it, and especially suggestions or better ideas. - Garrett Kajmowicz
Hi Garret, I just finished reading the whole tarball you sent me. It's very interesting. I'm planning to make some modifications on it to provide a generic new API for sending data (I also have a new dpi for file:/, some fixes for buffering in the transfer for bookmarks, some changes to downloads, also to consider cookies and preferences). BTW, with bookmarks I had already changed the data sending routines to provide for streams and flushing. Something like: <q> int send_data_chunk(int OutFD, char *Data, size_t DataSize, int flush); int send_data_string(int OutFD, char *str, int flush); </q> that provides for better tunning from each dpi (e.g. the new bookmarks transfers also run quickly on the 2.6.x series of the linux kernel). The idea of grouping common functions into something like a dpi library was present from a long time ago. This is a good opportunity to start with it. :) I have to think a bit more about the API for data sending. The plan is to have it merged on CVS before Friday. On Mon, 12 Jul 2004, Garrett Kajmowicz wrote:
Something with the DPI instrastructure needs to be considered - what to do if a plugin needs to prompt the user for some information.
Yes, this was considered. ...and it is much like what you describe.
The need for this first came about while developping the https plugin - there needs to be a way to prompt the user in the event that the foreign system isn't trusted.
This can currently be done through the use of direct calls to Gtk (I assume), but this is not the best result. It requires that everybody who needs to do user prompting write their own dialogs. It creates additional dependancies for the dpis. And it makes code upgrades more difficult - Should Dillo switch to another toolkit in the future for whatever reason (perhaps Gtk2?), all of the DPIs need to be rewritten. And in the event of multiple instances of Dillo running, it becomes impossible to determine which instance the prompt is for.
Yes, those are the two possibilities: a) Dialogs through Dillo (using dpip). b) Native dialogs. Currently b) seems inadequate, but for graphical dpis, it's different (for instance the graphical downloads: it's simpler to add "cancel" buttons in the native window). In the case of https, a) looks better.
My proposed solution to this problem is to create a new dpi command which is used to prompt the user for what to do. It should allow (require/default?) modal dialog boxes so that the prompt is associated with the Dillo instance the plugin is using.
I am suggesting that the dpi command be 'prompt_user'. There would be one manditory field, 'type' which would indicate the type of prompt to use. Example values might be 'dialog' or 'file_save'. These types would be extensible.
From there, additional tags would be allocated based on the type of prompt. For example, a 'file_save' prompt might have a default_filename tag. A 'dialog' would likely have a title, a message, and up to 3 button texts.
In all cases, the responce should be a dpi message of type 'user_response' with a 'response' tag holding the value of the user input.
I'll have to search my archives. I'm sure I wrote something about this long ago... AFAIR, there was the "question dialog" with fixed alternatives, and things like that. 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.
At least this is my proposal. I'd like some feedback on it, and especially suggestions or better ideas.
The question dialog through dpip for continuing or aborting over non-verifiable certificates, is the bottle-neck now. I'll start coding it ASAP. Of course it would be very helpful to know in advance the other possible dialogs. To design a good API, that is. Cheers Jorge.-
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
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
[Mon, 12 Jul 2004 09:33:55 -0400] Garrett Kajmowicz <gkajmowi@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
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
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
participants (4)
-
Barry Kauler -
Garrett Kajmowicz -
Jorge Arellano Cid -
Nicolas Pouillon