dx-packages team mailing list archive

[Christian Dywan <christian@xxxxxxxxxxxx>]

The preliminary conclusion is to leave this out of the new API - the
current ListItem is going to be deprecated because it's by design very
slow. The built-in shape feature is actually one of the reasons for
that. And it looks to be the minority of use cases that require a shape
at all.

14:33 <zsombi> kalikiana: the new ListItem does not have any shape, whatever you put in it that will eb shown, no predefined layout, nothing
14:34 <zsombi> kalikiana: all we have are layout helpers, like ListItemLayout, which is only a GridLayout with 2GU marging left/right
14:34 <kalikiana> zsombi: hmm would it make sense to have an app layout for that?
14:34 <zsombi> kalikiana: it won't be flexible enough...
14:35 <zsombi> kalikiana: the idea is that you could have an icon or an image there, framed or frameless
14:36 <kalikiana> zsombi: yeah that's what I'm wondering. it's tedious to hunt down the exact use cases… it may not even make sense to have a standard way of doing it, many of the bugs right now are due to the default being true which is almost always wrong
14:37 <zsombi> kalikiana: right. And if you don't need frame, meaning teh image/icon should not be in a Shape, then we'd have a dangling Shape component which is not visible but its initialization time eats performance...

** Changed in: ubuntu-ui-toolkit
       Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of DX
Packages, which is subscribed to notify-osd in Ubuntu.
Matching subscriptions: dx-packages
https://bugs.launchpad.net/bugs/1363015

Title:
  App icons require shaping at every callsite

Status in Ubuntu UI Toolkit:
  Won't Fix
Status in “notify-osd” package in Ubuntu:
  New

Bug description:
  In list items, showing an app icon in the correct Ubuntu shape requires shaping it when you are using it: ListItem.Standard{IconFrame: True}.
  <http://developer.ubuntu.com/api/qml/sdk-14.04/Ubuntu.Components.ListItems.Standard/#iconFrame-prop>

  That property is set to "True" by default, but it's not obvious why it
  should be, and list items aren't the only place that app icons get
  used.

  The result is that several times now, app updates have ended up without the appropriate frame:
  - in the System Settings "Updates" list (bug 1354478)
  - in the "Notifications" screen
  - in the Launcher the frame is unintentionally different (bug 1332119).

  Conversely, non-app icons have ended up *with* the frame by mistake:
  - "Display language" (bug 1288866)
  - "Orientation Lock" (bug 1365450)
  - Ubuntu updates (bug 1367136).

  In notification bubbles, the opposite applies -- you have to set a hint to use an *unshaped* icon: notify_notification_set_hint_string(m_notification, "x-canonical-non-shaped-icon", "true").
  <https://wiki.ubuntu.com/Touch/Notifications#Elements_of_a_Notification>

  Predictably, this has resulted in cases of icons having frames when they shouldn't:
  - Wi-Fi network authentication (bug 1346904)
  - alarms (bug 1346925)
  - Remove Account (bug 1350282).

  On the API design quality scale, both of these are roughly "Read the
  implementation and you'll get it right." <http://sweng.the-
  davies.net/Home/rustys-api-design-manifesto> Worse, they have opposite
  defaults.

  I suggest that the toolkit move all the way up to "It's impossible to
  get wrong", by always shaping an icon when it is an app icon, and
  never otherwise. Whether an icon is an app icon could (I assume) be
  detected by its path.

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