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 <[email protected]> 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: [email protected] To contact the owner, e-mail: [email protected]
