Patchwork [14,of,20] hgweb: add ajaxScrollInit skeleton

login
register
mail settings
Submitter Alexander Plavin
Date Aug. 9, 2013, 6:57 p.m.
Message ID <f28ca736646cf582ef71.1376074659@debian-alexander.dolgopa>
Download mbox | patch
Permalink /patch/2120/
State Changes Requested
Headers show

Comments

Alexander Plavin - Aug. 9, 2013, 6:57 p.m.
# HG changeset patch
# User Alexander Plavin <alexander@plav.in>
# Date 1376061308 -14400
#      Fri Aug 09 19:15:08 2013 +0400
# Node ID f28ca736646cf582ef71b518b995a1d63c40849a
# Parent  015d43fca74b12c5c79ca14683d375dc9675fdd2
hgweb: add ajaxScrollInit skeleton

This piece of code handles onscroll event and makes request to load next page
of entries, but doesn't actually add the loaded entries to the DOM tree yet.
Laurens Holst - Aug. 10, 2013, 1:22 p.m.
Op 09-08-13 20:57, Alexander Plavin schreef:
> # HG changeset patch
> # User Alexander Plavin <alexander@plav.in>
> # Date 1376061308 -14400
> #      Fri Aug 09 19:15:08 2013 +0400
> # Node ID f28ca736646cf582ef71b518b995a1d63c40849a
> # Parent  015d43fca74b12c5c79ca14683d375dc9675fdd2
> hgweb: add ajaxScrollInit skeleton
>
> This piece of code handles onscroll event and makes request to load next page
> of entries, but doesn't actually add the loaded entries to the DOM tree yet.

If I look at the bottom of the shortlog (e.g. 
http://hg.plav.in/hg/shortlog/1215bf60468f), every time I scroll down it 
keeps loading even though there is nothing to see anymore.

Worse, even when scrolling by a few pixels it fires up multiple 
requests. That’s a good way to get DoSsed :).

You should stop loading more entries when there aren’t any more to display.

> diff -r 015d43fca74b -r f28ca736646c mercurial/templates/static/mercurial.js
> --- a/mercurial/templates/static/mercurial.js	Fri Aug 09 22:48:44 2013 +0400
> +++ b/mercurial/templates/static/mercurial.js	Fri Aug 09 19:15:08 2013 +0400
> @@ -364,3 +364,38 @@
>           element.innerHTML += html;
>       }
>   }
> +
> +function ajaxScrollInit(urlFormat, lastHash, container) {
> +    updateInitiated = false;
> +
> +    window.onscroll = function () {
> +        if (updateInitiated) {
> +            return;
> +        }
> +
> +        var scrollHeight = document.documentElement.scrollHeight;
> +        var clientHeight = document.documentElement.clientHeight;
> +        var scrollTop = document.body.scrollTop
> +            || document.documentElement.scrollTop;
> +
> +        if (scrollHeight - (scrollTop + clientHeight) < 50) {
> +            updateInitiated = true;
> +
> +            makeRequest(
> +                format(urlFormat, {hash: lastHash, params: 'ajax=1'}),
> +                'GET',
> +                function onstart() {
> +                },
> +                function onsuccess(xml) {
> +                },
> +                function onerror(errorText) {
> +                },
> +                function oncomplete() {
> +                    updateInitiated = false;
> +                }
> +            );
> +        }
> +    };
> +
> +    onscroll();
> +}
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
Alexander Plavin - Aug. 12, 2013, 6:50 p.m.
10.08.2013, 17:22, "Laurens Holst" <laurens.nospam@grauw.nl>:
> Op 09-08-13 20:57, Alexander Plavin schreef:
>
>>  # HG changeset patch
>>  # User Alexander Plavin <alexander@plav.in>
>>  # Date 1376061308 -14400
>>  #      Fri Aug 09 19:15:08 2013 +0400
>>  # Node ID f28ca736646cf582ef71b518b995a1d63c40849a
>>  # Parent  015d43fca74b12c5c79ca14683d375dc9675fdd2
>>  hgweb: add ajaxScrollInit skeleton
>>
>>  This piece of code handles onscroll event and makes request to load next page
>>  of entries, but doesn't actually add the loaded entries to the DOM tree yet.
>
> If I look at the bottom of the shortlog (e.g.
> http://hg.plav.in/hg/shortlog/1215bf60468f), every time I scroll down it
> keeps loading even though there is nothing to see anymore.

By 'scrolling down' you mean 'scrolling a bit up and then down', right? :) As you can't scroll down after the end of the page.

