Search results for "plugin" - Dillo-dev

youtube-dl

by bobh＠n-cantrell.demon.co.uk

In article <20100704010103.GB2019(a)local.gobigwest.com>, corvid <corvid(a)lavabit.com> writes >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 Sounds interesting - but prone to be a long labour in the night... All I really want is a crisp way to get the alphanumeric file- descriptor safely away from the youtube window and into a youtube-dl call - cut and paste would be a significant improvement on copying it, usually incorrectly, character by character Bob -- robert w hall

14 years, 4 months

[PATCH] startup window

by corvid＠lavabit.com

Thomas wrote: > 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... I agree with Thomas here.

15 years, 7 months

Re: Testing without Dillo

by Schimon Jehudah

Good day, Rodrigo. It works! $ printf "<cmd='auth' msg='123456' '><cmd='open_url' url='gemini://woodpeckersnest.space/~schapps/' '>" | ./gemini.filter.dpi Thank you, Schimon On Thu, 7 Nov 2024 21:44:20 +0100 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Thu, Nov 07, 2024 at 05:49:37PM +0200, Schimon Jehudah wrote: > >Is it possible to run Dillo plugins without installing them? > > Try: > > $ printf "<cmd='auth' msg='123456' '><cmd='open_url' url='foo://bar' > '>" | ./foo.filter.dpi > > You can usually ignore the auth part. The response must look like: > > <cmd='start_send_page' url='' '> > Content-type: text/html > > <!DOCTYPE html> > <html> > ... > </html> > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

1 week, 1 day

Unveil discussion: TO-DO list

by a1ex＠dismail.de

Hi Rodrigo, Here are my initial thoughts on your review. Some of the stuff I will need help with, the rest I can probably manage on my own: On Sun, 28 Jul 2024 22:45:38 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > I recommend you add a configure switch (in configure.ac) to enable or > disable unveil(). By default you can keep it disabled and let the > user enable it manually, until we have more feedback to make it > enabled by default. Maybe by defining ENABLE_UNVEIL? You can take the > --enable-svg and ENABLE_SVG as an example. Ok, I think I can handle that. > You should also make a dillorc configure option to enable/disable the > unveil feature in runtime, so it can help debug problems. You can > make the dillorc option enabled by default, which will only take > action when unveil support has been compiled in. For dillo.cc that shouldn't be too hard. I would probably have more difficulties with with the plugins though. > The download directory is set in the dillorc configuration file, and > can be any other place. Is it viable to read the configuration first > and then unveil the appropriate directory? Got that partially working, but ran in to some challenges, see my earlier message. > You'll want to use the $(sysconfdir) autoconf variable: I can take a look, I didn't really consider portability at all since unveil is exclusive to OpenBSD, and will probably remain that way for some time. > As this won't be a simple patch, I suggest you open a PR in GitHub, > so the CI can compile your patch revisions for multiple platforms and > pass the tests. Otherwise I would have to spend the time to do it > myself. If this patch gets to a point where your concerns here are addressed, I will consider it. > The err() function is non-portable, please use Dillo MSG* macros or > perror() + exit(). This should be caught by the CI. > > Also, ensure the indentation is kept at 3 characters (not my > decision). Ok, that shouldn't be a problem. > You should find wget by locating it in the $PATH, not assuming it > would be here. Users may place their own wget binary somewhere else > and this would break the downloads. Will look at it. This brings up a completely separate question: why is wget hardcoded and not changeable as the downloader, and also has a hardcoded useragent which can't be changed by the user. To me, that's not ideal, and maybe you have some thoughts on it. > The .Xauthority file should be read from $AUTHORITY and then from > there if not set. I will try :) > Not sure if we want to constraint file:// like this. What if we are > using Dillo to read local HTML files in ~/? Would you prefer to just not do any unveil in file.c then? It's probably not a huge risk. > Plugins can also be found on the dpi_dir directory defined by the > user in the .dillo/dpidrc, so we would need to parse it first. I will look at it, but this could be more difficult for me. > I would also protect dpidrc from writing as well as dillorc. Agreed. No problem. Regards, Alex

3 months, 2 weeks

Re: [Dillo-dev] Serious Memory Allocation Strategy Problem in Cache_parse_header()

by R.L. Horn

