- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] wanted: CPU overhead source.

by Jorge Arellano Cid

Hi Johannes, > I just profiled cvs- and 0.7.3 version. I used http://www.w3.org/TR/xslt20/ > stored locally on disk (utilities.html rendered too fast here). > I could not yet get any reproducible results from profiling, !? Doesn't it show any function usage-ratio/run-time change? > but cvs is obviously slower 5.1 vs. 3.9 seconds. And with cvs the GUI freezes > until the whole page is loaded, whereas 0.7.3 displays the GUI while it is > rendering the page (you can see the "Kb" counting in the upper right corner). Yes, probably because rendering is done when idle. Thanks Jorge.-

Dec. 4, 2003

Re: dpid

by Jorge Arellano Cid

[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.-

Dec. 4, 2003

NEW YEARS EVE BASH! - Mention Perfect Match

by Sherrie Baily

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…

Dec. 4, 2003

Re: [Dillo-dev] wanted: CPU overhead source.

by Johannes Hofmann

Hi, I just profiled cvs- and 0.7.3 version. I used http://www.w3.org/TR/xslt20/ stored locally on disk (utilities.html rendered too fast here). I could not yet get any reproducible results from profiling, but cvs is obviously slower 5.1 vs. 3.9 seconds. And with cvs the GUI freezes until the whole page is loaded, whereas 0.7.3 displays the GUI while it is rendering the page (you can see the "Kb" counting in the upper right corner). Regards, Johannes Hofmann On Wed, Dec 03, 2003 at 01:09:26PM -0300, Jorge Arellano Cid wrote: > > 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.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Dec. 3, 2003

A Message For You

by From eLove

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…

Dec. 3, 2003

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

by David McKee

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* My attempts to read the auto<whatever> docs last week were very depressing, so I just looked at configure.in, and ponied up this fix: ========== --- dillo/configure.in Wed Dec 3 11:48:31 2003 +++ dillo_tweaked/configure.in Wed Dec 3 11:32:18 2003 @@ -201,7 +201,9 @@ if eval "test x$GCC = xyes"; then fi if test "`echo $CFLAGS | grep '\-W[^a]' 2> /dev/null`" = ""; then if test "`$CC -v 2>&1 | grep 'version 2'`" = ""; then - CFLAGS="$CFLAGS -W -Wno-unused-parameter" + if test "`$CC -v 2>&1 | grep 'version egcs-2'`" = ""; then + CFLAGS="$CFLAGS -W -Wno-unused-parameter" + fi fi fi if test "`echo $CFLAGS | grep '\-Waggregate-return' 2> /dev/null`" = ""; then ========== which simply adds anther test to exclude gcc 2.* based egcs releases before sticking in the new flags... Style question: Would it be better to test for the presence of the flag than to try to exclude those compilers without it? Anyway, thanks for the work. -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Dec. 3, 2003

dead link behavior

by Peter Milne

Greetings all, Was wondering if it is me or if it was normal. If I click a link and it turns out to be a dead link.....everything locks up hard and I have to 'xkill' Dillo. Thanks, -- ~~~Pete~~~ http://milneweb.com http://nomorevirus.com

Dec. 3, 2003

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

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

by Eric GAUDET

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 only problem, it seems, is that it still prints the dillorc setting, even when the CLI option is used: dillo.pos/src>./dillo -geometry 700x100+10+400 Setting geometry from CLI to 700x100 10 400 Setting geometry from rc to 320x200 50 50 ... The first one is actually used, but having the second message is confusing. Best, EG -- En reponse de "Re: [Dillo-dev] Patch to allow setting of initial position" de Jan Dittmer, le 30-Nov-2003 : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jorge Arellano Cid wrote: >| >| I understand. Maybe the "canonical" solution to this problem is >| to add support for the geometry CLI option. >| >| That is: >| >| -geometry <width>x<height>{+-}<x>{+-}<y> >| >| Can you make the patch this way? >| > > Here is a preliminary version. Only problem is that entering it in the > dillorc doesn't work, because the parser doesn't recognize the + as part > of a string resulting in these errors: > > dillorc:2: unexpected character `+', expected symbol > dillorc:2: unexpected character `0', expected symbol > dillorc:2: unexpected character `+', expected symbol > dillorc:2: unexpected character `0', expected symbol > dillorc:2: error: unexpected character `0', expected symbol > > So I tried changing > > - - "~-_:&%#/.0123456789" > + "~-_:&%#/.0123456789+" > > in prefs.c, which doesn't work. How the parse be changed that it > recognizes + as part of the value? > > Thanks, > > Jan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQE/ygYdLqMJRclVKIYRApfZAJ4jb1fc3Dd8OrMB+Csgyekz74VikwCfaFv5 > s7AZVApr+hS8dRtKK97kS0Y= > =axoU > -----END PGP SIGNATURE----- ------------------------------------------------------------------------ Eric GAUDET <eric(a)rti-zone.org> Le 30-Nov-2003 a 13:41:12 "Parler pour ne rien dire et ne rien dire pour parler sont les deux principes majeurs et rigoureux de tous ceux qui feraient mieux de la fermer avant de l'ouvrir." ------------------------------------------------------------------------

Nov. 30, 2003

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

by Jan Dittmer

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 only problem, it seems, is that it still prints the dillorc setting, > even when the CLI option is used: > > dillo.pos/src>./dillo -geometry 700x100+10+400 > Setting geometry from CLI to 700x100 10 400 > 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 Common subdirectories: org/src/IO and jan/src/IO 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 Sun Nov 30 22:48:24 2003 @@ -21,6 +21,7 @@ #include <stdio.h> #include <gtk/gtk.h> +#include <X11/Xlib.h> #include <sys/types.h> #include <sys/stat.h> @@ -66,6 +67,7 @@ DILLO_CLI_HELP = 1 << 3, DILLO_CLI_VERSION = 1 << 4, DILLO_CLI_LOCAL = 1 << 5, + DILLO_CLI_GEOMETRY = 1 << 6, DILLO_CLI_ERROR = 1 << 31 }; @@ -98,6 +100,9 @@ " -f, --fullwindow Start in full window mode."}, {"-l", "--local", 0, DILLO_CLI_LOCAL, " -l, --local Don't follow links for this URL(s)."}, + {"-g", "-geometry", 1, DILLO_CLI_GEOMETRY, + " -g, -geometry GEO Set initial window position where GEO is\n" + " <width>x<height>{+-}<x>{+-}<y>"}, {NULL, NULL, 0, 0, NULL} }; @@ -194,6 +199,8 @@ guint opt_flg; gint i; char **opt_argv = NULL; + gint xpos = D_GEOMETRY_DEFAULT_XPOS, ypos = D_GEOMETRY_DEFAULT_YPOS; + gint width = D_GEOMETRY_DEFAULT_WIDTH, height = D_GEOMETRY_DEFAULT_HEIGHT; /* set locale */ curr_locale = g_strdup(setlocale(LC_ALL, NULL)); @@ -226,6 +233,9 @@ case DILLO_CLI_FULLWINDOW: case DILLO_CLI_LOCAL: break; + case DILLO_CLI_GEOMETRY: + if ( XParseGeometry(opt_argv[0], &xpos, &ypos, &width, &height) ) + break; default: g_print("Error in command line options.\n"); return -1; @@ -265,9 +275,18 @@ if (options_got & DILLO_CLI_FULLWINDOW) prefs.fullwindow_start = TRUE; + /* override dillorc geometry */ + if (options_got & DILLO_CLI_GEOMETRY) { + prefs.width = width; + prefs.height = height; + prefs.xpos = xpos; + prefs.ypos = ypos; + } /* 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 != D_GEOMETRY_DEFAULT_XPOS) && (prefs.ypos != D_GEOMETRY_DEFAULT_YPOS) ) + 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 Sun Nov 30 22:48:36 2003 @@ -19,6 +19,8 @@ */ #include <glib.h> +#include <gtk/gtk.h> +#include <X11/Xlib.h> #include <sys/types.h> #include <sys/stat.h> #include <stdlib.h> @@ -104,14 +106,8 @@ /* assign value and exit successfully */ switch (symbol) { case DRC_TOKEN_GEOMETRY: { - gchar *ptr, *str = scanner->value.v_string; - gint width, height; - - if ( (ptr = strchr(str, 'x')) && (width = strtol(str,NULL,10)) && - (height = strtol(++ptr,NULL,10)) ){ - prefs.width = width; - prefs.height = height; - } + gchar *str = scanner->value.v_string; + XParseGeometry(str, &prefs.xpos, &prefs.ypos, &prefs.width, &prefs.height); } break; case DRC_TOKEN_PROXY: @@ -261,7 +257,7 @@ /* Specifies the chars which can be used in identifiers */ scanner->config->cset_identifier_nth = ( G_CSET_a_2_z - "~-_:&%#/.0123456789" + "~-_:&%#/.0123456789+" G_CSET_A_2_Z G_CSET_LATINS /*??? I don't know if we need these two */ G_CSET_LATINC /*??? */ @@ -329,6 +325,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 Sun Nov 30 15:29:57 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 -9999 +#define D_GEOMETRY_DEFAULT_YPOS -9999 #define DW_COLOR_DEFAULT_GREY 0xd6d6d6 #define DW_COLOR_DEFAULT_BLACK 0x000000 @@ -70,6 +72,8 @@ struct _DilloPrefs { gint width; gint height; + gint xpos; + gint ypos; DilloUrl *http_proxy; gchar *no_proxy; gchar **no_proxy_vec;

Nov. 30, 2003

Re: [Dillo-dev] How do you un-subscribe to this list

by Patrick Shanahan

* Ronald W. Henderson <rwhalb(a)nycap.rr.com> [11-30-03 12:27]: > Folks: > > I looked on this site and do not know how to un-subscribe to this list. > Thanks in advance... > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev Almost all mail-lists have subscribe/unsubscribe info in their headers, as does the one you posted: List-Unsubscribe: <http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev>, <mailto:dillo-dev-request@lists.auriga.wearlab.de?subject=unsubscribe> and the url listed at the bottom of every posting, included above. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Nov. 30, 2003

Re: [Dillo-dev] How do you un-subscribe to this list

by Mattias Östergren

On Sun, 30 Nov 2003 11:34:20 -0500 "Ronald W. Henderson" <rwhalb(a)nycap.rr.com> wrote: > Folks: > > I looked on this site and do not know how to un-subscribe to this list. > Thanks in advance... Go to the URL in the bottom of this mail and then fill in your email address in the box at the bottom of that page.

Nov. 30, 2003

How do you un-subscribe to this list

by Ronald W. Henderson

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

Nov. 30, 2003

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

by Jan Dittmer

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jorge Arellano Cid wrote: | | I understand. Maybe the "canonical" solution to this problem is | to add support for the geometry CLI option. | | That is: | | -geometry <width>x<height>{+-}<x>{+-}<y> | | Can you make the patch this way? | Here is a preliminary version. Only problem is that entering it in the dillorc doesn't work, because the parser doesn't recognize the + as part of a string resulting in these errors: dillorc:2: unexpected character `+', expected symbol dillorc:2: unexpected character `0', expected symbol dillorc:2: unexpected character `+', expected symbol dillorc:2: unexpected character `0', expected symbol dillorc:2: error: unexpected character `0', expected symbol So I tried changing - - "~-_:&%#/.0123456789" + "~-_:&%#/.0123456789+" in prefs.c, which doesn't work. How the parse be changed that it recognizes + as part of the value? Thanks, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/ygYdLqMJRclVKIYRApfZAJ4jb1fc3Dd8OrMB+Csgyekz74VikwCfaFv5 s7AZVApr+hS8dRtKK97kS0Y= =axoU -----END PGP SIGNATURE----- Common subdirectories: org/src/IO and jan/src/IO 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 Sun Nov 30 15:59:29 2003 @@ -21,6 +21,7 @@ #include <stdio.h> #include <gtk/gtk.h> +#include <X11/Xlib.h> #include <sys/types.h> #include <sys/stat.h> @@ -66,6 +67,7 @@ DILLO_CLI_HELP = 1 << 3, DILLO_CLI_VERSION = 1 << 4, DILLO_CLI_LOCAL = 1 << 5, + DILLO_CLI_GEOMETRY = 1 << 6, DILLO_CLI_ERROR = 1 << 31 }; @@ -98,6 +100,9 @@ " -f, --fullwindow Start in full window mode."}, {"-l", "--local", 0, DILLO_CLI_LOCAL, " -l, --local Don't follow links for this URL(s)."}, + {"-g", "-geometry", 1, DILLO_CLI_GEOMETRY, + " -g, -geometry GEO Set initial window position where GEO is\n" + " <width>x<height>{+-}<x>{+-}<y>"}, {NULL, NULL, 0, 0, NULL} }; @@ -194,6 +199,8 @@ guint opt_flg; gint i; char **opt_argv = NULL; + gint xpos = D_GEOMETRY_DEFAULT_XPOS, ypos = D_GEOMETRY_DEFAULT_YPOS; + gint width = D_GEOMETRY_DEFAULT_WIDTH, height = D_GEOMETRY_DEFAULT_HEIGHT; /* set locale */ curr_locale = g_strdup(setlocale(LC_ALL, NULL)); @@ -226,6 +233,11 @@ case DILLO_CLI_FULLWINDOW: case DILLO_CLI_LOCAL: break; + case DILLO_CLI_GEOMETRY: + if ( XParseGeometry(opt_argv[0], &xpos, &ypos, &width, &height) ) { + g_print("Setting geometry from CLI to %dx%d %d %d\n", width, height, xpos, ypos); + break; + } default: g_print("Error in command line options.\n"); return -1; @@ -265,9 +277,18 @@ if (options_got & DILLO_CLI_FULLWINDOW) prefs.fullwindow_start = TRUE; + /* override dillorc geometry */ + if (options_got & DILLO_CLI_GEOMETRY) { + prefs.width = width; + prefs.height = height; + prefs.xpos = xpos; + prefs.ypos = ypos; + } /* 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 != D_GEOMETRY_DEFAULT_XPOS) && (prefs.ypos != D_GEOMETRY_DEFAULT_YPOS) ) + 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 Sun Nov 30 16:00:14 2003 @@ -19,6 +19,8 @@ */ #include <glib.h> +#include <gtk/gtk.h> +#include <X11/Xlib.h> #include <sys/types.h> #include <sys/stat.h> #include <stdlib.h> @@ -104,14 +106,9 @@ /* assign value and exit successfully */ switch (symbol) { case DRC_TOKEN_GEOMETRY: { - gchar *ptr, *str = scanner->value.v_string; - gint width, height; - - if ( (ptr = strchr(str, 'x')) && (width = strtol(str,NULL,10)) && - (height = strtol(++ptr,NULL,10)) ){ - prefs.width = width; - prefs.height = height; - } + gchar *str = scanner->value.v_string; + XParseGeometry(str, &prefs.xpos, &prefs.ypos, &prefs.width, &prefs.height); + g_print("Setting geometry from rc to %dx%d %d %d\n", prefs.width, prefs.height, prefs.xpos, prefs.ypos); } break; case DRC_TOKEN_PROXY: @@ -261,7 +258,7 @@ /* Specifies the chars which can be used in identifiers */ scanner->config->cset_identifier_nth = ( G_CSET_a_2_z - "~-_:&%#/.0123456789" + "~-_:&%#/.0123456789+" G_CSET_A_2_Z G_CSET_LATINS /*??? I don't know if we need these two */ G_CSET_LATINC /*??? */ @@ -329,6 +326,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 Sun Nov 30 15:29:57 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 -9999 +#define D_GEOMETRY_DEFAULT_YPOS -9999 #define DW_COLOR_DEFAULT_GREY 0xd6d6d6 #define DW_COLOR_DEFAULT_BLACK 0x000000 @@ -70,6 +72,8 @@ struct _DilloPrefs { gint width; gint height; + gint xpos; + gint ypos; DilloUrl *http_proxy; gchar *no_proxy; gchar **no_proxy_vec;

Nov. 30, 2003

Re: [Dillo-dev] Re: about feedback

by Maurice McCarthy

Indan I actually thought you were a developer! Just to add to what others have said, your efforts are certainly appreciated in this quarter. As a complete numpty in programming little things like your install script are a joy to me. Look, copy and learn. Still have not managed to install Frank's tabs patch yet but I've by no means exhausted all I can do yet, so I'm not prepared to ask for help but want to plug away at it. I'll try to get your https patch in too. I suppose email suffers from what it fails to communicate, the nod of appreciation, the look of admiration, saying please and thank you etc. Well, thank you. Maurice

Nov. 29, 2003

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

by Jorge Arellano Cid

On Fri, 28 Nov 2003, Jan Dittmer wrote: > 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) I understand. Maybe the "canonical" solution to this problem is to add support for the geometry CLI option. That is: -geometry <width>x<height>{+-}<x>{+-}<y> Can you make the patch this way? Cheers Jorge.-

