Search results for "plugin" - Dillo-dev

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

by Globe Trotter

So, I assume that Jorge has not been able to get Sebastian to respond to his calls? It looks like Dillo is on its way to becoming history....what a sad way to end.... Trotter --- Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > 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. > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

17 years, 6 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.-

15 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.-

16 years, 6 months

Re: [Dillo-dev]RPM question, and how close is 0.8.0?

by Jorge Arellano Cid

Hi Kelson! On Tue, 3 Feb 2004, Kelson Vibber wrote: > At 08:21 AM 2/3/2004, Jorge Arellano Cid wrote: > > I'll start working on it after the 0.8.0 release. > > Any idea how soon that's coming? The idea is to have it ready this Sunday so the announcement is made by Monday in the morning. The newest CVS has the splash screen (grammar corrections are welcome:), and the pending issues are: * dpis should be able to run from ~/.dillo. I'll check that and maybe provide a shell script to install them there for users not having root access. * pthreads is still linked in dpis. This needs a patch but it's not indispensable. The release will be made with or without it. * Maybe it'd be good to mute dpid when started by dillo (to avoid printing to the terminal, specially when it exits). Not sure though and it's also a minor thing. * Expect reports on portability. This has been done to a good extent so I'll not delay the release because of it. After the release I'll take a week off! :-) > I've started making the necessary changes > for the RPM spec based on the current CVS version. With luck I'll be able > to start building as soon as the tarball is ready. I've posted some test > RPMs at http://www.hyperborea.org/software/dillo/pre.html if anyone's > interested. > > Question: I noticed that several of the included DPIs (https, ftp, > download) require wget. However, the main browser does not require > wget. That leads to several choices as far as RPM dependencies go: > > 1. Include all DPIs in the dillo package. Don't require wget. > 2. Include all DPIs in the dillo package. Do require wget. > 3. Separate the FTP, HTTPS, and download DPIs into a separate package > (something like "dillo-protocols") and set that package to require wget. > > Advantages: > #1: Simple installation, most linux distros probably already include wget > #2: Simple installation, lets you know about wget if you haven't installed > it already. > #3: If you don't want wget, you're not forced to install it. If you want > the plugin, you're told wget is needed. > > Problems: > #1: If you don't have wget, installing won't tell you that you need it. > #2: If you don't want to use those DPIs and you don't want wget, you need > to install it anyway. > #3: Installing is more complicated, because you have to download and > upgrade two RPMs. > > I don't think #1 is really an option, because it means people can install > dillo via RPM and not everything will work. > > I'm inclined to choose #2 over #3, just because of the simplicity. If > someone just wants to install Dillo, they already have to look through a > list of about 10 different RPMs for the right system, and sometimes people > miss the one they need. I occasionally get requests to add an RPM for a > system that's already on the list. On the other hand, some people might > consider wget to be unnecessary if they're not going to be using those DPIs. > > Anyway, has anyone got any thoughts on this issue? Just as you, my choice is #2. Cheers Jorge.-

20 years, 9 months

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

by Ben Wiley Sittler

One more update (this should be the last for awhile) -- this fixes crashes caused by stalled incomplete reads (due to EAGAIN on the C side.) I've attached the updated python filter in addition to the full patch since only the python changed. On 12/5/05, Ben Wiley Sittler <bsittler(a)gmail.com> wrote: > This updated copy of the patch corrects Content-Type defaulting > (text/plain;charset=US-ASCII if empty, text/plain if empty but charset > given.) > > This appears to work with all the Mozilla data: URL test-cases except > the JavaScript, CSS, XUL and MP3 ones (the MP3 one deserves further > investigation.) See: > > http://www.mozilla.org/quality/networking/testing/datatests.html > > On 12/5/05, Ben Wiley Sittler <bsittler(a)gmail.com> wrote: > > 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

Re: [Dillo-dev] Re: [PATCHES] hand_cursor and image_popup, some remarks

by Frank de Lange

