Bring back the poster/group/size toolbar?

Forum to report beta release bugs and discuss the latest beta releases with other users.
• If reporting a beta release bug, be sure read the bug reporting guidelines first.
Forum rules
IMPORTANT : Be sure to read the NewsLeecher forums policy before posting.

Do you want to bring back the Poster/MinKB/MaxKB/MinDays/MaxDays toolbar?

Yes. (I prefer the old toolbar)
34
89%
No. (I like the new 'advanced search' menu)
3
8%
Yes/No (I like the new menu, but it needs history of previous entries)
1
3%
 
Total votes: 38

User avatar
Quaraxkad
Posts: 311
Joined: Tue Aug 29, 2006 4:34 am

Re: Bring back the poster/group/size toolbar?

Post by Quaraxkad » Sun May 17, 2015 3:56 am

Your test is of absolutely no use. It proves or demonstrates nothing. The fact is that local filtering is done on the collection-level. SuperSearch and SuperLeech are done server-side at the article-level. Converting local filters in NL to also use the article-level would potentially require a huge backtracking of the cache format that gave us the grouped headers in the first place. If it was as simple as flipping a switch in the code as you seem to think, it never would have been changed in the first place.

kel
Posts: 46
Joined: Mon Aug 29, 2011 7:46 pm

Re: Bring back the poster/group/size toolbar?

Post by kel » Fri May 29, 2015 2:02 pm

kel wrote:Quaraxkad, I'd certainly be interested if your results to the suggested test were different than those I laid out and predicted.
kel wrote:If you don't think this is possible, perform this technical experiment:

Code: Select all

Download the headers for a group.  After done, completely pull your network cable.  Close Newsleecher.  Open Newsleecher. Open the group whose headers you downloaded in the article browser, pick any collection and expand it.  Notice all the files listed all while completely offline with no internet because you pulled your network cable.  The data is available to be presented, therefor it is available to be searched.  It will even show you which particular files of a collection are incomplete (further proving it has per file information).  As such, there exists no technical reason to not fix the search and filter system for local searches (there is a financial one, selling SuperSearch Service). 
I'll even add more here.   You can choose a single file from said collection and add just that file (not the whole collection) to your download queue for the next time you go online.   Further proving the point about the change in header caching and collection grouping does not prevent access to individual file information from within a collection.   Thus further proving that an individual file's information from within a collection is available and thus could be searched for.
Quaraxkad wrote:Your test is of absolutely no use. It proves or demonstrates nothing. The fact is that local filtering is done on the collection-level. SuperSearch and SuperLeech are done server-side at the article-level. Converting local filters in NL to also use the article-level would potentially require a huge backtracking of the cache format that gave us the grouped headers in the first place. If it was as simple as flipping a switch in the code as you seem to think, it never would have been changed in the first place.
It proves and demonstrates that per file information within collections exists locally, per file information within collections can be accessed locally, and thus search could be changed/fixed to find individual files in collections locally.   If you cannot understand since the program has the data to display & access locally down to the per file level within collections, then code could be written to search that same data locally then you have no business commenting on requests.

It would require a rewrite to how local searches work (a rewrite that was supposed to have been done before 4.0 went final when the new caching was introduced).   Such searches would indeed be slower since they'd end up being less optimized, but there is nothing technically preventing the exact type of recode I suggested, and at the code level I could even think of ways to optimize (such as instead of doing 2 passes, also check collection names without the common (part#, rar, zip, ### at the end) extensions on the first pass and if matched look within the collections right away).   It clearly doesn't require a rework of the caching format else it would be IMPOSSIBLE to display & access the data within collections locally down to the per file level, but does require some rework of local search which had been stated was going to be done/fixed back in 4.0 before it went final when the new header caching and collection system was introduced.

