Search results for "plugin" - Dillo-dev

Various minor patches

by Johannes.Hofmann＠gmx.de

On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote: > * 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? Not sure, it describes the same problem. I think the problem is that libiconv only exports libiconv_open() and the corresponding iconv.h header file defines iconv_open to libiconv_open. Unfortunately the test program generated by autoconf does not include iconv.h. Johannes > > -- > You may use my gpg key for replies: > pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen) > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

17 years, 9 months

Future of dillo2

by jcid＠dillo.org

On Mon, May 12, 2008 at 06:24:30PM +0100, Jeremy Henty wrote: > On Mon, May 12, 2008 at 12:20:45PM -0400, Jorge Arellano Cid wrote: > > On Mon, May 12, 2008 at 03:52:59PM +0000, corvid wrote: > > > The consequences of not informing the outside world about the progress > > > of dillo in any detail: http://wiki.linuxfromscratch.org/blfs/wiki/dillo2 > > > > Please feel free to write them to get that page back on track before > > somebody believes what was written. ;) > > I have a BLFS Trac account so I can probably do it myself. But what > should I change? At a glance: > > * We *do* support FTP and HTTPS. > * Change "can support cookies" to "supports cookies". Yes, but https is basic. If a page has multiple images, the dialog window may spam the user once per image. That's why https went disabled for normal users, and experienced guys/devs were left the chance to enable it. > * "Dillo always interprets web pages as if they had the ISO-8859-1 > encoding." True? It depends on what dillo they talk about. It looks like a dillo2 page, and in that case, it's FLTK2-based, it has nothing to do with GTK1, glib nor GTK2, just FLTK2. The code is now a mixture of C/C++ instead of pure C, etc... It's important to make a difference between dillo1 (C lang, GTK1/glib, __unmantained__, and dillo2 (active branch). If we talk about dillo2 then the statement: "Dillo always interprets web pages as if they had the ISO-8859-1 encoding." is absolutely false. > > * "useless for reading non-English web pages" Surely not true, though > maybe "useless for reading multibyte-encoded pages" is true. If we talk about dillo2, false again. Dillo2 uses utf-8 by default, and utf-8 is multibyte-encoded. On top of that we have all the work corvid put in the character decoding, so now dillo2 can decode a boat load of charsets into utf-8 using iconv. Non english pages render quite well provided you have the necessary fonts installed. There're a few exceptions as with those that render backwards or have collapsing glyphs. For instance, set: vw_fontname="DejaVu Sans" in ~/.dillo/dillorc2 and go to: http://www.gnu.org/home.fa.html Worth a thounsand words! then go to: http://www.gnu.org/ scroll to the bottom and you'll see plenty of non-english pages, that you can click into. If you go to: http://www.bds-bg.org/ you'll see windows-1251 charset handled properly by dillo. etc. > Anything else? Yes, we should compile and provide this information from our web site. Otherwise it will be extremely hard for a non-developer to get right. A good diff document may be got from reviewing the Changelog alone. Here we have the record of all the work we've put in dillo2; from time to time I find there things forgotten long ago! I'll try to update some pages in the site as soon as I find some time. That's the point: lack of time/manpower. All the help is appreciated. Another very important point to be stated is that the plugins and the dpi daemon need to be installed for most things to work. After the build this is done with: make install-strip. Bottom line: current dillo2 is for developers. After we make a release it will be user ready. HTH. -- Cheers Jorge.-

17 years, 5 months

dillo-2.1.tar.bz2

by jcid＠dillo.org