>
> Worse, even when scrolling by a few pixels it fires up multiple
> requests. That’s a good way to get DoSsed :).

No new requests are issued while the already sent one hasn't completed, so there are no more than one request active at a time (and they aren't queued, just discarded).

>
> You should stop loading more entries when there aren’t any more to display.

Althrough it doesn't seem like a server performance/security/DoS issue for me, I'd agree to you here: users can think that the list just isn't loaded further due to error, and not due to its end.

>
>>  diff -r 015d43fca74b -r f28ca736646c mercurial/templates/static/mercurial.js
>>  --- a/mercurial/templates/static/mercurial.js Fri Aug 09 22:48:44 2013 +0400
>>  +++ b/mercurial/templates/static/mercurial.js Fri Aug 09 19:15:08 2013 +0400
>>  @@ -364,3 +364,38 @@
>>            element.innerHTML += html;
>>        }
>>    }
>>  +
>>  +function ajaxScrollInit(urlFormat, lastHash, container) {
>>  +    updateInitiated = false;
>>  +
>>  +    window.onscroll = function () {
>>  +        if (updateInitiated) {
>>  +            return;
>>  +        }
>>  +
>>  +        var scrollHeight = document.documentElement.scrollHeight;
>>  +        var clientHeight = document.documentElement.clientHeight;
>>  +        var scrollTop = document.body.scrollTop
>>  +            || document.documentElement.scrollTop;
>>  +
>>  +        if (scrollHeight - (scrollTop + clientHeight) < 50) {
>>  +            updateInitiated = true;
>>  +
>>  +            makeRequest(
>>  +                format(urlFormat, {hash: lastHash, params: 'ajax=1'}),
>>  +                'GET',
>>  +                function onstart() {
>>  +                },
>>  +                function onsuccess(xml) {
>>  +                },
>>  +                function onerror(errorText) {
>>  +                },
>>  +                function oncomplete() {
>>  +                    updateInitiated = false;
>>  +                }
>>  +            );
>>  +        }
>>  +    };
>>  +
>>  +    onscroll();
>>  +}
>>  _______________________________________________
>>  Mercurial-devel mailing list
>>  Mercurial-devel@selenic.com
>>  http://selenic.com/mailman/listinfo/mercurial-devel
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
Dave S - Aug. 12, 2013, 11:32 p.m.
(resend, to list this time)

On Mon, Aug 12, 2013 at 11:50 AM, Alexander Plavin <alexander@plav.in>
wrote:


10.08.2013, 17:22, "Laurens Holst" <laurens.nospam@grauw.nl>:
> Op 09-08-13 20:57, Alexander Plavin schreef:
>
>> # HG changeset patch
>> # User Alexander Plavin <alexander@plav.in>
>> # Date 1376061308 -14400
>> # Fri Aug 09 19:15:08 2013 +0400
>> # Node ID f28ca736646cf582ef71b518b995a1d63c40849a
>> # Parent 015d43fca74b12c5c79ca14683d375dc9675fdd2
>> hgweb: add ajaxScrollInit skeleton
>>
>> This piece of code handles onscroll event and makes request to load next
page
>> of entries, but doesn't actually add the loaded entries to the DOM tree
yet.
>
> If I look at the bottom of the shortlog (e.g.
> http://hg.plav.in/hg/shortlog/1215bf60468f), every time I scroll down it
> keeps loading even though there is nothing to see anymore.

By 'scrolling down' you mean 'scrolling a bit up and then down', right? :)
As you can't scroll down after the end of the page.

With a scroll wheel,I sometimes get a bounce or sag that gives the same
effect.
And it seems to be worse when you jump to tip, and scroll down; I can never
see the bottom of the page.

I haven't figured out who much the page is growing; Opera's "page info"
tool doesn't seem clear about this, and I haven't looked enough to have a
better tool.

Also, the less-more-+60 links seem to behave a little oddly, sometimes
giving just 1 or 2 lines of output. Hmmm, this happens consistently when I
jump to 0, but then there are no commits older than that, so it makes sense
(I guess). I haven't figured out again what I did to get 2 lines.

I do feel that I'm not sure where I am after scrolling down a few times to
load more lines; the date of the c/s is there of course, but the rev number
shown next to less-more is for the top of the page, isn't it? So I'm
guessing or counting on my thumbs for the revs at the bottom.