I must come to the conclusion by the fact you ignored the basic premise of 'the software has the data to display & access locally down to the per file level within collections, as such code can be written to search locally down to the per file level within collections', now you are just trolling or failed to understand the point.   We're done for now if you have to dismiss facts as meaningless which can be tested and proven by anyone with eyes.   If you have to ignore your own eyes going on to say seeing the data locally doesn't show the article information exists locally, then one can only come to the conclusion you are trolling or failed to understand point and issue.   All further comments from you will be ignored until you can give a technical reason how the program can display & access the data locally down to the per file level within collections, but it is impossible to write code that would be able to search the data locally down to the file level within collections.   I've proven the data exists locally down to the per file level within collections and can be accessed down to the per file level within collections locally contrary to your claims.    It is now up to you to prove your claim, not dismiss the evidence and facts.
-
Seriously wish the missing features of local search and the features that have been broken/removed from local search but left in or in some cases improved on the SuperSearch would be fixed/restored and improved upon on for local search. - More details: http://www.newsleecher.com/forum/viewtopic.php?f=9&p=127938#p127938

kel
Posts: 46
Joined: Mon Aug 29, 2011 7:46 pm

Re: Bring back search features

Post by kel » Wed Sep 12, 2018 2:26 pm

kel wrote:
Mon Aug 29, 2011 11:16 pm
Just had to kick in my vote for bringing back filter bar.

Missing options that used to exist for searching:

Searching by part of a file name or even just a file extension for items that are part of a collection/grouping.
Poster Excludes - Yeah you can Settings|Group Browsing|Filters:Poster, but most times you need to just filter from a set of results on your active search and not everywhere.
Hide/Show Downloaded
Hide/Show Binary
Hide/Show Non Binary
Hide/Show Incomplete

Local search has really been getting raked over the coals with vanishing features.

SS has also had some features removed but some still work.
Example of a feature that still works on SS, searching by all or part of a filename still works in SS.
Like alt.binaries.freeware, assume your news host has and sends headers inclusive of 2/9/2010.
Go to articles tab, search OpenOffice you'll find the collection for "OpenOffice_3_2". Expand the collection and confirm the existence of part05.rar in the collection.
Next try to search specifically for "OpenOffice_3_2.part05.rar" and notice nothing will show up.
now try searching for ".part05.rar" and again still won't see it.
Go to SS and try the same search for "OpenOffice_3_2.part05.rar" and you'll find the item as expected.
Next try ".part05.rar Group:alt.binaries.freeware" and you'll be able to find the part.
Now I can't find the post but back when 4.0 was in beta I remember reading this searching issue was supposed to be addressed before 4.0 went final. Either it was not addressed, or it was broken again in the 5.x line.
2018 and no improvement on Local Search for features moved only to SuperSearch to increase profits (while people had paid for those features in the main application/local). Meanwhile SS has been getting more and more like Swiss Cheese with the data holes.
kel wrote:And just another reason why these search features should be improved and restored to local searching.

SuperSearch has been massively missing articles and incomplete on many occasions without having filled in said incomplete header lists, especially the past week for some groups. So we get forced into using Supersearch due to vanishing features and functionality (some of which only now exist in SuperSeacrh) and then Supersearch itself is not maintained and complete. That is just rotten.

Please fix and restore the functionality to local searching.
kel wrote:
Sun May 03, 2015 7:22 pm
This could easily be worked around since the file details of what files are a part of the collection are saved. Exact matches on items like "OpenOffice_3_2.part05.rar" would be easy. Look for collections or loose files listed with that exact name just as the search currently does now. None found, second pass, search the collections for a collection with files named "OpenOffice_3_2" just as search does now, and then do a new check inside the collection for the ".part05.rar" as all the files part of a collection are saved with the saved headers.
If you don't think this is possible, perform this technical experiment:

Code: Select all