Nov. 29, 2003

Patch to allow setting of initial position

by Jan Dittmer

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;

Nov. 28, 2003

Re: about feedback

by Indan Zupancic

Hi, To clear up some things to avoid misunderstandings: I will continue keeping the https patch up to date, no matter what else I'll do. As there seems to be enough demand, I will update the installer once a while too. > Sometimes, it took quite some time before Jorge looked at the patches and > fixed or accepted (or rejected) them. I had zero feedback the last 3 weeks, not very motivating. Merely a short email to say that it will be looked at or that it has no priority would be appreciated, I mean, _any_ feedback is. Now it's just a black hole where you pour patches into. Don't forget that it's their program you spend time writing a patch for, but currently it feels like it's a privilege to have your patch integreted in Dillo, even expecting some feedback is asked too much for. May I come to the conclusion that I should spend my time on something else instead of wasting it on Dillo? If they aren't willing to spend 10 minutes writing a short email, why should I spend hours or even days writing and testing some Dillo patch? I don't expect the Dillo developers to just integrate my https patch or so, I wouldn't either without a lot testing and making sure it's stable, but I would expect that they give some feedback about it, I mean, it's their program, they wrote it, so I would expect that they know the code better, so could give good advice about pitfals etc. Or just simply say "no, we don't like your approach, let us keep using wget for https". But for the IO.c patch it's a different case, all it is is a cleanup of their code, naive as I am, I would expected them to want cleaner code, even if it's a small step like I made with the patch. > Anyways, that's how it works here. I got used to it. Working with one feedback per month is impossible if you want to do major IO cleanups as I want. > However, the core developers probably need to read all mails and keep track > with a whole lot more patches - therefore, even they may miss one or two > patches/suggestions. Whole lot more patches? Looking at the CVS activity then I'm not too sure. Also there is a reasonable amount of old patches for Dillo already: multiple https implementations (I only found the last one when I started on mine), UTF8 support, server/client mode, and other I can't remember/didn't found. And looking at the mailing list, they didn't get much feedback either. All those people hooked off as far as I can tell, except Frank. > So, please stay with the project ... hmmm ... some semi-serious > suggestion ;-) : do some christmas shopping, enjoy the holidays > and wait for the feedback from the developers ...:-) Christmas shopping? Need money for that I suppose. Enjoy the holidays? Have no job, so it's always holiday for me ;-). And don't know where you live, but christmas is just a commercial paradise here. > However, overall, I like the dpi idea. There are certain advantages: As with many things, the idea is good, the implementating isn't, IMHO. > - For me, it makes it rather easy to contribute, since I need to only > write a program and not to dig through dillo's code (if only I did > write more than my simplistic finger plugin ;-) ...) True, but if I look at the default plugins they're not as easy to make as it should be. > - The concept of extra processes instead of extra code has advantages : > - with the download plugin being a seperate process you can even log > out of X while the download continues (e.g. over night on dial-up). That is true. I don't know if you noticed, but if you want to use the current download plugin, you need to start up 3 processes... First, the dpid, then the download dpi, which in turn starts wget. I'm so naive to think it could be only wget, with a simple "handle this protocol with this program with this parameters in this way" system. This way you could also startup your favourite email program when encountering mailto:, to give just one example. Don't forget that there is specific code in Dillo to handle certain plugins like the bookmark and download plugins. The plugins aren't really standalone. Sure, it's not finished yet, but the current dpi system can't solve that problem. What I would do is make a clear library plugin api, then you can implement the download and bookmark GUI in a library, and let the library start up wget. You can even implement a library plugin that handels the dpi plugins, instead of adding the code to Dillo's core as now happened (I mean moving the dpi code into a library plugin). This way you can have relative simple and small library plugins that don't do much, which let external programs like wget do the real work. Or add the features directly in the library plugin, whatever you want. > - the bookmark plugin allows for a real bookark server ! This is something > I am contemplating about : wouldn't it be cool if you could access the > same bookamrks from different machines via a sophisticated bookmark server > ? No, it doesn't. Not with the current dpi system anyway. As I said in an earlier email, the bookmark plugin should probably be a real, standalone daemon, so that it can also be used with other browser, from different pc's. It can even be hosted by some site, so that wherever you go, you can get your bookmarks :). Of course Dillo could have special support for it, so that it's easier to add bookmarks, and that it's started when it isn't running yet, but the main point is that the bookmark server won't be a dpi plugin, or can't be because you can't use unix sockets as the current dpi system uses now (which is fine for a plugin system, but not when you want to connect to non-local pc's). Greetings, Indan

Nov. 28, 2003

about feedback was: Re: [Dillo-dev] [patch] Cleanup of IO.c

by Andreas Schweitzer

Hi, I post this to the list, so that some other possible future contributor that might get frustrated can find it in the archive :-) > I feel sad and frustrated because of the lack of feedback from the Dillo > developers. I tried to improve Dillo, to add some extra features. Dillo is a > nice browser and I thought that spending my time on it would be appreciated, > but it seems I was wrong. I give up, I'm not going to waste my time on > improving Dillo while all efforts are just ignored or told to be useless > because of the "that mess is fine as it is now" attitude. If the neutral and > obviously (somehow I start doubting that now) improving IO cleanup patch is > ignored, then what chance do I have with cleaning up the CCC horror... I can totally understand you. I, too, sent in patches at times. Not as big as yours, some were useful, some were not. Sometimes, it took quite some time before Jorge looked at the patches and fixed or accepted (or rejected) them. The first time, I was very excited once I submitted the patch. But as time went by and I did not hear anything, I got disappointed, until I finally got feedback - life was good again ;-) ... Anyways, that's how it works here. I got used to it. Also, since Frank and you started contributing great patches, traffic went up quite a bit. I think it's ok, since I skip some threads that I'm not interested in. :-) However, the core developers probably need to read all mails and keep track with a whole lot more patches - therefore, even they may miss one or two patches/suggestions. So, please stay with the project ... hmmm ... some semi-serious suggestion ;-) : do some christmas shopping, enjoy the holidays and wait for the feedback from the developers ...:-) > To give you an idea how bad it is: Unfortunatly I am rather a happy user than a real developer. So, I just read and say "aha" ... Hence, I also could not comment on your cleanup of IO.c > Worst is, making a dpi isn't as simple as making a CGI, as it should be. And > of course the whole dpid construction makes no sense. not really anyway: you > can find all the dpi's the same way as you find the dpid... Sure, dpid has > some minor advantages, but everyhting has _some_ advantages. Currently, I'm just watching the changes to the dpi infrastructure. Sometimes, I too think "hopefully this is not getting too bloated, with two many interfaces". However, overall, I like the dpi idea. There are certain advantages: - For me, it makes it rather easy to contribute, since I need to only write a program and not to dig through dillo's code (if only I did write more than my simplistic finger plugin ;-) ...) - The concept of extra processes instead of extra code has advantages : - with the download plugin being a seperate process you can even log out of X while the download continues (e.g. over night on dial-up). - the bookmark plugin allows for a real bookark server ! This is something I am contemplating about : wouldn't it be cool if you could access the same bookamrks from different machines via a sophisticated bookmark server ? Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Nov. 28, 2003

