This make it is easier for the user to figure out on which workspace the
windows are. For instance, terminals related to various activities and put on
different workspaces were previously displayed as an uniform list, with no
visible distinction between the ones from the current workspace and the others.
Now they are physically separated by a thin gray line.
This is also consistent with the way applications are displayed in the
AppSwitcher.
https://bugzilla.gnome.org/show_bug.cgi?id=597944
If we're not mapped, only queue up a redisplay. This avoids
e.g. changes in recent documents such as saving a file in GEdit
causing a lot of blocking I/O in the shell (we need to make
recent loading async as well).
https://bugzilla.gnome.org/show_bug.cgi?id=599560
Previously shell_app_remove_window assumed that it was being
passed a window in its list; rather than having callers check
whether a window is interesting and only if so removing it
from the app, just ignore removal of windows we aren't interested
in, like how we ignore addition of windows we already have.
https://bugzilla.gnome.org/show_bug.cgi?id=598502
First, fix a problem where though we intended to request a minimum
height of 0 for the docs content, we were actually requesting
spacing for all items.
On low resolution screens, we were still attempting to allocate
an item even when we were given 0 height.
https://bugzilla.gnome.org/show_bug.cgi?id=596984
The behavior in respect to borders matches CSS - the properties set the size of
the content exclusive of the borders (CSS3 box-sizing property - not implemented
here - changes this).
min-width/min-height correspond very closely to the CSS meanings.
width/height are a little different from the CSS meanings - the CSS meaning is
"exactly this size unless overridden by min/max-width/height" - but within the
realm of our layout algorithm, making them control natural size is pretty
close.
This way we can force elements to have a fixed natural or minimum size.
https://bugzilla.gnome.org/show_bug.cgi?id=598651
For the purposes of determining which application is focused, don't
skip "uninteresting" windows. The old get_focused_window code
was used for usage tracking, but here we want reliable application
association.
Also convert a .text= to .set_text that was missed with the last
patch.
https://bugzilla.gnome.org/show_bug.cgi?id=599206
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
The window lists were not being resorted when user-time changed, and
the app list was mistakenly "penalizing" apps for having *any*
minimized windows, rather than for having *only* minimized windows.
https://bugzilla.gnome.org/show_bug.cgi?id=598389
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
If we had a pending search processing, finish it when the user
activates the entry.
This is a small conceptual change; the large diff is simply
moving the search implementation (unedited otherwise) from
an anonymous inline to a named function so it can be called
sanely in _activate.
https://bugzilla.gnome.org/show_bug.cgi?id=598111
