On 9/10/07, Dave Miner <Dave.Miner at sun.com> wrote: > With respect to Mike's assertion that we can assume language knowledge > based on the user getting the install running, that only works if we've > actually had an explicit question during install, or we've got an > implicit selection based on single-language media. I can get all sorts > of things to run by randomly clicking icons on a desktop without > understanding them, after all.
Fair enough. > So it seems we need to plan on asking a language question somewhere. > Replacing the installer question with a general one is fine, but my > original point is really that you need to specify where it will be asked > and it needs to end up on someone's task list. It's not spec'ed or > scheduled at this point. Previously (I think) it has been said that the language selector is a separate executable because the language that an app runs as cannot change during execution. That, combined with a few other factors brings the following random thoughts to mind: It is highly likely that the user has a live media in a language in which he/she has enough competency to perform the installation. Optimization for this case is good. If a person requires a different language than the one under which the live media runs, the user should be able to select one. It may be that the language does not exist on the media but is available through a network service. If so, the installer should be able to download and make available the required localizations so that the installer can use them. A single executable could allow the user to select the language and perform the installation. If a different language is chosen, the executable could perform a fork/exec/exit with the appropriate environment variables set, command line arguments, or other as applicable such that the exec'd instance runs with the appropriate language. This mechanism would hopefully minimize any major page faults associated with mapping the various shared libraries while those shared libraries reside on slow media. When people complain about long startup times, they say they want a splash screen or some other manner to understand that something is happening. One argument with the "wait icon" is that it prevents you from doing other things. Splash screens that not small relative to screen resolution and do not have window decorations/controls are similarly blocking. At screen resolution 1024x768, no splash screen is small enough to be out of the way for other things. In the old days of Evolution (Ximian days) I'm pretty sure that there was one window managed by the display manager with several executables providing content for the various frames. Translated to installer needs, it seems as though this "graphical shell" could be very minimal with the default canvas being the appropriately branded splash screen. It would start (fork+exec) the installer and allow the installer to paint the canvas with the language selector after the splash screen had been displayed an appropriate amount of time. If a different language is required, a second instantiation of the installer would take over the canvas running in the appropriate language. In this way, the user experience would be that there is one desktop application running (known as the installer) but behind the scenes, a more complex mechanism can take place to deal with the complexities that the end user doesn't care about. -- Mike Gerdts http://mgerdts.blogspot.com/
