Search results for "plugin" - Dillo-dev

current plans

by itsme_410＠yahoo.com

--- On Thu, 4/19/12, corvid at lavabit.com <corvid at lavabit.com> wrote: > From: corvid at lavabit.com <corvid at lavabit.com> > Subject: Re: [Dillo-dev] current plans > To: "Globe Trotter" <itsme_410 at yahoo.com> > Date: Thursday, April 19, 2012, 12:11 AM > > the current plans page has a > number of items which are said to be at least > > in prototype: is there a way to access these > prototypes? assuming that > > they are still part of the plans to move them to > dillo? > > > > any time for a new major release yet? > > My understanding for prototype items are: > > Throttle rendering: Jorge must've done something at some > point, but I > don't know what. > Graphical plugins framework: Maybe this refers to something > from dpi > ancient history. > Image backgrounds: I think I remember Jorge mentioning > trying something > quickly a year or two ago, but I never saw the code or > anything. > Javascript: In addition to the link, I can say that I > think...Jeremy? was > interested in getting something working, but may have been > too busy to do > so. > > As for a release, I for one have been on vacation of > late... > > Thanks very much! I would like to request that you consider releasing more often so that more users may continue to be interested in dillo.....

12 years, 6 months

latest network patch

by Jorge Arellano Cid

Hi there! A network patch that covers several aspects was just commited: + Connected the dpi stream to the cache using the CCC! + Fixed the cache API by introducing the new call a_Capi_get_buf(). + Fixed a race condition and a multiple request problem. + Enabled the https dpi (it doesn't work yet, just a development version). + Removed a cpu-hog when the network is unreachable. Besides what's stated above, it has improved a bit the network experience (for instance on sites with lots of small images. For ex. newspapers). Please test it and tell me how it works. Anders: Please try it and tell us if it also produces the locks you've seen. Does 0.7.3 also lock? Ferdi: It has the proper bindings between the cache and dpi, so HTML served over FTP works, among others! Some https sites are also viewable... Madis: This patch has the framework to implement https in a similar way than the ssl gateway. The connection between dillo and the https dpi is done by the generic dpi handler. Note that although it may be easy to add the POST method using wget to the current https dpi (wget >= 1.9.x using --post-data and the DilloUrl), making a native https plugin (avoiding wget) as in the ssl gatway is preferred. This allows for a simple way to implement connection caching. The current https dpi is a filter, not a server as it should to implement it this way. This is also easy to do. Regards Jorge.-

20 years, 11 months

Re: [Dillo-dev] Some news...

by Ferdi Franceschini

Lars Segerlund wrote: > I have been looking at the dpid, and from what I can see it looks > good, it would be a piece of cake to whip up some usefull dpi's now :-) That's great! > ... I will however dig a bit more, the issue that I am concearned is if > it prohibits some action to be implemented, ( workarounds are ok for me > :-) ). dpid does not prohibit anything, it simply starts a plugin on demand (similar to inetd). > I also have a related question about the dpi's, whith the new > interface, how it fx. a https dpi supposed to work ? and would it be > possible to make fw a svg dpi ? ( thus enabling the dpi to do the > rendering ? I don't think dillo supports https (other than to check that it is used for cookies), and I don't know what plans there are for https support. Can you explain what "fw" and "svg" stand for. For now, just have the dpi open its own window for rendering, we'll worry about how to integrate this with dillo later, you will also need to do this for GUI controls. > Anyhow, for my stumbling attempts whith dpi's it seems to be fully > adequat. That's good. If you have any further questions please let us know. I plan to make a new version of dpid which supports a dpi directory structure in a few days. Regards Ferdi

21 years, 4 months

Dillo + Partial Javascript Support

by matopoftheworld＠live.co.uk

Hi I have a cnm minibook which is part of a little Linux laptop family of mini laptops that use low powered Mipsel processors running Lnux. An unofficial site is here: http://linuxlaptopforum.ark2webdesign.co.uk/index.php One of the users has come up with a Linux distro called 3MX which uses IceWeseal but has also Dillo. The reason for this is because IceWeasel is a bit slow due to the low spec processor. Dillo runs far better than IceWeasel and would be an ideal replacement if it had the functionality of Javascript. 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. It is theoritcally possible as I use the noscript plugin on Firefox on my home PC which blocks javascript from certain 3rd party sites from running. I was wondering if anybody had any thoughts if the above is achievable and if so what would be the best Javascript engine to use with Dillo to achive this? Thanks in advance alsaf. _________________________________________________________________ Share your photos with Windows Live Photos ? Free. http://clk.atdmt.com/UKM/go/134665338/direct/01/

