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

Re: [Dillo-dev] [PATCH] Version 14 of tab/frames/kbnav patch is ready

by Stephan Goetter

Am Mon, Nov 10, 2003 at 05:36:59PM +0100 schrieb Frank de Lange und sprach: > Hi'all, > > The next version (14) of my tab/frame/keyboard navigation patch is > ready (see bottom of this message for download instructions). > Works very well. Here are the only things I noticed: If I have a site with frames and navigate around the history isn't updated properly. If you click back then you are on the site before. An additional history per frame would probably do it. Then you could go back in a frame using the popup menu. Using tabs the copy&paste just with selection is kind of weird. You can't select the directory in the location of a site and copy it to the location of a new tab (cos its the same widget). If you select some text in tab#1 you can't copy it to location#2. The following patch is useful if you have a lot of tabs. You can jump from the last to the first and vice versa (using shortcuts). Greets, Stephan --- commands.c.old 2003-11-10 18:37:54.000000000 +0100 +++ commands.c 2003-11-11 17:44:59.000000000 +0100 @@ -429,14 +429,22 @@ void a_Commands_save_link_callback(GtkWi /* VIEW MENU */ void a_Commands_tab_prev_callback(GtkWidget *widget, gpointer client_data) { - BrowserWindow *bw = (BrowserWindow *) client_data; - gtk_notebook_prev_page(GTK_NOTEBOOK(bw->container)); + BrowserWindow *bw = (BrowserWindow *) client_data; + if (gtk_notebook_get_current_page(GTK_NOTEBOOK(bw->container)) != 0) + gtk_notebook_prev_page(GTK_NOTEBOOK(bw->container)); + else + gtk_notebook_set_page(GTK_NOTEBOOK(bw->container), g_list_length(gtk_container_children(bw->container))-1); } void a_Commands_tab_next_callback(GtkWidget *widget, gpointer client_data) { - BrowserWindow *bw = (BrowserWindow *) client_data; - gtk_notebook_next_page(GTK_NOTEBOOK(bw->container)); + BrowserWindow *bw = (BrowserWindow *) client_data; + GtkNotebook *nb = GTK_NOTEBOOK(bw->container); + if (gtk_notebook_get_current_page(GTK_NOTEBOOK(bw->container)) + != g_list_length(gtk_container_children(bw->container))-1) + gtk_notebook_next_page(nb); + else + gtk_notebook_set_page(GTK_NOTEBOOK(bw->container), 0); } #endif

Nov. 11, 2003

Re: [Dillo-dev] [RFC] Quo Vadis Dillo

by Indan Zupancic

> I was unable to apply Indan's https patch to the 11-10.cvs, Known "problem", see my other mail for more info. > It would be nice if you included Indan's https patch with your's. My patch is very young and I'm not happy with it yet, but it looks like I need to update it, impatient people. :) Greetings, Indan

Nov. 11, 2003

Re: [Dillo-dev] [RFC] Quo Vadis Dillo

by Patrick Shanahan

* Frank de Lange <frank(a)unternet.org> [11-11-03 09:09]: > > Now that the last release of the patches seem to work (number 13 was > less of a success...)... I successfully applied #14 to SuSE 8.1 and have found no faults. I am very pleased with the functionality, tabs & keybindings. > Where do we want to be tomorrow? > > What needs to be added/changed to improve Dillo? > > Should the tab/frame/etcetera + Indan's patch + ??? be forked into an > 'experimental' version, somewhat like the Sylpheed MUA was forked > into Sylpheed-claws? I was unable to apply Indan's https patch to the 11-10.cvs, pat@wahoo:/dillo.cvs.1110> patch -p1 <dillo-ssl.diff patching file configure.in Hunk #1 succeeded at 26 with fuzz 2 (offset 2 lines). Hunk #2 succeeded at 177 (offset 8 lines). Hunk #3 succeeded at 225 (offset 22 lines). patching file src/IO/IO.c Hunk #1 succeeded at 48 with fuzz 2. Hunk #2 succeeded at 88 (offset 18 lines). Hunk #3 succeeded at 276 (offset 18 lines). Hunk #4 succeeded at 402 (offset 18 lines). Hunk #5 succeeded at 451 (offset 21 lines). Hunk #6 succeeded at 468 (offset 21 lines). Hunk #7 succeeded at 476 (offset 21 lines). Hunk #8 succeeded at 506 (offset 21 lines). Hunk #9 succeeded at 578 (offset 22 lines). Hunk #10 FAILED at 592. Hunk #11 succeeded at 746 (offset 24 lines). 1 out of 11 hunks FAILED -- saving rejects to file src/IO/IO.c.rej patching file src/IO/IO.h Hunk #1 FAILED at 46. 1 out of 1 hunk FAILED -- saving rejects to file src/IO/IO.h.rej patching file src/IO/Url.c patching file src/IO/http.c Hunk #2 FAILED at 219. Hunk #3 succeeded at 317 with fuzz 2 (offset 3 lines). Hunk #4 succeeded at 406 (offset 5 lines). 1 out of 4 hunks FAILED -- saving rejects to file src/IO/http.c.rej patching file src/capi.c Hunk #1 FAILED at 255. 1 out of 1 hunk FAILED -- saving rejects to file src/capi.c.rej rej files available on request. It would be nice if you included Indan's https patch with your's. INFO ONLY: I have compiled an rpm of 11-10.cvs with the tabs patch which is ~240K. Also available on request. tks for your efforts, -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Nov. 11, 2003

