Feature changed by: snwint
Feature #302955, revision 19
Title: Split translations out of installation system
openSUSE-11.0: Candidate
Priority
Requester: Mandatory
Projectmanager: Mandatory
Requested by: coolo(a)novell.com
Partner organization: openSUSE.org
Description:
The translations of yast are the biggest part of the installation
image.
These should not be part of the image, but should be pulled in from the
product media as the user selects them.
Discussion:
#1: jsrain(a)novell.com (2007-11-09 13:18:17)
Duncan, we will need a Linuxrc support for this. Can Steffen look into
this feature? What comes to my mind is:
Linuxrc needs to download and mount the language image for the language
which user selected in bootloader menu (or English as fallback)
Linuxrc needs to provide a support (eg. a script) which YaST can call
when Language changes and downloads and "mounts" the new translation
image
It is questionable whether it should be YaST or Linuxrc who makes
checks if the asked image is already downloaded, IMO it should be
Linurc...
#2: snwint(a)novell.com (2007-11-09 14:08:01) (reply to #1)
I don't see linuxrc involved at all. YaST can just donwload he required
files. Doesn't look that tricky to me.
#3: jsuchome(a)novell.com (2007-11-09 14:29:36) (reply to #2)
Maybe, but I do not know how. Lukas, don't we have some API in yast2-
installation for that (copying target package from media to inst-sys,
if I understand it correctly)?
#4: snwint(a)novell.com (2007-11-09 14:32:40) (reply to #3)
We've had exactly that discussion when we talked about loading the
licenses. I think now is a good time to fix yast. I really don't see
why other programs have to download various files for yast when yast
could as well do it itself. And when this means doing the repo init
earlier, then, well, do it earlier.
#5: jsrain(a)novell.com (2007-11-09 15:02:22) (reply to #4)
YaST can only fetch data from instlalation sources. Inst-sys can come
from completly different location than installation sources do. YaST
has no information where to get these images from. YaST would have to
reimplement getting data from all kind of locations on its own (it
cannot use libzypp, since at the location, there needn't be any valid
source.
That's why I'd like to reuse functionality which Linuxrc already has.
#7: coolo(a)novell.com (2007-11-16 11:42:17) (reply to #5)
Duncan, is it feasible to make the download functionality of libzypp
seperate from valid sources.
E.g. RepoManager::download(theurl_I_got_from_linuxrc,
"/suse/translations/de.tar");
#10: dmacvicar(a)novell.com (2008-01-22 18:35:02) (reply to #7)
Yes, MediaSetAccess or even MediaAccess can be used to get a file
directly from an Url.
The design is layered, MediaAccess sits on top of MediaManager(curl,
iso, etc), MediaSetAccess on top, adding multiple media and media
changing support, and RepoProvideFile on top, using the repos urls and
trying different mirrors.
There is also Fetcher which also sits on top of MediaSetAccess which
provide queues and using already downloaded files.
I think it is already used in YaST, YaST does transfer the content file
from media independently from ZYpp.
#6: locilka(a)novell.com (2007-11-09 16:54:01) (reply to #3)
As already written by snwint, there is no way how to download anything
from sources before they are initialized. So: no, there is no
Installation API for that.
As there can be an installation-(zypp)-source and a different inst-sys,
Installation could either initialize the source as soon as possible but
it still wouldn't know where to download inst-sys extensions. On the
other hand, Linuxrc doesn't know which translations will be needed. So
maybe inst-sys could provide some functionality (API) for downloading
these extensions and merging them (downloaddir + adddir), YaST could
then use that API. Just an idea...
#8: michl(a)novell.com (2007-11-29 12:46:53)
We should come down to tier1 languages here.
#11: locilka(a)novell.com (2008-01-28 19:06:03) (reply to #9)
According the forwarded mails, the Installation framework should call
Get
InstsysURL
and
RepoURL
from /etc/install.inf
(and combine them with a file/localization location to
$url_to_download_file_from)
/lbin/wget -v $url_to_download_file_from $path_to_save_file_to
mkdir /mounts/localization
mount -o loop $path_to_save_file_to /mounts/localization
adddir /mounts/localization /
Where (dir) and under which names will be the localization files
(language images) stored?
#12: locilka(a)novell.com (2008-01-29 10:39:24) (reply to #11)
Snwint: does /lbin/wget check signatures of that file or does inst-sys
provide some functionality I could use to check them?
+ #14: snwint(a)novell.com (2008-01-29 11:06:11) (reply to #12)
+ No it doesn't check them. But their SHA1sum will appear in /content.
#13: snwint(a)novell.com (2008-01-29 11:03:05) (reply to #11)
The language images are named root.XXX where XXX is XXX in yast2-trans-
XXX.
--
SUSE Feature Tool:
http://partnerfate.suse.de/?rm=feature_show&id=302955
Feature changed by: snwint
Feature #302955, revision 18
Title: Split translations out of installation system
openSUSE-11.0: Candidate
Priority
Requester: Mandatory
Projectmanager: Mandatory
Requested by: coolo(a)novell.com
Partner organization: openSUSE.org
Description:
The translations of yast are the biggest part of the installation
image.
These should not be part of the image, but should be pulled in from the
product media as the user selects them.
Discussion:
#1: jsrain(a)novell.com (2007-11-09 13:18:17)
Duncan, we will need a Linuxrc support for this. Can Steffen look into
this feature? What comes to my mind is:
Linuxrc needs to download and mount the language image for the language
which user selected in bootloader menu (or English as fallback)
Linuxrc needs to provide a support (eg. a script) which YaST can call
when Language changes and downloads and "mounts" the new translation
image
It is questionable whether it should be YaST or Linuxrc who makes
checks if the asked image is already downloaded, IMO it should be
Linurc...
#2: snwint(a)novell.com (2007-11-09 14:08:01) (reply to #1)
I don't see linuxrc involved at all. YaST can just donwload he required
files. Doesn't look that tricky to me.
#3: jsuchome(a)novell.com (2007-11-09 14:29:36) (reply to #2)
Maybe, but I do not know how. Lukas, don't we have some API in yast2-
installation for that (copying target package from media to inst-sys,
if I understand it correctly)?
#4: snwint(a)novell.com (2007-11-09 14:32:40) (reply to #3)
We've had exactly that discussion when we talked about loading the
licenses. I think now is a good time to fix yast. I really don't see
why other programs have to download various files for yast when yast
could as well do it itself. And when this means doing the repo init
earlier, then, well, do it earlier.
#5: jsrain(a)novell.com (2007-11-09 15:02:22) (reply to #4)
YaST can only fetch data from instlalation sources. Inst-sys can come
from completly different location than installation sources do. YaST
has no information where to get these images from. YaST would have to
reimplement getting data from all kind of locations on its own (it
cannot use libzypp, since at the location, there needn't be any valid
source.
That's why I'd like to reuse functionality which Linuxrc already has.
#7: coolo(a)novell.com (2007-11-16 11:42:17) (reply to #5)
Duncan, is it feasible to make the download functionality of libzypp
seperate from valid sources.
E.g. RepoManager::download(theurl_I_got_from_linuxrc,
"/suse/translations/de.tar");
#10: dmacvicar(a)novell.com (2008-01-22 18:35:02) (reply to #7)
Yes, MediaSetAccess or even MediaAccess can be used to get a file
directly from an Url.
The design is layered, MediaAccess sits on top of MediaManager(curl,
iso, etc), MediaSetAccess on top, adding multiple media and media
changing support, and RepoProvideFile on top, using the repos urls and
trying different mirrors.
There is also Fetcher which also sits on top of MediaSetAccess which
provide queues and using already downloaded files.
I think it is already used in YaST, YaST does transfer the content file
from media independently from ZYpp.
#6: locilka(a)novell.com (2007-11-09 16:54:01) (reply to #3)
As already written by snwint, there is no way how to download anything
from sources before they are initialized. So: no, there is no
Installation API for that.
As there can be an installation-(zypp)-source and a different inst-sys,
Installation could either initialize the source as soon as possible but
it still wouldn't know where to download inst-sys extensions. On the
other hand, Linuxrc doesn't know which translations will be needed. So
maybe inst-sys could provide some functionality (API) for downloading
these extensions and merging them (downloaddir + adddir), YaST could
then use that API. Just an idea...
#8: michl(a)novell.com (2007-11-29 12:46:53)
We should come down to tier1 languages here.
#11: locilka(a)novell.com (2008-01-28 19:06:03) (reply to #9)
According the forwarded mails, the Installation framework should call
Get
InstsysURL
and
RepoURL
from /etc/install.inf
(and combine them with a file/localization location to
$url_to_download_file_from)
/lbin/wget -v $url_to_download_file_from $path_to_save_file_to
mkdir /mounts/localization
mount -o loop $path_to_save_file_to /mounts/localization
adddir /mounts/localization /
Where (dir) and under which names will be the localization files
(language images) stored?
#12: locilka(a)novell.com (2008-01-29 10:39:24) (reply to #11)
Snwint: does /lbin/wget check signatures of that file or does inst-sys
provide some functionality I could use to check them?
+ #13: snwint(a)novell.com (2008-01-29 11:03:05) (reply to #11)
+ The language images are named root.XXX where XXX is XXX in yast2-trans-
+ XXX.
--
SUSE Feature Tool:
http://partnerfate.suse.de/?rm=feature_show&id=302955
Feature changed by: locilka
Feature #302955, revision 17
Title: Split translations out of installation system
openSUSE-11.0: Candidate
Priority
Requester: Mandatory
Projectmanager: Mandatory
Requested by: coolo(a)novell.com
Partner organization: openSUSE.org
Description:
The translations of yast are the biggest part of the installation
image.
These should not be part of the image, but should be pulled in from the
product media as the user selects them.
Discussion:
#1: jsrain(a)novell.com (2007-11-09 13:18:17)
Duncan, we will need a Linuxrc support for this. Can Steffen look into
this feature? What comes to my mind is:
Linuxrc needs to download and mount the language image for the language
which user selected in bootloader menu (or English as fallback)
Linuxrc needs to provide a support (eg. a script) which YaST can call
when Language changes and downloads and "mounts" the new translation
image
It is questionable whether it should be YaST or Linuxrc who makes
checks if the asked image is already downloaded, IMO it should be
Linurc...
#2: snwint(a)novell.com (2007-11-09 14:08:01) (reply to #1)
I don't see linuxrc involved at all. YaST can just donwload he required
files. Doesn't look that tricky to me.
#3: jsuchome(a)novell.com (2007-11-09 14:29:36) (reply to #2)
Maybe, but I do not know how. Lukas, don't we have some API in yast2-
installation for that (copying target package from media to inst-sys,
if I understand it correctly)?
#4: snwint(a)novell.com (2007-11-09 14:32:40) (reply to #3)
We've had exactly that discussion when we talked about loading the
licenses. I think now is a good time to fix yast. I really don't see
why other programs have to download various files for yast when yast
could as well do it itself. And when this means doing the repo init
earlier, then, well, do it earlier.
#5: jsrain(a)novell.com (2007-11-09 15:02:22) (reply to #4)
YaST can only fetch data from instlalation sources. Inst-sys can come
from completly different location than installation sources do. YaST
has no information where to get these images from. YaST would have to
reimplement getting data from all kind of locations on its own (it
cannot use libzypp, since at the location, there needn't be any valid
source.
That's why I'd like to reuse functionality which Linuxrc already has.
#7: coolo(a)novell.com (2007-11-16 11:42:17) (reply to #5)
Duncan, is it feasible to make the download functionality of libzypp
seperate from valid sources.
E.g. RepoManager::download(theurl_I_got_from_linuxrc,
"/suse/translations/de.tar");
#10: dmacvicar(a)novell.com (2008-01-22 18:35:02) (reply to #7)
Yes, MediaSetAccess or even MediaAccess can be used to get a file
directly from an Url.
The design is layered, MediaAccess sits on top of MediaManager(curl,
iso, etc), MediaSetAccess on top, adding multiple media and media
changing support, and RepoProvideFile on top, using the repos urls and
trying different mirrors.
There is also Fetcher which also sits on top of MediaSetAccess which
provide queues and using already downloaded files.
I think it is already used in YaST, YaST does transfer the content file
from media independently from ZYpp.
#6: locilka(a)novell.com (2007-11-09 16:54:01) (reply to #3)
As already written by snwint, there is no way how to download anything
from sources before they are initialized. So: no, there is no
Installation API for that.
As there can be an installation-(zypp)-source and a different inst-sys,
Installation could either initialize the source as soon as possible but
it still wouldn't know where to download inst-sys extensions. On the
other hand, Linuxrc doesn't know which translations will be needed. So
maybe inst-sys could provide some functionality (API) for downloading
these extensions and merging them (downloaddir + adddir), YaST could
then use that API. Just an idea...
#8: michl(a)novell.com (2007-11-29 12:46:53)
We should come down to tier1 languages here.
#11: locilka(a)novell.com (2008-01-28 19:06:03) (reply to #9)
According the forwarded mails, the Installation framework should call
Get
InstsysURL
and
RepoURL
from /etc/install.inf
(and combine them with a file/localization location to
$url_to_download_file_from)
/lbin/wget -v $url_to_download_file_from $path_to_save_file_to
mkdir /mounts/localization
mount -o loop $path_to_save_file_to /mounts/localization
adddir /mounts/localization /
Where (dir) and under which names will be the localization files
(language images) stored?
+ #12: locilka(a)novell.com (2008-01-29 10:39:24) (reply to #11)
+ Snwint: does /lbin/wget check signatures of that file or does inst-sys
+ provide some functionality I could use to check them?
--
SUSE Feature Tool:
http://partnerfate.suse.de/?rm=feature_show&id=302955
Feature changed by: locilka
Feature #302955, revision 15
Title: Split translations out of installation system
openSUSE-11.0: Candidate
Priority
Requester: Mandatory
Projectmanager: Mandatory
Requested by: coolo(a)novell.com
Partner organization: openSUSE.org
Description:
The translations of yast are the biggest part of the installation
image.
These should not be part of the image, but should be pulled in from the
product media as the user selects them.
Discussion:
#1: jsrain(a)novell.com (2007-11-09 13:18:17)
Duncan, we will need a Linuxrc support for this. Can Steffen look into
this feature? What comes to my mind is:
Linuxrc needs to download and mount the language image for the language
which user selected in bootloader menu (or English as fallback)
Linuxrc needs to provide a support (eg. a script) which YaST can call
when Language changes and downloads and "mounts" the new translation
image
It is questionable whether it should be YaST or Linuxrc who makes
checks if the asked image is already downloaded, IMO it should be
Linurc...
#2: snwint(a)novell.com (2007-11-09 14:08:01) (reply to #1)
I don't see linuxrc involved at all. YaST can just donwload he required
files. Doesn't look that tricky to me.
#3: jsuchome(a)novell.com (2007-11-09 14:29:36) (reply to #2)
Maybe, but I do not know how. Lukas, don't we have some API in yast2-
installation for that (copying target package from media to inst-sys,
if I understand it correctly)?
#4: snwint(a)novell.com (2007-11-09 14:32:40) (reply to #3)
We've had exactly that discussion when we talked about loading the
licenses. I think now is a good time to fix yast. I really don't see
why other programs have to download various files for yast when yast
could as well do it itself. And when this means doing the repo init
earlier, then, well, do it earlier.
#5: jsrain(a)novell.com (2007-11-09 15:02:22) (reply to #4)
YaST can only fetch data from instlalation sources. Inst-sys can come
from completly different location than installation sources do. YaST
has no information where to get these images from. YaST would have to
reimplement getting data from all kind of locations on its own (it
cannot use libzypp, since at the location, there needn't be any valid
source.
That's why I'd like to reuse functionality which Linuxrc already has.
#7: coolo(a)novell.com (2007-11-16 11:42:17) (reply to #5)
Duncan, is it feasible to make the download functionality of libzypp
seperate from valid sources.
E.g. RepoManager::download(theurl_I_got_from_linuxrc,
"/suse/translations/de.tar");
#10: dmacvicar(a)novell.com (2008-01-22 18:35:02) (reply to #7)
Yes, MediaSetAccess or even MediaAccess can be used to get a file
directly from an Url.
The design is layered, MediaAccess sits on top of MediaManager(curl,
iso, etc), MediaSetAccess on top, adding multiple media and media
changing support, and RepoProvideFile on top, using the repos urls and
trying different mirrors.
There is also Fetcher which also sits on top of MediaSetAccess which
provide queues and using already downloaded files.
I think it is already used in YaST, YaST does transfer the content file
from media independently from ZYpp.
#6: locilka(a)novell.com (2007-11-09 16:54:01) (reply to #3)
As already written by snwint, there is no way how to download anything
from sources before they are initialized. So: no, there is no
Installation API for that.
As there can be an installation-(zypp)-source and a different inst-sys,
Installation could either initialize the source as soon as possible but
it still wouldn't know where to download inst-sys extensions. On the
other hand, Linuxrc doesn't know which translations will be needed. So
maybe inst-sys could provide some functionality (API) for downloading
these extensions and merging them (downloaddir + adddir), YaST could
then use that API. Just an idea...
#8: michl(a)novell.com (2007-11-29 12:46:53)
We should come down to tier1 languages here.
+ #11: locilka(a)novell.com (2008-01-28 19:06:03) (reply to #9)
+ According the forwarded mails, the Installation framework should call
+ Get
+ InstsysURL
+ and
+ RepoURL
+ from /etc/install.inf
+ (and combine them with a file/localization location to
+ $url_to_download_file_from)
+ /lbin/wget -v $url_to_download_file_from $path_to_save_file_to
+ mkdir /mounts/localization
+ mount -o loop $path_to_save_file_to /mounts/localization
+ adddir /mounts/localization /
+ Where (dir) and under which names will be the localization files
+ (language images) stored?
--
SUSE Feature Tool:
http://partnerfate.suse.de/?rm=feature_show&id=302955
Feature changed by: jsuchome
Feature #302957, revision 26
Title: Combined "where am I" page
openSUSE-11.0: Candidate
Priority
Requester: Mandatory
Projectmanager: Important
SLED-11: New
Priority
Requester: Mandatory
SLES-11: New
Priority
Requester: Mandatory
Requested by: coolo(a)novell.com
Partner organization: openSUSE.org
Description:
Our (openSUSE) statistics show that most of our users are not native
english speakers. So I'm blindly assuming they do not have a english
keyboard either and do not live in an english speaking timezone.
So I want the first page to be not just the language in a blue box, but
to have _one_ installation page with language, timezone and keyboard
selection.
These selections should depend on each other, so depending on where I
click first the others change.
To have a good looking addon, I picture the timezone selection as
picture and not as fullscreen list boxes.
Discussion:
#1: coolo(a)novell.com (2007-11-09 11:48:30)
An additional note, feature #302955 is related (split translations out
of installation system).
#2: jsrain(a)novell.com (2007-11-09 13:27:05)
Isn't it easier for users who do not speak English to have the first
dialog really as simple as possible (since they cannot read it)? Having
just one selection box leads them straight where they need to get; I
guess that most of them use mouse for installation, so keyboard is not
an issue either...
Also, we already have a support in isolinux to select language; then
the first dialog is skipped.
#3: coolo(a)novell.com (2007-11-09 14:13:14)
If isolinux provides a language, then the page is not worse than the
timezone page is now. Just that it also allows to change the language
after the fact.
If users do not grasp english _at all_, they will have a hard time
booting the installation off the CD. So I would blindly assume that
users have no problem with selecting Deutsch, русский or čeština when
presented with a list even if they do not understand the exact context.
And when next to that list is even a graphical presentation of the
world, most will be able to select the part of the world they live in.
#4: evamaria.fuchs(a)novell.com (2007-11-09 16:00:35)
I think for the secondary target market of opensuse (first time user,
home user)an installer wizard that consists of a series of screens
would be convenient.
Basically it's preferable that language-, time-zone- and keyboard-
selection depend on each other so that modifying one will effect the
others. But - as I prefer a picture (e.g. a rotating globe) for time-
zone selection - sticking them together in one screen would clutter the
whole thing up.
#5: coolo(a)novell.com (2007-11-15 13:01:50)
after some discussions with Eva, I want to reexpress my request:
I want the language selection to be on one page together with license
and a welcome text and the timezone dialog to be graphical and a
proposed keyboard layout associated to the language from the first
page.
The license text doesn't have to be visible in full beauty. I talked
with the lawyer and what I got was: it's ok if the license can be read,
it doesn't have to optimized for scrolling.
I'll work on a mockup. The challenge is that we might need a slightly
different work flow for ncurses, but I think popups are ok for it. So
you can write UI code, that either fills a special widget or opens a
popup.
#6: coolo(a)novell.com (2007-11-18 13:53:57) (reply to #5)
Danger Mouse! I'm very far from a capable mockup designer.
But here is my show: http://ktown.kde.org/~coolo/Namenlos.png
#7: coolo(a)novell.com (2007-11-18 13:54:45) (reply to #6)
Ciaran, just to verify: is this way to present the license ok?
#9: cfarrell(a)suse.de (2007-11-19 08:51:13) (reply to #7)
Provided that we maintain the status quo with regard to not proceeding
with the installation until the user actually accepts the license.
#8: coolo(a)novell.com (2007-11-18 14:39:45) (reply to #6)
mocking up the timezone page, I leave to the interested reader.
For reference: this is how unbuntu's installer looks like: https://help.ubuntu.com/community/GraphicalInstall?action=AttachFile&do=get…
I would make the map a little smaller and do not show a region and not
the name of the timezone again, but rather have the value of the
combobox fill in what we have now as Europe/Berlin.
Because I want a "Keyboard: English" with a little test field in there.
But that is to be discussed. The main goal is to have a graphical
selection instead of these fullscreen list boxes.
#10: michl(a)novell.com (2007-11-19 13:28:22)
Mockup looks good. And the whole thing should simplify and shorten the
installation process.
#11: jsrain(a)novell.com (2007-11-19 16:57:23)
The timezone dialog looks good to me, however, we should not present
the other one in the current form. Even if we have a different dialog
for NCurses, we still must take care of Qt with the resolution of
800x600.
With the current font size, the text itself will not fit into the
screen if it is 800x600. Also consider the license - if one wants to
read it, he wants to read a reasonable part of the license without
scrolling - and not to scroll every 3rd line.
IMO this suggestion puts the usability a huge step back
#12: coolo(a)novell.com (2007-11-19 18:23:04) (reply to #11)
damn, fate crashed on my comment ;(
Again: I'm not a good designer
But as a matter of fact: we do not design the default screen estate for
reading the license, but of course a better design can add a popup to
read the full text in full screen.
#14: locilka(a)novell.com (2007-11-29 13:10:32)
Additional step to help user understand where he is and what he can do
there is to remove a [Show Release Notes] button and place that button
to a Welcome Dialog only. The button doesn't need to occupy
installation wizard screen all the time, it often rather confuses
users.
Frankly, this wasn't my idea but I found it useful :) ;)
#15: jsuchome(a)novell.com (2007-12-20 16:19:25)
Proposal of timezone dialog with a map: http://w3.suse.de/~jsuchome/screenshots/yast2-timezone-wordmap-zoomed.png
BTW, it may not have a sense to offer keyboard configuration together with
timezone. Keyboard layout is currently decided according to selected
language, so it may better fit together with language. But the language
dialog could get eventually too crowded.
#16: coolo(a)novell.com (2007-12-22 14:05:24)
new screenshot for the first page (I tried ycp):
http://ktown.kde.org/~coolo/yast7.png
Some icons and some more text would help the design I'd think.
#17: coolo(a)novell.com (2008-01-08 12:40:13)
http://en.opensuse.org/Image:Yast8.png is Martin's counter proposal.
This one needs icons to differ the combo boxes though, but I believe a
keyboard and an UN flag should make this obvious enough.
#18: locilka(a)novell.com (2008-01-10 15:24:31) (reply to #17)
BTW: This complex dialog will not be part of yast2-country (or similar)
but directly yast2-installation because it contains more than just
defining the language and keyboard settings. License handling needs to
be reworked.
#19: jsuchome(a)novell.com (2008-01-23 09:37:39) (reply to #18)
Well, OK than. I expect you will ask for creating some API of Language
(and maybe Keyboard) module, because current one probably is not
sufficient. The API should be used instead writing whole stuff again
separately, so we don't have the language handling on more places.
#20: locilka(a)novell.com (2008-01-28 11:22:59) (reply to #19)
Yes, Language API would probably help a lot.
Please, propose, what you could create considering the default state at http://svn.opensuse.org/svn/yast/trunk/installation/src/clients/inst_comple…
For instance, generating the combo boxes for language and keyboard
selections might be moved to the API (I saw some functions in the
current API though).
The current implementation has been done in a hurry before the alpha
deadline, it needs to be polished. Feel free to change it directly,
it's open source.
+ #21: jsuchome(a)novell.com (2008-01-28 11:32:01) (reply to #20)
+ I agree, currently the API for generating the widget contents is
+ needed, maybe that's all. I have to check it.
--
SUSE Feature Tool:
http://partnerfate.suse.de/?rm=feature_show&id=302957
Feature changed by: locilka
Feature #302957, revision 25
Title: Combined "where am I" page
openSUSE-11.0: Candidate
Priority
Requester: Mandatory
Projectmanager: Important
SLED-11: New
Priority
Requester: Mandatory
SLES-11: New
Priority
Requester: Mandatory
Requested by: coolo(a)novell.com
Partner organization: openSUSE.org
Description:
Our (openSUSE) statistics show that most of our users are not native
english speakers. So I'm blindly assuming they do not have a english
keyboard either and do not live in an english speaking timezone.
So I want the first page to be not just the language in a blue box, but
to have _one_ installation page with language, timezone and keyboard
selection.
These selections should depend on each other, so depending on where I
click first the others change.
To have a good looking addon, I picture the timezone selection as
picture and not as fullscreen list boxes.
Discussion:
#1: coolo(a)novell.com (2007-11-09 11:48:30)
An additional note, feature #302955 is related (split translations out
of installation system).
#2: jsrain(a)novell.com (2007-11-09 13:27:05)
Isn't it easier for users who do not speak English to have the first
dialog really as simple as possible (since they cannot read it)? Having
just one selection box leads them straight where they need to get; I
guess that most of them use mouse for installation, so keyboard is not
an issue either...
Also, we already have a support in isolinux to select language; then
the first dialog is skipped.
#3: coolo(a)novell.com (2007-11-09 14:13:14)
If isolinux provides a language, then the page is not worse than the
timezone page is now. Just that it also allows to change the language
after the fact.
If users do not grasp english _at all_, they will have a hard time
booting the installation off the CD. So I would blindly assume that
users have no problem with selecting Deutsch, русский or čeština when
presented with a list even if they do not understand the exact context.
And when next to that list is even a graphical presentation of the
world, most will be able to select the part of the world they live in.
#4: evamaria.fuchs(a)novell.com (2007-11-09 16:00:35)
I think for the secondary target market of opensuse (first time user,
home user)an installer wizard that consists of a series of screens
would be convenient.
Basically it's preferable that language-, time-zone- and keyboard-
selection depend on each other so that modifying one will effect the
others. But - as I prefer a picture (e.g. a rotating globe) for time-
zone selection - sticking them together in one screen would clutter the
whole thing up.
#5: coolo(a)novell.com (2007-11-15 13:01:50)
after some discussions with Eva, I want to reexpress my request:
I want the language selection to be on one page together with license
and a welcome text and the timezone dialog to be graphical and a
proposed keyboard layout associated to the language from the first
page.
The license text doesn't have to be visible in full beauty. I talked
with the lawyer and what I got was: it's ok if the license can be read,
it doesn't have to optimized for scrolling.
I'll work on a mockup. The challenge is that we might need a slightly
different work flow for ncurses, but I think popups are ok for it. So
you can write UI code, that either fills a special widget or opens a
popup.
#6: coolo(a)novell.com (2007-11-18 13:53:57) (reply to #5)
Danger Mouse! I'm very far from a capable mockup designer.
But here is my show: http://ktown.kde.org/~coolo/Namenlos.png
#7: coolo(a)novell.com (2007-11-18 13:54:45) (reply to #6)
Ciaran, just to verify: is this way to present the license ok?
#9: cfarrell(a)suse.de (2007-11-19 08:51:13) (reply to #7)
Provided that we maintain the status quo with regard to not proceeding
with the installation until the user actually accepts the license.
#8: coolo(a)novell.com (2007-11-18 14:39:45) (reply to #6)
mocking up the timezone page, I leave to the interested reader.
For reference: this is how unbuntu's installer looks like: https://help.ubuntu.com/community/GraphicalInstall?action=AttachFile&do=get…
I would make the map a little smaller and do not show a region and not
the name of the timezone again, but rather have the value of the
combobox fill in what we have now as Europe/Berlin.
Because I want a "Keyboard: English" with a little test field in there.
But that is to be discussed. The main goal is to have a graphical
selection instead of these fullscreen list boxes.
#10: michl(a)novell.com (2007-11-19 13:28:22)
Mockup looks good. And the whole thing should simplify and shorten the
installation process.
#11: jsrain(a)novell.com (2007-11-19 16:57:23)
The timezone dialog looks good to me, however, we should not present
the other one in the current form. Even if we have a different dialog
for NCurses, we still must take care of Qt with the resolution of
800x600.
With the current font size, the text itself will not fit into the
screen if it is 800x600. Also consider the license - if one wants to
read it, he wants to read a reasonable part of the license without
scrolling - and not to scroll every 3rd line.
IMO this suggestion puts the usability a huge step back
#12: coolo(a)novell.com (2007-11-19 18:23:04) (reply to #11)
damn, fate crashed on my comment ;(
Again: I'm not a good designer
But as a matter of fact: we do not design the default screen estate for
reading the license, but of course a better design can add a popup to
read the full text in full screen.
#14: locilka(a)novell.com (2007-11-29 13:10:32)
Additional step to help user understand where he is and what he can do
there is to remove a [Show Release Notes] button and place that button
to a Welcome Dialog only. The button doesn't need to occupy
installation wizard screen all the time, it often rather confuses
users.
Frankly, this wasn't my idea but I found it useful :) ;)
#15: jsuchome(a)novell.com (2007-12-20 16:19:25)
Proposal of timezone dialog with a map: http://w3.suse.de/~jsuchome/screenshots/yast2-timezone-wordmap-zoomed.png
BTW, it may not have a sense to offer keyboard configuration together with
timezone. Keyboard layout is currently decided according to selected
language, so it may better fit together with language. But the language
dialog could get eventually too crowded.
#16: coolo(a)novell.com (2007-12-22 14:05:24)
new screenshot for the first page (I tried ycp):
http://ktown.kde.org/~coolo/yast7.png
Some icons and some more text would help the design I'd think.
#17: coolo(a)novell.com (2008-01-08 12:40:13)
http://en.opensuse.org/Image:Yast8.png is Martin's counter proposal.
This one needs icons to differ the combo boxes though, but I believe a
keyboard and an UN flag should make this obvious enough.
#18: locilka(a)novell.com (2008-01-10 15:24:31) (reply to #17)
BTW: This complex dialog will not be part of yast2-country (or similar)
but directly yast2-installation because it contains more than just
defining the language and keyboard settings. License handling needs to
be reworked.
#19: jsuchome(a)novell.com (2008-01-23 09:37:39) (reply to #18)
Well, OK than. I expect you will ask for creating some API of Language
(and maybe Keyboard) module, because current one probably is not
sufficient. The API should be used instead writing whole stuff again
separately, so we don't have the language handling on more places.
+ #20: locilka(a)novell.com (2008-01-28 11:22:59) (reply to #19)
+ Yes, Language API would probably help a lot.
+ Please, propose, what you could create considering the default state at http://svn.opensuse.org/svn/yast/trunk/installation/src/clients/inst_comple…
+ For instance, generating the combo boxes for language and keyboard
+ selections might be moved to the API (I saw some functions in the
+ current API though).
+ The current implementation has been done in a hurry before the alpha
+ deadline, it needs to be polished. Feel free to change it directly,
+ it's open source.
--
SUSE Feature Tool:
http://partnerfate.suse.de/?rm=feature_show&id=302957
Feature changed by: jpr
Feature #303367, revision 6
Title: Better Beagle Acceptance
openSUSE-11.0: Evaluation
Priority
Requester: Mandatory
Requested by: aj(a)novell.com
Partner organization: openSUSE.org
Description:
There have been several discussions on the public openSUSE mailing
lists, e.g.
http://lists.opensuse.org/opensuse-factory/2008-01/msg00157.html where
people complain about resource usage or garbage from beagle.
I suggest that we analyze the current situation and check where are
real problems and consider solutions. One option would be to make it
easier for users to not enable beagle on their systems.
Note: The feature request is about getting a better acceptance by our
users of our indexing technology - and therefore let's figure out what
are the problems they are hitting in real life.
References:
https://bugzilla.novell.com/show_bug.cgi?id=282678
Discussion:
#1: aj(a)novell.com (2008-01-20 11:12:58)
See also bug 282678.
#2: aj(a)novell.com (2008-01-23 16:23:51)
Note: powertop advises "Suggestion: Disable or remove 'beagle' from
your system. Beagle is the program that indexes for easy desktop
search, however it's not very efficient and costs a significant amount
of battery life.".
#3: jpr(a)novell.com (2008-01-23 10:38:58) (reply to #2)
Yes, this is well known and was covered extensively last year and
caused by polling for battery status in some cases.
0.3.2 uses hal to detect battery status:
http://www.mail-archive.com/dashboard-hackers@gnome.org/msg03464.html
+ #4: jpr(a)novell.com (2008-01-23 10:41:35) (reply to #3)
+ Also part of it was a mono issue: http://www.nabble.com/Beagle-indexing-when-running-on-batteries-td13842939.…
--
SUSE Feature Tool:
http://partnerfate.suse.de/?rm=feature_show&id=303367
Feature changed by: jpr
Feature #303367, revision 5
Title: Better Beagle Acceptance
openSUSE-11.0: Evaluation
Priority
Requester: Mandatory
Requested by: aj(a)novell.com
Partner organization: openSUSE.org
Description:
There have been several discussions on the public openSUSE mailing
lists, e.g.
http://lists.opensuse.org/opensuse-factory/2008-01/msg00157.html where
people complain about resource usage or garbage from beagle.
I suggest that we analyze the current situation and check where are
real problems and consider solutions. One option would be to make it
easier for users to not enable beagle on their systems.
Note: The feature request is about getting a better acceptance by our
users of our indexing technology - and therefore let's figure out what
are the problems they are hitting in real life.
References:
https://bugzilla.novell.com/show_bug.cgi?id=282678
Discussion:
#1: aj(a)novell.com (2008-01-20 11:12:58)
See also bug 282678.
#2: aj(a)novell.com (2008-01-23 16:23:51)
Note: powertop advises "Suggestion: Disable or remove 'beagle' from
your system. Beagle is the program that indexes for easy desktop
search, however it's not very efficient and costs a significant amount
of battery life.".
+ #3: jpr(a)novell.com (2008-01-23 10:38:58) (reply to #2)
+ Yes, this is well known and was covered extensively last year and
+ caused by polling for battery status in some cases.
+ 0.3.2 uses hal to detect battery status:
+ http://www.mail-archive.com/dashboard-hackers@gnome.org/msg03464.html
--
SUSE Feature Tool:
http://partnerfate.suse.de/?rm=feature_show&id=303367
Feature changed by: aj
Feature #303367, revision 4
Title: Better Beagle Acceptance
openSUSE-11.0: Evaluation
Priority
Requester: Mandatory
Requested by: aj(a)novell.com
Partner organization: openSUSE.org
Description:
There have been several discussions on the public openSUSE mailing
lists, e.g.
http://lists.opensuse.org/opensuse-factory/2008-01/msg00157.html where
people complain about resource usage or garbage from beagle.
I suggest that we analyze the current situation and check where are
real problems and consider solutions. One option would be to make it
easier for users to not enable beagle on their systems.
Note: The feature request is about getting a better acceptance by our
users of our indexing technology - and therefore let's figure out what
are the problems they are hitting in real life.
References:
https://bugzilla.novell.com/show_bug.cgi?id=282678
Discussion:
#1: aj(a)novell.com (2008-01-20 11:12:58)
See also bug 282678.
+ #2: aj(a)novell.com (2008-01-23 16:23:51)
+ Note: powertop advises "Suggestion: Disable or remove 'beagle' from
+ your system. Beagle is the program that indexes for easy desktop
+ search, however it's not very efficient and costs a significant amount
+ of battery life.".
--
SUSE Feature Tool:
http://partnerfate.suse.de/?rm=feature_show&id=303367
Feature changed by: jsuchome
Feature #302957, revision 24
Title: Combined "where am I" page
openSUSE-11.0: Candidate
Priority
Requester: Mandatory
Projectmanager: Important
SLED-11: New
Priority
Requester: Mandatory
SLES-11: New
Priority
Requester: Mandatory
Requested by: coolo(a)novell.com
Partner organization: openSUSE.org
Description:
Our (openSUSE) statistics show that most of our users are not native
english speakers. So I'm blindly assuming they do not have a english
keyboard either and do not live in an english speaking timezone.
So I want the first page to be not just the language in a blue box, but
to have _one_ installation page with language, timezone and keyboard
selection.
These selections should depend on each other, so depending on where I
click first the others change.
To have a good looking addon, I picture the timezone selection as
picture and not as fullscreen list boxes.
Discussion:
#1: coolo(a)novell.com (2007-11-09 11:48:30)
An additional note, feature #302955 is related (split translations out
of installation system).
#2: jsrain(a)novell.com (2007-11-09 13:27:05)
Isn't it easier for users who do not speak English to have the first
dialog really as simple as possible (since they cannot read it)? Having
just one selection box leads them straight where they need to get; I
guess that most of them use mouse for installation, so keyboard is not
an issue either...
Also, we already have a support in isolinux to select language; then
the first dialog is skipped.
#3: coolo(a)novell.com (2007-11-09 14:13:14)
If isolinux provides a language, then the page is not worse than the
timezone page is now. Just that it also allows to change the language
after the fact.
If users do not grasp english _at all_, they will have a hard time
booting the installation off the CD. So I would blindly assume that
users have no problem with selecting Deutsch, русский or čeština when
presented with a list even if they do not understand the exact context.
And when next to that list is even a graphical presentation of the
world, most will be able to select the part of the world they live in.
#4: evamaria.fuchs(a)novell.com (2007-11-09 16:00:35)
I think for the secondary target market of opensuse (first time user,
home user)an installer wizard that consists of a series of screens
would be convenient.
Basically it's preferable that language-, time-zone- and keyboard-
selection depend on each other so that modifying one will effect the
others. But - as I prefer a picture (e.g. a rotating globe) for time-
zone selection - sticking them together in one screen would clutter the
whole thing up.
#5: coolo(a)novell.com (2007-11-15 13:01:50)
after some discussions with Eva, I want to reexpress my request:
I want the language selection to be on one page together with license
and a welcome text and the timezone dialog to be graphical and a
proposed keyboard layout associated to the language from the first
page.
The license text doesn't have to be visible in full beauty. I talked
with the lawyer and what I got was: it's ok if the license can be read,
it doesn't have to optimized for scrolling.
I'll work on a mockup. The challenge is that we might need a slightly
different work flow for ncurses, but I think popups are ok for it. So
you can write UI code, that either fills a special widget or opens a
popup.
#6: coolo(a)novell.com (2007-11-18 13:53:57) (reply to #5)
Danger Mouse! I'm very far from a capable mockup designer.
But here is my show: http://ktown.kde.org/~coolo/Namenlos.png
#7: coolo(a)novell.com (2007-11-18 13:54:45) (reply to #6)
Ciaran, just to verify: is this way to present the license ok?
#9: cfarrell(a)suse.de (2007-11-19 08:51:13) (reply to #7)
Provided that we maintain the status quo with regard to not proceeding
with the installation until the user actually accepts the license.
#8: coolo(a)novell.com (2007-11-18 14:39:45) (reply to #6)
mocking up the timezone page, I leave to the interested reader.
For reference: this is how unbuntu's installer looks like: https://help.ubuntu.com/community/GraphicalInstall?action=AttachFile&do=get…
I would make the map a little smaller and do not show a region and not
the name of the timezone again, but rather have the value of the
combobox fill in what we have now as Europe/Berlin.
Because I want a "Keyboard: English" with a little test field in there.
But that is to be discussed. The main goal is to have a graphical
selection instead of these fullscreen list boxes.
#10: michl(a)novell.com (2007-11-19 13:28:22)
Mockup looks good. And the whole thing should simplify and shorten the
installation process.
#11: jsrain(a)novell.com (2007-11-19 16:57:23)
The timezone dialog looks good to me, however, we should not present
the other one in the current form. Even if we have a different dialog
for NCurses, we still must take care of Qt with the resolution of
800x600.
With the current font size, the text itself will not fit into the
screen if it is 800x600. Also consider the license - if one wants to
read it, he wants to read a reasonable part of the license without
scrolling - and not to scroll every 3rd line.
IMO this suggestion puts the usability a huge step back
#12: coolo(a)novell.com (2007-11-19 18:23:04) (reply to #11)
damn, fate crashed on my comment ;(
Again: I'm not a good designer
But as a matter of fact: we do not design the default screen estate for
reading the license, but of course a better design can add a popup to
read the full text in full screen.
#14: locilka(a)novell.com (2007-11-29 13:10:32)
Additional step to help user understand where he is and what he can do
there is to remove a [Show Release Notes] button and place that button
to a Welcome Dialog only. The button doesn't need to occupy
installation wizard screen all the time, it often rather confuses
users.
Frankly, this wasn't my idea but I found it useful :) ;)
#15: jsuchome(a)novell.com (2007-12-20 16:19:25)
Proposal of timezone dialog with a map: http://w3.suse.de/~jsuchome/screenshots/yast2-timezone-wordmap-zoomed.png
BTW, it may not have a sense to offer keyboard configuration together with
timezone. Keyboard layout is currently decided according to selected
language, so it may better fit together with language. But the language
dialog could get eventually too crowded.
#16: coolo(a)novell.com (2007-12-22 14:05:24)
new screenshot for the first page (I tried ycp):
http://ktown.kde.org/~coolo/yast7.png
Some icons and some more text would help the design I'd think.
#17: coolo(a)novell.com (2008-01-08 12:40:13)
http://en.opensuse.org/Image:Yast8.png is Martin's counter proposal.
This one needs icons to differ the combo boxes though, but I believe a
keyboard and an UN flag should make this obvious enough.
#18: locilka(a)novell.com (2008-01-10 15:24:31) (reply to #17)
BTW: This complex dialog will not be part of yast2-country (or similar)
but directly yast2-installation because it contains more than just
defining the language and keyboard settings. License handling needs to
be reworked.
+ #19: jsuchome(a)novell.com (2008-01-23 09:37:39) (reply to #18)
+ Well, OK than. I expect you will ask for creating some API of Language
+ (and maybe Keyboard) module, because current one probably is not
+ sufficient. The API should be used instead writing whole stuff again
+ separately, so we don't have the language handling on more places.
--
SUSE Feature Tool:
http://partnerfate.suse.de/?rm=feature_show&id=302957