Today I was looking at https://bugzilla.redhat.com/show_bug.cgi?id=624158; part of that bug involved creating a locale mapping file in initscripts; this seemed like a bad idea. When considering that, I thought of lang-table, and wondered 'how could we get rid of that'. Some thinking later, and...
anaconda currently has multiple locale/location screens:
- language selection (custom anaconda) - keyboard selection (from s-c-keyboard, but nothing else uses that) - timezone selection (from s-c-date)
anaconda needs the following bits of localization info:
- locale/language - timezone - keyboard layout - text font
anaconda uses the following data sources:
- tzdata - lang-table (a custom anaconda file)
anaconda does *zero* autodetection.
The rest of this is driven by two assumptions:
1) We can do better. 2) We really shouldn't be driving off of configuration sources that only live in anaconda.
...
Currently, we have the following data sources available to us:
* iso-codes Includes: country subdivisions (state/province), indexed by country countries, and their country code languages Does not map: languages to countries
* localedata Maps: languages to countries (more or less) Does not map: languages to a primary locale/country
* tzdata Includes: timezones, indexed by country lat/lon for timezones Does not map: locales to country random cities to timezones (only specific timezone cities)
* libgweather Includes: many many cities, organized by country - with timezone - with lat/lon - with weather codes Does not map cities/contries to locale
* geoclue Maps: current location to: - country - city - lat/lon
* xkeyboard-config Maps: language name to xkb layout (1:n, though) country name to xkb layout
We also have the following widgetry:
* system-config-date - timezone selector Uses: tzdata
* system-config-keyboard - keyboard layout selector Uses: custom hardcoded mappings in the code, lang-table
* system-config-language - language selector Uses: iso-codes
* anaconda language selector - language selector Uses: lang-table
and the following other codebases that don't have widgetry split out:
* gdm - language and keyboard selectors Uses: iso-codes, xkeyboard-config
* gnome-control-center datetime - timezone selecor Uses: tzdata http://live.gnome.org/Design/SystemSettings/DateAndTime
* gnome-panel - location selector Uses: libgweather, tzdata
and the following widgetry currently in development:
* gnome locale configuration applet Uses: iso-codes, xkeyboard-config, and more http://live.gnome.org/Design/SystemSettings/RegionAndLanguage
A modest proposal...
On boot, as soon as there is networking available, start geoclue. Acquire location information. Then, feed the information as so:
- country, lat/lon (from geoclue) -> timezone (from country, lat/lon, via tzdata) -> language (via ???????, see below) -> keyboard layout (from country/language combo, via xkeyboard-config) -> text font (hardcoded!)
Notes: - What if we don't have network? Do DHCP always on link! - It's easy to get a list of possible languages given the country. There's no canonical data source of what to use for the *primary* language, though. We could make a mapping table (ugh), or do heuristics (double ugh). - text font is hardcoded to 'latarcyrheb-sun16'. We could conceivable have an override for the very few people who can't use that.
We then display as so:
...
Current settings:
Location: United States [ change ] [ details ]
If you click 'change', it pops up a selector dialog that either:
- allows you to enter a location (similar to the gnome panel clock code) - allows you to click a location (similar to the control center timezone selector)
Either of those resets country, timezone, language, keyboard layout, etc. If you select 'details', (or '>>>', or some expander, to be language-neutral), you get:
Language: English [ change ] Country: USA [ change ] Time: 2:33 PM (US Eastern) [ change ] Keyboard Layout: us [ change ]
Then, each of those options pops up a single-purpose configuration dialog. anaconda can either use the gnome capplet once it's done, or roll its own.
Thoughts?
Bill
On Thu, 2010-12-09 at 21:25 +0000, Bill Nottingham wrote:
Today I was looking at https://bugzilla.redhat.com/show_bug.cgi?id=624158; part of that bug involved creating a locale mapping file in initscripts; this seemed like a bad idea. When considering that, I thought of lang-table, and wondered 'how could we get rid of that'. Some thinking later, and...
[snip a lot of great stuff]
Just as a heads' up I broke out a new whiteboard for locale discussion and wiki-fied Bill's proposal:
https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Anaconda_Location
~m
On 09/12/10 19:51, Máirín Duffy wrote:
On Thu, 2010-12-09 at 21:25 +0000, Bill Nottingham wrote:
Today I was looking at https://bugzilla.redhat.com/show_bug.cgi?id=624158; part of that bug involved creating a locale mapping file in initscripts; this seemed like a bad idea. When considering that, I thought of lang-table, and wondered 'how could we get rid of that'. Some thinking later, and...
[snip a lot of great stuff]
Just as a heads' up I broke out a new whiteboard for locale discussion and wiki-fied Bill's proposal:
https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Anaconda_Location
~m
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Since hour format is included here, date format might be included as well. Maybe in the "advanced" sections if it's added to every page.
On boot, as soon as there is networking available, start geoclue. Acquire location information. Then, feed the information as so:
- country, lat/lon (from geoclue)
-> timezone (from country, lat/lon, via tzdata) -> language (via ???????, see below) -> keyboard layout (from country/language combo, via xkeyboard-config) -> text font (hardcoded!)
Notes:
- What if we don't have network? Do DHCP always on link!
- It's easy to get a list of possible languages given the country. There's no canonical data source of what to use for the *primary* language, though. We could make a mapping table (ugh), or do heuristics (double ugh).
- text font is hardcoded to 'latarcyrheb-sun16'. We could conceivable have an override for the very few people who can't use that.
If the user provides lang= and/or kbd= on the command line, I assume we have enough data to do the reverse mapping back to guess timezone and the rest. Or, do we proceed with the geoclue guess and then use any lang= or kbd= setting to augment what we figured out? This has implications for kickstart too.
Also, what do we do about loader? For the common use case, we likely will not stop in the loader so there will be no need to prompt. However, there are still a fair number of other reasons why we might have to do something interactive in loader - method selection, driver disk, can't fetch kickstart file, bring up network, etc.
- Chris
Chris Lumens (clumens@redhat.com) said:
If the user provides lang= and/or kbd= on the command line, I assume we have enough data to do the reverse mapping back to guess timezone and the rest.
... 'maybe'? If they select (for a random example) Spanish and Dvorak, that's not a unique combination that suggests a location. Although if they specify a full locale (es_ES, for example), we can then pick a country and therefore a timezone.
Also, what do we do about loader? For the common use case, we likely will not stop in the loader so there will be no need to prompt. However, there are still a fair number of other reasons why we might have to do something interactive in loader - method selection, driver disk, can't fetch kickstart file, bring up network, etc.
I thought method selection was dead, in favor of repo selection which is done in stage2? For the rest... hmm.
Bill
If the user provides lang= and/or kbd= on the command line, I assume we have enough data to do the reverse mapping back to guess timezone and the rest.
... 'maybe'? If they select (for a random example) Spanish and Dvorak, that's not a unique combination that suggests a location. Although if they specify a full locale (es_ES, for example), we can then pick a country and therefore a timezone.
"es_ES vs. es" could be a tricky distinction to education people about, but I don't yet see a better way to do it. For kickstart, at least, we can always introduce a new command. Perhaps "locale --lang= --kbd= --whatever=" that obsoletes the rest?
Also, what do we do about loader? For the common use case, we likely will not stop in the loader so there will be no need to prompt. However, there are still a fair number of other reasons why we might have to do something interactive in loader - method selection, driver disk, can't fetch kickstart file, bring up network, etc.
I thought method selection was dead, in favor of repo selection which is done in stage2? For the rest... hmm.
You can still get the loader method selection screen if you pass "askmethod". Otherwise, anaconda now either takes what you provide for method=/repo=, or uses whatever's in the default repo config files. Most people should fall into the latter case.
For the rest - perhaps the answer is that as much of this as possible should start moving into anaconda proper hopefully getting rid of the loader environment entirely. That's not really something we can crank out in a week or two to get started on this locale stuff, though.
Alternatively, perhaps we can work up something in loader that uses these same data sources but only provides the bare minimum of language and keyboard configuration. That gets us out of providing our own data sources but doesn't require us to duplicate the whole fancy UI in loader. This could also be seen as a stop gap while we work on killing loader entirely.
- Chris
On Mon, 2010-12-13 at 13:23 -0500, Chris Lumens wrote:
For the rest - perhaps the answer is that as much of this as possible should start moving into anaconda proper hopefully getting rid of the loader environment entirely. That's not really something we can crank out in a week or two to get started on this locale stuff, though.
I'm willing to help consider moving some of the driver bits up the stack. What we did in RHEL6 with unloading all drivers and reloading can be fixed to only reload changed drivers and their dependencies (this wasn't done before because it takes some ugliness to do this right) using SRCVERSION data to verify that the module actually changed. But we still have some drivers where we can't realistically load them other than early on, so we should think about it some more. I don't think graphics drivers matter hugely because we generally recommend doing an install with VESA or whatever works out of the box to get going, but there are probably some other cases. Let's talk about this.
Also, two random other comments:
1). I don't think you should always bring the network up without giving an option not to do so, or making it clear you are going to do this.
2). Many countries do not have an official language, which I would imagine is why you won't find it in an easy lookup table. For example, in the United Kingdom, in the country of England there is no official language (!English). A similar situation applies in the US. Some people get worked up about this kind of thing, like they do about flags.
Jon.
I'm willing to help consider moving some of the driver bits up the stack. What we did in RHEL6 with unloading all drivers and reloading can be fixed to only reload changed drivers and their dependencies (this wasn't done before because it takes some ugliness to do this right) using SRCVERSION data to verify that the module actually changed. But we still have some drivers where we can't realistically load them other than early on, so we should think about it some more.
It might help if we think about this in terms of what steps must come before others, instead of in today's terms of early/late, loader/stage2, etc. So for instance, it's pretty obvious that driver loading must come before the network is necessarily available (what if you're updating a network driver?) but that doesn't mean it can't be done in the graphical portion of anaconda.
We need to figure out what the end goal here is.
I don't think graphics drivers matter hugely because we generally recommend doing an install with VESA or whatever works out of the box to get going, but there are probably some other cases. Let's talk about this.
Do we support putting graphics drivers into update disks? As for which driver we use - VESA is only recommended as the fallback. We default to whatever X defaults to, and it tries to use the hardware-specific one by default.
1). I don't think you should always bring the network up without giving an option not to do so, or making it clear you are going to do this.
We already assume network in basically all code paths, unless you do an HD install or boot off the DVD.
2). Many countries do not have an official language, which I would imagine is why you won't find it in an easy lookup table. For example, in the United Kingdom, in the country of England there is no official language (!English). A similar situation applies in the US. Some people get worked up about this kind of thing, like they do about flags.
Yeah, this part is going to be a little difficult. The best we can hope for is making an educated guess and then letting people change it when we get it wrong.
- Chris
Hi,
On Thu, 2010-12-09 at 21:25 +0000, Bill Nottingham wrote:
Today I was looking at https://bugzilla.redhat.com/show_bug.cgi?id=624158; part of that bug involved creating a locale mapping file in initscripts; this seemed like a bad idea. When considering that, I thought of lang-table, and wondered 'how could we get rid of that'. Some thinking later, and...
[ snip ]
I put together some mockups based on your proposal, Bill-
https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Anaconda_Location#Mockup...
~m
I put together some mockups based on your proposal, Bill-
https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Anaconda_Location#Mockup...
Ahh good, something concrete to talk about.
It looks like every value only becomes a button once you put the mouse over it. Is that what I'm seeing?
Does the keyboard layout selector have any way to let you type and verify you're getting the right thing? I see the images of the layouts (do we have those in a package somewhere), but it's not clear to me that if you start typing, keys will light up or something. Having a test input box there would really make a lot of bug reporters happy.
- Chris
Hi Chris!
On Tue, 2011-01-11 at 21:36 +0000, Chris Lumens wrote:
I put together some mockups based on your proposal, Bill-
https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Anaconda_Location#Mockup...
Ahh good, something concrete to talk about.
It looks like every value only becomes a button once you put the mouse over it. Is that what I'm seeing?
Yep, that's correct! I don't know if it'll be too confusing in practice though; I mocked it up that way so it looks more clean / less-cluttered. The pattern is used in some more recent GNOME config UI such as the calendar widget (if you have multiple locations on your clock, hover over the right side of the clock drop-down and edit boxes appear) as well as in the new accountsdialog package.
I could probably do a little animated javascript thingy to usability test it out and make sure it won't cause problems though! I'll poke around with some jquery and these png files and see what I can build :) (it'll help to get a feel for how it works outside of testing those buttons anyway)
Does the keyboard layout selector have any way to let you type and verify you're getting the right thing? I see the images of the layouts (do we have those in a package somewhere),
xkeyboard-config is the low-level package that provides the layout metadata.... libgnomekbd is the higher-level package though that you'd probably want to use if you wanted to poke with it? (this is from talking to Ray about it)
but it's not clear to me that if you start typing, keys will light up or something. Having a test input box there would really make a lot of bug reporters happy.
I totally just ripped that off of:
System > Preferences > Keyboard ... Layouts Tab ... Add button .... Choose a layout dialog.
That dialog does actually respond to keypresses so if you hit a key on your keyboard it'll light up the key it'll use in the keyboard diagram. We probably need to blow it up much bigger to be readable though. Maybe it would be nice to have a textarea that shows as you're typing what it'll come out like? (Maybe easier to read than the highlighted keys?)
One thing I noticed poking around with the choose a layout dialog is that it is quite difficult to get focus on the keyboard diagram widget so that you can type to light up the keys. It would be nice if you type anywhere (besides the dropdown boxes, which *SHOULD* jump you to the keys you're typing but don't today making the selections extremely painful) that it lights up the keyboard rather than having the align the stars and planets just right. :p
~m
Yep, that's correct! I don't know if it'll be too confusing in practice though; I mocked it up that way so it looks more clean / less-cluttered. The pattern is used in some more recent GNOME config UI such as the calendar widget (if you have multiple locations on your clock, hover over the right side of the clock drop-down and edit boxes appear) as well as in the new accountsdialog package.
I could probably do a little animated javascript thingy to usability test it out and make sure it won't cause problems though! I'll poke around with some jquery and these png files and see what I can build :) (it'll help to get a feel for how it works outside of testing those buttons anyway)
Hm, I wonder how that's implemented and if it's some GNOME-specific thing that we're not going to be able to do.
This raises an important question about how we go about adding these new interfaces. The proposal is pretty drastically different in style from everything else in anaconda. Do we merge in a single completely different UI for one screen and have it look very out of place, or do we wait to merge until the rest of the UI looks similar?
Does the keyboard layout selector have any way to let you type and verify you're getting the right thing? I see the images of the layouts (do we have those in a package somewhere),
xkeyboard-config is the low-level package that provides the layout metadata.... libgnomekbd is the higher-level package though that you'd probably want to use if you wanted to poke with it? (this is from talking to Ray about it)
Okay, we'll investigate.
That dialog does actually respond to keypresses so if you hit a key on your keyboard it'll light up the key it'll use in the keyboard diagram. We probably need to blow it up much bigger to be readable though. Maybe it would be nice to have a textarea that shows as you're typing what it'll come out like? (Maybe easier to read than the highlighted keys?)
One thing I noticed poking around with the choose a layout dialog is that it is quite difficult to get focus on the keyboard diagram widget so that you can type to light up the keys. It would be nice if you type anywhere (besides the dropdown boxes, which *SHOULD* jump you to the keys you're typing but don't today making the selections extremely painful) that it lights up the keyboard rather than having the align the stars and planets just right. :p
As long as we have a way for the user to verify they're typing in the layout they chose, it's fine. It doesn't matter to me whether it's a magic light up layout image or a text box. However, it does seem like the layout image is harder to discover that you can use for verification. Without the focus stealing, you'd have to know to put the mouse over it first. I don't know that we can do the focus stealing. And if we do, can we still make the keyboard accelerators for Back/Next work right?
- Chris
Hi Chris!
On Thu, 2011-01-13 at 16:36 +0000, Chris Lumens wrote:
This raises an important question about how we go about adding these new interfaces. The proposal is pretty drastically different in style from everything else in anaconda. Do we merge in a single completely different UI for one screen and have it look very out of place, or do we wait to merge until the rest of the UI looks similar?
I think it's your call which approach is best. If it'd be helpful I could remix each set of mockups to fit the current layout / widget look & feel / patterns in today's Anaconda. If I understand then the choices would be:
- build all new ui on a different branch and wait until it's complete to merge... using an all-new look & feel, etc.
- update the current screens as is possible using the existing look & feel / constraints piece-by-piece / screen-by-screen, and once that is complete, then later on go back and update them to a revamped look & feel and make some UI pattern changes too (e.g., kill pop-up windows, introduce overlays).
I don't think you'd ever want to introduce one or two screens with this totally out-there look & feel in the middle of what you've got now... it's too jarring.
As long as we have a way for the user to verify they're typing in the layout they chose, it's fine. It doesn't matter to me whether it's a magic light up layout image or a text box. However, it does seem like the layout image is harder to discover that you can use for verification. Without the focus stealing, you'd have to know to put the mouse over it first. I don't know that we can do the focus stealing. And if we do, can we still make the keyboard accelerators for Back/Next work right?
Yeh the light-up map is clever but the discoverability is a pain-in-the-butt. Maybe having a simple text widget that fills in as you type makes the most sense. I think it's still good to have a visual of the keyboard layout though so you can compare it to the one under your fingers more easily. I'll play with the mockup and see how that might work.
~m
On Fri, 2011-01-14 at 11:17 -0500, Máirín Duffy wrote:
Hi Chris!
On Thu, 2011-01-13 at 16:36 +0000, Chris Lumens wrote:
This raises an important question about how we go about adding these new interfaces. The proposal is pretty drastically different in style from everything else in anaconda. Do we merge in a single completely different UI for one screen and have it look very out of place, or do we wait to merge until the rest of the UI looks similar?
I think it's your call which approach is best. If it'd be helpful I could remix each set of mockups to fit the current layout / widget look & feel / patterns in today's Anaconda. If I understand then the choices would be:
- build all new ui on a different branch and wait until it's complete to
merge... using an all-new look & feel, etc.
If we will go this way, I was thinking that we could create some custom class/widget (based on gtk.Notebook for example) to hold all the "pages", that will suit all our needs, and put this in some "anaconda library", so it can be used in other apps too, like for example Firstboot, and the look will be consistent.
We were already talking about removing the logic from the gui stuff, so this could be the time to start.
- update the current screens as is possible using the existing look &
feel / constraints piece-by-piece / screen-by-screen, and once that is complete, then later on go back and update them to a revamped look & feel and make some UI pattern changes too (e.g., kill pop-up windows, introduce overlays).
I don't think you'd ever want to introduce one or two screens with this totally out-there look & feel in the middle of what you've got now... it's too jarring.
As long as we have a way for the user to verify they're typing in the layout they chose, it's fine. It doesn't matter to me whether it's a magic light up layout image or a text box. However, it does seem like the layout image is harder to discover that you can use for verification. Without the focus stealing, you'd have to know to put the mouse over it first. I don't know that we can do the focus stealing. And if we do, can we still make the keyboard accelerators for Back/Next work right?
Yeh the light-up map is clever but the discoverability is a pain-in-the-butt. Maybe having a simple text widget that fills in as you type makes the most sense. I think it's still good to have a visual of the keyboard layout though so you can compare it to the one under your fingers more easily. I'll play with the mockup and see how that might work.
~m
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Mon, 2011-01-10 at 16:47 -0500, Máirín Duffy wrote:
Hi,
On Thu, 2010-12-09 at 21:25 +0000, Bill Nottingham wrote:
Today I was looking at https://bugzilla.redhat.com/show_bug.cgi?id=624158; part of that bug involved creating a locale mapping file in initscripts; this seemed like a bad idea. When considering that, I thought of lang-table, and wondered 'how could we get rid of that'. Some thinking later, and...
[ snip ]
I put together some mockups based on your proposal, Bill-
https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Anaconda_Location#Mockup...
~m
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Looks nice, but I don't like the Details... expander. User like me will _always_ click it, just because I'm curious what is hidden there, or to make sure, if there's not some important setting that has wrong value and I need to change it. So that's one more click for me every time.
There's a lot of free space on that screen, so why don't we show all the values at once?
Also the labels that change to buttons only when clicked are very nice to look at, but will everybody know that they can actually click it to change the value? This changes the well known widgets behavior so I'm afraid if we will not confuse people.
anaconda-devel@lists.fedoraproject.org
-
Bill Nottingham -
Chris Lumens -
Hugo Osvaldo Barrera -
Jon Masters -
Martin Gracik -
Máirín Duffy