Re: Scrolling patch!

On Mon, Oct 22, 2007 at 07:12:28PM -0300, Jorge Arellano Cid
wrote:
> Hi
> 
> > [...]
> > 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).
> 
>   Yes.
> 
>   I see this in two parts:
> 
>     1.- Remembering the scroll position in each bw's
nav_stack
>     2.- Making fragments push a new page (and not just
jump like now).
> 
>   Number 1.- is cooking here... 

  Number 1.- is commited!

  Note: this a long patch, and some glitches remain, but it
looks like
a good basis to improve upon.

  For instance, sometimes the page will not scroll to the
point were it was
(race condition, because most of the time it works), but the
scrolling pos.
is correctly kept and set, so it looks like a rendering
glitch.

-- 
  Cheers
  Jorge.-

_______________________________________________
Dillo-dev mailing list
Dillo-devdillo.org
http://lists.auriga.wearlab.de/cgi-bin/mailman/
listinfo/dillo-dev

Hi there,

  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!

  The  dw2  part  of  the  patch  is  attached  to this
email, so
Sebastian  can look at a minor change that looks like a fix
for a
hidden bug in the code...

  The patch is complete in CVS.

-- 
  Cheers
  Jorge.-

_______________________________________________
Dillo-dev mailing list
Dillo-devdillo.org
http://lists.auriga.wearlab.de/cgi-bin/mailman/
listinfo/dillo-dev

> Hi there,
> 
>   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!

Very nice! This was really missing.

  Johannes


_______________________________________________
Dillo-dev mailing list
Dillo-devdillo.org
http://lists.auriga.wearlab.de/cgi-bin/mailman/
listinfo/dillo-dev

On Fri, Oct 19, 2007 at 07:09:49PM -0300,
dillo-dev-bouncesdillo.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.diff.gz

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

_______________________________________________
Dillo-dev mailing list
Dillo-devdillo.org
http://lists.auriga.wearlab.de/cgi-bin/mailman/
listinfo/dillo-dev

Hi

> [...]
> 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).

  Yes.

  I see this in two parts:

    1.- Remembering the scroll position in each bw's
nav_stack
    2.- Making fragments push a new page (and not just jump
like now).

  Number 1.- is cooking here... 

-- 
  Cheers
  Jorge.-

_______________________________________________
Dillo-dev mailing list
Dillo-devdillo.org
http://lists.auriga.wearlab.de/cgi-bin/mailman/
listinfo/dillo-dev