- Dillo-dev - lists.mailman3.com

NEW YEARS EVE BASH! - Mention Perfect Match
by Sherrie Baily Dec. 4, 2003

Dec. 4, 2003

Wondering where to spend New Years Eve? Youâre invited to Shecky's New Years Ball 2004 on December 31st, 2003 at Flatiron's hot spot ANJU! Countdown to New Years at this fabulously swanky spot for a spectacular night of dancing, endless drinking, hors d'oeuvres and celebration. With its recent $1 million renovation, Anju promises one unforgettable night. View Invitation: http://www.sheckys.com/newyear/default.asp?rf=PMatch Your BIG night includes: - Premium Open Bar 9:00pm - 3:00am - Amstel Light 9:00pm - 6:00am - Passed Hors D'oeuvres - Party Favors - Champagne Toast @ Midnight - 2 DJ's & Bi-Level Dancing - Dim Sum Breakfast @ 3:30am - Complimentary Shecky's 2004 Bar, Club & Lounge Guide Price: $125 (per person) by Dec. 21st | $150 (per person) after Dec. 21st *VIP Tickets* include: (4 person minimum. required) - All of the above - 1 Private VIP Table - 1 Bottle of Kettle One Price: $175 (per person) by Dec. 21st | $200 (per person) after Dec. 21st ============== How to Buy Tickets: ============== Purchase Online: http://www.sheckys.com/newyear/tickets.asp?rf=PMatch Purchase By Phone: (212) 242-2566 Guests Must be 21 or Older | Tickets are very limited so buy soon | Mention "Perfect Match" when you buy! Got Questions? Call (212) 242-2566 ===== Details: ===== Day: December 31, 2003 Time: 9:00pm - 6:00am Place: ANJU @ 36 East 20th St. (Broadway & Park Ave. South) View Invitation: http://www.sheckys.com/newyear/default.asp?rf=PMatch Got Questions? Call (212) 242-2566 Follow the link below to unsubscribe from all future mailings associated with this list http://lfemail.com/unsub.lf/cid/1859/rid/14147/email/Dillo-dev@lists.auriga…

1 0

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