Re: [Dillo-dev] [patch] Cleanup of IO.c

by Indan Zupancic

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

Nov. 27, 2003

Re: [Dillo-dev] [patch] Cleanup of IO.c

by Diego Sáenz

In few words: more code and less words. Come on to code it to have something to compare. I will help you if you want and i think that more people in the list will help too. About feedback from developers they are always like that. I think they are busy. I do not understand your disapointing very well and maybe because that i sound rude, excuseme then. Diego. "Indan Zupancic" <indan(a)nul.nu> escribio: > Hello, > > The patch was downloaded 14 times, and zero feedback... Great. I > wanted to cleanup http.c in a similar way, but never mind. > > I feel sad and frustrated because of the lack of feedback from the > Dillo developers. I tried to improve Dillo, to add some extra > features. Dillo is a nice browser and I thought that spending my time > on it would be appreciated, but it seems I was wrong. I give up, I'm > not going to waste my time on improving Dillo while all efforts are > just ignored or told to be useless because of the "that mess is fine > as it is now" attitude. If the neutral and obviously (somehow I start > doubting that now) improving IO cleanup patch is ignored, then what > chance do I have with cleaning up the CCC horror... > > To give you an idea how bad it is: > > There are at least 24 ways of calling a ccc function. That is a > conservative estimation, because I only counted the possible parameter > combinations(values, types), you still need to know which variant of > the many you need to use with a certain module. Also I counted only > the ccc functions of the IO, cache, file, http and dns module, I > didn't count the dpi and capi modules(just didn't come that far). > > This mess means that modules can't communicate transparantly with > eachother, because they need to know exactly which data to give, > implicating that they need to know with which module they're talking. > That makes the whole CCC construction worthless, because one of it > goals, or so I guess, was to have a chain like communication where > linked elements could do their's stuff and notify the next element > without knowing anything specific about eachother. With the current > situation the CCC structure only adds unnecessary complexity to the > overall code, obfuscating it. > > If that's what you want, fine, but then say so, instead of saying that > it's hard to replace. Yes, duh, you made a spaghetti mountain, of > course it's hard to clear that up. I truly hope that the rest of Dillo > is cleaner, and from what I saw of it, the GUI part doesn't look that > bad. > > Next grief: DPI's. > > What was meant like a simple plugin system turned out to become the > sauce over the spaghetti, to stay with the previous metaphor. It seems > like the cache api code handles dpi's differently, at least there is > plenty dpi specific code in the capi.c file, so it seems like it's in > the wrong place. I mean, if it's not part of the cache api, then what > is it doing in that file? capi.c has even it's own CCC function only > for dpi's, so an extra module in a wrapper?? > > Worst is, making a dpi isn't as simple as making a CGI, as it should > be. And of course the whole dpid construction makes no sense. not > really anyway: you can find all the dpi's the same way as you find the > dpid... Sure, dpid has some minor advantages, but everyhting has > _some_ advantages. > > All the dpi code (not including bookmarks.c) is 14K big, just imagine > what you could implement with so much code (native ftp support comes > into mind). Not even talking about how much resources the dpi's use, > because they have such an awkward interface and need to do things that > Dillo already could do, duplicating code and features. > > I'm aware that certain people already wasted too much time on the > current dpi code, so it has zero chance of being changed, I'm not so > naive to think it would. I just give my oppinion on it. I had put my > hope on the IO/CCC mess. > > Sigh, if only Dillo went the GTK2 way, then I could say goodbye > without trouble, but now it seems like Dillo will use FLTK it's even > more depressing. > > --- > > Oh well, enough rambling, if someone wants an updated version of the > installer, then say so. I won't do much with the https patch, because > as it is now it can't be improved much without cleaning up IO, CCC > or/and http, or at least without merging the IOData structures, so > more than synching with CVS and tiny changes won't happen. > > Good luck and take care, > > Indan > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 27, 2003

Re: [Dillo-dev] [patch] Cleanup of IO.c

by Mike Eriksen

On Thu, 27 Nov 2003, Patrick Shanahan wrote: > * Indan Zupancic <indan(a)nul.nu> [11-27-03 13:42]: > > I'm not qualified to comment about the part snipped... The same goes for me too. > > ------ > > > > Oh well, enough rambling, if someone wants an updated version of the > > installer, then say so. I won't do much with the https patch, because > > as it is now it can't be improved much without cleaning up IO, CCC > > or/and http, or at least without merging the IOData structures, so more > > than synching with CVS and tiny changes won't happen. > > I would appreciate an updated version of the installer. > > Thankyou for your contributions. Please reconsider. I too would very much like an updated installer. And I would be really grateful if you would consider to maintain you HTTPS patch as well. I can understand you are disapointed with the lack of feed back from the official developers, but Dillo *is* a very conservative project. Look at Franks frame/tab patch - it has been around for ages and is still "just" an unofficial patch. I would be sad if you leave Dillo all together. I not only need Dillo+frames+HTTPS for myself, but as you can see from my signature, I'm involved in a linux based thin client project and a light web-mail capable web browser is a killer-app to us! And would make quite an impact on the Dillo user base too. Please reconsider. Mike -- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS

Nov. 27, 2003

Re: [Dillo-dev] [patch] Cleanup of IO.c

by Patrick Shanahan

* Indan Zupancic <indan(a)nul.nu> [11-27-03 13:42]: I'm not qualified to comment about the part snipped... > ------ > > Oh well, enough rambling, if someone wants an updated version of the > installer, then say so. I won't do much with the https patch, because > as it is now it can't be improved much without cleaning up IO, CCC > or/and http, or at least without merging the IOData structures, so more > than synching with CVS and tiny changes won't happen. I would appreciate an updated version of the installer. Thankyou for your contributions. Please reconsider. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Nov. 27, 2003

Re: [Dillo-dev] [patch] Cleanup of IO.c

by Indan Zupancic

Hello, The patch was downloaded 14 times, and zero feedback... Great. I wanted to cleanup http.c in a similar way, but never mind. I feel sad and frustrated because of the lack of feedback from the Dillo developers. I tried to improve Dillo, to add some extra features. Dillo is a nice browser and I thought that spending my time on it would be appreciated, but it seems I was wrong. I give up, I'm not going to waste my time on improving Dillo while all efforts are just ignored or told to be useless because of the "that mess is fine as it is now" attitude. If the neutral and obviously (somehow I start doubting that now) improving IO cleanup patch is ignored, then what chance do I have with cleaning up the CCC horror... To give you an idea how bad it is: There are at least 24 ways of calling a ccc function. That is a conservative estimation, because I only counted the possible parameter combinations (values, types), you still need to know which variant of the many you need to use with a certain module. Also I counted only the ccc functions of the IO, cache, file, http and dns module, I didn't count the dpi and capi modules (just didn't come that far). This mess means that modules can't communicate transparantly with eachother, because they need to know exactly which data to give, implicating that they need to know with which module they're talking. That makes the whole CCC construction worthless, because one of it goals, or so I guess, was to have a chain like communication where linked elements could do their's stuff and notify the next element without knowing anything specific about eachother. With the current situation the CCC structure only adds unnecessary complexity to the overall code, obfuscating it. If that's what you want, fine, but then say so, instead of saying that it's hard to replace. Yes, duh, you made a spaghetti mountain, of course it's hard to clear that up. I truly hope that the rest of Dillo is cleaner, and from what I saw of it, the GUI part doesn't look that bad. Next grief: DPI's. What was meant like a simple plugin system turned out to become the sauce over the spaghetti, to stay with the previous metaphor. It seems like the cache api code handles dpi's differently, at least there is plenty dpi specific code in the capi.c file, so it seems like it's in the wrong place. I mean, if it's not part of the cache api, then what is it doing in that file? capi.c has even it's own CCC function only for dpi's, so an extra module in a wrapper?? Worst is, making a dpi isn't as simple as making a CGI, as it should be. And of course the whole dpid construction makes no sense. not really anyway: you can find all the dpi's the same way as you find the dpid... Sure, dpid has some minor advantages, but everyhting has _some_ advantages. All the dpi code (not including bookmarks.c) is 14K big, just imagine what you could implement with so much code (native ftp support comes into mind). Not even talking about how much resources the dpi's use, because they have such an awkward interface and need to do things that Dillo already could do, duplicating code and features. I'm aware that certain people already wasted too much time on the current dpi code, so it has zero chance of being changed, I'm not so naive to think it would. I just give my oppinion on it. I had put my hope on the IO/CCC mess. Sigh, if only Dillo went the GTK2 way, then I could say goodbye without trouble, but now it seems like Dillo will use FLTK it's even more depressing. --- Oh well, enough rambling, if someone wants an updated version of the installer, then say so. I won't do much with the https patch, because as it is now it can't be improved much without cleaning up IO, CCC or/and http, or at least without merging the IOData structures, so more than synching with CVS and tiny changes won't happen. Good luck and take care, Indan

Nov. 27, 2003

Re: [Dillo-dev] patch: toggle force_my_colors

by Paul Pelzl

On Wed, Nov 26, 2003 at 02:06:20PM +0100, Frank de Lange wrote: > >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 > > > > > I can add this to the tab/frame patch if you want, so you don't have to > produce two different versions. I would modify it slightly, so the > option works for all frames (not just the one in which the menu was > popped up). I would also add a DILLO_COMMAND, and I move the menu option > (the content menu is getting to big I think). OK Frank, I'll leave it in your capable hands. :-) Paul

Nov. 26, 2003

Re: [Dillo-dev] patch: toggle force_my_colors

by Frank de Lange

Paul Pelzl wrote: >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 > > I can add this to the tab/frame patch if you want, so you don't have to produce two different versions. I would modify it slightly, so the option works for all frames (not just the one in which the menu was popped up). I would also add a DILLO_COMMAND, and I move the menu option (the content menu is getting to big I think). 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." ]

Nov. 26, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Frank de Lange

Indan Zupancic wrote: >Random site that doesn't work (thanks google): >http://www.public.iastate.edu/~stvoh/homepage.html > >"works" with the normal Dillo, but renders nothing with the frames patch >(non-standard frames?). > > <HTML> <HEAD> <TITLE> <FRAMESET ROWS="... etc. Missing title close tag (</TITLE>). In general Dillo does not try its best to render bad HTML, but missing tag problems are so common that I think this should be fixed. I'll have a look at it when I find some time... 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." ]

Nov. 26, 2003

Re: [Dillo-dev] patched dillo via Arch

by Grigory Bakunov

Paul Pelzl wrote: >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. > > No. Please don't stop! It's very nice idea. For all GNU Arch novices short tutorial how to grab this version from this archive: % tla register-archive pelzlpj(a)eecs.umich.edu--2003 ftp://pelzlpj.dyndns.org/pub/paul/tla/2003 % tla my-default-archive pelzlpj(a)eecs.umich.edu--2003 % tla get dillo--tabframe-pelzl--16.0 After this magical commands you get patched source with all what you need. -- .............................................................. IRC: irc.freenode.net #asplinux Grigory Bakunov ICQ: 51369901 ASPLinux Development Team Life would be so much easier if we could just look at the source code.

Nov. 26, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Frank de Lange

Indan Zupancic wrote: >Other issues: > >When resizing a vertical frame, a horizontal scrollbar is rendered in a >blinking way, even when it's not needed. This seems to appear only if a >scrollbar will be rendered when the frame doesn't fit, so when you'll never >see one it won't blink while resizing either. I guess this is the case with >horizontal frames too, but didn't find one to test it with (example url: >http://members.ams.chello.nl/wasscher/weer/) Should be easy to fix, I guess >initializing the size to 0xffffffff or something instead of 0 at the right >place could fix it, if it isn't a GTK issue. > This is explained in dw_gtk_viewport.c (Dw_gtk_viewport_calc_size): /* * Determine the size hints for the Dw widget. This is a bit * tricky, because you must know if scrollbars are visible or * not, which depends on the size of the Dw widget, which then * depends on the hints. The idea is to test several * configurations, there are four of them, from combining the * cases horizontal/vertical scrollbar visible/invisible. * >>> * For optimization, the horizontal scrollbar is currently not * regarded, the height hint is always the same, as if the * scrollbar was allways visible. In future, this may be * implemented correctly, by using the minimal width to optimize * most cases. (Minimal widths will also be used by tables.) ... */ Maybe it is time to 'implement this correctly'. I am not that bothered by the blinking scrollbar, but if there is consencus that this should be fixed I guess it should be fixed... 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." ]

Nov. 26, 2003

Re: [Dillo-dev] patched dillo via Arch

by Frank de Lange

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." ]

Nov. 26, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Frank de Lange

Indan Zupancic wrote: >Hi, > >Things I noticed: > >Frames with zero border aren't supported. > > Known problem, Dw (actually it is GtkDwScrolledFrame) is not able to draw borderless frames (this was in the README for many releases, but I got tired of repeating it so dropped it after README-11). As I did not want to hack to much around the widget (Sebastian's domain) I did not change this. Yet. >When there is a scrollbar in a frame it has a fat border to the left, making >it a little bit ugly, even wider than it already is, and making it look more a >part of the right frame because there is no such border at that side (see >www.xenon.nl for what I mean, or any other site with similar frames). > > Also a widget issue, but it is definitely more visible (and annoying) in framed document. >Reload doesn't reload all the frames. Known issue, but still annoying. :) > > Thus far I have not made any special-case exceptions for framed documents wrt. history etc. As there seem to be many requests for this, I think I can not get around this... Should not be hard (just have reload etc. work on document subtrees instead of single documents) but has not been done yet. >Other issues: > >When resizing a vertical frame, a horizontal scrollbar is rendered in a >blinking way, even when it's not needed. This seems to appear only if a >scrollbar will be rendered when the frame doesn't fit, so when you'll never >see one it won't blink while resizing either. I guess this is the case with >horizontal frames too, but didn't find one to test it with (example url: >http://members.ams.chello.nl/wasscher/weer/) Should be easy to fix, I guess >initializing the size to 0xffffffff or something instead of 0 at the right >place could fix it, if it isn't a GTK issue. > > Which it might just be... or not. I've played around with some configurations way back when I started this patch, but have not given it any attention afterwards. I'll see if I can find something to make it look less blinky (maybe hide scrollbars when resizing?). >Also the history seems very broken/buggy with framed webpages. Only thing that >worked for me on one page was forward/backward for the main frame, and for >most other sites there doesn't seem to be any history for frames at all, even >right-clicking gives no forward/backward options (know issue I assume). > > The latest patch (version 16) has navigation menus for all frames, in the 'This Frame...' submenu. These work fine AFAIK, if they don't please tell me what breaks where and I'll have a look at it. Individual document history (where 'document' signifies a single display frame/window) should work fine as it is now; adding cascaded reload and possibly some history update for frmae navigation should do the trick I guess? >Another one: Could you please edit your version of capi.c slightly, so that I >don't have to make a seperate version of my patch? Just an extra #ifndef HTTPS >/ #endif somewhere, so it won't affect your code at all. > > I'll add it to the next 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." ]

Nov. 25, 2003

patched dillo via Arch

by Paul Pelzl

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

Nov. 25, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Indan Zupancic

Other issues: When resizing a vertical frame, a horizontal scrollbar is rendered in a blinking way, even when it's not needed. This seems to appear only if a scrollbar will be rendered when the frame doesn't fit, so when you'll never see one it won't blink while resizing either. I guess this is the case with horizontal frames too, but didn't find one to test it with (example url: http://members.ams.chello.nl/wasscher/weer/) Should be easy to fix, I guess initializing the size to 0xffffffff or something instead of 0 at the right place could fix it, if it isn't a GTK issue. Also the history seems very broken/buggy with framed webpages. Only thing that worked for me on one page was forward/backward for the main frame, and for most other sites there doesn't seem to be any history for frames at all, even right-clicking gives no forward/backward options (know issue I assume). Side note: Paul Pelzl's toggle force-my-colours patch seems to work fine. Another one: Could you please edit your version of capi.c slightly, so that I don't have to make a seperate version of my patch? Just an extra #ifndef HTTPS / #endif somewhere, so it won't affect your code at all. The diff: @@ -253,15 +253,17 @@ gint a_Capi_open_url(DilloWeb *web, CA_C (a_Capi_url_read(web->url, &sz) == NULL || (URL_FLAGS(web->url) & URL_E2EReload)) ) { cmd = g_strdup_printf("<dpi cmd='open_url' url='%s'>", url_str); a_Capi_dpi_send_cmd(web, web->dd, cmd, "ftp", 1); g_free(cmd); +#ifndef HTTPS } else if (g_strncasecmp(url_str, "https:/", 7) == 0 && !Call && (a_Capi_url_read(web->url, &sz) == NULL || (URL_FLAGS(web->url) & URL_E2EReload)) ) { cmd = g_strdup_printf("<dpi cmd='open_url' url='%s'>", url_str); a_Capi_dpi_send_cmd(web, web->dd, cmd, "https", 1); g_free(cmd); +#endif } else { return a_Cache_open_url(web, Call, CbData); I would be grateful if you add this change to the next version of your patch. Greetings, Indan

Nov. 25, 2003

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

by Andreas Schweitzer

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). Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Nov. 25, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Indan Zupancic

Hi, Things I noticed: Frames with zero border aren't supported. When there is a scrollbar in a frame it has a fat border to the left, making it a little bit ugly, even wider than it already is, and making it look more a part of the right frame because there is no such border at that side (see www.xenon.nl for what I mean, or any other site with similar frames). Reload doesn't reload all the frames. Known issue, but still annoying. :) Random site that doesn't work (thanks google): http://www.public.iastate.edu/~stvoh/homepage.html "works" with the normal Dillo, but renders nothing with the frames patch (non-standard frames?). I will change my installer setup, I'll just use your patched Dillo code and apply my own patches on it, or download Dillo CVS and apply all the patches on it and make a tarball. I figured out that that's less work and better because people don't need to have CVS. This is such an obvious thing to do, and still I didn't think of it, sigh... Greetings, Indan

