- Dillo-dev - lists.mailman3.com

A Message For You
by From eLove Dec. 3, 2003

Dec. 3, 2003

Finally, a BETTER and SAFER way to meet QUALITY SINGLES in YOUR area! Go to http://www.elove.com to find out more. The Safe, Smart Way to Connect. eLove is a safe, confidential and easy way to meet quality singles. Our members are intelligent, attractive, professionals in search of meaningful relationships. Discover the freedom of Trust. Explore romance without fear or worry. The eLove method focuses on trust. Unlike online personals, where many people are not who they say they are, we screen all our members so you'll feel confident that you're meeting genuine people. No Games Online chatting seldom works. eLove is for people who truly want to meet someone special and don't have time for playing games. What are you waiting for? Boost Your Social Life. Revel in Romance. Get A Love Life. Why is eLove the best way for great people to connect? Ever wonder how successful couples met and fell in love? The eLove System Revealed. Follow the link below to unsubscribe from all future mailings associated with this list http://lfemail.com/unsub.lf/cid/1855/rid/14147/email/Dillo-dev@lists.auriga…

1 0

gcc 2.95 doesn't know about -Wno-unused-parameter
by David McKee Dec. 3, 2003

Dec. 3, 2003

Jorge, I suppose you're getting tired of hearing about my ancient Redhat system, but my gcc doesn't believe in -Wno-unused-parameters, preferning "-Wno-unused". Easy enough to fix by hand. Perhaps I should look nto configure in my copious spare time. Thanks, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

4 6

[INFRINGEMENT... errr PATCH] Html_image_menu signal propagation cleanup
by Frank de Lange Dec. 3, 2003

Dec. 3, 2003

Hi'all, First, forgive me the snide remark in the title, I am not that fond of lawyer-speak. Second, this is a small cleanup for html.c which removes the need for an explicit signal emission stop in Html_image_menu. The comment in html.c:Html_image_menu() reads: /* If the signal is not stopped, Dw_image_button_press will be called, * and return FALSE, so that the "button_press_event" signal is regarded * as not processed. The fact that here, TRUE is returned, does not seem * to play a role!? */ No, signal return values do not influence the current *emission*, only the *propagation* of it. And, when connected with gtk_signal_connect, the default handler is the last one to run - so it is the return value for the default handler which decides whether the signal will be propagated or not. To have the return value for a custom handler decide this, it needs to be connected with gtk_signal_connect_after so it is the last handler to run. That is all this simple patch does. 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/src/html.c 2003-11-21 22:33:49.000000000 +0100 +++ dillo_patched/src/html.c 2003-12-02 12:59:46.455306584 +0100 @@ -355,11 +355,6 @@ a_Menu_popup_set_url(bw, image->url); gtk_menu_popup(GTK_MENU(bw->menu_popup.over_image), NULL, NULL, NULL, NULL, event->button, event->time); - /* If the signal is not stopped, Dw_image_button_press will be called, - * and return FALSE, so that the "button_press_event" signal is regarded - * as not processed. The fact that here, TRUE is returned, does not seem - * to play a role!? */ - gtk_signal_emit_stop_by_name (GTK_OBJECT (image), "button_press_event"); return TRUE; } @@ -2248,8 +2243,8 @@ Image = Html_add_new_image(html, tag, tagsize, &style_attrs, TRUE); Html_connect_signals(html, GTK_OBJECT(Image->dw)); - gtk_signal_connect(GTK_OBJECT(Image->dw), "button_press_event", - GTK_SIGNAL_FUNC(Html_image_menu), html->bw); + gtk_signal_connect_after(GTK_OBJECT(Image->dw), "button_press_event", + GTK_SIGNAL_FUNC(Html_image_menu), html->bw); /* Image maps */ if (Html_get_attr(html, tag, tagsize, "ismap")) {

2 1

Patch to allow setting of initial position
by Jan Dittmer Dec. 3, 2003

Dec. 3, 2003

