Though, the Unity code doesn't seem to use HSplitter or VSplitter. Also,
it doesn't call QueueRelayout on any InputArea objects, which seems to
be the only other way for an InputArea object to be put on the layout
queue. Btw the "parent object of an object of type InputArea is a Layout
object" comm
And since InputArea and Layout are the only classes derived directly
from Area, and they would both have the same code in their destructors
with the patch in #6, the removal code can be moved to the Area
destructor, as in the attached patch.
** Patch added: "nux-remove-area-from-layout-queue.patch
However, if the "parent object of an object of type InputArea is a
Layout object" comment at Area.cpp:603 is inaccurate (as some of the
other comments there, such as the ones at :540, :576, and :596), and if
InputArea objects can have HSplitter or VSplitter as parent, then they
could be added to th
Actually, since View is FloatingWindow's indirect base class, and since
InputArea (which is the only other class derived from Area besides
Layout) is a direct base class of View, and InputArea objects are not
put on that queue, the RemoveObjectFromLayoutQueue calls in View and
Layout destructors do
** Patch removed: "nux-remove-area-from-layout-queue.patch"
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1337244/+attachment/4164791/+files/nux-remove-area-from-layout-queue.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
It seems like FloatingWindow is being added to the queue with
QueueObjectLayout in FloatingWindow.cpp, but might not be removed from
the queue before it's deleted. Its ancestor Area has the same potential
issue, as well. So, moving the RemoveObjectFromLayoutQueue call in View
and Layout destructors
Apparently, OS X does have the ability to do a right-click by two-
finger-clicking feature (enabled together with two-finger-tapping).
Doing the same will require some state tracking. Something to look into
next. Still, the patch should improve the current experience as long as
two-finger tapping i
** Attachment added: "Synaptics bcm5974 policy"
http://launchpadlibrarian.net/24852563/x11-synaptics-bcm5974.fdi
--
[Jaunty] MacBook 5.1 touchpad not fully supported (Alpha 5 of Jaunty)
https://bugs.launchpad.net/bugs/337935
You received this bug notification because you are a member of Ubunt
Here is a patch for bcm5974-dkms to make click-and-drag work with
Macbook 5,1. When clicking with two fingers touching the trackpad, it
simply ignores the finger that is doing the clicking (the one that is
relatively lower on the touchpad), just like OS X does. It does *not*
disable the bottom part
** Attachment added: "deb package for testing"
http://launchpadlibrarian.net/24852553/bcm5974-dkms_1.1.4_all_test.deb
--
[Jaunty] MacBook 5.1 touchpad not fully supported (Alpha 5 of Jaunty)
https://bugs.launchpad.net/bugs/337935
You received this bug notification because you are a member of
I should probably add that I occasionally (once a month or so) get a
similar resume failure on OS X Leopard, too (doing several suspends per
day).
--
[Apple Inc. MacBookPro5,1] suspend/resume failure [non-free: nvidia]
https://bugs.launchpad.net/bugs/353129
You received this bug notification beca
** Attachment added: "BootDmesg.txt"
http://launchpadlibrarian.net/24630451/BootDmesg.txt
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/24630452/Dependencies.txt
** Attachment added: "HalComputerInfo.txt"
http://launchpadlibrarian.net/24630453/HalComputerInfo.txt
Public bug reported:
During the Jaunty beta suspend test (
https://wiki.ubuntu.com/KernelTeam/SuspendResumeTesting ), the laptop
didn't resume completely at the "delay 58" test. It just waited with a
black (but lit) screen, ignoring keyboard/mouse events.
ProblemType: KernelOops
Annotation: This
13 matches
Mail list logo
