Mostly a straightforward porting of style code to CSS, except
that various bits of other code referenced a few GenericDisplay
constants, so those needed to be ported as well.
Add some padding at the top between the close button and the items.
Center the text and description.
https://bugzilla.gnome.org/show_bug.cgi?id=600734
In a variety of places we're using boxes as data-modeling displays,
and in doing so we often want to either remove the children or
explictly destroy them.
Now ideally Gjs would support callbacks, and this would make using
the for_each functions possible, but even then these functions
are more efficient and shorter to type, at least.
https://bugzilla.gnome.org/show_bug.cgi?id=600734
This should not be required, since glib correctly deals with such
applications by giving them the local gvfs path, and those
applications which do support URIs keep being able to use the URIs in
GFiles.
Based on original work by Guido Günther <agx@sigxcpu.org>.
https://bugzilla.gnome.org/show_bug.cgi?id=601287
It's very convenient to drill down through object properties and
be able to see exactly which portion of the screen those actors
correspond to, without trying to guess with the inspector tool.
Commit 94bd6f1718 introduced a trick
where we only do the heavy lifting for "redisplay" when we're mapped.
However, the search system wants to get the count of matched items,
and control the visibility of the display based on that. This introduces
a circularity; avoid it by forcing the search to do a redisplay.
In the future we should avoid this by separating out the "get matched
things for search" from "display list of things".
https://bugzilla.gnome.org/show_bug.cgi?id=600890
Places is one of the dash sections and it should be included in search results.
Factor out the code for getting and updating the information about places from
Places to PlacesManager.
Introduce PlaceInfo class that contains information about the place and can be
used by classes that display it in different ways. Rename classes so that their
names are consistent with corresponding classes in appDisplay.js and
docDisplay.js
https://bugzilla.gnome.org/show_bug.cgi?id=599125
If the space we're allocated is too small for our border + padding
constraints, don't give negative allocations to callers. Squash
to zero.
It isn't really useful for callers to get negative content sizes,
and certainly breaks most allocation code.
https://bugzilla.gnome.org/show_bug.cgi?id=600734
StTheme CSS supports different border widths for different sides. Implement
it for StWidget by drawing the border internally. However, we don't support
a nonzero corner-radius with nonuniform borders.
https://bugzilla.gnome.org/show_bug.cgi?id=599442
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