15 years, 7 months

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

Hello, > I made a prototype ftp plugin that is based on > http://nbpfaus.net/~pfau/ftplib/ > Did I post this to the list or only to Jorge ?!? I'm a from scratch die-hard ;), I would write all the code myself, I already looked at the FTP RFC and it's not too hard I think, especially if you only implement what you need (only passive transfers for instance). You posted it to the list, I remember reading it somewhere. That lib seems interesting though, even if only as reference. > AFAIR, the problem is that dillo tries to keep cookies in memory > and writes them to disk only when absolutely necesarry. It's > a privacy issue. No, that's not a problem, cookies that stay all the time in memory don't have to be synchronized, the problem is caused by that few cookies that need to be written to the cookies file, or so I think. Reading and writing to the cookie file everytime another Dillo instance changes it isn't very fast, but it shouldn't happen often, people shouldn't enable cookies for all sites. I use ENABLE_SESSION, but those cookies shouldn't be written to disk. Using file locks is simple to implement, even more so because Dillo already use them. It's possible to have a more complex system that manages that all Dillo instances use the same cookies, even in memory, with shared memory and semaphores, but those few cookies that are explicitly enabled aren't worth all that hassle. Greetings, Indan

21 years

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Patrick Shanahan

* Frank de Lange <frank(a)unternet.org> [09-25-03 16:14]: > On Thu, Sep 25, 2003 at 09:17:12PM +0200, Andreas Schweitzer wrote: > > > I'm guessing almost everybody wants to have frames, so maybe removing > > > the conditional compilation of frames is worthwhile for the sake of > > > simplifying code. > > > > Not only everybody *wants* it. Afterall, frames are part of > > the HTML standard. So it makes sense to have them. > > > > But then again, as far as I understood some of the last e-mails > > from Jorge : isn't he reviewing this patch now or pretty > > soon ? > > It was in reaction to comments from Sebastian that I posed this question to the > list. He suggested removing the conditional compile, but I want to know what > the list has to say on this. As a quick look at the list archives will show, > not everyone likes these new additions to Dillo. The _tabbed_ browsing is wonderful and, afaiac, necessary, along with the tab_on_middle_click. > - exchange tab_load_in_background with a UI element/choice (I think this > should be delayed until Dillo has a preference UI/plugin to avoid > unnecessary complexity and one-off solutions) acceptable > I will release a new version today or tomorrow Looking forward. Will provide a SuSE 8.1 rpm if I am able to compile. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

21 years, 1 month

patch: close windows from menubar

by jcid＠dillo.org

On Wed, Oct 08, 2008 at 05:04:29PM +0200, Joerg Sonnenberger wrote: > On Wed, Oct 08, 2008 at 03:32:42PM +0100, Jeremy Henty wrote: > > On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote: > > > > > ... why would you want dillo1 and dillo2 at the same time. > > > > I don't know. But when you start saying "No-one could *possibly* want > > to do that, so let's stop supporting it" then you are riding for a > > fall. Why make ourselves hostages to fortune? Why not make *sure* we > > avoid the problem rather than gambling that we've second-guessed our > > entire user base? Murphy's law applies, so play it safe unless > > there's a compelling reason not to. > > You are adding the overhead of changing user behavior though. The claws > backend might be a good reason, frankly it is the only one I see so far. OK, just checked Debian and Ubuntu and both have the dillo viewer plugin for sylpheed with a dependency on the plain "dillo" package. Looking around in the FLTK docs, there's this function: CreatedWindow::set_xid() It looks promising. Unfortunately I haven't found a full code example to make it work. If somebody knows how to use it, it'd be simple to make a "drop in" replacement for dillo1, and avoid the problems discussed in this thread. BTW, I'm inclined to using dillorc/dillo/2.0 in the release. -- Cheers Jorge.-

16 years, 1 month

Re: [Dillo-dev]Viewing HTTP Headers with DPI

by Russell J. Wood

