Search results for "plugin" - Dillo-dev

Connection problems on Mac OS X 10.6.7

by jcid＠dillo.org

On Thu, May 26, 2011 at 03:42:04PM -0500, reza farivar wrote: > On Thu, May 26, 2011 at 3:18 PM, Johannes Hofmann > > > [...] > > Did you take special care to compile fltk-1.3 with X11 backend? > > If not, you might run the dillo as native Cocoa application. > > In that case you were more successful then me. > > For me dillo with Cocoa-fltk starts, but does not load any remote > > pages. There seem to be severe issues with the way fltk handles events > > in the Cocoa case. > > > > Hmm, maybe I should try recompiling fltk with X11 backend...But my current > native version is so close to working with no problems... Yes, it's amazing how close it is from working native. Are plugins working OK? (e.g. can you browse the filesystem?) Do you know how to use gdb? It would be great to know in what functions the busy wait happens. It could be a timeout or anything. For this: gdb ./dillo <when locked on high CPU usage, hit Ctrl-c> bt This can hint us on what may be happening. -- Cheers Jorge.-

May 27, 2011

--xid option

by jcid＠dillo.org

On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote: > 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. This is very good. I'll have to dig for the sylpheed contact to let them know. Does anybody here know the email? -- Cheers Jorge.-

May 19, 2009

dpi problem

by Teddi Vazquez

Hello, I'm trying to add the plugins for gopher and gemini, when i run the "make install" the next message appears in both: echo 'proto.gopher=gopher/gopher.filter.dpi' >> /root/.dillo/dpidrc dpidc stop || true ** ERROR **: [Dpi_read_comm_keys] No such file or directory ** ERROR **: main: Can't read dpid's port number mkdir -p ~/.dillo/dpi/gopher cp -f gopher.filter.dpi ~/.dillo/dpi/gopher I read the docs and thought maybe it was because the "dpi_dir" option wasn't added: "dpi_dir=~/.dillo/dpi/" but when I run dillo on the terminal this appears: prefs: {dpi_dir} is not a recognized token. paths: Cannot open file '/home/tmv/.dillo/keysrc': No such file or directory paths: Using /usr/local/etc/dillo/keysrc paths: Cannot open file '/home/tmv/.dillo/domainrc': No such file or directory paths: Using /usr/local/etc/dillo/domainrc I'm sorry if this obvious error, if possible I would like to receive some help, thanks. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GC/CS/H/IT/L/M/P/S/SS/O d- s+: a? C++++ UL++++ P+ L+++ E+ W+++ N+ o- K++ w O-- M V- PS+++ PE++ Y+ PGP++ t+ 5+ X+ R tv b++++ DI--- D+ G++ e* h! r- x* ------END GEEK CODE BLOCK------ GPG: 37219EA0D04C8D3C Keybase: tmv

June 15, 2026

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

by jcid＠dillo.org

On Sat, Dec 03, 2011 at 10:41:50PM +0100, Johannes Hofmann wrote: > 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. Ditto. -- Cheers Jorge.-

Dec. 4, 2011

--xid option

by Johannes.Hofmann＠gmx.de

On Wed, May 27, 2009 at 05:25:15PM -0400, Jorge Arellano Cid wrote: > On Tue, May 26, 2009 at 08:17:53PM +0200, Johannes Hofmann wrote: > > On Tue, May 19, 2009 at 08:24:14PM +0200, Johannes Hofmann wrote: > > > On Tue, May 19, 2009 at 01:34:56PM -0400, Jorge Arellano Cid wrote: > > > > On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote: > > > > > 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. > > > > > > > > This is very good. > > > > > > > > I'll have to dig for the sylpheed contact to let them know. > > > > Does anybody here know the email? > > > > > > I already contacted them on irc (#claws on freenode). > > > It would be good if this get's some testing as there seems to be > > > some interaction with the WM in use. I now tested it successful > > > on dwm, twm, and fvwm. > > > Also there are probabely more elegant ways to do it, but > > > for now I think it's better than nothing. > > > > More testing showed that the current implementation has severe > > problems. > > The thing is that the window manager that I use (dwm) is one of the > > few non-reparenting WMs. Most others reparent new windows and that > > can create races with the reparentin we do. > > There also seems to be a problem with keyboard events in that case. > > Is there anyone on the list with in-depth X11 knowledge who could > > help with the xembed stuff? > > Not me. > > I've seen new patches in the repo so I assume this is more > or less being improved. Please let me know how it goes. I figured out some more how this is supposed to work with xtrace and the testsocket example from gtk2. For me it now works reliably with claws under kde3. An open issue is that claws eats up all key presses it has defined as hotkeys (including 'p' and 'u'), but the same thing happens when I embed the example plugin from gtk instead of dillo. > > AFAIS the current repo is almost dillo-2.1. I'd freeze here > and only accept bug fixes and polish from now. Opinions? Ok for me. Cheers, Johannes

May 28, 2009

Re: dillo displays corrupted data using gopher protocol

by Rodrigo Arias