Hi, for a TV Terminal I needed dillo to come up at a different position than 0,0. As there is no window manager running I wrote a small patch which allows to set the initial position of the upper left corner. Essentially it just clones the geometry code and adds a config option position=<xpos>x<ypos>. If it is not set or 0x0 specified it just takes it's default position. Perhaps this is of some use to anyone else. (Patch is against 0.7.3) Thanks, Jan diff -u org/src/dillo.c jan/src/dillo.c --- org/src/dillo.c Tue Jul 22 22:51:22 2003 +++ jan/src/dillo.c Fri Nov 28 14:34:35 2003 @@ -268,6 +268,8 @@ /* a_Nav_init() has been moved into this call because it needs to be * initialized with the new browser_window structure */ bw = a_Interface_browser_window_new(prefs.width, prefs.height, xid); + if ((prefs.xpos + prefs.ypos) > 0) + gtk_widget_set_uposition(bw->main_window, prefs.xpos, prefs.ypos); a_Bookmarks_init(); diff -u org/src/prefs.c jan/src/prefs.c --- org/src/prefs.c Mon Jul 7 17:40:15 2003 +++ jan/src/prefs.c Fri Nov 28 14:39:21 2003 @@ -35,6 +35,7 @@ guint token; } symbols[] = { { "geometry", DRC_TOKEN_GEOMETRY }, + { "position", DRC_TOKEN_POSITION }, { "http_proxy", DRC_TOKEN_PROXY }, { "no_proxy", DRC_TOKEN_NOPROXY }, { "link_color", DRC_TOKEN_LINK_COLOR }, @@ -114,6 +115,18 @@ } } break; + case DRC_TOKEN_POSITION: { + gchar *ptr, *str = scanner->value.v_string; + gint xpos, ypos; + + if ( (ptr = strchr(str, 'x')) && (xpos = strtol(str,NULL,10)) && + (ypos = strtol(++ptr,NULL,10)) ){ + prefs.xpos = xpos; + prefs.ypos = ypos; + } + } + break; + case DRC_TOKEN_PROXY: a_Url_free(prefs.http_proxy); prefs.http_proxy = a_Url_new(scanner->value.v_string, NULL, 0, 0); @@ -329,6 +342,8 @@ prefs.width = D_GEOMETRY_DEFAULT_WIDTH; prefs.height = D_GEOMETRY_DEFAULT_HEIGHT; + prefs.xpos = D_GEOMETRY_DEFAULT_XPOS; + prefs.ypos = D_GEOMETRY_DEFAULT_YPOS; prefs.http_proxy = NULL; prefs.no_proxy = NULL; prefs.no_proxy_vec = NULL; diff -u org/src/prefs.h jan/src/prefs.h --- org/src/prefs.h Thu Jul 10 00:00:34 2003 +++ jan/src/prefs.h Fri Nov 28 14:37:17 2003 @@ -10,6 +10,8 @@ #define DILLO_HOME "http://www.dillo.org/" #define D_GEOMETRY_DEFAULT_WIDTH 640 #define D_GEOMETRY_DEFAULT_HEIGHT 550 +#define D_GEOMETRY_DEFAULT_XPOS 0 +#define D_GEOMETRY_DEFAULT_YPOS 0 #define DW_COLOR_DEFAULT_GREY 0xd6d6d6 #define DW_COLOR_DEFAULT_BLACK 0x000000 @@ -27,6 +29,7 @@ typedef enum { DRC_TOKEN_FIRST = G_TOKEN_LAST, DRC_TOKEN_GEOMETRY, + DRC_TOKEN_POSITION, DRC_TOKEN_PROXY, DRC_TOKEN_NOPROXY, DRC_TOKEN_LINK_COLOR, @@ -70,6 +73,8 @@ struct _DilloPrefs { gint width; gint height; + gint xpos; + gint ypos; DilloUrl *http_proxy; gchar *no_proxy; gchar **no_proxy_vec;

3 5

[ANNOUNCEMENT] Dillo-Patches mailing list
by Paul Pelzl Dec. 3, 2003

Dec. 3, 2003

