openSUSE Lizards

Authors
Adam Jurkiewicz
Adrian Schröter (5)
Agustin Chavarria (1)
Akhil Laddha
Alex Barrios
Alex Minton
Alexander Naumov
Alexander Orlovskyy (3)
Alexey Eromenko
Alin M Elena (4)
Andrea Florio (14)
Andreas Jaeger (44)
Andreas Stieger (1)
Andreas van dem Helge
Andrej Semen
Andrew Wafaa (25)
Arvin Schnell (6)
Beineri2
Bernhard Wiedemann
Bharath Acharya
Bonnie Kurniawan
Brian G. Merrell
Bruno Friedmann
Carl Fletcher
Casual Programmer
Chang ChiaChin
Christoph Thiel
Christopher Hobbs (15)
Ciaran Farrell (2)
Claes Backstrom
Coly Li
Cristian Rodríguez
Daniel Bornkessel
David Bailey
David C. Rankin
Dean Hilkewich
Dinar Valeev (5)
Dirk Müller (1)
Dmitry Serpokryl (7)
Duncan Mac-Vicar
Enrique Herrera Noya
Eugene Pivnev
FabioMux (1)
Federico Lucifredi
Frank Lee
Gabriele Mohr
Gerrit Beine
Helman Rene Taleno Martinez
Helmut Schaa
Henne (6)
Herbert Graeber
Holgi (2)
Hubert Mantel (1)
Ioan Vancea
J. Daniel Schmidt (1)
Jaime Andrés Vélez Osorio
James Tremblay (7)
Jan Blunck (4)
Jan Loeser (1)
Jan Madsen (1)
Jan Nieuwenhuizen
Jan-Christoph Bornschlegel (3)
Jan-Simon Möller (19)
Javier Llorente (2)
Jigish Gohil (22)
Jiri Srain (1)
Jiří Suchomel (1)
Johan Kotze (5)
John Terpstra
Joop Boonen
José Oramas
Josef Reidinger (8)
Juergen Weigert (1)
Julio Vannini (7)
Justin Haygood
Kálmán Kéménczy
Kayo Hamid
Kevin Yeaux (10)
Klaas Freitag (21)
Klara Cihlarova
Klaus Kämpf
Klaus Singvogel
kl_eisbaer (10)
Lars Marowsky-Bree
Li Bin
Ludwig Nussel (6)
M. Edward (Ed) Borasky
M. Edwin Zakaria
M. Hill
Manuel Trujillo
Marcos David
Marcus Hüwe (8)
Marcus Meissner (1)
Marcus Moeller (1)
Marcus Schaefer (3)
Martin Lasarsch (8)
Martin Mohring (8)
Martin Schmiderer
Martin Schmidkunz
Masim "Vavai" Sugianto (20)
Matt Sealey
Mauro Parra-Miranda
Michael Andres (1)
Michael Löffler (3)
Michael Skiba
Michal Marek (3)
Michal Vyskocil (9)
Michal Zugec
Miguel Angel Barajas Hernandez
Mingxi Wu
mrdocs
Nikanth Karthikesan (2)
Oprea Lucian
Oswin Zulu
Peter Nixon
Peter Pöml (4)
Petr Mladek (32)
Petr Uzel (2)
Philipp Thomas
Pragnesh Radadiya
Raul Libório
Ravi Kumar
Ray Chen
Ray Wang (1)
Renato de Pontes Pereira
Ricardo Chung
Ricardo Varas Santana (6)
Richard Bos (5)
Robert Lihm
Roland Haidl
Roman Drahtmueller
Rossana Motta (1)
Rupert Horstkötter (10)
Sascha Manns (45)
Savin Alex V.
Sebastian Schöbinger (4)
Stanislav Visnovsky (7)
Stefan Haas (1)
Stefan Hundhammer (5)
Stefan Schubert (3)
Steffen Winterfeldt (4)
Stephan Kulow (10)
Suman Manjunath
Suresh Jayaraman (1)
Susanne Oberhauser (2)
Syamsul Qamar Ngabito
Thomas Göttlicher (4)
Thomas Jones
Thomas Schraitle (15)
Thruth Wang
Tuukka (11)
Ulrich Hecht
Vincenzo Barranco
Wilken Gottwalt
Will Stephenson (1)
Xin Wei Hu
Yuri Tsarev





 

YaST module the C++ way

1 Star2 Stars3 Stars4 Stars5 Stars (7 votes, average: 4.14 out of 5)
Loading ... Loading ...
Tuesday, July 15th, 2008 by J. Daniel Schmidt Digg!

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.


4 Comments

Comment by nobody
2008-07-16 05:34:51

Yea, it´s time to change color of YaST.It would be great.

Comment by HuHa
2008-07-17 14:05:20

Huh? You can do that yourself. Just use /usr/bin/qtconfig .

 
 
Comment by ryan
2008-08-10 21:31:22

The “System and Hardware Information” is a nice addition on the testing side. Will it also report successful or failed hardware installations to SUSE, or provide the user with options if a piece of hardware fails to install?

Comment by J. Daniel Schmidt
2008-08-18 14:36:39

Just a note: This module is not meant to be a “test all my hardware and its drivers and report any issues” module :)

The “System and Hardware Information” is no addition – it is already in the current registration module. But it never showed the data that would be sent. We just seprarated the workflow into 3 steps to make it more intuitive and in order to show the user, what actions will be performed.

The hardware data is basically the output of “hwinfo” – just go to your current registration module (aka. “Online Update Configuration”) and click on “Details” to see, what commands would be run if you wanted to send hardware data. There are no tests if a piece of hardware is failing or a driver is missing, we just collect the data that hwinfo outputs.
The data is used for statistics so we get an idea what hardware is important to support in future releases.

 
 

Sorry, the comment form is closed at this time.