1. 21 Oct, 2016 1 commit
  2. 15 Oct, 2015 1 commit
    • Florian Müllner's avatar
      shell: Use G_DECLARE_*_TYPE macros · 294702d3
      Florian Müllner authored
      Cut down on boilerplate by using the (no longer that) new helper
      macros. We don't care about breaking ABI in private libraries, so
      use G_DECLARE_FINAL_TYPE even where the class struct used to be
      exposed in the header, except for types we inherit from ourselves
      (obviously) or where the class exposes any vfuncs (where changes
      could affect inheritance in extensions).
      294702d3
  3. 20 Feb, 2015 1 commit
  4. 27 Nov, 2014 1 commit
  5. 01 Aug, 2014 1 commit
  6. 19 Jan, 2014 1 commit
  7. 03 Nov, 2013 2 commits
  8. 21 Oct, 2013 1 commit
  9. 22 Jul, 2013 1 commit
  10. 19 Apr, 2013 1 commit
  11. 19 Jun, 2012 1 commit
  12. 18 Jan, 2012 1 commit
  13. 20 Dec, 2011 2 commits
    • Matthias Clasen's avatar
      Add per-window actions · 6c4e9d23
      Matthias Clasen authored
      GTK+ also exports window-specific actions, by putting the object path
      for the exported action group in the _DBUS_OBJECT_PATH X property.
      We add this action group to the app's muxer with a 'win' prefix,
      since that is what the exported menu expects. Whenever the focus
      window changes, we update the window-specific actions of its
      application, and emit notify::action-group to cause the app
      menu to be updated.
      6c4e9d23
    • Giovanni Campagna's avatar
      ShellApp: port to new GDBusActionGroup and GMenuProxy API · 87642538
      Giovanni Campagna authored
      GDBusActionGroup and GMenuProxy are new objects in GIO 2.32 that
      help with accessing menus and actions of remote applications.
      This patch makes it possible for the shell to associate an
      application with a dbus name and from that a GMenu, that will
      be shown as the application menu.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=621203
      87642538
  14. 11 Aug, 2011 2 commits
  15. 10 Aug, 2011 1 commit
    • Colin Walters's avatar
      Kill off ShellAppInfo, move into ShellApp · 10dcc100
      Colin Walters authored
      This dramatically thins down and sanitizes the application code.
      
      The ShellAppSystem changes in a number of ways:
      * Preferences are special cased more explicitly; they aren't apps,
        they're shortcuts for an app), and we don't have many of them, so
        don't need e.g. the optimizations in ShellAppSystem for searching.
      * get_app() changes to lookup_app() and returns null if an app isn't
        found.  The semantics where it tried to find the .desktop file
        if we didn't know about it were just broken; I am pretty sure no
        caller needs this, and if they do we'll fix them.
      * ShellAppSystem maintains two indexes on apps (by desktop file id
        and by GMenuTreeEntry), but is no longer in the business of
        dealing with GMenuTree as far as hierarchy and categories go.  That
        is moved up into js/ui/appDisplay.js.  Actually, it flattens both
        apps and settings.
      
      Also, ShellWindowTracker is now the sole reference-owner for
      window-backed apps.  We still do the weird "window:0x1234beef" id
      for these apps, but a reference is not stored in ShellAppSystem.
      
      The js/ui/appDisplay.js code is rewritten, and sucks a lot less.
      Variable names are clearer:
      
      _apps -> _appIcons
      _filterApp -> _visibleApps
      _filters -> _categoryBox
      
      Similarly for function names.  We no longer call (for every app) a
      recursive lookup in GMenuTree to see if it's in a particular section
      on every category switch; it's all cached.
      
      NOTE - this intentionally reverts the incremental loading code from
      commit 7813c5b9.  It's fast enough
      here without that.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=648149
      10dcc100
  16. 07 Mar, 2011 1 commit
  17. 09 Feb, 2011 1 commit
    • Owen W. Taylor's avatar
      Don't switch to a workspace when dragging it to launch on that workspace · 0d32017f
      Owen W. Taylor authored
      With workspace thumbnails, we don't switch workspaces when dragging windows
      between workspaces or adding new workspaces, so we also shouldn't switch
      on launch.
      
       * Add workspace parameters to shell_doc_system_open(),
         shell_app_activate, shell_app_open_new_window()
      
       * Pass a 'params' object when activating items in the overview with
         two currently defined parameters: workspace and timestamp. (timestamp
         is only implemented where it is easy and doesn't require interface
         changes - using the global current timestamp for the shell is almost
         always right or at least good enough.)
      
      https://bugzilla.gnome.org/show_bug.cgi?id=640996
      0d32017f
  18. 09 Jun, 2010 1 commit
  19. 11 May, 2010 1 commit
  20. 06 May, 2010 1 commit
  21. 12 Apr, 2010 1 commit
    • Colin Walters's avatar
      Major ShellApp API cleanup, startup notification, window focus handling · 6aaf4b87
      Colin Walters authored
      This patch combines several high level changes which are conceptually
      independent but in practice rather intertwined.
      
      * Add a "state" property to ShellApp which reflects whether it's
        stopped, starting, or started.  This will allow us to later clean
        up all the callers that are using ".get_windows().length > 0" as
        a proxy for this property
      * Replace shell_app_launch with shell_app_activate and shell_app_open_new_window
        A lot of code was calling .launch, but it's signficantly clearer
        if we call this ".open_new_window()", and later if we gain the ability
        to call into an application's menu, we can implement this correctly rather
        than trying to update all .launch callers.
      * Because ShellApp now has a "starting" state, rebase panel.js on top of
        this so that when we get a startup-notification sequence for an app
        and transition it to starting, it becomes the focus app, and panel.js
        cleanly just tracks the focus app, rather than bouncing between SN
        sequences.  This removes display of non-app startup sequences, which
        I consider an acceptable action in light of the committed changes
        to startup-notification and GTK+.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=614755
      6aaf4b87
  22. 13 Mar, 2010 1 commit
    • Colin Walters's avatar
      Fix app icon fading · 3aea09b6
      Colin Walters authored
      The way we were loading data into a CoglTexture, then pulling it out
      and manipulating it on the CPU, then loading it back into a texture
      was a bit lame.
      
      Clean things up a bit here by loading directly into the CPU, doing
      the fading, then creating a texture.
      
      Also cache the faded data in StTextureCache.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=612759
      3aea09b6
  23. 20 Oct, 2009 1 commit
    • Colin Walters's avatar
      Split ShellAppMonitor into ShellWindowTracker, ShellAppUsage · e941e808
      Colin Walters authored
      The two parts were mapping windows to applications, and
      recording application usage statistics.  The latter part
      (now called ShellAppUsage) is much more naturally built on top of
      the former (now called ShellWindowTracker).
      
      ShellWindowTracker retains the startup-notification handling.
      
      ShellWindowTracker also gains a focus-app property, which is
      what most things in the shell UI are interested in (instead of
      window focus).
      
      ShellAppSystem moves to exporting ShellApp from more of its
      public API, rather than ShellAppInfo.  ShellAppSystem also
      ensures that ShellApp instances are unique by holding
      a hash on the ids.
      
      ShellApp's private API is split off into a shell-app-private.h,
      so shell-app.h can be included in shell-app-system.h.
      
      Favorites handling is removed from ShellAppSystem, now inside
      appFavorites.js.
      
      Port all of the JavaScript for these changes.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=598646
      e941e808
  24. 15 Oct, 2009 1 commit
  25. 14 Oct, 2009 1 commit
    • Colin Walters's avatar
      Create ShellApp, rebase things on it · 38c06ca8
      Colin Walters authored
      Previously, we had ShellAppInfo, which contains fundamental
      information about an application, and methods on ShellAppMonitor
      to retrieve "live" information like the window list.
      
      AppIcon ended up being used as the "App" class which was painful
      for various reasons; among them that we need to handle window
      list changes, and some consumers weren't ready for that.
      
      Clean things up a bit by introducing a new ShellApp class in C,
      which currently wraps a ShellAppInfo.
      
      AppIcon then is more like the display actor for a ShellApp.  Notably,
      the ".windows" property moves out of it.  The altTab code which
      won't handle dynamic changes instead is changed to maintain a
      cached version.
      
      ShellAppMonitor gains some more methods related to ShellApp now.
      
      In the future, we might consider changing ShellApp to be a GInterface,
      which could be implemented by ShellDesktopFileApp, ShellWindowApp.
      
      Then we could axe ShellAppInfo from the "public" API and it would
      return to being an internal loss mitigation layer for GMenu.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=598227
      38c06ca8