The recent "Official Statement" from the core Dillo developers contained this item: > We strongly urge the "code modifiers" to find their own mailing list > for discussing their "code modification" ideas In response, I would like to announce the dillo-patches mailing list. This list will provide a place for both users and developers to discuss extensive modifications of the Dillo sources, which are beyond the scope of the Dillo Project itself. If you are interested in some of the significant feature-enhancement patches that have been posted on dillo-dev recently, then I hope you will subscribe to dillo-patches. - You can subscribe to the list by sending email to dillo-patches-request(a)freelists.org with 'subscribe' in the Subject field OR by logging into the Web interface at www.freelists.org. - To post on the mailing list, send email to dillo-patches(a)freelists.org . Only subscribers may post to the list. - There is a Dillo-Patches website available at http://www.freelists.org/webpage/dillo-patches . It has some information about the list, has links to the archives, and will guide people in finding patches. I hope that this list will help to resolve some of the recent difficulties on dillo-dev. Jorge (or whoever has web access): It would be helpful to provide a link to http://www.freelists.org/webpage/dillo-patches somewhere on the Dillo website. Paul

1 0

Official Statement
by Sebastian Geerken Dec. 1, 2003

Dec. 1, 2003

Hi! This is an official statement about Dillo project's management, by the Dillo core team (mainly core and steady developers). About project management: ------------------------- There's an interesting difference between a: "code contribution" and a "code modification". The Dillo project, as a SW project, is not simply its code base. Among others, it has a core team that defines the development plans, policies, time frames, and technical details. If a "patch" happens to be aligned with the goals and technical guidelines defined by the core team, it's regarded as a "code contribution". If it doesn't follow them, or clearly infringes them, it is a "code modification". A "code modification" doesn't belong to the project, and must be hosted and supported elsewhere. Obviously, the code modification author can try to convince the core team of the idea (with reasonable arguments, not rants nor pejorative sentences, according to our mailing list etiquette). The final decision is up to Dillo's core team, and if the patch continues to be regarded as a "code modification" it must be hosted, discussed and supported elsewhere. About the dillo-dev mailing list: --------------------------------- dillo-dev is not the standard discussion forum of the web. It has an outstanding tradition of polite and respectful communication. dillo-dev is being flooded with rude emails from "code modifiers" that not only disregard the mailing list guidelines, but also refer to the core team's work in pejorative terms. This creates a very unfriendly atmosphere which has been severely detrimental to the continued development of Dillo. This situation has led some members of the team to communicate directly with each other. This is very bad because it has resulted in a lot of messages unrelated to the project which confuse subscribers about the current direction of Dillo development. Messages which are outside the bounds defined in the guidelines at http://www.dillo.org/MList.html are ignored and will remain unanswered. We strongly urge the "code modifiers" to find their own mailing list for discussing their "code modification" ideas, and to stop violating our mailing list etiquette. Please do not post any replies to this statement on dillo-dev. If any comments about this statement are posted to dillo-dev we urge all our subscribers not to follow the thread. Sincerely, Dillo core team.

1 0

How do you un-subscribe to this list
by Ronald W. Henderson Nov. 30, 2003

Nov. 30, 2003

Folks: I looked on this site and do not know how to un-subscribe to this list. Thanks in advance...

3 2

[patch] Cleanup of IO.c
by Indan Zupancic Nov. 29, 2003

Nov. 29, 2003

Hi, Just cleaned IO.c up, so nothing fundamental changed. Besides some cleanups in multiple functions this are the two major changes: Removal of a_IO_write_chunks, mainly because it isn't used anywhere and it doesn't add any real functionality, it does the same only in a different way. Thanks to CVS it is easy to add it back when you really needed, if you want. Removal of the ValidIOs list. This is the logical next step after g_source_remove was discovered, because the extra indirection isn't needed anymore. All in all the result is a much smaller IO.c (400 lines instead of 700), smaller Dillo (about 3K with -O2), and O(1) behaviour instead of O(n) in the IO engine. The changes have really no negative points as far as I can tell. Link to the patch: http://www.xs4all.nl/~dorinek/dillo/IO-cleanup.patch.gz Greetings, Indan

7 9

Re: [Dillo-dev] [patch] Cleanup of IO.c
by Indan Zupancic Nov. 27, 2003

