May 2008 - Dillo-dev - lists.mailman3.com

website FAQ update

by corvid＠lavabit.com

I made http://www.dillo.org/FAQ.corvid.html The old FAQ is still at http://www.dillo.org/FAQ.html for now. So if you have comments/find mistakes/whatever....

May 15, 2008

tabs - what are they?

by corvid＠lavabit.com

Johannes wrote: > while thinking about tabs I realized that I'm not really sure > what they are. > > * On the one hand they could be implemented just as a GUI alternative > to multiple bowser windows. > > * On the other hand they could be something like temporary bookmarks > that are easily accessible e.g. via buttons below the panel. That > way one would only need one layout and view. > The only issue here would be that one would expect a separate > navigation stack for each "tab". This mail http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-January/003685.html says the latter. PS I read your subject line and thought, "They're eight spaces, of course." :)

May 15, 2008

tabs - what are they?

by Johannes.Hofmann＠gmx.de

Hi, while thinking about tabs I realized that I'm not really sure what they are. * On the one hand they could be implemented just as a GUI alternative to multiple bowser windows. * On the other hand they could be something like temporary bookmarks that are easily accessible e.g. via buttons below the panel. That way one would only need one layout and view. The only issue here would be that one would expect a separate navigation stack for each "tab". What do you think? Cheers, Johannes

May 15, 2008

Dillo freeze

by jcid＠dillo.org

On Mon, May 12, 2008 at 09:29:11PM +0200, Johannes Hofmann wrote: > 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? I'm reviewing it, and in the process found 3 more bugs related to the same problem, but not necessarily to the patch... Stay tuned. -- Cheers Jorge.-

May 15, 2008

patch: some more window deletion

by corvid＠lavabit.com

I thought I was going to have to remove the viewport from the UI because both UI and layout would want to delete it, but it appears that TopGroup gets informed of the deletion and everything turns out fine.

May 15, 2008

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