/dps
Alexander Plavin - Aug. 13, 2013, 8:34 a.m.
13.08.2013, 03:32, "Dave S" <snidely.too@gmail.com>:
> (resend, to list this time)
>
> On Mon, Aug 12, 2013 at 11:50 AM, Alexander Plavin <alexander@plav.in> wrote:
>
> 10.08.2013, 17:22, "Laurens Holst" <laurens.nospam@grauw.nl>:
>> Op 09-08-13 20:57, Alexander Plavin schreef:
>>
>>> # HG changeset patch
>>> # User Alexander Plavin <alexander@plav.in>
>>> # Date 1376061308 -14400
>>> # Fri Aug 09 19:15:08 2013 +0400
>>> # Node ID f28ca736646cf582ef71b518b995a1d63c40849a
>>> # Parent 015d43fca74b12c5c79ca14683d375dc9675fdd2
>>> hgweb: add ajaxScrollInit skeleton
>>>
>>> This piece of code handles onscroll event and makes request to load next page
>>> of entries, but doesn't actually add the loaded entries to the DOM tree yet.
>>
>> If I look at the bottom of the shortlog (e.g.
>> http://hg.plav.in/hg/shortlog/1215bf60468f), every time I scroll down it
>> keeps loading even though there is nothing to see anymore.
>
> By 'scrolling down' you mean 'scrolling a bit up and then down', right? :) As you can't scroll down after the end of the page.
>
> With a scroll wheel,I sometimes get a bounce or sag that gives the same effect.
> And it seems to be worse when you jump to tip, and scroll down; I can never see the bottom of the page.

Yes, you can't see the bottom of the page (the part which is below the list) until you reach the end of the list, but this is true for any implementation of infinite scrolling.

>
> I haven't figured out who much the page is growing; Opera's "page info" tool doesn't seem clear about this, and I haven't looked enough to have a better tool.

Don't get what you want to say here by 'who (how?) much the page is growing'. It grows 60 entries each time you scroll to the bottom.

>
> Also, the less-more-+60 links seem to behave a little oddly, sometimes giving just 1 or 2 lines of output. Hmmm, this happens consistently when I jump to 0, but then there are no commits older than that, so it makes sense (I guess). I haven't figured out again what I did to get 2 lines.

If I understand you correctly, this is the right behavior (and has nothing to do with infinite scrolling). If you open the page of shortlog where the first revision shown is 1st revision in the repo, it will show you only only this revision, same for 2nd and so on.

>
> I do feel that I'm not sure where I am after scrolling down a few times to load more lines; the date of the c/s is there of course, but the rev number shown next to less-more is for the top of the page, isn't it? So I'm guessing or counting on my thumbs for the revs at the bottom.

Revision number near the less-more links always relate to the beginning of the list, same as it was before.

>
> /dps
>
> ,
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
Alexander Plavin - Aug. 13, 2013, 6:26 p.m.
13.08.2013, 21:56, "Dave S" <snidely.too@gmail.com>:
> On Tue, Aug 13, 2013 at 1:34 AM, Alexander Plavin <alexander@plav.in> wrote:
>> 13.08.2013, 03:32, "Dave S" <snidely.too@gmail.com>:
>>> (resend, to list this time)
>
>>>
>>> I haven't figured out who much the page is growing; Opera's "page info" tool doesn't seem clear about this, and I haven't looked enough to have a better tool.
>
>> Don't get what you want to say here by 'who (how?) much the page is growing'. It grows 60 entries each time you scroll to the bottom.
>
> Yes, "how much"; I apologize for the proof-reading goof.  I couldn't tell if it was growing by 6 or 60 entries, and having a visual clue would have been nice.  I was also looking for Opera page-info to tell me, and it didn't ... at least not in a way I could recognize; I think the numbers it displayed reflected the initial load, and didn't change when I scolled down and triggered some more.

As for visual clue, I'm sorry: the deployment to the server wasn't complete (now it is). So, look again - there is a tiny horizontal line between 'pages'. And I don't get what you say about Opera page-info and what you want to see there.

>
> Also, I am not certain I prefer "grows by 60" to "moves the visible buffer by 60" (Android, and I guess MySQL, call this a "cursor"); in the latter case, the top of the window would be showing a different line after each dynamic load (and maybe with a cursor, you want to move 60/2, and also have to add dynamic up-scrolling).

I haven't seen any website using such technique, so it seems to be very unintuitive and unexpected behavior.