Nov. 27, 2003

Hi, > I do not understand your disapointing very well and maybe because that i sound rude, excuseme then. Go read Dillo's website, go read the new developer info, go read the files in Dillo's doc dir. Then spend a reasonable amount of time coding for Dillo and cleaning up _their_ mess in IO.c. Then send a patch to the mailing list and wait one week. Let's see if you're disappointed or not. Keep in mind that CVS didn't change the last 6 days, and the last few changes were small, and also don't forget that Jorge claims that he's busy with Dillo full time. Dillo claims to have nice, modular, clean code, and then you encounter some ugly code and try to fix it... I'm afraid I sound rude sometimes too, but we're just telling what we think, right? :) Greetings, Indan

1 0

patch: toggle force_my_colors
by Paul Pelzl Nov. 26, 2003

Nov. 26, 2003

Hi folks, I have attached a pair of Dillo patches. They add a toggle-able menu item to the right-button context menu, which enables/disables the force_my_colors preference on the fly. I find this useful for some occasional websites that Dillo renders rather poorly, as well as sites that simply choose a horrid color scheme. The first patch applies on top of Frank's monster patch v15; the second applies against Dillo CVS of 20031119. I hope others find it useful. Paul

2 2

[PATCH] Version 16 of tab/frame/kbnav/etc patch is ready
by Frank de Lange Nov. 26, 2003

Nov. 26, 2003

Hi'all, The next version (16) of my tab/frame/keyboard navigation patch is ready (see bottom of this message for download instructions). This is mainly a bug-fix and CVS resync release. For an overview of the new features in this release, see the posting I made to the list on version 15. Fixed bugs ---------- keyboard navigation - erroneously highlighted link after leaving a form element, was caused by wrong function call order in focus_next_link. Fixed. keywords - problem with keywords separated by more than one space is fixed. Keywords can now be separated by any whitespace character, including newlines (but don't forget that you still have to enclose the whole keywords string in double quotes for the parser to recognize it!). splash screem - the splash screen is now installed in $(datadir)/dillo/dillo.html CVS date/time ============= The patch is made against CVS as it was on 20031124@13:18 GMT. It should apply against CVS as it was on 20031121(a)21.33 GMT and later. For those who can not or do not want to use CVS, a snapshot can be found here: http://www.geocities.com/ikbenfrank/dillo-200311241318.tar.gz Tabs, Frames and browser bloat ============================== version: 0.8.0-pre patch: dillo-20031124-tabs.patch.gz unpatched: 297204 bytes patched: 333460 bytes (gcc 3.2.2, binutils 2.13.90.0.18, CFLAGS "-Os") Download instructions ===================== The patch is made against 20031124@13:18 GMT 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-20031124-tabs.patch.gz size: 117192 bytes (gzipped, as downloaded) 531247 bytes (uncompressed) md5sum: 387f4dd85ead27de04d6527cc71504f5 (gzipped, as downloaded) 23ef8335f885d5657c75c7e9e0e18a3c (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." ] -- 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 8

patched dillo via Arch
by Paul Pelzl Nov. 26, 2003

Nov. 26, 2003

If anyone on the list is using GNU Arch, you can obtain: Dillo CVS + Frank's tab/frame/kbnav/etc. patch v16 + Indan's HTTPS patch v2 + my toggle-force-my-colors patch integrated into branch dillo--tabframe-pelzl--16.0 . The archive is: pelzlpj(a)eecs.umich.edu--2003 ftp://pelzlpj.dyndns.org/pub/paul/tla/2003 If you find this useful, please send me a private email. If no one cares, I won't bother to announce this archive in the future. Paul

2 1

Re: [Dillo-dev] patched dillo via Arch
by Frank de Lange Nov. 26, 2003

Nov. 26, 2003

