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

Re: [Dillo-dev] the #anchor links not going to history

by Frank Gevaerts

On Tue, Jun 10, 2003 at 12:03:05PM +0200, Jan Stary wrote: > Hello, > > there seems to be the following problem with the history of browsing: > > If first.html contains a link <a href="second.html">, then clicking on it > gets you to second.html - OK. If second.html contains a link <a > href=#"anchor"> pointing to a place in second.html, then clicking on the > link gets you to #anchor - OK. But then, when you press [,] to go back, > you get back to first.thml. > > Definitely, you want [,] to get you back to the beginning of second.html. > > It looks like the #anchor links don't go into the 'stack of previous > places'. I don't mean that second.html#anchor should be remembered as a > unique record in browser history (e.g. for future runs, after dillo > supports it), but definitely it's a step 'forward from second.html', > so going 'back' should go to second.html, not first.html. I have a patch for 0.6.6 that does this. I don't know if it still applies, but I'm appending it here. Note that I'm not sure this is/was the right way to do it. Frank diff -ur dillo-0.6.6/src/history.c dillo-0.6.6.fg/src/history.c --- dillo-0.6.6/src/history.c 2002-04-10 02:53:58.000000000 +0200 +++ dillo-0.6.6.fg/src/history.c 2002-08-16 17:58:55.000000000 +0200 @@ -38,7 +38,7 @@ gint i, idx; for (i = 0; i < history_size; ++i) - if (a_Url_cmp(history[i].url, url) == 0) + if (a_Url_cmp(history[i].url, url) == 0 && URL_STRCAMP_EQ(history[i].url->fragment,url->fragment)) return i; idx = history_size; diff -ur dillo-0.6.6/src/nav.c dillo-0.6.6.fg/src/nav.c --- dillo-0.6.6/src/nav.c 2002-04-10 03:10:16.000000000 +0200 +++ dillo-0.6.6.fg/src/nav.c 2002-08-16 20:34:52.000000000 +0200 @@ -176,7 +176,7 @@ MustLoad = ForceReload || !old_url; if (old_url){ MustLoad |= a_Url_cmp(old_url, url); - MustLoad |= strcmp(URL_STR(old_url), a_Interface_get_location_text(bw)); + MustLoad |= strcmp(URL_STR_NOANCHOR(old_url), a_Interface_get_location_text(bw)); } if ( MustLoad ) { @@ -195,9 +195,19 @@ a_Interface_set_cursor(bw, GDK_LEFT_PTR); } - /* Jump to #anchor position */ + /* Push on stack and jump to #anchor position */ if (URL_FRAGMENT_(url)) { - /* todo: push on stack */ + gint idx; + DilloUrl *hist_url=a_Url_dup(url); + + /* unset E2EReload before adding this url to history */ + a_Url_set_flags(hist_url, URL_FLAGS(hist_url) & ~URL_E2EReload); + idx = a_History_add_url(hist_url); + Nav_stack_add(bw, idx); + Nav_stack_clean(bw); + a_Interface_set_button_sens(bw); + a_Url_free(hist_url); + a_Dw_gtk_scrolled_window_set_anchor( GTK_DW_SCROLLED_WINDOW(bw->docwin), URL_FRAGMENT_(url)); } diff -ur dillo-0.6.6/src/url.c dillo-0.6.6.fg/src/url.c --- dillo-0.6.6/src/url.c 2002-04-10 03:10:28.000000000 +0200 +++ dillo-0.6.6.fg/src/url.c 2002-08-16 20:20:59.000000000 +0200 @@ -56,19 +56,47 @@ if (!url->url_string) { url->url_string = g_string_sized_new(60); - g_string_sprintf( - url->url_string, "%s%s%s%s%s%s%s%s%s%s", - url->scheme ? url->scheme : "", - url->scheme ? ":" : "", - url->authority ? "//" : "", - url->authority ? url->authority : "", - (url->path && url->path[0] != '/' && url->authority) ? "/" : "", - url->path ? url->path : "", - url->query ? "?" : "", - url->query ? url->query : "", - url->fragment ? "#" : "", - url->fragment ? url->fragment : ""); } + g_string_sprintf( + url->url_string, "%s%s%s%s%s%s%s%s%s%s", + url->scheme ? url->scheme : "", + url->scheme ? ":" : "", + url->authority ? "//" : "", + url->authority ? url->authority : "", + (url->path && url->path[0] != '/' && url->authority) ? "/" : "", + url->path ? url->path : "", + url->query ? "?" : "", + url->query ? url->query : "", + url->fragment ? "#" : "", + url->fragment ? url->fragment : ""); + + return url->url_string->str; +} + +/* + * Return the url as a string, without the anchor part. + * (initializing 'url_string' camp if necessary) + */ +gchar *a_Url_str_noanchor(const DilloUrl *u) +{ + /* Internal url handling IS transparent to the caller */ + DilloUrl *url = (DilloUrl *) u; + + g_return_val_if_fail (url != NULL, NULL); + + if (!url->url_string) { + url->url_string = g_string_sized_new(60); + } + g_string_sprintf( + url->url_string, "%s%s%s%s%s%s%s%s", + url->scheme ? url->scheme : "", + url->scheme ? ":" : "", + url->authority ? "//" : "", + url->authority ? url->authority : "", + (url->path && url->path[0] != '/' && url->authority) ? "/" : "", + url->path ? url->path : "", + url->query ? "?" : "", + url->query ? url->query : ""); return url->url_string->str; } diff -ur dillo-0.6.6/src/url.h dillo-0.6.6.fg/src/url.h --- dillo-0.6.6/src/url.h 2002-04-10 03:05:43.000000000 +0200 +++ dillo-0.6.6.fg/src/url.h 2002-08-16 20:25:02.000000000 +0200 @@ -56,6 +56,7 @@ #define URL_ALT_(u) u->alt #define URL_POS_(u) u->scrolling_position #define URL_STR_(u) a_Url_str(u) +#define URL_STR_NOANCHOR_(u) a_Url_str_noanchor(u) /* * Access methods that always return a string: @@ -75,6 +76,7 @@ #define URL_ALT(u) NPTR2STR(URL_ALT_(u)) #define URL_POS(u) URL_POS_(u) #define URL_STR(u) NPTR2STR(URL_STR_(u)) +#define URL_STR_NOANCHOR(u) NPTR2STR(URL_STR_NOANCHOR_(u)) @@ -117,6 +119,7 @@ gint flags, gint pos); void a_Url_free(DilloUrl *u); gchar *a_Url_str(const DilloUrl *url); +gchar *a_Url_str_noanchor(const DilloUrl *url); const gchar *a_Url_hostname(const DilloUrl *u); DilloUrl* a_Url_dup(const DilloUrl *u); gint a_Url_cmp(const DilloUrl* A, const DilloUrl* B);

