Mailinglist Archive: yast-devel (177 mails)

< Previous Next >
Re: [yast-devel] Direction of YaST Architecture?

Hello,

first a basic comment regarding "focus of mind":

Perhaps there is a misunderstanding about what the focus of mind
is of an individual contributor who likes to make a YaST module
for his specific setup task.

At least for me this is my focus of mind:

My interst and my focus of mind is only my specific setup task.


I am afraid but I am not at all intersted in YaST.

The programming environment which I use to implement
a tool which does the specific setup task is basically
only an obstacle between me and my goal to make the tool.

I have to overcome this obstacle to get the tool.

The easier it is to overcome this obstacle
the higher the likelihood that I actually implement
the tool with a particular programming environment.

Later - very much later - probably never - at the earliest
_after_ I had implemented my first usable version of the tool,
I may pay some attention to whatever brilliant design ideas
of the particular programming environment which I had already
chosen to make the tool.


What does this mean:

This does not mean that a brilliant design is useless.
Actually a brilliant design is required (see at the bottom).

But it does mean that first and foremost it must be easy
for an individual contributor to make his first usable version
of a setup tool for his specific setup task.

Later when he likes to enhace it, it is the right time
for the brilliant design which should make it again easy
for him to enhace his setup tool in whatever way he likes.



On Feb 10 12:44 Robert Schweikert wrote (excerpt):
This is probably the heart of the difference in the design approach. In
the system with the common lib, I as an implementer of a YaST module
depend on someone else to provide the functionality I need

I do not want this.
I want to implement what belongs to my setup task on my own.
I WANT TO BE FREE to implement whatever my specific setup task needs.


Well, beside the fact that I'd have to pick up YCP (the language) my
head was spinning after reading the tutorial for a few minutes because
of all the moving parts I had to consider for the module I wanted to
implement. My idea of doing this myself quickly deflated ...

I had exactly the same experience.
If I was not an employee of the same company which makes YaST,
I would for sure have given up to implement something for YaST.


I could see a tutorial (and now I am going of on a tangent, I realize
that) structured something like this.

- Your GUI code goes here: SOME_YaST-DIRECTORY
~ import yast3.gui_elements
~ use commonly known elements such as text area, buttons etc.
- Your backend code (code that touches configuration files) goes here:
SOME_OTHER_YaST-DIRECTORY inside a directory with a name to your
liking.
~ Take a look at the API documents found here: SOME-LINK
and try to reuse existing modules as much as possible
~ implement away and "Have a lot of Fun" :)

Hooray!
I understand this!
I want to have it simplified this way!


Why not have it simplified even more?

Why must the GUI code be separated from the "backend code"?
Why is it forbidden to implement a simple setup tool
in a single source code file like this:

- Your source code file your_module_name.yast3
goes here: SOME_YaST-DIRECTORY
~ import yast3.gui_elements
~ use commonly known elements such as text area, buttons etc.
~ Take a look at the API documents found here: SOME-LINK
and try to reuse existing modules as much as possible
~ implement away and "Have a lot of Fun" :)

If the GUI is shown on another machine than where my code runs,
why do I have to care?

All I have in mind is that my code "obviously" runs on the
same machine where the setup task actually happens.
Anything else is out of my focus of mind.

Why cannot a brilliant design how yast3.gui_elements is implemented
do what is needed so that I do not have to care?


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
--
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