>
> Which behavior is better is probably highly subjective, and I don't claim to speak for the consensus (yet).
>
>>>
>>> Also, the less-more-+60 links seem to behave a little oddly, sometimes giving just 1 or 2 lines of output. Hmmm, this happens consistently when I jump to 0, but then there are no commits older than that, so it makes sense (I guess). I haven't figured out again what I did to get 2 lines.
>>
>> If I understand you correctly, this is the right behavior (and has nothing to do with infinite scrolling). If you open the page of shortlog where the first revision shown is 1st revision in the repo, it will show you only only this revision, same for 2nd and so on.
>
> I think that accounts for what I saw, although I don't think "2" was a choice that was offered in those links, so I'm not sure how I got there.
>
>>>
>>> I do feel that I'm not sure where I am after scrolling down a few times to load more lines; the date of the c/s is there of course, but the rev number shown next to less-more is for the top of the page, isn't it? So I'm guessing or counting on my thumbs for the revs at the bottom.
>>
>> Revision number near the less-more links always relate to the beginning of the list, same as it was before.
>
> Yes, but in the past there was always a fixed relationship between the top and bottom numbers, and even my grey cells could compute that, but they start thrashing when trying to figure out where I am with infinite  scrolling.

As for me, changing the revision number on top or bottom (or both) will confuse users and has little sense.

>
> /dps
>
> --
> test signature -- please apply at front gate on Tuesdays only.

P.S.: add list to the CC please :)
Dave S - Aug. 13, 2013, 7:56 p.m.
On Tue, Aug 13, 2013 at 11:26 AM, Alexander Plavin <alexander@plav.in>
wrote:
> 13.08.2013, 21:56, "Dave S" <snidely.too@gmail.com>:

> > Yes, "how much"; I apologize for the proof-reading goof. I couldn't
tell if it was
> > growing by 6 or 60 entries, and having a visual clue would have been
nice.
> > I was also looking for Opera page-info to tell me, and it didn't ...
> > at least not in a way I could recognize;
> > I think the numbers it displayed reflected the initial load,
> > and didn't change when I scolled down and triggered some more.
>
> As for visual clue, I'm sorry: the deployment to the server wasn't
complete (now it is).
> So, look again - there is a tiny horizontal line between 'pages'.

I don't see any dynamic loading this time ... at <
http://hg.plav.in/hg/shortlog/tip>
Did I go to the wrong place?

> And I don't get what you say about Opera page-info and what you want to
see there.

It's just a tool, like an odometer is a tool for measuring how far I drive.

> > Also, I am not certain I prefer "grows by 60" to "moves the visible
buffer by 60"
> > (Android, and I guess MySQL, call this a "cursor");
> > in the latter case, the top of the window would be showing a different
line after
> > each dynamic load (and maybe with a cursor, you want to move 60/2,
> > also have to add dynamic up-scrolling).

> I haven't seen any website using such technique, so it seems to be very
unintuitive
> and unexpected behavior.

No web site uses a "sliding window"? (to use another name for this sort of
technique)

I'm not sure I have an example to show you; Google search still uses fixed
length pages.
Google Image search appends at the bottom without sliding the top, so
that's one example
that uses the "stretchy window" model of your sample.


[...]
> > > Revision number near the less-more links always relate to the
beginning of the list,
> > > same as it was before.
>
> > Yes, but in the past there was always a fixed relationship between the
top and bottom numbers,
> > and even my grey cells could compute that, but they start thrashing
when trying to figure out
> > where I am with infinite scrolling.

> As for me, changing the revision number on top or bottom (or both) will
confuse users
> and has little sense.

Perhaps, but as you can tell from my whining, some of us will get confused
from not providing
additional clues.

> P.S.: add list to the CC please :)

