Imgbrd-grabber: Endless Page mode for search results

[MasterPetrik]

This is the main suggestion in all my suggestion list. Time has come.

I suggest you to add auto paging of search results, as it done, for example in sankakucomplex.

Ok, I when I writed this text, by "auto paging" I meant not exectly AUTO changing pages feature, but variant, where you can infinity scroll one page down, and next page images will be added to the bottom of the page, instead of pages swithcing. But I will use auto paging term, just because I don't know another name of this feature.
So, would be more correct to describe my suggestion as "Endless Page"

It's obviously very convinient way to watch search results. And more easy then common page switching via next buttons. But I'm understand that it will be hard to make it.

And I'm realize, that these very-long-length pages will consume a lot of resources, compare to page switching, But for searchs with <500 results for example this way of showing results will help to watch all results much quicker and with ability to compare images from different pages with each other.

I still don't know optimal way to impliment Auto paging of search results in many source search, so I will try to describe how it can be implimnted in merged results mode or in single source search.

I like the way that uses sankakucomplex: after scroll page down, next page results appears at the bottom of the page. But of course in grabber it would work a bit different.

There is some related questions and possible solutions:

Problem1: How user can load next results.

Common for sites method with infinite page, where you need to just scroll down and page will auto add some content att the bottom of the page, so you will never see the bottom (the best example - Feed from facebook of another social network) won't work well in grabber. So we need another way to start loading next result.

I can suggest 2 ways to do that.

1. A little text at the bottom of the blank space of results grid. After pressing it, text will disappear and instead of it will be shows images from the next page.
   
   This way is good for users who like to click on buttons.

2. Mouse action. (You know that I'm very like mouse actions) But unlike browser version, I suggest you a little different solution: When user scroll down(via mouse wheel) results grid area, if he already scrolled at the bottom of the page, then if he move mouse wheel down twice, then images from the next page will be loaded to the bottom of results grid. Twice move rule will prevent misclicks.

You can ask me - Why we need another "next" button? We already have two!
But current "next" buttons are switches whole page from current to next. So you can't see old page images no more. But pressing "load more results" text, you will add new images to already existed images, so all images from two pages will be shown at the one page!
And this "load more results" text shouldn't be a button, because buttons are part of navigation, and they placed in GUI, and in results grid visually more logical will be text, than button. Because current Grid сontains only image, text and links information, so so new interactive element would be better make as colored text, I guess.

Both of these ways should work together to give user more ways to load next page by most comfortable way for him.

Problem2: How to add new images in existed grid

First of all, I need you to pay attention, that I expect to use Auto paging with resizable grids(number of images is not constant and depends og area width, and can be changed via resizing window)
There are two ways how this question can be solved. Please look at this image:

There are visualisation of two additional pages loaded to original page(20+20+20 = 60 images) via auto paging with two different ways.

First variant

First variant is used by sankaku, for each new page loaded there are starts new row. I prefer this variant, because It clearly shows you where which pages are. Moreover, you can visually count pages, see what number have a certain image on it's page. No need to write many text about this variant, you can just try it live on chan.sankakucomplex.com :

You can clearly say that there are 4 pages loaded, and with 9 images in a row.
But with resizing window, you can get and 5x4 grid, and 10x2 grid, there number of images in all rows will be the same for all rows.

This variant will be perfect for one-source-search(same images number for each page), and in future maybe for multiple sources search too.

Second variant

This variant adds images from next pages to already half-filled rows, so after addition, all rows still looks like onepiece, but it also looks like haotic bunch of images. for example, in one row fits 7 images:

Not very obvious separation, as you see... You can't tell, on what page was placed certain image, you cant even say for sertain where one page ends and starts another. I'm not recommend this way for normal search, but it will be perfect for merged results search, which main problem is different number of images for different pages. But Variant 2 solves this problem very well. Anyway there are no need to differ pages or somehing and it anyway will looks lika bunch of images, so adding auto paging will not harm it anyway)

Anyway, both of variants would work well with progressive rows filling, espessially for merged results mode auto paging.

Feel free to ask questions about possible details, If I explained something not clear.

[MasterPetrik]

Switching between auto paging mode and page switching mode.

I can suggest you an elegant solution for that. Give the user an ability to choose the way of loading next results right in the grid area, without any switchs or buttons in another GUI or going to the settings window.

User makes search request.
User gets first page with images.
At the bottom of this page appears text "Load more results".

there are two ways for user:

If he want to auto paging results, he press "Load more results" text or scroll mouse wheel down twice. Then "<" and ">" buttons will be instantly disabled and page will turns to auto paging mode.(reloading of tab, or re-search will cancel mode choise)

If he want to switch pages, then he just press ">" or "<" buttons and switches page to next\previous page. And on the next page he can switch to auto paging mode too, then auto paging will starts from 2 page instead of 1.

And of course this will need to add to setting checkbox, that disables auto paging mode from results completely, so it will remove "Load more results" text from every results page and will disable mouse wheel action for that. But normal condition should be activated by default auto paging variant(because it would not harm to current page swithing mode anyway), with an option of it disabling in settings.

[BarryMode]

The official name of the feature is, as you said, infinite scrolling. This may be of help in implementing it:
http://stackoverflow.com/questions/15095748/infinite-scrolling-of-a-qt-listview-in-qml