On Wed, Jun 08, 2005 at 12:46:19PM -0400, Jorge Arellano Cid wrote: > On Wed, Jun 08, 2005 at 06:31:18AM +0800, Russell J. Wood wrote: > > On Tue, Jun 07, 2005 at 05:13:11PM -0400, Jorge Arellano Cid wrote: > > > On Sun, Jun 05, 2005 at 12:17:20PM +0800, Russell J. Wood wrote: > > > > Hi all, > > > > > > > > Is it possible to view all request/response headers using DPI? > > > > > > That depends on the specific dpi. Please explain it further. > > > > Well, it's not for a specific DPI, I would like to know if it's possible to > > get that information using DPI as if it is, I would like to write a plugin to > > do it. > > > > It's just I didn't see much in the documentation about getting that information. > > Currently, dpip is not providing a dpi-command to request dillo > for that info. Now, it can be done in a quite similar way that > the cookies dpi (currently on testing) does. > > BTW, what for? (if not under NDA of course :) Great to hear it will be possible. just let me know when, and point me to the documentation. =) I like to view HTTP Headers when I've developing web applications or, when I'm just curious to know what's going on. Usually I use Firefox, but it's just so damn slow! - Russell

19 years, 5 months

[Dillo-dev]Please help me with some data

by Jorge Arellano Cid

Hi guys, This weeks have taken a hectic pace for me, finishing and taking care of a lot of issues has been the workload of each day. Now almost everything is ready for FOSDEM 2005 and a very long trip. The point: ;) I'm gathering more data to tune and enrich some points of the conference. The skeleton is: Presentation contents: * What's Dillo * Project objectives * Compatibility/Portability Dillo on PDAs: iPAQ, Yopi, Psion (familiar). uclibc * Architecture overview: Parser/Rendering/IO/Plugins * Current state of the project: Supported standards Features HTML bug meter Memory usage: Comparison table with other browsers by VSZ/RSS. CPU usage: Comparative wall-clock times for page rendering. * Near future potential The port to FLTK Antialiased fonts, UTF-8, more speed, smaller footprint, rendering to abstract devices. CSS, XHTML validation, more SSL, ... I need more data on: Memory usage: Comparison table with other browsers by VSZ/RSS. CPU usage: Comparative wall-clock times for page rendering. and uclibc This is: -------- * Comparison table with other browsers by VSZ/RSS.: On the same system, how much VSZ/RSS Dillo uses in comparison with Mozilla, Firefox, Opera, Whatever on startup and on loading a sample page. * Comparative wall-clock times for page rendering. Wall clock times for rendering a sample page. * uclibc I know Dillo has run under ucLibc. I need the system spec, RSS and compared with other browsers that may also work on the environment. That's it. Please post your answers to dillo-dev so everyone can see the collected data. A lot of TIA! -- Cheers Jorge.-

19 years, 8 months

Re: [Dillo-dev]dillo-0.8.4-rc1

by Patrick Shanahan

* Jorge Arellano Cid <jcid(a)dillo.org> [01-06-05 20:09]: > On Thu, Jan 06, 2005 at 03:38:33PM -0500, Patrick Shanahan wrote: > > * Jorge Arellano Cid <jcid(a)dillo.org> [01-06-05 14:46]: > > > I just finished packing the tarball for dillo-0.8.4-rc1. > > ... > > > Please grab it ASAP, test it throughly and report your findings > > > (finding no problems is a good sign ;). Some emphasis should be > > > put on the newest file server dpi and on compiling on 64 bit > > > machines. > > > > ?? and the URL ?? > > Forgoten somewhere inside my weary mind... :-) > > http://www.dillo.org/download/dillo-0.8.4-rc1.tar.bz2 A build on SuSE 9.0 is available at: http://wahoo.no-ip.org/~pat/dillo-0.8.4-rc1.i686.rpm I am playing with the rc1 now and have opened Yahoo, but cannot log in: Hi! This is the https dpi that just got a request to send the following HTTP query: { POST /config/login?4ghd98ggqpem2 HTTP/1.0 Host: login.yahoo.com User-Agent: Dillo/0.8.4-rc1 Cookie2: $Version="1" Content-type: application/x-www-form-urlencoded Content-length: 288 .done=http%3A%2F%2Fmy.yahoo.com%2Fp%2Fd.html&.tries=1&.src=my&.md5=&.hash=&.js=&.last=&promo=&.intl=us&.bypass=&.partner=&.u=4ks2nvl0ts3sp&.v=0&.challenge=60tz46k8k12hkA3xCJ3iKrQaajYW&.yplus=&.emailCode=&pkg=&stepid=&.ev=&.branch=&hasMsgr=0&.chkP=Y&login=os2pat&passwd=br549&.save=Sign+In } *** Dillo's prototype plugin for https support is disabled now *** If you want to test this alpha support code, just remove line 56 from https.c, recompile and reinstall. (beware that this https support is very limited now) .... But there is no src/https.c within the rc1 tar file ???? otherwise, appears solid. Will report more findings after further usage. thanks, -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos

19 years, 10 months

Dillo-dev search results for query "plugin"