Added few more thoughts
Looking for possible options to implement Offline Configuration Tool
requirement. please check and comment on it.
Configuration flow:
a) Task do_createconfig will generate data to configure. This serves as input
for configuration UI in OCT.
b) OCT UI will read that config data(from step(a)) to show it in GUI. User
configures using GUI inputs. Stores the user OCT configuration to OCT config
file. (Note user can directly modify the OCT config file, if User is familier
with it)
c) preinst, postinst, prerm, postrm, or a do_applyconfig(without bb files
reparse), can read OCT config file content (using a library) and apply
necessary changes.
Now we can look into possibility of using a specific configuration UI
implementation or a generic configuration model or combination of both.
1) Using a specific configuration GUI implementation:
do_createconfig generates the configuration information, in format like
datafile/xml and OCT reads this config data and provides a GUI to modify or
configure the features.
Pros: Detailed and complex GUIs can be supported which will be user friendly.
Ex: User management, network management etc.
Cons: As UI is static, it has to be modified to support new configuration
requirements
and UI modifications are generally complex.
2) A generic configuration model
do_createconfig generates configuration information with presentation
information included (like kconfig) and OCT reads this config information and
provides a generic UI implementation to modify or config the data like
menuconfig.
Pros:
- Generic and dynamic UI allowing the config menus to be added from
poky layers providing platform for configuration.
- New features can add new menus configuration options. Feature/package
enable and disable can control the configurtion menus.
- So configuration is shown only if feature/package is present/selected.
Cons:
- Generic method of implementing can be complex, specifically for
features where configuration is complex ex: User management, network
configuration.
- Custom or specific UI will be more user friendly and gives more
control to UI designer.
3) Combination of both
Complex features requiring more UI control can implement those features using
the method(1) and also providing the plaform for generic UI implementation.
OCT displays both UI configurations.
Ex: Static Image level features like User management, network config can be
implemented using method(1)
Service configuration, file system type, hist size configure etc can be
implemented using method(2).
Pros: Gives control to project to select the Complex and simple UIs.
Cons: Still needs a OCT UI change if method(1) feature need to be changed.
Drawing a line between complex and simple UI features may not very
straight forward.
Adding dynamic Complex UI is not possible to be added from poky layers.
Decision to provide a generic configuration model is mainly based on how much
we expect the configuration area to grow along with layers.
Image level features like user management, network management generally are not
dynamic features, so having a specific/custom UI implementation looks fine for
such features.
Regards,
Ramana
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
