Search results for "plugin" - Dillo-dev

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, 4 months

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

8 months

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

12 years, 4 months

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

15 years, 11 months

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 >

13 years, 10 months

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

13 years, 4 months

Cookies performance

by corvid＠lavabit.com

Johannes wrote: > On Tue, Jan 12, 2010 at 05:42:03PM +0000, corvid wrote: > > Johannes wrote: > > > I noticed that since the recent DPI update pages which use > > > cookies load slower (e.g. fltk.org) > > > Do others also see that? It could also be OS specific. > > > > I thought it seemed weirdly slow _sometimes_. > > I'll have to throw some gprof at it and hope for something > > simple and embarrassing. > > > > (I wonder whether it would be easy to do valgrind with dpid and the > > plugins.) > > I did some truss on the cookies dpi and found that it is reading > ~/.dillo/dpid_comm_keys quite often. Maybe that is related. It looks like it checks it through a_Dpip_check_auth() when it gets or sets a msg. As for whether it needs to, I don't know. I tried a little gprof, but a modest amount of browsing and accepting cookies wasn't enough for the dpi to use up enough time for gprof to generate stats.

15 years, 2 months

youtube-dl

by onepoint＠starurchin.org

robert w hall wrote: > Would it be 'easy' to turn youtube-dl (written in python) into a > dillo 'plugin'?? That's a fun idea! I'm a big fan of youtube-dl. But I'm not sure what you're suggesting. My dream would be to click on an embedded youtube video and have the download dpi (or something else like it) pull down the video. The problem is that, last time I looked at any rate, dpis are invoked by specific URL schemes. What I'm thinking of would require dillo to invoke dpis when it sees particular bits of HTML. That might be non-trivial to implement. As a side question, how much work would it be to get dillo to render <embed> and <object> elements in a useful way? Now there's a thought! How about if dillo rendered them as clickable boxes linked to some URL like embed://?html=<escaped_html>? Then they could be handled by a dpi that might eg. extract Youtube video URLs and run youtube-dl! Does this sound feasible? Regards, Jeremy Henty

14 years, 9 months

dillo bug#1127

by Johannes.Hofmann＠gmx.de

Hi, On Mon, May 20, 2013 at 02:07:54PM +0200, Urban Lundin wrote: > Hi Johannes, > > That sounds great if you could attempt to solve this issue! > We have made a small example in TCL/TK (which you have to install > first, available through http://www.tcl.tk/) > > We did not try to embed suckless as we could not find a simple > example inside it. > > > Then the example is below. Thanks for the example. For me it works with the following patch for dillo: diff -r ace33e3969af src/xembed.cc --- a/src/xembed.cc Sun Apr 28 15:11:03 2013 +0200 +++ b/src/xembed.cc Mon May 20 19:38:06 2013 +0200 @@ -108,6 +108,7 @@ createInternal(xid); setXembedInfo(1); Fl::event_dispatch(event_handler); + Fl_Window::show(); } void Xembed::createInternal(uint32_t parent) { Before pushing it to the main repo I need to read http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html a bit more, but to me it seems a reasonable thing to do. It would be cool, if anyone using the claws mail dillo plugin could verify that the above patch doesn't break embedding in claws mail. Cheers, Johannes

11 years, 10 months

[PATCH] startup window

by jcid＠dillo.org

On Wed, Apr 01, 2009 at 04:49:44PM +0000, corvid wrote: > 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. Me too. -- Cheers Jorge.-

16 years

Dillo-dev search results for query "plugin"