Search results for "plugin" - Dillo-dev

Re: [Dillo-dev] Dillo Support for Flash plugins

by Thorben Thuermer

On Wed, 7 Dec 2005 18:13:37 +0800 Xyber Blue <xyberblue(a)gmail.com> wrote: > Is there anyone here who tested the dillo with flash plugins??? I just want > to know if dillo is already supporting this kind of plugins. > If not, is there any plan to support flash player plugins for dillo??? http://www.dillo.org/Plans.html >Low priority >[-] Graphical plugins framework. http://www.dillo.org/dpi1.html > Hopefully, dillo will have two types of plugins: one of a >simple nature (described in this document), that operates in a >similar way of CGIs (with some extensions), and another that >integrates interaction with the rendering engine and its widgets. > > The fact is that our current rendering system, and its >associated internal layers is still under construction, makes >almost impossible to begin working on dpi2, and on the other >hand, gives an excellent oportunity to focus on dpi1 (that's also >expected to be easier to program with). - Thorben

18 years, 11 months

Re: [Dillo-dev] Dillo Windows port

by Andreas Schweitzer

Hi, although I'm not a main developer, I think I can answer a bit. > I have Dillo built now as a native Windows VC++ 6 project and am debugging > it. cool ! > Dillo uses pthreads and fork. Wouldn't it be better to use one multi-process > API? Shouldn't it be all pthreads? Of course, there is no fork under In the current CVS version I only found one reference to fork and it was to start a plugin. Currently, this is no longer used and is dead code. However, some way of starting the dpid automatically will most likely return - for the current CVS version this dpid has to be started manually. But either way, the plugins and the dpid are totally seperate programs. dpid is designed to only be started once. This functionality should be reproducable in Windows, I'd say :-) The other fork's are within the plugin framework when the dpid actually starts the requested plugin. You probably can delay that framework. Dillo will still work - with limited functionality. > Although Berkeley sockets are available in Windows, the AF_LOCAL protocol > doesn't seem to be. I've faked that out to get Dillo to compile but more > work may be needed there. Why are you using AF_LOCAL? What does that code do > and why? It's again related to plugins :-) ... dillo talks to its plugins via unix domain sockets. And that's what this code relates to. If you only need a help browser, you can ignore the plugin framework I would say. That way you will get no bookmarks, though. And the preferences are also planned to be done via a plugin. Or at least delay the plugin stuff until it matured. That's the cool part about the plugin design :-) I hope that helps, 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] dillo&sylpheed

by Todd Slater

On Tue, Jul 29, 2003 at 10:26:22PM +0800, ronnie wrote: > hi all! > > how can I embedded dillo into the sylpheed? > > can someone have done it and give me some advice or resourse? > > thanks! Hi, I use Sylpheed-Claws and it is a matter of enabling the Dillo plugin (do "./configure --help" to see all the options--I think you want --enable-dillo-viewer-plugin IIRC). After you install claws, you have to "turn on" the plugin. Go to Configuration > Plugins and Load the plugin (mine is in /usr/local/lib/sylpheed/plugins--yours may not be depending on how you installed claws). HTH, Todd -- Name that tune #10: Now a very great man once said that some people will rob you with a fountain pen; it didn't take too long to find out just what he was talking about.

21 years, 3 months

dpid

by Ferdi Franceschini

A new version of the plugin manager for dillo (dpid5) is now available at http://www.geocities.com/ferdif2003/ * dpid now scans a dillo plugin directory structure for available plugins. * the main function has been refactored to make it easier to understand and easier to extend with new dpid commands. * the test suite has been restructured so that it is now easier to test inividual modules and functions in a test environment with dummy clients and servers. TODO There is still no code to integrate new plugins into dillo. You still have to kill and restart dpid when new plugins are added. Ferdi

21 years, 3 months

Dillo Support for Flash plugins

by Xyber Blue