On Thu, Jun 18, 2009 at 09:01:39PM +0200, Devid Antonio Filoni wrote: > On Thu, Jun 18, 2009 at 6:57 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote: > > Hi, > > > > ?Working on: > > > > ? ? 1.- Solve the OpenSSL license issue and upload rc3. > > > > > > On Thu, Jun 18, 2009 at 05:24:25PM +0200, Devid Antonio Filoni wrote: > >> On Wed, Jun 17, 2009 at 11:45 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote: > >> > On Wed, Jun 17, 2009 at 10:01:12PM +0200, Devid Antonio Filoni wrote: > >> > [...] > >> > ?Devid: please send me the .deb and its directions when done. > >> DONE! You can find it at https://launchpad.net/~d.filoni/+archive/ppa > >> . However I found an error checking my package using lintian: > >> > >> E: dillo: possible-gpl-code-linked-with-openssl > >> N: > >> N: ? ?This package appears to be covered by the GNU GPL but depends on the > >> N: ? ?OpenSSL libssl package and does not mention a license exemption or > >> N: ? ?exception for OpenSSL in its copyright file. The GPL (including version > >> N: ? ?3) is incompatible with some terms of the OpenSSL license, and therefore > >> N: ? ?Debian does not allow GPL-licensed code linked with OpenSSL libraries > >> N: ? ?unless there is a license exception explicitly permitting this. > >> N: > >> N: ? ?If only the Debian packaging, or some other part of the package not > >> N: ? ?linked with OpenSSL, is covered by the GNU GPL, please add a lintian > >> N: ? ?override for this tag. Lintian currently has no good way of > >> N: ? ?distinguishing between that case and problematic packages. > >> N: > >> N: ? ?Severity: serious, Certainty: wild-guess > >> > >> Can you please fix it? > > > > ?AFAIS, the only program that links to OpenSSL is the https dpi. > > i.e. The ssl-enabled dillo binary doesn't link to it. > > ? ? https.filter.dpi links to it. > > > > ?IANAL, but it looks like giving permission for this dpi is enough, > > and it's already done in its sources (dpi/https.c): > > > > ?* [...] > > ?* As a special exception permission is granted to link the code of > > ?* the https dillo plugin with the OpenSSL project's "OpenSSL" > > ?* library, and distribute the linked executables, without including > > ?* the source code for OpenSSL in the source distribution. You must > > ?* obey the GNU General Public License, version 3, in all respects > > ?* for all of the code used other than "OpenSSL". > > ?* > > ?*/ > > > > > > ?Please let me know if this is _really_ enough or if some extra > > legal formula must be added somewhere else. > It should be enough, at least this is what I see for example at > http://lists.octality.com/pipermail/cherokee/2008-November/009408.html > (take a look in that page for more infos) Good! After reading it and the suggested URLs, especially [1], it looks like our current tarball (rc2) is enough. No new tarball is needed! I consider this point solved, so let's move to the second one... [1] http://www.openssl.org/support/faq.html#LEGAL2 -- Cheers Jorge.-

16 years, 4 months

Future of dillo2

by jcid＠dillo.org

On Sun, May 04, 2008 at 08:30:32PM +0200, Sebastian Geerken wrote: > Hi, Hi Sebastian! > just if you were courious: I'm still living and will continue working > on dillo. That's very good news. New developers are helping to push the project forward, and your presence is a very important asset for the team. > > On Sun, Apr 20, Jorge Arellano Cid wrote: > > [...] > > We could: > > > > * Attract new developers with a dillo2 release, > > leveraging the excellent documentation that we have. > > We have: > > - extensive documentations on the critical parts of dillo, expecially > on Dw, > - a prototype for CSS, and > - some more documents and prototypes on future ideas, including > scripting and graphical plugins. > > These should be copied on the web sever, and there should be a > prominent note on the web site linking to a new delevolers' section. > (Since attracting developers has high priority, this is what a visitor > should notice first.) Yes, I was planning on stating the quest for more developers in the splash page of the next release. BTW, it'd be great to also convert dillo2's plain text docs to doxygen format someday. > For those not listening to dillo-dev, it is important to know that > dillo is still an active project. I think we can sort the house and then make a release so the world knows. That's why having TABS and at least a CSS prototype matters. I don't want reviews to end with the typical line: "but no TABS and no CSS". ;-) If we have TABS (a thing I can spare some time to implement) and a CSS protoype published somewhere, the message will be more like: "it comes with: ..., antialiased fonsts, low-dependencies, UTF-8, TABS, and they already started with CSS." That sounds much better! > > * Planning for CSS, floating objects and TABS. > > (this are important features to a nice browsing experience) > > Just FYI: I've started a bit on floats. Jorge, I once told you that it > would take a week; actually it is a bit more complicated, nevertheless > it is not a big job like CSS. Speaking about floats, I was trying to make NBSP (non breaking spaces) work for pages like: http://fltk.org/newsgroups.php?gfltk.development+T (with a narrow window, the parenthesis are spared). but found that NBSP-handling wasn't coded in textblock yet: /* NOTE: Most code relies on that all values of nowrap are * equal for all words within one line. */ I planned to give it a try, but didn't know what was the model for handling it (a flag in the previous word, a flag in the previous and next word, an empty word, etc). Now that you're working in the textblock, can you give it a review? The attached patch is what the parser (html.cc) could look like to handle this. It uses WHITE_SPACE_NOWRAP in style, but I didn't know whether to use: addText(strdup(""), S_TOP(html)->style); or DW2TB(html->dw)->addSpace(S_TOP(html)->style); for NBSP whitespace. It should be simple to test with it. > > * Coordinate with FLTK2, DSL (Damn small linux) and other > > lightweight distros, Debian installer team, MINIX3, etc. > > Perhaps we can find there other "lightweight zealots". :-) Yes, and maybe someday people will start liking/using this lightweight browser. AMEN -- Cheers Jorge.-

