This is our convention.
The only exceptions are double quotes for words in comments that give
them a special meaning (though beware that these quotes are not truly
necessary most of the time) and double quotes that need to be a part
of the output string.
It was previously possible to add a workspace above the maximum workspaces
limit by dragging an item to the "add workspace" button or using the middle
mouse button click.
Provide the user with feedback in the info bar when it is not possible to create
a new workspace or remove the current workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=591645
This ensures that we launch the new instance of an application on the newly
added workspace in the grid view, in which we don't make the newly added
workspace active by default.
https://bugzilla.gnome.org/show_bug.cgi?id=591645
I have no idea why there existed code that if we saw e.g. min-width
without a width, we assigned min-width to ->width, thus effectively
treating it as a maximum.
Just delete that bit.
https://bugzilla.gnome.org/show_bug.cgi?id=618482
Allow using the middle mouse button to open a new instance of an
application on a new workspace. The middle mouse button function
can be achieved by clicking the left and right mouse buttons
together with a two buttons mouse or holding Ctrl while clicking
with a single button mouse.
https://bugzilla.gnome.org/show_bug.cgi?id=591645
Starting with gtk-2.20.0 there is a gdk_screen_get_primary_monitor,
which supports querying the primary monitor from xrandr.
But due to a sorting bug and lack of heuristics in the fallback path,
it isn't really useable.
Those bugs are fixed in gtk-2.20.1, so use it when building with
gtk-2.20.1+.
https://bugzilla.gnome.org/show_bug.cgi?id=608647
Passing an explicit width in the wfh case or a height in the hfw case
messes up the request caching, and confuses actors that assume they
won't be called with an explicit width/height unless they're being
allocated along the other axis.
https://bugzilla.gnome.org/show_bug.cgi?id=618295
Adds the ability to create one or more zoom regions that show magnified or
enhanced views of the desktop. The magnifier provides options for:
* magnification factor,
* four mouse tracking modes common to screen magnifiers,
* positioning the magnified view in one of four screen location, or full screen,
* crosshairs to accentuate the position of the mouse,
* user preferences persistence via GConf (schemas in
.../data/gnome-shell.schemas).
* a DBus API to allow other processes to drive the magnifier as a service.
https://bugzilla.gnome.org/show_bug.cgi?id=595507
Currently there is no way for the user to cancel a workspace drag action,
which means the user has to complete the drag action before and move back
to the other workspace manually afterwards.
So cancel the drag action when the user stops.
https://bugzilla.gnome.org/show_bug.cgi?id=618062
Add StContainer, which implements the ClutterContainer interface based
on the container methods in st-private and make the existing containers
subclass it.
https://bugzilla.gnome.org/show_bug.cgi?id=613907
To replace all calls to deprecated code, GTK+ 2.20 is required - add
some basic compatibility code, so that is still possible to build the
shell with GTK+ 2.18 when not using -DGSEAL_ENABLE.
https://bugzilla.gnome.org/show_bug.cgi?id=618258
With the transition to GTK+ 3.0, direct access to struct members
will no longer be possible.
This bumps the required minimum version of GTK+ to 2.20.
https://bugzilla.gnome.org/show_bug.cgi?id=618258
The StTable code only supports height-for-width. When called in
width-for-height sizing mode, instead of treating the -1 flag
value of 'for_width' as a real width, and requesting all the
children at 1 pixel wide, use the natural width of the table
as the width for determing the height.
Since we can't rewrap in width-for-height mode, we then report
the natural width also as the minimum width of the table.
https://bugzilla.gnome.org/show_bug.cgi?id=618104
Using a horizontal St.BoxLayout for calendar container forces
width-for-height layout on the St.Table child. Since St.Table
is naturally width-for-height, this can trigger bugs and is,
at best, a bit ineffecient. Use a St.Bin instead since we don't
need any BoxLayout features.
https://bugzilla.gnome.org/show_bug.cgi?id=618104
readlink() on /proc/<pid>/exe can have results like:
/usr/bin/gnome-keyring-daemon.#prelink#.5DFZsF (deleted)
/usr/bin/gnome-session (deleted)
To find gnome-session in a more robust way, read /proc/<pid>/cmdline
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=616706
A single window that does not need to be scaled down, should be centered
and not placed at the bottom.
To avoid blurryness window positions should be pixel aligned.
https://bugzilla.gnome.org/show_bug.cgi?id=617827
Some of the workspace view controls are hidden when the number of
workspaces is one (view toggle button, scroll bar in single view).
Use a fade effect instead of showing/hiding the control abruptly.
https://bugzilla.gnome.org/show_bug.cgi?id=613456
When adding/removing workspaces in linear view, both workspaces and
scrollbar movement are animated, but the size of the scrollbar handle
changes abruptly. It is more consistent to animate the size change
as well.
https://bugzilla.gnome.org/show_bug.cgi?id=613456
Add keys for customizing the panel clock to the gconf schema and make
the clock use them. The settings are copied from gnome-panel's clock
applet, excluding all location/weather/appointment/... keys. In addition,
'internet' is no longer a supported value for the format key.
https://bugzilla.gnome.org/show_bug.cgi?id=600276
In preparation for adding magnification, "uiGroup.patch", organizes the stage
along the following lines:
Stage
*Magnifier
UI group
Window group
Chrome group
Overlay group
Alt tab
App display
Chrome
...
This allows a magnifier actor to clone and magnify the UI group. The magnifier
is a sibling of the UI Group in this stage oraganization -- see the next patch,
"Magnifier.patch".
