- Dillo-dev - lists.mailman3.com

[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