[Bionus]

@MasterPetrik I was replying the issues in latest-first tonight, sorry 😛

While I understand why variant 1 can be better, with the current system, variant 2 is the most straightforward solution to implement, especially after the changes made for the "continuous results" in merged mode. Especially for merged mode, where there would be a mix of 1 and 2.

http://stackoverflow.com/questions/15095748/infinite-scrolling-of-a-qt-listview-in-qml

That's QML so it's for mobile Qt (which I'm considering as a for-fun side project). But adding this feature to a desktop application is not very complicated: one just has to listen to the "the user scrolled" event, and if the user is already at the bottom but keeps trying, you load the next page.

[BarryMode]

I've used infinite scrolling before, but only with JS. I didn't even know there was such a thing as mobile Qt. Interesting.

[MasterPetrik]

While I understand why variant 1 can be better, with the current system, variant 2 is the most straightforward solution to implement, especially after the changes made for the "continuous results" in merged mode.

But... but... I said the same thing in the first post:

1 variant will be perfect for one-source-search(same images number for each page), and in future maybe for multiple sources search too.

I'm not recommend 2 variant for normal search, but it will be perfect for merged results search, which main problem is different number of images for different pages. But Variant 2 solves this problem very well.

So it will be great to implement both variants, but for different modes

especially after the changes made for the "continuous results" in merged mode.

aaand... I said that in first post too:

Anyway, both of variants would work well with progressive rows filling, espessially for merged results mode

P.S.
I had a strict plan to suggest you at first progressive rows filling, and after that suggest infinite scrolling(my main suggestion for grabber) So of course it complements of each other.

[BarryMode]

I would prefer it to be seamless myself but if you were wanting to see page separation with variant 2 @MasterPetrik, I would think this could be achieved with some sort of marker. It could be as simple as a bullet inbetween the two images that separate the pages. In that case, however, you'd think a line break could also be implemented in which case you would have variant 1. I'm pretty indifferent on the details, but it's still a cool feature request!

[MasterPetrik]

Especially for merged mode, where there would be a mix of 1 and 2.

In merged mode nothing from variant 1 is needed. So variant 2 will be perfect for it without any changes.
About mix of 1 and 2. This is impossible, and moreover, I guess we don't need it anyway in none of modes.

if you were wanting to see page separation with variant 2, I would think this could be achieved with some sort of marker. It could be as simple as a bullet inbetween the two images that separate the pages. In that case, however, you'd think a line break could also be implemented in which case you would have variant 1.

Heh, I already described why page separation for merged results is not really necessary too. Yes, in first post:

Variant 2 will be perfect for merged results search, which main problem is different number of images for different pages. But Variant 2 solves this problem very well. Anyway there are no need to differ pages or something and it anyway will looks like bunch of images, so adding auto paging will not harm it anyway)

so we don't need to use any separation in merged results mode, because "pages" in this mode doesn't means anything, it'a a technical necessity, because there are existed only many-pages mode in grabber, so merged results were separated to some pages too, but, in fact, there are nothing similar between current pages in merged results mode, they have different number of images, from different sources, in different proportions, so any pages separation for merged results isn't needed.

[BarryMode]

@MasterPetrik Ah, I thought you were wanting to be able to see the different pages in variant 2. My mistake.

[Zekken01]

So this is like google images with everything on one page.

[Bionus]

• [x] Button, merged results
• [x] Scroll, merged results
• [x] Button/scroll, non merged results
• [x] Disabled
• [x] Setting to choose between button, scroll, and disabled, default: disabled (for now as the feature is new)
• [x] Determined image order when re-displaying images after appending some
• [x] Results label above results in merged mode
• [x] Results label above results in non-merged mode

[BarryMode]

I wish I could add a thumbs up to the commits. Very cool.

[MasterPetrik]

Can't wait to test it when it will be done >_< keep it up!

[Zekken01]

so very close, ❤️

[Bionus]

If there are bugs with the implementation in 5.4.0a1, please create new issues to not over-clutter this one, thanks :smile:

[MasterPetrik]

If there are bugs with the implementation in 5.4.0a1, please create new issues to not over-clutter this one, thanks :smile:

Write about bugs with the implementation in 5.4.0a1 in separated issues. Got it. But closing this issue isn't a good idea. Considering that this function even isn't fully implemented yet, so you can't close it now, but only when it will be implemented not only for one-source mode, but for multiple source merged results too. Untill then this issue shouldn't be closed. So please reopen it.

P.S.
BTW, good job, it really works

[Bionus]

The point of my message was that the feature is supposed to be fully implemented. So if there's some case that doesn't work, it's a bug, which then deserves a new issue. :smile:

Especially since the case multiple merged sources was the first to be implemented, and therefore should work. It must have been broken by another change for non-merged results.

[MasterPetrik]

Especially since the case multiple merged sources was the first to be implemented, and therefore should work.

But it don't!
It work for one source results.
It work for one source merged results.
And even there I found at least one crash-bug and one other problem...(I will make separate issues)
But it completely don't work with multiple source merged results. Nothing.
No button in button mode, nothing when scroll in scroll mode.
So it work as normal pages mode with no signs of changes.

Bug it or somehing else, doesn't matter, the fact is: function is work only in 1\2 of modes now.