Re: [Dillo-dev] [RFC] Quo Vadis Dillo

by Victor Sahlstedt

On Tue, 11 Nov 2003 15:05:17 +0100 Frank de Lange <frank(a)unternet.org> wrote: > Should the tab/frame/etcetera + Indan's patch + ??? be forked into an > 'experimental' version, somewhat like the Sylpheed MUA was forked into > Sylpheed-claws? Personally i'd prefer if the patches were merged with Dillo but I wouldn't mind a forkish "Dillo-Claws" or such. Jorge? > Some ideas: > - make the 'search the web' popup disappear when popup_dialogs=NO, > replace it with a non_popup version or use the location bar for > search (like several other browsers do) Being able to use the location-bar (or preferably a separate search-bar) would be really neato. It's #1 on my wish-list, anyways. Keep up the good work. - Victor

Nov. 11, 2003

Latest parser changes

by Jorge Arellano Cid

Hi there! After all the trouble with trying to convince Slashdot's webmasters to fix their HTML (because of the loftier importance of adhering to standards), and considering Andreas S. comment on that dillo was making a weird rendering only, but not helping to find the cause to fix the problem, I started a more in-depth review of it. As time passed the code I was developing turned more and more interesting and finally here you have it! This is a quote from the ChangeLog: * Adapted the generic parser to make HTML error detection, providing the line number and a hint (expected tag) in the error message! * Added 'show_html_wanings' option to dillorc (boolean). * Added information about optional, required and forbidden end tags. * Modified the parser's handling of closing tags to account for elements with an optional close tag, and for more accurate diagnosis messages. * Added 'use_old_parser' option to dillorc (boolean). * Fixed the handling of HEAD and BODY elements to account for their double optional condition (both open and close tags are optional). This basically means that now dillo will detect and print useful error messages about bad-formed HTML. After using it for a while it helped me to find bugs I have overseen for months and it proved very accurate and helpful! (it even catched one at the W3C site! :) I hope it will be a good tool for webmasters, and for people authoring simple web pages. In our side, it will help to polish our HTML parsing. For instance, it soon became clear that we're sometimes pulling tags when they should stay. For instance: <p> <ol><li> One <li> two </ol> </p> <- detects an error here. because <ol> anticipatedly cleans <p> from the stack. This may look not relevant, but when trying to build a DOM tree it certainly is! Some comments: The new parsing behaviour makes sites render different from what they used to. Sometimes they show better, some others worse. After all it is bad-formed HTML what we're dealing with. For instance: heise.de a bit worst but usable. slashdot.org renders ok. sf.net worst but usable. Please bear in mind that now dillo can diagnose these errors at render time so, as a user, now you can send a meaningful error report to a site's webmaster! (for instance slashdot is diagnosed on-the-fly). Our experience is that most webmasters welcome this reports. Finally, remember that you can turn off the HTML error messages show_html_wanings=NO and that you can fall back to the old parser: use_old_parser=YES Enjoy! (I hope ;) Jorge.-

Nov. 11, 2003

[RFC] Quo Vadis Dillo

by Frank de Lange

