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

wanted: CPU overhead source.

by Jorge Arellano Cid

Hi, I just noticed that utilities.html (from ImageMagick manual), takes near three times more time to render with CVS than with 0.7.3. That page is 230KB and has no images. It takes 3 seconds to render with 0.7.3 vs 9 seconds of CVS (on a slow machine). The same is true for the new and old parser. Can somebody please profile it to find the overhead source? (./configure --enable-gprof). TIA Jorge.-

Dec. 3, 2003

Re: [Dillo-dev] [INFRINGEMENT... errr PATCH] Html_image_menu signal propagation cleanup

by Jorge Arellano Cid

On Tue, 2 Dec 2003, Frank de Lange wrote: > Hi'all, > > First, forgive me the snide remark in the title, I am not that fond of > lawyer-speak. You have the freedom to modificate or contribute (or both), but please don't keep posting bad-seeds to dillo-dev. > 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: > [...] Done. (& thanks for the nice explanation). Sincerely Jorge.-

Dec. 3, 2003

Re: [Dillo-dev] Patch to allow setting of initial position

by Jorge Arellano Cid

Jan, > Eric GAUDET wrote: > > It works for me with today's CVS and your patch. > > > > in dillorc: > > geometry=320x200+50+50 > > > > dillo.pos/src>./dillo > > Setting geometry from rc to 320x200 50 50 > > ... > > > > The first one is actually used, but having the second message is confusing. > > Those can probably both go entirely. It was more for debug uses. Here is > an updated patch with those removed. > > Jan Fore unknown reasons, gcc 3.2.2 gives me this error: <q> In file included from IO/Url.h:7, from IO/mime.h:14, from dillo.c:47: IO/IO.h:40: unnamed fields of type other than struct or union are not allowed make[1]: *** [dillo.o] Error 1 </q> when X11/Xlib.h is included from dillo.c. The interesting part is that libDio.a compiles flawlessly. I moved the call into misc.c (which gives no problems) and also made a custom function. I prefer this one (to avoid X11/Xlib.h). I'm sending you this version of the patch (outside dillo-dev), so you can review it and comment. Cheers Jorge.- PS: there's no need to CC' me, I read dillo-dev.

Dec. 3, 2003

[ANNOUNCEMENT] Dillo-Patches mailing list

by Paul Pelzl

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

Dec. 3, 2003

Re: [Dillo-dev] gcc 2.95 doesn't know about -Wno-unused-parameter

by David McKee

On Tue, 2 Dec 2003, Jorge Arellano Cid wrote: > On Tue, 25 Nov 2003, Andreas Schweitzer wrote: [attribution to me lost] > > > my gcc doesn't believe in -Wno-unused-parameters, [snip] > > Attached is a patch [snip] > Commited. > Does it work for you David? Perfectly. Thanks. -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Dec. 3, 2003

Re: [Dillo-dev] gcc 2.95 doesn't know about -Wno-unused-parameter

by Jorge Arellano Cid

On Tue, 25 Nov 2003, Andreas Schweitzer wrote: > Hi > > > > I suppose you're getting tired of hearing about my ancient Redhat > > > system, but my gcc doesn't believe in -Wno-unused-parameters, preferning > > Same on FreeBSD which also still uses 2.95. I think there are lots > of systems that still use gcc2.95 > > > If you add a simple way to test whether gcc accepts the warning > > option, in configure.in, it'd be ok. > > Attached is a patch wich does just that. However, it assumes that the > -Wno-unused-parameters appeared with version 3 of gcc. A quick > google search seems to confirm that this option was introduced with > gcc 3.0 - can anybody with gcc 3.0 confirm that ? > > The patch also fixes some problems with detection of /usr/local > in the default path. > > This patch works on a FreeBSD 4.8 system (gcc 2.95) and a > Suse 8.2 system (gcc3.2). Commited. Does it work for you David? Cheers Jorge.-

Dec. 2, 2003

[INFRINGEMENT... errr PATCH] Html_image_menu signal propagation cleanup

by Frank de Lange

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")) {

Dec. 2, 2003

Official Statement

by Sebastian Geerken

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.

Dec. 1, 2003