Per design discussion, change things back so that when choosing
an individual window, we raise only that window. However
when we select an application, raise all windows.
A behavioral change required to clearly differentiate these
is that when the window thumbnail list is popped up, it no
longer has the first window selected by default. Therefore
the user has to explicitly press the down arrow or use the
mouse to enter individual window selection mode.
https://bugzilla.gnome.org/show_bug.cgi?id=617959
The ShellGlobal initialization performs several actions like connecting
to the X server, ensuring directories exist, etc., that are problematic
because we were creating the object even when running the binary for
introspection scanning. During compilation we may not even have X11
available in e.g. autobuilder type environments, and it's just a
bad idea to connect even if we do.
Avoid this by deferring creation of the ShellGlobal object
until the plugin is actually started.
Now that we're initializing things later, remove the connection to
screen changes, and initialize cached ShellGlobal state at the point
when the plugin is set. The root pixmap actor is now sized initially
on creation too. Instead of relying on screen-size-changed being
emitted on startup, explicitly invoke _relayout().
https://bugzilla.gnome.org/show_bug.cgi?id=618371
Fetch the names of the user's "subscribed" contacts, and use the
SimplePresence interface to watch for available/away/busy/etc messages
and create notifications for them.
Currently we display notifications when switching between "available"
and "offline"/"extended away", but when switching between "available"
and "away"/"busy" we just add the information to the chat window
without popping up a notification, to avoid spamming the user with
"Bob's screensaver activated" messages.
https://bugzilla.gnome.org/show_bug.cgi?id=611613
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
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
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
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
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".
When a dropped window is accepted by a workspace in linear view, it
is moved to the new workspace. After that, the view zooms back in on
the original workspace, resulting in the moved window disappearing
from the user's sight.
Change this rather unexpected behavior, so that a successful drop
triggers a switch to the new workspace. This also improves consistency
with drops on the (+) area.
https://bugzilla.gnome.org/show_bug.cgi?id=617785
Centralize the update of actor visibilities (overlays, shadows,
off-screen workspaces). Adjust the way scrolling is handled so
that it works correctly with removed workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=610191
Activate empathy when clicking on a chat icon by asking the
ChannelDispatcher to open the conversation in the default handler.
Also, remove the Approver and Handler for now, since until
telepathy-logger is stable, this means Empathy won't see (and log)
those conversations. This means that empathy's blinky status icon is
back; we'll have to do something else about that.
https://bugzilla.gnome.org/show_bug.cgi?id=611610
While the extension system already uses an XDG location (XDG_CONFIG_HOME),
other components use the deprecated $HOME/.gnome2 directory.
Replace both with XDG_DATA_HOME - the existing data (app usage stats,
looking glass history and extensions) is not migrated to the new location.
https://bugzilla.gnome.org/show_bug.cgi?id=617555
Previously we used a ClutterGroup containing a second ClutterGroup for
the non-visibleInOverview actors. Redo it using a single
ShellGenericContainer, and use set_skip_paint() to hide the
non-overview chrome when the overview is visible.
Also fix up the default values for trackActor().
https://bugzilla.gnome.org/show_bug.cgi?id=608667
If a notification is about to hide, but the user has moved the mouse
towards it, let it stick around for another second (and so on, until
the mouse either reaches the tray and causes it to be pinned, or stops
moving the mouse toward it).
https://bugzilla.gnome.org/show_bug.cgi?id=610071
Figure out if the banner is too long to fit as soon as the
notification's style is set, rather than waiting until allocation
time, since it's bad to add new table rows during allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=611612
Cache avatars to avoid having to re-download them every session.
We use a cache format that is compatible with empathy's, but we don't
actually use empathy's. This could be changed if we wanted.
https://bugzilla.gnome.org/show_bug.cgi?id=614974
This change doesn't actually affect anything visibly, but
using the absolute coordinates of our allocation box in allocate()
is wrong; we should be positioning our children at 0,0 and using
width/height as a reference.
https://bugzilla.gnome.org/show_bug.cgi?id=616951