Hi'all, Now that the last release of the patches seem to work (number 13 was less of a success...)... Where do we want to be tomorrow? What needs to be added/changed to improve Dillo? Should the tab/frame/etcetera + Indan's patch + ??? be forked into an 'experimental' version, somewhat like the Sylpheed MUA was forked into Sylpheed-claws? Talking about my patch, what does need improvement? Some ideas: - select contents of location bar/search field when they are focused (DONE, in next version) - make the 'search the web' popup disappear when popup_dialogs=NO, replace it with a non_popup version or use the location bar for search (like several other browsers do) - more key bindings (replacing current key handling where applicable) - remove compile options for tabs and frames, make tabs/frames standard? [ PDA/embedded developers: is this OK with you? ] - ??? 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. 11, 2003

Re: Keybd 3 patch

by Frank de Lange

Jorge Arellano Cid wrote: >Hi Frank, > > I just noticed the newes keyboard navigation patch in the >mailing list. Please tell me if this problems were fixed or if a >should wait the next version before aiming to a merge: > > These problems are gone. I have completely overhauled the internals so that focus always is in sync with the rest of Dillo. Which just happened to fix the problem Sebastian noticed... I'd say, wait a week or so to see if any issues crop up. If all seems OK commit the patch. [ LIST: please give keyboard navigation, on either version of the patch, a workout. This needs some testing if it is to be part of mainstream Dillo. Try it in frame sites, try navigatin between frames with Tab/Shift-Tab, try the keyboard bindings, etc. ] By the way, the patch also contains a fix to a problem with dpid/Makefile.am (which did not honour DESTDIR on installation, messing up make install for non-root users). Let me know when you apply this, because it will affect the tab/frame/kbnav patch s well. 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. 11, 2003

Re: [Dillo-dev] HTTPS Patch

by Paul Pelzl

On Tue, Nov 11, 2003 at 10:37:41AM +0000, robert w hall wrote: > To reiterate > It would be _really nice_ if all these links to these very useful > patches were findable from the dillo main site :-) Perhaps some enterprising individual (not me) would be interested in hosting some sort of Dillo Wiki. Any patch authors could then post links on the wiki without having to bother website maintainers... Paul

Nov. 11, 2003

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

> Note: When Indian continues to maintain his https patch i'll probably do > not bother with mine, lazy as i am... Also the Indian's idea of cleaning > up ccc into something more easy to understand is nice (current ccc has at > least one bad property - it is _hard_ to understand what goes on in it). It is my intention to keep my https up to date, it will be in a couple of days. I'm more or less waiting till Jorge tells me that I may go ahead with writing a patch that does that IOData and GDK stuff, or that he wants to keep it as it is now. That way it's clear for me what I can do, and how the more final version of my https patch should look like. I started documenting how the CCC functions are used currently in Dillo. After having it clear what happens now it's easier to see how to improve it, and what's wrong with the existing implementation. I do not know how hard it is to manage an experimental CVS branch, it has advantages and disadvantages. One pro is that the patches always work with eachother, because they use the same code, but that also means that the patches won't work seperately, that is, there is just an extended Dillo version, and no real patches anymore. It is very good to work with a stable code base, because then it's clear that all the encountered bugs are caused by your code, and not by someone else's code. Also it's useful when the base code doesn't change that much, especially when the patch is young. It is easier to keep the code up to date when it has it's own cvs branch, but on the other hand it could also mean that if someone drops his code and stops working on it, that someone else need to keep it up to date. Altogether quite risky. Of course everything is much simpler when only a few people use the alternative branch, it shouldn't be a dump place for never updated patches (tiny ones are ok of course). I think it will be only succesful when the branch is used only for things that have a chance to come in the official Dillo, as a sort of testing and developing place. Otherwise it will be very hard to keep it in sync with the official Dillo version, and the changes will only become greater after a while. Greetings, Indan

Nov. 11, 2003

Re: [Dillo-dev] HTTPS Patch

by robert w hall

In message <Pine.LNX.4.58.0311111201430.31566(a)kiku.itsise>, Madis Janson <madis(a)ats.cyber.ee> writes >you can use my patch for 0.7.3 until something better appears... > >http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz-wtab.diff.bz2 >http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz.html > To reiterate It would be _really nice_ if all these links to these very useful patches were findable from the dillo main site :-) -- robert w hall

Nov. 11, 2003