Mailinglist Archive: yast-devel (63 mails)

< Previous Next >
Re: [yast-devel] GUI for services management
  • From: Ancor Gonzalez Sosa <ancor@xxxxxxx>
  • Date: Tue, 02 Dec 2014 14:43:24 +0100
  • Message-id: <>
On 11/28/2014 03:23 PM, Johannes Meixner wrote:


On Nov 28 12:46 Lukas Ocilka wrote (excerpt):

On 28.11.2014 10:32, Johannes Meixner wrote:

Have a simple [Apply] button but when the service does not support
a really safe "reload" method (i.e. that neither makes the service
temporaryly unavailability nor resets existing connections),
then ask the user for confirmation if he wants to disrupt the
currently running service to apply the new settings right now.

That's a good point but it's actually something completely different.

It's a different use case, e.g., something like Samba service to
which clients might be connected "right now" and copying files.
If we talk about DNS, DHCP or NTP Server, then nobody cares.

But Ancor Gonzalez Sosa <ancor@xxxxxxx> initially wrote:

usability problems in all modules that manages servers

which I understand that he has all services in mind.

Then Ancor Gonzalez Sosah wrote:

taking this dns-server screenshot as starting point

which I understand that DNS is only meant as initial example.

If my understanding is right, there is no such thing as
"completely different use cases" because all are one same
use case "GUI for all modules that manage services".

Yes, that was my intention.

I have summarized all the input (including situations in which reloading
is not an option) in the last page of this Google document. Maybe it's
easier to discuss if we have something more visual about the changes in
the interface, so I included a mockup of the interface with the agreed
changes. Keep in mind, nevertheless, that is just a first approach.
Maybe (hopefully) the way to separate starting/stopping from the rest
will be different in the end.

There are two options. I think most of us prefer option A. The key for
success in that approach is an UI that makes the difference between
configuration and current status very clear. If we don't achieve that,
we will have to implement some variation of option B.


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 >
Follow Ups