Mailinglist Archive: yast-devel (42 mails)

< Previous Next >
Re: [apparmor] [yast-devel] apparmor: Texteditor


On 04/04/2017 10:15 AM, Ladislav Slezak wrote:
Dne 3.4.2017 v 16:25 Josef Reidinger napsal(a):
On Mon, 3 Apr 2017 09:13:27 -0500 Goldwyn Rodrigues <rgoldwyn@xxxxxxx> wrote:
[...]
While hacking on yast-apparmor to remove perl library dependency, we
discussed
on apparmor mailing list that we cannot have all possible options and the
information in yast to facilitate modification of configuration files. So,
a
dumb text editor would be the best option to configuration. After the user
modifies the file, it would checked by apparmor_parser for validity.

However, I could not find any options in Yast which would provide a text
editor
or I din't look in the right places.

There is no full text editor in YaST. But as a workaround you could use the
MultiLineEdit widget [1]. It's a simple text field but allows editing multi
line
text. In GUI you can use at least the basic shortcuts like Ctrl+C and Ctrl+V.
Another advantage is that is works also in the text mode and does not need any
external tools.

In the past we used this trick in the bootloader module, you could display the
proposed configuration and manually edit it. Then it was read and parsed
back. This
way you could set the options which were otherwise not available in the UI.

However I'd avoid this approach, see below.

[...]
In general I think yast goal is to allows non-expert to do common
configuration,
so support options that majority of users find useful. Of course, it is not
easy
to judge what is still common and what is expert only, but we should keep
common
sense. For example enabling debugging is probably not something common user
need,
another example is OWLSM enablement can be there with proper info that it
can
break setup.

I fully agree with that. The goal should not be covering 100% of the
available options and configuration possibilities in YaST.

That leads to overly complex UI which is hard to use by non-experts.
On the other hand experts would probably use a terminal and their favorite
editor
avoiding YaST completely.

Focus on the common cases, make them easy and understandable. For complex or
unusual
cases point users to the documentation and manual tools.

The only important thing for YaST is to keep the manual changes, or at least
warn
users when they will be overwritten if keeping them would be too complex or
impossible.



So to summarize:
Yast does not need to cover all the options, just the important ones.
However focus should be on the ease of use.

So this is how I think we should do this.

1. Put all the logic in yast, in the form of hashmap with what options
are compatible with which keywords.
2. Keep this hashmap in a separate file, so it makes it easier to update.
3. Present it to user in a dropdown menu/radio button/checkbox interface.
4. Validate the final profile file using apparmor_parser. This should be
a BUG() sequence for the developer to fix rather than telling the user
that s/he misconfigured.

The disadvantage with this approach is that we will not have an uptodate
list presented by apparmor. But I think we can live with that since we
are not trying to achieve 100% coverage. Besides, we are duplicating
logic (from apparmor).

My concern is, how do we handle the case where the users has a config
option not understood by yast, and the user tries to edit it. Mark it
un-editable?

You may propose something else if you find this proposal absolutely
preposterous.


--
Goldwyn
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups