- Dillo-dev - lists.mailman3.com

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

Re: [Dillo-dev] HTTPS Patch

by Andreas Schweitzer

Hi, > Sorry for the huge mail. :) And most of it is rather interesting but way more than I know about software design and C :-) > >> # Add ftp support. > > It has. > > Using wget for something as basic as ftp in a plugin isn't something that > I would call ftp support. Dillo is not a graphical front end for wget, > thus I do not think Dillo has ftp support. Wget has. 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 ?!? Unfortunately, lately I have a hard time dedicating some quiet time to dillo, so it's still sitting there. But since I could do it, then almost anybody can :-) > > (this is old problem of sharing a single resource among several > > clients). > > An old problem that is solved long ago. Just use inter process > communication, like file locks (you can unlock you know). Only what you > need to add is an extra fstat to see if the file is edited, and if so, > reload the cookies. No big deal if you ask me. 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. > (I wonder how many people wil read this 13K monster :) Ok, so I went back and read more ;-) But I leave it to the core developers to comment on it. I only found two points I could comment on. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Nov. 10, 2003

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

Hello, Sorry for the huge mail. :) >> # Moving the dns stuff to IO. >> # Move all the socket stuff into IO.c, the module that wants to handle >> opening the connection should also close it (all non-internet sockets, >> like files. Unix sockets may be added to IO.c.). > Gzilla had a flat design, we've come a long way to layer dillo > and to separate its code in modules. It's not what you think, what I meant was to move dns.c|h to the IO directory, not to move the code from those files into IO.c, I would never do that. What I want to do is to move the code into the modules where it belongs. I see no reason why the IO module shouldn't handle all the socket related stuff, currently http.c makes a new socket and connects it, then it passes it more or less to the IO module. It seems more logical and modular to me when the IO module does those TCP/IP specific things when http calls IO_new. Let the IO module do the IO, and the http module do the http related things, that's my opinion. I don't see the http module doing anything special with the dns info, so it probably makes more sense to let the IO module use the dns module too. You seperated the code in modules and layers, what I want to do now is to move code to the place it belongs, making Dillo in my opinion more modular, overall simpler and more flexible. Currently this has the effect that the IO modules becomes bigger and more complex, but it also means that the http module will be smaller and simpler, and that it's easier to add more http like modules in the future. What's bad about the current ccc functions? The problem is that currently not all modules can communicate blindly with other modules via ccc functions, because different ccc functions expect different parameters. Also most of the time modules know exactly with which module they talk, they have no choice, otherwise they don't know what parameters to give and expect. Now you use ccc functions like a sort of bad used void pointers: You know what you get, you know what you call, but still tunnel it through a typeless function. You mix a general API with module specific API's, making things only very confusing and unclear. All I want is a clear API. I see how ccc functions are usefull, and what their point is, but that is not my problem with them, the idea of a sort of linked list of functions is nice, but the implementation isn't very well if you ask me. Also the API used internally in Dillo isn't consistent. For example: Why call a_IO_new and not IO_ccc with OpStart? Things are unnecessary complicated and inflexible now. It's not easy to unravel the spaghetti, but it's doable, and when you're done you've a nice clean internal API that makes implementing library plugins a piece of cake. > It serves to isolate the query process from the answer process. > Also as dillo uses pipes to talk to itself, it makes sense to have read-only and write-only FDs. Of course it can be merged, but it may be not simple. With pipes it makes sense yes, but in general all other connections are bidirectional. Dillo uses mostly TCP, then it's one socket, one connection, one fd. And one IOData structure if you ask me. If you use one IOData structure that is also bidirectional, then all you need to do with pipes is to still use two IOData structures, but only for pipes. One IOData structure for each fd makes most sense to me. Connection caching. You say that Dillo has it, but when I open a website, and look with netstat, Dillo has no open connections. Same experience with debug output. Maybe Dillo has it with dpi connections, I don't know, didn't look at that code yet, but in general Dillo has no connection caching, at least not the kind I mean. The one I would want to have is that keeps connections open until the server closes them, or until they time out (I'm not sure if all connections should be cached, or only the one to the last domain/current site). > In the past that approach was used. ~/.dillo ended having a > splash file for each release. The point is that what's more memory consuming is the widget tree for rendering, not the source itself. I do not know (nor want to know ;) how you first implemented it, what I was thinking about is opening by default the about html file. To have something that does exactly the same as now, all you have to do is open by default e.g. /etc/dillo_splash.html. It takes about 5 lines, patch is written within 15 minutes, most work is getting rid of the old code. And instead of keeping that 10K splash info all the time in memory, you now don't use any memory at all for it, except the one to render it, but that's gone after going to another site (if we can tell the cache to not cache it anyway, but that's the same for the current implementation). Putting an about file integral into Dillo, that's what I consider being monolithic. There is nothing wrong with a distributed design, but my problem with you pushing everything into dpi plugins is that most of those things can be done in seperate modules, meaning that they can be library plugins as wel. It becomes scary when a simple "hello" dpi plugin is 150 lines of code, while the whole ssl support to IO.c is about the same (and much less when there is one IOData/fd). Now you get much more code that all does more or less the same, you may have kept the Dillo core clean and mean, but you get a ridiculous complicated and big plugin system, moving most of the code and functionality outside of Dillo (but in the same time making it twice as big). Now it's very tempting to make a dpi library that implements most used functions, as someone already discovered. What's the next step? Moving all the useful code from Dillo to that library so that even more code is shared I guess (and let Dillo use that library too). What you get is a weird attempt to make something that more or less resembles library plugins, but in, if you ask me, a very awkward way. Of course there are plugins that behave more like daemons, like the bookmark plugin, but then make it a real daemon, so that it can be used by even other browsers. With a flexible and clear internal API most plugins can be done with relative small and simple library plugins, and a few can be implemented as real daemons. >> # Add ftp support. > It has. Using wget for something as basic as ftp in a plugin isn't something that I would call ftp support. Dillo is not a graphical front end for wget, thus I do not think Dillo has ftp support. Wget has. > (this is old problem of sharing a single resource among several clients). An old problem that is solved long ago. Just use inter process communication, like file locks (you can unlock you know). Only what you need to add is an extra fstat to see if the file is edited, and if so, reload the cookies. No big deal if you ask me. > Yes I agree with that reusing dillo's http may come handy. What your mistake is, in my humble opinion, is that you treat https like a seperate protocol, instead of http over another kind of connection. My view is that http is just http over ssl, and that ssl should be a sort of sub-module of IO (or a module that's only used by IO, like dns would be in my way). If you take a look at my patch, you'll see that the changes in http.c and IO.c are minimal, most of the code is at the bottom of IO.c, it could be easily a seperate file (again, only if there is one IOdata per fd, but then the ssl code will be 50 lines or so). Currently proxy support has more impact on http than https support, and you should treat them in a similar way if you ask me. You don't want a seperate plugin or module for proxy http, why do you want one for https? If you mean with monolithic that it's part of the core code, then yes, my way is monolithic, but it's only very little code, modular, and much less monolithic than an embedded splash page. > the details of handling the possible errors should be solved by the client application depending on the protocol and what it is being used for. > So having a generic SSL/TLS gateway may look interesting but it > can get tricky to implement. Not at all. The openssl api supports error callback functions, so the SSL/TLS support in IO can be minimal, if modules need more control they can use the callback functions. All that is needed is a general behaviour that is sufficient in 90% of the cases, and the current implementation does exactly that. Because modules have access to the SSL structure they can have all control they want, if needed. There are more or less 3 types of errors: 1: Connection related errors. (handshake_failure etc) Not much choice how to handle this, retry or abort (all connection related errors, including ssl related things like unsupported something). 2: Bad use of the API. (illegal_parameter) Should never happen with a good implementation. 3: Certificate related errors. (6 out of the 8 errors you listed) Most certificate related things can be done with openssl callback functions, so it's very seperate of the rest, making it easy to add or change later, or to handle it as module. Maybe there's something needed to give the module a chance to do it's certificate (startup) things and setting up the error handling, but not much. All in all IO doesn't have to worry much about all those SSL errors. > It puzzles me: changing the IO engine, Only what will chance is that it does more what it should do, handling IO. > integrating parts of the code that were separated on purpose, That was a misunderstanding, I wouldn't do that, sorry for not being clear enough. > changing the internal API, getting rid of the CCC The current CCC API is not clear or flexible, nor simple. Maybe a more consistent CCC API is possible, maybe no CCC functions at all, I don't know yet, but I'm not simply getting rid of the CCC. > and porting to FLTK, we'd be talking about another browser. Well, porting to FLTK, FLTK has similar aims as Dillo (small and fast), so maybe it was best if it was implemented with FLTK in the first place, but it's too late for that now. I would think twice before porting Dillo to FLTK (making sure that FLTK is alive and actively developed is one thing I would do), but GTK 2 is currently just scary, so FLTK as long term option isn't that bad. Getting libraries smaller is always hard, and GTK 2 is 12 mb now? I also saw the benchmarks, all in all not very encouraging. There is also an existing UTF8 Dillo patch, so maybe it's an option to stick with GTK 1 for a while. I didn't make Dillo, nor do I have much GUI programming experience, so I'm the last one you should listen to when it comes to what widget set to use. But from the networking side, FLTK has a perfect API, only a thin layer on top of select/poll, making it possible to easily add, remove and change the poll events on fds. GTK has an undocumented way of removing fds, can only hope it cleans the io channels up too and so on, but it still has no way to change the events on a fd. GTK has a lot bloat in it's io channel implementation (it's bloat when you don't need all it's features). I looked a bit in GTK's online API, and found the "perfect" replacement for io channels, a bunch of GDK functions that do almost exactly what Dillo needs: http://developer.gnome.org/doc/API/gdk/gdk-input.html It gives us almost the same API as FLTK does, but instead of being a thin layer, it's implemented with io channels, so the bloat is still there, but no way around that with GTK (not without very ugly complicated stuff). Also I think that the hairy bug isn't there, nor will we get another by GTK caused hairy bug if Dillo uses this GDK API, because it does what we want and need, without adding extra complexity like io channels (sure, the bug wasn't GTK's fault you can say, but if the API was clear and simpler, it wouldn't happen). Also FLTK uses internally the same select/poll as for our fds, X communicates through unix sockets, so whole FLTK blocks when nothing happens, while it seems that GTK polls 50 times/second for events or something like that. It's just that I prefer FLTK's way of doing some things. :) > 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 (I wonder how many people wil read this 13K monster :)

