November 2003 - Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] HTTPS Patch

by Madis Janson

On Tue, 11 Nov 2003, Mike Eriksen wrote: > Sorry to interrupt... I'm a keen user of Dillo but no hacker. I'll not > comment on all the internals of Dillo since you guys are much more clever > on this than me. > > But, see - the reason why I like Dillo is that it is light and mean - and > can be tweaked into something I need. My need is a *light* browser which > can be fitted into a thin client but still allow you to read web mail. > This requires frame and https support. Other users of Dillo, like PDA > users, couldn't care less about frames and https. > you can use my patch for 0.7.3 until something better appears... http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz-wtab.diff.bz2 http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz.html It contains both tabs patch v6 and one https implementation (mine), but you should read sslgw/README to get it work, if you want to use it. Note: When Indian continues to maintain his https patch i'll probably do not bother with mine, lazy as i am... Also the Indian's idea of cleaning up ccc into something more easy to understand is nice (current ccc has at least one bad property - it is _hard_ to understand what goes on in it). > The key point here is that neither I nor the PDA guys really have > anywhere else to go than Dillo. >

Nov. 11, 2003

Re: [Dillo-dev] HTTPS Patch

by Frank de Lange

Indan Zupancic wrote: > Having a central place for all Dillo patches is always useful, because > that way it's easier to find and use them for users. Centralised isn't the > same as semi-official, it's a united effort of the patch makers. And that > means they probably have something betters to do, say, improving their > patch and keeping it up to date with cvs. ;) Another thing we can do is go the 'sylpheed-claws' route: create an extended version of Dillo, which regularly syncs up with Dillo CVS (and, possibly, the other way around). That way it is easier to create and maintain those features which are missing from Dillo. The risk is of course that the extended version starts to divert so far from CVS that it is hard to use it as a base to patch CVS. I've thought about going that way with the tab/frame/keyboard_navigation patch, as it does not get that much exposure currently. I have not done it yet, but given the number of patches which languish because of lack of exposure it is probably a good start. An 'experimental' branch on CVS and the main Dillo site would work as well of course... 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." ]

Nov. 11, 2003

Re: libpng detection again...

by William Trenker