June 10, 2003

the #anchor links not going to history

by Jan Stary

Hello, there seems to be the following problem with the history of browsing: If first.html contains a link <a href="second.html">, then clicking on it gets you to second.html - OK. If second.html contains a link <a href=#"anchor"> pointing to a place in second.html, then clicking on the link gets you to #anchor - OK. But then, when you press [,] to go back, you get back to first.thml. Definitely, you want [,] to get you back to the beginning of second.html. It looks like the #anchor links don't go into the 'stack of previous places'. I don't mean that second.html#anchor should be remembered as a unique record in browser history (e.g. for future runs, after dillo supports it), but definitely it's a step 'forward from second.html', so going 'back' should go to second.html, not first.html. Cheers Jan

June 10, 2003

Re: [Dillo-dev] entities display - lost attach

by Nikita V. Borodikhin

Lost attach only Nikita

June 9, 2003

Re: [Dillo-dev] entities display

by Nikita V. Borodikhin

Hello Jorge ! On Fri, 30 May 2003 12:52:04 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > Is there any > > reason to leave table without representations in place and add > > a new one _with_ them which differs only in representations field > > and(possible) bigger number of entities ? > > Maybe not, but I didn't suggest _that_ table. > > I thought that although implicit it was clear, but it seems > that character handling code is always harder than it seems! > > The main reason for separating the tables was to make clear > what was the workaround and what the code to be used with UCS in > the future. > > The other is that the second table can be ordered by isocode > and thus allow for a bin search instead of the slow linear search > the patch uses. OK, Jorge, you convinced me. Having a separate table is really better. New patch (against current CVS) is attached. Yours, Nikita.

