- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] [PATCH] Tabbed version of Dillo, now available on geocities

by Frank de Lange

Todd Slater wrote: > On Tue, 17 Jun 2003 01:21:34 +0200 > Frank de Lange <frank(a)unternet.org> wrote: > > >>Hiya! >> >>I put my patch for a tabbed version of Dillo on a geocities page, so >>if you are quick you might be able to download it before Yahoo? shuts >>it down because the site has exceeded its puny transfer allowance. >> >>Get it here: >> >>http://www.geocities.com/ikbenfrank/dillo-20030615-tabs.patch.gz >> >>md5sum: dae3cc4bb8c6c31050abaf8013a7e973 >> >>As said, this patch applies to today's (well, yesterday's) CVS version >>of Dillo. >> >>Good Luck//Frank > > > This is great, Frank! How does one apply the patch? > Todd > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev First, take a chicken... Well, no, skip the chicken, get the CVS version of Dillo instead (see the Dillo website for how to do this). Go to the base directory (/usr/src/dillo-cvs/dillo or something like that), and apply the patch using something like zcat name_of_gzipped_patch_file|patch -p1. If everything went allright, you now have a patched version of Dillo. So: get CVS version of Dillo get patch cd /to/where/you/put/dillo zcat /where/you/put/dillo-20030615-tabs.patch.gz | patch -p1 ./autogen.sh (this rebuilds the auto*tools files) ./configure (with the usual options like --prefix=, etc) (if you want to DISABLE tabs, use --disable-tabs after configure) make su -c 'make uninstall && make install' But, err, you already knew that, or you would not be subscribed to a developers list, right? It is late, I should sleep now. Go'Natt//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 17, 2003

Re: [Dillo-dev] [PATCH] Tabbed version of Dillo, now available on geocities

by Todd Slater

On Tue, 17 Jun 2003 01:21:34 +0200 Frank de Lange <frank(a)unternet.org> wrote: > Hiya! > > I put my patch for a tabbed version of Dillo on a geocities page, so > if you are quick you might be able to download it before Yahoo? shuts > it down because the site has exceeded its puny transfer allowance. > > Get it here: > > http://www.geocities.com/ikbenfrank/dillo-20030615-tabs.patch.gz > > md5sum: dae3cc4bb8c6c31050abaf8013a7e973 > > As said, this patch applies to today's (well, yesterday's) CVS version > of Dillo. > > Good Luck//Frank This is great, Frank! How does one apply the patch? Todd

June 16, 2003

[PATCH] Tabbed version of Dillo, now available on geocities

by Frank de Lange

Hiya! I put my patch for a tabbed version of Dillo on a geocities page, so if you are quick you might be able to download it before Yahoo? shuts it down because the site has exceeded its puny transfer allowance. Get it here: http://www.geocities.com/ikbenfrank/dillo-20030615-tabs.patch.gz md5sum: dae3cc4bb8c6c31050abaf8013a7e973 As said, this patch applies to today's (well, yesterday's) CVS version of Dillo. Good Luck//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 16, 2003

[PATCH] Tabbed version of Dillo

by Frank de Lange

FYI As promised, I now have a patch ready which implements tabbed browsing. The patch is quite big (173586 bytes, 42305 gzipped), so I think it is not a good idea to send it to the mailing list. As I currently do not have a webserver handy I can not put it on my site like I used to do when times were good and broadband was available (1-0 for The Netherlands - Sweden). Why is the patch so big? Well, it touches many files (37 source and header files, 6 other files) in Dillo, as it moves around some code and adds some more. The moving around is mostly due to the fact that, to implement tabs, I had to split 'document' from 'interface' logic in Dillo. In the current (non-patched) version of Dillo, the 'document' (everything related to a single browsing session in a single window) code is spread out over several files (interface.c, nav.c, web.c, html.c, plain.c, etc...). For tabs (and, later, frames) this does not work well, since a single browser window can contain several individual browsing sessions (tabs, frames (when implemented)). I solved this by putting all document-related stuff in a new abstraction, the 'DilloDoc' (defined in browser.h). DilloDoc contains the document-related stuff from BrowserWindow, progress data and document state info (the 'ready' bit) and - currently - the document-specific widgets (docwin, pagemark menu). Tab-specific stuff can be found in src/tab.c|h. As I know that not everybody wants to have tab functionality in the browser - it can also be implemented at the window manager level - I made the tabbed feature optional. To compile Dillo without tabs, use the --disable-tabs option, and there will be no tab-specific code in your binary. I did some tests with regard to 'code bloat' on the current, new (tabs disabled) en new (tabs enabled) versions of Dillo, which show a binary code size increase of about 7500 bytes for the tab feature. This is not to bad I think. The results of these tests can be found in the doc/Browser_Tabs.txt document (which comes with the patch). So, list, tell me what to do... Do you want your mailboxes to overflow, shall I send the patch to a select few, shall I wrap it in tar paper and bury it? I have already sent it to Jorge and the individuals who expressed interest in having a look at it, but I have had several requests from people on the list to send the patch to the list as well. As I have only a puny modem line here in Sweden, I do not relish the prospect of having to send the patch to loads of individuals. You decide. Oh, and I will be off-line between the 23d of june and the 13th of juli, so please let me know beforehand... Also, as the patch is against today's CVS version of Dillo, it has a relatively short shelf life. So, let me know, or (Jorge) apply it to CVS so others can have a go at it. Go'natt//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 16, 2003