Download the headers for a group.  After done, completely pull your network cable.  Close Newsleecher.  Open Newsleecher. Open the group whose headers you downloaded in the article browser, pick any collection and expand it.  Notice all the files listed all while completely offline with no internet because you pulled your network cable.  The data is available to be presented, therefor it is available to be searched.  It will even show you which particular files of a collection are incomplete (further proving it has per file information).  As such, there exists no technical reason to not fix the search and filter system for local searches (there is a financial one, selling SuperSearch Service). 
Facts are awesome, especially when one can easily show the data to support them.

Options such as these can work in all the search types as they all (except poster exclude) get labelled currently when the result sets are displayed.
The same highlighting code that already exists and is in use today could be used as part of a hide/show code set:
Poster Excludes - Yeah you can Settings|Group Browsing|Filters:Poster, but most times you need to just filter from a set of results on your active search and not everywhere. In fact most times a global hide of particular posts identity by name/email is NOT preferred.
Hide/Show Downloaded
Hide/Show Binary
Hide/Show Non Binary
Hide/Show Incomplete

You can currently disable the highlighting without performing new searches, giving further evidence the same code could be used, is dynamic, and is a filter.

As I said, you are are being dismissive, abrasive, and rude by saying a set of features that used to exist, that people used, that people want back, and have no technical reason for not being returned (since the data, highlighting system and code could be used, exists, and works already) should not be returned or requested to be returned. Even when the evidence shows all are possible. All while failing to provide any reasoning or actual technical proofs as to why people should NOT want such features or such features are not feasible.
kel wrote:
Fri May 29, 2015 2:02 pm
I'll even add more here. You can choose a single file from said collection and add just that file (not the whole collection) to your download queue for the next time you go online. Further proving the point about the change in header caching and collection grouping does not prevent access to individual file information from within a collection. Thus further proving that an individual file's information from within a collection is available and thus could be searched for.
Quaraxkad wrote:Your test is of absolutely no use. It proves or demonstrates nothing. The fact is that local filtering is done on the collection-level. SuperSearch and SuperLeech are done server-side at the article-level. Converting local filters in NL to also use the article-level would potentially require a huge backtracking of the cache format that gave us the grouped headers in the first place. If it was as simple as flipping a switch in the code as you seem to think, it never would have been changed in the first place.
It proves and demonstrates that per file information within collections exists locally, per file information within collections can be accessed locally, and thus search could be changed/fixed to find individual files in collections locally. If you cannot understand since the program has the data to display & access locally down to the per file level within collections, then code could be written to search that same data locally then you have no business commenting on requests.

It would require a rewrite to how local searches work (a rewrite that was supposed to have been done before 4.0 went final when the new caching was introduced). Such searches would indeed be slower since they'd end up being less optimized, but there is nothing technically preventing the exact type of recode I suggested, and at the code level I could even think of ways to optimize (such as instead of doing 2 passes, also check collection names without the common (part#, rar, zip, ### at the end) extensions on the first pass and if matched look within the collections right away). It clearly doesn't require a rework of the caching format else it would be IMPOSSIBLE to display & access the data within collections locally down to the per file level, but does require some rework of local search which had been stated was going to be done/fixed back in 4.0 before it went final when the new header caching and collection system was introduced.
kel wrote:
Fri May 29, 2015 2:02 pm
the basic premise of 'the software has the data to display & access locally down to the per file level within collections, as such code can be written to search locally down to the per file level within collections
2018 and no improvement on Local Search for features moved only to SuperSearch to increase profits (while people had paid for those features in the main application/local). Meanwhile SS has been getting more and more like Swiss Cheese with the data holes.
-
Seriously wish the missing features of local search and the features that have been broken/removed from local search but left in or in some cases improved on the SuperSearch would be fixed/restored and improved upon on for local search. - More details: http://www.newsleecher.com/forum/viewtopic.php?f=9&p=127938#p127938

DILLON
Posts: 1
Joined: Sat May 11, 2019 10:00 am

Re: Bring back the poster/group/size toolbar?

Post by DILLON » Wed May 22, 2019 8:57 am

he old way was incredibly improved. I dont know, why there were continually old working things emptied, and displaced with new crap.

Post Reply