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. > > 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
