Search results for "plugin" - Dillo-dev

--xid option

by Johannes.Hofmann＠gmx.de

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? Cheers, Johannes > > Cheers, > Johannes

15 years, 5 months

Re: [Dillo-dev] How to get dillo up to speed

by Jorge Arellano Cid

Guys, Once again I want to thank you for the appreciation you have for Dillo as a project. Now, if you read my original message again, you'll find: > Sebastian made a huge effort too. Having a job and developing a > web browser is a very demanding task, and he did even more than > that. I highly respect the man. > > In Germany we decided with him to keep the Dillo FLTK2 closed > until we both agreed to release. and > From some time ago I think it would be good to release the new > code. I have emailed several times with no answer. In fact, I think it was more or less 6 months ago, after some emails with Andrew Tanenbaum, who finally helped me to see that it was a good time to release the code again. Since then, I've tried to contact Sebastian to agree on this. -- On the technical part: > But Dillo need to evolve to support features only existents in modern > browsers as i18n, javascript, https, tabs, flash (gnash), etc. - i18n : this was the main reason for choosing FLTK2 (utf-8). - https: I started this plugin and also wish it can be improved (later Garrett Kajmowicz helped a lot with this). - tabs : I also want Dillo to have TABs. It may take to much time until WM TABs support is as good as internal TABS. I designed a Dillo FLTK2 UI where this is easy to add (one of these days I may code it up... :-) - flash: This depends on a external interpreter. I have no problem in making the hooks. - javascript: This also depends on a external VM, and a supporting framework. It can be done but requires time. I'm not opposed as long as it can be disabled/enabled because it comes with severe security/privacy risks. - CSS : All of us want this! Sebastian made a huge and accurate work to make the CSS model a part of the internal widget structures. We only need to hook the parser. We even showed a prototype in France 2005 at LSM Again, once released, the code will not improve alone, it needs dedicated developers/supporters willing to put their part in order to make the vision we share happen. <<Long life to Dillo!>> -- Cheers Jorge.- PS: For those willing to take our word at face value, I want to state that it was never our intention to sell the code to proprietary hands. BTW, we never did.

17 years, 7 months

FreeHG performance

by dillo-dev＠toykeeper.net

* Jeremy Henty <onepoint(a)starurchin.org> wrote: > Looks good, but I think Dillo would have to migrate > away from Mercurial to use it. After using hg for the past couple years and bzr for about a year, I've found bzr to be an upgrade. I still use both on a regular basis, but no longer choose hg for any new projects. The main differences to be aware of are: - Branches are directories instead of labels. Each directory has only one "head", and you switch between branches with "cd". Merging is done like "cd trunk ; bzr merge ../my-bugfix". - There are a lot of plugins available to extend functionality in various ways. A couple I recommend are bzr-gtk ("bzr vis" is a nice way to browse history) and bzr-bisect (helps isolate where bugs were introduced). - It has a concept of a main line of development, and meaningful version numbers. Merges are always explicit, even when hg would merge in-line. This makes feature branches more useful. That last one probably requires a little more explanation. Say you branch from trunk at r100 to add a feature. It requires some major changes, so you break everything while refactoring and spend a few revisions getting it all working again. It takes 10 revisions total. So, you send the changes upstream. They like it. They merge it... And nobody else checked anything in while you were working. Now (in hg) trunk is at r110, with your new feature. And the revision graph ends up being a straight line, so there's no evidence a merge occurred. If anyone tries to use r101 through r109, they'll find that it's all broken. The way bzr handles it is you submit 10 revisions, and when merged, trunk bumps up to r101. The revision graph shows a branch off to the side with 10 changes (r100.1.1 through r100.1.10) and a merge at the end (r101), and the trunk contains only non-broken versions. It makes more sense to me. > They use bzr, and although they integrate with some other > VCSs, mercurial isn't one of them. It's a one-time conversion, instead of the two-way conduit they support for subversion. I tried it just now (using bzr-fastimport) and it worked. The new branch is in my "junk" folder (launchpad equivalent of /tmp/) if anyone wants to try it: bzr branch lp:~toykeeper/+junk/dillo Personally, the main thing I find annoying about bzr is that it's not the easiest thing to type. I use "alias b=bzr" in my shell to fix that. -- Scott

