Hi all,
some time ago we discussed where and how we should share
"Tips&Tricks" for YaST users and developers.
IIRC there was no clear conclusion so I decided to start
a wiki [1] to collect all our tricks we know or use.
For now it's just a place for dumping your ideas, links, short
howtos, etc... When we collect enough data we can probably
split it to several categories or move it somewhere else.
We just need the data first.
I have added there some my tricks from my personal "knowledgebase"
file. If you have better tricks or find something wrong simply
change it, it's a wiki ;-)
Ladislav
[1] https://github.com/yast/yast.github.io/wiki/YaST-Tips-and-Tricks
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi there!
In the context of revamping yast2-users[1], I spent some days looking
for an alternative layout that could help to improve the current UI by
reducing the number of tabs and grouping form fields to make better use
of available space.
However, due to our resolution constraints (UI must fit well in an
80x24 terminal) and some UI library limitations[2], looks like there is
not too much room for big changes and our best bet is to keep the
layout almost as it is, just making some necessary adjustments[3].
Summarizing them a lot, those changes will consist of adding a top menu
bar for making easier the user navigation, moving all settings to the
same dialog, improving filters by using a popup, making small changes
in forms, and adding some summary views.
Of course, nothing is written in stone and it would be nice to know
your feedback and/or ideas too. So, please, keep reading the following
links if you are interested and tell us what do you think. Is there
anything we overlooked? Some other ideas we should evaluate?
Remember that you can reach us by email, on IRC, or even by directly
leaving a comment in those Github issues.
Thanks!
[1] "Revamping yast2-users" mailing list thread -
https://lists.opensuse.org/archives/list/yast-devel@lists.opensuse.org/thre…
[2] "UI library limitations"
https://github.com/yast/yast-users-ng/issues/8
[3] "Revamping yast2-users UI: an initial proposal"
https://github.com/yast/yast-users-ng/issues/6
--
David Díaz
YaST Team at SUSE LINUX GmbH
IRC: dgdavid
NameScheme=by-label on installer cmdline has had no effect I have observed for a
lot longer than I can remember, several years at least, continuing in 15.3 build
117.13. Has it been removed and the linuxrc page need matching update? Is this a
broken installer option? Am I not understanding why it's listed on the linuxrc
page? Shouldn't it prevent me from needing to change default mount by in the
expert partitioner?
--
Evolution as taught in public schools, like religion,
is based on faith, not on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
Hi,
This is not so much of a bug, but a nice to have (and most systems have this) therefore I wasn't sure where to paste this question where it will be read. Apologies if this is not the place. Anyhow:
I ran into this yesterday where I would've needed to set separate gateways for a bond and a bridge interface, but the only option YaST offers is the global routing which in some cases it is insufficient. However, wicked offers `ifroute` which does exactly this and which I found way too late. Would this be something that can be integrated into YaST as well or considered to be integrated?
Br,
A.
It's vacation season here in Europe. But that doesn't stop the YaST Team
from publishing our blog posts, this time including news that go beyond
the scope of YaST, like:
- Taking over the development of the (open)SUSE Release Tools
- Improvements in the new check-profile command
- Finished migration from Travis CI to GitHub Actions
- Several interesting bug fixes
Check the full report at:
https://yast.opensuse.org/blog/2021-07-27/sprint-127-128
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH
As you may know, this pull request in libyui brought nicer tabs in Qt
that rely on QTabWidget
https://github.com/libyui/libyui/pull/31
As explained there, some hacks were needed because the philosophy of
tabs in Qt is different from the one in libyui.
With Qt, the widgets contained in all tabs exist in memory (they keep
their state and can be referenced) as long as the group of tabs exists.
Changing between tabs is controlled by Qt itself (mostly transparent to
the program) and its just a matter of which widgets are visible and
which are not. In some sense, switching tabs is not so different from
scrolling a screen - some widgets will become visible and other will not
be longer in the spotlight, but all widgets are still there.
With libyui, switching a tab is just an event and it's program
responsibility to actually redraw the content below the tabs. Something
that is done thanks to the usage of replace points and that implies
destroying all the visible widgets and creating new ones to be drawn in
their places. If the program is using CWM (which offers an extra
abstraction layer on top of libyui with it's own sequence of events),
that means that for every widget that becomes hidden (destroyed,
actually) a "validate" and a "store" events are triggered. On the other
hand, the status of every widget that becomes visible (created again,
actually) must be initialized based on an "init" event (apart from
calling the constructor, the usual calls to "content", etc.).
While reviewing the changes in libyui we came to the question of whether
it would be actually better to adopt the Qt philosophy in libyui. Maybe
with an alternative widget (to not completely break backwards
compatibility and CWM tabs). What do you think? Would it be worth
considering?
Cheers
--
Ancor González Sosa
YaST Team at SUSE Software Solutions
