Search results for "plugin" - Dillo-dev

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

On Fri, May 27, 2011 at 3:53 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Fri, May 27, 2011 at 03:25:32PM -0500, reza farivar wrote: > > On Fri, May 27, 2011 at 3:18 PM, Jorge Arellano Cid <jcid(a)dillo.org> > wrote: > > > > > On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote: > > > > On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson < > > > obeythepenguin(a)gmail.com > > > > > wrote: > > > > > > > > > On Fri, 27 May 2011 13:38:43 -0400, reza farivar < > > > rf.opensource(a)gmail.com> > > > > > wrote: > > > > > > > > > > Yes. Well, the only plugin I could see is the save button on the > > > panel, > > > > >> and > > > > >> it can successfully navigate the filesystem and save a page > correctly. > > > > >> > > > > > > > > > > That one isn't a plugin, actually. Does the bookmarks button work? > > > > > > > > > > Yes, bookmarks work. (This is a bit of strange implementation of > > > bookmarks, > > > > no? took me a bit to find out difference of section and item) > > > > > > Good! > > > > > > If you can see the html page from the bookmarks, it means the > > > whole dpi framework is working on Mac; they communicate using > > > sockets. > > > > > > So it seems the main thing pending is socket support in fl_wait > > > for Mac (see my previous email). > > > > > > > Yes, I also think it's the source of this problem (see my other email). > > > > But what really perplexes me is that this happens only when I enter a URL > > manually. When I follow links from one page to another it never happens. > Are > > you guys using different (FLTK) functions when opening a new page or > > following a links (whether in the same tab or in a new tab)? > > No, but when you hit ENTER, FLTK has a chance to queue events > and zero-wait timeouts for the widget callback and necessary > stuff. OTOH, clicking a link goes another path (inside dillo). > > Can you point me to parts of code for either of these two code paths? Filename / line number should suffice. > > > And it seems that as Dillo "warms up" I get less of this problem... > > Timimg issues are moody. > e.g. Have you tried dillo listening a good mp3? :-) > > BTW, good you asked Manolo G. > (FWIW, FLTK2 has code for socket events in Mac). > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

May 28, 2011

[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.

Dec. 15, 2012

Re: Error when opening local html file

by Rodrigo Arias

Hi, On Sun, Jul 12, 2026 at 09:01:04PM -0400, Nikolas Nyby wrote: >Hello, >I couldn't find a bug log for this already, or maybe I am doing >something wrong. > >On current git master, I add this to the address bar: > file:///home/nik/Documents/margin-test.html > >The file fails to load. Also, when using the menu: >File -> Open File... dialog, which inserts this into the address bar: > file:/home/nik/Documents/margin-test.html > >and displays the error: > > ERROR: can't start dpid daemon (URL scheme = 'file')! Have you installed dillo in its prefix (make install)? This is often a symptom that you are running it directly from the build directory and is not able to find the plugins. Otherwise, please provide more details to reproduce this and the full execution log. Best, Rodrigo.

July 13, 2026

--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

May 18, 2009

[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.-

April 11, 2008

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

July 6, 2010

[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.

April 1, 2009

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

Nov. 8, 2024

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.

Nov. 8, 2008

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

July 30, 2024

Dillo-dev search results for query "plugin"