1. 21 Oct, 2021 1 commit
  2. 16 Oct, 2021 1 commit
  3. 14 Oct, 2021 6 commits
    • Ray Strode's avatar
      sessionMode: Drop allowExtensions property · d7b12648
      Ray Strode authored and Marge Bot's avatar Marge Bot committed
      Now that we allow extensions at the lock screens, extensions
      are allowed for every session mode gnome-shell would typically
      change to at runtime.
      
      This means there's little advantage to having an allowExtensions
      property in the session mode definition.
      
      This commit simplifies the code a bit by dropping the property.
      
      Third party session modes can still lock down extensions through
      gsettings if they need to.
      
      Part-of: <!1967>
      d7b12648
    • Ray Strode's avatar
      sessionMode: Allow extensions at the login and unlock screens · 2bf31dc4
      Ray Strode authored and Marge Bot's avatar Marge Bot committed
      Now extensions can specify which session modes they work in,
      but specifying the login screen or unlock screen session modes in
      an extensions metadata still won't work, because those session
      modes disallow extensions.
      
      This commit fixes that.
      
      Part-of: <!1967>
      2bf31dc4
    • Ray Strode's avatar
      extensionSystem: Allow extensions to run on the login screen · 242cff7a
      Ray Strode authored and Marge Bot's avatar Marge Bot committed
      At the moment it's not realy possible to extend the login screen to do
      things it doesn't have built-in support for. This means in order
      to support niche use cases, those cases have to change the main
      code base. For instance, oVirt and Vmware deployments want to be able
      to automaticaly log in guest VMs when a user pre-authenticates through a
      console on a management host. To support those use cases, we added
      code to the login screen directly, even though most machines will never
      be associated with oVirt or Vmware management hosts.
      
      We also get requests from e.g. government users that need certain features
      at the login screen that wouldn't get used much outside of government
      deployments. For instance, we've gotten requests that a machine contains
      prominently displays that it has "Top Secret" information.
      
      All of these use cases seem like they would better handled via
      extensions that could be installed in the specific deployments. The
      problem is extensions only run in the user session, and get
      disabled at the login screen automatically.
      
      This commit changes that. Now extensions can specify in their metadata
      via a new sessionModes property, which modes that want to run in. For
      backward compatibility, if an extension doesn't specify which session
      modes it works in, its assumed the extension only works in the user
      session.
      
      Part-of: <!1967>
      242cff7a
    • Ray Strode's avatar
      extensionSystem: Get rid of _enabled boolean optimization · 7e5ee2c2
      Ray Strode authored and Marge Bot's avatar Marge Bot committed
      At the moment a session mode either allows extensions or it doesn't.
      If it allows extensions, then the entire available list of
      configured extensions get enabled as soon as the session mode is
      entered.
      
      Since enabling or disabling extensions is an all or nothing situation,
      the code tracks whether extensions are already enabled when entering
      the session mode, and if so, avoids iterating through the extension list
      needlessly. It does this using a boolean named _enabled.
      
      In the future, the extensions themselves will be given some say on
      whether or not they should be enabled in a given session mode. This
      means, the configured extension list may contain extensions that
      shouldn't be enabled for a given session mode, and the _enabled boolean
      will no longer be appropriated.
      
      This commit drops the _enabled boolean optimization.
      
      Part-of: <!1967>
      7e5ee2c2
    • Florian Müllner's avatar
      Post-branch mutter API bump · 7bde02c1
      Florian Müllner authored
      Since the CI pipeline now runs `meson dist` which includes a test
      for an up-to-date NEWS entry, post-branch/release version bumps
      have become unwieldy.
      
      It's still useful to increase the API version right after branching
      though, so return to bumping it manually and do so now.
      
      Part-of: <!2005>
      7bde02c1
    • Florian Müllner's avatar
      theme: Fix high-contrast switches · 2dcbf5f3
      Florian Müllner authored and Marge Bot's avatar Marge Bot committed
      Commit 9d6fcfdc dropped the different us/intl switches, but
      the high-contrast theme was left out at the time (and therefore
      ends up with the regular assets now).
      
      #4672
      
      Part-of: <!2000>
      2dcbf5f3
  4. 12 Oct, 2021 1 commit
  5. 10 Oct, 2021 1 commit
  6. 08 Oct, 2021 3 commits
    • Carlos Garnacho's avatar
      ci: Install mutter again on coverity job · 4e5ddc54
      Carlos Garnacho authored and Marge Bot's avatar Marge Bot committed
      This job "needs" the build job and thus gets its artifacts, but
      it will not inherit the environment where we already installed
      Mutter in /usr. This apparently broke once there was a more
      recent mutter-clutter .pc file to look up.
      
      Install Mutter in /usr again in this job, so the new build for
      coverity finds all dependencies.
      
      Part-of: <!1979>
      4e5ddc54
    • Ray Strode's avatar
      unlockDialog: Properly reset auth prompt when showing it · ceee53aa
      Ray Strode authored
      If a user hits escape twice really fast when coming back to
      their machine to unlock it, they made end up getting presented
      with a non-functional unlock screen that doesn't show their
      user icon and doesn't ask for a password.
      
      This is because showPrompt assumes that if an auth prompt already
      exists, it's ready to go. That may not be true, if it's in the
      process of getting torn down at the time because it's in the middle
      of a cancel animation.
      
      This commit solves the problem by ensuring the auth prompt is always
      in a fresh reset state before showing it.
      
      Part-of: <!1999>
      ceee53aa
    • Ray Strode's avatar
      unlockDialog: Don't create AuthDialog just to finish it · 5d5bfe49
      Ray Strode authored
      If the the unlock dialog gets finished before an auth dialog is
      created, the code currently creates one just to tell it to finish.
      
      This commit changes the code to skip creating the auth dialog in
      that case.
      
      Part-of: <!1999>
      5d5bfe49
  7. 06 Oct, 2021 4 commits
  8. 05 Oct, 2021 1 commit
  9. 30 Sep, 2021 3 commits
  10. 27 Sep, 2021 1 commit
  11. 26 Sep, 2021 2 commits
  12. 21 Sep, 2021 1 commit
    • Jonas Ådahl's avatar
      Always assume GLSL is supported · 563437de
      Jonas Ådahl authored
      The support for GLSL has been advertised as unconditionally supported by
      mutter for a while, and has now lost the 'GLSL' feature completely. Lets
      remove the checks.
      
      Part-of: <!1985>
      563437de
  13. 20 Sep, 2021 1 commit
  14. 19 Sep, 2021 1 commit
  15. 17 Sep, 2021 1 commit
  16. 16 Sep, 2021 2 commits
  17. 15 Sep, 2021 1 commit
  18. 14 Sep, 2021 1 commit
  19. 13 Sep, 2021 2 commits
  20. 11 Sep, 2021 1 commit
  21. 10 Sep, 2021 1 commit
  22. 09 Sep, 2021 1 commit
  23. 07 Sep, 2021 3 commits