Search results for "plugin" - Dillo-dev

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

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.

Jan. 12, 2010

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

July 2, 2010

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

May 20, 2013

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

April 2, 2009

Re: FLTK 1.3.0 RC 1 released!

by jcid＠dillo.org

On Mon, Dec 27, 2010 at 05:45:20PM -0900, rogerx.oss(a)gmail.com wrote: > Dunno about the *other* distros, but Gentoo has several versions of FLTK > available including 2.0_pre branch. And, somebody has volunteered a > FLTK-1.3_rc1 ebuild on bugs.gentoo.org. > > Dillo is extremely important on all my platforms as I use Intel P3 CPU's. That's soothing to hear. > Using any other browser, and I'm just wasting my CPU cycles with unneeded html > scripts -- even with noscript & no-ads plugins for Seamonkey! > > Maybe hook-up with the FLTK mailing list to see if they're really going to push > 1.3? They're committed to it. I've posted some links to their forums from time to time. > From what I read a week ago, they're devoting all efforts on 1.3 and > deprecated 2.0 branch. 2.0 branch might get it's features ported to 1.3. In a nutshell: 2.0 is dead. The remaining developers agreed to cuncur on 1.3 long ago, and to try to release near Christmas (still in the ballpark). -- Cheers Jorge.-

Dec. 28, 2010

Re: RFC repository

by Rodrigo Arias

Hi, On Sun, Jul 07, 2024 at 02:08:30PM -0600, pastebin(a)gmx.com wrote: >Rodrigo this looks pretty amazing Thanks! >are you thinking along the lines of a plugin that will take for example on the page >https://github.com/dillo-browser/rfc >the drop down box - when viewed with dillo gives > >Product >Actions >Automate any workflow >Packages >Host and manage packages >Security >Find and fix vulnerabilities >Codespaces >Instant dev environments >GitHub Copilot >Write better code with AI >Code review >Manage code changes >Issues >Plan and track work >Discussions >Collaborate outside of code >Sun, 7 Jul 2024 20:53:34 +0200 >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >and put them into a drop down box? Yeah, that would be one of the use cases: HTML content rewriting. I think it would be easy to have a community maintained repository of rules to "fix the web" so it can be read by Dillo more easily. For now you can use the raw Markdown version to read it from Dillo: https://raw.githubusercontent.com/dillo-browser/rfc/rfc-002/rfc-002-rule-ba… Best, Rodrigo.

July 7, 2024

Dillo-dev search results for query "plugin"