I apologize. You'd think that catching my error once would have me watching
for it the next time,
instead of repeating the error again (my usenet habits expect the reply to
default to the list, and the mail program doesn't).

/dps

--
test signature -- please apply at front gate on Tuesdays only.
Alexander Plavin - Aug. 13, 2013, 8:13 p.m.
13.08.2013, 23:56, "Dave S" <snidely.too@gmail.com>:
> On Tue, Aug 13, 2013 at 11:26 AM, Alexander Plavin <alexander@plav.in> wrote:
>> 13.08.2013, 21:56, "Dave S" <snidely.too@gmail.com>:
>
>> > Yes, "how much"; I apologize for the proof-reading goof. I couldn't tell if it was
>> > growing by 6 or 60 entries, and having a visual clue would have been nice.
>> > I was also looking for Opera page-info to tell me, and it didn't ...
>> > at least not in a way I could recognize;
>> > I think the numbers it displayed reflected the initial load,
>> > and didn't change when I scolled down and triggered some more.
>>
>> As for visual clue, I'm sorry: the deployment to the server wasn't complete (now it is).
>> So, look again - there is a tiny horizontal line between 'pages'.
>
> I don't see any dynamic loading this time ... at <http://hg.plav.in/hg/shortlog/tip>
> Did I go to the wrong place?

I see dynamic loading at this URL with both chromium, opera, firefox (iceweasel). Try refreshing with Ctrl+F5.

>
>> And I don't get what you say about Opera page-info and what you want to see there.
>
> It's just a tool, like an odometer is a tool for measuring how far I drive.

Are you talking about the side-bar 'info' tab? I couldn't find anything else which is called 'page info' in opera. If so, it shouldn't show any changes.

>
>> > Also, I am not certain I prefer "grows by 60" to "moves the visible buffer by 60"
>> > (Android, and I guess MySQL, call this a "cursor");
>> > in the latter case, the top of the window would be showing a different line after
>> > each dynamic load (and maybe with a cursor, you want to move 60/2,
>> > also have to add dynamic up-scrolling).
>
>> I haven't seen any website using such technique, so it seems to be very unintuitive
>> and unexpected behavior.
>
> No web site uses a "sliding window"? (to use another name for this sort of technique)
>
> I'm not sure I have an example to show you; Google search still uses fixed length pages.
> Google Image search appends at the bottom without sliding the top, so that's one example
> that uses the "stretchy window" model of your sample.

Google search doesn't this kind of infinite scrolling, there is just a page switch. Almst the same behavior is when you just click on the forward/backward links in hg log (I mean +-N). The links not always work as expected for edited history and stripped csets (yet), but otherwise they seem ok if you want this. Google images use some kind of infinite scrolling on the other hand, and it's quite similar in behavior to mine one (not exactly).

>
> [...]
>> > > Revision number near the less-more links always relate to the beginning of the list,
>> > > same as it was before.
>>
>> > Yes, but in the past there was always a fixed relationship between the top and bottom numbers,
>> > and even my grey cells could compute that, but they start thrashing when trying to figure out
>> > where I am with infinite scrolling.
>
>> As for me, changing the revision number on top or bottom (or both) will confuse users
>> and has little sense.
>
> Perhaps, but as you can tell from my whining, some of us will get confused from not providing
> additional clues.

What would you suggest here? I'm almost certain that changing the numbers will confuse (much?) more.

>
>> P.S.: add list to the CC please :)
>
> I apologize. You'd think that catching my error once would have me watching for it the next time,
> instead of repeating the error again (my usenet habits expect the reply to default to the list, and the mail program doesn't).
>
> /dps
>
> --
> test signature -- please apply at front gate on Tuesdays only.
>
> ,
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
Dave S - Aug. 14, 2013, 2:41 a.m.
On Tue, Aug 13, 2013 at 1:13 PM, Alexander Plavin <alexander@plav.in> wrote:

>
>
> 13.08.2013, 23:56, "Dave S" <snidely.too@gmail.com>:
> > On Tue, Aug 13, 2013 at 11:26 AM, Alexander Plavin <alexander@plav.in>
> wrote:
> >> 13.08.2013, 21:56, "Dave S" <snidely.too@gmail.com>:
> >
> >> > Yes, "how much"; I apologize for the proof-reading goof. I couldn't
> tell if it was
> >> > growing by 6 or 60 entries, and having a visual clue would have been
> nice.
> >> > I was also looking for Opera page-info to tell me, and it didn't ...
> >> > at least not in a way I could recognize;
> >> > I think the numbers it displayed reflected the initial load,
> >> > and didn't change when I scolled down and triggered some more.
> >>
> >> As for visual clue, I'm sorry: the deployment to the server wasn't
> complete (now it is).
> >> So, look again - there is a tiny horizontal line between 'pages'.
> >
> > I don't see any dynamic loading this time ... at <
> http://hg.plav.in/hg/shortlog/tip>
> > Did I go to the wrong place?
>
> I see dynamic loading at this URL with both chromium, opera, firefox
> (iceweasel). Try refreshing with Ctrl+F5.
>
>
I must have accidentally tweaked a setting, still no joy with Opera, but
looks good with FF.  The line is nice.


> >
> >> And I don't get what you say about Opera page-info and what you want to
> see there.
> >
> > It's just a tool, like an odometer is a tool for measuring how far I
> drive.
>
> Are you talking about the side-bar 'info' tab? I couldn't find anything
> else which is called 'page info' in opera. If so, it shouldn't show any
> changes.
>
>
Page->Developer Tools->Page Info.
It shows a byte count, but it maybe doesn't update it for dynamic content.


> >
> >> > Also, I am not certain I prefer "grows by 60" to "moves the visible
> buffer by 60"
> >> > (Android, and I guess MySQL, call this a "cursor");
> >> > in the latter case, the top of the window would be showing a
> different line after
> >> > each dynamic load (and maybe with a cursor, you want to move 60/2,
> >> > also have to add dynamic up-scrolling).
> >
> >> I haven't seen any website using such technique, so it seems to be very
> unintuitive
> >> and unexpected behavior.
> >
> > No web site uses a "sliding window"? (to use another name for this sort
> of technique)
> >
> > I'm not sure I have an example to show you; Google search still uses
> fixed length pages.
> > Google Image search appends at the bottom without sliding the top, so
> that's one example
> > that uses the "stretchy window" model of your sample.
>
> Google search doesn't this kind of infinite scrolling, there is just a
> page switch. Almst the same behavior is when you just click on the
> forward/backward links in hg log (I mean +-N). The links not always work as
> expected for edited history and stripped csets (yet), but otherwise they
> seem ok if you want this. Google images use some kind of infinite scrolling
> on the other hand, and it's quite similar in behavior to mine one (not
> exactly).
>
>
Yes.


