touch-packages team mailing list archive

[Launchpad Bug Tracker <1111216@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package nux - 4.0.8+15.10.20150921.1-0ubuntu1

---------------
nux (4.0.8+15.10.20150921.1-0ubuntu1) wily; urgency=medium

  [ Stephen M. Webb ]
  * new upstream release 4.0.8
  * debian/control (Standards-Version): bump to 3.9.6 (no changes)

  [ Marco Trevisan (Treviño) ]
  * debian/control:
    - add xserver-xorg-video-dummy as build dependency
    - set libnux-4.0-common arch to all
    - depend on source:Version of libnux-4.0-common

  [ Andrea Azzarone andrea.azzarone@xxxxxxxxxxxxx ]
  * Remove alternative select mainloop. (LP: #1111216)

  [ Marco Trevisan (Treviño) ]
  * WindowCompositor: emit mouse_leave signal when releasing mouse over
    a new area (LP: #1496140)

 -- Marco Trevisan (Treviño) <mail@xxxxxxxxx>  Mon, 21 Sep 2015 17:41:54
+0000

** Changed in: nux (Ubuntu)
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nux in Ubuntu.
https://bugs.launchpad.net/bugs/1111216

Title:
  Drop support for running without GLib event loop

Status in Nux:
  In Progress
Status in nux package in Ubuntu:
  Fix Released

Bug description:
  Nux has support in conditional compilation for running without the
  GLib event loop.

  This bug is about getting support for that dropped. Considering that
  the GLib event loop is supported on all platforms that Nux supports,
  there isn't much of a reason for running without it.

  The main reasons it should be removed are :
  1. Its not used by anybody
  2. Maintenance burden - every time you want to use some new event source, you have to provide support on both
  3. Its completely broken from a code inspection POV:

   -> It uses while (true) and busy-waits for new events (most of the time)
   -> Sometimes the event retrieval sources block, sometimes they don't.
   -> The check-for-events and dispatch-event code is in the same function for every source, which means that if one source blocks (eg XLib), and the other has pending events (Geis) then there's a potential deadlock until the first one unblocks
   -> There's support for both Geis and XLib in the non-glib event loop, except that the Geis portion depends on compiling with GLib in order to actually retrieve events, rendering it non-functional in this mode.

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