[yast-devel] First meeting to discuss the long term vision for our UI framework
The YaST team wants to take some time to think in the long term and try to envision the future of our UI design/programming... which may be anything from just an improved libYUI to something completely different and unrelated. It likely makes sense to start discussing what are the requisites (and/or use cases) for the UI of YaST in the long term, so we have planned a meeting with all the interested people in this topic tomorrow Thursday at 2pm CEST. Usual meeting point: https://li2023-182.members.linode.com/#/rooms/2001 As said, the topic will be: requirements for the future UI of YaST. Some food for thought about the topic: - Do we ALWAYS need to offer TUI+GUI for all modules and steps? - Does it have any value to offer something else beyond TUI/GUI? - What are the requisites regarding support for programming languages? Those are not the only points to discuss, just some hints to get your brain started. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 7/22/20 4:53 PM, Ancor Gonzalez Sosa wrote:
The YaST team wants to take some time to think in the long term and try to envision the future of our UI design/programming... which may be anything from just an improved libYUI to something completely different and unrelated.
It likely makes sense to start discussing what are the requisites (and/or use cases) for the UI of YaST in the long term, so we have planned a meeting with all the interested people in this topic tomorrow Thursday at 2pm CEST. Usual meeting point: https://li2023-182.members.linode.com/#/rooms/2001
As said, the topic will be: requirements for the future UI of YaST.
Some food for thought about the topic:
- Do we ALWAYS need to offer TUI+GUI for all modules and steps? - Does it have any value to offer something else beyond TUI/GUI? - What are the requisites regarding support for programming languages?
Those are not the only points to discuss, just some hints to get your brain started.
# The Requirements Meeting: Results 1. Small glossary - TUI: Text-based User Interface, what libYUI now provides through ncurses - GUI: Graphical User Interface, what libYUI now provides through Qt - WUI: Web-based User Interface accessible with a browser, what the Cockpit project provides 2. Meeting Context and Original Goal The context of the meeting was: we are trying to envision how the future UI framework for YaST could be in the long term. That could be an evolution of libYUI, a replacement for libYUI or something completely different. The scope/goal of the meeting was trying to define which would be the requisites for such hypothetical framework. 3. Minutes / Summary 3.1 Requisites from the User Point of View As usual when we talk about YaST requisites in terms of what do we need to support, we got more questions than answers, since we don't have a formal and unified source of specifications and use-cases. Still, we opened interesting questions regarding TUI support: - Do we need to offer TUI support for all operations and all installer steps? - Are the UI needs (specially TUI) the same for the installer and for YaST as a configuration tool? If we make the separation of both more explicit, would that bring benefits in terms of fine-tuning the UI requirements? - What is the least capable TUI terminal (emulator) we want/have to support? Is still ok to assume we have to support 80x24 without Unicode? - Can we offer an alternative and more limited TUI for the more limited terminals? In linuxrc we have the linemode interface, which seems to be quite appreciated and used and which is kind of similar to what Red Hat does for the whole text-based installation process. https://en.opensuse.org/SDB:Linuxrc#p_linemode - Idea: if we improve the usability and visibility of AutoYaST, it could become kind of a vehicle to reduce the options we offer during TUI installation. We could have a simplified interface that allows only for relatively basic installation and promote AutoYaST for the rest. We also discussed the idea of offering a WUI: - We see real use-cases for it, like: * configuration via a web browser is kind of common/expected for embedded systems, IOT devices, etc. * sysadmins needing to adjust/monitor something when they only have a browser/tablet/phone at hand - The cockpit project has attracted quite some attention, even in the (open)SUSE community, which seems to indicate there is a real interest from the users in having such UI. As a last point regarding user requisites, It was also mentioned that YaST UI feels slow, going from one dialog/tab/section to another feels slow and inconvenient, and that's an operation that has to be done quite often. 3.2 Requisites from the Developer Point of View It would be good if the new framework would allow fast prototyping, the minimum effort to create a prototype with the current tools is too high. We should try to rely as much as possible in technologies/frameworks that are not invented and maintained fully in-house by the YaST Team. Knowledge silos are a very limiting factor. Assuming we have several backends as TUI, GUI, WUI, etc. we don't want to be always limited by the less capable backend (80x24 TUI, in the current libYUI). We want to be able to take advantage of the particularities/tools of each backend. One idea regarding the previous point: define widgets once and then get TUI + GUI + Whatever widgets that you can customize further: Abstract Factory -> Backend-specific Factory -> Backend-specific widget Another idea in the same line: compared to libYU, it should be easier to redefine how some things work in a particular widget compared to its "base widget". 3.3 Other Topics The meeting often drifted to other more or less related topics: - Colaboration with manatools https://github.com/manatools/python-manatools - The lack of separation of UI and "business logic" in YaST in general, which maybe is currently perceived by many YaST Team members as the most limiting factor to any UI-related discussion, beyond the UI framework itself. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Fri, 24 Jul 2020 14:55:50 +0200
Ancor Gonzalez Sosa
One idea regarding the previous point: define widgets once and then get TUI + GUI + Whatever widgets that you can customize further: Abstract Factory -> Backend-specific Factory -> Backend-specific widget
Another idea in the same line: compared to libYU, it should be easier to redefine how some things work in a particular widget compared to its "base widget".
One more idea I have. Something like gem2rpm or kind of how swig works. Define universal code ( description of UI ) and then have specialized code and as result it will generate code in target UI framework. It should work without specialized part. Advantage of this way: 1. you can easily write in target language like in swig 2. it ensure that basic UI looks same as widgets are generated from same base. 3. backend stuff should be done on universal part and query for widget result. So all fancy specialized features just helps with manipulation, but should not affect final result.
3.3 Other Topics
The meeting often drifted to other more or less related topics:
- Colaboration with manatools https://github.com/manatools/python-manatools
- The lack of separation of UI and "business logic" in YaST in general, which maybe is currently perceived by many YaST Team members as the most limiting factor to any UI-related discussion, beyond the UI framework itself.
What I miss and maybe something we should do for next meetings is plan how to move forward for next meeting.
Cheers.
Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 7/24/20 1:55 PM, Ancor Gonzalez Sosa wrote:
On 7/22/20 4:53 PM, Ancor Gonzalez Sosa wrote:
The YaST team wants to take some time to think in the long term and try to envision the future of our UI design/programming... which may be anything from just an improved libYUI to something completely different and unrelated.
It likely makes sense to start discussing what are the requisites (and/or use cases) for the UI of YaST in the long term, so we have planned a meeting with all the interested people in this topic tomorrow Thursday at 2pm CEST. Usual meeting point: https://li2023-182.members.linode.com/#/rooms/2001
As said, the topic will be: requirements for the future UI of YaST.
Some food for thought about the topic:
- Do we ALWAYS need to offer TUI+GUI for all modules and steps? - Does it have any value to offer something else beyond TUI/GUI? - What are the requisites regarding support for programming languages?
Those are not the only points to discuss, just some hints to get your brain started.
# The Requirements Meeting: Results
1. Small glossary
- TUI: Text-based User Interface, what libYUI now provides through ncurses
- GUI: Graphical User Interface, what libYUI now provides through Qt
- WUI: Web-based User Interface accessible with a browser, what the Cockpit project provides
2. Meeting Context and Original Goal
The context of the meeting was: we are trying to envision how the future UI framework for YaST could be in the long term. That could be an evolution of libYUI, a replacement for libYUI or something completely different.
The scope/goal of the meeting was trying to define which would be the requisites for such hypothetical framework.
3. Minutes / Summary
3.1 Requisites from the User Point of View
As usual when we talk about YaST requisites in terms of what do we need to support, we got more questions than answers, since we don't have a formal and unified source of specifications and use-cases. Still, we opened interesting questions regarding TUI support:
- Do we need to offer TUI support for all operations and all installer steps?
- Are the UI needs (specially TUI) the same for the installer and for YaST as a configuration tool? If we make the separation of both more explicit, would that bring benefits in terms of fine-tuning the UI requirements?
- What is the least capable TUI terminal (emulator) we want/have to support? Is still ok to assume we have to support 80x24 without Unicode?
- Can we offer an alternative and more limited TUI for the more limited terminals? In linuxrc we have the linemode interface, which seems to be quite appreciated and used and which is kind of similar to what Red Hat does for the whole text-based installation process. https://en.opensuse.org/SDB:Linuxrc#p_linemode
- Idea: if we improve the usability and visibility of AutoYaST, it could become kind of a vehicle to reduce the options we offer during TUI installation. We could have a simplified interface that allows only for relatively basic installation and promote AutoYaST for the rest.
In my opinion, we should start focusing on answering every one of these points. We need to come with some use cases before moving forward.
We also discussed the idea of offering a WUI:
- We see real use-cases for it, like: * configuration via a web browser is kind of common/expected for embedded systems, IOT devices, etc. * sysadmins needing to adjust/monitor something when they only have a browser/tablet/phone at hand
- The cockpit project has attracted quite some attention, even in the (open)SUSE community, which seems to indicate there is a real interest from the users in having such UI.
Yes, IMHO, WUI would open quite some doors to YaST. But Web is quite different to desktop. I have doubts we can really extend the libyui concept for WUI.
As a last point regarding user requisites, It was also mentioned that YaST UI feels slow, going from one dialog/tab/section to another feels slow and inconvenient, and that's an operation that has to be done quite often.
3.2 Requisites from the Developer Point of View
It would be good if the new framework would allow fast prototyping, the minimum effort to create a prototype with the current tools is too high.
We should try to rely as much as possible in technologies/frameworks that are not invented and maintained fully in-house by the YaST Team. Knowledge silos are a very limiting factor.
Assuming we have several backends as TUI, GUI, WUI, etc. we don't want to be always limited by the less capable backend (80x24 TUI, in the current libYUI). We want to be able to take advantage of the particularities/tools of each backend.
One idea regarding the previous point: define widgets once and then get TUI + GUI + Whatever widgets that you can customize further: Abstract Factory -> Backend-specific Factory -> Backend-specific widget
Another idea in the same line: compared to libYU, it should be easier to redefine how some things work in a particular widget compared to its "base widget".
3.3 Other Topics
The meeting often drifted to other more or less related topics:
- Colaboration with manatools https://github.com/manatools/python-manatools
- The lack of separation of UI and "business logic" in YaST in general, which maybe is currently perceived by many YaST Team members as the most limiting factor to any UI-related discussion, beyond the UI framework itself.
Cheers.
-- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 2020-07-24 14:55, Ancor Gonzalez Sosa wrote:
We also discussed the idea of offering a WUI:
- We see real use-cases for it, like: * configuration via a web browser is kind of common/expected for embedded systems, IOT devices, etc. * sysadmins needing to adjust/monitor something when they only have a browser/tablet/phone at hand
Oh, the old WebUI topic; a zombie that has to be slain every couple of
years, to be summoned back into this world by somebody who hasn't been
part of the previous bloody and messy slaying a few years before... ;-(
I lost count how many times we tried this. I remember some time in 2000
(when I did some experiments based on HTML CGI, again in 2001 by mmj
([*1]), again a year or two later by some intern ([*2]), again years
later with WebYaST ([*3]).
I don't know how much of that still applies with modern web tools (Ajax,
HTML5 and whatnot), but here is a list of challenges that a web UI
faces:
(1) Event model. YaST is driven by scripts (Ruby, formerly YCP). At
certain strategic points the script opens a dialog and lets the user
enter data or make decisions. For that, we have an explicit
UI.UserInput() or UI.WaitForEvent() call. This is exactly the opposite
how a web application works: The driving factor there is primarily the
user. A user action initiates a workflow, starts actions, sends off a
form full of data that the user entered.
In previous attempts, this was one of the major problems. This MIGHT
work better today with HTML5 and Ajax and all those tools.
(2) Geometry management. Our YaST UI provides a uniform layout
description to make it look as similar as possible between different UIs
(Qt, NCurses). The abstract layout management widgets on the libyui
level query their concrete implementations about the preferred size of
each sub-widget on each level, add up the totals, and manage excess or
missing screen space. To do that, the concrete widget has to know things
about its font metrics and the size (in whatever unit!) that the widget
needs on the screen. But that concept does not exist in a web UI
(AFAIK); there is no way of knowing how many pixels any given text will
need in width and in height. This is why web designers love to introduce
fixed limits for their content: The base page is designed to fit into,
say, 800 pixels horizontally, and if you have more than that, you will
get more empty space on the side. But the browser can (and will) scroll
endlessly in the vertical dimension.
This is just not how our UIs work. Trying to hammer a web UI into shape
for that will make it look like those poorly designed flash applications
of the early 2000s (anybody remember that crap? Always too tiny fonts,
always too small on some screens, and not fitting on others?).
(3) You can only support a limited number of browsers; they are just too
different to do anything else. Most web apps start with determining what
browser the user has, and they have a ton of library code for the quirks
and limitations of the most widely-used ones.
Realistically, that means they will only run well on the most recent
versions of Chrome and Firefox, maybe also Safari. Different screen
sizes / resolutions on mobile devices are already a challenge. You want
your content to fit on the screen, yet you want to use fonts that the
user can actually read (and the fact that most web designers are young
have good eye sight and love tiny fonts doesn't help either).
That means you need to come up with a set of different layouts for
different purposes: Normal PC screen, smartphone, tablet; not to mention
HiDPI screens and special layouts for visually impaired users (or
somebody might sue you based on some obscure Delaware law). Good luck
testing all that stuff. Good luck maintaining it.
(4-97) ...there are more, I am sure. Those are just the few that come
from the top of my head.
(98) There be dragons.
(99) RFC 1925 section 3: With sufficient thrust, pigs fly just fine. ;-)
https://tools.ietf.org/html/rfc1925
[*1] Mads Martin Joergensen, a legend of the SuSE of old. When he had
freshly arrived from Denmark and was on transit to the newly founded
SuSE USA, he brought up that topic of a YaST web UI again. Somebody had
told him that I had tried tis before, so he asked me what I would do. I
said "I'd jump right out of the window to be put out of that misery",
and he started laughing; only when he saw that I was not laughing at
all, he realized that I was not joking. I was dead serious.
[*2] I don't remember that guy's name; only that he was very convinced
of himself, and also convinced that we old farts were just too stubborn
and too unflexible to try such a novel thing. But he ruled the world, so
he'd show us how to do that right. He began a very enthusiastic project,
but after a while it just fizzled out with a gazillion problems. He
wouldn't listen to us old farts who told him about the problems in
advance; but of course we were just too stupid and too lazy to do it
right.
[*3] Anybody remember WebYaST? IIRC that was a very basic web UI that
more or less executed YaST command line calls when the user had
completed entering data into a form and would send that form off. Not
really anything that I would call a UI on the same level as our other
UIs (Qt, NCurses, even Gtk).
Kind regards
--
Stefan Hundhammer
On 8/10/20 3:03 PM, Stefan Hundhammer wrote:
On 2020-07-24 14:55, Ancor Gonzalez Sosa wrote:
We also discussed the idea of offering a WUI:
- We see real use-cases for it, like: * configuration via a web browser is kind of common/expected for embedded systems, IOT devices, etc. * sysadmins needing to adjust/monitor something when they only have a browser/tablet/phone at hand
Oh, the old WebUI topic; a zombie that has to be slain every couple of years, to be summoned back into this world by somebody who hasn't been part of the previous bloody and messy slaying a few years before... ;-(
Nobody thinks it's realistic to add a web UI to the CURRENT YaST. And nobody dares to even try. The premise of the card/meeting was to think about how the UI of a tool like YaST (not necessarily its current incarnation) could look like. You don't have to convince anyone that adding web capabilities to libYUI is a crappy idea. I hope everybody agrees there. :-) Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 8/10/20 3:25 PM, Ancor Gonzalez Sosa wrote:
On 8/10/20 3:03 PM, Stefan Hundhammer wrote:
On 2020-07-24 14:55, Ancor Gonzalez Sosa wrote:
We also discussed the idea of offering a WUI:
- We see real use-cases for it, like: * configuration via a web browser is kind of common/expected for embedded systems, IOT devices, etc. * sysadmins needing to adjust/monitor something when they only have a browser/tablet/phone at hand
Oh, the old WebUI topic; a zombie that has to be slain every couple of years, to be summoned back into this world by somebody who hasn't been part of the previous bloody and messy slaying a few years before... ;-(
Nobody thinks it's realistic to add a web UI to the CURRENT YaST. And nobody dares to even try. The premise of the card/meeting was to think about how the UI of a tool like YaST (not necessarily its current incarnation) could look like.
You don't have to convince anyone that adding web capabilities to libYUI is a crappy idea. I hope everybody agrees there. :-)
We've been trying to add Web UI/API in the past as there was a demand for that. We have already failed, yes, but the request comes over and over again, because it's still valid approach. Some use-cases: - IoT (and RPi) - Windows user re/configuring Linux system - (Far) remote installation/configuration - 1:many management In fact, many new things have some kind of a remote API. Trackers, electric plugs, cars, temperature sensors, vacuum cleaners, ... and they mostly either have web-based one or a phone app or both. The current task was to collect "as much ideas how the perfect next generation YaST could look like" as possible. Obviously we'll think about the current libyui later and maybe ... maybe the solution could be to write a new UI framework. Maybe we find and existent project that can be used and adjusted to our needs. Maybe we'll decide to do libyui refactoring. That's all undecided yet. Hopefully (anything we'll do) we'll use as much upstream as possible. NIH syndrome should not apply here. Thx && Bye Lukas -- Lukas Ocilka, Systems Management Team Leader & YaST Product Owner SLE Department, SUSE Linux 🌲 Please consider the environment before printing this e-mail ☂ Handle with care - Your reply can be stored in the cloud 😱 Pie-chart is just a representation of randomly chosen data ⚠ IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please, notify the sender immediately and do not disclose the contents to anyone or make copies of thereof. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 2020-08-10 15:51, Lukas Ocilka wrote:
Hopefully (anything we'll do) we'll use as much upstream as possible. NIH syndrome should not apply here.
When I look at our current YaST modules, I see an awful lot of NIH: So
many of them are just a thin wrapper around existing tools. So if we are
taking this seriously, we should get rid of YaST modules that are really
just duplicating functionality that is already available in some other
form.
yast-printer, anyone? Or yast-apparmor? To name just a few.
Kind regards
--
Stefan Hundhammer
On 8/10/20 4:07 PM, Stefan Hundhammer wrote:
On 2020-08-10 15:51, Lukas Ocilka wrote:
Hopefully (anything we'll do) we'll use as much upstream as possible. NIH syndrome should not apply here.
When I look at our current YaST modules, I see an awful lot of NIH: So many of them are just a thin wrapper around existing tools. So if we are taking this seriously, we should get rid of YaST modules that are really just duplicating functionality that is already available in some other form.
This is quite off-topic, please start another thread if necessary.
yast-printer, anyone? Or yast-apparmor? To name just a few.
Side note 1: Both actually have valid use-case: AutoInstallation. Side note 2: Neither of them were written by YaST developers. -- Lukas Ocilka, Systems Management Team Leader & YaST Product Owner SLE Department, SUSE Linux 🌲 Please consider the environment before printing this e-mail ☂ Handle with care - Your reply can be stored in the cloud 😱 Pie-chart is just a representation of randomly chosen data ⚠ IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please, notify the sender immediately and do not disclose the contents to anyone or make copies of thereof. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hello Lukas, On 2020-08-10 16:40, Lukas Ocilka wrote:
On 8/10/20 4:07 PM, Stefan Hundhammer wrote:
On 2020-08-10 15:51, Lukas Ocilka wrote:
Hopefully (anything we'll do) we'll use as much upstream as possible. NIH syndrome should not apply here.
When I look at our current YaST modules, I see an awful lot of NIH: So many of them are just a thin wrapper around existing tools. So if we are taking this seriously, we should get rid of YaST modules that are really just duplicating functionality that is already available in some other form.
This is quite off-topic, please start another thread if necessary.
you started talking about "NIH" and Stefan replied to that so in the end you started getting "quite off-topic" ;-)
yast-printer, anyone? Or yast-apparmor? To name just a few.
Side note 1: Both actually have valid use-case: AutoInstallation. Side note 2: Neither of them were written by YaST developers.
Your side note 2 is plain wrong, not helpful, and "very off-topic". The YaST printer module was written and maintained all the time by YaST developers until its last YaST developer left SUSE (I think I remember he even was laid off) and no other YaST developer took over maintainership so in the end I had to take it because at that time its YCP code was my experimental printer module code that replaced the official YaST printer module by its last YaST developer (because my experimental code was already better than the official pile of old grown code cf. https://en.opensuse.org/Archive:YaST_Printer_redesign) and because I was the one who got basically each and every printing related bug assigned I needed to further enhance my experimental code into something that doesn't cause too many new bugs. Then some YaST developers converted my YCP code into some generated "Ruby kind of code" that I neither speak nor understand. I even wasted one of my SUSE HackWeeks to learn Ruby but I don't like Ruby and some basic Ruby knowledge does not really help to actually maintain that generated Ruby kind of code. In practice the YaST printer module is no longer acually further developed since it was "converted from YCP to Ruby by YCP Killer" that happened in July 2013, see the yast2-printer.changes entry ---------------------------------------------------------- Wed Jul 31 08:37:43 UTC 2013 - yast-devel@opensuse.org - converted from YCP to Ruby by YCP Killer (https://github.com/yast/ycp-killer) - version 3.0.0 ---------------------------------------------------------- at https://build.opensuse.org/package/view_file/YaST:Head/yast2-printer/yast2-p... My last change is dated Mon Jan 19 14:51:39 UTC 2015 and my last actual further development enhancement are dated before it was "converted from YCP to Ruby by YCP Killer". Since that time the YaST printer module is kept working as is as far as possible with reasonable effort by YaST team members who know about how to deal with their generated Ruby code. Since my YCP code was converted into generated Ruby code it is no longer my code and it is no longer code that I could further develop with reasonable effort. Because the YaST printer module is based on the traditional way how printing works with CUPS <= 1.5.4 in particular for printing in the network, the YaST printer module intentionally fails with error messages when things won't work with nowadays way how printing in the network works with CUPS >= 1.6 cf. "CUPS >= 1.6 has major incompatible changes" in https://en.opensuse.org/SDB:CUPS_in_a_Nutshell So the YaST printer module is outdated for printing in the network. See also https://lists.opensuse.org/yast-devel/2015-03/msg00044.html and https://features.opensuse.org/308045 https://features.opensuse.org/316789 The links to features.opensuse.org fail with "openSUSE deprecated service" - nomen est omen.
--
Lukas Ocilka, Systems Management Team Leader & YaST Product Owner SLE Department, SUSE Linux
🌲 Please consider the environment before printing this e-mail ☂ Handle with care - Your reply can be stored in the cloud 😱 Pie-chart is just a representation of randomly chosen data
⚠ IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please, notify the sender immediately and do not disclose the contents to anyone or make copies of thereof.
Wow - I am impressed by so much IMPORTANT information - yeah! Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 8/11/20 10:06 AM, Johannes Meixner wrote:
This is quite off-topic, please start another thread if necessary.
you started talking about "NIH" and Stefan replied to that so in the end you started getting "quite off-topic" ;-)
Let's get back to UI, please. My request for new UI is no NIH if possible and that stays. For the rest, please open another thread when you feel it's needed. Thank you Lukas -- Lukas Ocilka, Systems Management Team Leader & YaST Product Owner SLE Department, SUSE Linux 🌲 Please consider the environment before printing this e-mail ☂ Handle with care - Your reply can be stored in the cloud 😱 Pie-chart is just a representation of randomly chosen data ⚠ IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please, notify the sender immediately and do not disclose the contents to anyone or make copies of thereof. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (6)
-
Ancor Gonzalez Sosa -
Johannes Meixner -
josef Reidinger -
José Iván López González -
Lukas Ocilka -
Stefan Hundhammer