[PATCH 14 of 20] hgweb: add ajaxScrollInit skeleton

[Alexander Plavin]

13.08.2013, 23:56, "Dave S" <snidely.too at gmail.com>:
> On Tue, Aug 13, 2013 at 11:26 AM, Alexander Plavin <alexander at plav.in> wrote:
>> 13.08.2013, 21:56, "Dave S" <snidely.too at 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 at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel