- Dillo-dev - lists.mailman3.com

Future of dillo2

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Diego wrote: >> With my recent patch (dpid-cleanup-and-DPIPATH.dillo2) one can use the >> attached script to run dillo in-tree which is nice if you just want to >> try it out but should also be useful for development purposes (easily >> manage different branches without the need to install them somewhere). > > The patch seems good to me, but i have not look it very deep or test it. Some more testing turned out that it's not enough to add another path to search for dpis. With no dpidrc fill_services_list fails: [dpid]: dpid.c:467: fill_services_list: Fatal error [dpid]: - Can't find the directory for dpis. This seems very non-plugin-like to me. What's the point in being able to have dpis in ~/.dillo/... but to actually use them you have to add them to your ~/.dillo/dpidrc. I mean it's okay up to this point, but consider you have one custom dpi in ~/.dillo/... : * in order to use it you have to create a custom dpidrc too * judging by a quick look at dpid.c/register_service I'd say that you have to copy the content of the system wide dpidrc file too since your custom one takes preference over the system wide one * now there's a package installed containing one more dpi. It might be doable to update the system wide dpidrc via a post-install script within the package (though thats error prone, you have to remove your entries on package removal etc.) * but what about the custom dpircs? You cannot have the post-install script modify those as well (well, you could, but naaa) > The idea is that each dpi can have its own files in its directory > (preferences, data, cache files ... ). I could go with preferences and data files, but caching feels like a no-no to me since on most installations the user is unable to write into those directories. Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKgZ9oPmwNWhsaZYRAjL+AJ9SjhWBUNh5WcO51GkJLaqtDyjFEwCeMQkz jkTcvl8xIbP3EedZP8T72fc= =xAX5 -----END PGP SIGNATURE-----

May 13, 2008

Future of dillo2

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Kemnade wrote: > Hmm, can you really fully test dillo in its build directory? > You won't have the dpi stuff and loose functionality. Perhaps that should be > noted too. With my recent patch (dpid-cleanup-and-DPIPATH.dillo2) one can use the attached script to run dillo in-tree which is nice if you just want to try it out but should also be useful for development purposes (easily manage different branches without the need to install them somewhere). One catch is the way dillo expects the dpis to be in their own directory the script solves that by creating a temporary directory, but this seems like a bad hack. What is the big idea behind this anyway? * dpis cant usually write to "their" own directory anyway * afaik this isn't a namespace thing either (since the directory is named like the executable without the .dpi extension) So unless there's a reason that I cannot see I would suggest to get rid of the X/X.dpi thing all together and stuff them all into one directory. Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKdUToPmwNWhsaZYRAqtyAJwNUOKoOPhKxJGAKKRBl68kIQ5PCQCgpV3D VFbjZobjZbmkSbEFa8lyNAY= =ro4T -----END PGP SIGNATURE-----

May 13, 2008

patch: Re: [Dillo-dev] should zlib be required?

by jcid＠dillo.org

On Mon, May 12, 2008 at 10:24:19PM +0000, corvid wrote: > Joerg wrote: > > On Sat, May 10, 2008 at 12:17:37PM +0000, corvid wrote: > > > Should zlib be required? > > > > Given many sites allow compression for HTML pages, it is useful to have > > around anyway. I would just make it a requirement. > > Attached. > I'm not sure that the old_libs code is serving any purpose, > but, being an autoconf newbie, I left it alone. Autoconf is a complex dragon! old_libs was for not stuffing libz in LIBS when the test failed. That way it could continue without zlib and without png. Now, IMHO it looks orthogonal and clean to leave it there. Committed. (now let's pray for it to work everywhere... :-) -- Cheers Jorge.-

May 13, 2008

Future of dillo2

by jcid＠dillo.org