Hi, On Mon, May 25, 2026 at 02:14:27PM -0700, Ben Collver wrote: >Greetings, > >I am usuing dillo 3.3.0 on Slackware64 15.0. > >When i open the following document, dillo corrupts the content 100% of >the time. > > <gopher://tilde.pink/1/~bencollver/log/2026-01-04-m1-macro-processor-retreat/readme.map> > >See example screenshots linked below. > > <gopher://tilde.pink/I/~bencollver/files/dillo-1.png> > <gopher://tilde.pink/I/~bencollver/files/dillo-2.png> > >Details noticed about this corruption: > >* It never happens in lynx. >* It only happens for type 1 gopher items. >* It always begins on the line of text at offset 1500, which > happens to be the MTU for both the server and the client. > >Any suggestions for troubleshooting this further? I don't observe it here, which gopher plugin are you using and which commit? You can likely invoke it manually with: $ dpidc stop $ dpid & $ key=$(cat ~/.dillo/dpid_comm_keys | cut -d " " -f2) $ url="gopher://tilde.pink/1/~bencollver/log/2026-01-04-m1-macro-processor-retreat/readme.map" $ echo "<cmd='auth' msg='$key' '><cmd='open_url' url='$url' '>\n" |\ ~/.dillo/dpi/gopher/gopher.filter.dpi Perhaps using strace or gdb may help. Best, Rodrigo.

May 25, 2026

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

On Fri, May 27, 2011 at 1:08 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Fri, May 27, 2011 at 12:38:43PM -0500, reza farivar wrote: > > On Fri, May 27, 2011 at 10:28 AM, Jorge Arellano Cid <jcid(a)dillo.org> > wrote: > > > > > On Thu, May 26, 2011 at 03:42:04PM -0500, reza farivar wrote: > > > > On Thu, May 26, 2011 at 3:18 PM, Johannes Hofmann > > > > > > > > > [...] > > > > > Did you take special care to compile fltk-1.3 with X11 backend? > > > > > If not, you might run the dillo as native Cocoa application. > > > > > In that case you were more successful then me. > > > > > For me dillo with Cocoa-fltk starts, but does not load any remote > > > > > pages. There seem to be severe issues with the way fltk handles > events > > > > > in the Cocoa case. > > > > > > > > > > > > > Hmm, maybe I should try recompiling fltk with X11 backend...But my > > > current > > > > native version is so close to working with no problems... > > > > > > Yes, it's amazing how close it is from working native. > > > Are plugins working OK? (e.g. can you browse the filesystem?) > > > > > > > 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. > > > > > > > > > > Do you know how to use gdb? > > > It would be great to know in what functions the busy wait happens. > > > It could be a timeout or anything. For this: > > > > > > > > gdb ./dillo > > > <when locked on high CPU usage, hit Ctrl-c> > > > > bt > > > > > > > Yes, Here's the result. I tried it a couple of times, and this looks like > > the culprit: > > > > #13 0x000000010007d373 in do_queued_events () at style.hh:554 > > #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 > > #15 0x0000000100083c6f in Fl::run () at style.hh:554 > > This gets us on track! > > Dig... > > In fltk-1.3-rc6, Fl_mac.cxx, it says: > > <quote> > > /** > * This public function handles all events. It wait a maximum of > * 'time' secods for an event. This version returns 1 if events > * other than the timeout timer were processed. > * > * \todo there is no socket handling in this code whatsoever > */ > int fl_wait( double time ) > { > do_queued_events( time ); > return (got_events); > } > > </quote> > > so it looks like when there're sockets to watch, there's a busy > wait (because it sometimes work). > > This is for the FLTK devs to answer. > Interesting find. Indeed if you look at FL_wait in FL_x.cxx, they issue a select system call that can identify socket events, while the mac version seems to only be a timeout based mechanism. I just emailed Manolo Gouy from FLTK (he seems in charge of the Mac section), and I'll let you know. BTW, FL_mac.cxx seems to be deprecated, and their most recent developments is in FL_cocoa.mm. > > As a wild shot I'd try: > > Fl_cocoa.mm:680 > - time_to_wait = 0.0; > + time_to_wait = 0.2; > > Or set it to always 0.1 and see what happens. > > -- > 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

Unused?: the url tag in the DPI start_send_page command

by jcid＠dillo.org

On Sun, Dec 09, 2012 at 04:14:01PM +0000, Jeremy Henty wrote: > > Everything that sends the start_send_page DPI command also sends a url > attribute with it, but I think this attribute is always ignored. > > Dillo processes the command in capi.c but it does nothing with it > because the Cache is already set up to receive the following raw data. > So it doesn't look at any attributes. The only other thing that > receives a start_send_page is the view source DPI and it doesn't look > at any of the attributes either (it extracts a url from the previous > tag in the stream, which it then sends back to Dillo to be ignored). View source shows the URL as page title. > So what is this attribute for? Future use? Or is it something that > just never got used? In general terms, there were ideas that went unused, and some extensions that were necessary to solve an unforeseen situation; as dpi authentication to avoid a local socket spoofing attack. The dpi framework is the same for several quite different dpi programs (aka plugins). The interface was kept more or less uniform, and each dpi chooses whether to use the info or not. -- Cheers Jorge.-

Dec. 9, 2012

Feature Request

by Johannes.Hofmann＠gmx.de

On Sat, Nov 08, 2008 at 04:19:19PM -0500, me at swva wrote: > 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]# dillo-0.8.6 is no longer supported and you should consider to upgrade to dillo-2.0. But nevertheless for me it also works with dillo-0.8.6. If you enter "google.com" in the location bar and hit return it doesn't go to google?

Nov. 8, 2008

[PATCH] startup window

by jcid＠dillo.org

On Wed, Apr 01, 2009 at 08:11:32PM +0200, Hofmann Johannes wrote: > 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 :) Good one! I should have suggested using Gecko... :-) -- Cheers Jorge.-

April 2, 2009

Dillo-dev search results for query "plugin"