Home Home > Tag > YaST
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Posts Tagged ‘YaST’

YaST releases independent of openSUSE releases?

November 7th, 2008 by

YaST is one of the cornerstones of openSUSE. It is developed for openSUSE and is released as part of openSUSE. There never was a release of YaST independent of openSUSE. Even the versioning of YaST is tied to openSUSE – the versions are 2.X.Y, where X is increased for every openSUSE release (17 for 11.1) and Y is simply a patch level, whenever a new fix or feature is added. Even more, every YaST package has its own versioning, so the only way to ensure you have a consistent set of YaST packages is via dependencies set in the .spec file of the YaST packages.

But in principle, YaST is a tool that can be used across distributions and there are people interested in this to happen. There are technical barriers to do releases independent of openSUSE (e.g. a lot of openSUSE-specific knowledge and behavior coded in YaST) as well as procedural. During past years, a lot of these non-technical issues has been addressed as we opened up the YaST development (re-licensing the code under GPL, opening up source control system and mailing lists, etc).

But still, there is one big thing left: YaST packages are released in concert with openSUSE. Yes, it is very convenient for openSUSE, but it makes it almost impossible to track the development during for people outside of our great distribution.

If one looks at the way the YaST packages are updated during the hotphase of an openSUSE release, the core parts of YaST (yast2-devtools, yast2-core, libyui, …) are rarely updated, they get a bug fix here and there. However, the distribution specific parts (yast2-pkg-bindings, yast2 common libraries, bootloader, storage, networking, …) get a fast flow of patch-level releases, typically several between openSUSE milestones.

Thus, the way forward I like the most right now is a compromise: a core YaST system should be released independently of the openSUSE release cycle while specific modules could keep their crescendo during openSUSE hot phase. How to do that?

For core YaST packages (a list to be defined) would be released independently of openSUSE and during hot phase, they would be handled the way other FOSS parts of openSUSE are – by patching the code in the package. The rest of the YaST, current practice would stay untouched.

There are clearly advantages – the YaST developers can do a proper release management of the core code and it is much more predictable how the core part of YaST will be released. On the other hand, people would need to be aware of the split.

However, I can imagine there is a lot of I did not realize. I’m definitely interested in comments about this topic.

Learning YaST (YCP language)

September 12th, 2008 by

