Search results for "plugin" - Dillo-dev

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

12 years, 11 months

Re: [Dillo-dev]Toolkit & dillo

by Roberto A. Foglietta

robert w hall wrote: > In article <41987D95.7010209(a)sad.it>, Roberto A. Foglietta > <roberto.foglietta(a)sad.it> writes > >>Lars Segerlund wrote: >> >>> There has been a lot of talk about toolkits and dillo, and I had a small >> >>idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can >>bring only the widgets you need ) and if done with some care a statically linked >>dillo would not be bloated. >> >>Suggest: use directfb combined with gtk eventually > > > will that translate easily across all machine architectures? ALL? What does it means? ;-) Before choosing a toolkit is necessary understand the target of users. What kind of usage and what kind of arch is very impostant for dillo? In my opinion Dillo is not a good project BECAUSE graphic and gtk are mixed up with HTML rendering engine and everything else. You have to split up: - html engine - cache doesn't have to depend on html engine - plugin and applet engine - users functionalities \___ gui - graphic / Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

20 years

Re: [Dillo-dev] more dillo unfinished code

by Alan Carvalho de Assis

Hi Diego, congratulations, these plugin appear very nice. I'm busy now devoloping my thesis but when I get time I will test it. Cheers, Alan 2007/7/31, Diego . <darkspirit5000(a)gmail.com>: > Hello, i have added a patch to manage scripts with DPIs to my (dully and > silly) dillo unfinished code page. > > The patch only allow dillo to send scripts to DPIs and have bugs. > > Now i am working in mime DPIs. The test file type DPIs part work but the > code is too nasty yet. > > Please give your opinions about the page and the code. > > Do not worry to ask any doubt. > > I need some help about the english part to so do not doubt to blame my > english and tell my errors. Like this is not the topic of the list send > language errors directly to me. > > The page is http://personales.ya.com/darkspirit/ > > Diego. > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > -- ------------------------------------------------------------ | Alan Carvalho de Assis | ------------------------------------------------------------ -- Não importa o que os outros irão pensar, A cura para a infelicidade é a felicidade

17 years, 3 months

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 >

13 years, 5 months

dillo-0.7.3.tar.bz2

by Jorge Arellano Cid

Hi there! Yesterday I posted an email about 0.7.3 but forgot to mention the most important part: the URL! :-) There's a tarball of 0.7.3 at: http://www.dillo.org/download/dillo-0.7.3.tar.bz2 The plan was to test it yesterday (it already passed my tests and Seb's too) and to announce it on Wednesday while letting our packagers some time to update them for announce time. So there it is, and will be announced on Thursday. Please get it and give it some hard testing. Kelson, Phil, Oliver: please make update your packages with it. Sorry for the mistake. Cheers Jorge.- Frank: after I upload 0.8.0-pre I'll have some time to look in your work. Now that 0.7.3 release is almost done, I guess Sebastian will have some time too (we were working on a plan for CSS, and then Sebastian had to make a detailed review of the incremental resizing mechanism because of some discovered bugs. I was working on 0.8.0-pre (plugins) and on the release). All this explanation is to state that it is not lack of interest, but lack of manpower. You'd be amazed to know all of the things I'm working in parallel. PS: the above note applies to all of you waiting for an answer from my side...

21 years, 3 months

cookies dpi patch is on CVS now

by Jorge Arellano Cid

Hi there, After a more in depth review, the patch for the cookies dpi was uploaded to the CVS. It has some minor modifications and it's ready for testing! Cookies now hare handled by a dpi (dillo plugin), so there's no more restriction of only one instance of Dillo having cookies enabled. Every single dillo sees cookies.dpi as the "cookies server" so there's no problem, and dillo's core gets smaller. After 'make", remember to "dpidc stop" and to 'make install' to get the cookies dpi installed. If you find some bugs, please report back here to Diego or me. Diego: I'll try to catch up with the thread about the MIME dpi. As Matthias Franz pointed out, I'm interested on it. The main point is to make it use the dpi/dpip framework instead of a custom approach. --More on this soon. I'm also working on a new dpip library, so it may be merged in the future (don't worry, that's my work and it makes things easier, not harder). Porting the cookies dpi to it should be no more than one day, and I have already every other dpi working on it on a custom tree... -- Cheers Jorge.-

19 years, 3 months

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

11 years, 11 months

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?

16 years

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

15 years, 7 months

[Dillo-dev]Hello to all and first question

by Roberto A. Foglietta

Hi, first of all: thank you very much for you great job in doing Dillo! Actually I'm trying to use it to display bus time table in a station. What I'm looking here? A /deprecated/ features! I need to reload _automatically_ pages on the bus-station screens, there are some ways to do that: 1) use deprecated meta refresh tag (not work, even in previous vers.) 2) modify Dillo code to accept a -r <n> flag which force him to reload every <n> seconds 3) writing a dpi plugin (???) The way n.1 could be the best for me because I could choose reload delay just from server inserting that deprecated flag in HTML code. But old version of Dillo like 0.2.4 - 0.6.1 don't do that. Simply moved on the specified url and nothing else about reload. I would find a solution should be usefull for everybody and quite simple to do. Like put a flag which enable that deprecated tag and do it working. Or it could be better do something else? Automatically reload should be very usefull in all embedded (but not pda) system which aim to keep some information on the screen refreshed. That for all. Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

20 years

Dillo-dev search results for query "plugin"