ubuntu-sdk-bugs team mailing list archive

[Andrea Bernabei <andrea.bernabei@xxxxxxxxxxxxx>]

Public bug reported:

ubuntu-ui-toolkit r1873

Currently, when creating a list item, the developer has to manually bind
the height of the ListItem to that of ListItemLayout that it contains.

Since this is not intuitive in QML (you usually bind content's size to
parent's, not the opposite), we're seeing that the developers most of
the times forget to add that binding.

Proof: even the UI Components Gallery was not doing it, and as a result the labels in the list items of the left panel were *slightly* offset.
https://code.launchpad.net/~faenil/ubuntu-ui-toolkit/fixListItemAlignmentUIGallery/+merge/287492

If the developer doesn't add that binding, the ListItem usually ends up
being shorter in height than the ListItemLayout (or SlotsLayout) it
contains.

This is usually not a big issue because the deafult ListItem height is
enough to show a couple of labels in a column, so the developer will
usually not realize that he's done something wrong, but the vertical
alignment of the slots will be wrong, because it's computed relative to
ListItemLayout's height, not ListItem's (since ListItemLayout resizes
dynamically by design to accomodate all the slots).

In the worst case (very tall ListItemLayout/SlotsLayout with lots of
text), ListItem layout will clip part of the content.

My proposal is that we handle this automatically.
The developer should not have to care about this detail, because ListItem+ListItemLayout/SlotsLayout is the our main and most important usecase for those components, so it should work straight out of the box and be as simple as possible to implement.

My solution (although I only know ListItemLayout/SlotsLayout's code, not ListItem's):
- change ListItem so that when a new child is added (content), it checks if that child is a SlotsLayout-derived component. If that is the case, and if that's the only child, then ListItem binds to content's height.

NOTE: the solution described above is just a proposal, please make sure that the implementation doesn't prevent the dev from overriding or changing the behaviour if needed. 
Moreover, I think the binding should not be created automatically if there's more than one child (which I think is then case when using ListItem's "expansion" mode)

** Affects: ubuntu-ui-toolkit (Ubuntu)
     Importance: High
     Assignee: Zsombor Egri (zsombi)
         Status: Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
SDK bug tracking, which is subscribed to ubuntu-ui-toolkit in Ubuntu.
https://bugs.launchpad.net/bugs/1551349

Title:
  Make ListItem automatically bind to the height of a
  SlotsLayout/ListItemLayout when that's the only content

Status in ubuntu-ui-toolkit package in Ubuntu:
  Confirmed

Bug description:
  ubuntu-ui-toolkit r1873

  Currently, when creating a list item, the developer has to manually
  bind the height of the ListItem to that of ListItemLayout that it
  contains.

  Since this is not intuitive in QML (you usually bind content's size to
  parent's, not the opposite), we're seeing that the developers most of
  the times forget to add that binding.

  Proof: even the UI Components Gallery was not doing it, and as a result the labels in the list items of the left panel were *slightly* offset.
  https://code.launchpad.net/~faenil/ubuntu-ui-toolkit/fixListItemAlignmentUIGallery/+merge/287492

  If the developer doesn't add that binding, the ListItem usually ends
  up being shorter in height than the ListItemLayout (or SlotsLayout) it
  contains.

  This is usually not a big issue because the deafult ListItem height is
  enough to show a couple of labels in a column, so the developer will
  usually not realize that he's done something wrong, but the vertical
  alignment of the slots will be wrong, because it's computed relative
  to ListItemLayout's height, not ListItem's (since ListItemLayout
  resizes dynamically by design to accomodate all the slots).

  In the worst case (very tall ListItemLayout/SlotsLayout with lots of
  text), ListItem layout will clip part of the content.

  My proposal is that we handle this automatically.
  The developer should not have to care about this detail, because ListItem+ListItemLayout/SlotsLayout is the our main and most important usecase for those components, so it should work straight out of the box and be as simple as possible to implement.

  My solution (although I only know ListItemLayout/SlotsLayout's code, not ListItem's):
  - change ListItem so that when a new child is added (content), it checks if that child is a SlotsLayout-derived component. If that is the case, and if that's the only child, then ListItem binds to content's height.

  NOTE: the solution described above is just a proposal, please make sure that the implementation doesn't prevent the dev from overriding or changing the behaviour if needed. 
  Moreover, I think the binding should not be created automatically if there's more than one child (which I think is then case when using ListItem's "expansion" mode)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1551349/+subscriptions