Mailinglist Archive: yast-devel (63 mails)

< Previous Next >
Re: [yast-devel] GUI for services management
  • From: Ancor Gonzalez Sosa <ancor@xxxxxxx>
  • Date: Thu, 04 Dec 2014 16:43:24 +0100
  • Message-id: <5480811C.3060808@suse.de>
On 12/02/2014 04:38 PM, Johannes Meixner wrote:

Hello,

On Dec 2 14:43 Ancor Gonzalez Sosa wrote (excerpt):
http://goo.gl/Sbe3Ld

This reads:
----------------------------------------------------------------------
3) The most common approach in YaST interfaces is allowing the user
to configure everything in the UI without the changes taking effect
immediately. When the user clicks the "ok" button, all the changes
are applied to the system and the YaST interface is closed. Although
that's the usual YaST behavior, it's not mandatory to stick to that
approach.
----------------------------------------------------------------------

Personally I am against this usual YaST behavior.

The usual YaST behavior is no real (i.e. no bidirectional)
communication between user and system. The dialogs might look
as if there is such a communication but actually it happens
only between the user and the GUI but not between the user and
the system simply because nothing is done regarding the system
until the whole module is finishing and then it is too late
for a bidirectional communication.

A consequence is that when something goes wrong while the module
is finishing (i.e. while changes are applied to the system),
there can be only unfriendly error messages because the user
can no longer do anything at this stage.

See
https://en.opensuse.org/Archive:YaST_Printer_redesign
therein in particular the sections
- Transaction Semantics For Each "One Setup"
- "Just In Time" Configuration
- Different Workflow What Actually Happens


I see your point. Let's keep in mind that all YaST modules should be
consistent. So before proceeding with the discussion on how to change
the behaviour of the modules managing network services, let's ask ourselves:

Do we want to change the way YaST interacts with the user and the system
in general?
That means changing this current behaviour for MOST modules:

1. During startup read all information from the system.
2. Show whatever dialogs are needed to let the user do all his
configuration tasks and keep all settings only internally.
3. When finishing write all settings to the system.

Whatever is the answer, we cannot change our mind then again in six
months from now. There are almost 100 YaST modules out there and even
adapting them for small things in which all agree takes a lot of time.

I think the current approach is perfect for installation, in which you
configure everything before pushing the big red button. But I kind of
agree that it has important drawbacks on running system.

And that's, IMHO, one of the main problems in YaST development. We are
writing modules to fit both installation and configuration of an
installed system and I'm not sure to what degree the solutions for both
use cases are "compatible".

Cheers.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >