1. 09 Aug, 2019 1 commit
  2. 17 Nov, 2018 3 commits
  3. 23 Sep, 2015 1 commit
  4. 10 Apr, 2014 1 commit
  5. 14 Nov, 2013 1 commit
  6. 23 Aug, 2013 1 commit
  7. 18 May, 2013 1 commit
  8. 19 Feb, 2013 1 commit
  9. 01 Dec, 2012 1 commit
  10. 26 Jan, 2012 1 commit
  11. 13 Oct, 2011 1 commit
  12. 08 Sep, 2011 1 commit
  13. 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.
  14. 09 Aug, 2011 1 commit
  15. 07 Mar, 2011 1 commit
  16. 24 Jan, 2011 1 commit
  17. 18 Jun, 2010 1 commit
    • Milan Bouchet-Valat's avatar
      Migrate to GSettings · 2799327c
      Milan Bouchet-Valat authored
      Use GSettings for all Shell configuration. GConf is kept to read
      configuration from external programs (Metacity, Nautilus and Magnifier),
      but ShellGConf is removed because it's mostly useless for the few calls
      we still have. Also get rid of unused GConf code in ShellAppSystem.
      A basic GConf schema is still used to override Metacity defaults and
      configure Magnifier in a system-wide fashion. GConf is also used as
      GSettings backend via the GSETTINGS_BACKEND environment variable.
      All of this will be removed when these programs have been ported
      to GSettings and able to use dconf.
      GLib 2.25.9 is required. Schemas are converted to the new XML format,
      and compiled at build time in data/ so that the Shell can be run from
      the source tree. This also requires setting the GSETTINGS_SCHEMA_DIR
      environment variable both when running installed or from source tree,
      in src/gnome-shell.in and src/gnome-shell-clock-preferences.in.
  18. 09 Jun, 2010 1 commit
    • Colin Walters's avatar
      Fix ShellAppSystem's use of no_focus_window, clean up state handling · e4a6bf99
      Colin Walters authored
      First, we were passing an incorrect timestamp to
      meta_display_focus_the_no_focus_window - fix that.
      The invocation of set_focus_app to the started app there couldn't
      really work, because (if the above call had worked) we'd get the
      X reply *after* the started app.
      What we need to untangle here is the distinction that's now made in
      ShellApp between _STATE_STARTING and _STATE_RUNNING.  A nice way to
      start doing this is to rebase ShellWindowTracker to only be concerned
      with app states.  Concretely, the current "has windows implies
      running" logic now lives just inside shell-app.c.
      Rename the app-running-changed signal to be app-state-changed.  This
      will ultimately be useful so that inside the panel, we can track
      the last started app.
  19. 05 May, 2010 1 commit
  20. 06 Jan, 2010 1 commit
    • Colin Walters's avatar
      [ShellAppUsage] Fix use-after-free · 98a8dd68
      Colin Walters authored
      We were holding on to UsageData structure pointers in previously_running,
      but those can be purged by the unused app cleanup.  Instead just hold
      onto dup'd copies of the application id strings.
  21. 24 Nov, 2009 2 commits
  22. 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
      Port all of the JavaScript for these changes.