Search results for "plugin" - Dillo-dev

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

by Brian Sammon

> As occasionly I come across websites (up to around 3 times a day) > which because of one reason or another display white-on-white, or > other things like that, and because most of the time I like seeing real > colours of pages, I quickly added a "use colours" button to the toolbar > of my local dillo, which (obviously) toggles the use of local colours or > not. > Anyway, my question is, as this kind of thing isn't really wanted for > mainstream/normal dillo, is there any way of writing it as an extension, > or a plugin, rather than as a patch? Or will there be such a way, ever? Something I really miss from my browser from way back when, Mosaic, is the "Options" menu which had a bunch of checkboxes for options like that. I would love to see your function (and something related to image loading, while I'm making out my wish list) show up in a similar menu in dillo.

20 years, 1 month

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

20 years, 4 months

claws? (Re: [Dillo-dev] Garbage chars added)

by fgeek＠hack.fi

On Thu, 23 Oct 2008 15:16:28 -0300 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Thu, Oct 23, 2008 at 08:27:13PM +0300, Henri Salo wrote: > > On Thu, 23 Oct 2008 16:31:14 +0000 > > "corvid" <corvid(a)lavabit.com> wrote: > > > > > Tomas wrote: > > > > X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.0; i486-pc-linux-gnu) > > > > > > Just noticed this. Is claws able to make much use of dillo2? > > > Jorge put in a special-case workaround for "dillo -l -f -x XID > > > URL" right before release, but I don't know whether anyone's > > > using it (or if any claws users even know it's there) > > > > > > Hmm...a moment of searching and the first hit I get is > > > http://www.nabble.com/Using-of-Dillo2-td20014194.html > > > which suggests that, no, they don't know. > > > > They know. Both users and development. I said about Dillo2 in #claws > > when it was release. I'm not sure when they are going to implement > > it as plugin nor if it already works. Some information can be > > located in two places: > > > > http://www.claws-mail.org/plugin.php?plugin=dillo > > http://www.claws-mail.org/plugins.php?branch=STD > > The problem is dillo-2.0 has a workaround only implementation > for the CLI switches claws needs. > > It'd be good to patch it fully, but before that we need to know > whether is possible to embed an FLTK2 window into an Xwindow. > > Once we know it's possible, the patch is in place and the release > made, I'd advice claws folks to use it. You should communicate directly with Claws-Mail's development team for sure. -- Henri Salo <fgeek at hack.fi> +358407705733 GPG ID: 2EA46E4F fp: 14D0 7803 BFF6 EFA0 9998 8C4B 5DFE A106 2EA4 6E4F

16 years

finger plugin

by Andreas Schweitzer

Hi, as promised in a previous mail. Here is the still quite rough finger dpi intended for interested developers : http://www.hs.uni-hamburg.de/~stcd102/dillo/ http://www.hs.uni-hamburg.de/~stcd102/dillo/adpi-0.1.tar.gz It's configure.in is essentially dillo's configure.in :-) you could actually just put finger.c in the ./dpi/ subdirectory of dillo and adjust Makefile.am accordingly. but now I have an actual distribution :-) In the tarball is also what I call so far a library ... well, or at least the routines that have been re-used over and over. Lastly, there is also an experiment : a term plugin, which lets you call arbitrary programs from within dillo (read the source, though !) Installation: just copy the created .dpi files to ~/.dillo/ and edit ~/.dillo/dpidrc (as long as this file exists), then go to dpi:/finger/ If you want dillo to actually recognize the finger URL you will have to edit src/IO/Url.c and sr/capi.c. Search for the string "ftp" inside these two files and duplicate the relevant part for the finger protocol. Or await how dillo evolves :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

21 years, 2 months

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

by Andreas Schweitzer

Hi, This e-mail account was cut off the net (literally ...) for 2 days, hence the delay in answering. > > > 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!. I understand. I think my original wording was not the best. But in the end, if the user can easily manage and configure URL->(via services)->dpi-program w/o compiling dillo, (s)he will be happy :-) > > > 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. I'll put it on hold :-) > > > 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). OTOH, for a user (like myself) who likes editing configuration files by hand, it is more convenient to have it in one place ... just an opinion though :-) ... but ... as you say : > 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 | .... > | ---------------------------------------------------. ^^^^^ should be named "Plugin Management" or the like :-) this is of course also acceptable. Thinking a bit longer ... I think Mozilla is very much like that. You can configure Mozilla from within and it puts its config files scattered thorugh ~/.mozilla/ within a maze of directories. Every time I look inside that directory trying to fix things by hand, I am completely lost ... hence my desire for a one stop config file :-) > > > P.S.: I also have some ideas about improving the ftp plugin. There > > > is a pretty simple ftp library, > > Which one? http://nbpfaus.net/~pfau/ftplib/ seems to be relatively old, but the ftp protocol hasn't really changed that much :-) I *think* it is also used in some other applications. > > > 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. and for files the user clicks on, like text files, images and even html files that exist in the ftp directory. > 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 have been thinking back and forth about that point. I think what I will end up doing is at least implementing the actual download from within the ftp plugin. Weather it will be included in the "official" one, or if I make 2 versions (a basic one and a fancy one), or whatever, remains to be seen. I guess one could also think about sending the data from the ftp plugin directly to the download plugin w/o relaying it via dillo. > 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). I saw it, and this is indeed a problem. I checked the ftp rfc and there is no command that will tell me if something is a regular file or a directory. Also, after checking the ftp rfc and the url syntax rfc (rfc 1738) especially, section 3.2.4 and 3.2.5 makes the logging into ftp sites somewhat problematic. Essentially, it says, unless you actually travel an ftp site like within an interactive client, there is no way of telling how to get from ftp://site.com/foo/bar/ (which could be one link in an html page) to ftp://site.com/foo2/bar2/ (which could be a 2nd link in an html page) > 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. I think either way it could be useful to look at :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