My name is Alexander i`m a trainee at SUSE.

In my blog i will write about my experience with learning YCP (YaST Control Language)

First of all, most important part of learning is to have a good manual.

Here you have some links to start:

YCP book ->must read! (up to date)

YCP Reference book

YCP User interface referece book

YaST Development in General

Later i add additional info …..

Button Order in YaST: Trying to Make Peace with Both Worlds

August 28th, 2008 by

KDE and GNOME have different button orders. Like many desktop-related issues, this has been a subject of heated debates time and time again.

Where KDE uses something like this:

GNOME would use something like this:

Which one is right? Which one is wrong? There is no real answer to that; it will always be more a religious debate rather than an objective discussion.

YaST Button Order

So, which button order to choose for YaST?

For historical reasons, we used the KDE button order. But this has repeatedly started the same heated discussions as for KDE vs. GNOME, with the same results — which is, no tangible result, only something along the lines of “because we says so” (and didn’t you always hate it as a kid when mom or dad said that?).

YaST should not favour one of the major desktops over another. YaST should work well for all users. So, YaST should adapt to the environment it runs in.

YaST comes in different flavours. There is the graphical version: The YaST Qt UI (user interface) engine (Side note: The YaST Qt UI is not in any way KDE specific; Qt just happens to be a great toolkit for making graphical user interfaces, and KDE happens to use it, too. There is not one single line of KDE-specific code in the YaST Qt UI.).

There is also the text-based version, the YaST NCurses UI.

As an alternative graphical UI, there is also the YaST Gtk UI which uses the same widget toolkit (Gtk) as GNOME. That brings YaST closer to the GNOME crowd. At least, that’s the theory. Yet, that alone didn’t improve the situation in any way for this button order issue:

YaST dialogs are specified in a subset of the YaST-specific YCP scripting language. Those dialog descriptions include input fields, list boxes, headings, etc. as well as the logical arrangement of all those user interface elements (widgets, even though that term has seen a lot of misuse recently). And buttons, too, of course.

So, the arrangement of buttons was still fixed. The YaST Gtk UI couldn’t really do anything about changing that button order so it looked more GNOMEish.

This is now different. We introduced a new widget ButtonBox that abstracts exactly that. A YaST module developer now only specifies “there is a ButtonBox, this is where I put my buttons, and the ButtonBox will arrange them as appropriate”.

…for users…

So now it is possible for the first time to use the proper button order for each environment: GNOME button order for the Gtk UI, KDE button order for the Qt UI.

But there is more.

…for power users…

The Qt UI can now demonstrate the fact that it’s not KDE specific. It checks what environment it runs in and uses the appropriate button order: GNOME button order when running in GNOME and KDE button order for KDE (or other window managers).

It checks the $DESKTOP_SESSION and $WINDOWMANAGER environment variables to figure that out. But of course power users can still override that and set the $Y2_BUTTON_ORDER environment variable to “KDE” or “GNOME”.

…for YaST developers…

Of course, such a change doesn’t come over night. There is a very large amount of YaST code. I counted 69 .desktop files in my /usr/share/applications/YaST2 directory; that corresponds to 69 YaST modules. On my machine I have 432000+ lines of YCP code below /usr/share/YaST2 . Now try to figure out how many YaST dialogs that might be, and how many of them need to be converted to use that new ButtonBox mechanism.

Obviously, it’s a lot of stuff to change. So the change should not hurt the people doing the change more than it absolutely has to. Don’t forget, it’s not just working hours that have to be paid; it’s also working hours that can’t be spent on implementing other features or on fixing bugs. And any change (even more so changing code at so many places) means a possibility to introduce new bugs.

…trying to be smart…

So this ButtonBox mechanism was made to be smart, to re-use existing information (things that are already there in the code), to make good use of existing conventions.

In principle, using something like the ButtonBox means having to tell it which logical role each button has so it can be arranged according to the current button order’s conventions: Which button is the positive confirmation of a dialog (it might be “OK” or “Continue” or “Yes”, but it might also be someting like “Save” or “Print”), which one is the “safe escape” (“Cancel”, but sometimes also “No”), which one is the “Apply” button or the “Help” button, and which ones are just “other” buttons. Remember, YaST is being translated into some dozen languages, so just hard-coding the English button labels won’t do.

But we already have a mechanism that maps (translated!) button labels to function keys, and that mechanism does something similar: There is a list of commonly used button labels and what function key is to be used (in the NCurses UI) for them. For example, “OK”, “Continue”, “Yes”, “Next” all map to the F10 key, “Cancel” to F9, “Help” to F1.

Extending that thought some more, it makes sense to assume an “okButton” role for buttons that are otherwise assigned the F10 key, “cancelButton” for buttons that get the F9 key, etc.

Buttons in YCP each are assigned a widget ID. That ID is the “handle” by which a button is being referenced; this is what the YCP application receives when it is informed that the user clicked that key. When specifiying a layout with buttons, this looks (slightly simplified) like this:

UI::OpenDialog( 
    `VBox(
         `InputField(`id(`name  ), "Name" ),
         `InputField(`id(`street), "Street" ),
         ...
         `HBox(
               `PushButton(`id(`ok    ), "OK" ),
               `PushButton(`id(`apply ), "Apply" ),
               `PushButton(`id(`cancel), "Cancel" )
               )
         )
);

As shown in this example, a button with the “OK” role typically has an ID like `id(`ok), a “Cancel” button has `id(`cancel), an “Apply” button has `id(`apply). So this information is used, too, to figure out what role a button has.

