Mailinglist Archive: yast-devel (177 mails)

< Previous Next >
Re: [yast-devel] Direction of YaST Architecture?
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: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
List Navigation
This Thread
Follow Ups