> >
> > [...]
> >> > > Revision number near the less-more links always relate to the
> beginning of the list,
> >> > > same as it was before.
> >>
> >> > Yes, but in the past there was always a fixed relationship between
> the top and bottom numbers,
> >> > and even my grey cells could compute that, but they start thrashing
> when trying to figure out
> >> > where I am with infinite scrolling.
> >
> >> As for me, changing the revision number on top or bottom (or both) will
> confuse users
> >> and has little sense.
> >
> > Perhaps, but as you can tell from my whining, some of us will get
> confused from not providing
> > additional clues.
>
> What would you suggest here? I'm almost certain that changing the numbers
> will confuse (much?) more.
>
>
Perhaps you could put something in the margin for the entry after the
horizontal line, or maybe just a tooltip when you hover over an entry.

I am, by the way, impressed by the work you've been doing on hgweb ... the
amount and quality are both inspiring.  To use an old sports phrase, you're
red hot and rolling!

/dps
Alexander Plavin - Aug. 14, 2013, 5:27 p.m.
14.08.2013, 06:41, "Dave S" <snidely.too@gmail.com>:
> On Tue, Aug 13, 2013 at 1:13 PM, Alexander Plavin <alexander@plav.in> wrote:
>> 13.08.2013, 23:56, "Dave S" <snidely.too@gmail.com>:
>>> On Tue, Aug 13, 2013 at 11:26 AM, Alexander Plavin <alexander@plav.in> wrote:
>>>> 13.08.2013, 21:56, "Dave S" <snidely.too@gmail.com>:
>>>
>>>> > Yes, "how much"; I apologize for the proof-reading goof. I couldn't tell if it was
>>>> > growing by 6 or 60 entries, and having a visual clue would have been nice.
>>>> > I was also looking for Opera page-info to tell me, and it didn't ...
>>>> > at least not in a way I could recognize;
>>>> > I think the numbers it displayed reflected the initial load,
>>>> > and didn't change when I scolled down and triggered some more.
>>>>
>>>> As for visual clue, I'm sorry: the deployment to the server wasn't complete (now it is).
>>>> So, look again - there is a tiny horizontal line between 'pages'.
>>>
>>> I don't see any dynamic loading this time ... at <http://hg.plav.in/hg/shortlog/tip>
>>> Did I go to the wrong place?
>>
>> I see dynamic loading at this URL with both chromium, opera, firefox (iceweasel). Try refreshing with Ctrl+F5.
>
> I must have accidentally tweaked a setting, still no joy with Opera, but looks good with FF.  The line is nice.

No idea why, may be js is off? :)

>>>
>>>> And I don't get what you say about Opera page-info and what you want to see there.
>>>
>>> It's just a tool, like an odometer is a tool for measuring how far I drive.
>>
>> Are you talking about the side-bar 'info' tab? I couldn't find anything else which is called 'page info' in opera. If so, it shouldn't show any changes.
>
> Page->Developer Tools->Page Info.
> It shows a byte count, but it maybe doesn't update it for dynamic content.

Yes, it's the same sidebar thing. Web developer can't force it to show actual byte count, as it shows the source html length which was downloaded.