17 years, 5 months

Various minor patches

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:36]: > On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote: > > * 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? > > > Before this patch, we had no test for iconv. Did it work for you then? > In a way yes. because my solution was to add -liconv to my LDFLAGS. Thanks for looking at this -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

17 years, 9 months

dillo 2.1

by sandshrew＠gmail.com

Been testing dillo 2.1 for some time and would like to share my experience. It's really great to see some basic css support (appearance of most if not all websites has improved alot), properly resized images, redirection and basic authentication working now :) Anyway, even dillo improved alot recently there still seems to be some issues. Here are some I've noticed after testing this release for few days: Rendering 1) ubuntu.lt Not sure if it's dillo fault or website's malformed stylesheet, but with default dillo settings some of the lithuanian characters are not displayed. This can be fixed by just adding "* {font-family: serif !important}" to the style.css. Here is a pic with some of the places where letters are missing marked in red: http://img4.imageshack.us/img4/2227/ubuntult.png 2) gmail It's nice that login works now, but with default dillo settings the size of most of the text is 1px. This can be partially fixed by adding font_min_size to dillorc, but it's obviously a dillo bug as this doesn't happen with links-hacked. 3) google What's with the textarea in the top left corner of the page? And just for information: signing out doesn't work because it requires basic javascript support (works with links-hacked). 4) Black on black, white on white... http://www.nma-fallout.com/forum/viewtopic.php?t=42776&start=2660&sid=a5712… For some reason black font color is used here and we get black text on black background in some posts (doesn't happen with links-hacked). http://www.acetoneteam.org/ Background color is not set here and if we have "body {background-color: white}" rule in our style.css file, we get white text on white background. 5) http://ubuntuforums.org/showthread.php?p=6592005 What's with the PINK blocks? If that's more of a "feature" then a bug, can the color be changed by using some css rule? 6) http://www.binaryworld.skynet.lt/DUK.html If we use one link with fragment identifier in the page, all the others are marked as visited too. 7) Authentication Basic authentication does work now, but at first the server displays a message saying "wrong credentials or browser doesn't understand how to supply the credentials" and only then a window pops up asking for the credentials... UI 1) Positioning the tab close button on the top RIGHT corner of the browser isn't a good thing because: a) The distance between the most commonly used buttons and the tab close button is pretty big (especially when widescreen monitors are pretty common nowadays); b) It only allows closing the active tab; I think it would be much better if all tabs had close buttons or at least the button was placed near the last tab. 2) Trivial but... because the setting to enable/disable image loading now is in the wrench menu it is two clicks away instead of one as it used to be in dillo 2.0. Maybe css settings could be left where they are now, but the setting for enabling/disabling images could be moved where it was in dillo 2.0? 3) UPPERCASE letters should be used in the File menu to define keyboard shortcuts, because now L looks like I (Open url... ctrl+l) 4) Don't you think "Are you sure you want to close the browser?" message is pretty annoying? Other: It seems whoever designed the new website theme has no idea what READABILITY means... It looks like someone just used some stupid online color picker, which just picks some similar colors to the one user chooses. The old website looked MUCH MUCH better. Imho, it's a regression... PS: how to install dillo 2.1 claws-mail plugin? -- Brain: an apparatus with which we think we think. - A. Bierce

16 years, 4 months

Re: Dillo not rendering HTML with comments before <!DOCTYPE>

by Rodrigo Arias