June 9, 2003

Re: [Dillo-dev] can't connect remote host!!

by Andreas Kemnade

On Mon, 09 Jun 2003 15:46:01 +0800 ronnie <wang_xq(a)neusoft.com> wrote: > hi all! > I'm new user dillo and the first question is the dillo can't connect remote host .I have set the file "dillorc" in the path ~/.dillo/dillorc : > # Set the proxy information for http > #http_proxy=http://localhost:8080/ > http_proxy=http://localhost:8080/-------which need username and passwd; Does dillo really support authentication in that way? AFAIK you need an additional patch. Perhaps someone can remember the url of that patch. Greetings Andreas Kemnade

June 9, 2003

can't connect remote host!!

by ronnie

hi all! I'm new user dillo and the first question is the dillo can't connect remote host .I have set the file "dillorc" in the path ~/.dillo/dillorc : # Set the proxy information for http #http_proxy=http://localhost:8080/ http_proxy=http://localhost:8080/-------which need username and passwd; once I set the proxy as :http_proxy=http://proxy.neusoft.com:8080/ It still can't connect remote host. additional I set : # When using a proxy, this sets the domains to access without proxy. # (separated with a single space -- see examples below) #no_proxy = ".mynet.com" #no_proxy = ".mynet.com .other.net .foo.bar.org" no_proxy = ".web.neusoft.com"-----Url our company internal. all of those setting can't make dillo connect any host! could you help me sir ? ********************************************* Sincerely Yours Wang Xingqiang Embedded Software Division. Neusoft Middleware Technologies Company Neusoft Park, Hun Nan Industrial Area, New & High-Tech Development Zone, Shenyang 110179, PRC TEL:+86-24-83665518 E-mail:wang_xq@neusoft.com Http://www.neusoft.com

June 9, 2003

Re: [Dillo-dev] chinese support!!

by Nikita V. Borodikhin

Hello, Wang ! On Fri, 06 Jun 2003 16:41:42 +0800 ronnie <wang_xq(a)neusoft.com> wrote: ...skipped... > and then dillo can display chinese but the window can not show > properly . However dillo-0.7.2 dose not suport pango and is based on > gtk-1.2 ,the most important is dillo dose not internationlize .Why > this change can make dillo display chinese ? I'm so > puzzling! Try to use russian patch. I didn't tested it on Chinese encodings or fonts but it works quite nice (unless selection code) with multibyte-encoded locales like UTF-8. If you'd try it please say your opinion (and how it will run for you). It lives here: http://stuphead.asplinux.ru/dillo/index.html.en Nikita eliterr(at)tkk.ru

June 9, 2003

Re: [Dillo-dev] HTTPS support

by madis

On Mon, 9 Jun 2003, CHEE BIN HOH wrote: > how about adding client side certificate into the https proxy (dpi > plugin), certain website might requires a client certificate (which user > can obtain from them), it is good if we can allow the user to add a file > certificate so or allow another level of plugin to retrieve the client > certificate from like smartcard, or other entity, so the https proxy can > verify the client with the server. But this happen very rare. > This could be also done by adding files manually to separate directory (some conf file is then also needed, to associate hosts with certificates that will be used, when connecting to them). And i think, that if someone wants a gui for adding them, this (gui) could be very well done later using a separate plugin. -- mzz

June 9, 2003

Re: [Dillo-dev] HTTPS support

by CHEE BIN HOH