Nov. 10, 2003

[PATCH] nit in dpid/Makefile.am

by Frank de Lange

The makefile for dpid does not honour $DESTDIR, which can make package builds fail. Fix attached This fix is also in the latest versions of the tab/frame and kbnav patch. If this fix is applied to CVS, it will cause those patches to fail. This is NOT a problem, just ignore the reject message on dpid/Makefile.am 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/dpid/Makefile.am 2003-11-03 14:12:39.000000000 +0100 +++ dillo_kbnav/dpid/Makefile.am 2003-11-10 10:44:28.163417832 +0100 @@ -21,4 +21,4 @@ install-data-local : $(mkinstalldirs) $(DESTDIR)$(sysconfdir) - echo dpi_dir=$(libdir)/dillo/dpi > $(sysconfdir)/dpidrc + echo dpi_dir=$(libdir)/dillo/dpi > $(DESTDIR)$(sysconfdir)/dpidrc

Nov. 10, 2003

[PATCH] Version 3 of keyboard navigation patch

by Frank de Lange

Hi'all, The next version (3) of my keyboard navigation patch is ready. See the end of this message for download instructions. Do note that the tab/frame patch already contains this functionality, so there is no need (and no way) to apply this patch on top of that or the other way around. 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 (in the tab/frames patch they can also be used to move focus between frames). For more info on what this patch does, see the doc/Keyboard_Navigation.txt document (after applying the patch, naturally...) Download instructions ===================== There is currently only one version of the patch, made against 20031110@09:27GMT CVS. As always, have a look at the patch website (http://www.geocities.com/ikbenfrank/) for the latest version of the patch. This patch does NOT apply on top of the tab/frame patch, and the tab/frame patch does not apply on top of this one! The tab/frame patch already contains this functionality, so it is not needed. http://www.geocities.com/ikbenfrank/dillo-200311101257-kbnav.patch.gz size: 28437 bytes (gzipped, as downloaded) 138796 bytes (uncompressed) md5sum: 08ca999609cd9124be49cabc0650dccf (gzipped, as downloaded) 8a8b7e5dc55842661fefa76153356ca4 (uncompressed) 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

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

by Frank de Lange

Hi'all, The next version (13) of my tab/frame/keyboard navigation patch is ready (see bottom of this message for download instructions). 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") Be aware of the fact that the patch now also includes keyboard navigation (which can not be compiled out, hence th size increase for the 'patched, no tabs, no frames' version). 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: 100106 bytes (gzipped, as downloaded) 449100 bytes (uncompressed) md5sum: 5b1122e1ffa55137e7862547bec8a6fc (gzipped, as downloaded) 4962df326289c4603266002dd111b6c9 (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

Re: mailing lists dead?

by Thorben Thuermer

On Mon, 10 Nov 2003 14:29:43 +0100 Frank de Lange <frank(a)unternet.org> wrote: > Hey PM, > > Just tried to submit a few messages to the > dillo-dev(a)lists.auriga.wearlab.de list, and got them back: > > Your message has encountered delivery problems > to the following recipient(s): > > dillo-dev(a)lists.auriga.wearlab.de > Delivery failed > 550 Unknown local part dillo-dev in <dillo-dev(a)lists.auriga.wearlab.de> a problem with the mailserver configuration... sorry, fixed > > Cheers//Frank Greetings, Thorben

Nov. 10, 2003

Re: [Dillo-dev] HTTPS Patch

by Jorge Arellano Cid

