When dragging windows in linear view, the workspace zooms out to
allow moving the window to other workspaces. Enable the same
behaviour for items dragged from the dash.
https://bugzilla.gnome.org/show_bug.cgi?id=618055
While zoomed out, the workspaces view's drop target spans the entire
monitor to implement reactive screen edges. When a drop event is not
handled by the view, an attempt is made to pass it on down the stack,
but it doesn't work properly. Fix it by iterating the target's parents
as well.
Also improve the code which translates dnd coordinates to target
positions.
https://bugzilla.gnome.org/show_bug.cgi?id=619203
Ignore the fullscreen flag when we are in the overview,
otherwise we might up not showing actors like the panel even though
they have visibleInOverview set to true.
https://bugzilla.gnome.org/show_bug.cgi?id=619693
Add events when we start preparing a frame and finish preparing
a frame. (In addition to measuring property-updating overhead, this allows
us to see the interval between finishing preparing a frame and starting
painting the frame, which is the relayout time.)
https://bugzilla.gnome.org/show_bug.cgi?id=619515
Currently, the drag and drop code assumes that on a successful drop
the target will either consume the drag actor or that it is otherwise
OK to destroy the actor.
As the drag behavior for window preview was changed, dropping a preview
on the dash now results in the preview being swallowed - to fix, add an
option to restore the actor in case of a successful drop as well.
https://bugzilla.gnome.org/show_bug.cgi?id=619203
The activities overview is not a place where we expect users to
interact with a specific application, so showing the application
menu there is misleading.
https://bugzilla.gnome.org/show_bug.cgi?id=618479
There are some places in the code where we use both fixed positioning
and CSS. Currently we use either a combination of ClutterGroup and StBin,
or we uses StBoxLayout with fixed positioning. Replace those with the new
StGroup container.
https://bugzilla.gnome.org/show_bug.cgi?id=613907
First, simply set the ellipsize flag on the application menu labels.
Next, rework how we lay out the panel components so that the center
box is always centered and constrains the left and right, rather
than pushing it around.
Previously, as part of making the shell not obviously explode if
one had a lot of tray icons, we allowed them to push the clock over.
Instead, go back to just failing in this case; we need to exile legacy
tray icons, not be slightly less ugly.
https://bugzilla.gnome.org/show_bug.cgi?id=592640
SwitcherList.actor is no longer a St.BoxLayout but a
GenericContainer now, so the hack in AppSwitcher._getPreferredHeight is no
longer needed (it is called with the correct width now).
https://bugzilla.gnome.org/show_bug.cgi?id=613194
Switch from having separate METRICS and METRIC_DESCRIPTIONS objects
in a perf module to a single METRICS array. This is done so the
perf module can define the units for each metric.
In addition to improving the output in the web interface, the purpose
of having units is to give some clue about how to pick from multiple
values from different runs. In particular, with the assumption that
"noise" on the system will increase run times, for time values we want
to pick the smallest values, while for "rate" values, we want to pick
the largest value.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
When SHELL_PERF_OUTPUT is set, instead of just dumping out the metrics, dump
a more complete report with:
- Event descriptions
- Metric descriptions and value
- Event log
Helper functions shell_perf_log_dump_events() and shell_perf_log_dump_log()
are added to ShellPerfLog to support this. The gnome-shell wrapper is adapted
to deal with the changed report format.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
Add gnome-shell options:
--perf-iters=ITERS"
Numbers of iterations of performance module to run
--perf-warmup
Run a dry run before performance tests
Make a successful run of a performance test return 0 not non-zero,
and handle the difference between that and a 0-exit in normal
usage (meaning replaced) in the wrapper.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
Add some basic statistics for allocated memory based on mallinfo(),
and use that to define two metrics:
usedAfterOverview: bytes used after the overview is shown once
leakedAfterOverview: additional bytes used when the overview is
shown a second time.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
We want to be able to summarize the behavior of the shell's
performance in a series of "metrics", like the latency between
clicking on the Activities button and seeing a response.
This patch adds the ability to create a script under perf/
in a special format that automates a series of actions in the
shell, writing events to the performance log, then collects
statistics as the log as replayed and turns them into a set
of metrics.
The script is then executed by running as gnome-shell
--perf=<script>.
The 'core' script which is added here will be the primary
performance measurement script that we use for shell performance
regression testing; right now it has a couple of placeholder
metrics.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
To support scheduling performance-measurement scripts that want to run
a number of actions in series, add shell_global_run_at_leisure() to run
a callback when all work is finished.
The initial implementation of this is not that accurate: we track
business in Tweener.js via new shell_global_begin_work(),
shell_global_end_work() functions, and we also handle the case
where the main loop is continually busy.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
We don't need to reposition the menu every time its button is
allocated; we can just stick it in the right place when we pop it up
(which is guaranteed to not be during a layout cycle).
(This means that now we won't reposition the menu if the button
moves/resizes while the menu is already popped up, but it's not clear
that we'd want it to anyway, since that could easily result in the
user selecting the wrong item, etc.)
Also, we don't need to override the menu's width any more, so remove
that.
https://bugzilla.gnome.org/show_bug.cgi?id=619113
* Align the icons inside text
* Add application name to Quit
* Fade in/out the menu
* Drop some padding around the edges
* Add padding around the separators
* Use a gradient for separators
https://bugzilla.gnome.org/show_bug.cgi?id=618460
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
This patch combines several high level changes which are conceptually
independent but in practice rather intertwined.
* Add a "state" property to ShellApp which reflects whether it's
stopped, starting, or started. This will allow us to later clean
up all the callers that are using ".get_windows().length > 0" as
a proxy for this property
* Replace shell_app_launch with shell_app_activate and shell_app_open_new_window
A lot of code was calling .launch, but it's signficantly clearer
if we call this ".open_new_window()", and later if we gain the ability
to call into an application's menu, we can implement this correctly rather
than trying to update all .launch callers.
* Because ShellApp now has a "starting" state, rebase panel.js on top of
this so that when we get a startup-notification sequence for an app
and transition it to starting, it becomes the focus app, and panel.js
cleanly just tracks the focus app, rather than bouncing between SN
sequences. This removes display of non-app startup sequences, which
I consider an acceptable action in light of the committed changes
to startup-notification and GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=614755
We can't use gdk_display_get_pointer/gdk_window_get_pointer from gjs
when XKB is active. We already had a wrapper that did the
get-modifier-state part of that, but some places also need the
get-pointer-location part of it. So update our wrapper to return both,
and update js code to use it.
https://bugzilla.gnome.org/show_bug.cgi?id=613428
The original window dnd code needed to track whether or not the
pointer was in the clone. Some later rewrite made this unnecessary,
but we were still keeping track anyway.
When the notificaionBin has an odd width this could result into
loosing pixel aligment (and ugly looking font).
As the notification is already reactive make it non reactive and
remove the use of garvity.
https://bugzilla.gnome.org/show_bug.cgi?id=614702
Also reorganizes the notification layout to use an StScrollView; very
tall notifications are now scrolled instead of just taking up more and
more of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=608999
Also, remove a lot of cruft from genericDisplay.js leftover from
previous St-ifications, and remove the pre-gtk-2.16 hacks from the
status tray in panel.js (which are much less needed with the
nearly-all-black panel anyway).
https://bugzilla.gnome.org/show_bug.cgi?id=614516
The actual changes to shell-menu.[ch] are pretty minimal; most of the
changes there are just style/spacing/indentation.
Also, removed shell_menu_append_separator() since it wasn't needed;
the separators would already have been behaving as intended just
because they were non-reactive.
https://bugzilla.gnome.org/show_bug.cgi?id=614516