Paul Pelzl wrote: >I wouldn't mind setting up a patches list, but only if there is demand >for it. Is patch discussion creating too much traffic on the wearlab >mailing list? If not, then it seems like keeping patch discussion on >the list would give the patches more exposure. > >Anyone else have an opinion? > >Paul > > > I think that patch traffic belongs on this list, as it is quite often relevant for all of Dillo (patched or unpatched). It also keeps the patches in sight for users/developers of unpatched Dillo, which should generate exposure. If/when the patches really take on a life of theirselves it is time to move, but that time has not arrived as far as I'm concerned. Good initiative btw, the Archive. 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

kbnav bugs anyone?
by Frank de Lange Nov. 25, 2003

Nov. 25, 2003

Hi'all, I just noticed that kbnav does not do the right thing when tabbing out of a mouse-selected form field. Instead of going to the next field, it starts at the first form field/button on the page. I'll resolve this for the next patch. If anyone has any other problems with kbnav (or tabs or frames, but that is another patch...) let me know. I'd like to resolve problems in the current feature set before adding anything new... 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] HTTPS version 2.
by Indan Zupancic Nov. 25, 2003

Nov. 25, 2003

Hi, I updated my https patch, can get it from: http://www.xs4all.nl/~dorinek/dillo/dillo-https.patch.gz I will update the installer tomorrow. Not much time, so here the readme text, which can be found at http://www.xs4all.nl/~dorinek/dillo/readme.txt: ------------------------------------------------------------------------ Last updated: 24 November 2003 This patch adds https support to the Dillo CVS version (Pre 0.80). FILES: * Latest https patch is called dillo-https.patch.gz. BUGS: * Dillo will crash if you reload a https webpage very fast multiple times. But you can't do that because I was so mean to edit the refresh function so that you can't reload faster than once per second, which makes no sense anyway. With fast reloads I mean clicking absurdly fast: I can't do it while holding my mouse in a normal way. Keeping Ctrl+R pressed is too though fast though: It aborts the previous reload before it can make a connection. TODO: * Proper proxy support. Tell me if you need it. Now proxy may work only if it uses https with the proxy port and if https is just http over ssl with proxies too (which is the case with the only proxy I know). * Fancy stuff like auto ACCEPT_SESSION for cookies for https connections, auto refresh every 15 minutes or so to keep the ssl connection alive, etc. (things to make Dillo work better with webmail) * Realy fix the weird bug. I tried it, and I gave up for now. STATS: With CFLAGS="-O2 -s" (Os is much slower than O2), gcc 3.2.2 347K, 355368 bytes: unpatched 344K, 351816 bytes: patched, configure --disable-https 346K, 353928 bytes: patched Yes, Dillo becomes smaller after my patch. I cleaned up IO.c a lot. CHANGELOG: - Synchronized to the current CVS. - Added better proxy handling: no idea if proxy works or not though. - Made it harder to crash: needs more fast reloads now (~10 instead of 3). - Prevented fast reloads so that Dillo can't crash anymore. :p - Cleanup of IO.c (smaller, faster, better). - Cleanup of all the https code (bigger, faster, better). - Proper autoconfiguring thanks to Paul Pelzl's patch. Thanks Paul. :) Enjoy, Indan P.S. If you reply, please don't include the whole email you reply to, only the parts you're replying to, or nothing at all. If everyone quotes everything every time you'll get huge emails very fast...

2 1

Proposal: United Dillo
by Indan Zupancic Nov. 24, 2003

Nov. 24, 2003

Hello, With "united Dillo" I mean that there is always just one Dillo running per user, so when you start Dillo while it is already running, then the current one will open a new window. I made a patch as proof of concept, see: http://www.xs4all.nl/~dorinek/dillo This approach has two big advantages: 1) Always one Dillo has less overhead than running multiple instances at the same time. 2) Automatic synchronization/no need for synchronization anymore. First advantage is in the spirit of Dillo, wanting to be small, light and fast. Second advantage means that doing certain things will be much simpler, like having always cookies, no need to synchronize plugins, meaning that dpid is not really needed anymore, because most of the points from the problem list are solved (see Dpid.txt). Problems that aren't solved: * Forks can be expensive (Dillo had to fork its dpis). But dpid does much more than simply forking: it forks and then starts up an external program (which often also forks and starts up wget). Beside, if Dillo uses library plugins then there is no need to fork at all. * It increments dillo's core size. The patch adds about 70 lines of code to dillo.c and increases dillo with about 1 K. It is true that if you get rid of dpid then more code is needed in Dillo's core. But that's only moving the code to some other place, no real increase if you ask me. Having a seperate dpid has much more overhead at runtime (seperate process versus bigger executable). You can always make a plugin handling library, then it isn't part of Dillo's core. Of course a united Dillo has problems/disadvantages too: It is sometimes still needed to synchronize multiple windows. If it's not implemented carefully, you may lose functionality (aka command line options). A user can't run more than one Dillo instance. Sometimes it's wanted to run multiple Dillo's, for instance two different versions. But that isn't possible at all, or if version awareness is added, without losing synchronization. What do you think about it? Greetings, Indan

