[Desktop-packages] [Bug 1279499] Re: Input interactions in the Switcher has random behavior

2014-04-02 Thread Stephen M. Webb
Fix Released in Unity Unity 7.2.0.

** Changed in: unity
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity in Ubuntu.
Matching subscriptions: dp-unity
https://bugs.launchpad.net/bugs/1279499

Title:
  Input interactions in the Switcher has random behavior

Status in Unity:
  Fix Released
Status in “unity” package in Ubuntu:
  Fix Released

Bug description:
  When using the Switcher with either the mouse or arrow keys, sometimes
  they would work and other times they would not.

  This is causing quite a few AP tests to fail which is blocking landing
  Unity in distro.

To manage notifications about this bug go to:
https://bugs.launchpad.net/unity/+bug/1279499/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1279499] Re: Input interactions in the Switcher has random behavior

2014-02-17 Thread Launchpad Bug Tracker
This bug was fixed in the package unity -
7.1.2+14.04.20140214.1-0ubuntu1

---
unity (7.1.2+14.04.20140214.1-0ubuntu1) trusty; urgency=low

  [ Sebastien Bacher ]
  * use unity-control-center by default.
  * lists keybinding in unity-control-center. (LP: #1271710)

  [ Brandon Schaefer ]
  * Bump to new libnux from this branch:
https://code.launchpad.net/~brandontschaefer/nux/xim-preedit-
support.
  * Adds Super+L to lock the screen, while keeping the older shortcut
around in g-s-d (Ctrl+Alt+L). (LP: #830709)
  * Do not open the dash/hud on a monitor with a top most window that is
fullscreen. (LP: #1267210)
  * Implement an EMConveter. This way with default settings such that
DPI = 96.0f, and font_size = system font size. We can get the
correct EM value for any pixel size. Once we have the correct EM
value for any pixel size, the DPI value can be adjusted to the
current logical one. From here, you can now get the correct pixel
size based from of the EM value for the logical DPI of the screen.
  * Refactor EMConverter API. Now all thats needed is int
ConvertPixels(int pixel); This will calculate the correct pixel size
based on the DPI and font size.
  * Testing that the ibus anthy tests could possibly be causing strange
issues on the nvidia machine. So skipping them to test if tihs is
the source of the error.
  * Add Pt to Px function to em converter.
  * Move EMConverter over to unity settings.
  * Add multi monitor support for EMConverter in unity settings. Now you
can grab a specific converter per monitor.
  * Simple RawPixel class. It adds 2 define literals, ex: 10_em,
10.0_em. From there it turns them into raw pixels. RawPixels have CP
(CovertPixel) function which takes in an EMConverter that allows you
to use a converter specific to a monitor to convert the raw pixel to
the correct value.

  [ Marco Trevisan (Treviño) ]
  * Don't re-present all of our windows on every frame. Only do that if
damage intersects it. Use the new APIs exposed by compiz and nux to
intelligently determine which windows need to be presented per-frame
and only register damage for those windows. This fixes two things:
1. BaseWindows being redrawn from scratch every time damage was
registered over them. That was incorrect and should only be done in
the case of background blurs. 2. BaseWindows being drawn to the
screen on every frame, regardless of whether or not they needed to
be. Now they will only be drawn if some damage intersects beneath
them. Note that unity will expand the damage region to accomadate
the base window since nux does not support geometry clipping. So if
there is a partial intersection of the launcher for example, the
area of the screen which contains the launcher will be re-painted
(but the launcher itself won't be redrawn, just its texture) (LP:
#1080947). (LP: #1080947)
  * Convert compiz regions / rects to nux::Geometry's and back easily.
  * UnityScreen: remove the useless and expensive gl{Push,Pop}Attrib
calls For some reasons this code was copied by the opengl plugin as
a workaround to fix the state of our screen after that nux has
drawn. Actually this is not needed, the only thing we really need to
do is to fix the current Viewport, because nux seems to leave it in
a bad state which would lead to flickering menus, fullscreen
windows, tooltip and missing windows thumbnails in switcher. Thanks
to Sam Spilsbury for his precious support. (LP: #1251275)
  * Unity: always prefer passing [this] to lambdas than [].
  * Introspectable: use IntrospectionData class for collecting data from
children Now each introspectable object is called with an
IntrospectionData parameter and calling one of its methods it's the
only way to fill introspection data into unity. As bonus point,
remove all the unneeded UnityCore/Variant.cpp inclusions. (LP:
#1227131)
  * DebugDBusInterface: add local::xpathselect::NodeSelector to use the
dloaded lib.
  * BackgroundEffectHelper: Specify the required blur area before
drawing so selectively copy it at paint time This means that we
don't have to waste fragment bandwidth copying the entire backbuffer
when we could just do parts of it. Now BackgroundEffectHelper
listens to windows and views geometry changes and updates a list of
blurred regions that might be copied to the backup texture at every
repaint that affects them. This avoids to copy large regions
(especially when using big resolutions or multiple monitors), but
only the ones we really need to blur.
  * SwitcherView: define a custom GeometryGetterFunc and notify helper
on changes Thanks to this the switcher won't make
BackgroundEffectHelper to create a blurred area as big as the
current monitor (with just a small padding), but an area big enough
to draw its background. This get updated 

[Desktop-packages] [Bug 1279499] Re: Input interactions in the Switcher has random behavior

2014-02-12 Thread Christopher Townsend
** Changed in: unity
   Status: New = In Progress

** Description changed:

  When using the Switcher with either the mouse or arrow keys, sometimes
  they would work and other times they would not.
+ 
+ This is causing quite a few AP tests to fail which is blocking landing
+ Unity in distro.

** Changed in: unity
   Importance: Undecided = High

** Changed in: unity
 Assignee: (unassigned) = Christopher Townsend (townsend)

** Also affects: unity (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: unity (Ubuntu)
   Status: New = In Progress

** Changed in: unity (Ubuntu)
   Importance: Undecided = High

** Changed in: unity (Ubuntu)
 Assignee: (unassigned) = Christopher Townsend (townsend)

** Changed in: unity
Milestone: None = 7.2.0

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity in Ubuntu.
Matching subscriptions: dp-unity
https://bugs.launchpad.net/bugs/1279499

Title:
  Input interactions in the Switcher has random behavior

Status in Unity:
  In Progress
Status in “unity” package in Ubuntu:
  In Progress

Bug description:
  When using the Switcher with either the mouse or arrow keys, sometimes
  they would work and other times they would not.

  This is causing quite a few AP tests to fail which is blocking landing
  Unity in distro.

To manage notifications about this bug go to:
https://bugs.launchpad.net/unity/+bug/1279499/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp