Search results for "plugin" - Dillo-dev

[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

hyphenation in dillo

by sgeerken＠dillo.org

On Wed, Nov 07, corvid wrote: > Sebastian wrote: > > On Mon, Sep 10, corvid wrote: > > > I was looking at the src for http://distrowatch.com , and the > > > source page is very wide -- wider than any lines, so far as I > > > could see. > > > > There is one line, which is very long (number 54), but the current > > release breaks this line into multiple ones. Can someone provide > > details about the vsource plugin? > > The vsource page has > <style type="text/css">PRE {white-space: pre-wrap} > and the css2 spec says > "If 'white-space' is set to 'pre' or 'pre-wrap', any sequence of spaces > (U+0020) unbroken by an element boundary is treated as a sequence of > non-breaking spaces. However, for 'pre-wrap', a line breaking opportunity > exists at the end of the sequence." So "pre-wrap" can be broken. Fixed. Sebastian

Nov. 8, 2012

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). > > That can explain it. Well, then your patch might have a chance, if it's not really a socket issue. I'll give it a try later tonight. > > > 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). > > Yes, I found it in FLTK2. It turns out fl_wait in FLTK2 (in src/osx/run.cxx) is a complex function, while the equivalent incomplete function in 1.3 only a couple of lines. I think it's best let FLTK guys handle it. -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

May 27, 2011

Dillo + Partial Javascript Support

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 alsa F wrote: > Rather than somebody trying to get full Javascript suport for Dillo, I was thinking along the lines of partial Javascript support. The bare minimum would be to access websites that use Javascript to allow logins to forums etc. If any more functionality could be added so that for example social network sites like facebook or bebo then that would be great.On a personal note, I don't mind the lack of CSS when displaying pages on Dillo due to the small screen size of the minibook so any Javascript concerning that is not necessary. There are several free ecmascript interpreters available, choosing one of them and putting it into a dillo plugin is the easy part. But in order to be useful the script needs the ability to manipulate the page content. And designing that part right is hard... Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkndo70ACgkQoPmwNWhsaZYfHgCeIIA+fSBS9AZJTk93OeAUpIiG OIAAn38AnWLOAm1BgrHjKWkLLkexgIvM =USWg -----END PGP SIGNATURE-----

April 9, 2009

IPv6 and HTTPS (Re: release candidate for dillo-3.0.2)

by Johannes.Hofmann＠gmx.de

On Sat, Dec 03, 2011 at 09:23:41PM +0000, corvid wrote: > Axel wrote: > > IPv6 and HTTPS seem both to work independently, but HTTPS over IPv6 > > does not work. An example host would be the IPv6-only reachable server > > at https://jumper.deuxchevaux.org/. (Submitted to the bug database as > > bug #1023.) > > > > The same host with just HTTP (http://jumper.deuxchevaux.org/) works > > fine as well as does a randomly chosen (IPv4 :-) HTTPS website. > > > > OTOH with 3.0.1 it looks very similar and doesn't work either with > > IPv6 + HTTPS, so I think it's "just" a bug in Dillo, but not a > > regression in 3.0.2. :-) > > Is anyone in a sufficiently IPv6-ed environment that they can dig into > this at some point? I doubt it's worth making the current experimental HTTPS plugin IPv6 ready. We will need a more robust HTTPS solution at some point. Cheers, Johannes

Dec. 3, 2011

Dillo-dev search results for query "plugin"