Search results for "plugin" - Dillo-dev

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

20 years, 4 months

[Dillo-dev]Dillo on Cygwin

by Kelson Vibber

A few days ago I noticed that GTK+ and GLib are now available through the Cygwin installer, so I started reworking my directions for building Dillo on Cygwin (currently at http://www.hyperborea.org/software/dillo/cygwin.html ). I hadn't tried it since Dillo 0.7.3, so when I built 0.8.2 with the new built-in libraries, I discovered some problems with DPI. First, since Cygwin knows it's running under Windows, it appends .exe to any executable files it builds. (When you run a command in Cygwin, it will look for the file as written, then look for it with .exe added -- so the compiler is really gcc.exe but you can still run it by typing "gcc".) This includes the DPI plugins, which end up being bookmarks.dpi.exe, downloads.dpi.exe, etc. This means dpid will not find them when it looks for available plugins unless you rename them. Second, even after renaming them, I can't get any DPI plugins to actually work. Here is the output from clicking on the bookmarks button: Nav_open_url: Url=>dpi:/bm/< url_str = dpi:/bm/ Dpi_check_uds: Connection refused /tmp/kvibber-5re3lm/dpid.srs debug_msg - init_sockdir: The socket directory /tmp/kvibber-5re3lm exists and is OK dpid started Capi_dpi_conn_timeout:: try 1 main.c:153: get_command: dpid tag is NULL : main.c:326: main: get_command failed : bookmarks.dpi (v.13): accepting connections... [accept]: Software caused connection abort File permissions on the sockets look the same as they do on a Linux box (srw-------) It may just be something about the way Cygwin handles sockets. Unfortunately I have very little experience with sockets on *any* platform (and very little experience with C, for that matter) Anyway, I figure Cygwin support probably isn't a priority, but I thought I'd point out the issues in case anyone was interested in tracking them down. -- Kelson Vibber www.hyperborea.org

20 years, 1 month

Re: Dillo

by Jorge Arellano Cid

Stefan, > Hi! Hi. > First of all: Thanks! Thanks for giving me Dillo! You're welcome. > I've got two questions: > > 1. In the dpi text a hello_world plugin is mentioned. Where can I find it? Hold on a bit, we're working with Ferdi on a new plugin manager that will ease a lot the making of new plugins. (if you can't hold your breath, drop me a note and I'll send it to you). > 2. I'd like to see some things in future releases. Where can I post suggestions? You said 'dont brainstorm to the mailing list'. First, think a lot of suggestions before posting them. That's the idea. We have little manpower and a lot to do, so we focus on the most important issues only. > What I'd like to see: Incremental full text search like in the latest Mozilla version. Just typing in the main window starts a search over the whole displayed Page. Prefix letters (configurable!) restrict search, e.g. > > '/' -> search only within link text > '\' -> search only within link target > ':' -> search only within plain text > '#' -> search only within current frame > '*' -> use regexp search (okay, this one's really advanced) > > ESC -> stops old search, starts new > TAB -> jump to next match > > So, '#\foo.com<TAB>' would find the second occurence of a link in the current frame which is coded as <a herf='www.foo.com/list.html'>link</a> I wouldn't go for something so specific at this time, but if you like, you can start studying the Knuth-Morris-Pratt algorithm in findtext.c, and evaluate from there. Cheers Jorge.-

21 years, 5 months

https plugin status

by place＠gobigwest.com

Jeremy wrote: > On Sat, Mar 15, 2008 at 01:22:09AM +0000, Jeremy Henty (ie. me) wrote: > > > I was wrong, the https filter dpi *is* starting. But, its debugging > > messages don't appear because it sends them to stdout, which dpid > > redirects to the DPI socket. This feels ... somehow ... wrong. > > And so it is! (Patch submitted in a new thread.) After redirecting > the debugging messages to stderr I see: > > [https dpi]: {In https.filter.dpi} > [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue > [https dpi]: { exiting https.dpi} > > which at least gives some idea of what is going wrong. It appears that Capi_dpi_build_cmd() needs to test for "proto.https" instead of "https"...

16 years, 8 months

IPv6 and HTTPS (Re: release candidate for dillo-3.0.2)

by obeythepenguin＠gmail.com

Johannes wrote: > I doubt it's worth making the current experimental HTTPS plugin > IPv6 ready. > We will need a more robust HTTPS solution at some point. > Cheers, > Johannes Why not just reuse the existing HTTP code? *cough* http://dillo-win32.sourceforge.net/patches/07-dfcntl.diff http://dillo-win32.sourceforge.net/patches/08-dsock.diff http://dillo-win32.sourceforge.net/patches/17-https.diff Just add some warning dialogs and you've got everything the plugin offers, plus greater efficiency, code reuse, IPv6, etc. (Not to mention, it's thoroughly tested and quite stable on Linux, BSD, that other OS with 99% market share, etc. I use it myself every day.) Anyway, all my code's still there if you're interested. Cheers, ~Benjamin

12 years, 11 months

Re: [Dillo-dev] Some points about the dpi's

by Jorge Arellano Cid

Andreas, Here go my comments... > On Tue, Aug 19, 2003 at 12:33:53AM +0200, Andreas Schweitzer wrote: > > Hi, > > > > All right, I did it. I made my first dpi ! :-) (heavily > That's great, I hope to make a new patch for dpid available soon. Good! That means it's understandable now! :-) > > > > The second caveat : dillo does not automatically call this plugin > > upon such a URL. It is easy to patch dillo, though. > Creating a new dpi still requires more effort than it should. Eventually there'll be a mechanism for automating the inclusion of new URL-handling plugins. We're working on it with Ferdi. > > > However, this brings me to my questions : > > 1) will there be a generic URL->dpi mapping ? > > I could imagine that dpid could actually handle that. > Yes, but I think you mean URL->SERVICE, a dpi is just an implementation > of a service. Ditto!. The distinction is relevant because there may be several different dpi programs that implement the same service. The user makes a choice and uses _one_ of them. > > > I think, one would need to only modify IO/Url.c and > > capi.c to simply pass through EVERYTHING to the dpi framework. > > However, some "core URL handling dpi's" that will become > > part of the dillo package can probably stay hardcoded in dillo. And attached to a service name... If there's a dpi for handling it, no problem. If not, warn that is not an available service. > > > > 1b) Either way, I am planing on writing a "catch-all-URL handler" > > or "fallback handler" or "univeral URL handler" or the like. > > It will give the user the possibility to start an external > > program for handling certain URL's. > > In fact, with my current dpi, this is quite easy > > to do :-). > OK, but I think we should hold off on 1 and 1b until I make the next > dpid patch available. Me too. > > > 2) Does it make sense to write a library for all the dpi's ? > > I, for myself, did start simply collecting all the functions > > that I found in dpi/ and are used by many dpi's and put them > > in a library. Like the various send_stream functions or the > > get_attr_value function, or the encoding and decoding functions. > Yes, that would be very useful. Your strategy of creating a library > of functions which are actually used by many dpis is a good one. > > > 3) About configuration (and I think I read comments about this > > in the code), shouldn't there be only one config file ? > > and not dpidrc and possibly different configs for all the dpis ? > > maybe even merge cookiesrc with dillorc ? > Yes, my next dpid patch gets rid of dpidrc. This is the only point I have some doubts. I've always thought that it is a good idea to keep separate configuration files for dillo, and its dpis (and dpid). One file with a lengthy collection of not tightly-related configuration directives sounds to me as low-cohesion and high-coupling (I'm not sure about what are the words in english for those technical terms. In spanish it is: cohesión y acoplamiento). The idea of having a preferences plugin providing an HTML GUI for: dillo, dpid, and each dpi, is what I picture in the long term. Something like: .-------. | Dillo | Dpid | ftp | https | .... | ---------------------------------------------------. | | | <dillo's preferences here> | | ... | | '-----------------------------------------------------------' Restore Apply Save I think that is easier and cleaner with separate configuration files. Also, the rc for each dpi would be located in its own dpi directory tree (available in next dpid patch). Note that the task of the preferences dpi is to change the rc file providing a nice GUI, not to make the changes effective. Taking the changes into account is a thing that each program knows better. The preferences dpi will "tell" that program to reread the rc and update its state, probably through dpidc or dpip. > > > I guess some of this (or all of it ?) is being worked on > > by some of you. Maybe this mail helps to avoid duplication :-) Yes it is! > > > > Cheers, > > Andreas > > > > P.S.: I also have some ideas about improving the ftp plugin. There > > is a pretty simple ftp library, Which one? > > and I think it does make sense to > > actually log in an ftp server and stay logged in for all the operations. > > (unlike wget which logs in and out for every file). This is not only > > faster but helps with busy ftp sites, too ! > Developing the ftp plugin is a high priority and your help here would be > appreciated. Just as hinted in the comments inside ftp.c! Note that you only need to provide the HTML output for FTP directories. Downloads are to be bounced back to dillo for it to forward them to the downloads plugin (that way the whole downloading is centralized in a single place, stats can be provided etc.). I left some code inside ftp.c that shows a beautiful trick to tell whether an FTP URL is a directory when using wget (it probably can be re-used). The most time consuming task with this approach is to parse the ASCII from the ftp server into HTML (easy in theory but you'll find different layouts). In fact that's what I did with and ancient FTP plugin I wrote. If the library you think of using writes HTML itself, great! If not, just tell me to dig in for my old FTP code, and to send it to you. Cheers Jorge.-

21 years, 2 months

Question about local file browsing

by rogutes＠googlemail.com

Benjamin Johnson (2011-04-09 14:17): <...snip...> > One other thing that concerns me: a Windows user might start Dillo, > see a bunch of unfamiliar DPI programs running, and worry that it's > some kind of virus/spyware infection. Even if someone explained > that it's just part of the browser, they might not be convinced, > since -- say -- Firefox doesn't start all that stuff in the > background. Spyware is increasingly a very real and very serious > concern, so many users are justifiably suspicious of anything even > remotely out of the ordinary. Firefox does start some stuff in the background (plugin-container.exe, since Firefox 3.6.4). Though your point seems to be valid, at least on Windows: http://google.com/search?q=plugin-container.exe -- -- Rogut?s Sparnuotos

13 years, 7 months

Re: [Dillo-dev] Very close to a new release!

by TheStar

> > > Note to all/self: Dillo will *not* work with autoconf-2.13. > > > > Please test our latest CVS. It should work with the old autoconf. > > Works fine now, thanks. :) I've been using 0.7.0-pre since last night; > it works beautifully so far. Can't wait for the release! > Same here, although I'd much prefer having the plugins in some generic place such as /usr/share/dillo so that I don't have to make sure that each user has the correct plugin, etc... (Can I do that already?) I'd also _really_ like to have a "open link with..." dialog/menu/etc... ;) Great job, Once the cut & paste and downloading are finished, it will be better than the graphical links!

21 years, 9 months

Re: [Dillo-dev] dillo officially supported in Sylpheed-Claws

by Jorge Arellano Cid

Melvin, > Current cvs version of Sylpheed-Claws mail client (0.8.11claws14) > officially supports Dillo to"safely" view html mail within the mail client > window using the embedding facility of Dillo and a plugin technique in > Sylpheed-Claws. The forthcoming 0.8.12claws will be the first public release to > provide the Dillo plugin. (no timeline known, but it's a matter of weeks). That's very good news! > I wrote "safely" between quotes, because IMHO there is a bug in Dillo when using > the "-l" (or SpamSafe) command line option, as I pointed out in a previous mail > (Message-Id: <20030221093243.435de32f.melvin.hadasht(a)free.fr>). I'll shortly > post a patch for it in this ML. Already in the CVS! > Thank you for your work. You're welcome. Cheers Jorge.-

21 years, 7 months

Re: [Dillo-dev]Plugin infrastructure

by Jorge Arellano Cid

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

20 years, 4 months

Dillo-dev search results for query "plugin"