after quite long playing with achieving layout I decide to write down what I found.
To get nice box centered at middle of screen, but content in box left aligned use
It start with feature to adapt theme and our designed team found some strange alignment that they want to change in dialog layout.
So I start with trivial idea to have something like `Center(VBox(Left(*content)))` This sadly does not work as it in
the end create box over whole place and everything is ugly on left side. which looks strange ( see screenshots in ).
So next attempt with a bit of help is MarginBox. It looks fine and is shrinkable, so even on very small screen in ncurses
looks fine, but in qt it is hard to pick good sizes as with different resolutions it is never on center for all resolutions.
So good to make some spacing, but not to align box.
The proper solution is to use that stretches around that create spacing around box that is proportional and content in Box
then can left alignment with proper position.
Pro tip: If you do not want center but e.g. in one third, it is possible to use Weight to stretch. See documentation at 
There are many ways to teak the installer and people keep asking for more.
We are discussing use cases and ways to improve things on github:
If you have suggestions or more use cases or just want to stay in touch,
feel free to join the discussion.
2021 is here with a lot of interesting news, and YaST development is not
an exception. During the first sprint of the year we have worked on:
- Writing NetworkManager configuration during system installation
- Refining the mechanism to reuse existing EFI partitions
- Using better names to reference devices in the boot loader
- Improving AutoYaST behavior when no product has been specified
- Updating the roles offered by yast2-vm
- Many more small improvements here and there
Check the whole report at:
Ancor González Sosa
YaST Team at SUSE Linux GmbH
Today I opened an issue in yast2-installation for proposing to
(almost) start the installation process in the summary screen.
Benefits? Since the product control file of each product sets
reasonable defaults for most users (correct me if I'm wrong), the
installation steps could be shortened. Users should adjust just the
desired settings, nothing else. So, there is no reason for forcing them
to go through the whole installation options in a specific order
(unless, of course, for those dependent/coupled steps).
What do you think?
PS: I'm not sure if it has been discussed already in the past, but IMHO
it worth it to (re)evaluate it.
I've already mentioned this at some calls before, but this is actually
the right channel for discussing the idea.
I've seen many times before, that there is, for instance, a media layout
error, but we simply report that problem into the log and try to
continue. Usually it's nothing critical in our eyes. As an example,
we've recently seen that someone reported a missing Czech license in
installer. Ladislav found out that the license actually exists, but
wrongly uses "cz" instead of "cs" in its filename. The installer
actually reported a warning into the log. Something like "unknown
So, what is the problem? It could have been spotted 3 months earlier.
Plus it could have been fixed without us debugging the problem.
Proposed solution: In case of Y2DEBUG==1, raise an internal error or
rather show a pop-up error/warning message. This would not influence
common installations, but openQA would catch and record it. With a
little piece of work openQA could even skip it if needed. I would like
to have a separate Y2SOMETHING variable to control the behavior (by
default, X==1 in case of Y2DEBUG==1).
Obviously, this means more work now and from time to time for adding
such warning/error reports one by one. But that IMO pays off mid-to-long
term. At the end we could have more time to fix "our" bugs :)
What do you think?
As a result of small research about the current status of the YaST
Firstboot module, I have created a couple of issues in its Github
repository pointing out what I found wrong and my (sometimes wild)
ideas to fix/improve it.
I used the Github's issues feature to ease the interaction/discussion
since you can add there your thoughts/ideas as a comment. But, of
course, you can just reply to this thread if it is better for you.
So, let me invite you to follow the links you can find in the first
issue and give your feedback to both, commented gotchas and
openSUSE is looking for Google Summer of Code mentors again.
Just saying ;-)
-------- Forwarded Message --------
Subject: openSUSE - Google Summer of Code 2021
Date: Fri, 15 Jan 2021 14:55:59 +0100
From: ddemaio <ddemaio(a)suse.de>
To: opensuse-project(a)opensuse.org <opensuse-project(a)opensuse.org>
Applications for mentor organizations for the 2021 Google Summer of Code
will be from Jan. 29 - Feb. 19. The openSUSE Project has a long history
of participating as a mentor organization.
If you are interested in mentoring for your open source project, please
let me know so I can come up with a list of the people who are interested.
You would need to be committed to actively mentoring a student/s if
openSUSE becomes selected as a mentor organization.This will involve
keeping the student on task, actively communicating and mentoring them
and writing progress reports; I believe there are 2 reports the mentors
must write (mid-term review and final review).
If there are enough interested mentors to proceed with an application,
which I will let you know ASAP, potential mentors would need to update
the git repository (https://github.com/openSUSE/mentoring) for
https://101.opensuse.org, so I can submit the application.
If you have any questions, please let me know.