Search results for "plugin" - Dillo-dev

Connection problems on Mac OS X 10.6.7

by jcid＠dillo.org

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). > 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). -- Cheers Jorge.-

May 27, 2011

web bug save?

by corvid＠lavabit.com

I wrote: > I wrote: > > I wrote: > > > Johannes wrote: > > > > On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > > > > > Sometimes I wonder whether > > > > > connecting through to a TOR network could help us a lot with it. > > > > > > > > You can already use dillo with privoxy and tor. We could perhaps > > > > make it more convenient to configure such a setup. > > > > We also would need to make sure that really all requests go through > > > > the proxy, e.g. I'm not sure, whether wget called from dowload.dpi > > > > uses the proxy from dillorc. > > > > > > I have warnings in the FAQ and dillorc that the wget env variables would > > > need to be set appropriately, but it would be nice to have dillo send that > > > to the dpi in requests so that it can set the environment for sure before > > > execing wget. > > > > I just committed a patch to set the environment variable from the preference > > if it wasn't already set. > > > > issues: > > - maybe we should have an ftp_proxy pref, too. > > - ISTR that dillo doesn't understand user/pass in URLs. > > This means that dillo doesn't do the right thing if > > - the env var has the user/pass > > - dillo is setting the env for wget. > > It turns out that if I want to add the ability for ftp/downloads > to do the right thing with the no_proxy pref as well, > I would have to send a no_proxy arg to the dpi. > > It would be cleaner to send the proxy URL to the dpi > (and set/clear it there in the environment for wget) every time > that it's needed than to have the proxy URL in the environment > and send a no_proxy arg when it's needed. > > So I'm going to back out that change. This turns out to be a somewhat complicated situation. I naively imagined that whatever I found in wget's 1500-line manpage was what there was, but since wget is a gnu program, it's a subset selected who-knows-how. wget understands the http_proxy, https_proxy, and ftp_proxy environment vars. dillo understands the http_proxy environment var. If it is not set, dillo will use the http_proxy pref. dillo uses its http_proxy value for both http and the https plugin. Whatever we might do to get *_proxy set a certain way in the environment in the downloads/ftp dpis, wgetrc can override them. - should the https plugin use the https_proxy environment var if it's set? I'm leaning toward no. - should dillo try to set the https_proxy env var from the http_proxy pref for the benefit of the downloads dpi? Well, the downloads dpi doesn't like https anyway right now because we haven't given it any sort of #ifdef ENABLE_SSL add argument "--no-check-certificate" #endif, but we could and probably should add the argument. As for the question, ... not sure. (Maybe we should just let wget do all of our https, at least instead of the current plugin.) - should dillo have https_proxy prefs and ftp_proxy prefs? On one hand it might minimize confusion, but then I could take the same amount of space in dillorc to write a big comment explaining all of this. (The unpleasant part of putting things in dillorc or explaining things in dillorc is that I know that no one who upgrades is going to look through it meticulously to see what tiny things have changed.) wget also understands the no_proxy environment variable and wgetrc option. Dillo understands the no_proxy preference. Coincidentally(?), they have the same format. - Should dillo set the env var for wget from the pref if not set? I think so, for the benefit of http downloads. - Should dillo use the env var for itself if set? I kind of don't want to add the complexity. I don't know. (And to get user/pass into wget for proxy, it seems that the proper thing is to stuff them into the env var *_proxy urls.) Anyway, I'm finding this all somewhat tricky to think about.

Jan. 12, 2010

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

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 Those three lines are consistent everytime I break in GDB. The more detailed ones are different of course. Here's one, just in case: #0 0x00007fff87967dc5 in tiny_malloc_from_free_list () #1 0x00007fff87966fdd in szone_malloc_should_clear () #2 0x00007fff8799d32b in szone_memalign () #3 0x00007fff879a46eb in malloc_zone_memalign () #4 0x00007fff87376608 in CFSortIndexes () #5 0x00007fff87376480 in CFQSortArray () #6 0x00007fff87386ad2 in __CFRunLoopDoObservers () #7 0x00007fff87361da4 in CFRunLoopRunSpecific () #8 0x00007fff842457ee in RunCurrentEventLoopInMode () #9 0x00007fff842455f3 in ReceiveNextEventCommon () #10 0x00007fff842454ac in BlockUntilNextEventMatchingListInMode () #11 0x00007fff85739e64 in _DPSNextEvent () #12 0x00007fff857397a9 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #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 #16 0x0000000100003a85 in main (argc=1, argv=0x7fff5fbff828) at dillo.cc:431 -Reza > This can hint us on what may be happening. > > > -- > 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

[patch]: improve the "SSL disabled" warnings.

by onepoint＠starurchin.org

This is a purely cosmetic update to my previous patch: it adds a warning about alpha code to the output of "./configure --help" and improves the appearance of the "SSL is disabled" message from the plugin. It does not change any functionality. Regards, Jeremy Henty

Oct. 17, 2008

[patch]: improve the "SSL disabled" warnings.

by jcid＠dillo.org

On Fri, Oct 17, 2008 at 02:24:15AM +0100, Jeremy Henty wrote: > > This is a purely cosmetic update to my previous patch: it adds a > warning about alpha code to the output of "./configure --help" and > improves the appearance of the "SSL is disabled" message from the > plugin. It does not change any functionality. Committed. -- Cheers Jorge.-

Oct. 17, 2008

More dillo mentions

by jcid＠dillo.org

On Sat, Oct 25, 2008 at 01:54:49PM +0100, Jeremy Henty wrote: > > "Adding a Lightweight GUI and Webmin to Ubuntu Server" > http://smallboxadmin.blogspot.com/2008/10/adding-lightweight-gui-to-ubuntu-… > > Unfortunately the author thinks that the SSL support isn't good enough > and uses Firefox instead: > > Dillo is a simple lightweight browser that would fit into this > lightweight theme, however, https (SSL) is in a alpha stage and > not well supported. SSL is needed for Webmin. If Webmin can work without Javascript, it'd be intersting to add more priority on the SSL plugin. -- Cheers Jorge.-

Oct. 25, 2008

Cookies performance

by corvid＠lavabit.com

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

Jan. 12, 2010

youtube-dl

by bobh＠n-cantrell.demon.co.uk

Would it be 'easy' to turn youtube-dl (written in python) into a dillo 'plugin'?? Bopb -- robert w hall

July 1, 2010

youtube-dl

by bobh＠n-cantrell.demon.co.uk

Would it be 'easy' to turn youtube-dl (written in python) into a dillo 'plugin'?? Bopb -- robert w hall

July 1, 2010

Ignore a command line option (for Mac OS bundles)

by corvid＠lavabit.com

reza wrote: > Now most of the plugins seem to work, at least bookmarks work fine. > > There is still a problem remaining though. In the target machine, I cannot > open sites that require SSL (for example www.gmail.com, mail.yahoo.com) I'm > not sure why it happens. Is there any library that helps in SSL connections > that I forgot copying over? openssl?

June 5, 2011

Dillo-dev search results for query "plugin"