>>>
>>>> > Also, I am not certain I prefer "grows by 60" to "moves the visible buffer by 60"
>>>> > (Android, and I guess MySQL, call this a "cursor");
>>>> > in the latter case, the top of the window would be showing a different line after
>>>> > each dynamic load (and maybe with a cursor, you want to move 60/2,
>>>> > also have to add dynamic up-scrolling).
>>>
>>>> I haven't seen any website using such technique, so it seems to be very unintuitive
>>>> and unexpected behavior.
>>>
>>> No web site uses a "sliding window"? (to use another name for this sort of technique)
>>>
>>> I'm not sure I have an example to show you; Google search still uses fixed length pages.
>>> Google Image search appends at the bottom without sliding the top, so that's one example
>>> that uses the "stretchy window" model of your sample.
>>
>> Google search doesn't this kind of infinite scrolling, there is just a page switch. Almst the same behavior is when you just click on the forward/backward links in hg log (I mean +-N). The links not always work as expected for edited history and stripped csets (yet), but otherwise they seem ok if you want this. Google images use some kind of infinite scrolling on the other hand, and it's quite similar in behavior to mine one (not exactly).
>
> Yes.
>
>>>
>>> [...]
>>>> > > Revision number near the less-more links always relate to the beginning of the list,
>>>> > > same as it was before.
>>>>
>>>> > Yes, but in the past there was always a fixed relationship between the top and bottom numbers,
>>>> > and even my grey cells could compute that, but they start thrashing when trying to figure out
>>>> > where I am with infinite scrolling.
>>>
>>>> As for me, changing the revision number on top or bottom (or both) will confuse users
>>>> and has little sense.
>>>
>>> Perhaps, but as you can tell from my whining, some of us will get confused from not providing
>>> additional clues.
>>
>> What would you suggest here? I'm almost certain that changing the numbers will confuse (much?) more.
>
> Perhaps you could put something in the margin for the entry after the horizontal line, or maybe just a tooltip when you hover over an entry.

Margins and/or other styles are easy to add/change and other themes creators/editors can simply change the corresponding CSS part. And what tooltip do you mean, with what information?

> I am, by the way, impressed by the work you've been doing on hgweb ... the amount and quality are both inspiring.  To use an old sports phrase, you're red hot and rolling!

Thanks :) By the way, I write small blog posts about my mercurial-related development: http://blog.plav.in/tags/Mercurial.

> /dps
>
> --
>
> test signature -- please apply at front gate on Tuesdays only.
Alexander Plavin - Aug. 14, 2013, 6:24 p.m.
14.08.2013, 22:19, "Dave S" <snidely.too@gmail.com>:

>  On Wed, Aug 14, 2013 at 10:27 AM, Alexander Plavin <alexander@plav.in> wrote:
>>  14.08.2013, 06:41, "Dave S" <snidely.too@gmail.com>:
>>>  I must have accidentally tweaked a setting, still no joy with Opera, but looks good with FF.  The line is nice.
>>  No idea why, may be js is off? :)
>  No, I think the VM I was running in was getting a bit twitchy about mouse events.
>>>>>>  And I don't get what you say about Opera page-info and what you want to see there.
>>>>>  It's just a tool, like an odometer is a tool for measuring how far I drive.
>>>>  Are you talking about the side-bar 'info' tab? I couldn't find anything else which is called 'page info' in opera. If so, it shouldn't show any changes.
>>>  Page->Developer Tools->Page Info.
>>>  It shows a byte count, but it maybe doesn't update it for dynamic content.
>>  Yes, it's the same sidebar thing. Web developer can't force it to show actual byte count, as it shows the source html length which was downloaded.
>  Ah, yes, it is.
>>>  Perhaps you could put something in the margin for the entry after the horizontal line, or maybe just a tooltip when you hover over an entry.
>>  Margins and/or other styles are easy to add/change and other themes creators/editors can simply change the corresponding CSS part. And what tooltip do you mean, with what information?
>  Well, the rev number is the key one I'm interested.  The hash is in the link, of course.  And I wouldn't mind Matt's suggestion of a commit message, but the rev number is probably something that can be done sooner.

As I understand, Matt wrote about commit message tooltips in another place, in annotation view. However, I agree that it would be nice to see them here too. But it's certainly another step and another issue, having not much relation to infinite scrolling.

>  /dps
>
>  --
>  test signature -- please apply at front gate on Tuesdays only.
Dave S - Aug. 15, 2013, 7:37 a.m.
On Wed, Aug 14, 2013 at 11:24 AM, Alexander Plavin <alexander@plav.in>wrote:

> 14.08.2013, 22:19, "Dave S" <snidely.too@gmail.com>:
>
> >  On Wed, Aug 14, 2013 at 10:27 AM, Alexander Plavin <alexander@plav.in>
> wrote:
> >>  14.08.2013, 06:41, "Dave S" <snidely.too@gmail.com>:
>


