-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collect dt_control_log() and dt_toast_log() messages #16967
Collect dt_control_log() and dt_toast_log() messages #16967
Conversation
@jenshannoschwalm : The discussion was there #16611 |
Note that in this discussion I have even proposed a new button to be able to browse the log in a dialog. |
Right, #16611 was it. Although i personally think this here is sufficient. |
9ddc846
to
982bb91
Compare
b5a21e1
to
361d212
Compare
361d212
to
21577e9
Compare
d730bac
to
bc83e0a
Compare
Visibility of messges shown via dt_control_log(), dt_toast_log() and dt_toast_markup_log() is currently pretty bad as only the last shown message is shown if new ones are "pushed". This commit redesigns both buffers to be used as circular buffers, a new call to any function above will not display the last text but all available and not-yet ackknowledged (or disappered) messages for improved user readability.
bc83e0a
to
f202272
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's see how this works in real life... So merging for field testing. Thanks!
Yes, this is how it's been designed. Take it as a simple-solution proposal instead of collecting to a buffer/window that can be selected and opened. If this information collection is enough - instead of something more complex - i could add a preference option for "how many lines" to make this less "offensive". Otherwise - if this feature is not liked or not good enough by others, we can just revert. |
The number of lines shown for toast and log messages could be felt to be too offensive, this PR makes the number of lines choosable via preferences between 0 (down't show any) and a max of 8. Fixes comments in darktable-org#16967
The number of lines shown for toast and log messages could be felt to be too offensive, this PR makes the number of lines choosable via preferences between 0 (down't show any) and a max of 8. Fixes comments in darktable-org#16967
The number of lines shown for toast and log messages could be felt to be too offensive, this PR makes the number of lines choosable via preferences between 0 (down't show any) and a max of 15. Fixes comments about index errors and UI in darktable-org#16967
The number of lines shown for toast and log messages could be felt to be too offensive, this PR makes the number of lines a) 1 for toast b) 7 for log messages so there is a still a good chance to see every log message Fixes comments about index errors and UI in darktable-org#16967
The number of lines shown for toast and log messages could be felt to be too offensive, this PR makes the number of lines a) 1 for toast b) 7 for log messages so there is a still a good chance to see every log message Fixes comments about index errors and UI in #16967
The number of lines shown for toast and log messages could be felt to be too offensive, this PR makes the number of lines a) 1 for toast b) 7 for log messages so there is a still a good chance to see every log message Fixes comments about index errors and UI in darktable-org#16967
The number of lines shown for toast and log messages could be felt to be too offensive, this PR makes the number of lines a) 1 for toast b) 7 for log messages so there is a still a good chance to see every log message Fixes comments about index errors and UI in darktable-org#16967
Visibility of messages shown via
dt_control_log()
,dt_toast_log()
anddt_toast_markup_log()
is currently pretty bad as only the last shown message is shown if new ones are "pushed".This commit redesigns both buffers to be used as circular buffers, a new call to any function above will not display the last text but all available and not-yet ackknowledged (or disappeared) messages for improved user readability.
I think there was some discussion - can't find it right now - @TurboGit and @victoryforce iirc about some sort of larger log to be shown on request or something like that. This pr would be a very simply&safe redesign showing the last bunch of messages. No new strings, nothing "unusual" ...