Suggestion for a next dillo version

by Manuel Serrano

Hello there, first of all, many thanks for making Dillo available. I'm using it on a daily basis. It does almost anything I want of my web browser (nearly may be CSS2 but this is not the purpose of this mail :-). I like the new feature of 0.7.2 that enables to hide the navigation bar. I was wondering if it could be possible to have an automatic hidden bar such as in many window manager (fluxbox, kde, gnone, ...). That is the navigation bar is automatically hidden until the mouse fly over the very top lines. If the mouse fly over these lines, it automatically appears... Do you think that it would be difficult to implement this feature in a coming version? Many thanks in advance and one more time, thanks for making Dillo available. -- Manuel

June 16, 2003

Re: [Dillo-dev] Strange condition in cache.c old code

by Nikita V. Borodikhin

Hello, Andreas ! Andreas Kemnade wrote: >> <...> >> The presence of an entity body in a request is signaled by the >> inclusion of a Content-Length header field in the request message >> headers. HTTP/1.0 requests containing an entity body must include > ^^^^^^^^^ >> a valid Content-Length header field. >> > We speak about HTTP *responses* so that argument is invalid > >> IMHO if HTTP/1.0 response has an entity body then we know its type >> and length and should display it if we know how regardless of its size. >> So for this purpose "1024 test" has not sense. >> > see above > > Greetings > Andreas Kemnade OK, may be I'm wrong in my opinion but please give me _argumented_ answer why the current way of redirection confirms the standard. I'll accept any answer with reference to RFC, either HTTP/1.0 or HTTP/1.1. I dig them both and found those paragraphs to prove my point of view. May be I didn't found something that concern this question so if you can do it then do it ! Yours, Nikita

June 15, 2003

Re: [Dillo-dev] IFRAME element stub

by Stephen Lewis

On Sat, 14 Jun 2003 15:22:48 +0700 (NOVST) "Nikita V. Borodikhin" <eliterr(a)tkk.ru> wrote: > Hello, Stephen ! > > Stephen Lewis wrote: > > >> > There is a very small patch to support IFRAME HTML element. It > >does> > nothing except handling IFRAME via FRAME handler so special > >IFAME> > attributes(width and height) are not handled but this patch > >is> > suitable for current temporary solution (as we do not have real > >> > frame support for now). > > > > Just a comment about this - I'm using a recent CVS version some time > > after this was integrated, and it causes some display issues with a > > lot of sites. In particular, sites that use narrow IFRAMEs for ads <snip> > > This is a consequence of currently used way to handle frames, as Links > has. This IFRAME handler may be redesigned to use supplyed width and > height, I think it is not too hard but I expect it is a _temporary_ > solution intended just for having a link to IFRAME content until we do > not have normal frames. > OK, thanks for the response - I just wanted to make sure it hadn't slipped through unnoticed. Of course, if I'd actually read your original message thoroughly, I would have noticed that you'd said it was a temporary solution anyway... knee-jerk bug reporting reactions strike again! As an aside, it was quite an eye-opener viewing websites with this patch, I discovered many sites which I had thought to be free from advertising were in fact saturated with it - they were having about as much effect on me using Dillo as all of those pop up/under ads I hear about all the time ;) -- Stephen Lewis slewis(a)paradise.net.nz

June 15, 2003

Re: [Dillo-dev] IFRAME element stub

by Stephen Lewis

