- Dillo-dev - lists.mailman3.com

[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