Hello, it wasn't that easy then I thought. :D I would like to give an error message to the user who is using the GUI. But not from the GUI code but from the cli backend. To be specific: In "snapshots.py::Snapshots.remove()" I want to fire an error and it should be displayed not only in terminal but in the GUI. It doesn't matter if it is a error-message-window or just a error-tooltip in the systray. I tried logger.error('my message') The message appears in the terminal but not in the GUI. On a first shot I would say a quick & dirty solution would be to check the return value here in the qt code: https://github.com/bit-team/backintime/blob/bcf4b9097842beb8c700f9f9c542ecd7... and then calling errorHandler() https://github.com/bit-team/backintime/blob/bcf4b9097842beb8c700f9f9c542ecd7... But isn't there a more generic/automatic solution? Kind Christian
In the same process and thread: 1. Using the return value is a simple and reliable way to indicate a final result of a function call. The return value may be a typical "magic" number or a result object containing a result message (possibly a list) and other information. Disadvantage: Many "if"s at the caller side may make the code harder to read 2. Generally exceptions should be thrown only for technical errors IMHO (eg. not to validate data and return an error). 3. A classical way of decoupled communication is the observer pattern (GUI viewmodel registers its "listener" functions at the "model" - here your Snapshots class - the model then calls the registered functions to inform the "listening functions" about things that happen - eg "finished taking snapshot", "drive not found" or "refresh the GUI please, data in the model has changed". An example of registering a listener is eg. here in the settingsdialog.py (so that config can inform "error" listeners): https://github.com/bit-team/backintime/blob/bcf4b9097842beb8c700f9f9c542ecd7... Out of process / async: A. D-Bus communication (not easy) B. Other Linux-specific IPC mechanisms (very technical/low-level) I'd suggest 1.) with an result object. This could be a new reusable class with - a list of messages - origin as technical representation (who created this -> method name, instance ID whatever) - origin in human readable form (eg "Snapshot xy"), - time stamp - ... In the GUI we currently have only two options to display this: 1. Status bar (exactly one line, may disappear when the next message flies even if the user didn't notice it) 2. Message boxes (blocking, very annoying IMHO, only good for severe problems) In the future I'd like to introduce an extra multi-line text field (or table widget) in the lower part of the GUI which could show the full history of all messages (scrollable) so that nothing is lost if you drink a coffee while taking a snapshot. ATM a message box is the best way to inform the user about "must see" errors... On Fri, 2022-10-14 at 11:28 +0000, c.buhtz@posteo.jp wrote:
I'd suggest 1.) with an result object.
How often may I change my opinion? ;-) I think 3. via an error listener is a really simple but powerful solution and since the config is (almost) everywhere it could be easy to reuse the config error handler (setErrorHandler + notifyError). The other thing is the "config is not really a singleton" problem (the error handler may be set in one instance but not in the other) On Fri, 2022-10-14 at 15:05 +0200, J. A. wrote:
Dear Jürgen, I agree with all your points. ;) On 2022-10-14 15:05 "J. A." <python@altfeld-im.de> wrote:
2. Generally exceptions should be thrown only for technical errors IMHO (eg. not to validate data and return an error).
That was what I had been thinking about. Because of that I modified my PR #1334 to not raise but just return a boolean.
3. A classical way of decoupled communication is the observer pattern
I'm aware of that and used it in some other projects. It is one of my far away goals on my TODO list.
2. Message boxes (blocking, very annoying IMHO, only good for severe problems)
I prefer this as a quick solution for the first time.
In the future I'd like to introduce an extra multi-line text field (or table widget) in the lower part of the GUI
Kind of a logging message window? Great idea and very easy to implement when we get rid of all the old-school stuff in the BIT code. ;) Thanks for your thoughts. Kind Christian
You could check how it's done in this instance: https://github.com/bit-team/backintime/issues/1118#issuecomment-1257213378 Or is the situation different here? Michael On 14.10.2022 13:28, c.buhtz@posteo.jp wrote:
In the same process and thread: 1. Using the return value is a simple and reliable way to indicate a final result of a function call. The return value may be a typical "magic" number or a result object containing a result message (possibly a list) and other information. Disadvantage: Many "if"s at the caller side may make the code harder to read 2. Generally exceptions should be thrown only for technical errors IMHO (eg. not to validate data and return an error). 3. A classical way of decoupled communication is the observer pattern (GUI viewmodel registers its "listener" functions at the "model" - here your Snapshots class - the model then calls the registered functions to inform the "listening functions" about things that happen - eg "finished taking snapshot", "drive not found" or "refresh the GUI please, data in the model has changed". An example of registering a listener is eg. here in the settingsdialog.py (so that config can inform "error" listeners): https://github.com/bit-team/backintime/blob/bcf4b9097842beb8c700f9f9c542ecd7... Out of process / async: A. D-Bus communication (not easy) B. Other Linux-specific IPC mechanisms (very technical/low-level) I'd suggest 1.) with an result object. This could be a new reusable class with - a list of messages - origin as technical representation (who created this -> method name, instance ID whatever) - origin in human readable form (eg "Snapshot xy"), - time stamp - ... In the GUI we currently have only two options to display this: 1. Status bar (exactly one line, may disappear when the next message flies even if the user didn't notice it) 2. Message boxes (blocking, very annoying IMHO, only good for severe problems) In the future I'd like to introduce an extra multi-line text field (or table widget) in the lower part of the GUI which could show the full history of all messages (scrollable) so that nothing is lost if you drink a coffee while taking a snapshot. ATM a message box is the best way to inform the user about "must see" errors... On Fri, 2022-10-14 at 11:28 +0000, c.buhtz@posteo.jp wrote:
I'd suggest 1.) with an result object.
How often may I change my opinion? ;-) I think 3. via an error listener is a really simple but powerful solution and since the config is (almost) everywhere it could be easy to reuse the config error handler (setErrorHandler + notifyError). The other thing is the "config is not really a singleton" problem (the error handler may be set in one instance but not in the other) On Fri, 2022-10-14 at 15:05 +0200, J. A. wrote:
Dear Jürgen, I agree with all your points. ;) On 2022-10-14 15:05 "J. A." <python@altfeld-im.de> wrote:
2. Generally exceptions should be thrown only for technical errors IMHO (eg. not to validate data and return an error).
That was what I had been thinking about. Because of that I modified my PR #1334 to not raise but just return a boolean.
3. A classical way of decoupled communication is the observer pattern
I'm aware of that and used it in some other projects. It is one of my far away goals on my TODO list.
2. Message boxes (blocking, very annoying IMHO, only good for severe problems)
I prefer this as a quick solution for the first time.
In the future I'd like to introduce an extra multi-line text field (or table widget) in the lower part of the GUI
Kind of a logging message window? Great idea and very easy to implement when we get rid of all the old-school stuff in the BIT code. ;) Thanks for your thoughts. Kind Christian
You could check how it's done in this instance: https://github.com/bit-team/backintime/issues/1118#issuecomment-1257213378 Or is the situation different here? Michael On 14.10.2022 13:28, c.buhtz@posteo.jp wrote:
participants (3)
-
c.buhtz＠posteo.jp -
J. A. -
Michael Büker