15 years, 9 months

Feature Request

by akemnade＠tzi.de

On Sun, 9 Nov 2008 09:38:11 +0100 Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > On Sat, Nov 08, 2008 at 04:40:01PM -0500, me at swva wrote: > > > > 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. > > I don't know what Alpine exactly does, but if I do > dillo google.com > on the command line, it works fine with both dillo 2.0 and 0.8.6. > The interesting question here is which 0.8.6? the official one or the inofficial dillo-i18n one? At least debian does not ship the official one. If that's about the dillo-i18n stuff (and not reproducable with official dillo), then the problem should go to the corresponding team. Greetings Andreas Kemnade

16 years

Feature Request

by newman.x＠gmail.com

me at swva wrote: > > 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 > That's life. In Fedora, nor even Rawhide, isn't Dillo v2.0. Two reasons: 1) No one packed FLTK 2.x, check repository there's still 1.1.9. 2) Because of (1) no Dillo 2. Although Fedora is usually fresh, in case of Dillo it's still on Dillo 0.8.6 mainline. Feel free to file bug (bugzilla.redhat.com) against Dillo and Package Review for FLTK2, but be aware that having unstable FLTK 2.x in Fedora might be quite fight. (Believe me I am Fedora packager.) Feel free to use mines with SSL enabled (no guarantee at all), both F10. http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/dillo/dillo-2.0-1.i386.rpm http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/fltk/fltk2-2.0.x.r6403-0.1.i3… But you'll probably have more luck with those: http://www.hyperborea.org/software/dillo/rpms/ Enjoy. >> 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. > Might be here interesting whether Dillo2 cooperates nicely with alpine, let us know. Michal

16 years

Re: [Dillo-dev]New developer info

by Jorge Arellano Cid

On Tue, Jun 14, 2005 at 02:36:19PM +0200, Wim De Smet wrote: > Hi, Hi Wim! > [...] > I was thinking about doing some simple kind of plugin to get started > (are there any you want to work on?), but I'm fascinated with parsers > and how they work, though I might not be very good at writing them, > I'd be interested in working on that later on. Unfortunately my C > skills aren't very good but I've got the basics and I also know lots > of java (pretty useless here I guess :), some C++, and have experience > scripting in shells and python. > > cheers, > Wim OK. I think the easiest one is BUG#343 (parser related). On the side of dpis, I think a man-page-to-html filter can be interesting. This is something that lets you view man pages as html in the browser. It can be evolved to also handle "info" files and then become a good help browser, making an easy&quick interface to local information (in the harddisk). These days, GNU/Linux, BSD*, etc. distributions come with lots if information in different formats that is seldom used. This is man pages, info files, html files etc. if a dillo dpi can provide for an easy interface for accesing it, I think it would be very handy. Think of a single text entry that searches in the local HD for information ao a keyword[s] providing some local links as answer. > [Drasko wrote:] > Thanks for your replies and warm welcome. > I have experience in C, C++ and Java, and I am learning GTK+ and > Python at the moment. I would like something simle to start on gently, > as my skills are not qute high. I have no special preferencies, so > I'll agree with anything that you consider appropriate for beginer. > It would be nice to have some point-outs about the subject given (how > to start and where to look for the docs). Well, I meant something more specific about expertise. For instance: libc, pthreads, sockets, network programming, parsing, RFC implementations, protocols, widgets sets (as GTK/FLTK/Dw), non blocking IO, distributed programming, daemons, QA, testing, etc. :-) As with Wim, an easy one is BUG#343. On the cookies field, you can investigate/test BUG#364 and/or BUG#370 (got to coordinate with Diego S.). Another good one to start is BUG#674. A quick solution is trivial, but a good one requires a bit more of thinking and investigation to choose a good "cutting threshold" for the protection scheme. HTH. -- Cheers Jorge.-

19 years, 5 months

Re: [Dillo-dev]dillo-0.8.3-rc3