6 13

[PATCH] Version 5 of kbnav patch is ready
by Frank de Lange Nov. 24, 2003

Nov. 24, 2003

Hi'all, The next version (5) 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 add any new features, it is mainly a bug fix and CVS resync release. For more info on what this patch does, see the doc/Keyboard_Navigation.txt document (after applying the patch, naturally...) Fixed bugs ---------- - erroneously highlighted link after leaving a form element, was caused by wrong function call order in focus_next_link. Fixed. CVS date/time ============= The patch is made against CVS as it was on 20031124@13:18 GMT. It should apply against CVS as it was on 20031121(a)21.33 GMT and later. For those who can not or do not want to use CVS, a snapshot can be found here: http://www.geocities.com/ikbenfrank/dillo-200311241318.tar.gz Download instructions ===================== There is currently only one version of the patch, made against 2003124@13:18GMT 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-200311241458-kbnav.patch.gz size: 30633 bytes (gzipped, as downloaded) 152984 bytes (uncompressed) md5sum: 0ed60695cab750669f3d50c201bdf217 (gzipped, as downloaded) 20aeb6b96e551cd8f4fa65ac5d74ef9e (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

RPM Latest Frame tabs patch with basic authentication:
by Ronald W. Henderson Nov. 24, 2003

Nov. 24, 2003

Folks: Could someone direct me to a location that has a RPM built with the latest Frame and Tabs patch but also basic authenitcation code. I find dillo as an excellent browser but the lack of basic authentication as a standard built in feature limits my use. Today, many networking Vendor's support a web interface for administation of their product and typically require basic authentication for login. I would like to use dillo as my browser for administration purposes. I appreciate your support on this excellent browser! ---Ron Henderson

1 0

Re: [Dillo-dev] [PATCH] Version 15 of tab/frame/kbnav/etc patch, now with keywords and more...
by Frank de Lange Nov. 24, 2003

Nov. 24, 2003

Paul Pelzl wrote: > Now that I look at the problem again, I appear to have misdiagnosed it. > >It looks like the problem is with multiple spaces between keywords, not >with newlines. I've attached an example that causes a segfault after >entering any URL in the location bar. > >keywords = "s:http://www.google.com/search?q=%s ~:file:~" > > OK, solved this one as well. g_strsplit creates an empty string when two or more consecutive split-characters are encountered (quite reasonable behaviour, but not what I want for keywords) and the keywords processing code was not prepared for empty keywords (this in constrast to keywords with empty URLs which were handled OK). Is fixed in my code now, I'll release a new version of the patch with all recent fixes, made against the most recent version of CVS today or tomorrow. 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

Sigh... CVS out of sync 5 minutes after I upload my patches
by Frank de Lange Nov. 23, 2003

Nov. 23, 2003

It is as if the devil plays with it... 5 minutes after I upload my latest patches, CVS gets updated and the patch does not apply anymore. Well, this time I was prepared for that. Anyone who wants to try tab/frame patch no. 15 can download the CVS source on which it is based from the patch site: http://www.geocities.com/ikbenfrank/dillo-200311191409.tar.gz This is the UNPATCHED CVS code that was used to create the patch. To get a working tabbed/frames/etc browser, download this tarball and the patch, then apply the patch. From now on I will always include the CVS code on which the patch was based to get around these irritating synchronisation problems. Indan, if you want to update your HTTPS patch, may I suggest you use this source code tarball instead of current Dillo CVS? This way we are less dependent on the state of 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." ]

