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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org