Re: Notifying post-install tools about screens seen by the user

On 11/06/2015 09:26 AM, Martin Kolman wrote:
> On Fri, 2015-11-06 at 04:41 -0500, David Cantrell wrote:
>> On Thu, Nov 05, 2015 at 09:11:16AM -0800, Brian C. Lane wrote:
>>> On Thu, Nov 05, 2015 at 04:59:07PM +0100, Martin Kolman wrote:
>>>> Looking forward to your feedback! :)
>>> Some random thoughts:
>>>
>>> Ideally we wouldn't have to do this. The other apps should be able
>>> to
>>> detect when something has been changed from the default and skip
>>> it.
>> The goal should be to skip the screen if the user previously visited
>> a
>> similar or the same screen.  But visiting a screen doesn't mean they
>> made a
>> change.  All of those UX aspects aren't really recorded in setting
>> the
>> timezone for the system.  I agree that other apps should skip it if
>> the
>> default has been changed, but we don't record the default anywhere.
>>   Maybe
>> that's how we record the state change.
>>
>>> Synchronizing this configuration file between anaconda and the
>>> other
>>> apps means that any changes we make will need to be coordinated.
>> True, this would now be a public API.  But that's not necessarily a
>> bad
>> thing.
> I think as long as there is a definitive spec somewhere (say in the
> Anaconda source tree) and any backward incompatible changes are
> communicated to all known users it should be fine.
>
> On a related note - what about the screen/spoke naming ?
> The original idea was just to use the Anaconda spoke class names,
> but maybe some generic naming should be used ?
>
> Say KeyboardScreen instead of KeyboardSpoke ?
>
> Also what about "combined" screens ? For example the TimedateSpoke has
> both timezone and time+date configuration - so what's actually the
> correct thing to write to the config file ?
>
> [TimedateScreen]
> visited=1
>
> or rather
>
> [TimezoneScreen]
> visited=1
>
> [TimedateScreen]
> visited=1
>
> ?
>
> The second option would handle the possibility that different tools
> might have different "batching" of settings on individual screens, for
> example:
>
> Tool A having just a timezone screen, this marks TimedateScreen as
> visited.
> Tool B has a combined timezone and time+date configuration screen, but
> it is skipped due to the TimedateScreen appearing as visited, this
> making it impossible for user to set a the time & date.

If this file is to be parsed by computers, rather than people, I'd 
rather stick with the Anaconda Class names.  It makes it easier to see 
what options/attributes/etc are located there.  I think it might also 
make the code cleaner for launching the class later - fewer text 
substitutions to get to the actual code.

>
>>> Will the entries in the file be translated? I'd suggest they be in
>>> English.
>> I don't think translation is important here since it's a config file
>> that
>> users don't ever have to look at.
> Yes, it should contain only machine readable information in English, so
> no translations are needed.
>
>> /etc/sysconfig/anaconda or /etc/default/anaconda seems like a better
>>> place for this than a whole new directory in /etc/
>>
>> I like either of these ideas.  That file could also carry more UX
>> information if we need to in the future.
> Yeah, both also sound good to me + we are not the only software project
> called "anaconda", so this might as an added benefit help avoid
> collisions.
>
> Maybe one additional issue - should the folder be called "anaconda" or
> maybe as something neutral, such as  "installation" or os_installation"
> ? I'm asking because according to Michaels email, it might happen that
> some tools would be writing to the file even before Anaconda is
> started.
>
> On the other hand the "spec" should be managed as part of the Anaconda
> project, so naming the folder containing the config accordingly also
> makes sense.
>
>>> Visiting a spoke isn't the same as changing something. I think we
>>> should
>>> base this on changes, shouldn't we?
>> I think so.
>>
>>> I almost like the idea of parsing the kickstart better, it is
>>> already a
>>> known well defined format, we already write it out, and it wouldn't
>>> require coordinating a new thing with everyone.
>> The downside to that is that we'd start overloading kickstart with UX
>> metadata, which seems unnecessary.  That and the parser for it is
>> Python
>> only, which would make it difficult for programs like g-i-s.  I think
>> we can
>> probably do this with VARIABLE=VALUE syntax in a
>> /etc/sysconfig/anaconda
>> file.
>>
> _______________________________________________
> Anaconda-devel-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list