Search results for "plugin" - Dillo-dev

[PATCH] startup window

by thomas-forum＠orgis.org

Am Wed, 1 Apr 2009 09:47:11 +0200 schrieb Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: > Hi, > attached patch adds a proper startup screen for dillo. Oh, is dillo slow enough now that it needs a splash screen distracting the user while waiting for startup? I sort of like the "instant startup" behaviour. A splash startup screen reminds you of the startup _not_ being instant. Especially opening an extra window wastes CPU cycles, even in X11, that could be used on doing the actual work... Of course I'll have to check out a current dillo2 to see how eminent the issue really is. But when we reach the startup speed of e.g. the GIMP with it's endless loading of plugins etc., one can safely declare dillo "just another bloated browser". I don't want to be offensive, just voice my concern... Alrighty then, Thomas.

15 years, 7 months

Re: [PATCH v2] Unveil patch

by Diego

Hi. Sorry I can't help dillo more. I'm always very busy with my work. El vie, 2 ago 2024 a las 1:24, Rodrigo Arias (<rodarima(a)gmail.com>) escribió: > > >To-Do: > >- Add prefs parsing to plugins to get 'save_dir' (may need help here) > > I assume you could reuse the same prefs parser from Dillo, but we would > need to link the DPIs with some of the code that is now only being > linked in the browser. > > You could use dParser_parse_rc_line() from dlib/dlib.[hc] ../dlib/dlib.c:int dParser_parse_rc_line(char **line, char **name, char **value) ../dlib/dlib.h:int dParser_parse_rc_line(char **line, char **name, char **value); ./srch dParser_parse_rc_line keys.cc: st = dParser_parse_rc_line(&line, &keycomb, &command); prefsparser.cc: st = dParser_parse_rc_line(&line, &name, &value); ../dpid/dpid.c: st = dParser_parse_rc_line(&line, &service, &path); Salud! Diego

3 months, 2 weeks

Re: [Dillo-dev]Re: dillo: umask(0) in dpid/main.c?

by Jorge Arellano Cid

On Wed, Dec 01, 2004 at 06:35:33AM +0000, Jeremy Henty wrote: > > On Tue, Nov 30, 2004 at 03:10:50PM -0300, Jorge Arellano Cid wrote: > > On Sun, Nov 28, 2004 at 01:03:23PM +0100, Richard Zidlicky wrote: > > > > > Is there still a good reason to set umask to 0 for all plugins? > > > > ... it makes much more sense to use 077 as a mask for dpis > > (i.e. only allowing the owner). > > > > Comments are welcome. > > Well, I'd vote for 077. World-writable files give me the willies. Just changed dpid's umask to 0077. As Dillo is not designed to share its internal files among users, this seems to be the right setting. Does anyone know better about umask's effects in depth? -- Cheers Jorge.-

19 years, 10 months

keyboard shortcuts non-functioning under KDE 3.5.10

by paul＠claws-mail.org

Hi Jorge, On Thu, 4 Jun 2009 12:23:57 -0400 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Paul, please let us know what binding are you trying to make, > what is failing and your keysrc. I'm not actually trying to make any. I got on to this problem when talking to Johannes on #claws - dillo1 had 'show controls' and 'reload' in the context menu, which was always very useful in Claws Mail with the plugin, because it runs `dillo -f`, but anyway... Even the default keybindings don't work for me. I don't have a keysrc file, but I did create one, at Johannes suggestion, but this didn't have any effect either. Pressing key-combos has no effect. best regards Paul -- "Thanks to his green candle, the 'Pataphysician can lighten our darkness."

15 years, 5 months

[patch] Gopher DPI

by p37sitdu＠lavabit.com

I implemented basic Gopher support using DPI, patch is attached. It is already quite usable. "URL:" links are not supported, but Gopher servers send redirect pages for compatibility. The only major problem is unrecognized file types. I looked at FTP DPI. It sends Content-type: application/octet-stream. This forces Dillo to ask downloads DPI to start download. With gopher it doesn't work as downloads DPI doesn't suppport gopher. So Dillo just says "Content-Type 'application/octet-stream' not viewable.". I left it as it is for now, because I don't think adding support for all known and unknown protocols into downloads.cc is the right solution. Maybe downloads DPI protocol should be changed so Dillo would feed plugin with data it receives as octet-stream and downloads DPI would only save what it receives to disk instead of connecting to server and downloading the file itself.

11 years, 11 months

Re: [Dillo-dev]Invoke application upon clicking a link

by Matthias Franz

