Add Head/Tail filtering of log for more efficient searches

[ddb4github]

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
Suggest use "Head lines" for "Display Order => Oldest First'
And keep current 'Tail lines" for "Display Order => Newest First'

[netniV]

Can you be more explainatory? As far as I am aware, that is exactly how it works.

[ddb4github]

Current "Logs(tab)" design is:

• tail some lines of selected cacti.log file, then show them by timestamp.
• head of selected cacti.log is not able to display by current filter combination.

My idea is:

• head or tail some lines of selected cacti.log, then show them by timestamp.
• Then we can freely read logfile whatever get from head or tail, display them by ordest or newest first.
  Like
  

My Case is:

- When I found my cacti have some problem around midnight 00:00,  I want to check tail of
  yesterday cacti.log-<date> and head of today cacti.log;
- I checked tail of last cacti.log by "Logs(tab) ->  (Display Order=Newest First)"
- I get few confusion when I want to check head of today cacti.log by  "Logs --> (Display Order=Oldest First)"

[netniV]

I think introducing the Head/Tail options would potentially speed up some searches but since the number of rows is linked to the filtered results of a search... it could get extremely confusing and lead to misunderstanding of what's being displayed in the results if we were to also add head/tail filtering. Some would expect the 500 to be maximum number of lines displayed after filtering, others the number trimmed before filtering even starts.

If there was a way to automatically scroll from one log file to another, that would make life easier.

[netniV]

So currently, having just been through this to add a feature to 1.3, the code loops through every line in the file to determine if it should display it and get an accurate line count. Once that is done, it then calculates the number of pages it would have from the displayed lines and then caclulates the start line and the end line.

With all that info, it then reads the file for a second time and displays those appropriate lines that should be displayed. Currently, the code actually calculates whether to display a line twice so I have speeded that be up in 1.3 by caching the result. You may not notice that speed difference though as it would be tiny, especially given the following enhancement that may have an opposite effect:

See #3679 and its associated commit for more info.

[TheWitness]

This is resolved now.