Nov. 25, 2003

kbnav bugs anyone?

by Frank de Lange

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." ]

Nov. 25, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Frank de Lange

Melvin Hadasht wrote: >Pasting from a web page to the URL entry does not work. (But pasting to >an entry field in the web page or in another X app works). > > This is related to the new focus-related code: on grab-focus the location bar (and the search entry fields) select their contents. This causes the selection in the page to be destroyed. I'll see if I can find a way around this problem. >It looks also that selecting a link, we cannot paste the text of the link >(not the link itself). I don't have a non-patched dillo anymore to test if this >is due to your patch or not. > > This is solved. It was, as I expected, a missing update to selection.c. A new macro (DW_CONTENT_ALL(content.type)) can be used in situations where the DW_CONTENT_FOCUSABLE type should be filtered out (eg. switch statements). Fix in next release of patch, if you want to have the fix now apply the short patch which is attached to this message to a PATCHED dillo tree. 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_patched/src/selection.c.org 2003-11-25 12:39:16.119342032 +0100 +++ dillo_patched/src/selection.c 2003-11-25 12:40:26.743605512 +0100 @@ -568,7 +568,8 @@ (cmp = a_Dw_ext_iterator_compare (i, b)) <= 0; a_Dw_ext_iterator_next (i), start = FALSE) { si = i->stack[i->stack_top]; - switch (si->content.type) { + switch (si->content.type & + (DW_CONTENT_ALL ^ DW_CONTENT_FOCUSABLE)) { case DW_CONTENT_TEXT: if (start) { tmp = g_strndup(si->content.data.text + a_char,

Nov. 25, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Frank de Lange

Melvin Hadasht wrote: >Pasting from a web page to the URL entry does not work. (But pasting to >an entry field in the web page or in another X app works). > > Noticed. Might have something to do with the focus-related code. I'll see what I can do about this.. >It looks also that selecting a link, we cannot paste the text of the link >(not the link itself). I don't have a non-patched dillo anymore to test if this >is due to your patch or not. > > I noticed this as well - even before the release - but forgot to fix it. The fix should be really simple if it is what I think it is: a case of the selection code (or ext_iterator) not knowing how to handle combined content types. Should be fixed in next release. 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." ]

Nov. 25, 2003

Re: [Dillo-dev] [PATCH] HTTPS version 2.

by Patrick Shanahan

* Indan Zupancic <indan(a)nul.nu> [11-24-03 20:07]: > > I updated my https patch, can get it from: Patch fails for me: SuSE 8.1 dillo cvs 20031124 13:18gmt Hunk #1 FAILED at 256. 1 out of 1 hunk FAILED -- saving rejects to file src/capi.c.rej patching file src/nav.c src/capi.c.rej: *************** *** 256,267 **** a_Capi_dpi_send_cmd(web, web->bw, cmd, "ftp", 1); g_free(cmd); } else if (g_strncasecmp(url_str, "https:/", 7) == 0 && !Call && (a_Capi_url_read(web->url, &sz) == NULL || (URL_FLAGS(web->url) & URL_E2EReload)) ) { cmd = g_strdup_printf("<dpi cmd='open_url' url='%s'>", url_str); a_Capi_dpi_send_cmd(web, web->bw, cmd, "https", 1); g_free(cmd); } else { return a_Cache_open_url(web, Call, CbData); --- 256,269 ---- a_Capi_dpi_send_cmd(web, web->bw, cmd, "ftp", 1); g_free(cmd); + #ifndef HTTPS } else if (g_strncasecmp(url_str, "https:/", 7) == 0 && !Call && (a_Capi_url_read(web->url, &sz) == NULL || (URL_FLAGS(web->url) & URL_E2EReload)) ) { cmd = g_strdup_printf("<dpi cmd='open_url' url='%s'>", url_str); a_Capi_dpi_send_cmd(web, web->bw, cmd, "https", 1); g_free(cmd); + #endif } else { return a_Cache_open_url(web, Call, CbData); tks, -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Nov. 25, 2003

[PATCH] HTTPS version 2.

by Indan Zupancic

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...

Nov. 25, 2003

Re: Browser tabs vs. window manager tabs, again (Was: [Dillo-dev] Proposal: United Dillo)

by Indan Zupancic

Just think about all those people that want to use Dillo in a kiosk running no window manager at all. ;)

Nov. 24, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Melvin Hadasht

Hi, > The next version (16) of my tab/frame/keyboard navigation patch is > ready (see bottom of this message for download instructions). Pasting from a web page to the URL entry does not work. (But pasting to an entry field in the web page or in another X app works). It looks also that selecting a link, we cannot paste the text of the link (not the link itself). I don't have a non-patched dillo anymore to test if this is due to your patch or not. Thanks for your work: it really suits my browsing habits (incremental search, no dialog for searching, keywords, keyboard navigation). Concerning the keyboard navigation, thanks for adding support to open the menu popup from the keyboard. Concerning the accessibility, I must say I have no experience, but adding keyboard navigation is surely a real improvement: it is n°1 on the Checkpoints for User Agent Accessibility Guidelines 1.0 at: http://www.w3.org/TR/UAAG10/uaag10-chktable.html. -- Melvin Hadasht

Nov. 24, 2003

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

by Victor Sahlstedt

* Jorge Arellano Cid (jcid(a)dillo.org) wrote: > If you add a simple way to test whether gcc accepts the warning > option, in configure.in, it'd be ok. As he's hardly the only one still using 2.95.x it would probably be a good idea to have that testing-procedure in the main configure.in - or do you have any objection? - Victor

Nov. 24, 2003