On Fri, Aug 20, 2004 at 09:05:13PM -0700, huy wrote: > I would like to be able to click on a link and invoke a local executable. > [...] > Is there a way I can do this with dillo (short of modifying the source code). Dear huy, using the external viewers patch (see my posting to this list) and the Dillo dpi framework, there is a short solution to your problem: Save the attached shell scipt to ~/.dillo/dpi/runcmd/runcmd.filter.dpi and put the line application/x-runcmd; %{cmd} into your ~/.mailcap . Then any link of the form "dpi:/runcmd/prog" starts the program "prog". See the Dillo file doc/Dpid.txt for more on (filter) plugins. > security isn't an issue I hope so since otherwise you'd better forget all this! All the best, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

20 years, 1 month

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

by jcid＠dillo.org

Hi, I just committed the implementation of a_Dialog_choice5(). This function allows for question dialogs with max. 5 options. It is used by https, and you can test it with "dpi:/hello/". As stated above, dpi programs can ask questions by sending a dpi command and receiving an answer from dillo. This implementation is modal, but if there's a need to make it non-modal, it should be easy to implement choice5 as a class with internal state and to issue the callback from there. Please excuse the late patch, but I had a lot to review and I still can't trap the freeze on: http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 (with cookies enabled.) :-P 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. > The most work that still needs to be done is to handle certificates > and the user interaction required to make it usable. 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. > 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. Yes, dpi bookmarks have proven quite useful a model for this local data-handling case. > 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 assume you know more than me about this topic, so feel free to design a simple way to handle it. AFAIS it looks OK. > > 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. I'm not sure on which model will end up being simpler. I'd suggest to design on paper and test the basics before going for a full implementation. HTH. -- Cheers Jorge.-

16 years, 7 months

--xid option

by Johannes.Hofmann＠gmx.de

On Mon, May 18, 2009 at 01:48:43PM -0400, Jorge Arellano Cid wrote: > On Mon, May 18, 2009 at 01:18:11AM +0200, Johannes Hofmann wrote: > > Hi, > > > > attached patch tries to implement the missing --xid option that is > > used to embed dillo into the claws mailer. > > The right way to do this would probabely be to implement the > > complete XEMBED protocol which is also mentioned in > > doc/fltk-problems.doc. > > However a simple XReparentWindow() seems to work more or less here. > > Please test. > > It seems like you forgot to commit xembed.{hh,cc} to the repo. > e.g. hg add xembed.hh xembed.cc Oh yes. Should be fixed now. Btw. I managed to install the claws mail client including the dillo plugin and it seems to work fine now with dillo2. That's why I just committed the xembed stuff. Cheers, Johannes

15 years, 5 months

Re: [Dillo-dev] https approaches?

by madis

On Thu, 13 Mar 2003, Ami Fischman wrote: > Hi there, > > SSL support is one of the biggest lacks in dillo for me. To that end, > I'm thinking of adding it in. Without knowing the dillo codebase, I see two > obvious options: > 1) Add a src/IO/https.c file based on src/IO/http.c > 2) Move http.c to using openssl's BIO's which can support either encrypted > or clear traffic, as well as filters. Imho it should be a plugin or something alike to avoid bloating dillo with ssl specific code. Current dpi does not support sending raw http to dillo, so maybe simplest solution would be to create pseudo-proxy for https, which sends https queries in unencrypted form to unix socket sitting in ~/.dillo/. Local proxy would then do the actual encryption (some authentication may be required to ensure that both dillo and proxy are actually runned by same user). -- mzz

21 years, 8 months

Re: [Dillo-dev]Using dillo on SourceForge

by Andreas Kemnade

On Mon, 4 Apr 2005 20:34:55 +0100 Jeremy Henty <jeremy(a)chaos.org.uk> wrote: > > Is the SSL-enabled version of dillo-0.8.4 up to managing SourceForge > accounts? I'm on the login page at > <URL:https://sourceforge.net/account/login.php> but when I click the > "Login with SSL" button the page just blinks at me as if I'd refreshed > the it. I don't get logged in. Is anyone using a SourceForge account > through dillo? > You need some of these ssl-patches (with an older dillo) which do not use the dpi interface because SF needs cookies to login. With that, you can use at least the SF installation at auriga.wearlab.de As far as I understand, the https dpi plugin does not handle cookies because the cookies do not find their way to cookies.c So you probably have to wait for the cookies dpi. Greetings Andreas Kemnade

19 years, 7 months

Dillo-dev search results for query "plugin"