Hi, On Thu, Apr 25, 2024 at 09:23:38AM +1000, Kevin Koster wrote: >Thanks for the explanation, this also makes clearer an issue I had with >XHTML image indexes generated by ImageMagick Montage which were getting >(by an unusual sequence of events) the incorrect HTTP Content-Type type >of "text/xml" (and they don't contain a meta tag). They'd load properly >via file:// but show as text over http://. Now I know to ideally force >the HTTP Content-Type to "application/xhtml+xml" instead of "text/html" >which I used to fix the problem originally. For Dillo, "application/xhtml+xml" and "text/html" are handled by the same HTML parser, which later identifies which version of HTML/XHTML is the document, based on the doctype. The problem is failing to set the content type to any of those two, like when using "text/xml". AFIK, the proper content type for XHTML is "application/xhtml+xml", which should be set on the HTTP Content-Type header. >> Regarding the type guessing bug, I think I can improve it by assuming >> that if we find the "<!doctype html" string in the first 1024 bytes or >> so, it is an HTML-like type, but it incurrs in more overhead. > >But if it aborts that search upon encountering the first thing that >isn't "spaces, newlines, tabs, and comments", most text files will be >detected within the first few bytes. > >I'm not sure how that approach would work with ImageMagick image index >XHTML pages which start like this though: > <?xml version="1.0" encoding="US-ASCII"?> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > >Example: >http://www.ombertech.com/cnk/dillo/STS-133_Pictures/photo_index.html > >I don't really understand how XHTML is supposed to work, and I don't >have time to learn, so perhaps I'm ignoring a distinction between >differet flavours of XHTML that can begin in different ways? Anyway I >like how ImageMagick image map pages are viewable in Dillo at the >moment. We can improve the content detection to handle both HTML and XML-style comments, but I prefer to defer it after the 3.1.0 release. Websites shouldn't rely on the browser to guess the content type, it should be stated in the HTTP header or the meta tag. So I don't consider this a priority that should block the release for longer. If you want to work on it, feel free to do so :-) >> So I think for now we can rely on the correction of "text/xhtml" to >> "application/xhtml+xml", which seems to work fine. I don't like adding >> quirks, but I will keep this one as it was already there. Here is the >> PR: >> >> https://github.com/dillo-browser/dillo/pull/140 > >I've built Dillo from that branch and pages on www.lemis.com now render >correctly, thanks! If I save the homepage as lemis.xhtml it still shows >as plain text when loaded with file://, though it is rendered if the >comments before <!DOCTYPE> are removed or if the original file is saved >as lemis.html. Not much of an issue, but it could cause confusion for >someone. I pushed another patch that should fix this issue. It is caused primarily by the ".xhtml" extension not being recognized by the file plugin, which then tries to detect the doctype and fails in the same way, falling back to text/plain. Best, Rodrigo.

1 year, 6 months

Various minor patches

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 04:37:09PM +0100, Johannes Hofmann wrote: > On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote: > > * 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? > > Not sure, it describes the same problem. > > I think the problem is that libiconv only exports > libiconv_open() and the corresponding iconv.h header file defines > iconv_open to libiconv_open. > Unfortunately the test program generated by autoconf does not > include iconv.h. OK, I modified configure.in in CVS. This approach may work. Beware I don't have how to test this patch, so you will probably have to try and tweak. -- Cheers Jorge.-

17 years, 9 months

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by jcid＠dillo.org

Hi Christian, Sorry for the late answer, but I've had little spare time, and several topics to answer. Probably you have already read: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.ht… an got some info from there. On Sat, Mar 15, 2008 at 02:02:07PM +0100, Christian Kellermann wrote: > * Christian Kellermann <Christian.Kellermann(a)nefkom.net> [080315 09:49]: > > Dear list, > > > > In order to fix the https plugin I have stumbled upon the fact, > > that the former dialog code seems to be removed from cvs. To see > > what's goign on further down the code I have added a basic Yes/No > > popup using the existing a_Dialog_choice3 function. For this the > > numbering of the buttons have changed also in https. Dialogs with > > more than two alternatives will have the additional choices dropped > > silently. This is good for now but I really like to have it done > > right. Which function should get used instead of a_Dialog_choice3? > > > > Also what's the real purpose of http_request? At the moment I cheat > > and set it to url in case it is empty. Which value is to be expected > > when calling the document root in a URL? "/"? "/index.html"? or am > > I getting this all wrong? > > > > Whith this patch I can bypass the "certificate could not get verified" > > case but not much further. Also cancelling the dialog seems to leave > > some data behind, another call of https URLs won't do anything. But > > this is a bit better than it has been before... > > > > I am not sure whether I should stop beating this dead horse or > > continue. What's your advice? > > > > Ignore the http_request part I figured it out. > > Ok, I have changed the proto comparison from "https" -> "proto.https" > and I am able to view https sites again. This module still needs a > lot of cleanup. As a next step I want to implement simple certificate > caching so accepted certificates won't get prompted again. This > will be memory only at first, making the certificate valid (or > invalid) as long as the dpid lives. > > The updated patch is attached below. A long time ago, browsing was mainly fetching pages and images. It made a lot of sense to use an external tool (as wget) to grab https pages. Implementing this idea with dpi was also simple. Now, it may be not the case. You have to keep track of certificates, sessions, sometimes keep an open connection, etc. Years ago SSL wasn't widespread, today is an everyday need, so it may make sense to consider having it inside dillo. It can take some design time at the beginning but will be easier to maintain and extend than to have it living in an external dpi. Developers is what we need, so if you want to work on https, you're more than welcome. Lack of manpower is our biggest problem! "place" implemented gzip decoding in dillo2, he may help you with ideas on how to add an extra layer/decoding-stage for SSL. (With regard to your specific questions about https, you'll have to wait some time until I can look at it again in depth. IIRC there was a five option dialog requested through dpip that sent the answer back on what to do. It was removed from the code while porting, delayed for future implementation). Again, my suggestion is to consider an internal implementation. -- Cheers Jorge.-

17 years, 7 months

Re: Towards 3.2.0

by Rodrigo Arias

Hi all, On Thu, Oct 24, 2024 at 10:45:49PM +0200, Xavier Del Campo Romero wrote: >I would have preferred to resume my work on multipart/form-data, but I >have been too busy with other projects and IRL. The required changes >were way too complex to shoehorn into this release, so I assume they >will have to wait for the next one :) No worries :-) On Thu, Oct 24, 2024 at 11:09:46PM +0200, a1ex(a)dismail.de wrote: >I don't know about the complexity, but it worked fine here! Yeah, but I prefer to move to a new file when the format is more stable, so you can keep your rules intact. Now I'm experimenting. >Sounds good, but in that case, maybe we should provide an example >handler script in the docs, since that could be a barrier for some >users. > >I'm still using a variant of this[1] patch, but with multiple >entries, which still seems to be the easiest way of allowing external >actions. > >[1] https://alex.envs.net/patches/00-ext-link-handler.patch Yeah, maybe I could also make it like this so you can specify a program directly: actions="Open with external tool:/path/to/the/handler.sh default $URL" actions="Open as audio:/path/to/the/handler.sh audio \"$URL\"" actions="Open with MPV:mpv $URL" actions="Open with Firefox:firefox $URL" But this won't work well when the URL has characters that are interpreted by the shell. It "should" be like: actions="Open with external tool:/path/to/the/handler.sh default \"$URL\"" actions="Open as audio:/path/to/the/handler.sh audio \"$URL\"" actions="Open with MPV:mpv \"$URL\"" actions="Open with Firefox:firefox \"$URL\"" But is quite ugly. And I'll have to check if you can still inject some command in the URL, which would be dangerous. On Fri, Oct 25, 2024 at 09:12:21AM +1000, Kevin Koster wrote: >One action which would probably complicate things, but likely be >among the most used for me, would actually be something like "View >as text" (in Dillo). Effectively the inverse of "Save link as...". > >Websites with annoying MIME settings can give links that one wants >to view as text (eg. source code files), but the server assigns a >MIME value to them that makes Dillo download them to file. This >would force Dillo to display the link as a Text file regardless. Yes, I have also experienced this annoyance. It may be nice yes, not sure how complex to implement. >Also the view source plugin/rendering can choke a bit >performance-wise (on the modestly-powered computers I use, at >least) with the multi-MB webpages that are common today. Just >viewing as text might be a quicker option, eg. when looking to >manually extract a URL meant to load via Javascript. I think for very long text files this may continue to choke Dillo. Maybe you could add a external tool that pipes it to more(1) or less(1). >> Then, your handler will be invoked using the label as: >> >> /bin/the-handler <URL> <action-label> >> >> And you do whatever you find convenient in your handler, so you have >> more context to decide the proper action based on the label. I think >> this would cover most of the use cases of opening URLs with other >> programs without being too convoluted. > >What would the default behaviour be? Will Dillo install a default >handler with its own separate configuration file for setting up the >default 'action' behaviours? Or does the feature only appear after >each user has created their own handler? By default, no extra options. As you add the actions they appear on the menu. We may want to distribute an example handler for users to have a reference. Best, Rodrigo.

1 year

Dillo-dev search results for query "plugin"