On Sat, 2003-06-07 at 21:51, Madis Janson wrote: > > On Fri, 6 Jun 2003, Jorge Arellano Cid wrote: > > > The "http to https proxy" is what I call dpi! > > > > I'm working very hard with Ferdi extending the dpi1 design with > > a general plugin manager. We have working code and it had gone > > great on tests. I hope to commit the first version in a week or > > so. > > > Great! > > > > This will ease the process of understanding and developing a > > dpi. I hoped all the concepts and internal working to be clear > > from the dpi1 spec and the bookmarks server code, but it is > > certainly very complex to understand it fully (inside and outside > > of dillo and inside the dpi and within the CCC for dpi). > > It would be useful, if you could put some of the basic dpi server > functionality into a simple library (so dpi tag parsing does not have > to be reimplemented in every dpi server written in C). > > > > Now, as I'm not an HTTPS expert, I don't know what interactions > > will be required to support https fully. That is what data > > exchanges/questions/ are required for each operation. > > > > For instance, when the server's certificate can't be verified > > (by the https dpi in this case), the user must be asked whether > > to accept it under this doubt. This will traduce into a dpi > > command sent to dillo, something like: > > > > <dpi cmd='question' srv='https' > > text='Accept unverified connection from this server?' > > options='YES|NO'> > > > > Then dillo will make the window, ask the user, and send the > > answer back: > > > > <dpi cmd='answer' srv='https' answer='YES'> > > > > ...and the https dpi can resume. > > It would be nice, if some certificate fields (issuer, dates) and > certificate MD5/SHA1 hashes would be also shown to the user. This > allows user to verify the certificate hash in a rare case, when > (s)he has got the hash previously using some trusted channel > (printed to paper for example). > > > > Appart from this one, what else is required? > > That I don't know in detail. <-- (this is a question!) > > On the connection side, nothing. Some way for adding trusted certificates > is needed. This could be achieved by coping these certificate files to > certain directory (like .dillo/certificates), although it is _maybe_ > easier for user, when this can be done using some file open dialog (which > will tell the dpi plugin to get the file from specified location). I think > the dialog way of adding certificates is not essential (notably, because > its a very rare activity). > how about adding client side certificate into the https proxy (dpi plugin), certain website might requires a client certificate (which user can obtain from them), it is good if we can allow the user to add a file certificate so or allow another level of plugin to retrieve the client certificate from like smartcard, or other entity, so the https proxy can verify the client with the server. But this happen very rare. -- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chee Bin HOH (cbhoh) iVEST Department, Mimos Bhd, Technology Park Malaysia, 57000, Kuala Lumpur, Malaysia. http://www.mimos.my http://www.ivest.com.my -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+JkDQAlAFlqwDyl4RAqrhAKClZ50SvSMPeMWYEHbGKQDnfN5FQwCg4JGH u4FBpHbJTKfskuJiS9BjP2o= =pnCn -----END PGP SIGNATURE-----

June 9, 2003

Re: [Dillo-dev] Tabbed version of Dillo

by Frank de Lange

Andreas Schweitzer wrote: > Hi, > > >>Yes, it does facilitate the development of a frames-capable Dillo. I >>have some ideas about how to implement this, and might implement it >>after the tab code is ready for first release. > > > If the "might" should not happen, I'll certainly look into it :-) Well, the weekend is nearly over and I have not used a computer other than to send this message, so it'll definitely be somewhere coming week for the first release of dillo/tabs. By theway, do not let me possibly working on tabs withold you from doing the same... > Oh, one thing : Sebastian Geerken is the one responsible for > the widget part - unless he already mailed you :-) Ack, have not seen mail from him... Sebastian, maybe dw_gtk_scrolled_window needs a method to remove the gadget? I re-use the BrowserWindow's full_screen_off_button gadget in all tabs (reparenting it when needed), but I have to forcibly NULLify the window->gadget attribute to be able to add a new gadget to a dw_gtk_scrolled_window. It is not 'right' to mess with interal widget structures... or am I missing something? The code does not seem to provide a way to remove the gadget once it has been defined. 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." ]

June 8, 2003