Jorge Arellano Cid wrote: > <candidate line> > CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --cppflags`" > </candidate line> Yes! Hooray! I've been struggling with this for months and at last I have Dillo back again. After applying this change to configure.in and re-running autoconf the ./configure worked and I was able to build Dillo without a hitch. Thank you very much. And thanks Dillo team for a great browser! Regards, Bill

Nov. 11, 2003

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

> When I tried to add Indans https patch, it > didn't work. Too old. Two weeks ago I tried the same. At that time the > problem was the opposite! Plain bad luck, Jorge just changed those files enough, and I was bussy with making a pc stable and upgrading it, all my Dillo files are backuped on another pc now, it's a slight mess. :) Also I want to merge the read/write IOData structures, and change to the GDK API, if Jorge and others agree with that. If that's going to change then updating my https patch now is a waste of time, because relatively much is going to change (the https patch will shrink incredibly :). > But in my humble oppinion either Dillo should release official minor > version (0.7.4, 0.7.5 etc) more often so privateers can offer patches > against these, or go along with this suggestion of Indans and support a > semi-official patch model. More often is not the point, Dillo is relatively close to 0.80 and far away from 0.73, so this seems to be just an unfortunate time for patches. Normally you should just use the 0.73 patches. There is no 0.73 https patch from me because I'm not happy with the current implementation, caused by all the hassle with keeping the two IOData structures synced and GTK's io channel annoyance. If there are fewer official Dillo versions it's easier to keep all the patches up to date. Actually, all what is needed is a cvs tag for each stable release, and maybe some extra tag for sort of beta versions that can be used for patches if it turns out that the official releases are not often enough for the patches. This way it's clear for the patches what Dillo version to use, so all can be relatively easily kept synchronized (at least for what Dillo version the patches use). Having a central place for all Dillo patches is always useful, because that way it's easier to find and use them for users. Centralised isn't the same as semi-official, it's a united effort of the patch makers. And that means they probably have something betters to do, say, improving their patch and keeping it up to date with cvs. ;) Greetings, Indan P.S. Seems like I just can't write short mails. :(

Nov. 11, 2003

Re: [Dillo-dev] HTTPS Patch

by Mike Eriksen

On Mon, 10 Nov 2003, Indan Zupancic wrote: [cut - a lot!] > > Making a web site (or page for it) requires time, if you're > > willing to do that, go ahead but beware that we do not support > >unofficial patches so you'd have to answer all the incoming > >questions too. > > Hmm, a web page, mind if I use the code of the splash screen as a basis? I > only want to make an installer so that it's easy for people who, for > instance, don't know what cvs is, to get a patched Dillo version. The goal > is to have some sort of centralized patch place, with patches that work > with eachother and are up to date. It requires time, true, but I'm willing > to spend time on Dillo. The installer has no priority though, would rather > spend my time to unite the IOData structures, switch to the GDK api, and > clean up the https patch for now. > > All the things I want to have different in Dillo I'm willing to change > myself. I'm not saying you should change this or that so or so, I ask if > you mind if I change or add some things a certain way, and if you agree > that it's better that way. > > Greetings, > > Indan Sorry to interrupt... I'm a keen user of Dillo but no hacker. I'll not comment on all the internals of Dillo since you guys are much more clever on this than me. But, see - the reason why I like Dillo is that it is light and mean - and can be tweaked into something I need. My need is a *light* browser which can be fitted into a thin client but still allow you to read web mail. This requires frame and https support. Other users of Dillo, like PDA users, couldn't care less about frames and https. The key point here is that neither I nor the PDA guys really have anywhere else to go than Dillo. I need to patch up Dillo with both Franks tab/frame patch and Indans https patch. Currently Franks patch is at ver. 14. The latest patch working on the most recent official Dillo release (0.7.3) is - as far as I remember - version 6. Today, when Franks new patch came out, I patched the Dillo cvs version with it. No problem. When I tried to add Indans https patch, it didn't work. Too old. Two weeks ago I tried the same. At that time the problem was the opposite! Honestly, this isn't a good situation. After following the mailing list for a couple of months I understand that the core developers have strong oppinions on the structure of the internals of Dillo. The is probably good since this created Dillo as it is in the first place. But in my humble oppinion either Dillo should release official minor version (0.7.4, 0.7.5 etc) more often so privateers can offer patches against these, or go along with this suggestion of Indans and support a semi-official patch model. The current model will not bring Dillo forward with the necessary speed, I fear. A lot of good ideas need to be tested and eventually absorbed if proven good. > (I wonder how many people wil read this 13K monster :) I did! And this post even looks short now ;-) Mike -- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS

Nov. 10, 2003

Re: [Dillo-dev] [ATTENTION][PATCH] New version of tab/frame patch (13) has error, new version later today

by David McKee

Ahhhhh... User Friendly works again. Thanks. -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Nov. 10, 2003

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

Hello, > I made a prototype ftp plugin that is based on > http://nbpfaus.net/~pfau/ftplib/ > Did I post this to the list or only to Jorge ?!? I'm a from scratch die-hard ;), I would write all the code myself, I already looked at the FTP RFC and it's not too hard I think, especially if you only implement what you need (only passive transfers for instance). You posted it to the list, I remember reading it somewhere. That lib seems interesting though, even if only as reference. > AFAIR, the problem is that dillo tries to keep cookies in memory > and writes them to disk only when absolutely necesarry. It's > a privacy issue. No, that's not a problem, cookies that stay all the time in memory don't have to be synchronized, the problem is caused by that few cookies that need to be written to the cookies file, or so I think. Reading and writing to the cookie file everytime another Dillo instance changes it isn't very fast, but it shouldn't happen often, people shouldn't enable cookies for all sites. I use ENABLE_SESSION, but those cookies shouldn't be written to disk. Using file locks is simple to implement, even more so because Dillo already use them. It's possible to have a more complex system that manages that all Dillo instances use the same cookies, even in memory, with shared memory and semaphores, but those few cookies that are explicitly enabled aren't worth all that hassle. Greetings, Indan

Nov. 10, 2003

[PATCH] Version 14 of tab/frames/kbnav patch is ready

by Frank de Lange

Hi'all, The next version (14) of my tab/frame/keyboard navigation patch is ready (see bottom of this message for download instructions). /* ATTENTION */ Version 13 of the patch was missing a line, which made it segfault when clicking on some images. That is fixed in this release. This is the ONLY difference between version 13 and version 14. I sent a small patch to the mailing list which fixes this problem in version 13, if you already downloaded version 13 you can apply that patch instead of downloading version 14. The filenames for version 13 and version 14 are the same, if you are in doubt which version you have run md5sum on the file and compare the result with that in this message. /* and now we continue with our scheduled program */ Keyboard navigation has grown up, it is more or less complete now. There have been many internal changes, leading to a much more robust implementation. Links are now highlighted in a distinct way, with a dashed inverse frame around highlighted text. Link navigation should now be reliable in any direction (up, down, left, right). Scrolling movements are minimized, the code starts looking for links in the currently visible part of the document. The Tab/Shift-Tab keys now really work as advertised, they can also be used to move focus between frames. If something doesn't work they way it should (or the way you *think* it should), I want to know! For more info on keyboard navigation, see the doc/Keyboard_Navigation.txt document (after applying the patch, naturally...). More information on tabs can be found in doc/Browser_Tabs.txt, for frames see doc/Browser_Frames.txt. The mailing list archives are also a good place to look for answers to questions relating to this patch. Tabs, Frames and browser bloat ============================== version: 0.8.0-pre patch: dillo-20031110-tabs.patch.gz unpatched: 295956 bytes patched, no tabs, no frames: 312660 bytes patched, with tabs, no frames: 318964 bytes patched, no tabs, with frames: 329076 bytes patched, with tabs, with frames: 335604 bytes (gcc 3.2.2, binutils 2.13.90.0.18, CFLAGS "-Os") Download instructions ===================== The patch is made against 20031110@10:27 CVS. Do not forget to run ./autogen.sh after applying the patch. You can find the patch on the usual (ad-happy, use an ad-blocking proxy or sane browser) site: http://www.geocities.com/ikbenfrank/ More specifically: Dillo 0.8.0-pre (CVS) ===================== http://www.geocities.com/ikbenfrank/dillo-20031110-tabs.patch.gz size: 100110 bytes (gzipped, as downloaded) 449102 bytes (uncompressed) md5sum: 4e11fbbac0945882f8bdedbd0b0f31ac (gzipped, as downloaded) 95f3d0aa78939fd9105d921665a87072 (uncompressed) As always, check the site for the most recent version 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." ]

Nov. 10, 2003

[ATTENTION][PATCH] New version of tab/frame patch (13) has error, new version later today

by Frank de Lange

Hi'all, As some of you may have noticed, the last version of the tab/frame patch segfaults when clicking on some images. This is caused by a missing line in html.c:346: static gboolean Html_image_menu(GtkWidget *widget, GdkEventButton *event, DilloDoc *dd) should be: static gboolean Html_image_menu(GtkWidget *widget, gint32 x, gint32 y, GdkEventButton *event, DilloDoc *dd) You can either apply the patch which comes with this message, or wait for a new release (14) of the patch which solves this issue. No, I do not know why this line was missing... Thanks to Johannes Hofmann for notifying me of this problem! 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." ] --- dillo_tabs/src/html.c~ 2003-11-10 12:38:45.171994080 +0100 +++ dillo_tabs/src/html.c 2003-11-10 17:14:28.530021384 +0100 @@ -343,8 +343,9 @@ /* * Popup the image menu ("button_press_event" callback of image) */ -static gboolean Html_image_menu(GtkWidget *widget, GdkEventButton *event, - DilloDoc *dd) +static gboolean Html_image_menu(GtkWidget *widget, + gint32 x, gint32 y, GdkEventButton *event, + DilloDoc *dd) { DwImage *image = DW_IMAGE (widget); gboolean return_val;

Nov. 10, 2003

Re: [Dillo-dev] [PATCH] Version 13 of tab/frames/kbnav patch is ready

by Frank de Lange

Johannes Hofmann wrote: > Hi, > > thanks for your continued work on dillo! > > With the newest version (13) of your patch I encountered a segfault when > clicking on clickable images on FreeBSD-current: > > Program received signal SIGSEGV, Segmentation fault. > Html_image_menu (widget=0x811d500, event=0x10c, dd=0xee) at html.c:354 > 354 if (event->button == 3 && image->url) { > (gdb) p event > $1 = (GdkEventButton *) 0x10c > (gdb) p image > $2 = (DwImage *) 0x811d500 > (gdb) p image->url > $3 = (DilloUrl *) 0x8146a80 > (gdb) p event->button > Error accessing memory address 0x148: Bad address. I'll have a look at this asap... 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." ]

Nov. 10, 2003