On Thu, 7 Sep 2006, Jorge Arellano Cid wrote: >> (Actually, this is functionality that would be nice in the main branch, >> albeit with its own plugin and user-selectivity. If there's interest, >> please let me know.) > > Yes, more or less this is the plan. Great! > OK, a good workaround is to check for huge filesizes while parsing the > header and to set as if no Content-length was given in that case. This > is simple and will work. That's kind of what I did. Actually, I just removed the code that had to do with static buffers entirely (while still allowing for a Content-length check). If the GTK branch weren't pretty well deprecated, I'd go ahead and do it right: Add a boolean to the "entry" structure to indicate a fully allocated buffer and complete the allocation (where reasonable) at dispatch time.

18 years, 2 months

Feature Request

by Beartooth＠swva.net

On Sat, 8 Nov 2008, Johannes Hofmann wrote: > Hi, > > On Sat, Nov 08, 2008 at 03:40:08PM -0500, me at swva wrote: >> >> Dillo, alone of all browsers I know, cannot handle "www.site.xyz.com," >> by simply converting it on the fly to "http://www.site.xyz.com" > > It works fine for me. > Do you have an example where it doesn't work for you? > What version of dillo are you using? Iirc, it has *always* done this to me, on all machines, for years out of mind, on all URLs. Just to check, I did this as root : [root@Hbsk2 btth]# rpm -q dillo dillo-0.8.6-7.fc9.i386 [root@Hbsk2 btth]# yum update dillo Loaded plugins: refresh-packagekit updates-newkey | 2.3 kB 00:00 updates | 2.6 kB 00:00 fedora | 2.4 kB 00:00 Setting up Update Process No Packages marked for Update [root@Hbsk2 btth]# -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

16 years

Re: [Dillo-dev]Using dillo on SourceForge

by Diego Sáenz

> > 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. can you give a url to test it? thanks > > Hmm, what's the status of the cookies dpi? It is almost done, but i need an answer to a big doubt before it. how can a function wait(with a timeout if posible) until the cookies dpi send the answer to dillo after dillo have send to dpi cookies a get_cookies command? more explained: the a_Cookies_get function in dillo send a get_cookies command to cookies dpi, then wait a command from the cookies dpi with the answer and the function return the cookies. I have try to do the same that bookmarks dpi but the function used in it is void. I have try to understand ccc but i get it only superficialy. DarkSpirit/Diego

19 years, 6 months

[Dillo-dev]dpi preferences suggestion

by David McKee

Folks, I've been thinking a little about my comment the other day to the effect that I prefer more contrast in list views than the new file:// dpi's table mode provided. I wondered if that might be a reasonable candidate for a configurable preference. It's not clear that it is, but it got me thinking about handling preferences in dpi. I suggest that we don't want every dpi implementing it's own preferences scheme. So dpid should handle reading in any preferences for dpis, and pass them to the plugin. The simplest method would be to set environment variables in the new processes execution environment. If we are willing to tolerate having preferences read in only at startup (as with the main program right now) that is the whole of the problem. For reading user preferences from disk we can presumably use the same code that is current employed to get the dillo preferences... Any thoughts? Cheers, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

20 years, 3 months

Re: [Dillo-dev]Is IO.txt outdaetd?

by Jorge Arellano Cid

On Mon, Aug 09, 2004 at 03:18:47PM +0800, Calvin Yu wrote: > It says dillo uses threads for DNS querying and reading local > files, and signal driven I/O for TCP connections. When the socket > gets ready for transmission, the data is sent using > g_io_channel_write. But I can't not find the place where > g_io_channel_write is invoked in the code. Ok, I updated it. Beware that it's not an exact explanation of what happens inside Dillo today. Anyway, it continues to be an excellent source of information that describes the theory behind the code. Beware that the plugin system is not described in IO.txt and that the latest patch moved the "file:" protocol to a dpi, so it's not handled with a thread and a pipe inside Dillo anymore. Anyway, the thread and pipe pair is the basis for the generic dpi data stream transfer, so the theory in IO.txt will explain it to some extent. -- Cheers Jorge.-

20 years, 3 months

Re: [Dillo-dev] Using Dillo as google search frontend.

by Diego Sáenz

This old mail can be interesting for you: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-January/000078.html External donloader is now unecesary, but it took me 5 minutes to update and test. Updated and corrected patch in the atachment May be a page with list of dillo pathes can be usefull. Diego. El Sun, 05 Mar 2006 01:09:52 +0900 Jun OKAJIMA <okajima(a)digitalinfra.co.jp> escribio: > > > Hello. > > What I want to do is like this. > > 1. Googling with Dillo. > 2. Then, a search result screen comes. > 3. When click a result, firefox starts and shows the page. > > What I want? > I want to google with a very fast browser(= dillo), > but browse other pages with full browser with plugins(=Firefox). > > Is this possible? > > --- Okajima, Jun. Tokyo, Japan. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

18 years, 8 months

Dillo-dev search results for query "plugin"