Search results for "plugin" - Dillo-dev

Re: [Dillo-dev] CPU usage

by Andreas Schweitzer

Hi, > > AFAIR 0.7.3 had a bug which caused that. I'm running CVS on FreeBSD 4.8 > > That would be the one I am using. Where can find out how to do the CVS for FBSD 4.9? > I have not ever done anything CVS and would like to get this resolved. I guess once in a while there can go some CVS infos onto the mailing list and into the archive ;-) This will be for FreeBSD and not all applies for Linux distributions. First you need gmake (GNU make), autoconf and automake installed. On FreeBSD you can choose which version. Currently *I* use automake14 and autoconf213. But on Linux I have newer version (but don't use the very latest version). Before installing the CVS version, I would de-install the current one. If you used ports or packages to get dillo, that is. I.e. for FreeBSD : pkg_delete dillo-0.7.3 (The executable would be in the same place, and then FreeBSD's package management could get confused ... unless you get brave and install the CVS version not in /usr/local/bin/ ...) Also make sure to kill the bookmark server : killall bm_srv12 Then you could start with http://www.dillo.org/cvs.html or simply copying from that page : cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo login # just hit return here cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dillo # then continue with cd dillo ./autogen.sh ./configure gmake gmake install That's it. /usr/local/bin/dillo is now the CVS version. *Hopefully* everything works. By now, the new plugin framework should also have gotten installed with "gmake install". And from now on, if you want the latest version, go to the directory where you started with the inital cvs commands, then : cd dillo cvs up -d now you can try the "shortcut" : gmake gmake install if that fails, do the full thing : ./autogen.sh ./configure gmake gmake install Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

20 years, 9 months

patch: close windows from menubar

by Johannes.Hofmann＠gmx.de

On Thu, Oct 09, 2008 at 04:26:02PM -0400, Jorge Arellano Cid wrote: > 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. I think it's supposed to work more or less like in attached test program. When called with a (decimal) window id (from xlsclients) it draws a small but visible frame on that window. I don't know why it doesn't work correctly. Probabely some more setup necessary... Cheers, Johannes

16 years, 1 month

Re: [Dillo-dev] Very close to a new release!

by Jorge Arellano Cid

Andreas, > > The point is: testing it. Sadly I didn't received more than a > > single comment of its working. Now I'm asking again: please > > download the latest CVS, the bookmarks server, intall them, play > > with them, test and report how it works for you. > > With the CVS verion as of > > $ date -u > Mon Feb 3 16:38:33 UTC 2003 > > It works almost out of the box for FreeBSD (the latest stable) > The only thing : autogen.sh should be a /bin/sh script, > not a /bin/bash script to make it portable. > > Same for the small convert script for the bm_dpi. > I'll change those. > > Ah, if someone here has NFS mounted accounts (from another > > machine), I want to know how it works there. As unix domain > > sockets are accessible only to the local machine, and it listens > > on /tmp, it should work, but we need the proof! > > The NFS part works between 2 FreeBSD machines. Thanks for testing. May I bother you with the socket access test? > There is just one problem : dillo waits 128 cycles for > the plugin to get online. > On my machine, this seems to be not long enough. I > set it to 256, and then it says it waits 90-190 cycles to get > online ... weird ... and then it works. > Maybe this hard coded waiting is not such a great idea. Yes. The problem is the time gap between 'exec' and the dpi-program being operative. It should be minimal when the programs is on a local HD, but NFS may take some time. I added the wait cycles for this case, and don't know the "canonical" way to do it. Yes it could be done with a gtk-timeout function or something akin but the wait cycles were the simplest thing to begin with. ;) Cheers Jorge.-

21 years, 9 months

Re: dns over tls or dns over https

by pastebin＠gmx.com

