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
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
