desktop-packages team mailing list archive
-
desktop-packages team
-
Mailing list archive
-
Message #129333
[Bug 1016603] Re: table design view handles field length non-intuitively
** Description changed:
Table design view handles field length non-intuitively when picking
different field types. For example:
1. Choose VARBINARY field type, the Length input field below gets filled with 2147483647.
2. Now pick CHAR field type, the Length input field remains the same (2147483647).
- 3. Pick SMALLINT, the Length chanes to 5.
+ 3. Pick SMALLINT, the Length changes to 5.
This behaviour _may_ be acceptable (some field types can have min-max
lenghts, others are defined to be fixed length, etc.), but for the
novice user it appears confusing.
I suggest that:
- For fixed length field types (TINYINT, BOOLEAN, REAL, etc.) the Lenth
field should be _visibly_ disabled (grayed out). Right now, it is
disabled, but this is not indicated by any shading, coloring, whatever.
- The average user won't understand, why the Length is not changeable.
+ The average user won't understand, why the Length field is disabled.
- When field types with min-max length restrictions are chosen, the GUI
should clearly indicate the length limits. (Do not expect the novice
user to read into the SQL standard for this.)
- Have a default length value for every field type, and overwrite the
length with it whenever the field type is changed. IMHO this is
- especially useful when the user is creating the table the first time and
- skimming through the varius field types. Accidentally assigning a CHAR
- type length to be 2147483647 instead of 100 (see 1-2 steps above) should
- be avoided. I guess that there are scenarios where the current behaviour
+ especially useful when the user is creating a new the table and skimming
+ through the varius field types. Accidentally assigning a CHAR type
+ length to be 2147483647 instead of 100 (see 1-2 steps above) should be
+ avoided. I guess that there are scenarios where the current behaviour
(only touch the length value when changing to a field type, for which
- the current length value is too high/low) is only safer when modifiing
+ the current length value is too high/low) is only safer when modifying
an existing table structure - changing a CHAR field to VARCHAR for
example. But that small safety is also lost after the user accidentally
- picks a BOOLEAN or a VARBINARY type. So I guess if the we're creating a
+ picks a BOOLEAN or a VARBINARY type. So I guess if we're creating a
brand new table column, then the length should be overwritten by a
default tied to the field type, whenever the field type changes. And if
we're in the middle of editing an existing column, the GUI should always
remember the original length value and try to set it as a default,
whenever a different field type is selected, and the length constraints
of that field type allow the original length value. Otherwise it should
set the length to the value that is closest to the original length.
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libreoffice-base 1:3.5.3-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-25.40-generic-pae 3.2.18
Uname: Linux 3.2.0-25-generic-pae i686
NonfreeKernelModules: nvidia
ApportVersion: 2.0.1-0ubuntu8
Architecture: i386
CheckboxSubmission: e665592ec356650b8c1e4f41698ed522
CheckboxSystem: 4ed15c40009aa6f7770f606350a390a2
Date: Fri Jun 22 16:47:26 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta i386 (20120301)
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/1016603
Title:
table design view handles field length non-intuitively
Status in libreoffice package in Ubuntu:
Confirmed
Bug description:
Table design view handles field length non-intuitively when picking
different field types. For example:
1. Choose VARBINARY field type, the Length input field below gets filled with 2147483647.
2. Now pick CHAR field type, the Length input field remains the same (2147483647).
3. Pick SMALLINT, the Length changes to 5.
This behaviour _may_ be acceptable (some field types can have min-max
lenghts, others are defined to be fixed length, etc.), but for the
novice user it appears confusing.
I suggest that:
- For fixed length field types (TINYINT, BOOLEAN, REAL, etc.) the
Lenth field should be _visibly_ disabled (grayed out). Right now, it
is disabled, but this is not indicated by any shading, coloring,
whatever. The average user won't understand, why the Length field is
disabled.
- When field types with min-max length restrictions are chosen, the
GUI should clearly indicate the length limits. (Do not expect the
novice user to read into the SQL standard for this.)
- Have a default length value for every field type, and overwrite the
length with it whenever the field type is changed. IMHO this is
especially useful when the user is creating a new the table and
skimming through the varius field types. Accidentally assigning a CHAR
type length to be 2147483647 instead of 100 (see 1-2 steps above)
should be avoided. I guess that there are scenarios where the current
behaviour (only touch the length value when changing to a field type,
for which the current length value is too high/low) is only safer when
modifying an existing table structure - changing a CHAR field to
VARCHAR for example. But that small safety is also lost after the user
accidentally picks a BOOLEAN or a VARBINARY type. So I guess if we're
creating a brand new table column, then the length should be
overwritten by a default tied to the field type, whenever the field
type changes. And if we're in the middle of editing an existing
column, the GUI should always remember the original length value and
try to set it as a default, whenever a different field type is
selected, and the length constraints of that field type allow the
original length value. Otherwise it should set the length to the value
that is closest to the original length.
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libreoffice-base 1:3.5.3-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-25.40-generic-pae 3.2.18
Uname: Linux 3.2.0-25-generic-pae i686
NonfreeKernelModules: nvidia
ApportVersion: 2.0.1-0ubuntu8
Architecture: i386
CheckboxSubmission: e665592ec356650b8c1e4f41698ed522
CheckboxSystem: 4ed15c40009aa6f7770f606350a390a2
Date: Fri Jun 22 16:47:26 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta i386 (20120301)
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1016603/+subscriptions