- Dillo-dev - lists.mailman3.com

RE: [Dillo-dev] FLTK
by Eric Gaudet Nov. 21, 2003

Nov. 21, 2003

I will give it a try. > -----Original Message----- > From: Sebastian Geerken [mailto:s.geerken@ping.de] > Sent: Tuesday, October 14, 2003 1:55 PM > To: Dillo mailing list > Subject: Re: [Dillo-dev] FLTK > > > Hi! > > To have some facts for this discussion, there is a (basicly working) > patch for the Gtk2 port, at > <http://www.dillo.org/misc_files/gtk2.diff.gz>. > It is a slightly modified version of a patch, which Jörgen sent me > some time ago, and compiles with the current CVS (probably not with > 0.7.3). > > Sebastian > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

8 10

Re: kbnav3 patch test
by Jorge Arellano Cid Nov. 21, 2003

Nov. 21, 2003

Frank, > Jorge Arellano Cid wrote: > > >Hi Frank, > > > > After waiting for a week as you suggested, today I gave a > >review to the new kbnav patch. It feels good! > > > > After some testing I came across a page that produces a > >segfault. The attached patch is against today's CVS + a couple of > >compiler-warning removals. The page is also attached. Beware that > >the segfault is only caught when the new parser is used, and that > >the page has bad-html. The case is interesting though, because a > >weird widget tree is generated and iterators should be able to > >handle/survive them! > > > > Please give it a look. > > > > Cheers > > Jorge.- > > > I have taken a look at your patch-to-my-patch, but did not apply it to > the version I will publish later today. :-o > I did do some manual > reformatting to correct some tab-related problems Good! > (Emacs' use of tabs > messes up things sometimes, and the 2-space indent it uses are not > consistent with Dillo's conventions). Thanks, we strive to be style consistent. BTW, I didn't try to fix indentation in the patch, it was just to do a test run. > Some files seem to be missing from > the patch you sent me, I guess you did not make any changes to those? My mistake. > > I did not see anything in your patch which would have corrected any > compiler warnings by that way, with a possible exception for the > disputed URL_ILLEGAL_CHARS_ macro. In my patch I used > URL_ILLEGAL_CHARS_(u) in html.c, while you use URL_ILLEGAL_CHARS(u). In > the current patch I use URL_ILLEGAL_CHARS(u) as well. The end result > should be the same however now that both versions exist. What compiler > warnings did you get which were corrected by your modifications to my patch? focus.c: In function `Focus_state_find_list': focus.c:268: warning: `list' might be used uninitialized in this function focus.c: In function `Focus_state_find_link': focus.c:465: warning: `list' might be used uninitialized in this function gcc version 3.2.3 > > On that Tarot-page you added to the message, I can say that navigation > is still quirky. But so is the page, it produces 9 warnings about > misplaced </a> tags. If you look at the source, you'll notice that it > misses several closing </A> tags (causing Dillo to allocate links all > over the page). It also contains some links with <BR> in them, which > used to crash patched Dillo because of the problem with > a_Dw_page_construct_iterator (which used to always set the mask to > DW_CONTENT_ALL, I changed this to a user-settable mask like all other > iterators have). I guess you attached the page because of those crashes? Yes, for you to have a way to reproduce it. BTW, that is what I meant with: "page has bad-html". > I will probably publish a new version of the patch (4) today, together > with a new version of the tab/frame patch. That version should be more > or less ready to commit, as no serious problems have cropped up for > several days now. See the list for problems found and corrected > (including the one causing the Tarot page to crash by the way - see my > message dated Wed, 12 Nov 2003 11:00:58 +0100). Oh, I didn't find anything about it at GMANE !? Cheers Jorge.-

3 3

FORM:DICKSON M.
by MR Dickson Mubane. Nov. 20, 2003

Nov. 20, 2003

FGood Day Friend, With warm heart I offer my friendship, and my greetings, and I hope this letter meets you in good time. It will be surprising to you to receive this proposal from me since you do not know me personally. However, I am sincerely seeking your confidence in this transaction, which I propose with my free mind and as a person of integrity and from a family with high moral respect . My name is Dickson Mubane, the first son of Mapele Mubane, of the most popular black farmer from Zimbabwe, murdered in the land dispute in my country. As led by my instict, My motherand Idecided to contact you through email, after searching for contacts via the internet,as it is the only means I can contact anybody since I am cutting off ties with Zimbabwe for security and safety reasons. However, I apologize if this is not acceptable to you. The purpose of this letter is to seek your most needed assistance in a business venture. Due to the land and political problems in Zimbabwe, as a result of President Robert Mugabe's introduction of new Land Act Reform wholly affecting the rich white farmers and the few rich black farmers, and his desire to hold on to power for life, my father for saw the danger that came in Zimbabwe. Before he was murdered, he withdrewall of our business foreign accounts in dollars and sold up our sharesin major companies. We then went to SOUTH AFRICA to deposit the sum of US$50.million (Fifty million, US dollars),in a private security company. This money was deposited with this Private Security company for safety and security reasons, and was to be used for the purchase of land, new machines and chemicals establishment of new farms in Europe.President Mugabe's support for the violent Zimbabwean war veterans andsome lunatics in the society, led to the murder of my beloved fatherand other innocent lives. I was continually threatened to abandon myinheritance from my father after he was murdered. I resited for awhile, but when the danger became unbearable, and I survived two murderattempts, I fled Zimbabwe. I am currently staying in the Netherlands where I am seeking political asylum. In fact my decision to come hereto seek asylum, is because the security company from South Africa, hasa branch here, and they have moved the deposit from their office in Johannesburg down here. I need you to assist in receiving thisconsignment from the security compamy. Since the law of Netherlands prohibits a refugee (asylum seeker) to be involved in such transactions and my mother advised that it will be better for our foreign partner to help receive this fund to avoid any eye brown being raised by Robert Mugabe, this is why I am seeking a genuine and reliable partner,who will assist in receiving the funds and also investing it wisely in a profitable venture.You have to understand that this decision taken by me entrusts my future and in your hands, as a result of the safe keeping of this money. If you accept to assist me, all I want you to do for me, is to assist with arrangements to claim the deposit from the security company from their office here in The Netherlands, as it has now been transfered from Johannesburg,South Africa to their branch in The Netherlands. The company will be legally informed of you representing my family. For your assistance, I have two options for you. Firstly you can choose to have 10% of the money for your assistance, and helping my family investing this funds, or you can go into partnership with me for the proper profitable investment of the money in your country. Whichever the option you want, please to notify me in your reply. I have also set aside 1% of this money for all kinds of expenses that come our way in the process of this transaction, and 4% of the total sum for Charitydonation.If you prefer to accept the 10% for assisting in representing my family to receive this funds, then 85%will be left for my family.Please, I want you to maintain the absolute secrecy for the purpose of this transaction. I look forward to your reply and co-operation, and Ithank you in advance as I anticipate your co-operation.You can reach me on my private line which is or via email Sincerely, Dickson Mubane. PLEASE YOU CAN READ ABOUT PROBLEMS IN ZIMBABWE FROM THE LINKS BELOW. http://news.bbc.co.uk/1/hi/world/africa/918781.stm http://news.bbc.co.uk/1/hi/world/africa/715001.stm http://news.bbc.co.uk/1/hi/world/africa/1063785.stm

1 0

Re: [Dillo-dev] HTTPS Patch
by Indan Zupancic Nov. 20, 2003

Nov. 20, 2003

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 :)

15 38

mail adress
by Sebastian Geerken Nov. 18, 2003

Nov. 18, 2003

Hi! Please send private mail to me via <s.geerken(a)ping.de>. Do not use <sgeerken(a)student.physik.uni-dortmund.de>, the latter causes some problems. Sebastian

1 0

Re: [Dillo-dev] tabs, https, ...
by Indan Zupancic Nov. 17, 2003

Nov. 17, 2003

Hello, Thank you for your kind offer, but as it looks now it's just Frank and me who could use a CVS branch, and perhaps the Dillo developers are willing to make a CVS branch too, then you don't have to be bothered with mirroring the base Dillo and serving it. Having one or more CVS branches would be great, the question is if the Dillo developers are willing to cooperate and provide them, or that we should make use of your offer. Let's see what Frank has to say about it. Greetings, Indan

1 0

tabs, https, ...
by taj＠www.linux.org.uk Nov. 17, 2003

Nov. 17, 2003

I've been following the dillo mail list for a while getting a feel for what is up; Good things! With the external patches, I'd be willing to toss in a cvs server that mirrors the base dillo and has modified branches for various interests or even one merged branch. The intent would be to just keep a seperate single repository for external work which dillo could merge portions that fit it's philosophy. The offer would include www,cvs,ftp and shell access for developers that post their nontrivial patches to the official mail-list. -- Trent Jarvi taj(a)www.linux.org.uk

1 0

gushort for port instead of guint
by Indan Zupancic Nov. 16, 2003

Nov. 16, 2003

Hello, Just a tiny cleanup, ports are always shorts, so no need to make it an int. It also makes the structure SocketData 4 bytes smaller because of less padding. Greetings, Indan diff -purN orig/src/IO/http.c https/src/IO/http.c --- orig/src/IO/http.c 2003-11-11 22:15:39.000000000 +0100 +++ https/src/IO/http.c 2003-11-15 18:26:01.000000000 +0100 @@ -58,7 +58,7 @@ G_STMT_START { typedef struct { gint SockFD; const DilloUrl *Url; /* reference to original URL */ - guint port; /* need a separate port in order to support PROXY */ + gushort port; /* need a separate port in order to support PROXY */ gboolean use_proxy; /* indicates whether to use proxy or not */ DilloWeb *web; /* reference to client's web structure */ GSList *addr_list; /* Holds the DNS answer */

2 2

Cross Compiling for arm
by Donald McKnight Nov. 13, 2003

Nov. 13, 2003

Hello, I recently downloaded 0.7.3 to cross compile on the gmate yopy 3700. with my first attempt I noticed the configure script grabbed all of my local variables such as /usr/local/lib instead of /opt/arm-linux/lib. This gave me libgtk.so cannot read symbols. I went though the configure and manually set the environment variables and was able to successfully compile dillo, however when I transfer the binary to arm it does not launch it just hangs. I have cross-compiled several apps using the same cross-compiler on my system. I am using slackware 9.1 kernel 2.4.22, but I don't think the version should matter. Has anyone ran into this before? Thanks Donald McKnight

2 2

[RFC] keywords
by Frank de Lange Nov. 13, 2003

Nov. 13, 2003

While we're talking preferences anyway... I have another addition to the range: keywords. In my current version you can type "s something or other" in the location bar, which is interpreted as "search for something or other" through this keyword definition in the dillorc: s:http://www.google.com/search?q= You can define as many as these as you want. The format is keywords = "<keyword>:<url> <keyword>:<url> ..." The end result of a successful keyword match consists of the url for the keyword, followed by an escaped copy of anything that followed the keyword. The above example for "s" looks like this: http://www.google.com/search?q=something%20or%20other This adds next to nothing to the size of Dillo by the way. Any strong sentiments against this functionality? [ and on the subject of preferences... I know what Havoc et al say, but I do not always agree... In many cases choice is a good thing, as long as it is not mandatory to choose. Define sane defaults for those who can not or do not want to choose, but keep things flexible for those who want to change those defaults. TIMTOWTDI ] 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." ]

2 1

[RFC] Last call... remove conditional compilation from tab/fram patch?
by Frank de Lange Nov. 13, 2003

Nov. 13, 2003

Hi'all, Those of you who want to keep the conditional compilation options for tabs and frameset support in the tab/frame patch, speak up now. If I do not get any serious requests in this direction I will remove the conditional compilation options in the next patch (any day now...) and you'll all be stuck with tabs and frames. But... that might be the reason you applied the patch in the first place, so... BTW, the selection issue with the tab/frame patch is solved, I just forgot to set the owner for the selection. 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." ]

3 3

[RFC] external Dillo splash screen
by Frank de Lange Nov. 13, 2003

Nov. 13, 2003

Hi'all, I've removed the Dillo splash screen from src/IO/about.c, and added a new preference 'splash_url' (currently set to '/usr/lib/dillo/dillo.html' by default, this can change). The contents of that file are identical to the current splash screen. I've also added a new pref 'show_splash', which - you guessed it - can be used to suppress the splash screen. Set it to NO, and Dillo will come up with a blank window instead. Dillo is now ca. 11 KB smaller than before. The splash screen loads just as fast. The splash screen can be distributed with Dillo just like the dpi's are. Should it be missing, all that'll happen is that Dillo will complain about not finding the file. No breakage... Seems like an improvement to me. 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." ]

3 5

[RFC] Quo Vadis Dillo
by Frank de Lange Nov. 13, 2003

Nov. 13, 2003

Hi'all, Now that the last release of the patches seem to work (number 13 was less of a success...)... Where do we want to be tomorrow? What needs to be added/changed to improve Dillo? Should the tab/frame/etcetera + Indan's patch + ??? be forked into an 'experimental' version, somewhat like the Sylpheed MUA was forked into Sylpheed-claws? Talking about my patch, what does need improvement? Some ideas: - select contents of location bar/search field when they are focused (DONE, in next version) - make the 'search the web' popup disappear when popup_dialogs=NO, replace it with a non_popup version or use the location bar for search (like several other browsers do) - more key bindings (replacing current key handling where applicable) - remove compile options for tabs and frames, make tabs/frames standard? [ PDA/embedded developers: is this OK with you? ] - ??? 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." ]

8 12

dillo won't resolve URLs under a proxy environment?
by Ken Wolcott Nov. 12, 2003

Nov. 12, 2003

Hi; Dillo looks interesting. However I can't go anywhere with it as I am under a proxy environment. I saw that the default dillorc has a commented-out section for http_proxy. I copied the default dillorc to be my ~/.dillorc and started dillo again. I noticed that the chatter from dillo no longer complained about a missing .dillorc, yet I am still unable to go to any URL. The message on the web browser was: "Error: Dns: can't resolve http://linuxtoday.com". I get the same basic error message when trying to go to www.perl.com or http://www.perl.com. I am able to go to these web sites using other web browsers such as mozilla, galeon, opera, netscape and konqueror. Each one of those I had to set a proxy preference. Perhaps my proxy setting has incorrect syntax? Enclosed is the chatter from dillo and the .dillorc (proxy setting has obviously been sanitized). Thanks, Ken **************snip********************** prompt> cat /etc/redhat-release Red Hat Linux release 8.0 (Psyche) prompt> which dillo dillo is /usr/bin/dillo ptompt> dillo --version Dillo 0.7.3 /msa3530> prompt> dillo Setting locale to C... dillo_dns_init: Here we go! Disabling cookies. Nav_open_url: Url=>about:splash< Nav_open_url: Url=>http://linuxtoday.com/< Dns_server [0]: linuxtoday.com is (nil) Dillo: normal exit! /prompt> **************snip********************** **************snip********************** http_proxy=http://my_ip:my_port/ **************snip**********************

5 10

Re: [Dillo-dev] dillo won't resolve URLs under a proxy environmen t?
by Ken Wolcott Nov. 12, 2003

Nov. 12, 2003

Hi Stephen; That was **EXACTLY** the problem! I moved ~/.dillorc to be ~/.dillo/dillorc...Works fine now! Thanks, Ken On Wednesday 12 November 2003 14:35, Stephen Lewis wrote: > On Wed, Nov 12, 2003 at 02:18:38PM -0600, Ken Wolcott wrote: > > Hi Thorben; > > > > If my proxy server refuses to resolve requests coming from the dillo > > web > > > browser, it doesn't make any sense for it not to refuse requests from > > the > > > mozilla web browser. The proxy settings are identical. One of them > > exists > > > in the ~/.dillorc and the other exists in the mozilla advanced proxy > > setting > > > preferences. So, it looks to me like dillo doesn't like my ~/.dillorc > > and > > > isn't telling me that there's a problem. Mozilla works fine, dillo > > doesn't, > > > the proxy settings are the same. > > Hi, I think I just noticed the root of your problem. > > You're using a ~/.dillorc file. What dillo actually wants is a > ~/.dillo/dillorc file, I don't think it is using the file at > ~/.dillorc at all :) > > Another method is to set the "http_proxy" environment variable, > which many console progams like wget tend to honour > > Hope that helps.

1 0

Re: Keybd 3 patch
by Frank de Lange Nov. 12, 2003

Nov. 12, 2003

Jorge Arellano Cid wrote: >Hi Frank, > > I just noticed the newes keyboard navigation patch in the >mailing list. Please tell me if this problems were fixed or if a >should wait the next version before aiming to a merge: > > These problems are gone. I have completely overhauled the internals so that focus always is in sync with the rest of Dillo. Which just happened to fix the problem Sebastian noticed... I'd say, wait a week or so to see if any issues crop up. If all seems OK commit the patch. [ LIST: please give keyboard navigation, on either version of the patch, a workout. This needs some testing if it is to be part of mainstream Dillo. Try it in frame sites, try navigatin between frames with Tab/Shift-Tab, try the keyboard bindings, etc. ] By the way, the patch also contains a fix to a problem with dpid/Makefile.am (which did not honour DESTDIR on installation, messing up make install for non-root users). Let me know when you apply this, because it will affect the tab/frame/kbnav patch s 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." ]

3 7

[PATCH] cleanup of URL_ILLEGAL_CHARS
by Frank de Lange Nov. 12, 2003

Nov. 12, 2003

Jorge, Skip that last patch I sent you, here is a new one which also touches html.c... Please apply 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." ] diff -pruN dillo/src/html.c dillo_patched/src/html.c --- dillo/src/html.c 2003-11-11 21:45:01.947370344 +0100 +++ dillo_patched/src/html.c 2003-11-12 09:01:46.119597904 +0100 @@ -152,7 +152,7 @@ static DilloUrl *Html_url_new(DilloHtml url_str, (use_base_url) ? base_url : URL_STR_(html->linkblock->base_url), flags, pos); - if ((n_ic = URL_ILLEGAL_CHARS(url)) != 0) + if ((n_ic = URL_ILLEGAL_CHARS_(url)) != 0) MSG_HTML("URL has %d illegal character%s (00-1F, 7F or space)\n", n_ic, (n_ic) > 1 ? "s" : ""); return url; diff -pruN dillo/src/url.h dillo_patched/src/url.h --- dillo/src/url.h 2003-11-11 21:45:02.153339032 +0100 +++ dillo_patched/src/url.h 2003-11-12 08:16:28.038808992 +0100 @@ -57,7 +57,7 @@ #define URL_ALT_(u) u->alt #define URL_POS_(u) u->scrolling_position #define URL_STR_(u) a_Url_str(u) -#define URL_ILLEGAL_CHARS(u) url->illegal_chars +#define URL_ILLEGAL_CHARS_(u) url->illegal_chars /* * Access methods that always return a string: @@ -77,7 +77,7 @@ #define URL_ALT(u) NPTR2STR(URL_ALT_(u)) #define URL_POS(u) URL_POS_(u) #define URL_STR(u) NPTR2STR(URL_STR_(u)) - +#define URL_ILLEGAL_CHARS(u) NPTR2STR(URL_ILLEGAL_CHARS_(u)) /* URL-camp compare methods */

2 2

Cookies disabled
by William Trenker Nov. 12, 2003

Nov. 12, 2003

When dillo starts a console message indicates that cookies are disabled. Is there a way to enable cookies? Thanks, Bill

3 2

help
by Pavankumar P Nov. 12, 2003

Nov. 12, 2003

---------------------------------------------------NOTIFICATION-------------- -------------------------------------------- The subject line for this message is prohibited by Symantec AVF and the message was quarantined. The Subject Line of the message falls under restricted category. If you think that the message is valid please raise a call through helpdesk for further clarifications and release of the same." Please note this message will be retained for 3 Days for claim, after which it will be purged. ----------------------------------------------------------------------------- ----------------------------------------------- ID:MTV01EX01::SYQ69c2e949 DISCLAIMER: This message (including attachment if any) is confidential and may be privileged. Before opening attachments please check them for viruses and defects. MindTree Consulting Private Limited (MindTree) will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside. If you have received this message by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change and MindTree shall not be liable for any improper, untimely or incomplete transmission.

1 0

[PATCH] Version 14 of tab/frames/kbnav patch is ready
by Frank de Lange Nov. 12, 2003

Nov. 12, 2003

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

3 4

DPI's and 0.7.3
by William Trenker Nov. 11, 2003

Nov. 11, 2003

Will the download and ftp dpi's in CVS work with Dillo 0.7.3? If so, how do I build them? Or do I have to wait until version 0.8 is available? Thanks, Bill

1 0

Latest parser changes
by Jorge Arellano Cid Nov. 11, 2003

Nov. 11, 2003

Hi there! After all the trouble with trying to convince Slashdot's webmasters to fix their HTML (because of the loftier importance of adhering to standards), and considering Andreas S. comment on that dillo was making a weird rendering only, but not helping to find the cause to fix the problem, I started a more in-depth review of it. As time passed the code I was developing turned more and more interesting and finally here you have it! This is a quote from the ChangeLog: * Adapted the generic parser to make HTML error detection, providing the line number and a hint (expected tag) in the error message! * Added 'show_html_wanings' option to dillorc (boolean). * Added information about optional, required and forbidden end tags. * Modified the parser's handling of closing tags to account for elements with an optional close tag, and for more accurate diagnosis messages. * Added 'use_old_parser' option to dillorc (boolean). * Fixed the handling of HEAD and BODY elements to account for their double optional condition (both open and close tags are optional). This basically means that now dillo will detect and print useful error messages about bad-formed HTML. After using it for a while it helped me to find bugs I have overseen for months and it proved very accurate and helpful! (it even catched one at the W3C site! :) I hope it will be a good tool for webmasters, and for people authoring simple web pages. In our side, it will help to polish our HTML parsing. For instance, it soon became clear that we're sometimes pulling tags when they should stay. For instance: <p> <ol><li> One <li> two </ol> </p> <- detects an error here. because <ol> anticipatedly cleans <p> from the stack. This may look not relevant, but when trying to build a DOM tree it certainly is! Some comments: The new parsing behaviour makes sites render different from what they used to. Sometimes they show better, some others worse. After all it is bad-formed HTML what we're dealing with. For instance: heise.de a bit worst but usable. slashdot.org renders ok. sf.net worst but usable. Please bear in mind that now dillo can diagnose these errors at render time so, as a user, now you can send a meaningful error report to a site's webmaster! (for instance slashdot is diagnosed on-the-fly). Our experience is that most webmasters welcome this reports. Finally, remember that you can turn off the HTML error messages show_html_wanings=NO and that you can fall back to the old parser: use_old_parser=YES Enjoy! (I hope ;) Jorge.-

1 0

libpng detection again...
by Jorge Arellano Cid Nov. 11, 2003

Nov. 11, 2003

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

3 2

[ATTENTION][PATCH] New version of tab/frame patch (13) has error, new version later today
by Frank de Lange Nov. 10, 2003

Nov. 10, 2003

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;

2 1

Re: [Dillo-dev] [PATCH] Version 13 of tab/frames/kbnav patch is ready
by Frank de Lange Nov. 10, 2003

Nov. 10, 2003

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

1 0

[PATCH] nit in dpid/Makefile.am
by Frank de Lange Nov. 10, 2003

Nov. 10, 2003

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

1 0

[PATCH] Version 3 of keyboard navigation patch
by Frank de Lange Nov. 10, 2003

Nov. 10, 2003

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

1 0

[PATCH] Version 13 of tab/frames/kbnav patch is ready
by Frank de Lange Nov. 10, 2003

Nov. 10, 2003

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

1 0

Re: mailing lists dead?
by Thorben Thuermer Nov. 10, 2003

Nov. 10, 2003

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

1 0

Re: [Dillo-dev] HTTPS Patch
by Indan Zupancic Nov. 7, 2003

Nov. 7, 2003

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

2 1

Simulating a slow connection
by Sebastian Geerken Nov. 4, 2003

Nov. 4, 2003

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

2 2

[PATCH] memory leak in dw_ext_iterator
by Frank de Lange Nov. 4, 2003

Nov. 4, 2003

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);

2 2

IPv6
by Jorge Arellano Cid Nov. 3, 2003

Nov. 3, 2003

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

1 0

(no subject)
by Jan.Stary＠ff.cuni.cz Nov. 3, 2003

Nov. 3, 2003

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

2 2

version tests on automake and autoconf
by robert w hall Nov. 2, 2003

Nov. 2, 2003

I believe Dillo 7.2 tests for v1.7 of autoconf and, if configure.in is patched, for 1.7 of automake. A couple of us are interested in porting uptodate ssl-enabled versions of dillo to the playstation2, where the base distro is rather ancient (Redhat 5 -era :-)) Dillo 7.1.2 with Andreas' ssl-patch compiled fine, but didn't require these recent versions of automake & autoconf. Are these recent versions _in fact_ required or can the tests for them be safely disabled? Bob -- robert w hall

2 2

hairy bug in IO fixed!
by Jorge Arellano Cid Oct. 31, 2003

Oct. 31, 2003

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

1 0

Re: [Dillo-dev] HTTPS Patch
by David McKee Oct. 28, 2003

Oct. 28, 2003

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)

5 6

HTTPS patch
by Indan Zupancic Oct. 27, 2003

Oct. 27, 2003

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

2 3

fltk c binding
by cesar Oct. 27, 2003

Oct. 27, 2003

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;

2 1

[PATCH] Version 2 of keyboard navigation, solves problem with Tab
by Frank de Lange Oct. 26, 2003

Oct. 26, 2003

Hi'all, The next version (2) 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. This release does not contain any major new functionality. It solves the problems with Tab, which now does what you'd expect it to do: cycle through form widgets. For more info on what this patch does, see the last message on the list or the doc/Keyboard_Navigation.txt document (after applying the patch, naturally...) Download instructions ===================== There is currently only one version of the patch, made against 20031017/11:26GMT 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-200310171559-kbnav.patch.gz size: 14494 bytes (gzipped, as downloaded) 64277 bytes (uncompressed) md5sum: 8ebd2450b762a720363346c0c4a7a537 (gzipped, as downloaded) 9538b60172b910e89c993d887b28bc97 (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." ]

8 24

Bug #502 solved
by Frédéric Bothamy Oct. 24, 2003

Oct. 24, 2003

Hello, I submitted the bug #502 a while ago about some PNG images not displayed correctly. And today someone finally gave the explanation: the Debian web server sends GIFs images with image/png content type (and png extension) (for more details, see http://lists.debian.org/debian-www/2003/debian-www-200310/msg00133.html) Could someone, please, close this (non-)bug? Sorry for not testing this issue enough and thanks for this wonderful, lightweight browser. Fred PS: for anyone interested in using Dillo 0.7.3 with tab+frame patch (v10) under Debian woody (i386 only), I have an unofficial package available at http://olympie.dyndns.org/debian/debs/dillo_0.7.3-1.3_i386.deb.

2 1

frames, tabs patch
by Jens Arm Oct. 24, 2003

Oct. 24, 2003

Hi When will the frames- and tabs-patch integrated into CVS ? Jens

1 0

Re: [Dillo-dev] FLTK
by Jorge Arellano Cid Oct. 23, 2003

Oct. 23, 2003

Hi there! Just to add more information about FLTK: http://mail.gnu.org/archive/html/texmacs-dev/2003-02/msg00073.html Very informative. Cheers Jorge.-

1 0

Can't find dpidrc
by Nigel Wilkinson Oct. 23, 2003

Oct. 23, 2003

Hi folks I've just built dillo-0.8.0-pre from the CVS but when I try to use bookmarks it can't fimd dpidrc either in /usr/lib/dillo/dpi or in the ~/.dillo/dpi directory (and its right, they aren't there. Where is it or what is the format so that I can create it. Cheers Nigel

3 5

Re: [Dillo-dev] FLTK
by Jorge Arellano Cid Oct. 23, 2003

Oct. 23, 2003

Hi there! After the previous answers from Michael Sweet (forwarded to this list), Sebastian rose a key question: > GtkLayout is mainly there to overcome the limited size of X > windows. When I started to develop Dw, I first tried to get a similar > result by writing anything myself, but finally gave it up. Look at the > Gtk+ documentation, GtkLayout does some weird things which may not be > possible with FLTK. Once again, here're the answers. Cheers Jorge.- PS note: Fl_Help_View is a widget for basic HTML rendering. ---------- Forwarded message ---------- Date: Wed, 22 Oct 2003 16:03:52 -0400 From: Michael Sweet <mike(a)easysw.com> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Re: FLTK and Dillo Jorge Arellano Cid wrote: > ... > One interesting concern raised by Sebastian is about a way to > overcome the limited-window-size problem of X windows (GTK+ uses > GtkLayout to overcome it). I know FLTK runs on WIN32 so it should > have no problems with large windows, but I couldn't find any > formal doc stating it. This is an issue for us because of large > scrolled html pages (or should I say books?). Are you referring to the 16-bit coordinate issues? If so, those are also present on WIN32... FLTK 1.1.x uses 16-bit integers for coordinates, so to support views larger than 16-bits you'll need to do a little work yourself. For example, Fl_Help_View offsets the X,Y values by the current scroll position and does gross clipping of blocks to support really long HTML files. FLTK 2.x uses 32-bit integers for coordinates and doesn't have this limitation. It will also be providing device classes to support X11, PostScript, PDF, etc. rendering in a device- independent way. >>> 2.- Unicode, UTF-8. >>> This was the main reason for considering GTK2. Is FLTK ready >>> to render Unicode characters? >> >>The patched version is, and FLTK 2.0 will fully embrace UTF-8. > > > Do you mean current FLTK 2.0 CVS does not have the patch yet? AFAIK, 2.0 doesn't have it yet. Bill Spitzak is probably a better person to talk to on that issue, as I've been sticking to maintaining 1.1.x (lack of time on my part - too many other projects! :) > If so, can it be patched or should we use 1.1.4 + utf-8 patch? > > In other words, which version should we start testing with? > What's your advice to structure it (i.e on which widgets should > we base HTML rendering)? Use 1.1.4 + UTF-8 patch; 2.0 is still in a state of flux, and until we have the new device classes in place there may still be some API changes. If you write to 1.1.x now, the 1.x compatibility headers in 2.0 should be enough to support your apps with either release. You'll probably want to subclass Fl_Group and use the existing Fl_Scrollbar classes to provide your scrollbars. The Fl_Help_View widget might serve as a guide for your porting effort, as it supports a limited subset of HTML and does all of the scrolling, linking, etc. stuff. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com

1 0

CSS
by Sebastian Geerken Oct. 23, 2003

Oct. 23, 2003

Hi! At <http://www.dillo.org/CSS.html>, you'll find an updated version of a document I posted quite a while ago. What this text describes, is partly implemented (mainly to test the critical aspects of the design), I may soon make a tarball public, after some cleanups. The further development is unclear, since some parts have been rewritten, incremental development is difficult, and several general tests are necessary (performance, functionality etc). Sebastian

1 0

localhost
by Ivo Oct. 23, 2003

Oct. 23, 2003

Hi all, I noticed the following behaviour, with 0.7.3 and also with the current CVS (just checked out the latest version an hour ago). When I type the following at the location bar: http://www.cnn.com/ Opens the webpage (offcourse) www.cnn.com Opens the webpage (it prepends http://) http://localhost/ Connects to my webserver localhost Connects to my webserver (prepends http://) http://localhost:2317/ It connects to my geneweb server localhost:2317 It fails, saying ERROR: unsupported protocol Is this normal and expected behaviour, or considered a bug? Opera, for example, prepends http:// and all works like expected. --Ivo

2 1

[PATCH] Version 12 of tab/frame/kbnav patch, solves problem with Tab
by Frank de Lange Oct. 23, 2003

Oct. 23, 2003

Hi'all, The next version (12) of my tab/frame/keyboard navigation patch is ready (see bottom of this message for download instructions). No big new features this time, just a useability fix for the Tab key and an update to the latest CVS. Tab now does what you'd expect it to do, cycle through form widgets. I'll spare you the usual list of comments on this release, it would be identical to last release's list anyway... Download instructions ===================== The patch is made against 20031017/11:26GMT 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-20031017-tabs.patch.gz size: 85658 bytes (gzipped, as downloaded) 373460 bytes (uncompressed) md5sum: be0618ac0136fafd9f7f91ce8a4db142 (gzipped, as downloaded) 41438b3b27bf45f23b6a9069eee37cb6 (uncompressed) As always, check the site for the most recent version Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / \ \ `--| _/ <Hacker for Hire> \ `---' \ +46-734352015 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

2 1

Thanks
by Maurice McCarthy Oct. 22, 2003

Oct. 22, 2003

Hi all As a linux learning running Woody from a home pc I'd just like to thank you all for a great browser. Came across it by chance looking for something else then was totally surprised to find it in the Woody CD's! It goes great with Mutt. Fast. Thanks again Maurice

3 5

A short potpourri
by Eythan Weg Oct. 22, 2003

Oct. 22, 2003

Hi, I have read that people use dillo to read documents, long documents, and perhaps whole books, or chapters... In such cases there comes a time when a use of a dictionary is a must. Is it possible to have a dpi that will allow for the running of any shell command on a highlighted portion of the screen? In this example running a dictionary on a word? The output of the command would go into a new tab, or window or split of the current window, horizontally or vertically, depending on the key-binding. On another vein, I have two problems with version 8-pre of about two weeks ago patched with the tab-frame feature (I compiled yesterday's version with the new patch, but could not figure how to start the dpis... can someone tell how in some more details, please?) The first is over-tabbing. For example browsing http://mail.gnome.org/archives/gnomemeeting-list/ choose any thread and it opens on a new tab. Read any post and again it opens in a new tab. The second is that copy and/or paste do not work reliably. I am not sure this is dillo's issue though. Sincerely, eythan

3 2