First, we were passing an incorrect timestamp to
meta_display_focus_the_no_focus_window - fix that.
The invocation of set_focus_app to the started app there couldn't
really work, because (if the above call had worked) we'd get the
X reply *after* the started app.
What we need to untangle here is the distinction that's now made in
ShellApp between _STATE_STARTING and _STATE_RUNNING. A nice way to
start doing this is to rebase ShellWindowTracker to only be concerned
with app states. Concretely, the current "has windows implies
running" logic now lives just inside shell-app.c.
Rename the app-running-changed signal to be app-state-changed. This
will ultimately be useful so that inside the panel, we can track
the last started app.
https://bugzilla.gnome.org/show_bug.cgi?id=620899
Currently the workspaceSwitcher does not take the screen size into account
which could result into overflowing the screen.
Fix that but using Shell.GenericContainer instead of St.BoxLayout which takes
the monitor size into account when allocating.
https://bugzilla.gnome.org/show_bug.cgi?id=620404
Before adding a new entry to the history, we check that it does not
match the previous entry to cut down the number of duplicate entries.
Part of that condition is a check for a history length greater zero
to avoid an illegal negative index, with the side effect that nothing
is ever added while the history is empty.
https://bugzilla.gnome.org/show_bug.cgi?id=621123
As the design calls for smooth transitions whenever possible, use
a similar fade effect for the all-apps and more-docs menus as for
the panel menus.
https://bugzilla.gnome.org/show_bug.cgi?id=620775
When the app well doesn't contain any applications, it displays a placeholder text
to indicate that it's a drop target. When porting WellGrid from St.Bin to St.BoxLayout,
the call to set_child() to set the text was overlooked.
https://bugzilla.gnome.org/show_bug.cgi?id=617281
Currently, only the base style class is set in the constructor, the
style update according to the state of the represented app is deferred
until the actor is shown.
As existing icons are destroyed and recreated when the number of icons
changes, this behavior causes the icons of running apps to flicker if
CSS transitions are used.
Set the style directly in the constructor and update the code to not
delay style updates until the actor is shown - StWidget does defer
expensive calculations until the actor is mapped anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=620782
As the search entry captures the pointer when activated, the hover
state is not updated properly when the activation is cancelled
(either by clicking outside the entry or by hitting Escape).
Update the state manually in these cases.
https://bugzilla.gnome.org/show_bug.cgi?id=611095
Separate out the main app view into different sections based on the categories
in the desktop file. The configuration is done via gmenu and the desktop menu
specification, we set XDG_MENU_PREFIX="gs-" on startup, so that gmenu reads
gs-applications.menu, which we install.
There is no support for "submenus" - only the menus directly under
Applications will be displayed as categories.
https://bugzilla.gnome.org/show_bug.cgi?id=614131
Currently we only relayout when the screen size changes, this gets
the cases where a monitor gets added/removed but not when the primary
monitor changes.
We need to relayout on all monitor layout changes.
Remove ShellGlobal::screen-size-changed signal as it is no longer used, Gdk is
used to track changes now.
A ShellGlobal::gdk-screen property is added for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=620377
In all the cases where we activate GNOME 2 UI, e.g. the shutdown
dialog, pop out of the overview. Otherwise, it's fairly broken
since you won't see the result of your action.
https://bugzilla.gnome.org/show_bug.cgi?id=620525
Currently we don't get any drop events for dual screen modes with a screen
at the right, and behave weird by hardcoding the screen size and 0 as drag
edges.
Fix that by spawning the drop group over the whole stage and take the primary monitors position and size into account in _handleDragOver.
https://bugzilla.gnome.org/show_bug.cgi?id=620378
This patch adds ISO week dates to the calendar. Week dates are an
often used feature in business and government offices. Can be turned
on through gconf, off by default.
https://bugzilla.gnome.org/show_bug.cgi?id=603532
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
The check in _windowsRestacked checks for
windows[i].x >= primary.x
and
windows[i].x <= primary.x + primary.width
(likewise for y).
This is wrong because a fullscreen window on the secondary screen is likely
to have windows[i].x == primary.x + primary.width which means that the checks
for _both_ screens would be valid, but the first one would win due to
the "break;" statement.
But here the window isn't really on the primary but on the secondary one.
Fix that by using < instead of <= for those checks.
https://bugzilla.gnome.org/show_bug.cgi?id=614509
Moving to St.Table introduced a regression that resulted in the height
of Places section to only depend on the height of the left column.
This could result into some bookmarks not being displayed at all because
there are not enough items in the left column to allocate the needed height.
Fix this by removing the St.BoxLayout actors and add the items directly to
the table.
https://bugzilla.gnome.org/show_bug.cgi?id=614144
Notify() was calling setApp() unconditionally after attempting to
determine an application. However, determining the application can
fail (for example, when notify-send is used) and resulted in an exception
being printed.
Rather than having the notificationBin, summaryBin, and
summaryNotificationBin span the whole width of the screen and just
align their children to the right spot, set their anchor_gravity
appropriately, set their anchor point correctly, and let their width
vary with the width of their child.
Fixes the fact that the area to the left and right of an expanded
notification was reactive, because the notificationBin was invisibly
covering it.
https://bugzilla.gnome.org/show_bug.cgi?id=612072
Currently manual dnd mode is used with St.Clickable to avoid messing
up its internal state with a pointer grab. To avoid code duplication,
move this special handling into dnd.
https://bugzilla.gnome.org/show_bug.cgi?id=610385
While most of the code already is CSS stylable, the two-colum setup
is still done using Big.Box with hard coded spacings. Port those
remaining parts to St.Widget, so that all spacings can be adjusted
by the theme.
https://bugzilla.gnome.org/show_bug.cgi?id=610385
The POPUP_LIST_SPACING constant was used for the AltTabPopup.actor's padding,
AltTabPopup.actor's spacing and SwitcherList._list's spacing.
Switch to CSS and remove the constant.
https://bugzilla.gnome.org/show_bug.cgi?id=613195
Left-clicking an app icon and holding the button used to pop up the
app menu, but regressed when rewriting appDisplay.
Restore the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=609013
Clicking the eject button in the places display always triggers an
unmount action. In some cases like USB drives or DVDs, eject makes
more sense - it is also consistent with nautilus' behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=613405
After closing a window, the remaining previews are repositioned
after a timeout; when it is called while the user zooms a preview,
the window positions get all messed up, so postpone the positioning
in this case until the zoom ends.
https://bugzilla.gnome.org/show_bug.cgi?id=613536
The hover rewrite added a freeze/thaw_notify to
st_clickable_leave_event() (to match the one already in
st_clickable_enter_event()), which broke code in two places that
assumed "pressed" would still be TRUE when "hover" changed to FALSE.
Fix that by exposing the "held" property as well.
St.Widget's new "hover" property takes reactive children into account
when deciding whether or not the pointer has actually left the actor,
so it works better than the code that used to be here.
https://bugzilla.gnome.org/show_bug.cgi?id=610726
If track-hover is set, update the hover property automatically, and
the "hover" pseudo class to match, as StClickable used to do. (Remove
the corresponding code in StClickable). Tweak the tooltip handling to
use track-hover, which also makes it slightly more reliable in the
presence of reactive children, etc.
Since style_class and pseudo_class are space-separated lists of names,
add new methods to add and remove individual names rather than just
re-setting the entire name.
Update existing code to use the new pseudo-class methods where
appropriate. In some cases, this may result in actors having multiple
pseudoclasses where previously they only had one at a time, but there
don't seem to be any visible differences.
(There are some places that could usefully use the new style_class
methods as well, but this patch doesn't change them.)
Also, update test-theme.c to test the new methods.
https://bugzilla.gnome.org/show_bug.cgi?id=604943
When the user runs the same command as the last one saved there
is no need to save it again, otherwise we the history might end
up having lots of dupes which makes searching for an old command
harder.
https://bugzilla.gnome.org/show_bug.cgi?id=613731