Hi, On Thu, 30 Oct 2003, Indan Zupancic wrote: > Updated the diff, gcc 2.x should work now, link is still > http://www.xs4all.nl/~dorinek/dillo/dillo-ssl.diff.gz Here go my comments. (An important part of the answer is in this email: http://article.gmane.org/gmane.comp.web.dillo.devel/1407 ) > It would be nice to get some feedback from the Dillo developers, I'd like > to know what they think should change before the code is good enough to go > into the official Dillo, and if they even consider that of course. Of course it is considered! (see above URL) > I have plenty of ideas, but most of them aren't feasible without merging > the two IOData structures (now there is one for the read part, and one for > the write part, why, I don't know, doesn't make things simpler), It serves to isolate the query process from the answer process. Also as dillo uses pipes to talk to itself, it makes sense to have read-only and write-only FDs. Of course it can be merged, but it may be not simple. > doing > that makes it much easier to do certain, more complex things that need to > have all the fd related info in one place, like ssl, connection caching > (currently Dillo opens and closes a connection for each action, although > it seems to work well, it's still more efficient to keep connections open > longer, especially with slow/bad network connections), "keep alive" (to > avoid timeout problems in ssl, quite annoying when you're taking too much > time typing an email), simple ftp support, etc. Currently dillo does that. Every time you add a bookmark, dillo and the server chat a little while before adding it (with connection caching). > I know that the Dillo developers want to implement most "extra" features > like https/ftp/bookmarks/etc as plugins, but I think it's beter to > implement the features that are used a lot, or just very important, like > https and ftp, natively in Dillo with a small implementation. The overall > code is most times smaller too, can say that Dillo is just 300 K, but it > would be a bit weird if the plugins together are bigger than Dillo after a > while. https took around 2 Kb, I think I can implement basic FTP (and > possibly ftps) in about 15 K, using no external ftp library or program > (hopefully 10, worst case 20K). That is a design decision: Monolithic vs Distributed. Is hard to have a definitive choice. Dillo follows the distributed approach. > If you let me loose on Dillo's code then this is what I would do: > > # Cleanup the IO engine, one IOData per fd. Could be. > # Moving the dns stuff to IO. > > # Move all the socket stuff into IO.c, the module that wants to handle > opening the connection should also close it (all non-internet sockets, > like files. Unix sockets may be added to IO.c.). Gzilla had a flat design, we've come a long way to layer dillo and to separate its code in modules. > # Add ftp support. It has. > # Add file upload support in html forms. Agreed. > # Add connection caching to IO. It has. > # Auto keep alive like behaviour for ssl connections. > > # Maybe always ACCEPT_SESSION for cookies when they come via a https > connection. Could be. > # Get rid of the ccc construction, or change it so that it behaves more > logical. My opinion is that you should have either a clear unique API for > each module, or one general API that is the same for each module. > Something in between like the current ccc functions is only confusing (if > you want a chain like behaviour, then use function pointer stuctures or > something). The CCC is all about parallelism and error handling. It is the supporting core of the application. Not easy to substitute. > # When changing the internal API anyway, making shared library plugins > possible too, at least for the IO part (maybe ftp library plugin as proof > of concept). Changing the internal API... > # Get rid of the splash stuff, move it to an external html file that is > opened by default when nothing else is opened. Currently the splash screen > is even opened when you do "dillo http://site.org". Loading a file is > almost as fast as the build in splash screen. Removing it makes Dillo > smaller (about 10 K), simpler and lets people make their own startup pages > (for instance a to hd saved google.com) In the past that approach was used. ~/.dillo ended having a splash file for each release. The point is that what's more memory consuming is the widget tree for rendering, not the source itself. Having a dillorc option to replace the Splash with a local file may be handy though. > As you could notice, I'm mainly interested in the internet/IO part, > graphical stuff doesn't attract me much. If it did, I would help/start > porting Dillo to FLTK. If Dillo decides to go with GTK 2 then I will > probably stop using it :(. It puzzles me: changing the IO engine, integrating parts of the code that were separated on purpose, changing the internal API, getting rid of the CCC and porting to FLTK, we'd be talking about another browser. > I don't have enough faith in GTK2, it's already > too big (and I saw the test results). If you have GTK 2 running anyway it > doesn't matter much if you run Dillo too of course, but that's the case > too with all those KDE/Gnome programs. IMHO, you should look at all the > code that a program uses, including the one in dependencies. I prefer a > program that has it's own small and efficient implementation of something > to one that is smaller but uses huge libraries. Agreed. The GTK2 issue is under study now. > I'm also thinking about making a Dillo installer (sh script) that > downloads and installs the cvs version of Dillo and applies the patches > the user wants. This needs some coordination, I saw links to other Dillo > patches, but I don't know if they are up to date, nor if the maker is > willing to keep that so. Currently the only patches I know that are up to > date are Frank's patches and my own https patch. 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. Cheers Jorge.-

Nov. 7, 2003

Re: [Dillo-dev] Simulating a slow connection

by johannes leimbach

Hi! You might try the following programs for a more genuine slow surfing experience: http://www.netlimiter.com - For Windoze http://www.monkey.org/~marius/trickle/ - For *ix, *bsd Hope that helps :)

Nov. 4, 2003

Re: [Dillo-dev] [PATCH] memory leak in dw_ext_iterator

by Frank de Lange

Jorge Arellano Cid wrote: > Is this next kbnav patch CVS-ready, or a testing version? > > I'm testing it now, fixing small things, should be CVS-ready. 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. 4, 2003

Re: [Dillo-dev] Simulating a slow connection

by Sebastian Geerken

On Mon, Nov 03, Sebastian Geerken wrote: > At <http://www.dillo.org/download/dillo-slow-0.0.1.tar.gz>, you'll > find a dpi, which simulates a slow connection, and is useful for > testing incremental rendering. Read the README file within the tarball > for more informations. > > (I'm not yet very familiar with dpip, I just modified the "hello > world" example for my needs, and especially, currently only one > instance of this dpi can run at a time.) If you want to pass additional parameters, you have to start dillo, go to a dpi generated page (e.g. bookmarks), and then enter the dpi:/slow URL into the location bar. See Capi_verify_dpi_url_request, why: /* test POST and GET */ if (strchr(URL_STR(web->url), '?') || URL_DATA_(web->url)) { /* safety measure: only allow dpi requests from dpi-generated urls */ if (a_Nav_stack_size(web->bw)) { referer = a_History_get_url(NAV_TOP(web->bw)); if (g_strncasecmp(URL_STR(referer), "dpi:/", 5) == 0) allow = TRUE; } } else { allow = TRUE; } Although the slow page is not requsted by the bookmarks page ... Sebastian

Nov. 3, 2003

Simulating a slow connection

by Sebastian Geerken

Hi! Sorry for being silent the last week. At <http://www.dillo.org/download/dillo-slow-0.0.1.tar.gz>, you'll find a dpi, which simulates a slow connection, and is useful for testing incremental rendering. Read the README file within the tarball for more informations. (I'm not yet very familiar with dpip, I just modified the "hello world" example for my needs, and especially, currently only one instance of this dpi can run at a time.) Sebastian

Nov. 3, 2003

Re: https dpi

by Jorge Arellano Cid