Of course, there are still situations where the system needs to be explicitly told what button has which role: It’s hard to figure out in a generic way that a “Print” button or a “Save” button has the “okButton” role in a dialog. In that case, the YCP developer has to change the code to look like this:

`PushButton(`id(`print), `opt(`okButton), "Print" )

…the normal case…

But in many cases, the migration is as simple as replacing the `HBox() (the horizontal layout box) holding the buttons with `ButtonBox():

UI::OpenDialog( 
    `VBox(
         `InputField(`id(`name  ), "Name" ),
         `InputField(`id(`street), "Street" ),
         ...
         `ButtonBox(        // This is the only line that changed
               `PushButton(`id(`ok    ), "OK" ),
               `PushButton(`id(`apply ), "Apply" ),
               `PushButton(`id(`cancel), "Cancel" )
               )
         )
);

…taming the masses…

Just imagine doing only this little change in 432000+ lines of code – of course, only where such a `HBox() contains `PushButtons, not just blindly replacing all `HBoxes. And just changing it is not all there is to it; each dialog has to be tested, too. And that alone is not so trivial: A dialog might easily only be shown in very exotic cases, so the developers doing the test have to recreate each of those exotic cases just to see the dialog.

You see, masses of code are a dimension of complexity all of their own. Little things that look trivial to do gain a whole new meaning. Everybody can do this change in one or two places, but try to do it in someting as big as YaST — without introducing new bugs that would wreck other people’s system.

Yet, we do those kinds of changes, typically unnoticed by the user community. And those little things are what, if added up, make or break a system’s quality.

We don’t take such decisions lightly. But we felt that in this specific case (the button order) the gain would be worth the pain: Users should feel at home in the tools we provide. And having the buttons where you are used to is part of this feeling at home.

Further Reading

http://en.opensuse.org/YaST/Development/Misc/Button_Order

YaST module the C++ way

July 15th, 2008 by

From May 30th to July 4th we had a YaST workshop in Nuremberg. The workshop was basically a hackshop as we wanted to work on cool and new things for YaST during this week.

There is one big change in YaST in openSUSE 11.0 – yea, we found out that there are even more colors than gray, ok – but there is one that is not really visible to the end-user. Stefan Hundhammer, maintainer our YaST UI, completely separated the UI from the rest of the YaST infrastructure. This now makes it possible to use the UI directly, from anywhere, independent from our YaST-own-language YCP. So with a team of four hackers we wanted to prove that we can write a YaST module in plain C++ using the new modularized UI directly. And here is the outcome:

We went for rewriting the registration module (well, we chose it because I know it well, as I am the maintainer, and it will change anyhow for the next release). This module is not that integrated in the overall YCP world, so it should be feasible. First we had to find an alternative way to access system configuration files, as this is done by so-called SCR agents in YCP. To make life easier (and future development faster) we had to look for a replacement of our YCP Wizard Seqencer. And of course we redesigned all dialogs to make them more intuitive.

We solved all the issues and now have

  • a wrapper class for accessing different configuration files (currently only ini files)
  • an automatic wizard sequencer equivalent (using the advantages of an object oriented language, btw YCP is not)
  • three clear and intuitive dialogs, every user should understand

And as everybody wants to see screenshots, here they are:

Configure Update Source Send Hardware Information Register for Installation Support

The code is just a proof of concept and not yet reusable for new YaST modules but everything we wanted to show works great. We will continue to work on such kind of modules and in that process move the generic parts out into single libraries so that they can be reused and even may be exposed to scripting languages.

Writing YaST module this way has lots of advantages

  • YaST modules evolved into the object oriented world and can make use of it (the automatic sequencer is the first benefit)
  • the code is reusable
  • a huge bunch of documentation and lots of tools exist for C++
  • its a compiled language and has a better performance than an interpreted one
  • we can bind automatically to the most important scripting languages and give them access to the modules logic

If you are interested in the source code, have a look at my svn repo and if you want to help join the team and contact us on our mailinglist.