Hi Niall,
Niall Power wrote: > Hi Jedy, > > > Jedy Wang wrote: >> Hi Niall, >> >> I updated the language screen. But I did not change the interface >> between language screen and install engine. That means >> InstallationProfile.languages and InstallationProfile.locales are not >> changed. > That shouldn't be a problem as I believe that this interface gets > ignored by the Indiana version of the install engine. > All languages get installed and this is not user modifiable? > > Can someone working on the transfer module confirm this? > > >> Now InstallationProfile.languages can only have one item which is the >> default language and InstallationProfile.locales stores only the >> locales belong to the default language. I did not change the call to >> set default language and locales. I assume I do have to do this. If I >> am wrong, pleas correct me. > > I'm not sure. My suspicion is that these two items > (InstallationProfile.languages and InstallationProfile.locales) will > be ignore since all available > languages and locales will always be installed. This is correct - looking at the orchestrator Slim code, it doesn't utilize OM_ATTR_LOCALES_LIST string attribute - this one is populated in GUI from InstallationProfile.locales and contains list of selected locales. I am not sure how InstallationProfile.languages is used, since it is not directly used during process of preparing installation profile for orchestrator, but it seems to me that it contains current list of selected languages. Since every locale is to be installed, this will become redundant as well. > I would think that the only configuration variable we need to set is > InstallationProfile.def_lang > to specify the default locale. Currently InstallationProfile.def_locale is used for providing orchestrator with information about default locale chosen (OM_ATTR_DEFAULT_LOCALE attribute). Looking at the GUI code, InstallationProfile.def_lang is only being logged, but doesn't participate in the process of preparing installation profile. Thank you, Jan > > Jan: Is my understanding of this correct? > > Thanks, > Niall. > >> >> Regards, >> >> Jedy >> On Thu, 2008-03-27 at 00:08 -0700, Niall Power wrote: >>> Hi Frank, >>> >>> Jedy has been working on this and it's not a trivial task to convert >>> the view to the appropriate widget. GtkList is actually deprecated >>> and it's replacement widget, GtkTreeView although very flexible, is >>> also more complex to work with. The specific issue we have is that >>> it's model doesn't support radio buttons natively. It will draw >>> radio button widgets in a list, but none of the radio button >>> behaviour is provided since they are not actual radio button >>> widgets. The application has to implement all the associated radio >>> button logic. >>> Given the time constraints and risk of trying to implement this >>> before code freeze, Jedy feels that this work isn't possible to >>> complete to a satisfactory level before march 31st and I agree with >>> him on this also. >>> So our current plan is to stick with the existing scrolled window >>> view that we used for the language check buttons in SXDE, but to >>> swap out the check buttons for radio buttons. >>> I believe this has less risk and is more doable at this late stage. >>> I hope you will find this an acceptable comprimise. >>> >>> Thanks, >>> Niall. >>> -- >>> This message posted from opensolaris.org >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org <mailto:caiman-discuss at opensolaris.org> >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>> >
