Search results for "plugin" - Dillo-dev

Patch for xembed updated

by podarcis＠lavabit.com

> > When porting dillo to fltk we had to implement xembed on our own or > break support for the claws-mail plugin. > That's why we added xembed.cc. > Thank you for the infos. Keeping compatability is of course a main goal... Nevertheless I am still not really certain, what the current xembed protocol implementation does - or does *NOT*. Please have a look at the enclosed diff 'xembed_removed_demo.diff', that removes the *WHOLE* xembed protocol implementation and only keeps the window creation. Still embedding with 'tabbed' works as before. This really makes me wonder... > I would prefer a minimal fltk-based example program in the test > directory, that implements the embedder side of xembed. > It shouldn't be too hard to do (e.g. by looking at the tabbed > sources). > It would be cool if you would like to work on that. Sorry, but I don't feel able to do this proper. Looking at the xembed protocol specification makes me consider that as an extremely time-consuming task. One idea, which could make us both happy: I have again updated my patch, so that using the xembed protocol can be specified by the application. If using it (and that's the default of course) will run the current xembed code effectively unchanged. This way there should be no compatabiliy issues (The way I have designed that option is only an outline, maybe this can be done better). Only if running with xembed protocol disabled my patch comes into action. --> xembed_patch_xembed_protocol_set.diff --> dembed.cxx Cheers, Podarcis

11 years, 10 months

Re: [Dillo-dev] Re: https dpi

by Jorge Arellano Cid

Hi Madis, On Tue, 27 Jan 2004, Madis Janson wrote: > > 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). Interesting idea! I'll start working on it after the 0.8.0 release. Cheers Jorge.- PS : Dylan knows crypt stuff. You may work together on it. PS2: He's on dillo-dev.

20 years, 9 months

Re: [Dillo-dev]https

by robert w hall

In article <200409111409.13477.gkajmowi(a)tbaytel.net>, Garrett Kajmowicz <gkajmowi(a)tbaytel.net> writes >> Any more news here? >> Things seemed to be going rather well a month back :-) > >I sent in a patch a month or so ago, but I don't know if there is much more to >be done at this stage. Things seem to work well, and most error conditions >notify the user specifically. Those that don't give a generic error message >(very unlikely cases). > >I'm not sure where to go from here. The dpi infrastructure makes it hard to >do some things, but I guess it might be possible to convert the plugin to a >process. Other than that, I don't know if there is much more that needs to >be done. > >- Garrett > > Thanks - I hadn't tried it for a bit and was pleasantly surprised to find that the functionality is now sufficient (provided you ignore the certification messages) to post to the playstation2-linux group. But I didn't manage to get into my amazon account - I think I've managed that with previous dillo-ssl's. Is there a work around? This was with the x86 version. Will now try out a ps2-compilation. When 0.8.3 is finalised it's probably time for a new ps2-rpm version - the last was 0.7.2 or so... (rpm - ugh! any offers? I'm a slackware .tgz man myself) Bob >_______________________________________________ >Dillo-dev mailing list >Dillo-dev(a)lists.auriga.wearlab.de >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- robert w hall

20 years, 2 months

Re: [Dillo-dev]About proxy authorization && password storing

by Jorge Arellano Cid

On Fri, 23 Apr 2004, Ivan Daniluk wrote: > > [...] > > - renamed a_Http_use_proxy_passwd() to a_Http_set_proxy_passwd(). > > - Made the password not visible when typed. > > - Added a commented entry for "http_proxyuser" in dillorc. > > > > This patch is now in CVS, but is not tested because I don't > > have a proxy at hand! :-) > I've tested - it seems to be ok. Good. > And one correction from Francis Daly: > ------------------------------------------- > > From: "Francis Daly" <francis(a)daoine.org> > > To: "Ivan Daniluk" <Ivan.Daniluk(a)ucl.com.ua> > > > > On Thu, Apr 08, 2004 at 06:49:45PM +0300, Ivan Daniluk wrote: > > Hi there, > > One small thing: > > > + static const char *base64_hex = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" > > > + "abcdefghijklmnopqrstuvwxyz" > > > + "0123456789._"; > > > > RFC 2068 (HTTP/1.1) defers to RFC 2045 (MIME), which uses "+/" as the > > final two elements, instead of "._". > > > > RFC 1945 (HTTP/1.0) defers to RFC 1521 (MIME, obsoleted by 2045) which > > uses the same. Done! > PS. I've sent a letter to Madis, but have got no reply yet. Yes, he's under too much work now (we were working on the SSL plugin and he had to stop because of his duties). Please allow him some time. BTW, we have a new SSL dpi prototype (not for the next release though). More on this later. I'll send a recapitualtion about the FLTK port first... Cheers Jorge.-