by Jorge Arellano Cid

On Mon, Oct 25, 2004 at 09:37:36AM -0700, Kelson Vibber wrote: > Jorge Arellano Cid wrote: > > I found a bug that could increment the redirection counter when > > the HTTP answer is a redirection coming in several tiny packets. > > Daniel Lord wrote: > >What about setting MTU of your ethX to a small number? My ISP's proxy/router/gateway/whatever doesn't like to negotiate MTU!, but that's another story... Theoretical debugging is helping me now. When I finish the patch, as long as Kelson can reproduce and test it, it'll be fine. > > Hmm, that might be it. I'm not going through a proxy, but I am going > through a broadband router connecting via PPPoE. I just tried it from > work, and browsing from my desktop (through the firewall) shows the same > problem (on the search form, anyway), but connecting from an outside > system (directly over ethernet) seems okay. > > Jorge Arellano Cid wrote: > > Even more, the search is giving me no redirection but a plain > > 200 OK answer. Look: > > Agh. I've got a caching plugin on the journal that saves the HTML > output to cut down on database & processing time. It looks like it's > caching the search results and just sending them as 200 instead of > processing the pre-output part of the script. This explains the > apparent inconsistency in which only the first hit triggered the > spurious loop error: later hits picked up the cached copy with a 200 > instead of a 302. > > Sorry about that. > > I've disabled it for now -- the only reason I really had it on was to > deal with delays talking to Waypath, but they seem to be down half the > time anyway. (In the long term I can set up a separate page to handle > searches, and just tell it not to cache that page, but for now, this is > simpler.) That should help with the debugging, since I won't have time > to put together a test case today. Don't worry, I'll send (or upload) a patch for you to test. AFAIU, when the hops counter in Dillo detects a redirection Loop (whether real or false), and the next URL requested also gets a redirection code as answer, the latter is mistakenly treated as a redirection loop too. I'm polishing the patch... How much time will you be online. Or at what time (GMT) do you leave? (I want to upload 0.8.3 today for testing and to announce it on Wednesday morning). -- Cheers Jorge.-

20 years

Re: [Dillo-dev] patch: python filter DPI supporting the "data:" scheme from RFC 2397

by Diego Sáenz

El Mon, 5 Dec 2005 07:58:11 -0800 Ben Wiley Sittler <bsittler(a)gmail.com> escribio: > Hi! I've been using dillo a bit since the i18n patch became usable, > and found that there was one crucial URI scheme missing: "data:", > defined in RFC 2397. I used the simple filter DPI model and had > something working fairly quickly (thank you all for making that easy!) Great, i try to do the same for the xproto patch with a shell script, but only support base 64 and forget it. > > This works by adding a filter for dpi:/dataurl/... and rewriting > data:... to use it, in a fashion similar to the one used by the https > filter. > > The data: URI scheme allows image data (and other linked resources) to > be embedded in a web page, so (for example) your DPIs can now > trivially embed images, even dynamically-generated ones. It is also > supported by the Mozilla family (it's used heavily in GreaseMonkey > plugins) and in Konqueror and Safari. I think i will use this feature for the prefs plug-in. > > Here's an example data: URI (an image) from the RFC: > > <IMG > SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw > AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz > ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp > a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl > ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis > F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH > hhx4dbgYKAAA7" > ALT="Larry"> > > The ";base64" is optional, and indicates Base-64 encoded data. The > default is unencoded, i.e. just URL-escaped. Here's a non-Base-64 > conversion of the same data: > > <img > src="data:image/gif,GIF87a0%000%00%F0%00%00%00%00%00%FF%FF%FF%2C%00 > %00%00%000%000%00%00%02%F0%8C%8F%A9%CB%ED%DF%00%9C%0EH%8Bs%B0%B4%AB > %0C%86%1E%14%96%A64.%E7%2A%A6%09%8B%1A%A7%2B%AFQIo8%D9%8Ef%D7%F3%80 > %5C%C1%C90u%D1%0819%1D%13%A8%14%1E%8E%14M%CC%E7%E4T%9F%B9b%25%2A%AD > qyc%99J%87%F0%DE%B8%D7%0F%E7%22%D6%1A%C1%1B%B4%B8%8EJ%96%BFL%F8%3B% > 26%92G%C7%27%A7w5%93%05%F5%F4s%13%A7%28%F8%E0%078%B8v%28%A7Xgd%17%C > 9%23u%F9%F2q%06We%E6%06z9%89%95%97%86%97%D8%B6%89%C5jh%D5Z%8AT%FA%1 > 7%98%89%F7I%BA%9A%FB%93K%83%8A%D3%934%BC94C%85%D4%B7%0B%CA%3B%3A%DC > wx%AA%F6%E8%AC%17%CDL%D4%E2%1CG%B9D%7B%0C%1C.%9E%ED%B8%D3d3%7B%8D%9 > D%AD%C5%D8%94%05%A3%DE%D5%AE%2C%BF%5E%5E%3F%7FW%1F%E5U%B3_%2C%A6%EC > %F1%E1%87%1E%1Dn%06%0A%00%00%3B" > alt="Larry" > /> > > So far this DPI has only been tested with the i18n-patched version of > dillo (I use it to load small test texts in different charsets), but > it should theoretically work in regular dillo too. > > Enjoy, > -ben Goodbye Diego

