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

[INFRINGEMENT... errr PATCH] Html_image_menu signal propagation cleanup
by Frank de Lange 03 Dec '03

03 Dec '03

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 03 Dec '03

03 Dec '03

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 03 Dec '03

03 Dec '03

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 01 Dec '03

01 Dec '03

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