> >  Well, the rev number is the key one I'm interested.  The hash is in the
> link, of course.
>
> > And I wouldn't mind Matt's suggestion of a commit message, but the rev
number is probably
> >  something that can be done sooner.

>
> As I understand, Matt wrote about commit message tooltips in another
> place, in annotation view. However, I agree that it would be nice to see
> them here too. But it's certainly another step and another issue, having
> not much relation to infinite scrolling.
>
>
And the summary message is right there in front of me, which can stand in
for the commit message for now.

/dps
Dave S - Aug. 23, 2013, 6:38 p.m.
(You'd think I'd learn to send these properly)

---------- Forwarded message ----------
From: Dave S <snidely.too@gmail.com>
Date: Fri, Aug 23, 2013 at 10:56 AM
Subject: Re: [PATCH 14 of 20] hgweb: add ajaxScrollInit skeleton
To: Alexander Plavin <alexander@plav.in>



On Tue, Aug 13, 2013 at 10:56 AM, Dave S <snidely.too@gmail.com> wrote:

> On Tue, Aug 13, 2013 at 1:34 AM, Alexander Plavin <alexander@plav.in>wrote:
>
>>
>>
>> 13.08.2013, 03:32, "Dave S" <snidely.too@gmail.com>:
>> > (resend, to list this time)
>>
>
>
>> > I haven't figured out who much the page is growing; Opera's "page info"
>> tool doesn't seem clear about this, and I haven't looked enough to have a
>> better tool.
>>
>>
>
>> Don't get what you want to say here by 'who (how?) much the page is
>> growing'. It grows 60 entries each time you scroll to the bottom.
>>
>
> Yes, "how much"; I apologize for the proof-reading goof.  I couldn't tell
> if it was growing by 6 or 60 entries, and having a visual clue would have
> been nice.  I was also looking for Opera page-info to tell me, and it
> didn't ... at least not in a way I could recognize; I think the numbers it
> displayed reflected the initial load, and didn't change when I scolled down
> and triggered some more.
>
> Also, I am not certain I prefer "grows by 60" to "moves the visible buffer
> by 60" (Android, and I guess MySQL, call this a "cursor"); in the latter
> case, the top of the window would be showing a different line after each
> dynamic load (and maybe with a cursor, you want to move 60/2, and also have
> to add dynamic up-scrolling).
>
>
As an example of asynchronous completion, here's a little background on
"cursors" (which you may understand better than I; I was obviously being
loose in my usage).

<http://en.wikipedia.org/wiki/Cursor_%28databases%29>

What I was trying to use "cursor" to say, was having the display be a fixed
number of rows, but sliding down (or up) the full set of rows (I guess
another description of this would be something like a browser's viewport).

And this article has an interesting usage:

<
http://tech.sarathdr.com/android-app/convert-database-cursor-result-to-json-array-android-app-development/
>

"This might be use ful when you do some database applications with
phonegap. Phonegap storage class could be some times slow and difficult
handle. Then you can write a separate plugin to do the querying. If you use
database raw queries you will get the results as cursor data structure. The
below code converts that to json array."


But I can see that removing the top entries that were previously displayed,
and then restoring them when scrolling up, would add to the complications
of writing the code.

/dps

Patch

diff -r 015d43fca74b -r f28ca736646c mercurial/templates/static/mercurial.js
--- a/mercurial/templates/static/mercurial.js	Fri Aug 09 22:48:44 2013 +0400
+++ b/mercurial/templates/static/mercurial.js	Fri Aug 09 19:15:08 2013 +0400
@@ -364,3 +364,38 @@ 
         element.innerHTML += html;
     }
 }
+
+function ajaxScrollInit(urlFormat, lastHash, container) {
+    updateInitiated = false;
+
+    window.onscroll = function () {
+        if (updateInitiated) {
+            return;
+        }
+
+        var scrollHeight = document.documentElement.scrollHeight;
+        var clientHeight = document.documentElement.clientHeight;
+        var scrollTop = document.body.scrollTop
+            || document.documentElement.scrollTop;
+
+        if (scrollHeight - (scrollTop + clientHeight) < 50) {
+            updateInitiated = true;
+
+            makeRequest(
+                format(urlFormat, {hash: lastHash, params: 'ajax=1'}),
+                'GET',
+                function onstart() {
+                },
+                function onsuccess(xml) {
+                },
+                function onerror(errorText) {
+                },
+                function oncomplete() {
+                    updateInitiated = false;
+                }
+            );
+        }
+    };
+
+    onscroll();
+}