18 years, 11 months

Various minor patches

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:06]: > On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > > 1) detect_libiconv.diff > > > > > > > > > > > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > > > > > > > is not in the default linker path, making the build abort. Add > > > > > > > a simple test to configure.in to check for libiconv's presence > > > > > > > and usability and a substitution for ICONV_LIBS to src/Makefile.am. > > > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > > but it turned out that the problem was caused by a libiconv > > > > package that was no longer needed. The iconv stuff is now handled > > > > in libc on DragonFly... > > > > > > I have attached the log. Seems like the function signature differs > > > on OpenBSD a bit. The testcase modified as such that it includes > > > <iconv.h> and calling iconv_open("",""); works for me when doint > > > it manually. > > > > > > I don't know what happens here... > > > > > > Kind regards, > > > > Does it fail with current CVS? > > Sorry, from the log it's clear it doesn't. > > This page seems to have good info: > > http://synflood.at/blog/index.php?/plugin/tag/bsd > > (my understanding of German is barely for survival. ;). > Yes it does describe my problem, but how do we fix this in a portable way? -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

16 years, 9 months

[Dillo-dev]protocol handler dpi for mailto:, etc.

by Lee Bigelow

Hello again, I did up a proto-type bash shell dpi for handling unsupported protocols, like mailto:, with external applications. I called it xproto. It uses the config file $HOME/dillo/protorc to decide what to do. The plugin will make a default one you can edit when it's first run. I'm working on the C version, but I'm just learning C, so it'll take me a bit. One thing I can't seem to figure out is how to send a url from the plugin to dillo and have dillo display that page. For example I would like the url gg:water to send dillo http://www.google.com/search?q=water For now I just have it open up another dillo. I tried sending <dpi cmd="open_url" url="http://www.google.com/search?q=water"> but that didn't work, booo. Again, xproto.filter.dpi is just a shell script, so play away. If you have any hints on the gg: thing let me know, please... The patch, against dillo-0.8.2: -------------------------------------- diff -pruN dillo-0.8.2/dpi/Makefile.am dillo-0.8.2-xproto/dpi/Makefile.am --- dillo-0.8.2/dpi/Makefile.am 2004-01-29 17:04:05.000000000 -0330 +++ dillo-0.8.2-xproto/dpi/Makefile.am 2004-10-31 09:51:39.000000000 -0330 @@ -5,11 +5,13 @@ downloadsdir = $(libdir)/dillo/dpi/downl ftpdir = $(libdir)/dillo/dpi/ftp httpsdir = $(libdir)/dillo/dpi/https hellodir = $(libdir)/dillo/dpi/hello +xprotodir = $(libdir)/dillo/dpi/xproto bookmarks_PROGRAMS = bookmarks.dpi downloads_PROGRAMS = downloads.dpi ftp_PROGRAMS = ftp.filter.dpi https_PROGRAMS = https.filter.dpi hello_PROGRAMS = hello.filter.dpi +xproto_PROGRAMS = xproto.filter.dpi bookmarks_dpi_LDADD = @GLIB_LIBS@ downloads_dpi_LDADD = @GLIB_LIBS@ diff -pruN dillo-0.8.2/dpi/Makefile.in dillo-0.8.2-xproto/dpi/Makefile.in --- dillo-0.8.2/dpi/Makefile.in 2004-07-06 14:31:24.000000000 -0230 +++ dillo-0.8.2-xproto/dpi/Makefile.in 2004-10-31 10:18:28.000000000 -0330 @@ -44,6 +44,7 @@ downloads_PROGRAMS = downloads.dpi$(EXEE ftp_PROGRAMS = ftp.filter.dpi$(EXEEXT) https_PROGRAMS = https.filter.dpi$(EXEEXT) hello_PROGRAMS = hello.filter.dpi$(EXEEXT) +xproto_PROGRAMS = xproto.filter.dpi$(EXEEXT) subdir = dpi DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 @@ -53,14 +54,15 @@ am__configure_deps = $(am__aclocal_m4_de mkinstalldirs = $(mkdir_p) CONFIG_HEADER = $(top_builddir)/config.h CONFIG_CLEAN_FILES = -am__installdirs = "$(DESTDIR)$(bookmarksdir)" "$(DESTDIR)$(downloadsdir)" "$(DESTDIR)$(ftpdir)" "$(DESTDIR)$(hellodir)" "$(DESTDIR)$(httpsdir)" +am__installdirs = "$(DESTDIR)$(bookmarksdir)" "$(DESTDIR)$(downloadsdir)" "$(DESTDIR)$(ftpdir)" "$(DESTDIR)$(xprotodir)" "$(DESTDIR)$(hellodir)" "$(DESTDIR)$(httpsdir)" bookmarksPROGRAMS_INSTALL = $(INSTALL_PROGRAM) downloadsPROGRAMS_INSTALL = $(INSTALL_PROGRAM) ftpPROGRAMS_INSTALL = $(INSTALL_PROGRAM) helloPROGRAMS_INSTALL = $(INSTALL_PROGRAM) +xprotoPROGRAMS_INSTALL = $(INSTALL_PROGRAM) httpsPROGRAMS_INSTALL = $(INSTALL_PROGRAM) PROGRAMS = $(bookmarks_PROGRAMS) $(downloads_PROGRAMS) $(ftp_PROGRAMS) \ - $(hello_PROGRAMS) $(https_PROGRAMS) + $(xproto_PROGRAMS) $(hello_PROGRAMS) $(https_PROGRAMS) am_bookmarks_dpi_OBJECTS = bookmarks.$(OBJEXT) bookmarks_dpi_OBJECTS = $(am_bookmarks_dpi_OBJECTS) bookmarks_dpi_DEPENDENCIES = @@ -81,7 +83,7 @@ depcomp = $(SHELL) $(top_srcdir)/depcomp am__depfiles_maybe = depfiles @AMDEP_TRUE@DEP_FILES = ./$(DEPDIR)/bookmarks.Po \ @AMDEP_TRUE@ ./$(DEPDIR)/downloads.Po ./$(DEPDIR)/ftp.Po \ -@AMDEP_TRUE@ ./$(DEPDIR)/hello.Po ./$(DEPDIR)/https.Po +@AMDEP_TRUE@ ./$(DEPDIR)/hello.Po ./$(DEPDIR)/https.Po COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \ $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) CCLD = $(CC) @@ -198,6 +200,7 @@ downloadsdir = $(libdir)/dillo/dpi/downl ftpdir = $(libdir)/dillo/dpi/ftp httpsdir = $(libdir)/dillo/dpi/https hellodir = $(libdir)/dillo/dpi/hello +xprotodir = $(libdir)/dillo/dpi/xproto bookmarks_dpi_LDADD = @GLIB_LIBS@ downloads_dpi_LDADD = @GLIB_LIBS@ ftp_filter_dpi_LDADD = @GLIB_LIBS@ @@ -333,6 +336,28 @@ uninstall-helloPROGRAMS: clean-helloPROGRAMS: -test -z "$(hello_PROGRAMS)" || rm -f $(hello_PROGRAMS) + +install-xprotoPROGRAMS: $(xproto_PROGRAMS) + @$(NORMAL_INSTALL) + test -z "$(xprotodir)" || $(mkdir_p) "$(DESTDIR)$(xprotodir)" + @list='$(xproto_PROGRAMS)'; for p in $$list; do \ + p1=`echo $$p|sed 's/$(EXEEXT)$$//'`; \ + if test -f $$p \ + ; then \ + f=`echo "$$p1" | sed 's,^.*/,,;$(transform);s/$$/$(EXEEXT)/'`; \ + echo " $(INSTALL_PROGRAM_ENV) $(xprotoPROGRAMS_INSTALL) '$$p' '$(DESTDIR)$(xprotodir)/$$f'"; \ + $(INSTALL_PROGRAM_ENV) $(xprotoPROGRAMS_INSTALL) "$$p" "$(DESTDIR)$(xprotodir)/$$f" || exit 1; \ + else :; fi; \ + done + +uninstall-xprotoPROGRAMS: + @$(NORMAL_UNINSTALL) + @list='$(xproto_PROGRAMS)'; for p in $$list; do \ + f=`echo "$$p" | sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \ + echo " rm -f '$(DESTDIR)$(xprotodir)/$$f'"; \ + rm -f "$(DESTDIR)$(xprotodir)/$$f"; \ + done + install-httpsPROGRAMS: $(https_PROGRAMS) @$(NORMAL_INSTALL) test -z "$(httpsdir)" || $(mkdir_p) "$(DESTDIR)$(httpsdir)" @@ -480,7 +505,7 @@ check-am: all-am check: check-am all-am: Makefile $(PROGRAMS) installdirs: - for dir in "$(DESTDIR)$(bookmarksdir)" "$(DESTDIR)$(downloadsdir)" "$(DESTDIR)$(ftpdir)" "$(DESTDIR)$(hellodir)" "$(DESTDIR)$(httpsdir)"; do \ + for dir in "$(DESTDIR)$(bookmarksdir)" "$(DESTDIR)$(downloadsdir)" "$(DESTDIR)$(ftpdir)" "$(DESTDIR)$(xprotodir)" "$(DESTDIR)$(hellodir)" "$(DESTDIR)$(httpsdir)"; do \ test -z "$$dir" || $(mkdir_p) "$$dir"; \ done install: install-am @@ -530,7 +555,7 @@ info: info-am info-am: install-data-am: install-bookmarksPROGRAMS install-downloadsPROGRAMS \ - install-ftpPROGRAMS install-helloPROGRAMS \ + install-ftpPROGRAMS install-helloPROGRAMS install-xprotoPROGRAMS \ install-httpsPROGRAMS install-exec-am: @@ -560,7 +585,7 @@ ps-am: uninstall-am: uninstall-bookmarksPROGRAMS uninstall-downloadsPROGRAMS \ uninstall-ftpPROGRAMS uninstall-helloPROGRAMS \ - uninstall-httpsPROGRAMS uninstall-info-am + uninstall-httpsPROGRAMS uninstall-xprotoPROGRAMS uninstall-info-am .PHONY: CTAGS GTAGS all all-am check check-am clean \ clean-bookmarksPROGRAMS clean-downloadsPROGRAMS \ @@ -570,14 +595,14 @@ uninstall-am: uninstall-bookmarksPROGRAM html-am info info-am install install-am \ install-bookmarksPROGRAMS install-data install-data-am \ install-downloadsPROGRAMS install-exec install-exec-am \ - install-ftpPROGRAMS install-helloPROGRAMS \ + install-ftpPROGRAMS install-xprotoPROGRAMS install-helloPROGRAMS \ install-httpsPROGRAMS install-info install-info-am install-man \ install-strip installcheck installcheck-am installdirs \ maintainer-clean maintainer-clean-generic mostlyclean \ mostlyclean-compile mostlyclean-generic pdf pdf-am ps ps-am \ tags uninstall uninstall-am uninstall-bookmarksPROGRAMS \ uninstall-downloadsPROGRAMS uninstall-ftpPROGRAMS \ - uninstall-helloPROGRAMS uninstall-httpsPROGRAMS \ + uninstall-xprotoPROGRAMS uninstall-helloPROGRAMS uninstall-httpsPROGRAMS \ uninstall-info-am # Tell versions [3.59,3.63) of GNU make to not export all variables. diff -pruN dillo-0.8.2/dpi/xproto.filter.dpi dillo-0.8.2-xproto/dpi/xproto.filter.dpi --- dillo-0.8.2/dpi/xproto.filter.dpi 1969-12-31 20:30:00.000000000 -0330 +++ dillo-0.8.2-xproto/dpi/xproto.filter.dpi 2004-10-31 09:44:40.000000000 -0330 @@ -0,0 +1,64 @@ +#!/bin/bash +read -d'>' dpip_tag + +url=${dpip_tag##*url=\'} +url=${url%\'} +dproto=${url%%:*} +ddata=${url#*:} + +confdir="$HOME/.dillo" +if [ ! -d "$confdir" ]; then + if ! mkdir $confdir; then + msg="Error, could not make directory $confdir" + fi +else + conffile="$confdir/xprotorc" +fi + +if [ "$conffile" ]; then + if [ ! -e "$conffile" ]; then + echo " +# %d is replaced with just the data after the : +# %s is replaced with the full url +ed2k; ed2k.sh %s +mailto; sylpheed --compose %d +rtsp; realplay %s +gg; dillo http://www.google.com/search?q=%d" > $conffile + fi + if [ -e "$conffile" ]; then + while read line; do + line=${line%%#*} + fproto=${line%%;*} + if [ x"$fproto" = x"$dproto" ]; then + handler=${line#*;} + break + fi + done < $conffile + else + msg="Error, could not create file $conffile" + fi +fi + +if [ "$handler" ]; then + handler=${handler//\\%s/"$url"} + handler=${handler//\\%d/"$ddata"} + msg="Using: $handler" + output=$($handler &) +else + msg="No handler registered for protocol: $dproto +Please edit the config file: $conffile" +fi + +cat <<EOF +<dpi cmd="start_send_page" url="dpi:/xproto/xproto.filter.dpi"> +Content-type: text/html + +<html> +<head><title>Xproto Feedback</title></head> +<body> +<hr><h1>Xproto Feedback</hq><hr> +<pre>$msg</pre> +<h3>Command Output, If Any:</h3> +<pre>$output</pre> +</body></html> +EOF diff -pruN dillo-0.8.2/src/capi.c dillo-0.8.2-xproto/src/capi.c --- dillo-0.8.2/src/capi.c 2004-05-21 19:43:07.000000000 -0230 +++ dillo-0.8.2-xproto/src/capi.c 2004-10-31 06:03:28.000000000 -0330 @@ -247,6 +247,9 @@ gint a_Capi_url_uses_dpi(gchar *url_str, } else if (g_strncasecmp(url_str, "https:/", 7) == 0) { server = g_strdup("https"); + + } else { + server = g_strdup("xproto"); } return ((*server_ptr = server) ? 1 : 0); diff -pruN dillo-0.8.2/src/IO/Url.c dillo-0.8.2-xproto/src/IO/Url.c --- dillo-0.8.2/src/IO/Url.c 2004-05-21 19:43:29.000000000 -0230 +++ dillo-0.8.2-xproto/src/IO/Url.c 2004-10-31 06:19:57.000000000 -0330 @@ -108,6 +108,6 @@ ChainFunction_t a_Url_get_ccc_funct(cons if ( j == KeyLen ) return cccList[i].cccFunction; } - return NULL; + return a_Dpi_ccc; } -- Lee Bigelow Blatch Enterprises <ligelowbee(a)yahoo.com>

20 years

Dillo-dev search results for query "plugin"