On Mon, May 12, 2008 at 10:30:14PM +0000, corvid wrote: > > On Mon, May 12, 2008 at 09:35:46PM +0000, corvid wrote: > > > > http://www.dillo.org/Plans.html > > > > > > Did you commit/make/whatever it? > > > I thought "What changed?" and looked at a cached version, > > > and didn't see any differences. > > > > Not much here AFAIR the form elements and the rewrite of tables > > have now a green ball (finished). > > > > The bulk of it is adding what "should" be added. :-) > > I see the problem now. > > You didn't update the alt tags :) Yes! Now they're updated, and the extra items added, some sorting made and it looks more like what we have. I believe if we can complete the high priority items and stabilize the code we'd have a release candidate in our hands. If Sebastian completes the floating objects in textblock, that'd be great for the release, because dillo2 would show much better rendering in DIV-based and TABLE-based pages Comments? -- Cheers Jorge.-

May 13, 2008

patch: Re: [Dillo-dev] should zlib be required?

by corvid＠lavabit.com

Joerg wrote: > On Sat, May 10, 2008 at 12:17:37PM +0000, corvid wrote: > > Should zlib be required? > > Given many sites allow compression for HTML pages, it is useful to have > around anyway. I would just make it a requirement. Attached. I'm not sure that the old_libs code is serving any purpose, but, being an autoconf newbie, I left it alone.

May 13, 2008

Future of dillo2

by jcid＠dillo.org

On Mon, May 12, 2008 at 11:40:41PM +0200, Diego . wrote: > 2008/5/12 Jorge Arellano Cid <jcid(a)dillo.org>: > > > On Mon, May 12, 2008 at 03:51:42PM -0400, Jorge Arellano Cid wrote: > > > [...] > > > I'll try to update some pages in the site as soon as I find > > > some time. > > > > Just updated: > > > > http://www.dillo.org/cvs.html > > > > with directions on how to get dillo running. Developers, > > packagers, and experienced user should be pointed here. > > > > Somebody please check the directions work. :-P > > > > I doubt about the "exit" command, but i have not test the directions. "exit" is used as "logout" to get out of root. > and: > > > > http://www.dillo.org/Plans.html > > > > There is a line not updated under the "Current Plans for dillo2" text: > "--updated February 2007" > > It can be confusing. Ooops. Fixed. -- Cheers Jorge.-

May 13, 2008

Future of dillo2

by jcid＠dillo.org

On Mon, May 12, 2008 at 03:51:42PM -0400, Jorge Arellano Cid wrote: > [...] > I'll try to update some pages in the site as soon as I find > some time. Just updated: http://www.dillo.org/cvs.html with directions on how to get dillo running. Developers, packagers, and experienced user should be pointed here. Somebody please check the directions work. :-P and: http://www.dillo.org/Plans.html with what's already done. Note that we have more features than what this page states. Some new features as: * multiple character sets (in both HTTP and META). * HTTP-1.1's chunked transfer support. * optional image loading. * experimental gzip decoder. * Implemented the file input control for forms. * Optimized scrolling. * 64-bit ready out of the box. should be added here. -- Cheers Jorge.-

May 12, 2008

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

May 12, 2008

Dillo freeze

by Johannes.Hofmann＠gmx.de

On Mon, May 05, 2008 at 05:41:32PM -0400, Jorge Arellano Cid wrote: > Hi there, > > Dillo freezes on this page: > > http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.6.tar.bz2.sign > > Dillo bug or FLTK2? Other than I initially thought it is a Dillo bug. The IOwatch for reading is not removed properly. As a result the select call in the fltk event loop keeps failing with EBADF. Attached is a fix for the problem, but I'm not sure whether it is correct. Jorge, can you please have a look at it? Cheers, Johannes

May 12, 2008

Future of dillo2

by onepoint＠starurchin.org

On Mon, May 12, 2008 at 08:08:38PM +0200, Andreas Kemnade wrote: > Hmm, can you really fully test dillo in its build directory? You > won't have the dpi stuff and loose functionality. Perhaps that > should be noted too. Good catch! We don't want BLFS telling users to run Dillo in ways we don't support. Personally I don't understand the author's fear of installing alpha software. Does Dillo's "make install" do anything other than install a few executables and config files? If not then what's the problem with installing it? Also, the instructions should specify " ./configure --prefix=/usr " as the BLFS convention is to install everything in /usr rather than /usr/local . Jeremy Henty

May 12, 2008