On Sat, 14 Jun 2003 16:49:45 -0700 Chris Palmer <chris(a)nodewarrior.org> wrote: > Madis Janson writes: > > > + gchar *src, *buf, *name; > > + gint dummy, len; > > - if ( !(attrbuf = Html_get_attr(html, tag, tagsize, "name")) ) { > > + if ( !!(attrbuf = Html_get_attr(html, tag, tagsize, "name")) ) { > > + a_Dw_page_add_text(page, g_strdup(attrbuf), link_style); > > + } else if (tolower(tag[1]) != 'i' || (len = strlen(name = src)) > > < 16 ||+ (name += 7, len -= 7) < 16) { > > - a_Dw_page_add_text(page, g_strdup(attrbuf), link_style); > > + buf = g_malloc(16); > > + memcpy(buf, name, 6); > > + strcpy(buf + 6, "..."); > > + memcpy(buf + 9, name + (len - 6), 6); > > + buf[15] = 0; > > + a_Dw_page_add_text(page, buf, link_style); > > Two questions: > > 1. Where does buf get free()'d? I had a quick look around for this and found the following comment for a_Dw_page_add_text (from src/dw_page.c): /* * Add a word to the page structure. Stashes the argument pointer in * the page data structure so that it will be deallocated on destroy. */ Which I guess answers the second question too. It's always such a pleasant surprise to have actual, useful comments in code! But then, I've come to expect pleasant surprises with Dillo ;) -- Stephen Lewis slewis(a)paradise.net.nz

June 15, 2003

Re: [Dillo-dev] IFRAME element stub

by Stephen Lewis

On Sat, 14 Jun 2003 11:51:35 +0300 (EEST) Madis Janson <madis(a)ats.cyber.ee> wrote: > On Sat, 14 Jun 2003, Stephen Lewis wrote: > <snip> > > It's great having this patch apart from the display issues it > > causes. Would it be possible to make the displayed URL wrap? > > > > > > I made it to replace the middle of long urls with ... for iframes: <snip> That patch works very nicely, thank you! -- Stephen Lewis slewis(a)paradise.net.nz

June 15, 2003

Re: [Dillo-dev] IFRAME element stub

by Chris Palmer

Madis Janson writes: > + gchar *src, *buf, *name; > + gint dummy, len; > - if ( !(attrbuf = Html_get_attr(html, tag, tagsize, "name")) ) { > + if ( !!(attrbuf = Html_get_attr(html, tag, tagsize, "name")) ) { > + a_Dw_page_add_text(page, g_strdup(attrbuf), link_style); > + } else if (tolower(tag[1]) != 'i' || (len = strlen(name = src)) < 16 || > + (name += 7, len -= 7) < 16) { > - a_Dw_page_add_text(page, g_strdup(attrbuf), link_style); > + buf = g_malloc(16); > + memcpy(buf, name, 6); > + strcpy(buf + 6, "..."); > + memcpy(buf + 9, name + (len - 6), 6); > + buf[15] = 0; > + a_Dw_page_add_text(page, buf, link_style); Two questions: 1. Where does buf get free()'d? 2. If you know the exact size you need for buf, why not just use an array of that size? char buf[16]; bzero(buf, 16);

June 14, 2003

Re: [Dillo-dev] Strange condition in cache.c old code

by Andreas Kemnade

On Sat, 14 Jun 2003 17:02:00 +0700 (NOVST) "Nikita V. Borodikhin" <eliterr(a)tkk.ru> wrote: > <...> > The presence of an entity body in a request is signaled by the > inclusion of a Content-Length header field in the request message > headers. HTTP/1.0 requests containing an entity body must include ^^^^^^^^^ > a valid Content-Length header field. > We speak about HTTP *responses* so that argument is invalid Greetings Andreas Kemnade > > IMHO if HTTP/1.0 response has an entity body then we know its type > and length and should display it if we know how regardless of its size. > So for this purpose "1024 test" has not sense. > see above Greetings Andreas Kemnade

June 14, 2003

Re: [Dillo-dev] Strange condition in cache.c old code

by Nikita V. Borodikhin

Hello, Jorge ! Jorge Arellano Cid wrote: >> Explain me please what is 1024 in the following code for. I read HTML >> and >> HTTP/1.1 (rfc2616) specifications but didn't find an answer. > > FYI: Dillo uses HTTP/1.0. OK, I'll give citations from HTTP/1.0 (RFC1945) >> I think this >> condition must be wiped out because some servers (linux.org.ru for >> example) >> give too long responses. >> >> [...] >> >> /* >> * Process redirections (HTTP 30x answers) >> * (This is a work in progress --not finished yet) >> */ >> int Cache_redirect(CacheData_t *entry, int Flags, BrowserWindow *bw) >> { >> if ( ((entry->Flags & CA_Redirect) && entry->Location) && >> ((entry->Flags & CA_ForceRedirect) || !entry->ValidSize || >> entry->ValidSize < 1024 ) ) { > > IIRC this is an heuristical boundary. > > Some servers don't send entity content within an http > redirection (Correct behaviour IMHO). Some send a short default > message as entity content (something so redundant as "This page > is being redirected"), and some others send a full page that can > be anything! I don't really encountered any server that gives a _garbage_ in 3xx response. Usually it is a HTML page with short decription and in rare case it is just a redirection without entity-body. RFC says that servers _may_ send a content (entity) but may do not: 4.1 Message Types HTTP messages consist of requests from client to server and responses from server to client. HTTP-message = Simple-Request ; HTTP/0.9 messages | Simple-Response | Full-Request ; HTTP/1.0 messages | Full-Response Full-Response = Status-Line ; Section 6.1 *( General-Header ; Section 4.3 | Response-Header ; Section 6.2 | Entity-Header ) ; Section 7.1 CRLF [ Entity-Body ] ; Section 7.2 7.2 Entity Body The entity body (if any) sent with an HTTP request or response is in a format and encoding defined by the Entity-Header fields. Entity-Body = *OCTET <...> The presence of an entity body in a request is signaled by the inclusion of a Content-Length header field in the request message headers. HTTP/1.0 requests containing an entity body must include a valid Content-Length header field. > The "1024" somehow decides this: > > < 1024: > Short redirection message. > > > 1024: > Don't know what is this large page! IMHO if HTTP/1.0 response has an entity body then we know its type and length and should display it if we know how regardless of its size. So for this purpose "1024 test" has not sense. > I also have a vague memory in my mind about how the http > redirection data stream is (or isn't) cut in order to make the > redirection. The "1024" threshold may "solve" this somehow. ??? I don't undestand this problem... > This is where you need to start investigating. > > HTH > Jorge.- Yours, Nikita

June 14, 2003

Re: [Dillo-dev] IFRAME element stub

by Madis Janson

On Sat, 14 Jun 2003, Stephen Lewis wrote: > Just a comment about this - I'm using a recent CVS version some time > after this was integrated, and it causes some display issues with a lot > of sites. In particular, sites that use narrow IFRAMEs for ads in a > table(e.g. http://www.osnews.com, http://arstechnica.com/ ). The > displayed URL seems to force the column width to be much, much wider > than it normally would, making these websites look very bad (very wide > column with ads, very narrow column with actual text :/ ) > > It's great having this patch apart from the display issues it causes. > Would it be possible to make the displayed URL wrap? > > I made it to replace the middle of long urls with ... for iframes: diff -pru -x CVS -x configure -x 'aclocal*' -x 'Makefile*' -x config.h.in cvs/dillo/src/html.c dillo/src/html.c --- cvs/dillo/src/html.c 2003-06-11 23:43:07.000000000 +0300 +++ dillo/src/html.c 2003-06-12 21:18:36.000000000 +0300 @@ -1603,12 +1612,12 @@ static void Html_tag_open_tr(DilloHtml * static void Html_tag_open_frame (DilloHtml *html, gchar *tag, gint tagsize) { const char *attrbuf; - gchar *src; + gchar *src, *buf, *name; DilloUrl *url; DwPage *page; DwStyle style_attrs, *link_style; DwWidget *bullet; - gint dummy; + gint dummy, len; page = DW_PAGE(html->dw); @@ -1641,10 +1650,18 @@ static void Html_tag_open_frame (DilloHt a_Dw_page_add_space(page, html->stack[html->stack_top].style); /* If 'name' tag is present use it, if not use 'src' value */ - if ( !(attrbuf = Html_get_attr(html, tag, tagsize, "name")) ) { + if ( !!(attrbuf = Html_get_attr(html, tag, tagsize, "name")) ) { + a_Dw_page_add_text(page, g_strdup(attrbuf), link_style); + } else if (tolower(tag[1]) != 'i' || (len = strlen(name = src)) < 16 || + (name += 7, len -= 7) < 16) { a_Dw_page_add_text(page, g_strdup(src), link_style); } else { - a_Dw_page_add_text(page, g_strdup(attrbuf), link_style); + buf = g_malloc(16); + memcpy(buf, name, 6); + strcpy(buf + 6, "..."); + memcpy(buf + 9, name + (len - 6), 6); + buf[15] = 0; + a_Dw_page_add_text(page, buf, link_style); } a_Dw_page_add_parbreak(page, 5, html->stack[(html)->stack_top].style);

June 14, 2003

Re: [Dillo-dev] IFRAME element stub

by Nikita V. Borodikhin

Hello, Stephen ! Stephen Lewis wrote: >> > There is a very small patch to support IFRAME HTML element. It does >> > nothing except handling IFRAME via FRAME handler so special IFAME >> > attributes(width and height) are not handled but this patch is >> > suitable for current temporary solution (as we do not have real >> > frame support for now). > > Just a comment about this - I'm using a recent CVS version some time > after this was integrated, and it causes some display issues with a lot > of sites. In particular, sites that use narrow IFRAMEs for ads in a > table(e.g. http://www.osnews.com, http://arstechnica.com/ ). The > displayed URL seems to force the column width to be much, much wider > than it normally would, making these websites look very bad (very wide > column with ads, very narrow column with actual text :/ ) > > It's great having this patch apart from the display issues it causes. > Would it be possible to make the displayed URL wrap? This is a consequence of currently used way to handle frames, as Links has. This IFRAME handler may be redesigned to use supplyed width and height, I think it is not too hard but I expect it is a _temporary_ solution intended just for having a link to IFRAME content until we do not have normal frames. > Stephen Lewis > slewis(a)paradise.net.nz Yours, Nikita

June 14, 2003

Re: [Dillo-dev] IFRAME element stub

by Stephen Lewis

On Wed, 11 Jun 2003 11:32:22 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > Nikita, > > > Hi all Dillo developers ! > > > > There is a very small patch to support IFRAME HTML element. It does > > nothing except handling IFRAME via FRAME handler so special IFAME > > attributes(width and height) are not handled but this patch is > > suitable for current temporary solution (as we do not have real > > frame support for now). > > Done! Just a comment about this - I'm using a recent CVS version some time after this was integrated, and it causes some display issues with a lot of sites. In particular, sites that use narrow IFRAMEs for ads in a table(e.g. http://www.osnews.com, http://arstechnica.com/ ). The displayed URL seems to force the column width to be much, much wider than it normally would, making these websites look very bad (very wide column with ads, very narrow column with actual text :/ ) It's great having this patch apart from the display issues it causes. Would it be possible to make the displayed URL wrap? -- Stephen Lewis slewis(a)paradise.net.nz

June 14, 2003

Tabbed version of Dillo

by Frank de Lange

Hiya, I have finally found some time to work on my tabbed version of Dillo, which I mailed about last week. I hope to have it ready for first release in a few days. If anyone is planning extensive architectural changes to one of these files in the next few days, please let me know: interface.c html.c web.c nav.c plain.c cache.c capi.c browser.h Some other changes I made: - I separated the pagemark functionality into its own file, and renamed the functions from 'pagemarks' to a_Pagemark_... files pagemark.c/h - new files for tab and document functionality files tab.c/h, doc.c/h There is still quite a bit of 'interface' code in the document rendering path (just do a search for a_Interface_ and see from where these functions are called...). This needs to be dealt with for implementation of frames. I'm currently looking at this, but I will probably not implement it before I release the patch. 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 13, 2003

convert mozilla bookmarks to dillo

by Kyle Amon

Hi, I don't subscribe to this list, but I've been sweet on Dillo since about 1997 or 1998 (who knows). Anyway, I just wrote a trivial but usefull perl script to generate a Dillo bm.txt file from a Mozilla bookmarks.html file and thought others might be interested in using it as well. It is attached and posted on my homepage under Software. Enjoy, -- Kyle -- Kyle Amon email: amonk(a)gnutec.com url: http://www.gnutec.com/~amonk KeyID 1024D/4EB96E44 Fingerprint = E9EC 0046 8487 23D7 C91C D757 7B2A 8AE9 4EB9 6E44 "Learning isn't a duty that we must be flogged into performing; it's our birthright, our very human specialty and joy." - Jerry Farber The Student As Nigger This email Copyright 2003 by Kyle Amon, Inc., a Florida corporation, 6002 Palm Shadow Way, Suite 1218, Tampa, FL 33647: (813) 689-4041 amonk(a)gnutec.com http://www.gnutec.com/~amonk. All rights reserved.

June 12, 2003

gtk-list@gnome.org

by Jorge Arellano Cid

Hi, Is anyone here member of "gtk-list(a)gnome.org"? I sent an email some days ago there and it is being "held" for aproval because I'm not a member. If someone has a membership there please let me know to forward my message through him. Thanks Jorge.-

June 12, 2003

Re: [Dillo-dev] New program icons (not toolbars)

by Melvin Hadasht

> Just look at the new stuff at: http://www.dillo.org/Icons/ Gorgeous: (web1913) Gorgeous \Gor"geous\, a. [OF. gorgias beautiful, glorious, vain, luxurious; cf. OF. gorgias ruff, neck handkerchief, and F. gorge throat, and se pengorger to assume airs. Cf. Gorge, n.] Imposing through splendid or various colors; showy; fine; magnificent. The new icon set is all that.

June 11, 2003

Re: [Dillo-dev] New program icons (not toolbars)

by Chris Palmer

Jorge Arellano Cid writes: > Just look at the new stuff at: http://www.dillo.org/Icons/ Nice!

June 11, 2003

New program icons (not toolbars)

by Jorge Arellano Cid

Hy Guys! Just look at the new stuff at: http://www.dillo.org/Icons/ Enjoy Jorge.- PS: Poll is over, we all agreed on making JG's icons the default!!!

June 11, 2003

Re: [Dillo-dev] IFRAME element stub

by Jorge Arellano Cid

Nikita, > Hi all Dillo developers ! > > There is a very small patch to support IFRAME HTML element. It does nothing > except handling IFRAME via FRAME handler so special IFAME attributes > (width and height) are not handled but this patch is suitable for current > temporary solution (as we do not have real frame support for now). Done! Cheers Jorge.-

June 11, 2003

Re: [Dillo-dev] Strange condition in cache.c old code

by Jorge Arellano Cid

Nikita, > Hello old Dillo developers ! Hi! > Explain me please what is 1024 in the following code for. I read HTML and > HTTP/1.1 (rfc2616) specifications but didn't find an answer. FYI: Dillo uses HTTP/1.0. > I think this > condition must be wiped out because some servers (linux.org.ru for example) > give too long responses. > > [...] > > /* > * Process redirections (HTTP 30x answers) > * (This is a work in progress --not finished yet) > */ > int Cache_redirect(CacheData_t *entry, int Flags, BrowserWindow *bw) > { > if ( ((entry->Flags & CA_Redirect) && entry->Location) && > ((entry->Flags & CA_ForceRedirect) || !entry->ValidSize || > entry->ValidSize < 1024 ) ) { IIRC this is an heuristical boundary. Some servers don't send entity content within an http redirection (Correct behaviour IMHO). Some send a short default message as entity content (something so redundant as "This page is being redirected"), and some others send a full page that can be anything! The "1024" somehow decides this: < 1024: Short redirection message. > 1024: Don't know what is this large page! I also have a vague memory in my mind about how the http redirection data stream is (or isn't) cut in order to make the redirection. The "1024" threshold may "solve" this somehow. This is where you need to start investigating. HTH Jorge.-

June 11, 2003

Strange condition in cache.c old code

by Nikita V. Borodikhin

Hello old Dillo developers ! Explain me please what is 1024 in the following code for. I read HTML and HTTP/1.1 (rfc2616) specifications but didn't find an answer. I think this condition must be wiped out because some servers (linux.org.ru for example) give too long responses. Code from cache.c revision 1.2, Tue Aug 29 00:36:27 2000 UTC, 2 years, 9 months ago by shaleh: /* * Process redirections (HTTP 30x answers) * (This is a work in progress --not finished yet) */ int Cache_redirect(CacheData_t *entry, int Flags, BrowserWindow *bw) { if ( ((entry->Flags & CA_Redirect) && entry->Location) && ((entry->Flags & CA_ForceRedirect) || !entry->ValidSize || entry->ValidSize < 1024 ) ) { Yours, Nikita

June 11, 2003

Re: IFRAME element stub

by Nikita V. Borodikhin

On Wed, 11 Jun 2003 20:30:32 +1000 TheStar <thestar(a)tpg.com.au> wrote: > > There is a very small patch to support IFRAME HTML element. It does > > nothing except handling IFRAME via FRAME handler so special IFAME > > attributes(width and height) are not handled but this patch is > > suitable for current temporary solution (as we do not have real > > frame support for now). > > This implies that Dillo can now handle frames (perhaps by re-rendering > to tables), on at least one developer's computer - Correct? No, not on my computer. Dillo (CVS version and all releases) cannot handle frames as needed. It currently follows HTML specification in handling frames by browsers which do not have an ability to show them so it gives you only links to frames. This patch only adds ability to draw link to IFRAME source. Some work is in progress which may implement frames (see last week postings about tabbed version) but it is not currenly done. Yours, Nikita

June 11, 2003

IFRAME element stub

by Nikita V. Borodikhin

Hi all Dillo developers ! There is a very small patch to support IFRAME HTML element. It does nothing except handling IFRAME via FRAME handler so special IFAME attributes (width and height) are not handled but this patch is suitable for current temporary solution (as we do not have real frame support for now). Your, Nikita diff -pruN dillo/src/html.c dillo-iframe/src/html.c --- dillo/src/html.c 2003-06-06 14:13:00.000000000 +0700 +++ dillo-iframe/src/html.c 2003-06-11 16:50:54.000000000 +0700 @@ -3795,6 +3795,7 @@ static const TagInfo Tags[] = { {"hr", Html_tag_open_hr, Html_tag_close_nop}, /* html */ {"i", Html_tag_open_i, Html_tag_close_default}, + {"iframe", Html_tag_open_frame, Html_tag_close_nop}, {"img", Html_tag_open_img, Html_tag_close_nop}, {"input", Html_tag_open_input, Html_tag_close_nop}, /* ins */

June 11, 2003

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

Re: [Dillo-dev] can not connect remote web!

by ronnie

hi Franco Thanks respondence! I have edited the dillorc and set the folloings: # Set the proxy information for http http_proxy=http://proxy.neusoft.com:8080/ proxy.neusoft.com is the proxy and which need username and passwd; But I still can't connect remote URL . ----- Original Message ----- From: "fraazz" <cfraz(a)wanadoo.fr> To: "ronnie" <wang_xq(a)neusoft.com> Cc: <dillo-dev(a)lists.auriga.wearlab.de> Sent: Friday, June 06, 2003 7:01 PM Subject: Re: [Dillo-dev] can not connect remote web! > On 06.06.2003 05:48, ronnie wrote: > > hello everyone! > > I have installed dillo on my pc(redhat 7.2) and find it's perfect.But I can > > connect any remote web through our company proxy .can you tell me how set the > > proxy in dillo and make me enjoy the lightweight browser? > > > see your /home/user/.dillo/dillorc file > > Franco > > >

June 8, 2003

Re: [Dillo-dev] Tabbed version of Dillo

by Chris Palmer

Paul Pelzl writes: > I prefer Mozilla's model for closing tabs: there is a single close Agreed. > The most important functionality, in my opinion, is to have the option > of loading a link in the background without automatically switching > focus to that tab. Agreed. > I look forward to seeing what you come up with. Me too. :)

June 6, 2003

Re: [Dillo-dev] Tabbed version of Dillo

by Paul Pelzl

On Fri, Jun 06, 2003 at 11:50:06PM +0200, Frank de Lange wrote: > Anyone have any special wishes for this tabbed feature? Architecturally > it is easy to move tabs between browser windows, or move single tabs > into new browserwindows (like Galeon does), but is this needed? Also, > tab-close buttons on the tabs, in the tab button-3 menu, elsewhere? I prefer Mozilla's model for closing tabs: there is a single close button somewhere to the right of the tabs, which closes the active tab. The tab button-3 menu can be used to close an inactive tab if desired. (Putting tab-close buttons on every tab clutters the interface, and it means you have to hunt around for the proper close button instead of having it fixed in a constant location.) The most important functionality, in my opinion, is to have the option of loading a link in the background without automatically switching focus to that tab. I look forward to seeing what you come up with. Paul

June 6, 2003

Re: [Dillo-dev] Tabbed version of Dillo

by Frank de Lange

Grigory Bakunov wrote: > Frank de Lange wrote: > >> >> When ready, I'll send a patch to jcid(a)softhome.net. > > > > Can you show this patch to all please? > Jorge work on dillo hardly, so you patch must be placed to queue, not > to stack > We all can test your patch before Jorge read it and (may be) > commit to cvs. > OK, when ready (somewhere next week, unless I find time this weekend...) I'll see how big the patch is, and tell the list the results. If it is to big to send to the list (probably...) I'll find some other way to spread it. (yeah, it really is time for broadband to come to this part of Sweden so I can put up my webserver again... this was better in the Netherlands...) Anyone have any special wishes for this tabbed feature? Architecturally it is easy to move tabs between browser windows, or move single tabs into new browserwindows (like Galeon does), but is this needed? Also, tab-close buttons on the tabs, in the tab button-3 menu, elsewhere? 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 6, 2003

Re: [Dillo-dev] Tabbed version of Dillo

by Grigory Bakunov

Frank de Lange wrote: > > When ready, I'll send a patch to jcid(a)softhome.net. Can you show this patch to all please? Jorge work on dillo hardly, so you patch must be placed to queue, not to stack We all can test your patch before Jorge read it and (may be) commit to cvs. -- .............................................................. IRC: irc.openproject.net #asplinux Grigory Bakunov EMAIL: black(a)asplinux.ru ASPLinux Development Team ICQ: 51369901 http://www.asplinux.ru

June 6, 2003

Re: [Dillo-dev] Tabbed version of Dillo

by Andreas Schweitzer

Hi, > To add this feature, I have created a new 'document' abstraction in > Dillo, the 'DilloDoc'. This contains all data related to a single > 'browser document' (including navigation history, etc), many parts of > which used to reside in the 'BrowserWindow'. This was necessary to > separate 'interface' functionality from 'document' functionality, as a > tabbed browser can have 'document' activity going on in the background > (eg. load a tab in the background while reading another tab, etc). hmmm, that sounds awfully a lot like what I thought frames would need. I tried to modify the BrowserWindow as well, but wasn't too succesful (due to lack of time and lack of GTK knowledge). So, I think, this is useful as frames should then be trivial to implement. Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

June 6, 2003

Tabbed version of Dillo

by Frank de Lange

FYI, I have added the often-requested 'tabbed browsing' feature to dillo. Even though it works fine, I want to finish the patch before I send it off for inclusion (or rejection, see below). To add this feature, I have created a new 'document' abstraction in Dillo, the 'DilloDoc'. This contains all data related to a single 'browser document' (including navigation history, etc), many parts of which used to reside in the 'BrowserWindow'. This was necessary to separate 'interface' functionality from 'document' functionality, as a tabbed browser can have 'document' activity going on in the background (eg. load a tab in the background while reading another tab, etc). When ready, I'll send a patch to jcid(a)softhome.net. <OT> I know that tabbed functionality can also be implemented at the window manager level, but I happen to like having it in the browser itself. It also saves memory compared to having several instances of Dillo loaded, which fits in nicely with Dillo's 'philosophy'. </OT> 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 6, 2003

Re: [Dillo-dev] can not connect remote web!

by fraazz

On 06.06.2003 05:48, ronnie wrote: > hello everyone! > I have installed dillo on my pc(redhat 7.2) and find it's perfect.But I can > connect any remote web through our company proxy .can you tell me how set the > proxy in dillo and make me enjoy the lightweight browser? > see your /home/user/.dillo/dillorc file Franco

June 6, 2003

chinese support!!

by ronnie

hi all! I insert follow into the dw_style.c's Dw_style_font_relize : strcat (fontname, "-adobe-helvetica-medium-r-normal--16-*-*-*-*-*-iso8859-1,\ -*-*-medium-r-normal--16-*-*-*-*-*-gb2312.1980-0,*-r-*"); font->font = gdk_fontset_load(fontname); // font->font = gdk_font_load (fontname); 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! ********************************************* 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 6, 2003

Re: [Dillo-dev] HTTPS support

by Andreas Kemnade

On Fri, 6 Jun 2003 01:42:25 +0300 (EEST) Madis Janson <madis(a)ats.cyber.ee> wrote: > > I wrote a http to https proxy and simple patch to make dillo to start this > up (when some https query is made) and forward https queries through unix > domain socket to the proxy. Server certificate chains verification is not > implemented (yet). > > It probably could be made into a dpi plugin in future, but currently dpi > seemed to lack some needed properties (like forwarding full http querys > with cookies to the proxy), which are used by the patch and proxy > interface. > Oh, yet another method to support ssl in dillo. Very interesting idea. I guess now it is time to find out which is the better one. Is there any ssl patch out there, which supports certificates? Greetings Andreas Kemnade

June 6, 2003

can not connect remote web!

by ronnie

hello everyone! I have installed dillo on my pc(redhat 7.2) and find it's perfect.But I can connect any remote web through our company proxy .can you tell me how set the proxy in dillo and make me enjoy the lightweight browser? ********************************************* 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 6, 2003

HTTPS support

by Madis Janson

I wrote a http to https proxy and simple patch to make dillo to start this up (when some https query is made) and forward https queries through unix domain socket to the proxy. Server certificate chains verification is not implemented (yet). It probably could be made into a dpi plugin in future, but currently dpi seemed to lack some needed properties (like forwarding full http querys with cookies to the proxy), which are used by the patch and proxy interface. oh and it could be get here: http://www.zone.ee/myzz/dillo/sslgw-0.1.tar.gz -- mzz

June 5, 2003

dillo.org

by Jorge Arellano Cid

Hi there! Have you tried http://www.dillo.org ? :-) Cheers Jorge.-

June 5, 2003

confirm 681396

by ronnie

********************************************* 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 5, 2003