This patch add an auto reload functionality when the user answers the ModOnHdPrompt accordingly
BUG:375361
BUG:377505
BUG:384384
FIXED-IN: 5.57
cullmann |
KTextEditor |
This patch add an auto reload functionality when the user answers the ModOnHdPrompt accordingly
BUG:375361
BUG:377505
BUG:384384
FIXED-IN: 5.57
375361 Request a behaviour like tail -f, to fulfil this would an option needed to scroll to the bottom of the view or move the cursor there.
However, some comments are against this at all, but I think it's no harm to have it.
384384 Say "no tail -f" but it sound so
Lint Skipped |
Unit Tests Skipped |
I would like to expand this patch by "auto reload when file is empty"
Sometimes I have the case that a session is opened where some files are gone due to work on a different branch. Switching the branch then caused to ask unneeded.
I think in principle the idea is sound.
But e.g., if you have have some file where one process writes to "fast" and it is "large" this will instantly lock up the application.
If we really want that, we need to: 1) ask the user e.g. if he wants to "auto-reload" this document on first change 2) have some timer based throtteling of the reloading to avoid lockups.
TODO(?)
Perhaps in addition to the message, one should just add a menu entry in Tools like "Read Only Mode", then the user can turn it of again.
And as said, I think one needs some timer to delay this to reload all x seconds, otherwise it might really stall.
Beside that: already nice
src/document/katedocument.h | ||
---|---|---|
1086 | What about this: make this a QAction with setCheckable(true). Then, you could reuse this action in the KTextEditor::Message. You can put this action then into the menu as well. ...then again, this could also be in tbe DocumentConfig just like many other settings we have. |
src/document/katedocument.h | ||
---|---|---|
1086 |
I'm working on a toggle action added to the View menu, so you can then enable that in advance. Surprising much effort :-/ but maybe I'm too stupid to do it in a simple way |
Just to be on the safe side: Does this also work, if you have two views visible showing the same document, and then the message appears? Does it also work, if you have two main windows showing the same document (View > New Window)?
src/view/kateview.cpp | ||
---|---|---|
238–239 ↗ | (On Diff #53613) | Could you use new-style signal/slot syntax for new code? :) |
Just to be on the safe side: Does this also work, if you have two views visible showing the same document, and then the message appears?
As said, poor tested., but what needs to be taken care? Normally these messages works well, so no idea why now not.
Does it also work, if you have two main windows showing the same document (View > New Window)?
Do you mean something else than this hint?
One issue may/is that in case of multible views/windows the actions only get synced after an reload event :-/
A tip how to solve this may helpful.
src/view/kateview.cpp | ||
---|---|---|
238–239 ↗ | (On Diff #53613) | Yeah, normally I do. Here I was not sure if it will keeped/accepted and only did lazy copy old code :-) BTW I'm surprised that such function (slot) didn't alrady exist. Instead will in the doc all views at some points directly called to update some things. See e.g. DocumentPrivate::documentReload:4310 |
TODO
#!/bin/bash # Usage: ./me |tee -a foobar while : do echo $(date -Ins) # delay 1sec, -t 0.1 delay 100msec read -t 1 -n 1 done
I think this works well enough to be added.
Could the "view_auto_follow" be implemented in a second review after this is commited?
I see there is some unresolved comment about action reuse, but I have no issue with this being commited as-is.
The feature is quiet nifty at least for "smaller" log files.
Could the "view_auto_follow" be implemented in a second review after this is commited?
I had remove this because it's somehow unhandy. When enabled you can't scroll up an look at some line without to be interrupted on next update. Now it works the smart way.
I see there is some unresolved comment about action reuse, but I have no issue with this being commited as-is.
Only these "Done" button was not klicked by me, but I think it's fixed as suggested by @dhaumann
Hmm, if the follow_.. stuff is removed, I think the sub-menu should go away, too.
The view_auto_reload should just be a top-level action, menus with single entries are strange ;)
Feel free to commit this with such a change.
As you see, not only the menu is changed, so I update this diff for your approval.
I think this works well enough to be added.
Harr, I found it now not good enough and spend some more time for this. Looks now nicely to me. The view still jumps slightly around but that may be go away by D17857, but not tested.
The menu is now ok and the feature still works for me.
And yes, the view still jumps a bit.
:P Funny enough for me it failed during testing more because of missing file notifications, should not have tried it on NFS.