desktop-packages team mailing list archive

[Launchpad Bug Tracker <1016603@xxxxxxxxxxxxxxxxxx>]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: libreoffice (Ubuntu)
       Status: New => Confirmed

-- 
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