On Tue, 9 Sep 2003 15:57:42 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Yes, that problem is known since a long time. It was very hard > to root down! The good news is that it's solved. > > It's not a problem of dillo but of GTK1. details here: > > http://mail.gnome.org/archives/gtk-list/2003-June/msg00289.html > > (As Sebastian, I think we'd better solve this with GTK2.) This is not the same problem. set-focus-chain allows you to program around this problem... The real problem, however, is still there... There is a widget, somewhere, which gets focussed without showing a visible focus cue (this is the problem you described, which could be avoided by setting an explicit focus chain) and - the real problem - does not allow the tab key OR gtk_widget_grab_focus(some_other_widget) to shift away focus from it. > > > > Clashing with other apps. is almost unavoidable (unless we > > > clone), but we have chosen to rely over an underlying cognitive > > > model for our UI. It has been very succesful, and praised! > > > > > > Now, as a matter of serendipity :), the bouncing keyboard may > > > have shown us both a better way. If we make Ctrl-L focus the > > > location bar (as Ctrl-U does now) and a second Ctrl-L to clear > > > it, that may be a good choice. > > > > Well, Ctrl-U is generally used for 'clear entry' in GTK1 (not > > in GTK2 though), so I think it is best to use it for that purpose > > in Dillo as well. For GTK2, following the toolkit default > > bindings is the logical thing to do. > > For now, I'll leave it as explained here: > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/001113.ht… Well, let's just say that I do not agree with all the choices (Ctrl-S for searhc the web? While just about every other application uses that for 'save'? And while searching can be done from the location bar or a search box? Please, no...) and, since I am not only a developer of (my version of) Dillo but also a user, I want my browser to do what I want, not what someone else thinks it should do. Hence the preferences. I guess I'm not the only one who feels like that - I know I'm not - so I feel that user choice is a good thing. Havoc's ideas notwithstanding. By the way, Havoc speaks about 'having good defaults'. Well, I think Dillo has some good defaults. But some defaults are less than good. Those which are - in the user's opinion - less than good can be changed using a preference (in the dillorc or some future preference plugin), those which are fine are left at their default setting. So, the user has as few or many preferences in the preference file as s/he wishes. Ain't choice a beautiful thing? Those who want their I-want-to-be-able-to-control-EVERYTHING app can have it, while those who are happy with the defaults can go by without any preferences at all... 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, 2 months

Re: [Dillo-dev] Java in Dillo

by TBlittlefoot

On Sun, Sep 04, 2005 at 08:25:51PM +0100, Jeremy Henty wrote: > On Sun, Sep 04, 2005 at 11:14:38AM -0700, TBlittlefoot wrote: > > On Sun, Sep 04, 2005 at 10:36:57AM -0700, Kelson Vibber wrote: > > > If I were to guess, they're probably using HTML for the background > > > and CSS for the text, or possibly doing something nonstandard like > > > putting <font color="white"> at the beginning of the page instead > > > of inside each block element. So the site is either badly > > > designed (relying on two separate technologies instead of one for > > > something as critical as readability) or badly coded (using code > > > that happened to work in Netscape 2 and IE, but fails in a > > > stricter rendering engine). > > > > Good, Kelson. I'll send this thread to the webmaster there. > > Please be tactful about doing this. You don't want to come across as > saying "Your web site breaks in some bizarre web browser you've never > heard of. It's probably because you're incompetent". It's possible > the site designer has no interest in browsers that don't support CSS > and doesn't want to be bothered by people who use them. It's possible > they *know* the coding sucks but are tied to a framework that > generates sucky code and are sick and tired of well-meaning bug > reports that they can do nothing about. It's possible they won't know > what on earth you're talking about. At the very least it would be > considerate to examine the HTML first so you can give some details > rather than a vague "Your web site's broke". Good advice, Jeremy. I'll be polite and much more general: Myself and a lot of other folks are really tired of all the pointless (in terms of substance) and bandwidth-consuming requisites of a lot of websites these days, where the (erroneous) assumption that we all use the latest version of MSIE seems to reign. A lot of us don't even use Windows and have no intention of getting a high-speed connection to the Internet. We don't do sound or java or cookies or plugins or video. On my perfectly functional and RFC-compliant graphical browser, your page displays as mostly blank. It turns out that the printing is white on white... So I use my textmode browser to view it. Have a nice day. No, Bill Gates and his minions do not run my computer, and if you are going to let him run your website, then it is going to look like garbage on my browser and I'll look for another site where the webmaster has thrown off the yoke of the Dark Lord Gates --- Three OS's from corporate kings in their towers of glass, Seven from valley lords where orchards used to grow, Nine from dotcoms doomed to die, One from the Dark Lord Gates on his dark throne In the Land of Redmond where the Shadows lie. One OS to rule them all, one OS to find them, One OS to bring them all and in the darkness bind them, In the Land of Redmond where the Shadows lie. ----------------- :-) Might have gotten a little carried away there! I'm a webmaster, too, Jeremy. I follow the printable standard: What you see with your browser is what you'll see on paper if you print out the webpage. Tom

19 years, 2 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)

16 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

15 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.

6 months, 3 weeks

Dillo-dev search results for query "plugin"