Re: [yast-devel] What is the best way to use AugeasTree in a dialog tree?
On Wed, 10 Jun 2020 20:32:25 -0600 "David Benjamin" <dbenjamin@ontario.k12.or.us> wrote:
Thank you.
So CWM is good? I thought I read it is being phased out.
Thanks again, David.
Well, it is not perfect and we are experimenting how to have object UI without need to load and store values, but for now I think it is the best representation of the object based UI. So we have two concepts there: 1. event based UI where you have defined how UI looks and event loop which react on user actions for whole dialog. Its advantage is that everything is together. Disadvantage is very low re-usability as it is all or nothing and often lead to just copy pasting of same code. Example in more modern code is in yast2-journal - https://github.com/yast/yast-journal/blob/master/src/lib/y2journal/query_dia... 2. widget based UI ( represented by object CWM ) which define each widget as object that itself handle user input on that widget. Its advantage is re-usability as you can you can just reuse widget that you need in different dialog. Disadvantage is that on dialog level you do not see immediatelly how it will react and need to check each widget. Example is e.g. bootloader module - widgets at https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/grub2... and dialog at https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/confi... Sadly we do not have now the one best way how to write UI and sometime we suffer from it as those two concepts is not so easy to mix. Josef
josef Reidinger <jreidinger@suse.cz> 06/10/20 4:29 PM >>> On Wed, 10 Jun 2020 12:21:06 -0600 "David Benjamin" <dbenjamin@ontario.k12.or.us> wrote:
Hello everyone,
I have data from a file that was parsed using CFA::AugeasParsser.
Can it be used in a dialog without translating from CFA::AugeasTree it to Yast::Term.Tree?
Hi David, sadly(?) it cannot be done. Usual work-flow is to have own model class that is child of CFA::BaseModel that provide access to variables you are interested ( as usually you do not want to present user everything in file to not overwhelm him ).
This model is then used as backend and in frontend you use various terms to represent widgets. As beside parsing, config file values often have its semantic and you want to help user to fill it correct. So e.g. for variables that are on/off you want to use checkbox, if it is local path, you want input field with Browse button that allows to select file on system, or int field for integer values. Also often configuration files has dependent values, like if value A is true, then value A1 is used, but if it is false, it is ignored. You can represent it in frontend by event handling that disable widget for A1 if A is unselected.
If you are interested in example code, just write and I can point you to some. ( also nowadays we use quite lot CWM widgets, which is object oriented way how to write widgets, so if you are interested, I can also point you to some examples and code ).
Thanks, David.
Josef
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (1)
-
josef Reidinger