Search results for "plugin" - Dillo-dev

Suggestion regarding its Bookmarks plugin

by Zero3K＠myopera.com

It should have the ability to open all of the bookmarks of a section (either a link or button named "Open All"). That or the ability to open them via a keyword that's assigned to a section.

11 years, 7 months

Suggestion regarding its Bookmarks plugin

by Zero3K＠myopera.com

On Sun, 24 Mar 2013 23:52:27 -0400 Bryan Kirk <Zero3K at myopera.com> wrote: > It should have the ability to open all of the bookmarks of a section (either a link or button named "Open All"). That or the ability to open them via a keyword that's assigned to a section. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev Any thoughts on it?

11 years, 7 months

Testing without Dillo

by Schimon Jehudah

Greetings! Is it possible to run Dillo plugins without installing them? I ask for two reasons: 1) Ease of development. 2) I fail to activate plugins. ** ERROR **: [Dpi_read_comm_keys] No such file or directory Dpi_blocking_start_dpid: try 1 [dpid]: a_Misc_mksecret: 1j91dh5 dpid started Dpi_get_server_port: can't read server port from dpid. Dillo: normal exit! Regards, Schimon

1 week, 2 days

https plugin status

by onepoint＠starurchin.org

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

16 years, 8 months

Re: [Dillo-dev]Extension/plugin question...

by Brian Sammon

> > You can start by looking at the patch by Brian. Then look at > > the force_my_colors dillorc option and hook it to the menu that > > will pop-up from the new toolbox icon placed to the left of the > > Um... 'scuse my ignorance, but what patch by Brian? I think he's referring to your patch. Apparently due to the poor quoting style of my mail client, I've been getting credit for the patch you submitted to the list. As much as I like taking credit for other people's work, I feel I must correct this misunderstanding.

20 years, 1 month

https plugin status

by onepoint＠starurchin.org

On Fri, Mar 14, 2008 at 11:35:38PM +0000, Jeremy Henty (ie. me) wrote: > ... I can see the CCC setting up tearing down the IO links, so it > looks as though the dillo process is talking to something, and > getting something sensible from it. But AFAICT the https filter dpi > isn't even starting (it should dump some startup messages to stdout > which I'm not seeing). 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. Jeremy Henty

16 years, 8 months

https plugin status

by jcid＠dillo.org

On Sat, Mar 15, 2008 at 08:21:23PM +0000, Jeremy Henty wrote: > On Sat, Mar 15, 2008 at 03:31:52PM -0400, Jorge Arellano Cid wrote: > > > > [Jeremey wrote] > > > Or maybe Capi_url_uses_dpi() should be checking for "https" and > > > *not* adding the "proto." prefix? > > > > "proto.https" is the right patch. > > OK, what about my patch to redirect MSG debugging messages from stdout > to stderr? Is that correct? Dpi programs are reading and writing from the stdin descriptor, and all of them send debug messages to stdout. I think this is correct, or at least standard by now. -- Cheers Jorge.-

16 years, 7 months

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by jcid＠dillo.org

Hi Christian, On Sat, Mar 15, 2008 at 07:32:56PM +0100, Christian Kellermann wrote: > Hi Jorge, > > * Jorge Arellano Cid <jcid(a)dillo.org> [080315 18:58]: > > Sorry for the late answer, but I've had little spare time, > > and several topics to answer. > > > > Probably you have already read: > > > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.ht… > > > > an got some info from there. > > Yes, thanks for the hint, it was insightful. I have spend a few > thoughts on the SSL issue and I'd like to hear your opinion on it. Funny how this makes me wonder whether you read the rest of my comment on this same email: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-March/003928.html :-) There I suggest for an internal implementation, but, I know it can also be done with a server dpi: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-October/003237.html > The most work that still needs to be done is to handle certificates > and the user interaction required to make it usable. Garret wrote a good part of the certificate handling, you will find that code inside the plugin. > The user needs > to add trust values to certificates and to add or remove them > offline. I think this can fit well into a server dpi. Adding and > deleting bookmarks could be done similar to handling bookmarks. Yes. > Which might be a bit rough but is independent on fltk widgets. I > do think that we already have enough dialog types in dillo. Hard > coding the certificate handling would not make the situation any > better. That's why I implemented the dialog request option in dpip. This is, a dpi can ask dillo to pop a dialog and to send back the answer. This was working in dillo-0.8.6, and got a bit trimmed after the port. It should be simple to enable it again. > > Also I can imagine this plugin to handle client certificates which > I do believe will become a more common requirement for certain > applications in the future. Adding secure storage capabilities will > be easy. Also people will have the chance to write some "bridging" > plugin that extracts the needed data from existing storage sources > elsewhere, i.e. certificate servers,... I like the ide of an https dpi server. What I don't know is whether the current and future requisites for it to work, will make it harder to mantain in the future. At the present day both options (server and internal) look similar. > Handling this all internally means that we put functionality into > dillo that are needed for, but basically have nothing to do with > browsing. As I have grasped the spirit of this project this may not > be the way to go. A nice thing about handling https internally is > the opportunity to reuse an established connection for more than > one request, which might speed up transfers significantly. > > But on the other hand couldn't this be done by dpid for all filter > plugins? For all filter plugins, not. They were designed as one request, one answer with EOF and close as an important part of the process. OTOH, dpi servers were designed to do that. > Dpid can keep them alive as long as the following requests > belong to the same URL, then closing the connection after a timeout? > > I am sorry if this has been already decided on before. These thoughts > were rumaging aroung my head all day now... I hope these lines help. -- Cheers Jorge.-

16 years, 7 months

youtube-dl

by corvid＠lavabit.com

Jeremy wrote: > corvid wrote: > > Maybe it would be nice to have the dpis able to register interest in > > resources meeting certain criteria or something. Or maybe the trick > > is to simply :) implement the NPAPI. > > ??? What is this "NPAPI" of which you speak, Earth being? :-) I > guess I've not been keeping up. Sorry, I wrote more and then I guess I trimmed it down too much. Netscape Plugin API The mighty wikipedia claims: The following web browsers support NPAPI plugins: o Epiphany o Google Chrome o Konqueror o Mozilla project applications, including o Camino o Firefox o Mozilla Application Suite o Seamonkey o Netscape Navigator and Communicator o Opera

14 years, 4 months

dillo officially supported in Sylpheed-Claws

by Melvin Hadasht

Hi, 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). 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. Thank you for your work. Cheers -- Melvin Hadasht

21 years, 8 months

Dillo-dev search results for query "plugin"