On 03/25/2013 10:05 PM, Chris Lumens wrote:
pyanaconda/ui/gui/spokes/langsupport.glade | 201 +++++++++++++++++++++++++++++ pyanaconda/ui/gui/spokes/langsupport.py | 195 ++++++++++++++++++++++++++++ 2 files changed, 396 insertions(+) create mode 100644 pyanaconda/ui/gui/spokes/langsupport.glade create mode 100644 pyanaconda/ui/gui/spokes/langsupport.py
Remember to add your new files to po/POTFILES.in or they won't get translated.
Sure, thanks.
<child><object class="GtkEntry" id="langsupportEntry"><property name="visible">True</property><property name="can_focus">True</property><property name="valign">start</property><property name="margin_top">6</property><property name="hexpand">True</property><property name="invisible_char">???</property><property name="invisible_char_set">True</property><property name="secondary_icon_name">edit-clear-symbolic</property><signal name="changed" handler="on_entry_changed" swapped="no"/><signal name="icon-release" handler="on_clear_icon_clicked" swapped="no"/></object>One thing we started doing on these kinds of widgets on the UI throwdown day last week was add secondary text to indicate this is a search box. Check out 9b632169e5b83d57d627d39f94f4315abbb9aabf for an example. I think we should do the same thing here, too.
Ok, I'll add it.
- def apply(self):
self.data.lang.addsupport = [row[COL_LANG_SETTING]for row in self._langsupportStoreif row[COL_SELECTED] and row[COL_IS_ADDITIONAL]]I was kind of imagining that this would work by adding *-support packages to the list of packages to be installed. I suppose at this point we don't necessarily have packaging set up, though, do we? Passsing through kickstart elsewhere like this is probably for the best, though.
No, not necessarily IMO. I think handling *-support groups in payload.preInstall() - as we have been doing - is fine.We'll just add additional groups in the same place. Note that we don't do dependency checking for those groups earlier in first hub (which OK I think and doing it would mean entering whole new area of pain of syncing lang support selection and source/software selection I think).
Moreover, we not only add *-support groups but also need to update configuration file for yum langpacks plugin which happens also only before installation.
You may not remember this, but a long time ago we even had a langsupport kickstart command. I wonder if it'd be better to bring that back than to add additional options to existing commands. Which way is more confusing?
Yes, I noticed the command and thought about it.One difference here is that with current approach you can't add additional support without specifying lang (system language). Is it worse or better? To me it seems less comfortable (no option to just go with default lang and add additional one with langsupport command), but I think it is also more clear in a way (e.g. is it clear that when using onlylangsupport command, default system lang will be used?).
- @property
- def status(self):
# TODO: translateinfos = set(self._find_localeinfos_for_code(self.data.lang.lang, self.locale_infos_for_data)[:1])for code in self.data.lang.addsupport:infos.update(self._find_localeinfos_for_code(code, self.locale_infos_for_data))return ", ".join(info.english_name for info in infos)What happens if I select a lot of languages to add?
They are ellipsized in the status. Do you think we should display only system lang (data.lang.lang) - similar as withdefault keyboard and keyboard spoke? Maybebut one thing is that it can't be changed in the spoke sothe status wouldn't reflect any changes in the spoke actually. Perhapswe can make the system lang (which comes first) more prominent?
Radek