3 4

latest commit: cleanup on glib ids
by Jorge Arellano Cid Nov. 21, 2003

Nov. 21, 2003

Hi Sebastian! While making the latest patch (now in CVS), I finally had the time to track gtk_timeout_add, gtk_idle_add and g_io_add_watch inside gtk/gdk/glib sources. The interesting part is that after the related wrappers, they all end using g_source_add; this function uses hook_id (ghook.h) which gets the id from seq_id. :-) In short: seq_id starts from 1 and hook_id is largely used with zero as a non-used/non-active/non-valid value! I updated dillo accordingly and eliminated the uneasy feel of initializing a guint with -1 as an invalid value. Regards Jorge.-

1 0

Re: [Dillo-dev] [PATCH] Version 15 of tab/frame/kbnav/etc patch, now with key words an more...
by Billy Nov. 21, 2003

Nov. 21, 2003

In src/prefs.h you specify DILLO_SPLASH as file:/usr/share/dillo/dillo.html We don't install into that prefix. I made 2 changes. Added a dep for prefs.h and a rule which fixes the splash path as well as changing DILLO_SPLASH to file%%PREFIX%%/share... It's an ugle Makefile hack, but I didn't want to wade through the morass of autoconf for the correct solution. --- src/Makefile.am Fri Nov 21 09:35:45 2003 +++ src/Makefile.am.orig Tue Nov 11 07:13:59 2003 @@ -1,9 +1,3 @@ -.fixed_splash_path: - cp prefs.h x && cat x | sed 's@%%PREFIX%%@$(prefix)@' > prefs.h && rm -f x - touch .fixed_splash_path - -prefs.h: .fixed_splash_path - AM_CPPFLAGS=-DDILLORC_SYS='"$(sysconfdir)/dillorc"' SUBDIRS = IO @@ -24,8 +18,6 @@ capi.c \ capi.h \ debug.h \ - doc.c \ - doc.h \ dw.h \ dw.c \ dw_aligned_page.c \ @@ -68,18 +60,12 @@ dw_tooltip.h \ dw_widget.c \ dw_widget.h \ - gtkframeset.c \ - gtkframeset.h \ findtext.c \ findtext.h \ selection.c \ selection.h \ - focus.c \ - focus.h \ web.c \ web.h \ - pagemark.c \ - pagemark.h \ progressbar.c \ progressbar.h \ dillo.c \ @@ -100,8 +86,6 @@ image.h \ misc.c \ misc.h \ - tab.c \ - tab.h \ interface.h \ interface.c \ history.c \ --- src/prefs.h Fri Nov 21 09:35:11 2003 +++ src/prefs.h.orig Sat Nov 15 14:13:03 2003 @@ -8,8 +8,6 @@ #endif /* __cplusplus */ #define DILLO_HOME "http://www.dillo.org/" -#define DILLO_SPLASH "file:%%PREFIX%%/share/dillo/dillo.html" - #define D_GEOMETRY_DEFAULT_WIDTH 640 #define D_GEOMETRY_DEFAULT_HEIGHT 550 @@ -19,15 +17,6 @@ #define DW_COLOR_DEFAULT_PURPLE 0x800080 #define DW_COLOR_DEFAULT_BGND 0xd6d6c0 -#define COMPRESS_COMMON_PREFIXES "index of ;re: ;fwd: ;www.;welcome to ;the " - -/* target enumeration */ -enum { - TARGET_SELF, - TARGET_TAB, - TARGET_WINDOW -}; - /* define enumeration values to be returned */ enum { PARSE_OK = 0, @@ -49,8 +38,6 @@ DRC_TOKEN_TEXT_COLOR, DRC_TOKEN_USE_OBLIQUE, DRC_TOKEN_HOME, - DRC_TOKEN_SPLASH, - DRC_TOKEN_KEY_BINDINGS, DRC_TOKEN_PANEL_SIZE, DRC_TOKEN_SMALL_ICONS, DRC_TOKEN_FONT_FACTOR, @@ -69,10 +56,8 @@ DRC_TOKEN_SHOW_URL, DRC_TOKEN_SHOW_SEARCH, DRC_TOKEN_SHOW_PROGRESS_BOX, - DRC_TOKEN_SHOW_POPUP_NAVIGATION, DRC_TOKEN_FULLWINDOW_START, DRC_TOKEN_TRANSIENT_DIALOGS, - DRC_TOKEN_POPUP_DIALOGS, DRC_TOKEN_FW_FONT, DRC_TOKEN_VW_FONT, DRC_TOKEN_GENERATE_SUBMIT, @@ -81,14 +66,6 @@ DRC_TOKEN_SHOW_HTML_WARNINGS, DRC_TOKEN_SHOW_MSG, DRC_TOKEN_USE_OLD_PARSER, - DRC_TOKEN_KEYWORDS, - DRC_TOKEN_TARGET_BLANK, - DRC_TOKEN_TAB_LOAD_IN_BACKGROUND, - DRC_TOKEN_TAB_BAR_SHOW_FULLSCREEN, - DRC_TOKEN_TAB_BAR_SHOW_SINGLE_TAB, - DRC_TOKEN_TAB_BAR_SCROLLER, - DRC_TOKEN_TAB_TITLE_COMPRESS, - DRC_TOKEN_COMPRESS_COMMON_PREFIXES, DRC_TOKEN_LAST } Dillo_Rc_TokenType; @@ -102,8 +79,6 @@ gchar *no_proxy; gchar **no_proxy_vec; DilloUrl *home; - gchar *splash; - gboolean show_splash; guint32 link_color; guint32 visited_color; guint32 bg_color; @@ -130,10 +105,8 @@ gboolean show_url; gboolean show_search; gboolean show_progress_box; - gboolean show_popup_navigation; gboolean fullwindow_start; gboolean transient_dialogs; - gboolean popup_dialogs; gchar *vw_fontname; gchar *fw_fontname; gboolean generate_submit; @@ -142,16 +115,6 @@ gboolean show_html_warnings; gboolean show_msg; gboolean use_old_parser; - gchar *keywords; - gchar **keywords_vec; - gint target_blank; - gboolean tab_load_in_background; - gboolean tab_bar_show_fullscreen; - gboolean tab_bar_show_single_tab; - gboolean tab_bar_scroller; - gboolean tab_title_compress; - gchar *compress_common_prefixes; - gchar **compress_common_prefixes_vec; }; -- billy "Who get's bigger evertime you void, It's Hank the Happy Hemorroid."

