1. 18 Sep, 2018 2 commits
    • Adam Williamson's avatar
      Fix connection to wifi APs from user menu (RH #1628263) · 33ffdd60
      Adam Williamson authored
      In recent Fedora 29, connecting to wifi access points from the
      user menu (top-right menu) does not work. Clicking the 'Connect'
      button just animates it but does nothing else. The logs show an
      error "JS ERROR: Error: Expected type utf8 for Argument
      'specific_object' but got type 'undefined'".
      
      Looking into this, it seems the problem is these uses of the
      `path` property of an NMAccessPoint. NMAccessPoint inherits
      from NMObject, and NMObject *does* have a path property:
      
      https://developer.gnome.org/libnm/stable/NMObject.html#NMObject--path
      
      so at first glance this seems fine. But I poked around a bit
      using libnm via Python (which goes via introspection, just like
      this JS code does), and found that indeed AccessPoint objects
      don't seem to have a `path` property there either.
      
      Looking at the libnm code, this actually makes sense, because
      the property is marked "(skip)":
      
      https://github.com/NetworkManager/NetworkManager/blob/master/libnm/nm-object.c#L1291
      
      and the introspection docs suggest that means it should be left
      out of introspected output:
      
      https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations#Symbol_visibility
      
      I'm a bit concerned that this was only found recently - whereas
      the change to use `.path` in gnome-shell dates from October 2017
      (d71af5e5) and the property has been marked (skip) in NM since
      at least 2016 - but this all seems to add up. The obvious fix is
      to replace use of `.path` with `.get_path()`, which returns the
      path and is *not* marked (skip) and so *is* available via
      introspection. I tested that this works in Python and also did
      a test build of gnome-shell with this change and installed it on
      an affected system, it does seem to fix the bug.
      Signed-off-by: 's avatarAdam Williamson <awilliam@redhat.com>
      33ffdd60
    • Khaled Hosny's avatar
      Update Arabic translation · 34fd6819
      Khaled Hosny authored
      34fd6819
  2. 17 Sep, 2018 7 commits
  3. 16 Sep, 2018 1 commit
  4. 14 Sep, 2018 1 commit
  5. 13 Sep, 2018 3 commits
    • Daniel Drake's avatar
      switchMonitor: switch to next config upon initial keypress · fcdac69e
      Daniel Drake authored
      In GNOME-3.24, pressing Super+P or a similar function key would cause
      a switch to the next available monitor configuration.
      
      However, in GNOME-3.26, this was reimplemented in mutter and gnome-shell
      and the behaviour is now different: pressing Super+P and releasing will
      cause no change in montor configuration[1]. In this new design you have
      to press Super+P and keep holding Super in order to keep the switcher
      open, then press P again (or use the arrow keys or mouse) to
      select the next one in the list.
      
      This is incompatible with many Asus products such as Asus X530UN, where
      pressing the presentation mode media key (Fn+F8) actually generates
      the following keypress events from the keyboard controller:
      
      Fn pressed: nothing
      F8 pressed: nothing
      F8 released: Super press, p press, p release, Super release (quick burst)
      Fn released: nothing
      
      With this firmware behaviour it's not possible to hold the keys and have
      the dialog come up so that you can select another new mode.
      
      To solve this, when the switcher is opened, select the next available
      display config by default, which is more similar to the pre-GNOME-3.26
      behaviour. Now pressing Fn+F8 on this laptop will result in the display
      mode switch taking place.
      
      [1]: The mentioned desired behaviour will at least happen after
      mutter#281 has been fixed
      
      !208
      fcdac69e
    • Florian Müllner's avatar
      workspaceTracker: Don't keep multiple trailing workspaces · 9d6e1a89
      Florian Müllner authored
      Since we always keep the active workspace until the user switches
      to a different one, we may end up with two empty workspaces at
      the end. It's not obvious to users why this happens, and there's
      indeed no good reason for the behavior - just remove the trailing
      workspace in that case.
      
      #536
      9d6e1a89
    • Florian Müllner's avatar
      app: Close all closable windows from quit() · 87a645aa
      Florian Müllner authored
      There's no relation between a window being hidden from overview/taskbars
      and a window not being closable - currently we effectively disable the
      fallback quit action for any application with open transients, which
      simply doesn't make sense.
      
      Instead, only exclude windows for which the close action has been
      explicitly disabled.
      
      !217
      87a645aa
  6. 11 Sep, 2018 2 commits
  7. 08 Sep, 2018 1 commit
  8. 06 Sep, 2018 1 commit
  9. 05 Sep, 2018 2 commits
  10. 03 Sep, 2018 16 commits
  11. 02 Sep, 2018 2 commits
  12. 01 Sep, 2018 2 commits