On Sat, 25 Oct 2003, Madis Janson wrote: > I read the https.c included in dillo/dpi and seams, that it just > gets url and and dumps html. Yes, it's basically a dpi filter plugin. > What about content-type, cookies and POST > requests? Since https is http over ssl, it seems natural to use dillo's > http protocol implementation for these things (like i did with my https > proxy for dillo), but is it possible with dpi? > > Also, there seems to be one process for one connection, which makes hard > to implement SSL session cache. Unfortunatelly I don't have definitive answers for these questions. There's more than one way to do it and the choice somewhat depends on what the underlying purpose of the bigger picture is. For instance: distributed design vs monolithic, quick implementation vs a more flexible one, low library dependencies vs linking dillo to a bigger set. Personally, I think that patching dillo with an integrated quick implementation of https (like Indan's) while we develop a more flexible dpi that provides at least the same, can be a good approach. I'll try to briefly comment your concerns: > Also, there seems to be one process for one connection, which makes hard > to implement SSL session cache. Yes, that happens with dpi filters. The idea in this case is to have an http dpi that's able to handle several connections at the same time (like the downloads dpi). That is: a dpi server instead of a dpi filter. With that scheme session cache is easy to implement. (and BTW much easier for the developer because he can arrange things much more freely than when patching inside dillo). > content-type (as above). The https dpi would need to listen the HTTP stream and so has access to the content-type sent by the remote https server. > Cookies Cookies will end being a dpi! Currently dillo enables cookies for the first instance only (this is old problem of sharing a single resource among several clients). Fortunately dpi solves this, as with the current bookmarks dpi server that can be shared by multiple running instances of dillo. When this port is done, the one-instance-only restriction for cookies will be gone. > POST POST data can be passed to the https dpi using dpip. This information is inside the DilloUrl. > Since https is http over ssl, it seems natural to use dillo's > http protocol implementation for these things (like i did with my https > proxy for dillo), but is it possible with dpi? Yes I agree with that reusing dillo's http may come handy. Now, dillo does http 1.0 only so having it done inside a dpi can also bring http 1.1 (as with wget and current https.c). The other interesting point is that the SSL/TLS library spec states that appart from making a socket secure, the details of handling the possible errors should be solved by the client application depending on the protocol and what it is being used for. So having a generic SSL/TLS gateway may look interesting but it can get tricky to implement. For intance: handshake_failure(40), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), are to be handled in different ways regarding what the protected protocol using SSL/TLS is, the transport circumstances and the user's choice. (ah, and all the alerts can have a "level" of fatal or not). With a gateway, having only the option of closing the connection is not enough. Question dialogs can be implemented in the gateway process itself though (a GUI inside the dpi), and you also have to take care of differentiating the protocols. With dpi, the questions and actions can be communicated to dillo with dpip or be made part of the dpi server. It provides more flexibility. Making SSL a part of IO, comes with the burden of having to develop all of this error handling knowledge inside the IO layer (making dillo grow in size and complexity). Including questions, actions a protocol differentiation. HTH Jorge.-

Nov. 3, 2003

Re: [Dillo-dev] libpng detection again...

by Andreas Schweitzer

Hi, > <current line> > CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --I_opts`" > </current line> <snip> > <candidate line> > CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --cppflags`" > </candidate line> Total approval from my side ! Yes, the two options give slightly different results, but the differences don't matter. The problem is, the png developers first introduced the --cppflags options in release 1.2.4 and in 1.2.5 they furthermore introduced --I_opts (and more fine grained flags). And dillo, of course :-), expects the latest release of libpng. So all distributions stuck at release 1.2.4 have this problem we are seeing (e.g. Suse 8.1). But moving to the more comaptible --cppflags version will fix this particular problem. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Nov. 3, 2003

libpng detection again...

by Jorge Arellano Cid

Hi, We've been through this several times, and today I received one more suggestion that may work: The whole point is replacing the current line in configure.in with something better ;). <current line> CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --I_opts`" </current line> Kelson and Raphael had to patch for SUSE 8.1: http://article.gmane.org/gmane.comp.web.dillo.devel/1011/match=libpng http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-April/000532.html Basically: <patched line> CPPFLAGS="$CPPFLAGS -I/usr/local/include/libpng12" </patched line> and here's the new candidate: <candidate line> CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --cppflags`" </candidate line> At least it looks clean! The funny thing is that on my box, the "candidate" and "current" give different results, but it works with either one! :-) Worth a try? Surely. Please give a test to the candidate and tell us how it works for you. Cheers Jorge.-

Nov. 3, 2003

Re: [Dillo-dev] [PATCH] memory leak in dw_ext_iterator

by Jorge Arellano Cid

On Mon, 3 Nov 2003, Frank de Lange wrote: > Hi'all, > > There's a memory leak in dw_ext_iterator, which causes every call to > dw_ext_iterator_new() to leak one DwIterator. The solution is simple, as > can be seen in the attached patch. > > Jorge, can you apply this? Done! > It saves quite a bit of memory, and will do > so even more once my next kbnav patch is out (now testing). Is this next kbnav patch CVS-ready, or a testing version? > The patch > currently contains this fix for dw_ext_iterator (plus a whole lot of > other changes to it). With regard to the other changes (to dw_ext_iterator), you can consult them with Sebastian (he developed the iterators). Thxs! Jorge.-

Nov. 3, 2003

IPv6

by Jorge Arellano Cid

Hi there! Please someone give a test to the CVS's IPv6 code. It has some new memory handling calls and it'd be good to be sure it works as expected. Just navigating will do, but the key point of the test is when dillo has to retry with different IPs for a single connection (that is: when the GioChannel is reused). Cheers Jorge.-

Nov. 3, 2003

[PATCH] memory leak in dw_ext_iterator

by Frank de Lange

Hi'all, There's a memory leak in dw_ext_iterator, which causes every call to dw_ext_iterator_new() to leak one DwIterator. The solution is simple, as can be seen in the attached patch. Jorge, can you apply this? It saves quite a bit of memory, and will do so even more once my next kbnav patch is out (now testing). The patch currently contains this fix for dw_ext_iterator (plus a whole lot of other changes to it). As this would make the patch fail to apply cleanly, I'd like to see this fixed in CVS. 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." ] diff -pruN dillo/src/dw_ext_iterator.c dillo_patched/src/dw_ext_iterator.c --- dillo/src/dw_ext_iterator.c 2003-07-12 19:35:50.000000000 +0200 +++ dillo_patched/src/dw_ext_iterator.c 2003-11-03 13:58:35.020401864 +0100 @@ -366,7 +366,7 @@ gint a_Dw_ext_iterator_compare (DwExtIte void a_Dw_ext_iterator_free (DwExtIterator *eit) { int i; - for (i = 0; i < eit->stack_top; i++) + for (i = 0; i <= eit->stack_top; i++) a_Dw_iterator_free (eit->stack[i]); g_free (eit->stack); g_free (eit);

Nov. 3, 2003

Re: referer

by Jan.Stary＠ff.cuni.cz

:Dillo does NOT send referer header, if you mean this. Well ... why not? jan

Nov. 3, 2003

Re: [Dillo-dev] (no subject)

by Madis Janson

On Mon, 3 Nov 2003 Jan.Stary(a)ff.cuni.cz wrote: > Hello, > > using the usual "http://validator.w3.org/check/referer" doesn't > seem to work in dillo. On the validator page, you get a "302 > Moved", which dillo _does_ follow, but the resulting > "http://validator.w3.org/check/referer?uri=" is of no use. > > I tried viewing http://www.stare.cz/referer.html and clicking 'validate' > in lynx, mozilla and dillo. In dillo it does not work. > > Is dillo really _sending_ the referer? > Dillo does NOT send referer header, if you mean this.

Nov. 3, 2003

(no subject)

by Jan.Stary＠ff.cuni.cz

Hello, using the usual "http://validator.w3.org/check/referer" doesn't seem to work in dillo. On the validator page, you get a "302 Moved", which dillo _does_ follow, but the resulting "http://validator.w3.org/check/referer?uri=" is of no use. I tried viewing http://www.stare.cz/referer.html and clicking 'validate' in lynx, mozilla and dillo. In dillo it does not work. Is dillo really _sending_ the referer? Thanks Jan

Nov. 3, 2003

8.3pre on the playstation2 - [was version tests on automake and autoconf]

by robert w hall

Very pleased to find that 8.3pre compiles 'out of the box' on the playstation2 :-). It should be an ideal browser, at last, for this machine (at present some people are even resorting to Mozilla!) It's currently being 'stress-tested' by the ps2's (16-yr old) owner... Like others who dip in and out of the dillo-dev list, I often find it difficult to know what the state of the 'unofficial' patches is (eg the 'auth' patch and of course the 'frames' patch) - this is especially difficult when posting to the playstation2-linux lists ('I've found some really-useful patches, but I can't tell you where...) Any chance of an unofficial page on the main site listing these??? (or is it there already, but I don't know where... :-)) Bob

Nov. 2, 2003

hairy bug in IO fixed!

by Jorge Arellano Cid

Hi there! The last five or six days were spent on trying to find (& fix) a bug that caused the CPU to hog under very hard to reproduce conditions. I know that heavy duty dillo users had noticed that in rare ocassions dillo starts taking all the CPU, and that's almost impossible to reproduce it again with another dillo... Well, the first interesting thing is that the CPU hog is "soft" (i.e. doesn't block dillo) because it is caused by a polling loop. The other surprising fact is that the CPU-hog occurs outside of dillo (!). That is, not in any part of its code. So if you were to attach GDB to find the bug (once on hog), you'd be always pointed outside dillo's source, but with a clue: polling. I was working with the ftp dpi when I finally came accross a way to reproduce the bug, so I took the chance and started digging. A whole revision/tweaking of the IO engine close/abort handling, a revision of glib's sources (gio channels) to finally find a way to stop the polling loop. Short story, there were several involved parts: threads, the IO, external processes, several open connections in parallel, glib (and the kernel). It turned out to be a race condition in the window between the actual close of the file descriptor, the glib source event removal for the watch, and the kernel reuse of FD number. The source code for gio channels (inside glib) hinted a way to remove the event source cleanly, but outside the gio channel's explicit API. The details are in IO.[ch] in CVS! Cheers Jorge.- PS: Indan wrote: > 3) There is no efficient way of (un)registering file descriptor events in > GTK. (FLTK has a perfect interface). Yes there is! (subtle but effective) > Did anyone found the bug yet, without reading the diff? If not, then it's > as harmless as I thought ;-). Still not nice of course, but it's unclear > where it goes wrong exactly, doesn't seem to be easily fixed without > changing Dillo a lot. I hope this patch and explanations helps you with point number 3. More comments later... Cheers 2 Jorge.-

Oct. 31, 2003

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

Updated the diff, gcc 2.x should work now, link is still http://www.xs4all.nl/~dorinek/dillo/dillo-ssl.diff.gz Did anyone found the bug yet, without reading the diff? If not, then it's as harmless as I thought ;-). Still not nice of course, but it's unclear where it goes wrong exactly, doesn't seem to be easily fixed without changing Dillo a lot. It would be nice to get some feedback from the Dillo developers, I'd like to know what they think should change before the code is good enough to go into the official Dillo, and if they even consider that of course. I have plenty of ideas, but most of them aren't feasible without merging the two IOData structures (now there is one for the read part, and one for the write part, why, I don't know, doesn't make things simpler), doing that makes it much easier to do certain, more complex things that need to have all the fd related info in one place, like ssl, connection caching (currently Dillo opens and closes a connection for each action, although it seems to work well, it's still more efficient to keep connections open longer, especially with slow/bad network connections), "keep alive" (to avoid timeout problems in ssl, quite annoying when you're taking too much time typing an email), simple ftp support, etc. I know that the Dillo developers want to implement most "extra" features like https/ftp/bookmarks/etc as plugins, but I think it's beter to implement the features that are used a lot, or just very important, like https and ftp, natively in Dillo with a small implementation. The overall code is most times smaller too, can say that Dillo is just 300 K, but it would be a bit weird if the plugins together are bigger than Dillo after a while. https took around 2 Kb, I think I can implement basic FTP (and possibly ftps) in about 15 K, using no external ftp library or program (hopefully 10, worst case 20K). If you let me loose on Dillo's code then this is what I would do: # Cleanup the IO engine, one IOData per fd. # Moving the dns stuff to IO. # Add ftp support. # Add file upload support in html forms. # Add connection caching to IO. # Move all the socket stuff into IO.c, the module that wants to handle opening the connection should also close it (all non-internet sockets, like files. Unix sockets may be added to IO.c.). # Auto keep alive like behaviour for ssl connections. # Maybe always ACCEPT_SESSION for cookies when they come via a https connection. # Get rid of the ccc construction, or change it so that it behaves more logical. My opinion is that you should have either a clear unique API for each module, or one general API that is the same for each module. Something in between like the current ccc functions is only confusing (if you want a chain like behaviour, then use function pointer stuctures or something). # When changing the internal API anyway, making shared library plugins possible too, at least for the IO part (maybe ftp library plugin as proof of concept). # Get rid of the splash stuff, move it to an external html file that is opened by default when nothing else is opened. Currently the splash screen is even opened when you do "dillo http://site.org". Loading a file is almost as fast as the build in splash screen. Removing it makes Dillo smaller (about 10 K), simpler and lets people make their own startup pages (for instance a to hd saved google.com) As you could notice, I'm mainly interested in the internet/IO part, graphical stuff doesn't attract me much. If it did, I would help/start porting Dillo to FLTK. If Dillo decides to go with GTK 2 then I will probably stop using it :(. I don't have enough faith in GTK2, it's already too big (and I saw the test results). If you have GTK 2 running anyway it doesn't matter much if you run Dillo too of course, but that's the case too with all those KDE/Gnome programs. IMHO, you should look at all the code that a program uses, including the one in dependencies. I prefer a program that has it's own small and efficient implementation of something to one that is smaller but uses huge libraries. I'm also thinking about making a Dillo installer (sh script) that downloads and installs the cvs version of Dillo and applies the patches the user wants. This needs some coordination, I saw links to other Dillo patches, but I don't know if they are up to date, nor if the maker is willing to keep that so. Currently the only patches I know that are up to date are Frank's patches and my own https patch. Greetings, Indan ------------------------------------------------- This mail is written in SquirrelMail with Dillo -------------------------------------------------

Oct. 30, 2003

Fonts

by Carlos Daniel Ruvalcaba Valenzuela

Does <font size=5> exist in current CVS?, or any plans to support it and <basefont>? I think they are really useful, and should be in already. Cheers Carlos Daniel Ruvalcaba Valenzuela _________________________________________________________ Do You Yahoo!? La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

Oct. 28, 2003

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

> Declaring variables in mid-code (ie, anywhere in the block) is valid > only for compilers complying with the C99 standard (such as GCC3). The code is declared at the start of the block, and is also the last code declared, it's just also initialized, but if you look at the code all declarations are before the statements. Please send the emails only to the list, otherwise I receive two emails, thanks.

Oct. 27, 2003

Re: [Dillo-dev] HTTPS Patch

by David McKee

Indan, This is extremely cool. I am pleased and excited. It rates as high with me as frame support, and leaves me waiting only for printing to be content. On Mon, 27 Oct 2003, Indan Zupancic wrote: > > First, the build doesn't know where to find my openssl headers > > and libraries [snippage] > I don't know much about autoconfigure/make/build, so it's no wonder. In > the final version it should be autodetected. Fair enough. Neither do I. > Seems like you have an old openssl version, on my computer all headers > are in openssl/, you probably need to change the includes at the top > of IO.c. If they are just in a non-default directory then run > "CFLAGS=-I/path/to/ssl ./configure". Also don't forget to run autogen > after applying the patch. New openssl in a weird place because I compiled from source. I fixed this by installing some carefully chosen links in the file system, so it should work for other builds as well... But thanks for the advice: I hadn't realized that ./configure could take paths from environment variables. > I'll change that St thing, but I'm pretty sure it's allowed to do it that > way, my compiler (gcc 3.2.2) didn't give any warnings either. Will change > it anyway, if old gcc has problems with it (not home now, so will change > it later). It is (as has already been noted) a c99 thing, not allowed in the old ANSI standard. Thanks for your work. It looks great. -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Oct. 27, 2003

Re: [Dillo-dev] HTTPS Patch

by Livio Baldini Soares

Indan Zupancic writes: [...] > I'll change that St thing, but I'm pretty sure it's allowed to do it that > way, my compiler (gcc 3.2.2) didn't give any warnings either. Will change > it anyway, if old gcc has problems with it (not home now, so will change > it later). Declaring variables in mid-code (ie, anywhere in the block) is valid only for compilers complying with the C99 standard (such as GCC3). IMHO this type of construct should still be avoided, as it breaks compatibility with other ANSI-C-only compilers (including GCC 2.95). best regards, -- Livio B. Soares

Oct. 27, 2003

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

> First, the build doesn't know where to find my openssl headers > and libraries, and there does not seem to be a ./configure option > for this. (BTW: My goodies are in /usr/local/ssl/...) I can fix > this locally, but a config option might be in order. I don't know much about autoconfigure/make/build, so it's no wonder. In the final version it should be autodetected. Seems like you have an old openssl version, on my computer all headers are in openssl/, you probably need to change the includes at the top of IO.c. If they are just in a non-default directory then run "CFLAGS=-I/path/to/ssl ./configure". Also don't forget to run autogen after applying the patch. I'll change that St thing, but I'm pretty sure it's allowed to do it that way, my compiler (gcc 3.2.2) didn't give any warnings either. Will change it anyway, if old gcc has problems with it (not home now, so will change it later). greetings, Indan

Oct. 27, 2003

Re: [Dillo-dev] HTTPS Patch

by Mike Eriksen

My Red Hat 7.3 didn't have problems finding the ssl-headers, but I couldn't compile before I made the two changes to St mentioned below. Yahoo! Now I have webmail with Dillo. Even with Yahoo! ;-) Mike On Mon, 27 Oct 2003, David McKee wrote: > Folks, > > When I apply and attempt to compile (on a Redhat 6.2 machine, gcc > 2.95), I have two problems. > > First, the build doesn't know where to find my openssl headers > and libraries, and there does not seem to be a ./configure option > for this. (BTW: My goodies are in /usr/local/ssl/...) I can fix > this locally, but a config option might be in order. > > > > Secondly, I get two compilation errors in IO.c. Both are related to the > code: > > errno = 0; > ssize_t St = SSL_read(io->ssl, io->Buf, io->BufSize); > > which I believe should (strictly) be > > ssize_t St; > errno = 0; > St = SSL_read(io->ssl, io->Buf, io->BufSize); > > because declaration should come before statements. In anycase, > making this change in both places (around lines 822 and 852) > fixes the problem for me. > > Now to try it out... > > Thanks, > > -- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS

Oct. 27, 2003

Re: [Dillo-dev] HTTPS Patch

by David McKee

Folks, When I apply and attempt to compile (on a Redhat 6.2 machine, gcc 2.95), I have two problems. First, the build doesn't know where to find my openssl headers and libraries, and there does not seem to be a ./configure option for this. (BTW: My goodies are in /usr/local/ssl/...) I can fix this locally, but a config option might be in order. Secondly, I get two compilation errors in IO.c. Both are related to the code: errno = 0; ssize_t St = SSL_read(io->ssl, io->Buf, io->BufSize); which I believe should (strictly) be ssize_t St; errno = 0; St = SSL_read(io->ssl, io->Buf, io->BufSize); because declaration should come before statements. In anycase, making this change in both places (around lines 822 and 852) fixes the problem for me. Now to try it out... Thanks, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Oct. 27, 2003

Re: [Dillo-dev] HTTPS patch

by Mike Eriksen

Sorry - apparently I can't read :-( I'll go for the cvs version. Thanks Mike On Mon, 27 Oct 2003, Indan Zupancic wrote: > > Which version does the patch require? I tried against 0.7.3 and got some > > errors - one in each of IO.c, Url.c and capi.c. > > Quote: "It was made against the current cvs" > > I guess that's pre 0.8. > > it shouldn't be much work to get it working with 0.7.3, if you want that > then just say, I'll make another patch then. The current cvs version seems > very stable, and Frank's patches are also cvs only, so it seems more than > logical to me that if you want experimental new features, you use the cvs > version. > > Two things I forgot to mention: > > If you want a lean and mean Dillo, then comment out or, remove "#define > DEBUG_MSG 5" at the top of IO.c, the extra overhead of the spam isn't > negligible on my 233 mhz computer (it also makes the https code much > bigger). > > The openssl licence is a "GPL-Incompatible, Free Software Licenses", so > it's needed to add an exception that says that DIllo may be linked to the > openssl library, see for more info: > http://www.gnu.org/philosophy/license-list.html#TOCGPLIncompatibleLicenses > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > -- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS

Oct. 27, 2003

Re: [Dillo-dev] fltk c binding

by Indan Zupancic

You still have to compile the program with a C++ compiler, also it won't be supported in the future, not sure if it is now. Xforms seem to make things only more complex without any real benefits. Take a look at FLTK's code, from what I saw it's just c with classes. If all you use is classes from c++, and no STL or other stuff, then you can compile a program that doesn't link to standard c++ libraries and isn't bloated by c++.

Oct. 27, 2003

Re: [Dillo-dev] HTTPS patch

by Indan Zupancic

> Which version does the patch require? I tried against 0.7.3 and got some > errors - one in each of IO.c, Url.c and capi.c. Quote: "It was made against the current cvs" I guess that's pre 0.8. it shouldn't be much work to get it working with 0.7.3, if you want that then just say, I'll make another patch then. The current cvs version seems very stable, and Frank's patches are also cvs only, so it seems more than logical to me that if you want experimental new features, you use the cvs version. Two things I forgot to mention: If you want a lean and mean Dillo, then comment out or, remove "#define DEBUG_MSG 5" at the top of IO.c, the extra overhead of the spam isn't negligible on my 233 mhz computer (it also makes the https code much bigger). The openssl licence is a "GPL-Incompatible, Free Software Licenses", so it's needed to add an exception that says that DIllo may be linked to the openssl library, see for more info: http://www.gnu.org/philosophy/license-list.html#TOCGPLIncompatibleLicenses

Oct. 27, 2003

Re: [Dillo-dev] HTTPS patch

by Mike Eriksen

Which version does the patch require? I tried against 0.7.3 and got some errors - one in each of IO.c, Url.c and capi.c. Mike On Mon, 27 Oct 2003, Indan Zupancic wrote: > Get it here: http://www.xs4all.nl/~dorinek/dillo/dillo-ssl.diff.gz > > It's not as nice and simple as I wanted it to be, thanks to three things: > > 1) SSL can always read and write, meaning that SSL_write may want to read. > 2) Dillo uses two IOData structures per file descriptor. > 3) There is no efficient way of (un)registering file descriptor events in > GTK. (FLTK has a perfect interface). > > This three facts contribute a lot to the complexity of the code. > > There is one known bug, you may try to find it. ;) > Dillo will not crash, I made it exit with a message. > > This patch adds also generic ssl/tls support to Dillo, most work was done > in IO.c, http.c has hardly changed. The current way to tell the IO engine > that it should use ssl is by giving a negative fd to a_IO_new. This avoids > extra interface, is simple, and doesn't clash with anything else. > > Dillo is about 2K bigger after the patch. It was made against the current > cvs, apply it with 'patch -p1 < dillo-ssl.diff' while you're in the dillo > dir. Run configure with --disable-ssl if you don't want https... > > Have fun. > > p.s. > I hate glib ;), it's totally worthless, the most complex piece Dillo uses > is a hash table, and glib implements it as a linked list, look in the code > yourself if you don't believe me. Since when is ansi c not good enough? > Please switch to FLTK. :) > > p.s.s > This mail was sent from webmail with a patched Dillo. :) > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > -- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS

Oct. 27, 2003

fltk c binding

by cesar

Fltk was modeled following XForms and has a XForms compatibility layer: http://fltk.org/documentation.php/doc-1.1/forms.html#forms http://fltk.org/documentation.php/doc-2.0/forms.html#forms You can learn more about XForms here: http://world.std.com/~xforms/ pd: I don't know how to program using Fltk or XForms. I only was aware of this compatibility layer. Both also have a GUI designer. I only know of very few apps using XForms, the most important of those being LyX. cesar;

Oct. 27, 2003

HTTPS patch

by Indan Zupancic

Get it here: http://www.xs4all.nl/~dorinek/dillo/dillo-ssl.diff.gz It's not as nice and simple as I wanted it to be, thanks to three things: 1) SSL can always read and write, meaning that SSL_write may want to read. 2) Dillo uses two IOData structures per file descriptor. 3) There is no efficient way of (un)registering file descriptor events in GTK. (FLTK has a perfect interface). This three facts contribute a lot to the complexity of the code. There is one known bug, you may try to find it. ;) Dillo will not crash, I made it exit with a message. This patch adds also generic ssl/tls support to Dillo, most work was done in IO.c, http.c has hardly changed. The current way to tell the IO engine that it should use ssl is by giving a negative fd to a_IO_new. This avoids extra interface, is simple, and doesn't clash with anything else. Dillo is about 2K bigger after the patch. It was made against the current cvs, apply it with 'patch -p1 < dillo-ssl.diff' while you're in the dillo dir. Run configure with --disable-ssl if you don't want https... Have fun. p.s. I hate glib ;), it's totally worthless, the most complex piece Dillo uses is a hash table, and glib implements it as a linked list, look in the code yourself if you don't believe me. Since when is ansi c not good enough? Please switch to FLTK. :) p.s.s This mail was sent from webmail with a patched Dillo. :)

Oct. 27, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Frank de Lange

Melvin Hadasht wrote: >> A >> . >> . . B . C >> . . . >> D . E . F >> . . . >> G . H . I >> >>When moving focus DOWN from A, it will land in B (because that is the >>next LOWER link closest to A). >> >> > >I agree with this. It is also the common behaviour in text editors and >text processors. > > > >>Moving it down again lands it in C (NOT >>E), as that is the next LOWER link closest to the original x-coordinate. >> >> > > > Of course I meant D, not C... >I would expect that moving down will bring me to one of the links in the >D.E.F line, the link which x position is the closest to A's. As this is >a geometrical/(geographical) navigation, I'd expect a behaviour similar to >cursor motion in text editors. > > 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." ]

Oct. 26, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Jorge Arellano Cid

On Sat, 25 Oct 2003, Frank de Lange wrote: > Jorge Arellano Cid wrote: > > > For instance: placing the nav cursor in the [gtk_type_new] link > >inside the "struct GtkTypeObject" section and pressing DOWN, > >brings the cursor to the leftmost [GtkType] under gtk_type_unique > >but it is possible to get to the leftmost [GtkType] too! That is > >focusing the leftmost one, then going UP then DOWN again. > > > You mean left- and right-most link? As in... > > A > . > . > B . . C > > Going from A sometimes lands you in B, sometimes in C, depending where > you came from? Yes! > If so, that is by design. The code only modifies the 'x' cursor > coordinate when the link is explicitly moved to the left or right, NOT > when it is moved up or down. The reason for this is best explained in > yet another ASCII-graphic: > > A > . > . . B . C > . . . > D . E . F > . . . > G . H . I > > When moving focus DOWN from A, it will land in B (because that is the > next LOWER link closest to A). Moving it down again lands it in C (NOT > E), as that is the next LOWER link closest to the original x-coordinate. > If you now were to move focus to link E (by moving it to the right), it > would update the 'x' cursor coordinate, so the next move DOWN after that > would end up on H. > > The cursor is ALWAYS set to the current link's 'y' coordinate. In case > focus is moved out of context (eg when it is set by the search feature) > it should be set to the current link's 'x' coordinate as well. Thanks for the accurate explanation. If updating both coordinates helps to go from A to B and then to E (in the previous example), it'd be worth a try. > That's the theory, which is followed in the code - mostly. It might be > that there are some cases where context is retained while it should be > discarded. Combined with the unknown-location-problems this can lead to > unexpected behaviour. I understand. What worried me most was being able to reach a state where it was possible to jump over a set of links... > > The gain I see with this scheme is that you can scroll down a > >page, and when you find an interesting link "call" the keyboard > >navigation cursor and quickly select the link. Otherwise you're > >carried to the top of the page (or to wherever the cursor was > >left) and will have to start finding the scrolled region where > >the to-be-clicked link is. > > > Ah, that's what you mean. Yes, this will be implemented in the next > version as well. Good! Cheers Jorge.-

Oct. 25, 2003

Re: [Dillo-dev] Thanks

by Maurice McCarthy

Frank, I'll do my best to give you the most accurate description that I can but I'm afraid I'll be away from my machine for 3 to 4 weeks. (I work in the North Sea oil fields. There is no linux machine there and we have only email but no internet accesss.) Maybe I can sort it myself as partly it does compile OK but I've not got frames support. Best Maurice On Sat, Oct 25, 2003 at 03:40:18PM +0200 or thereabouts, Frank de Lange wrote: > Maurice McCarthy wrote: > > >The invitation is nice but I don't think I have the skill. Where I work > >if something is not functioning then you > > > >a) hit it with a scaffold pole > >b) if its too small, hit it with a shifter (adjustable spanner) > >c) take it apart and clean it > >d) if its electrical push every button in sight > >e) when you know you've really broken it then > >f) call the maintenance dept. > > > > > Good! Do this to my tab/frame and keyboard_navigatino patches and tell > me what you've managed to break! > > I'll release new versions of the patches RSN (tm) which should apply to > current CVS. > > Cheers//Frank >

Oct. 25, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Paul Pelzl

On Sat, Oct 25, 2003 at 03:14:22PM +0200, Frank de Lange wrote: > Jorge Arellano Cid wrote: > > Note: we use to work heavily on patches and commit only after > >they're stable or polished. All this with a view to keep a > >relatively stable CVS source tree to work with. This is different > >to the usual model, but it has its rewards. With regard to the > >keyboard navigation patch, it probably can be polished better > >when on CVS, so here my remarks to make the next version into the > >sources. > > > > > I agree with screening patches for bugs, but I think there should be a > way for patches to get more exposure than they currently do. Many eyes > make all bugs shallow, release early release often, rinse, repeat, etc. > I test te patches, but I can only try so many sites and combinations. > Several bugs have been found by users (eg. the LOCALE bug in > GtkFrameset) which I probably would not have found. Aren't these sorts of problems generally solved by using CVS branches? The main tree can remain stable, and the development code would be (marginally) easier to obtain and work with if it could be tracked via a CVS branch. Paul

Oct. 25, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Melvin Hadasht

> A > . > . . B . C > . . . > D . E . F > . . . > G . H . I > > When moving focus DOWN from A, it will land in B (because that is the > next LOWER link closest to A). I agree with this. It is also the common behaviour in text editors and text processors. > Moving it down again lands it in C (NOT > E), as that is the next LOWER link closest to the original x-coordinate. I would expect that moving down will bring me to one of the links in the D.E.F line, the link which x position is the closest to A's. As this is a geometrical/(geographical) navigation, I'd expect a behaviour similar to cursor motion in text editors. > If you now were to move focus to link E (by moving it to the right), it > would update the 'x' cursor coordinate, so the next move DOWN after that > would end up on H. OK. > The cursor is ALWAYS set to the current link's 'y' coordinate. In case > focus is moved out of context (eg when it is set by the search feature) > it should be set to the current link's 'x' coordinate as well. I came across the User Agent Accessibility Guideline 1.0 (http://www.w3.org/TR/WAI-USERAGENT/cover.html#toc) but there is not much information in it that could help deciding what behaviour is to be expected with the cursor motion (but again, those are guidelines).

Oct. 25, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Frank de Lange

Jorge Arellano Cid wrote: > For instance: placing the nav cursor in the [gtk_type_new] link >inside the "struct GtkTypeObject" section and pressing DOWN, >brings the cursor to the leftmost [GtkType] under gtk_type_unique >but it is possible to get to the leftmost [GtkType] too! That is >focusing the leftmost one, then going UP then DOWN again. > You mean left- and right-most link? As in... A . . B . . C Going from A sometimes lands you in B, sometimes in C, depending where you came from? If so, that is by design. The code only modifies the 'x' cursor coordinate when the link is explicitly moved to the left or right, NOT when it is moved up or down. The reason for this is best explained in yet another ASCII-graphic: A . . . B . C . . . D . E . F . . . G . H . I When moving focus DOWN from A, it will land in B (because that is the next LOWER link closest to A). Moving it down again lands it in C (NOT E), as that is the next LOWER link closest to the original x-coordinate. If you now were to move focus to link E (by moving it to the right), it would update the 'x' cursor coordinate, so the next move DOWN after that would end up on H. The cursor is ALWAYS set to the current link's 'y' coordinate. In case focus is moved out of context (eg when it is set by the search feature) it should be set to the current link's 'x' coordinate as well. That's the theory, which is followed in the code - mostly. It might be that there are some cases where context is retained while it should be discarded. Combined with the unknown-location-problems this can lead to unexpected behaviour. > The gain I see with this scheme is that you can scroll down a >page, and when you find an interesting link "call" the keyboard >navigation cursor and quickly select the link. Otherwise you're >carried to the top of the page (or to wherever the cursor was >left) and will have to start finding the scrolled region where >the to-be-clicked link is. > Ah, that's what you mean. Yes, this will be implemented in the next version as well. 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." ]

Oct. 25, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Jorge Arellano Cid

Frank, Sebastian, List :) > > This is a good idea. Having the spaces inside links highlighted > >and the whole kbd. nav. current link in a distinctive pattern or > >color > > > > > I have used Sebastian's patch for a while now, let my GF try it, and we > are unanimous: looks much nicer ('more professional'), but is less > useable (hard to see where focus is). The next version of the patch will > use both color and a frame for focus highlight. Good! > > > One thing I noticed between kbd1 and kbd2 is that sometimes the > >latter makes odd jumps when using UP and DOWN keys. For instance > >with "gtk-types.html" page from GTK+'s manual. > > > > > What problem are you referring to? I tried that page (both for the > GTK+-1.2 and GTK+-2.2 manuals), and it reacted the way I would expect it > to (down goes down a link, up takes focus one link up). Completely > predictable and consistent. Which does not surprise me, as this is a > relatively 'easy' page with many links to choose from. Yesterday it took me some time to produce an odd behaviour. I didn't know then that user link navigation influenced how links are passed through, so I assumed a bug. You've already noticed some other glitches (as going from the first link to the one to the right when pressing DOWN), but yesterday (and again today) I managed to get into a situation where going from one link down to another and up again (using UP/DOWN), skipped several links placed in between. Unfortunately I don't know how to reproduce it... One interesting thing that may hint how to reproduce this is that it is possible to change (program to some extent) which link is selected for an up or down jump. i.e. it is not always the same. For instance: placing the nav cursor in the [gtk_type_new] link inside the "struct GtkTypeObject" section and pressing DOWN, brings the cursor to the leftmost [GtkType] under gtk_type_unique but it is possible to get to the leftmost [GtkType] too! That is focusing the leftmost one, then going UP then DOWN again. Maybe all these little glitches will be wiped out with the new link selection algorithm, I don't know... > > The places where I see inconsistent behaviour are mostly: > > - going UP in a page with few links sometimes takes me DOWN instead... > This is caused by the fact that links which have not yet been displayed > have their location set to '0,0'. The 'UP' code tries to find a link > with a lower y-coordinate than the current cursor. The solution is > probably to give such 'unknown' links a recognizable location (-1,-1) > and ignore them for positional navigation. > - sometimes a link is highlit when I did not ask for it (eg. first page > of Google search results). Have to look in to this. > - sometimes focus cycles to the top of the document when pressing > 'DOWN' on the last link on the page. This should not happen. Cause > probably the same as above. > - it is currently not possible to use Tab to focus the next frame in a > frameset. This is clearly a bug... > > > The "directional" navigation of links feels very handy and > >intuitive. One thing that can be improved is when the current > >link is outside the screen not to jump to it upon a key press but > >to find the most appropriate one within the displayed area. This > >would allow for a smooth keyboard navigation by integrating with > >the scrolling keys. > > > > > Ah, but what about those cases where there are no links inside the > displayed area? This happens quite often, eg. the 'next/prev' links on > the top and bottom of a document generated with LaTeX2html (and such). > This is actually what made me notice the problem in the first place. If there are no links inside the displayed area, jump to next one then! (just as it is now). The gain I see with this scheme is that you can scroll down a page, and when you find an interesting link "call" the keyboard navigation cursor and quickly select the link. Otherwise you're carried to the top of the page (or to wherever the cursor was left) and will have to start finding the scrolled region where the to-be-clicked link is. > I think that in these cases, 'sequential' focus (just take the next link > from the document source) is the best compromise between useability and > performance. To really solve this problem, the document would have to be > pre-rendered once to learn the location of all links. That is to big a > sacrifice for to little gain I think. [LIST: what do you think?] Yes, in case it is too complex to find whether a link is currently upon display (and also one that is), it may be not worth. Maybe Sebastian knows of a not too costly way. Sebastian? Cheers Jorge.-

Oct. 25, 2003

Re: [Dillo-dev] Thanks

by Frank de Lange

Maurice McCarthy wrote: >The invitation is nice but I don't think I have the skill. Where I work >if something is not functioning then you > >a) hit it with a scaffold pole >b) if its too small, hit it with a shifter (adjustable spanner) >c) take it apart and clean it >d) if its electrical push every button in sight >e) when you know you've really broken it then >f) call the maintenance dept. > > Good! Do this to my tab/frame and keyboard_navigatino patches and tell me what you've managed to break! I'll release new versions of the patches RSN (tm) which should apply to current CVS. 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." ]

Oct. 25, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Frank de Lange

Jorge Arellano Cid wrote: >Hi, > > Here go my comments on the keyboard navigation patches. > > I like them, and would like to commit it probably in the next >version (kbd3). > > Good! Maybe it would be a good idea to wait for patch #4 though, as #3 might (not sure yet) contain some big changes in the way links are found. This might introduce new bugs... > Note: we use to work heavily on patches and commit only after >they're stable or polished. All this with a view to keep a >relatively stable CVS source tree to work with. This is different >to the usual model, but it has its rewards. With regard to the >keyboard navigation patch, it probably can be polished better >when on CVS, so here my remarks to make the next version into the >sources. > > I agree with screening patches for bugs, but I think there should be a way for patches to get more exposure than they currently do. Many eyes make all bugs shallow, release early release often, rinse, repeat, etc. I test te patches, but I can only try so many sites and combinations. Several bugs have been found by users (eg. the LOCALE bug in GtkFrameset) which I probably would not have found. >>>I would at least leave the traditional line, for reasons of >>>consistence. Perhaps the link may be also highlighted, in a lighter >>>color than the background color (and lightgray for white etc., look at >>>Dw_style_color_create, which is used for shaded colors for borders)? >>>This would make it unconfusable with text selections. >>> >>> >>I have tried using tile and stipple fill patterns for focus highlight, >>this did not give useable results. Next on the line is color, with a >>(stippled/dashed) frame around the link. >> >> > > This is a good idea. Having the spaces inside links highlighted >and the whole kbd. nav. current link in a distinctive pattern or >color > > I have used Sebastian's patch for a while now, let my GF try it, and we are unanimous: looks much nicer ('more professional'), but is less useable (hard to see where focus is). The next version of the patch will use both color and a frame for focus highlight. > One thing I noticed between kbd1 and kbd2 is that sometimes the >latter makes odd jumps when using UP and DOWN keys. For instance >with "gtk-types.html" page from GTK+'s manual. > > What problem are you referring to? I tried that page (both for the GTK+-1.2 and GTK+-2.2 manuals), and it reacted the way I would expect it to (down goes down a link, up takes focus one link up). Completely predictable and consistent. Which does not surprise me, as this is a relatively 'easy' page with many links to choose from. The places where I see inconsistent behaviour are mostly: - going UP in a page with few links sometimes takes me DOWN instead... This is caused by the fact that links which have not yet been displayed have their location set to '0,0'. The 'UP' code tries to find a link with a lower y-coordinate than the current cursor. The solution is probably to give such 'unknown' links a recognizable location (-1,-1) and ignore them for positional navigation. - sometimes a link is highlit when I did not ask for it (eg. first page of Google search results). Have to look in to this. - sometimes focus cycles to the top of the document when pressing 'DOWN' on the last link on the page. This should not happen. Cause probably the same as above. - it is currently not possible to use Tab to focus the next frame in a frameset. This is clearly a bug... > The "directional" navigation of links feels very handy and >intuitive. One thing that can be improved is when the current >link is outside the screen not to jump to it upon a key press but >to find the most appropriate one within the displayed area. This >would allow for a smooth keyboard navigation by integrating with >the scrolling keys. > > Ah, but what about those cases where there are no links inside the displayed area? This happens quite often, eg. the 'next/prev' links on the top and bottom of a document generated with LaTeX2html (and such). This is actually what made me notice the problem in the first place. I think that in these cases, 'sequential' focus (just take the next link from the document source) is the best compromise between useability and performance. To really solve this problem, the document would have to be pre-rendered once to learn the location of all links. That is to big a sacrifice for to little gain I think. [LIST: what do you think?] 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." ]

Oct. 25, 2003