- Dillo-dev - lists.mailman3.com

Frames
by Peter Milne Dec. 5, 2003

Dec. 5, 2003

Tell me, if I recall, there is a way to view frames in Dillo...correct? Would love to use it for Squirrelmail. Would actually be willing to use another web based, imap mail client too. -- ~~~Pete~~~ http://milneweb.com http://nomorevirus.com

2 1

Re: [Dillo-dev] gcc 2.95 doesn't know about -Wno-unused-parameter
by Jorge Arellano Cid Dec. 5, 2003

Dec. 5, 2003

On Wed, 3 Dec 2003, David McKee wrote: > On Tue, 2 Dec 2003, David McKee wrote: > > 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. > > Having said that on the basis of my gcc 2.95 based debian machine at home, > I tried it on my work machine. > > The Redhat box actual uses: > > $ gcc -v > Reading specs from > /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs > gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > > *sigh* > [...] > Style question: > > Would it be better to test for the presence of the flag than to try to > exclude those compilers without it? Yes, that's the right way to do it, but I don't know how yet :) I commited a patch that tests for gcc version 3. Please test it and tell us. Cheers Jorge.-

2 1

Re: dpid
by Jorge Arellano Cid Dec. 4, 2003

Dec. 4, 2003

[we've had this thread for a long time outside dillo-dev, it has some interesting information so I'm switching to dillo-dev] Ferdi, On Thu, 4 Dec 2003, Ferdi Franceschini wrote: > Hi Jorge, > > On Tue, Dec 02, 2003 at 09:03:08AM -0300, Jorge Arellano Cid wrote: > > > > Hi Ferdi, > > > > > > [...] > > > > Unfortunately the dpid is showing some problems with some https > > > > urls (also with some ftp ones). It sometimes ends in a loop of > > > > endless forking of dpi programs. > > > The https dpi appears to be implemented as a filter type plugin but it is installed as > > > https.dpi and not https.filter.dpi. > > > > Oh! > Does https work now? It does partly! (with the dpi-cache patch I'm developing). I'm planning to develop https.dpi as a dpi server so it can directly link against SSL lib or GNU TLS, instead of using wget. This ends the forking and allows for an easy implemetation of connection caching. BTW, https pages render OK with my tree, it's just the lack of reuse of the same connection what I suspect keeps it from working fully. I need to test a bit more too. Note: is there anybody here interested in working on the https dpi. I can quickly make the base (dpi server instead of filter) and then is a matter of knowing SSL or TLS and start implementing connection caching (no need to know about dillo internals). > [...] > > > The idea is interesting. Perhaps looking at the Volume III of > > Douglas Comer's book is well worth a try. I skimmed it yesterday > > and it has a lot of theory about this kind of servers. Do you > > have that volume? > I'm affraid not, I'll see if I can hunt down a cheap copy. Worth a read (although I prefer Richard Stevens' books). > > Now that filter dpis can run in parallel, they're also showing > > the fork hog problem. I'm attaching an example page; drop it > > inside an ftp directory of your local machine and try loading it > > from dillo. > > > > WARNING: don't do it on a server, it can bring down the machine! > > (I've had to switch-off mine to recover). > > > Dpid keeps on forking new instances of the ftp dpi until the > > machine is full of new processes. It looks like when the first > > child can't accept the connection, dpid regards the old request > > as a new one and forks another child. > But dpid accepts the connection from dillo on behalf of filter dpis so any > connections seen by dpid must be new requests. I'll double check that. (It could be that the service FD keeps showing in the select call because it was connected, but never serviced...) > I set up an ftp server on my old 486 and tried out the test page. > And it killed my Xserver! > It also really upset inetd on my 486 which was > running ftpd, inetd reported looping ftp connections and terminated the > service. It also refused further connections for some time afterwards, however > you can get things back to normal by restarting inetd. > > I redirected the messages to a file and tried again, I found multiple > occurences of the following message: > <q> > Dpi_get_server_uds_name:: /tmp/ferdi-khv5us/ftp.filter.dpi > </q> > > this suggests that dillo is actually making multiple requests. > I also found the following error messages from dpid: > <q> > main.c:153: get_command: dpid tag is NULL > : main.c:323: main: get_command failed > </q> > > I still don't know what's going wrong, I'll have another look at this in the > next couple of days, I hope the above information helps. I'll check it too. > > Some time ago I started a download with a graphical dpi, and > > the downloader was open twice! This hints towards the presence of > > a race condition. > What do you mean by graphical dpi? It's an idea I've been preaching on for a long time. But nobody seems to believe until they see! :-) --Blame St. Tomás. > Is there a shiny new downloads server that > I'm missing out on? Yes! MUUUAAHAHAHAHAHAHAA!! It needs polishing but illustrates the idea pretty good. You'd be surprised at how simple it is. BTW, it was developed by a complete newcomer to dillo I was advicing. I'll send it to you and Sebastian (to illustrate part of a response I owe him about preferences). List: I'll review the latest version and decide whether to share it in its current state for polishing. The required knowledge to work on it is minimal: just GTK+ (the server part is already done). More on this later... Anyone interested? > > a race condition: if the father continues running before its > > child accepts, the request may be served twice or more times. > Only if the child terminates before it accepts. > This is because dpid clears the downloader's socket from the > socket_set which > 'select' is watching before forking and the socket is then set again by > dpid.c:handle_sigchld() when the child terminates. Time to review. Regards Jorge.-

1 0

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