Thanks - good information are you getting my emails to your gmail email? suggestion add 'to search for mbed TLS only' to '--disable-openssl' switch :) why don't you like dnssec? On Sat, 1 Jun 2024 21:58:42 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Sat, Jun 01, 2024 at 01:27:07PM -0600, pastebin(a)gmx.com wrote: > >Hi > > > >could someone give me an idea about dillo using 'dns over tls' or 'dns > >over https'? or using dnssec? > > The mobilized fork has added support for it, as it is provided by > libcurl (which they have switched to): > > > 20240522: New tarball. To enable DNS-over-HTTPS (DoH), you can now set > > the preference dns_over_https_url. > > https://www.toomanyatoms.com/software/mobilized_dillo.html > > My recommendation is to setup a local resolver on your machine, so all > name resolution is handled by it, not just Dillo. Then you can use > whatever mechanism you want (DoH, DoT, DNSSEC...). > > This would be especially useful if you download a file with Dillo, as it > would launch an external wget process. Or if you use any plugin that > performs network operations on its own. > > Here are some docs (even if you don't use Arch): > > https://wiki.archlinux.org/title/DNS-over-HTTPS > https://wiki.archlinux.org/title/DNSSEC > > I didn't check on my own how well that works, but I would rather keep it > out of Dillo if posible. > > >what about dillo using mbed-tls vs openssl? > >the configuration only shows a --disable-mbedtls > > The DNS resolution is done prior to interacting with any TLS library. > There is also a --disable-openssl switch to search for mbed TLS only, > see ./configure --help. > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

5 months, 2 weeks

Re: [Dillo-dev]why use "ccc chain" instead of calling the function directly?

by Jorge Arellano Cid

On Sat, 3 Apr 2004, [gb2312] Lei Jin wrote: > Use "ccc chain" mechanism makes the code seeming uniform. But > it cause the source code difficult to understand because lots > of indirect function call and variety of parameters. The other way is to use threads and mutexes (much more complex and a bit slower too). > I wonder whether we can call the target function directly > instead of using "ccc chain", but I do not know if there is > difference between these two methods ??? The CCC is not just a way of making function calls, is a theory that allows for implementing non-preemptive parallelism without threads or forks. All the networking and error control in Dillo is driven by these pseudo-threads each shaped as a dynamic CCC. There can be even hundreds of them running at the same time (depending on the page, and on how many pages are loading in the background). Each thread doing network jobs can linger for a long time (generally measured in seconds, depending on latency, network load, size of the transfer, bandwidth etc) --that explains the need for a parallel approach--, now, each one of those threads needs independent error control and recovery, and it may have several steps to perform, so it also has to keep track of its state. That's the job of the CCC. It looks like contrived complexity, for sure, but that's mainly because people don't even start to realize that it handles parallelism in a single address space. This is a bit of my fault, I created the theory while working on Dillo, but I've never had the time to write it down and present it in abstract. Priorities always stood in the way. To my relief, it has worked rock solid, flexible enough to even account for plugins, and has needed low maintenance. Beleieve it or not, when things arrive to this state, the Jargon file regards them as "Deep magic". Cheers Jorge.-

20 years, 7 months

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

by Frank de Lange

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. I have already removed some preferences which could be combined (frame_blank_in_tab and tab_on_middle_click -> tab_instead_of_window) or which should be defaulted to the new functionality (document_title_use_url). Other suggestions Sebastian made are: - Remove tab title compression/shortening (I might create a new label widget which compresses/shortens text to a given size for this functionality) - 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) - rename "DilloDoc" to something else (I do not agree, DilloDoc is descriptive and short) The current state of the patch is: - still have conditional compile - have removed unnecessary preferences - have removed some recent changes to CVS nav.c which conflict with document/interface separation (have mailed Jorge about this) - have added incremental search and status-bar search widget (instead of popup) I will release a new version today or tomorrow Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

21 years, 1 month

Re: [Dillo-dev] cookies dpi patch is on CVS now

by Diego Sáenz

El Fri, 5 Aug 2005 14:00:16 -0400 Jorge Arellano Cid <jcid(a)dillo.org> escribio: > 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! > Then other thing to mark as in cvs in the current plans page. Thanks for the modifications, specially for MSG/_MSG and english corrections :P > 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 think that the way to register dpis and the mime that each dpi understand is needed before that. If dillo use mailcap then it will have a lot of configuration done, but dillo need to support dpis for mime too so they work with dillo better. I am open to change mi opinion with a better solution, of course. > > 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... I await it. > > > -- > Cheers > Jorge.- > Diego Sáenz / Darkspirit

19 years, 3 months