21 years, 2 months

claws? (Re: [Dillo-dev] Garbage chars added)

by jcid＠dillo.org

On Thu, Oct 23, 2008 at 09:20:55PM +0300, Henri Salo wrote: > On Thu, 23 Oct 2008 15:16:28 -0300 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > On Thu, Oct 23, 2008 at 08:27:13PM +0300, Henri Salo wrote: > > > On Thu, 23 Oct 2008 16:31:14 +0000 > > > "corvid" <corvid(a)lavabit.com> wrote: > > > > > > > Tomas wrote: > > > > > X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.0; i486-pc-linux-gnu) > > > > > > > > Just noticed this. Is claws able to make much use of dillo2? > > > > Jorge put in a special-case workaround for "dillo -l -f -x XID > > > > URL" right before release, but I don't know whether anyone's > > > > using it (or if any claws users even know it's there) > > > > > > > > Hmm...a moment of searching and the first hit I get is > > > > http://www.nabble.com/Using-of-Dillo2-td20014194.html > > > > which suggests that, no, they don't know. > > > > > > They know. Both users and development. I said about Dillo2 in #claws > > > when it was release. I'm not sure when they are going to implement > > > it as plugin nor if it already works. Some information can be > > > located in two places: > > > > > > http://www.claws-mail.org/plugin.php?plugin=dillo > > > http://www.claws-mail.org/plugins.php?branch=STD > > > > The problem is dillo-2.0 has a workaround only implementation > > for the CLI switches claws needs. > > > > It'd be good to patch it fully, but before that we need to know > > whether is possible to embed an FLTK2 window into an Xwindow. > > > > Once we know it's possible, the patch is in place and the release > > made, I'd advice claws folks to use it. > > You should communicate directly with Claws-Mail's development team for > sure. Do you have an email pointer? -- Cheers Jorge.-

16 years

Re: Firefox bookmarks plugin

by Diego

El mar, 27 ago 2024 a las 23:17, Rodrigo Arias (<rodarima(a)gmail.com>) escribió: > > Hi, > > On Mon, Aug 26, 2024 at 01:31:13AM +0200, Diego wrote: > >Good work and very interesting idea. > > Thanks! > > >If I can suggest a change I would add this lines to dpidrc at Makefile > >the installation > > > ># Default dillo bookmarks dpi > >#bookmarks=bookmarks/bookmarks.dpi > ># ffbm: A Dillo plugin to sync bookmarks with Firefox > >bookmarks=$(DPI_DIR)/$(BIN) > > > > > >maybe it's time to patch dpidrc to make it more descriptive > > > >I sugest this > >dpi_dir=/usr/local/lib/dillo/dpi > > > ># standard dillo distributed DPIs > >#bookmarks=bookmarks/bookmarks.dpi > >#cookies=cookies/cookies.dpi > >#downloads=downloads/downloads.dpi > >#vsource=vsource/vsource.filter.dpi > > The file dpidrc only registers the protocols (ftp: -> ftp dpi), the dpis > are taken from the dpi_dir or ~/.dillo/dpi automatically. > I know. > It doesn't require describing the available dpis in the file. Not sure > what would be the advantage of doing so. For reference. To explain to the user how to switch between a built-in DPI and another DPI for the same service. Maybe a documentation patch better? I can try to write some documentation about it Diego.

2 months, 2 weeks

Ignore a command line option (for Mac OS bundles)

by rf.opensource＠gmail.com

On Sun, Jun 5, 2011 at 11:31 AM, corvid <corvid(a)lavabit.com> wrote: > > I could use a bit of advice though. In my preliminary experiments, > > I'm having a bit of problem with the dpi related dynamic libraries. > > I can get dillo to run on another machine with libpng, libjpeg and > > zlib copied over to /usr/local/lib, but none of the plugins work. I > > have copied the usr/local/lib/dillo folder too, and also > > /usr/local/bin/dpid and /usr/local/bin/dpic, but still the plugins > > do not work in the target system. Any files I forgot to copy over? > > How about dpidrc? > > > Thanks, yes it works. I had forgotten the following: /usr/local/etc/dillo/dillorc /usr/local/etc/dillo/dpidrc /usr/local/etc/dillo/ Now most of the plugins seem to work, at least bookmarks work fine. There is still a problem remaining though. In the target machine, I cannot open sites that require SSL (for example www.gmail.com, mail.yahoo.com) I'm not sure why it happens. Is there any library that helps in SSL connections that I forgot copying over? BTW, I tried following Makefile to see what happens for make install, but since it is autogenerated by autoconf it's a bit too complex to follow manually :(

13 years, 5 months

claws? (Re: [Dillo-dev] Garbage chars added)

by jcid＠dillo.org

Hi Paul, On Fri, Oct 24, 2008 at 08:21:29AM +0100, Paul wrote: > [...] > "dillo -l -f -x XID URL" these options are known by the Claws Mail team, they > are built into the Claws Mail Dillo Browser plugin - iirc, they first > appeared in Dillo as a result of a discussion between Melvin, the developer > of the plugin, and the Dillo team. The Claws Mail users do know these > options, at least through the plugins preferences page, and, I would imagine, > the majority of them do use these options. imo, having the option to avoid > loading of remote content is crucial in an email app's html message display. Thanks for the info. > Athur F. Ucksayke from #claws is interested what command: "dillo -l -f > -x XID URL" is supposed to do? Is this documented? Not documented. In dillo2: - This enables the SPAM safe mode (no images/resource loading). - It doesn't embed the window because we don't yet know how to do it. - Full screen is ignored - The URL is shown. As this was a "blind workaround" (i.e. not tested), would you mind trying whether it works. It should start a dettached dillo2 window in SPAM safe mode, with browser controls showing. As for proper implementation of those CLI switches in the future, who should I contact? I assume by your email you're a good person to ask. -- Cheers Jorge.-

16 years

Re: [Dillo-dev] Proposal: United Dillo

by Jyri Jokinen

On Thu, Nov 20, 2003 at 04:50:14PM +0100, Indan Zupancic wrote: > Always one Dillo has less overhead than running multiple instances at > the same time. > Beside, if Dillo uses library plugins then there is no need to fork at > all. I'm not really qualified but that has never stopped me before eather. You want to get rid of dpid in favor of library plugins and make dillo execute as one process only. I'm right this far? And once one happens to have 20+ dillo windows open with your proposed way, some library plugin (or dillo itself) decides to halt everything. Or segfault. 20+ browsing windows spirited away. How many times has this happened with Mozilla, M-Firebird or just about any other web browser? How much did you swear after it? Right now I practically allways launch a new dillo when i need a new browser window. It's just so much nicer when all those 50 or more windows I often have open don't go at one blow if something bad happens. > What do you think about it? I think it's the stupidest idea since browser tabs. (*) You asked. Dunno if my facts are right, but this is what my user experience tells me. Feel free to flame me if I got something terribly wrong. -- shared, (*) Nothing personal at Frank, you're a hard working guy doing things you believe in, appreciate it truly even I disagree with some of it.

20 years, 11 months

Dillo-dev search results for query "plugin"