Hello poeple, Good day, Is there anyone here who tested the dillo with flash plugins??? I just want to know if dillo is already supporting this kind of plugins. If not, is there any plan to support flash player plugins for dillo???

18 years, 11 months

Firefox bookmarks plugin

by Rodrigo Arias

Hi, Here is another small plugin to sync bookmarks with Firefox Sync: https://github.com/dillo-browser/dillo-plugin-ffbm It uses the ffsclient program to connect to the Firefox Sync server and a few lines of shell script for plumbing. It replaces the builtin bookmarks plugin when installed, so all menu buttons work as expected. Best, Rodrigo

2 months, 3 weeks

Re: Firefox bookmarks plugin

by Diego

Good work and very interesting idea. 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 # protocols DPIs proto.file=file/file.dpi proto.ftp=ftp/ftp.filter.dpi proto.data=datauri/datauri.filter.dpi # dpid uses this line when no line for a protocol is found in this file proto.*=misc/ProtocolNotSupported.filter.dpi Thanks for all the work cheers! Diego. El dom, 25 ago 2024 a las 21:55, Rodrigo Arias (<rodarima(a)gmail.com>) escribió: > > Hi, > > Here is another small plugin to sync bookmarks with Firefox Sync: > > https://github.com/dillo-browser/dillo-plugin-ffbm > > It uses the ffsclient program to connect to the Firefox Sync server and > a few lines of shell script for plumbing. It replaces the builtin > bookmarks plugin when installed, so all menu buttons work as expected. > > Best, > Rodrigo > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

2 months, 3 weeks

Development

by Carlos Daniel Ruvalcaba Valenzuela

Hi everyone It sems i lost a lot of the development cycle, now even plugins are implemented! Anyways, here is my wasted effort with dillo-0.7.3: * Fixed dpi.c capi.c, to handle launching multiple dpis via url, example dpi:/bm/ will launch bookmarks plaugs, dpi:/cfg/ will launch the configuration plugin. * Worked on dpilib a bunch of code to initialize comunications from a dpi to dillo, it works pretty well, also handles tag params, and url passed vars. * ddm_srv.c Dillo Download Manager, a download plugin using wget, will be able to download multiple files and show their progress in dpi:/ddm/downloads * cfg_srv.c Configuration, It can tweak a bunch of options for Dillo and DDM. Way back about a month i worked on a plugin daemon too. But with current changes i maded the daemon is not necesary, also dillo can load plugins if necesary. Any comments?, anyone wants the patches? Anyway, cheers. Carlos Daniel Ruvalcaba Valenzuela --------------------------------- Do You Yahoo!? Yahoo! Net: La mejor conexión a internet y 25MB extra a tu correo por $100 al mes.

21 years, 1 month

Re: about feedback

by Indan Zupancic

