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._langsupportStore
> + if 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: translate
> + infos = 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