Search results for "plugin" - Dillo-dev

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.

14 years, 10 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, 4 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, 5 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.-

15 years, 7 months

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

13 years, 10 months

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.

4 months, 1 week

[PATCH] startup window

by Johannes.Hofmann＠gmx.de

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 - check the date :)

15 years, 7 months

Re: [Dillo-dev] [PATCH] version 6 of Dillo tab patch now available!

by Ralph Slooten

Although I'm not a developer, I am a regular user of dillo, and live off it's cvs ;-) May I just conclude that I just love this patch! Thanks, as it makes my life easier I find, and even though I use fluxbox, with tabs (so I already had usage of tabs to a point), I much prefer this method of doing it. Actually I'm running dillo at the moment with 3 separate patches: This one (tabs) External helpers patch (alowing quick starts to the page with a bigger browser which supports the pages dillo cannot render [plugins, css, java, so on]) and lastly the ssl patch (modified due to the tabs patch) My question is this to the dillo developers: Are these patches staying as patches, or is there any consideration to impliment them (or some of them as there are more) as optionals for the future? What I mean "as optionals" is default off, but optionally built in. Thanks again Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

21 years, 3 months

Re: [Dillo-dev] Loosing bookmarks

by Jorge Arellano Cid

On Wed, 26 Feb 2003, Phillip Warner wrote: > On Wed, 26 Feb 2003 10:17:14 -0300 (CLST) > Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > > The patch: > > > > This patch does two things: > > > > 1.- Keeps a backup of the bookmarks file: bm.txt.bak > > 2.- Avoids not loading the bookmarks file by issuing a > > conditional load before any operation. > > > > Notes: > > * The backup file is made by renaming the original file, so > > if a write error happens the backup remains! > > * The backup is made when the original file has a size greater > > than 256 bytes (just in case!). > > > > > > Please test it as hard as you can. > > > > The test was successful on my end. However, if I kill the server with > -9, the pipe remains and the server will not reload. If I then remove > the pipe, the server loads and responds "Hi browser" but no bookmarks > are written. If I then try to access the bookmarks, I get a blank > page. If I then close dillo, the server also stops. > > Of course, after reloading dillo all is well. > > But, no bookmarks are lost, except the ones that were chosen after the > server was killed. > > Is there a way to overwrite the abandoned pipe (when no server is > running) when restarting the server? I know sylpheed does this. Yes, this situation is problematic. Besides the 'kill -9', a system crash can also leave the socket's filename in /tmp... and the trouble only ends when the user realizes he must remove the socket's filename manually! After some thought, I finally found a way to check these problems using connect(). I'm not sure which error code (errno number) the different OSes will return, so I included: ECONNREFUSED, EBADF, ENOTSOCK and EADDRNOTAVAIL. GNU/Linux returns ECONNREFUSED in this case. ...and I almost forgot that sometime ago (Nov 27), Ben Wolley wrote: > Hello Jorge, > > I just tried out the dpi1 bookmarks plugin, and I really like the concept. > But I started wondering if someone could take advantage of a dpi URL to do > something improper. > > <html> > <body> > <a href="dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&sub > mit=submit.">test</a> > <img src="dpi:/bm/modify?operation=add_url2&title=home2&url=http%3A%2F%2Fhome&submit=submit." > alt="test image"> > </body> > </html> > > When I load that page, not only does the image alter my bookmarks, when I > click on the link the window closes (after altering my bookmarks). This > seems to be an issue similar to what is discussed in the HTTP 1.1 spec > section 15.1.3. > > Can POST data be sent instead? Section 9.5 says that POST should be used > for "extending a database through an append operation", which is what the > plugin actually does. A hacked dpi-request using POST can also be faked, so the decision was to only allow dpi-urls from dpi-generated pages. The attached patch (against dillo-0.7.0) does five things: 1.- Keeps a backup of the bookmarks file: bm.txt.bak 2.- Avoids not loading the bookmarks file by issuing a conditional load before any operation. 3.- Takes care of EINTR while in recv(). 4.- Tests the socket's filename to be responsive and relaunchs the server if necessary. 5.- Allows dpi-requests, but only from dpi-generated pages. Most probably this will be the patch in the bug-fix release. Once again, please test it throughly! Cheers Jorge.-

21 years, 8 months

Re: [Dillo-dev] Re: https dpi

by Madis Janson

On Mon, 3 Nov 2003, Jorge Arellano Cid wrote: > On Sat, 25 Oct 2003, Madis Janson wrote: > > > Also, there seems to be one process for one connection, which makes hard > > to implement SSL session cache. > > Yes, that happens with dpi filters. The idea in this case is to > have an http dpi that's able to handle several connections at the > same time (like the downloads dpi). That is: a dpi server instead > of a dpi filter. With that scheme session cache is easy to > implement. > > (and BTW much easier for the developer because he can arrange > things much more freely than when patching inside dillo). > > > content-type > > (as above). > > The https dpi would need to listen the HTTP stream and so has > access to the content-type sent by the remote https server. > (http://article.gmane.org/gmane.comp.web.dillo.devel/1407) if someone would create non-ssl dpi proxy plugin (that just makes http requests), i will add the ssl part to it (i have working ssl proxy code, which currently works using a patched dillo).

20 years, 9 months

Dillo-dev search results for query "plugin"