Re: [Dillo-dev] HTTPS Patch

by Andreas Schweitzer

On Thu, Nov 13, 2003 at 04:40:35PM +0100, Stephan Goetter wrote: > Am Thu, Nov 13, 2003 at 12:23:52PM +0100 schrieb Indan Zupancic und sprach: > > > I think something like Arch or Subversion, with an accompanying Wiki for > > > developers and users to converse (and converge) is a good idea. > > > > I'm starting to doubt the whole idea, how nice it may be: Are there any > > other active patch makers out there except us? > > I'm working on JavaScript support for dillo using the SpiderMonkey > C-Engine of the Mozilla project: http://www.mozilla.org/js/spidermonkey/ At some point I was thinking (or rather fanatsising :-) ...) about using http://www.bbassett.net/njs/ as a Javascript Interpreter. (That was when I first understood plugins and played with them.) > The patch is not yet stable/clean enough to post it here and it lacks > a lot. Currently I try to clean it up and get the focus set on google. Google uses Javascript ? > I know most people here have low-end machines and there is probably no > interest in JavaScript support in the main branch. IMHO it could be useful to have an extremely light implementation. Only the OnClick, OnSUbmit things. I read on the specs etc., understood only a portion and probably remember only a tiny fraction now :-). But I remember, that it may make sense to only implement a handful of Javascriopt things (as you see, I even forgot the terminology), It may still be compaitible with dillo's design goals. I was mainly thinking of the sites that use Javascript to pop up new windows on clicking some links - which could just as easily be implemented in HTML. I.e. the ones that don't know the difference between Javascript and HTML. Also, the OnSUbmit thing seems to be useful for checking form values before submissions. However, all in all, I use dillo because it does NOT support Javascript and let the browser invade my desktop :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

21 years

patch: python filter DPI supporting the "data:" scheme from RFC 2397

by Ben Wiley Sittler

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

18 years, 11 months

[Dillo-dev]Re: Remote control of displayed URL

by Ian Walberg

Jorge, I have a kiosk type setup where I need to be able to reset dillo to a given URL from another programme and then allow the user to navigate on their own. I really do not care how this is achieved but I do not want to restart dilio with a specific URL each time. Thanks Ian -----Original Message----- From: dillo-dev-admin(a)auriga.wearlab.de [mailto:dillo-dev-admin@auriga.wearlab.de] On Behalf Of dillo-dev-request(a)auriga.wearlab.de Sent: 09 July 2004 05:27 To: dillo-dev(a)auriga.wearlab.de Subject: Dillo-dev digest, Vol 1 #462 - 1 msg Send Dillo-dev mailing list submissions to dillo-dev(a)lists.auriga.wearlab.de To subscribe or unsubscribe via the World Wide Web, visit http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev or, via email, send a message with subject or body 'help' to dillo-dev-request(a)lists.auriga.wearlab.de You can reach the person managing the list at dillo-dev-admin(a)lists.auriga.wearlab.de When replying, please edit your Subject line so it is more specific than "Re: Contents of Dillo-dev digest..." Today's Topics: 1. Re: Remote control of displayed URL (Jorge Arellano Cid) --__--__-- Message: 1 Date: Thu, 8 Jul 2004 08:26:48 -0400 (CLT) From: Jorge Arellano Cid <jcid(a)dillo.org> To: Dillo mailing list <dillo-dev(a)lists.auriga.wearlab.de> Subject: Re: [Dillo-dev]Remote control of displayed URL Hi Ian, On Tue, 6 Jul 2004, Ian Walberg wrote: > I would like to be able to command dillo via a socket to a specific > URL from another application. > > Can this be done already? Yes it can be done. The specific dpi to provide for that service is not written yet, but the bookmarks-dpi commands dillo to open and refresh URLs all the time. > I tried a simple server plugin but did not get the > results I was looking for. Please explain further what you want to do. It may be a couple of days to write a specific server and get it working depending on what is required. > Thanks No problem. Cheers Jorge.- --__--__-- _______________________________________________ Dillo-dev mailing list Dillo-dev(a)lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev End of Dillo-dev Digest

20 years, 4 months

Dillo-dev search results for query "plugin"