Hi, To clear up some things to avoid misunderstandings: I will continue keeping the https patch up to date, no matter what else I'll do. As there seems to be enough demand, I will update the installer once a while too. > Sometimes, it took quite some time before Jorge looked at the patches and > fixed or accepted (or rejected) them. I had zero feedback the last 3 weeks, not very motivating. Merely a short email to say that it will be looked at or that it has no priority would be appreciated, I mean, _any_ feedback is. Now it's just a black hole where you pour patches into. Don't forget that it's their program you spend time writing a patch for, but currently it feels like it's a privilege to have your patch integreted in Dillo, even expecting some feedback is asked too much for. May I come to the conclusion that I should spend my time on something else instead of wasting it on Dillo? If they aren't willing to spend 10 minutes writing a short email, why should I spend hours or even days writing and testing some Dillo patch? I don't expect the Dillo developers to just integrate my https patch or so, I wouldn't either without a lot testing and making sure it's stable, but I would expect that they give some feedback about it, I mean, it's their program, they wrote it, so I would expect that they know the code better, so could give good advice about pitfals etc. Or just simply say "no, we don't like your approach, let us keep using wget for https". But for the IO.c patch it's a different case, all it is is a cleanup of their code, naive as I am, I would expected them to want cleaner code, even if it's a small step like I made with the patch. > Anyways, that's how it works here. I got used to it. Working with one feedback per month is impossible if you want to do major IO cleanups as I want. > However, the core developers probably need to read all mails and keep track > with a whole lot more patches - therefore, even they may miss one or two > patches/suggestions. Whole lot more patches? Looking at the CVS activity then I'm not too sure. Also there is a reasonable amount of old patches for Dillo already: multiple https implementations (I only found the last one when I started on mine), UTF8 support, server/client mode, and other I can't remember/didn't found. And looking at the mailing list, they didn't get much feedback either. All those people hooked off as far as I can tell, except Frank. > So, please stay with the project ... hmmm ... some semi-serious > suggestion ;-) : do some christmas shopping, enjoy the holidays > and wait for the feedback from the developers ...:-) Christmas shopping? Need money for that I suppose. Enjoy the holidays? Have no job, so it's always holiday for me ;-). And don't know where you live, but christmas is just a commercial paradise here. > However, overall, I like the dpi idea. There are certain advantages: As with many things, the idea is good, the implementating isn't, IMHO. > - For me, it makes it rather easy to contribute, since I need to only > write a program and not to dig through dillo's code (if only I did > write more than my simplistic finger plugin ;-) ...) True, but if I look at the default plugins they're not as easy to make as it should be. > - The concept of extra processes instead of extra code has advantages : > - with the download plugin being a seperate process you can even log > out of X while the download continues (e.g. over night on dial-up). That is true. I don't know if you noticed, but if you want to use the current download plugin, you need to start up 3 processes... First, the dpid, then the download dpi, which in turn starts wget. I'm so naive to think it could be only wget, with a simple "handle this protocol with this program with this parameters in this way" system. This way you could also startup your favourite email program when encountering mailto:, to give just one example. Don't forget that there is specific code in Dillo to handle certain plugins like the bookmark and download plugins. The plugins aren't really standalone. Sure, it's not finished yet, but the current dpi system can't solve that problem. What I would do is make a clear library plugin api, then you can implement the download and bookmark GUI in a library, and let the library start up wget. You can even implement a library plugin that handels the dpi plugins, instead of adding the code to Dillo's core as now happened (I mean moving the dpi code into a library plugin). This way you can have relative simple and small library plugins that don't do much, which let external programs like wget do the real work. Or add the features directly in the library plugin, whatever you want. > - the bookmark plugin allows for a real bookark server ! This is something > I am contemplating about : wouldn't it be cool if you could access the > same bookamrks from different machines via a sophisticated bookmark server > ? No, it doesn't. Not with the current dpi system anyway. As I said in an earlier email, the bookmark plugin should probably be a real, standalone daemon, so that it can also be used with other browser, from different pc's. It can even be hosted by some site, so that wherever you go, you can get your bookmarks :). Of course Dillo could have special support for it, so that it's easier to add bookmarks, and that it's started when it isn't running yet, but the main point is that the bookmark server won't be a dpi plugin, or can't be because you can't use unix sockets as the current dpi system uses now (which is fine for a plugin system, but not when you want to connect to non-local pc's). Greetings, Indan

20 years, 11 months

New dpid patch

by Ferdi Franceschini

There is a new dpid patch for dillo-0.8-pre available from http://www.geocities.com/ferdif2003/ Plugins are now stored in a directory structure under libdir/dillo/dpi. You need to put dpi_dir=/usr/local/lib/dillo/dpi in ~/.dillo/dpidrc so that dpid can find the plugins, there should be no other entries in this file. Dpid now uses a .filter suffix in the plugin name to identify plugins which read and write to stdio (eg hello.filter.dpi). The following changes affect the CVS repository: Renamed dpiddir.[ch] to dpi_socket_dir.[ch] New files dpi_service.[ch] Cheers, Ferdi

21 years, 2 months

Dillo-dev search results for query "plugin"