On Friday, February 11, 2011 03:06:00 pm Johannes Meixner wrote: > Hello, > > On Feb 11 13:12 Thomas Goettlicher wrote (excerpt): > > On Friday, February 11, 2011 12:18:12 pm Johannes Meixner wrote: > ... > > >> As an example assume there is a software which provides > >> a horrible stack of any kind of scripts to install it > >> plus any kind of GUI programs to configure it. > > ... > > >> What he wants to implement is a YaST module which provides > >> a frontend that asks for particular installation parameters > >> and calls each of the scripts one by one to get it installed > >> and then the YaST module runs the software's GUI programs > >> which configure the software. > >> > >> Would it be easy to implement such a YaST module? > > > > I hope I understood your use case correctly. > > Please correct me if I'm wrong. > > What about when a software's graphical GUI programs > have to be called from within a YaST module? That's where design clashes with reality. In this scenario you need to run the yast ui as user root. But more important: How to tunnel a gui program to a webyast module? From the design point you don't want this. Your example shows that reality looks different. :-(
> For a real-world example: > > In the YaST printer and scanner modules I provide that the user > can run HP's own graphical GUI setup program "hp-setup". > > HP's own tool "hp-setup" provides the only way to set up > HP all-in-one devices which require a proprietary plugin > downloaded from HP and installed on the end-user's machine > after the end-user confirmed a particular license agreement. > > Additionally "hp-setup" provides the best available support > to set up HP all-in-one network devices. > > I have neither the knowledge to deal with special cases > for HP devices nor do I have the time to re-implement > in YCP what "hp-setup" already provides "out-of-the-box" > nor am I legally allowed to implement something on my own > which deals with HP's proprietary stuff. > > > You have some shell scripts that need be be called with > > parameters and the return code indicates if everything went fine. > > You create a plugin for the commonlib or in Robert's notation > > a "configuration module" that abstracts these shell scripts. > > Let's say this module provides an api function bool > > flux::first_time_installation(parameter) it calls your > > shell script and returns its exit value. > > Why do I need to implement a wrapper function? > Does the commonlib not provide a ready-to-use module You split your code into two parts: business logic and user interface. In your specific case business logic is pretty simple as it just calls shell scripts. The ui doesn't even know that shell scripts are called it just the api's high level functions. > > which I could import and use like in my example code: > >> ------------------------------------------------------------------ > > ... > > >> import run external non-gui programs > > ... > > >> run first script > > or does the commonlib not provide a ready-to-use function like > in YCP "SCR::Execute(.target.bash_output, bash_commandline)"? The commonlib provides such a function but it's not directly used by ui modules, because running shell scripts isn't an abstract task. > > > Kind Regards > Johannes Meixner -- Thomas Goettlicher SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