20 years, 6 months

Re: [Dillo-dev]Invoke application upon clicking a link

by Diego Sáenz

I think i have an easier solution than that. First install the exec dpi that i atach. Read the dpi spec in dillo page for more info. Then use links to dpi:/exec/dillo to start dillo or dpi:/exec//usr/local/bin/dillo to start /usr/local/bin/dillo. With this dpi you can not pass parameters. If you make it understand %20 in the url passed, so commands can have parameters, please send the cahnges. Diego/DarkSpirit El Fri, 8 Oct 2004 12:08:05 +0200 Matthias Franz <Matthias.Franz(a)ujf-grenoble.fr> escribio: > On Fri, Aug 20, 2004 at 09:05:13PM -0700, huy wrote: > > I would like to be able to click on a link and invoke a local executable. > > [...] > > Is there a way I can do this with dillo (short of modifying the source code). > > Dear huy, > > using the external viewers patch (see my posting to this list) and > the Dillo dpi framework, there is a short solution to your problem: > > Save the attached shell scipt to ~/.dillo/dpi/runcmd/runcmd.filter.dpi > and put the line > > application/x-runcmd; %{cmd} > > into your ~/.mailcap . Then any link of the form "dpi:/runcmd/prog" starts > the program "prog". > > See the Dillo file doc/Dpid.txt for more on (filter) plugins. > > > security isn't an issue > > I hope so since otherwise you'd better forget all this! > > All the best, > -- > Matthias Franz > > Section de Mathématiques, Université de Genève, Suisse >

20 years, 1 month

Puppy Linux 0.9.1 has Dillo, works fine

by Barry Kauler

Hi guys, Just a comment because I started a thread a little while ago, that never got resolved. The 0.8.x series of Puppy Linux had all the apps compiled against uClibc, which saved about 1M but caused various compatibility problems. One of those was the Dillo plugins not working right. That problem never got resolved, however it is now academic as far as Puppy is concerned, as I recompiled everything against glibc, for Puppy 0.9.0 (using Mandrake 9.2 as the host). Having finished with that, I wish to make one further interesting comment. Puppy is a tiny distro, the live-CD is only 49M, designed to fit on a business-card-size CD, and easily install to usb pen drive or Zip drive. The widget libraries used are only GTK 1.2, Xaw95 and Tk/tix/bwidget. I also installed the gdkxft package, which is a fairly small library that bolts font antialising onto GTK 1.2 apps. I wish to report that it works brilliantly with Dillo. The latest Puppy. v0.9.1, has Dillo with font antialiasing and it sure looks good. Note that one interesting thing about gdkxft, for anyone else interested in trying it, is that it can be applied on a per-application basis, without recompiling the app. You just install libgdkxft.so, then do this when launching Dillo: LD_PRELOAD=/usr/lib/libgdkxft.so dillo There is a config file, /etc/gdkxftrc I think it's called, and all you do is put a single "*" in it, which means apply antialiasing to all fonts. Puppy home page: http://www.goosee.com/puppy News page: http://www.goosee.com/puppy/news.htm Regards, Barry Kauler

20 years, 4 months

Feature Request

by Beartooth＠swva.net

