desktop-packages team mailing list archive
-
desktop-packages team
-
Mailing list archive
-
Message #129265
[Bug 1016603] Re: table design view handles field length non-intuitively
** Tags added: enhancement trusty
** Tags removed: i386
** Tags added: base
--
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 chanes 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.
- 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 (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 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 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