dialog: Support extra backend for bliss dialog
To allow to improve the dialogs without much effort, we could implement other backend than prompt toolkit, like Qt or web.
To aim that some improvement could be done.
- Simplify the data structure
-
Rework UserDlg
as dataclass (something flat) -
No need wtype -
No need inheritance
-
-
BlissDialog
should not depend on prompt toolkit-
We could think of a function to launch a dialog show_dialog(...)
, or maybe reusemenu(...)
-
This function could have the responsibility to serialize/deserialize mulatable object (like axis) that the dialog could contain
-
- Inconsistency
-
UserChoice defval
is right now an index (instead of a value) is not a very good idea, we could create aUserChoice2
to change this behaviour
-
- Normalize
BlissDialog
input-
The double list [[dialog]]
should be normalized with normalContainer
, this would help other's backend implementation -
pt_widget.display
could be implemented byBlissDialog
(or ashow_dialog
) (most of the time) -
pt_widget.*_dialog
could be implemented byBlissDialog
(or ashow_dialog
) (most of the time)
-
Also this is a very naive approach, because a need backend also means other way to interact. And here we are still stuck with very basic components.
Edited by Valentin Valls