3 3

[PATCH] Version 4 of kbnav patch is ready
by Frank de Lange Nov. 21, 2003

Nov. 21, 2003

Hi'all, The next version (4) 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 add many new features. It does however fix most known bugs, which is a good enough reason for applying it I'd say... One new feature is that is is now possible to popup context menus with keyboard navigation. The default key binding is Alt-Enter (and Alt-KP_Enter), this can of course be changed using the appropriate preference incantation. For more info on what this patch does, see the doc/Keyboard_Navigation.txt document (after applying the patch, naturally...) Fixed bugs ---------- - all known segfaults - most 'weird navigation order' problems - related issue (now fixed in CVS): a_Findtext_search returned FALSE (instead of FINDTEXT_NOT_FOUND) when a search was performed on an empty page. Since this function is supposed to return a FindtextResult enum value (and the first value in that enum is FINDTEXT_SUCCESS) this made the focus code try to focus a link in an empty page leading to a segfault in the scrolled_window. TODO ==== - add x scrolling capability to Dillo (change anchors, URL_POS, scrolling functions, iterators, etc...). This is needed for better keyboard navigation on wide pages. Download instructions ===================== There is currently only one version of the patch, made against 2003119@14:09GMT 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-200311211558-kbnav.patch.gz size: 30615 bytes (gzipped, as downloaded) 152903 bytes (uncompressed) md5sum: 29aa01c8c5eabe3c7294b975155255ce (gzipped, as downloaded) 5c848e7f0e281e3135392522c8a7f980 (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

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