On Fri, Oct 19, 2007 at 07:09:49PM -0300, dillo-dev-bounces@dillo.org wrote:
Here's a patch I wanted to add since a long time. Remembering the scroll position in a page. At least for me, it improves web browsing a lot!
Hi Jorge, this patch is really helpful!!! Maybe this is a good time to remember a patch of mine that I sent to Jorge (not to dillo-dev) more than 2 years ago (for Dillo1, of course). It changed the way the scrolling position is remembered so that, I think, dillo becomes more user friendly. In Dillo[12], the scrolling position is associated to a URL. This means that when displaying a page which is already in the history list, the old position is restored (no matter whether one uses the same window or another). With the patch, there is a separate scrolling position for each item in the history list. This means that each click on a link opens a page at the beginning (or at the position specified by the tag if there is one). I find this natural and sometimes even important: Consider some manual on several web pages where a link takes you to the definition of some function etc. If you click on a link, you don't care if the definition you want to see is on a page where you have been before (or maybe even the same page); you just want to open the new page there where the relevant information is, and going one page back should bring you to the page where you clicked on the link (even if it is the same page). The patch, which was against dillo1 CVS from 2005-01-05, can be found at http://www-fourier.ujf-grenoble.fr/~franz/dillo/dillo-CVS20050105-history.di... It is quite long because it changed some data types which were used everywhere, but I would like to point out that the resulting binary was not bigger than before (rather on the contrary, if I remember correctly). Below I include the email to Jorge where I explain the patch. As I've already written in another email, I'm quite busy with other things right now. Maybe this patch is still useful for others. ===== from email to Jorge, 2005-01-06 ===== DETAILED DESCRIPTION #################### FIXED BUGS: * BUG#569: Links to the same page are not recorded in the history list. * BUG#581: Reloading an URL with fragment identifier doesn't keep the page position. * The scrolling positions of a page are initialised to 0 (new: -1). This way one cannot safely tell whether a page has already been displayed. Test: Load an URL with fragment identifier, move to the very top of the page, click back button, click forward button. Now you are again at the anchor position. * Jumping to an anchor position in Nav_open_url is premature: Try to open some non-existing URL with fragment identifier #anchor. Then Dillo jumps to #anchor on the current page (if such an anchor exists). * Some others that I'm to lazy to describe. (Changing settings before the new page has arrived, see below.) CHANGES: * The real changes (described below) happen in nav.[ch], url.[ch], a_Web_dispatch_by_type and Html_close. The files history.[ch] are removed (see below). * Look first a Nav_open_url, a_Nav_expect_done and a_Web_dispatch_by_type. Now a_Nav_expect_done is called for every page (it should better be called a_Nav_open_url_finish). I've moved many things from Nav_open_url and a_Web_dispatch_by_type to a_Nav_expect_done, either because the code was similar, or because many things should only be done when the new page has arrived, for example saving the scrolling position of the current page or clearing the page menu. * In Nav_open_url, the navigation index nav_stack_ptr is not changed any more; instead the new position is stored in nav_expect_ptr. The reason is that otherwise one cannot save the current scrolling position in a_Nav_expect_done, because one doesn't know any more what was the current page. * The scrolling position is not stored in DilloUrl anymore, but in the navigation list (or stack). The list items are now of the new type NavItem (browser.h): /* navigation list item */ typedef struct { DilloUrl *url; const gchar *title; gint posx; /* -1 if page has not been displayed */ gint posy; } NavItem; This is also the place where form data should be kept so that Dillo remembers the filled-in values in the history list. (This is another patch I'm planning.) * Before, the navigation list only kept indices to the history list (history.h): typedef struct { DilloUrl *url; gchar *title; } H_Item; * Global history list */ static H_Item *history = NULL; static gint history_size = 0; /* [1 based] */ static gint history_size_max = 16; This additional referencing from the navigation list to the history list seemed to me very weird. I guess the history list is still from a time where Dillo didn't support multiple browser windows. As you can see, I've completely removed the history list. Consequence: The files history.[ch] are completely REMOVED. * BUG#581 actually had two reasons. One was located in nav.c (now fixed as a by-product), the other was the following: Restoring a previous scrolling position in a_Web_dispatch_by_type doesn't always work because at that time the page is being rendered. If there one calls a_Dw_gtk_scrolled_window_set_scrolling_position with a position that doesn't fit on the page (because rendering hasn't reached that position yet), the call is ignored. Current patch: Restore the scrolling position after rendering has been finished in Html_close. This works, but it is not optimal. A better solution would be as for anchors: Anchor positions can be set even if the anchor place hasn't been rendered yet. But I think this should be done by a dw_* specialist. CODE STATUS: * The code seems to be stable. * PROBLEM: When going through the history list, it takes at lot of time before the new page is displayed. (Try a long page like the HTML 3.2 spec.) Before, switching was only done after some time (I think when the page was rendered), now the switching is immediately, which gives you a blank page for a fraction of a second before the new page content is displayed. This is particularly noticable when you change between two pages with different background colours. * There is still a small scrolling position problem: Sometimes when I come back to a previously displayed page (using back/forward), the scrolling position has changed somewhat (up to 1/3 of a screen). But this happens with the unpatched Dillo as well, so it seems to be a separate bug. * The code might still need a bit polishing. ===== end email ===== Cheers, -- Matthias Franz