I think I'm being unclear, in two ways. >> 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]# On Sat, 8 Nov 2008, Johannes Hofmann wrote: > 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. For those who run other OSs, what the emphasized lines mean is the 0.8.6 is what Fedora has, period. (I run F9, the latest release.) Any idea why it's so far behind?? I didn't realize 1.0 had become official, let alone 2.0 > If you enter "google.com" in the location bar and hit return > it doesn't go to google? It does indeed. I'm putting this badly. I run Alpine 2.0; it is set to launch the default browser, which is dillo -- and URLs in emails are what I use a default browser for. Does this mean something in my Alpine settings (and my Pine 4.64 settings, which it took over) is wrong? My Fedora default browser setting is simply "dillo %s"; my Alpine setting is something I'll have to dig for, as it's buried way deep. -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

16 years

Re: [Dillo-dev] dpi interface ....

by Jorge Arellano Cid

On Fri, 27 Jun 2003, Lars Segerlund wrote: > > Hi, > > I'm trying to hack a mailreader dpi for dillo, and I have some code > which runs on top of nmh and works decently, ( I looked at exmh :-) ). > So now I wan't to know where the dpi's are heading ? Mainly if there > is a plan for 'dynamic dpi configuration' and such, i.e. the ability to > use a dpi bound at runtime, I have looked at the bookmarks dpi, and > since parts of it is compiled into the binary ( the button binding and > such ), I am wondering how to handle this in a future safe manner ? > > ( btw. the mail reader works something like a local webmailer, and I > wanted somthing which made extensive use of comand line mail utilities > which alredy exist ). > > So is there a furure target to aim for or do I make it a patch a'la > bookmarks ? Sorry, I tried to wrap things up, but a lot of other things came up this week, and that's why I haven't commited anything. Judging from the past, forwarding documentations without the code is almost of no help here. A LOT OF things have been done, I just need some time to wrap it up. Yes, things will be flexible so don't try to hardcode it as bookmarks (BTW, the bookmarks plugin is now running under dpid). If I can't do it the next week, I'll post the whole work we have with Ferdi as it is then. Cheers Jorge.-

21 years, 4 months

Re: [Dillo-dev] The kind of computer that is perfect for Dillo

by Diego Sáenz

El Thu, 24 Aug 2006 17:07:21 +0000 (UTC) Sam Trenholme <sam+dillo(a)chaosring.org> escribio: [...] > I would look at the "i18n" version and try and add Javascript support > to it (or, better yet, EMCAscript support). Personally, I think Dillo > needs some level of Javascript support; a lot of high-profile sites > (can we say MySpace and their crappy JavaScript and HTML) plain simply > do not work without Javascript. If you do it, i will try to make a Dillo Plug-In with it. A DPI will work unmodified with or without i18n-patch/fork. If you want any help about Dillo PlugIns ask in the list and i will try to help. > I also believe that Dillo shouldn't try to get CSS support; the last > thing I want is yet another browser with buggy CSS that I have to > design around. If Dillo is going to support CSS, I don't think the > support should become a part of a stable release of Dillo until Dillo > can render ACID2 perfectly. A site that uses CSS is perfectly usable, > albeit a bit ugly, in a browser that doesn't have CSS. I disagree with you. Dillo needs CSS, well better said i need a dillo with CSS :P and i think that a lot of persons need it too. Until dillo suport enought the standard and pass ACID2 a note "wait until CSS test passed before mail your webmaster or test a page with dillo(if you are a webmaster)" can be enought. Dillo is still beta. Diego.

18 years, 2 months

Re: RFC repository

by pastebin＠gmx.com

Rodrigo this looks pretty amazing 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? > Hi, > > I've decided to open a RFC-like repository for Dillo here: > > https://github.com/dillo-browser/rfc > > So we can have a centralized place to propose and discuss non-arbitrary > changes or other topics regarding Dillo. For now they are just Markdown > files so they are easy to read and write from any editor and we don't > rely much on GitHub. This also allows contributions by sending patches > via email. > > I'll be collecting more thoughts about the rule-based mechanism I was > talking about in other threads in the RFC-002: Rule-based content > manipulation, here: > > https://github.com/dillo-browser/rfc/blob/rfc-002/rfc-002-rule-based-conten… > > I may also add the PEC proposal I did the other day to classify how > broken are pages when you disable JS, although it not very Dillo > specific: > > https://dillo-browser.github.io/pec/ > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

4 months, 1 week

Dillo-dev search results for query "plugin"