Tray icons control their own lifespan; they're not supposed to
disappear when you dismiss their notifications like non-trayicon
notification sources do.
https://bugzilla.gnome.org/show_bug.cgi?id=631042
Previously, when you clicked on a notification, it would call
this.source.clicked(), which would emit a 'clicked' signal on the
source, and then various other stuff would happen from there. This
used to make a little bit of sense, when clicking on a notification
was supposed to do the same thing as clicking on its source, but makes
less sense now, when clicking on the source itself *doesn't* call
source.clicked()...
Change it so that when you click on a notification, the notification
emits 'clicked' itself, and the source notices that and calls its
notificationClicked() method, and the various source subclasses do
what they need to do with that, and Source no longer has a clicked
method/signal.
https://bugzilla.gnome.org/show_bug.cgi?id=631042
Redo the way that the summary item expand/collapse animation works so
that the items all resize in unison so that when moving from one to
another, the summary area as a whole stays a constant width rather
than wobbling slightly.
(Also rename all references to the "minimum" summary item title width,
since it's not a minimum, it's just the width.)
https://bugzilla.gnome.org/show_bug.cgi?id=630546
This fixes the bug when the body would be missing from the expanded notification
that has a short body that used to fit in the one-line banner and is expandable
because it has action buttons.
We always want to add the banner to the body of an expandable notification,
unless the notification has custom content. We used to only do that when
creating this._scrollArea for the content. We should also do that when creating
this._actionArea .
https://bugzilla.gnome.org/show_bug.cgi?id=631566
It's possible that an item that was added to the summary got removed before
we had a chance to show the summary because the user has interacted with
the notification (e.g. clicked on an application ready notification). We should
not be showing the summary with an unchanged set of items in this case.
However, it is possible that multiple items were added to the summary before
we had a chance to show the summary, and only some of them got removed. In view
of this scenario, we can't just use a boolean flag to indicate if the summary
needs to be shown, but have to maintain an array of new summary items instead.
https://bugzilla.gnome.org/show_bug.cgi?id=630939
Environment.init() uses Shell.Global, which is not accessible outside
the mutter process; allowing to run the function when window.global is
undefined fixes the environment for tests.
https://bugzilla.gnome.org/show_bug.cgi?id=631091
Introduce Cairo-drawn sliders to be used in PopupMenus (for example for
volume). They are stylable to some extent (colors, border width, slider
height) and have the standard behaviour of a slider, except they are
completely modal (once you start dragging, all events are intercepted by
the slider, which thus is kept active and highlighted at all times).
They show numeric values between 0 and 1 (scaling must be performed outside)
and emit value-changed on button release, but no activate, keeping the
menu open.
https://bugzilla.gnome.org/show_bug.cgi?id=625029
PopupMenuManager now connects to the destroy signal of PopupMenu, so
that destroying a PopupMenu is now enough for removing it from the
relevant manager. Useful if menu come and go on-the-fly (like in
app views or sidebars).
https://bugzilla.gnome.org/show_bug.cgi?id=630914
Having the summary pop up automatically after a source icon has been
removed is pretty useless ("Hey, there was something interesting going
on, but you missed it and it's gone now, kthxbye").
https://bugzilla.gnome.org/show_bug.cgi?id=630939
Icons can be loaded as St.Icon.SYMBOLIC, FULLCOLOR, APPLICATION or
DOCUMENT. The first will look for a symbolic equivalent, the second
looks for a full-color version (and does fallback, eg, from
"drive-harddisk-usb" to "drive-harddisk"). APPLICATION and DOCUMENT do
full-color icons without fallback (as specified by the icon spec).
And update various callers to use the right flags.
Based on a patch from Matt Novenstern.
https://bugzilla.gnome.org/show_bug.cgi?id=621311
Both current design and new mockups use square icons. Currently this
is implemented by setting a fixed width and height in the CSS, which
does not work for the growing/shrinking items in the new sidebar.
By moving the assumption of square items into the code, the size will
adjust according to icon size, spacing, padding and font size if not
explicitly overwritten in the CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=625887
The current design features a sidebar where the icon size shrinks
automatically to fit more items. Add a setSizeManually parameter
to BaseIcon, which disables sizes read from CSS and allows to use
BaseIcon.setIconSize() to support this.
https://bugzilla.gnome.org/show_bug.cgi?id=625887
All mockups now use a representation for documents/places similar to
the one used for applications. Rename AppIcon to BaseIcon and move its
code together with WellGrid out of appDisplay to stress their general
usefulness.
https://bugzilla.gnome.org/show_bug.cgi?id=625887
The actor emitted by ShellTrayManager is now ShellTrayIcon, a subclass
of ShellGtkEmbed which has several properties on it which are (or will
soon be) useful to the shell.
Part of the rearranging to use ShellTrayIcon means that we now show
the ShellEmbeddedWindow before creating its ShellGtkEmbed, which
requires a few modifications to ShellEmbeddedWindow (notably, telling
it at construct time what stage it will be drawn on, since it needs to
know that before it has a ShellGtkEmbed now).
https://bugzilla.gnome.org/show_bug.cgi?id=608869
Resolve a notification's ShellApp before posting the notification, so
that notification sources now always have an app associated (assuming
they came from an app as opposed to the command line). Index sources
by PID rather than by appName (so that, eg, multiple calls to
notify-send now show up as separate sources).
For Sources that have an associated app, use the app's icon for the
source, rather than tracking the notification icon.
This change also lets us get rid of appNameMap, since we can just use
shell_app_get_name() now.
https://bugzilla.gnome.org/show_bug.cgi?id=629090
Previously we were hiding the banner label if the title was too long,
but this causes queue_relayout() warnings. Instead, just set its
opacity to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=629308
Introduce the Universal Access status indicator as designed, modeled
after the similar UI provided by g-s-d. This indicator allows the user
to change rapidly the keyboard and mouse behaviour (sticky keys, slow
keys, bounce keys, mouse keys), as well as the enabled ATs (magnifier,
screen reader, screen keyboard) and the HighContrast Gtk theme.
https://bugzilla.gnome.org/show_bug.cgi?id=624916
Adds class PopupSubMenuMenuItem, which is an item holding a submenu,
that is opened when the corresponding item is active, and is keyboard
and mouse navigable like its Gtk counterpart.
https://bugzilla.gnome.org/show_bug.cgi?id=623498
This patch allows the icon in PopupImageMenuItems to be changed at
any time, while preserving the item and all other properties (style,
signals) attached and without rebuilding the whole menu. This is useful
for images reflecting a dynamic status (e.g. cellular strength
indicator or battery level)
https://bugzilla.gnome.org/show_bug.cgi?id=623652
Modal dialogs slide back into the titlebar of the parent window when destroyed.
This looks weird if the parent window itself has been destroyed, so cancel the
effect in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=629560
Extend WellGrid with an optional rowLimit parameter and an accessor
function for the grid's items, then use it to replace the custom
container used to display the application search results.
Also adjust the spacing of the search results slightly to make it
consistent with the app well.
https://bugzilla.gnome.org/show_bug.cgi?id=622446
The keyReleaseEvent handler does not take into account that a
user might release Alt while still holding shift
(the keycode becomes Meta_L/R in that case).
The result is that the switcher stays open which is unexpected.
https://bugzilla.gnome.org/show_bug.cgi?id=629368
Override the new mutter preference /apps/mutter/general/attach_modal_dialogs
to attach modal dialogs to their parent window. Animate the modal dialogs
expanding from the top of the parent window. Slowly dim the parent window
after the dialog comes up.
https://bugzilla.gnome.org/show_bug.cgi?id=612726
This patch ensures the following notifications behavior:
- Urgent notifications that have long title or banner text are auto-expanded
correctly.
- Single-line notifications that have _expandNotification() called (e.g.
because the user mouses over to them), are treated as expanded, which means
they get fully expanded if they are updated with more content and the user
can escape them.
- The position of expanded notifications is updated when they are updated.
- Notification banner is shown again on the first line if it can fully fit
there after a notification is updated, even if it was previously hidden
because the notification was expanded and the old banner did not fully fit.
- New notifications are immediately hidden if the user mouses away from them.
- If a new notification is updated while it is shown, we extend the time it
will be shown.
- If a new notification is updated while it is hiding, we stop hiding it and
show it again.
- If a summary notification is updated while it is hiding, we let it finish
hiding and show a new notification with the updated information.
Implementation details:
- Single-line notifications now have 4px bottom padding instead of 8px, which
means that their height matches the tray height, they are fully shown in the
banner mode, and don't pop out by 4px when the notification is expanded.
- Notification keeps a flag that indicates whether it is expanded, updates
its expanded look when it is updated, and emits an 'expanded' signal
indicating that its layout has possibly changed. The message tray connects
to this 'expanded' signal when it is showing a notification in the expanded
state and updates the position of the notification accordingly when this
signal is received so that the notification is fully shown. This is better
than connecting to 'notify::height' signal on the notification bin, since
it results in fewer callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=617209
The Shell is the only user of the magnifier, so there's no
reason to keep using GConf for its settings. Since it's a
session-wide tool, use a distinct schema,
org.gnome.accessibility.magnifier, stored in
/desktop/gnome/accessibility/magnifier just like before.
Put these settings in a separate schema file for clarity.
Old enums in GConf were stored as integers, we now use the
facilities provided by GSettings to save them as strings,
and convert them to integers automatically thanks to the
mapping stored in the schemas. Remove hard-coded default values,
which we can get from the schemas.
https://bugzilla.gnome.org/show_bug.cgi?id=622414
Return a DND.DragMotionResult constant from delegate _handleDragMotion
methods as well as the existing return value from the drag monitor method dragMotion.
https://bugzilla.gnome.org/show_bug.cgi?id=607821
Expanding notifications automatically just because they popped up where
the pointer is positioned distracts the user. It can also lead to a behavior
that is surprising to the user by, for example, making the user's input
switch to the notification's text entry box.
It is possible to expand a notification that popped up over the pointer
by mousing away from it and then mousing back in immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=617209
We used to keep long titles ellipsized when a notification was expanded,
which was a bug. We now show them fully by line wrapping them.
Based on the original patch from Steven Van Bael.
https://bugzilla.gnome.org/show_bug.cgi?id=623970
We used 'bannerBody' flag to differentiate the case when we move the banner to
the body when the notification is expanded from the one when we don't do that
and only use the custom content set for the notification, as is the case for
Telepathy notifications. We also always cleared the content of the notification
on update when bannerBody was set to true.
Flag named 'customContent' reflects the use case for it more clearly. The
comments that accompany it were also updated and improved.
We now always add the banner text as the first element in the expanded
notification unless 'customContent' flag is set to true.
If the 'body' parameter is specified, we use it in addition to the banner
text. The earlier version of the code had a bug that resulted in the 'body'
parameter not being set only in the case when the 'bannerBody' was set to
true and the banner text had newlines in it.
https://bugzilla.gnome.org/show_bug.cgi?id=623970
The banner should not be appearing briefly when we are hiding the notification.
For that, we should only restore the opacity of the banner in popInCompleted()
when we are done hiding the notification. We do need to restore the opacity
in case the notification is updated and is shown in the banner mode again.
The banner should not be appearing briefly when we are showing the notification
in the summary mode. For that, we should not use the animation time to fade out
the banner in popOut() for summary notifications.
These two problems were particularly visible when the ANIMATION_TIME was increased.
https://bugzilla.gnome.org/show_bug.cgi?id=623970
In Clutter 1.2, clutter_event_get_keysym() ignored the state of the
Shift key. In 1.4, it does not, so we have to adjust our comparisons
accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=627782
The old calculation did not take into account the icon and the spacing
between columns. This resulted in the notifications that had a slightly
longer title/banner combination than could actually fit not being expandable.
The new calculation is done in _bannerBoxAllocate() so
that we don't need to hardcode which other elements are present.
https://bugzilla.gnome.org/show_bug.cgi?id=627985
A Source needs exactly one summary icon (which in the case of a
trayicon-based source won't even be just an image), but possibly many
notification icons, which may vary for successive notifications
(particularly in the case of NotificationDaemon notifications). So
differentiate these cases in the API.
https://bugzilla.gnome.org/show_bug.cgi?id=627303
The tray itself does not actually need them, and to make status icon
sources work correctly the NotificationDaemon will need to be tracking
its sources by two separate IDs, so the existing system won't work.
Also remove MessageTray.removeSourceByApp(), which is
NotificationDaemon-specific, and implement the functionality in
notificationDaemon.js instead.
https://bugzilla.gnome.org/show_bug.cgi?id=627303
The current search system uses the OR operator to concatenate search
terms. While results which are matched multiple times sort before
other matches, it is almost guaranteed that adding an additional term
to the search increments the number of results, which is rather
surprising.
https://bugzilla.gnome.org/show_bug.cgi?id=610955
When calling Notification.update, reuse the previous _bannerBox and
related labels (only changing the label content and relayouting), so
that the opacity set on popOut is preserved. As a consequence, updating
an opened notification no longer shows (or flicker) the banner at the
top.
https://bugzilla.gnome.org/show_bug.cgi?id=625502
The start date is shifted by a week if the day number of the month's
first day is smaller than the week start's day number. Probably the
only real world examples are months starting on a Sunday with locales
using Monday as start of week.
https://bugzilla.gnome.org/show_bug.cgi?id=625756
It is not obvious that only the icon is clickable to activate the
default action - in fact, with the area being that tiny, many don't
even know that notifications can be clicked.
Just extend the clickable area to the whole notification.
https://bugzilla.gnome.org/show_bug.cgi?id=613932
Adds class PopupSwitchMenuItem, which is a two-state switch similar
to those in system status indicators mockups. Also adds class Switch,
which represents the switch itself, in case it is useful somewhere
else.
https://bugzilla.gnome.org/show_bug.cgi?id=621880
In addition to already grabbing focus in the summary notifications,
we also want to grab focus in the new notifications when the user
hovers over them and expands them.
The notifications that expand automatically will only get focus once
the user hovers over them. The notifications that don't expand will
never grab focus because they don't need it.
Make sure that we toggle the way we grab focus when switching between
the overview and the main mode. This is necessary because, unlike
summary notifications that pop down when the user moves between the two
modes, new notifications keep being shown as long as the user hovers
over them or until they time out.
https://bugzilla.gnome.org/show_bug.cgi?id=617224
Because clicking on the summary item to have it display its notification
is a more deliberate action than hovering, we can now grab focus in that
notification. This makes chat notifications in the summary more convenient
to use because you don't need to click on the text entry there.
We pop down the notification when the user clicks anywhere outside of it,
triggers the overview, or the run dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=617224
This ensures that the summary appears when we are showing a new
notification and switch to the overview at the same time.
Another effect of this patch is that the summary is shown if the
user moves the mouse to the bottom right corner while a notification
is being shown, which is ok.
This patch adds the method "removeMenu" to PopupMenuManager, to allow
for removal of menus after they're inserted. In order to do this, it
needs to store along with the menu all the relevant signal connections,
that are disconnected when the menu is removed.
Also adds a parameter "position" to "addMenu", so that menus can added
in arbitrary order (in particular to reintroduce those which were removed).
This patch is intended towards dynamic menu users, like extensions for
application lists, docks, sidebars showing recent documents or favourites,
as well as advanced system tray implementations.
https://bugzilla.gnome.org/show_bug.cgi?id=622730
In GSettings, a change notification is generated immediately from context of the _set() call.
In GConf, The "value_changed" signal is emitted whenever the server
notifies your client program that a value has changed in the database (100% NOT from context of the _set() call).
https://bugzilla.gnome.org/show_bug.cgi?id=624296
We need to only connect to 'action-invoked' on notification once
when the notification is created. We were accumulating callbacks
otherwise, which resulted, for example, in the Rhythmbox skipping
through multiple tracks when the 'Next' button was hit.
Always be sure to destroy the notification when its source is
destroyed, which is the case when an action is invoked.
Note that in the future, we might not want to destroy the source
for some notifications when an action is invoked. For example,
it makes sense to keep Rhythmbox in the tray while the music is
playing and allow the user to use the controls from the summary
notification too.
Solved by splitting the base class (PanelMenuButton) in a separate
module, ui.panelMenu, which is meant to hold also other reusable
button classes.
https://bugzilla.gnome.org/show_bug.cgi?id=621705
The spinner animation moving from left-to-right to indicate a starting
application changes its direction on reaching the end of the movement.
Instead, keep the spinner at the right of the app name until startup
has finished.
https://bugzilla.gnome.org/show_bug.cgi?id=623687
We should not be showing the cursor in the search entry in the overview
if the user's input will be appearing elsewhere, such as in the run dialog,
in the Looking Glass console, or in the notification's response field.
"text-align" allows setting the alignment of text, with respect to
other lines and allocated space, without requiring a reference to
the ClutterText (which is private for most widgets).
If not specified, all text is left-aligned.
https://bugzilla.gnome.org/show_bug.cgi?id=622447
This is part of the design update for the message tray.
Source now takes an extra argument called 'title'.
All expanded message tray items are same width, which is determined by
the width of the item with the longest title, up to MAX_SOURCE_TITLE_WIDTH.
This is done so that items don't move around too much when one is expanded
and another one is collapsed.
https://bugzilla.gnome.org/show_bug.cgi?id=617224
While the contents of the left and right group in the panel are
flipped correctly, the groups themselves have to be swapped as
well. The location of the hot corner has to be corrected as well.
https://bugzilla.gnome.org/show_bug.cgi?id=622243
It has probably crossed the line to evil by a mile or so, but here
it is: a Tweener.slowDownFactor replacement used by all animations
without exception.
While at it, update Tweener to use the new setTimeScale() upstream
function instead of adjusting the timeline directly.
https://bugzilla.gnome.org/show_bug.cgi?id=622249
Use GSettings for all Shell configuration. GConf is kept to read
configuration from external programs (Metacity, Nautilus and Magnifier),
but ShellGConf is removed because it's mostly useless for the few calls
we still have. Also get rid of unused GConf code in ShellAppSystem.
A basic GConf schema is still used to override Metacity defaults and
configure Magnifier in a system-wide fashion. GConf is also used as
GSettings backend via the GSETTINGS_BACKEND environment variable.
All of this will be removed when these programs have been ported
to GSettings and able to use dconf.
GLib 2.25.9 is required. Schemas are converted to the new XML format,
and compiled at build time in data/ so that the Shell can be run from
the source tree. This also requires setting the GSETTINGS_SCHEMA_DIR
environment variable both when running installed or from source tree,
in src/gnome-shell.in and src/gnome-shell-clock-preferences.in.
https://bugzilla.gnome.org/show_bug.cgi?id=617917
The shell design says that upon launching an application,
no X window should have focus, and we should display an
animated launching indicator.
Implement this by in panel.js, keep track of the last started
application. If there isn't currently an X focus, show an animation
for the last starting application.
https://bugzilla.gnome.org/show_bug.cgi?id=598349
Canonical replaced status icons with libindicator based solutions,
which don't work in the shell environment. Force the distro-patched
versions to fall-back to upstream.
https://bugzilla.gnome.org/show_bug.cgi?id=621382
While zoomed out in drag mode, the workspaces at the left and right
of the active workspace are slightly transparent - when switching
workspaces, one of the transparent workspaces becomes the new active
workspace, but its opacity is not updated.
https://bugzilla.gnome.org/show_bug.cgi?id=620940
When in drag mode, the linear view raises a transparent actor
covering the entire stage. That way the view can handle events
like dragging items to the screen edges, but in order to not
disable any drop target not handled by itself, it duplicates
huge amounts of code from dnd.js.
Cleanup that mess by using the new drag monitoring support.
https://bugzilla.gnome.org/show_bug.cgi?id=620504
Sometimes it is desirable to be able to react to DND events that
happen outside a target actor's bounds, e.g. to implement reactive
screen edges. Add a simple interface which allows to hook into
drag motion and drop handling without jumping through ugly hoops.
https://bugzilla.gnome.org/show_bug.cgi?id=620504
The design calls for item to not appear abruptly, but not too slow
either - 100ms seems to be a good sweet spot for elements which are
supposed to appear "instantly".
Add a fade effect to the alt-tab popup and set the timings for other
fade effects to 100ms.
https://bugzilla.gnome.org/show_bug.cgi?id=621247
We query the transformed position and size of the popupMenu before actually showing
it which results into wrong positioning, when displaying it for the first time.
In case of the statusMenu this can even result into it being offscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=621385
Add _st_actor_contains() in st-private for use within St, and
monkey-patch in a Clutter.Actor.contains() for use by javascript, and
then replace all the duplicate implementations with one or the other
of those.
https://bugzilla.gnome.org/show_bug.cgi?id=621197
Currently, we use 'gtk-yes', 'gtk-no' and 'gtk-media-pause' as
user status icons. It seems more logical to use the dedicated
icons from gnome-icon-theme instead.
https://bugzilla.gnome.org/show_bug.cgi?id=620374
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
Using a clone for the drag actor causes the animation into
the final position not to work as expected; instead use
the newly added DND parameters to change the original
drag actors size and opacity. (This reverts the change in
011db9f).
Since we are using the original actor, we have to be careful
not to change it during the drag, so don't actually position
dragged window actors in Workspace.positionWindows().
https://bugzilla.gnome.org/show_bug.cgi?id=613367
Gjs now removes user_data arguments for callbacks - the existing
code still works because all user_data arguments are unused and
at the end of the argument list, but it's a lot prettier to remove
them.
Currently, the workspace objects are destroyed and recreated on
view switches. Instead, keep the objects around and reparent the
workspace actors on view switches.
https://bugzilla.gnome.org/show_bug.cgi?id=610191
Depending on screen size and pointer position, the scroll bar used
to switch the active workspace in linear view may not be a convenient
target, so allow dragging the desktop as an alternative.
https://bugzilla.gnome.org/show_bug.cgi?id=610892
DND from the places section broke with 1c4c3afb when St.Label was
replaced with St.Button.
To fix, replace St.Button with St.Clickable and use a fake_release
when starting a drag.
https://bugzilla.gnome.org/show_bug.cgi?id=609218
Currently we use two buttons to toggle between the different views,
one of them always being redundant.
Fix that by only use one button that changes it's style depending on
the current view.
https://bugzilla.gnome.org/show_bug.cgi?id=610801
When an unmount operation fails, the only feedback given currently
is an exception on stderr. Use the infoBar to display an error
message and allow the user to retry the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=612200
Currently the infoBar's button will always read "Undo" - sometimes
a different label makes more sense, so allow to optionally set the
label to something else.
https://bugzilla.gnome.org/show_bug.cgi?id=612200
Instead of setting a fixed size in the CSS which only works well
with a limited range of screen resolutions, assign a relative
size in the code.
While this takes away some flexibility from theme authors, it is in
line with most elements in the overview (workspaces area, dash).
Also expose the menu panes vertical alignment, so that more-apps aligns
to the workspaces area's top and more-docs to the bottom.
https://bugzilla.gnome.org/show_bug.cgi?id=610872
Limit the AppSwitcher to the screen size by either downscaling or
scrolling.
We scale the icons down up from 96, 64, 48, 32 to 22 and start scrolling
if we still fail to fit on screen.
The thumbnail box is shifted to either left or right, when failing to
fit we scroll here to.
To prevent from being offscreen at the buttom we adjust the thumbnail
height to fit.
The old positioning logic is replaced with a ShellGenericContainer to
implement a custom allocation system.
https://bugzilla.gnome.org/show_bug.cgi?id=597983
As the repositioning after closing a window preview is delayed, it is
possible that the timeout is triggered while leaving the overview. In
that case the previews move to the new overview position and are changed
abruptly to the original window position when the overview zoom is done.
To prevent this, disconnect the handler when leaving the overview.
Rename WorkspacesViewSwitch to WorkspacesControls and let it manage
all workspace controls. Do not destroy and recreate the controls bar
actor on each view change, but add it to the overview once and let it
update itself.
https://bugzilla.gnome.org/show_bug.cgi?id=610189
Hide the original actor during a grab, and create a new
clone. This is easier than trying to ensure we maintain
the state of the original window clone.
https://bugzilla.gnome.org/show_bug.cgi?id=607821
The way we were loading data into a CoglTexture, then pulling it out
and manipulating it on the CPU, then loading it back into a texture
was a bit lame.
Clean things up a bit here by loading directly into the CPU, doing
the fading, then creating a texture.
Also cache the faded data in StTextureCache.
https://bugzilla.gnome.org/show_bug.cgi?id=612759
Having StDrawingArea use ClutterCairoTexture causes circularity
problems with sizing - StDrawingArea wants to use its allocation for
the size of the texture, but ClutterTexture wants to use the size of
the texture to determine the requited size.
Avoid this by making StDrawingArea directly use Cairo and CoglTexture;
while doing this, the API is changed a bit for simplicity and to
match our use case:
- Instead of clutter_cairo_texture_create(), we have
st_drawing_area_get_context() to retrieve an already created
context. This can only be called in the ::repaint signal.
- The ::redraw signal is changed to ::repaint so we can have
st_drawing_area_queue_repaint() that doesn't collide with
clutter_actor_queue_redraw()
- ::repaint is now emitted lazily when painting the actor rather
than synchronously at various different points.
https://bugzilla.gnome.org/show_bug.cgi?id=611750
Currently clicking on an empty spot on the workspace actors switches to the workspace, this has a side effect that when for some reason (like using a touchpad),
the user misses the window he intends to open he will end up with the currently focused window instead.
Disable this behaviour if more than one window is open (in that case the user has to explicitly target a specific window).
https://bugzilla.gnome.org/show_bug.cgi?id=610868
Support completion on files and folders in the run dialog and launch
the default application when activated. Assume a path relative to the
home directory if execution as command fails and the input doesn't start
with a slash.
Removed workaround for relayout of error messages.
https://bugzilla.gnome.org/show_bug.cgi?id=611209
We used to set this._notificationRemoved to false in _hideNotification().
However, the user focusing on the associated application can result in the
source being removed while the notification is hiding, in which case
this._notificationRemoved was set to true and never unset. This resulted in
the next notification only showing up briefly and hiding. Moving setting
this._notificationRemoved to false to _hideNotificationComplete() fixes this
behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=611122
The top part of the application pane closes the pane, while outside
the menu only the workspace area accepts clicks for closing the pane.
Let the user close the pane by clicking anywhere outside the menu, but
not inside.
https://bugzilla.gnome.org/show_bug.cgi?id=611641
When closing windows in the window picker, the remaining windows
move to their new positions, which prevents the user from performing
additional actions in the picker until the animation stops and the
user adjusts to the new layout.
Instead we try to be smart and delay the repositioning, either until
the pointer stops moving or until it leaves the workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=611167
Brute force merge these two by essentially replacing St.TextureCache
with a (renamed) Shell.TextureCache.
One function was added for convenience, namely "st_texture_cache_load_file_simple".
St.TextureCache had a function to load a texture from a filename, and it
returned NULL on error but only half the callers actually checked this. This
function is better.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
These variables were computed strangely; through cancellation
they'd end up being negative 1/2 the width/height of the actor,
so just use that directly.
https://bugzilla.gnome.org/show_bug.cgi?id=607821
The current check looks at whether there was some am/pm suffix in the
localized time; however in some cases (locales) that does not seem to
work. this version instead checks whether the localized versions of 05:00 and
17:00 start with the same two digits; if not, it's probably a 24h clock.
https://bugzilla.gnome.org/show_bug.cgi?id=603488
The previous commit broke activation when selecting an actor
from a custom renderer. Fix this by explicitly defining a method
activateSelected on the search renderer.
Switch to using an application icon as per design.
We need to drop the 4 pixels padding to ensure we fit 3 icons.
There was a typo where getVisibleCount should have been getVisibleResultsCount.
https://bugzilla.gnome.org/show_bug.cgi?id=610740
When workspaces slide in/out in mosaic view, they may cross with the
workspace controls, which looks pretty weird.
Also adjust the vertical spacing in the grid view so that the grid height
matches the workspace height in the linear view.
https://bugzilla.gnome.org/show_bug.cgi?id=610350
When figuring out where to position window previews, use the clone's
position instead of the the original meta window. There shouldn't be
a difference when entering the overview, but it makes the motion when
opening/closing new windows in the overview tinier and more predictable.
https://bugzilla.gnome.org/show_bug.cgi?id=611167
Fading the application icon required the texture to have already been
loaded, which was normally the case since we create icons for apps
in the well and browser; but when finding an app not from there,
the cogl-texture for the icon might not be available.
Fix this by watching for the texture and fading when it appears.
https://bugzilla.gnome.org/show_bug.cgi?id=611288
Because we were setting the "fixed-position-set" property
on the internal label, its width/height requests weren't
being accounted for in the size request of the overall box.
The way we were hooking up to notify::allocation was hacky; do
this correctly by simply implementing a container.
https://bugzilla.gnome.org/show_bug.cgi?id=611288
Currently the picker displays information on the hovered actor's
position and the object itself. Adding style id and class of
StWidgets to the displayed information can be very helpful for
identifying a particular actor or code segment.
https://bugzilla.gnome.org/show_bug.cgi?id=611211
When the currently focused app sends a notification while in the overview,
the corresponding source icon is not removed when the overview is left.
It does make some sense to treat the overview transition the same as a
normal focus change, so we should update the summary view accordingly.
When a notification is updated by the application, the corresponding
app in its source is lost, so it is no longer possible to switch to
the application by clicking either the notification or the summary icon.
As the associated application of a source never changes, it appears safe
to leave it alone on notification updates.
https://bugzilla.gnome.org/show_bug.cgi?id=610820
Source icons are no longer needed to inform the user about events
having occured in a particular application when (s)he activates the
window - treat that case just as if the user had clicked the source
icon.
https://bugzilla.gnome.org/show_bug.cgi?id=610494
Right now notifications are expandable if the length of bannerText
exceeds the notification's width - however, if bannerText contains
newlines, it should be expandable regardless of the length.
https://bugzilla.gnome.org/show_bug.cgi?id=610549
When leaving the overview by hitting escape or super, all windows animate
to their original positions. Zoomed windows are kept above others until
the animation ends, then the focused window is brought to the front; as
this looks odd if the zoomed window does not have focus, cancel the zoom
in that case before leaving the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=609243
While zooming, a window clone is reparented to the stage and thus cannot
be destroyed automatically by the "parent" container. To prevent the clone
and the corresponding overlay from leaking, we enforce destroying the clone
with the workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=609243
We are planning to add Empathy-specific features in the message tray, but in the
meantime we handle Empathy notifications received through the notification daemon
so that their behavior is closer to the eventual design, which is how it was before
we started associating applications with a single source and enabled notification
replacement.
Use the "appName" parameter in notifications to identify the source
rather than the id - use the latter to enable update and removal of
individual notifications as laid out in the desktop notification spec.
This is a rebase of the patch by Florian Müllner.
Add a 'vshadow' property to StScrollView, which, when turned on,
overlays gradient shadows on the top and bottom of the StScrollView.
Turn this on for the StScrollView used for the app browser.
https://bugzilla.gnome.org/show_bug.cgi?id=609604
Changes notifications like:
XChat: Private message from: danw (GimpNet) blah...
to
danw: blah blah blah blah
(the "XChat" being unnecessary since there's already an xchat icon
there anyway.)
https://bugzilla.gnome.org/show_bug.cgi?id=608915
Make the width of the workspace switcher dynamic in order to make it have the same proportions as the actual screen.
Call redraw after adding indicator to stage to avoid warning.
https://bugzilla.gnome.org/show_bug.cgi?id=610049
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Inform the user about demands attention events using the messagetray.
Clicking on the notification icon moves the user to the window.
It differentiates between newly started apps and windows of already running apps, by showing different banners for this cases.
It is based on Jon Nettleton's "window attention" extension.
https://bugzilla.gnome.org/show_bug.cgi?id=610594
WindowOverlay has two actors, both with custom style properties, which
share a common _onStyleChanged() handler. This is not a problem when
entering the overview, because the actors' parent (the workspaces group)
is hidden while the actors are added. However, when windows are added to
the workspace while in the overview (e.g. when opening a new window or
dragging a window from one workspace to another), adding the first actor
to the workspaces group triggers a style-changed signal - the handler
then calls st_widget_get_theme_node() on both actors, which triggers a
warning as the second actor has not been parented yet.
https://bugzilla.gnome.org/show_bug.cgi?id=610279
If the notification body contains '&' it ends up empty and a warning
about an invalid entity is printed on stderr, so our escape code must
handle ampersands as well.
https://bugzilla.gnome.org/show_bug.cgi?id=607375
Right now, the summary starts popping up when the overview has been
shown and starts to disappear when the overview is hidden. Instead,
animate the summary during the overview transition.
https://bugzilla.gnome.org/show_bug.cgi?id=610520
Unify the style of <delegate>.destroy() methods to only contain a
call to <delegate>.actor.destroy() and handle additional cleanup
in a _onDestroy() signal handler.
https://bugzilla.gnome.org/show_bug.cgi?id=609454
Instead of deleting workspaces immediately, animate the removal - it may
be useless eye-candy, but it's pretty sexy nonetheless ...
More seriously, the animation improves consistency with both workspace
additions and the mosaic view.
https://bugzilla.gnome.org/show_bug.cgi?id=609673
Currently the width of the gaps between workspaces in both linear
and mosaic view are defined as constants. Move these to the theme's
CSS instead.
https://bugzilla.gnome.org/show_bug.cgi?id=609673
Reorganize the code to break up positioning into:
1) updating workspace object's scale and position
2) applying the updated parameters to the workspace actor
3) scrolling the view to a particular workspace
4) handling dragging of the scroll bar
With these cleanups, it becomes much easier to fix
the following issues:
- use animations consistantly instead of doing hard breaks
for some actions and smooth transitions for others
- snap to the closest workspace when scrolling stops
(https://bugzilla.gnome.org/show_bug.cgi?id=607823)
- fix the regression of the zoomFromOverlay animation when
the selected app is on another workspace
(https://bugzilla.gnome.org/show_bug.cgi?id=609081)
https://bugzilla.gnome.org/show_bug.cgi?id=609673
This way, clicking a message tray icon while the overview is open will
close the overview when activating its window.
Remove some other overview-related activation code which is now
redundant.
Also, remove calls to "global.get_current_time()" when calling
Main.activateWindow, since it's unnecessary (activateWindow will call
it itself if you don't pass in that arg).
https://bugzilla.gnome.org/show_bug.cgi?id=609765
Previously, every time _updateState was called, it would make some
change, and so it was necessary to very carefully set up all the calls
to it, to ensure it was always called at exactly the right time. Now,
instead, we keep a bunch of state variables like "_notificationState"
and "_pointerInSummary", and potentially multiple timeouts, and
_updateState looks at all of them and figure out what, if anything,
needs to be changed.
By making the rules about what causes changes more explicit, it will
be easier to change those rules in the future as we add new
functionality.
Also, update the rules a bit, so that notifications can appear while
the summary is visible, and the summary only shows after a
notification if the summary has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=609765
Fallback icons (i.e icons < requested size) cause the box in the switcher
to be a smaller rectangular item instead of the normal sized square one.
Fix that by putting the icons in a St.Bin with the correct size.
https://bugzilla.gnome.org/show_bug.cgi?id=609777
Currently, activating a search result always opens a new window. Change
this behavior, so that if an application has open windows, the most
recently used one is activated instead.
Also change the implementation of dnd of search results to allow providers
to treat results activated via dnd differently.
https://bugzilla.gnome.org/show_bug.cgi?id=610027
Previously the banner was only promoted to the body if it got
truncated, but the banner was *always* hidden when expanding the
notification. This meant a message with a short banner, plus
notification buttons, would have no banner text visible when it was
expanded. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=606755
As desktop icons don't have any purpose in the overview (except for
distracting the user), fade them out when entering the overview.
Unfortunately, the fading effect affects performance, therefore hide
icons directly when there are maximized windows on the desktop.
https://bugzilla.gnome.org/show_bug.cgi?id=600999
This adds some meaningful functionality to the notification icons in the tray
and in the notification pop-up and allows to switch to the application that
sent the notification.
We get the application from the notification context and set it on the source
for the notification.
Replace the current workspace switcher popup (which is still the old metacity popup), with a clutter based one, which fits better into the overall shell design.
https://bugzilla.gnome.org/show_bug.cgi?id=609187
Currently the window-added and window-removed callbacks in
main.js:_onWorkspaceSwitched access the first parameter as metaWindow object,
but in fact the first one passed is the workspace (metaWorkspace).
Fix it by using the second parameter instead (which is a metaWindow object).
https://bugzilla.gnome.org/show_bug.cgi?id=609521
Currently the check in chrome.js checks if a window is on the
primary screen by checking its coordinates, width and height.
This check misses the case where windows just set
_NET_WM_FULLSCREEN without changing their position and
size (examples are Flash and ooimpress's presentation window).
Fix this by separating the check for fullscreen windows from the
override redirect one, and only check whether the window is
anywhere on the primary screen in the fullscreen case.
https://bugzilla.gnome.org/show_bug.cgi?id=597271
Currently the messagetray opens up everytime the user hits the bottom of the screen.
To avoid this "opening by accident" this patch changes the behaviour so that:
1) It only opens when there is a notification showing or
2) When the user hits the summary area (assuming he wants to interact with it)
Includes fixes from https://bugzilla.gnome.org/show_bug.cgi?id=607244#c17https://bugzilla.gnome.org/show_bug.cgi?id=607244
Make the framerate, file extension and gstreamer pipeline used by the
screencast recorder configureable using gconf.
This patch does not change the defaults, it justs provides a way for
the user to override them.
https://bugzilla.gnome.org/show_bug.cgi?id=608995
Animate an expanding ripple from the hot corner using multiple
scaling copies of a PNG of a single ripple. The idea here is to
give the user a clue as to what happened.
Based on initial version implemented live at MIT IAP GNOME Shell
intro session; thanks to all the attendees for coming!
https://bugzilla.gnome.org/show_bug.cgi?id=609135
The design document states:
"Animate the action as shrinking into or being consumed by the Activities Item"
This makes it clear what happens to the window (i.e it doesn't vanish but can be brought back by going to the overview).
https://bugzilla.gnome.org/show_bug.cgi?id=609079
We need to return the "thing that is being dragged" from
getDragActorSource() so that dnd.js can figure out the right
relationship between the dragged object and cursor.
https://bugzilla.gnome.org/show_bug.cgi?id=607351
- Handle non-uniform child heights properly - use a constant
grid size as the maximum of all child heights; with the
previous code, the children might not line up in the two
columns and the last item could be lost if the second column
was taller than the first column.
- Call set_skip_paint(child, false) on children that we do
want visible to override any previous hiding of that child.
- Correctly handle the DashDocDisplay not being allocated at 0, 0;
children should be allocated starting at 0, 0, not at origin
of the allocation box passed in.
- Remove an unused skipPaint variable.
https://bugzilla.gnome.org/show_bug.cgi?id=608801
- add some spacing between buttons
- move controls closer to the workspaces view (we'll need that space
for the message tray)
- fix the look of the scrollbar background
- adjust sizes of theme images
- some general CSS cleanup
https://bugzilla.gnome.org/show_bug.cgi?id=607872
This helps illustrate that expired notifications move to the summary view.
Animate the separate components of the message tray individually
as in http://www.gnome.org/~mccann/shell/mockups/20090630-demo
Based on the patch from Florian Müllner.
'workspace_relative' is used in workspace.js, not in workspacesView.js
Change a couple strings to have single quotes instead of double quotes to indicate that
they don't need to be translated.
When using the scroll wheel on the workspace indicators in single view,
make them use the same interpretation as the scrollbars: scrolling up
moves to the previous workspace, scrolling down to the next one.
https://bugzilla.gnome.org/show_bug.cgi?id=607824
Matching the 20091114 mockup, the default workspace view
is now a scrollable horizontal list, with a control to
switch between this and the previous grid view.
https://bugzilla.gnome.org/show_bug.cgi?id=593844
With the above preference set to true, the home and desktop entries
both represent the same location. Hide the desktop icon in that case
to avoid redundancy.
https://bugzilla.gnome.org/show_bug.cgi?id=606922
Added signal 'screen-size-changed' to ShellGlobal.
Connect to this signal in main.js and run the _relayout() method.
If Overview or calendar are visible when this signal emit, they will be hiding.
https://bugzilla.gnome.org/show_bug.cgi?id=584526
Make the event blocking done by Lightbox optional - leave it activated
when displaying the run dialog, but deactivate it when highlighting
windows in the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=602774
The run dialog crashes when PATH contains non-existing directories (some
distros seem to do that ...).
Fix by filtering those out before setting up file monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=606418
This bug happened because the thumbnail box was only maxed, not set to 256x256.
Standard window thumbnails would max out only the width to 256. Having a window with
its height greater than its width meant that the height would max out, but not the
width, causing thumbnails to look uneven.
https://bugzilla.gnome.org/show_bug.cgi?id=604963
Until now LookingGlass could only be closed using the Escape
key when the Evaluator class was active, as the relevant code
was associated to the text input field; this moves it into a
global event handler instead which works everywhere in LG.
We need to set the positions after the animation ends (and
fadeIn starts), not before when allocation is changed.
As the window may still be in motion when the overlay is
repositioned, it is safer to pass the calculated values
as parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=602598
Consumer documentation will live at http://live.gnome.org/GnomeShell/Extensions
In terms of implementation; basically we load extensions from the well-known
directories. Add a GConf key to disable extensions by uuid. There is a new
option --create-extension for the gnome-shell script which takes a bit of
interactive input, sets up some sample files, and launches gedit.
No extensions UI in this patch; that will come later.
https://bugzilla.gnome.org/show_bug.cgi?id=599661
The high level goal is to separate the concern of searching for
things with display of those things; for example in newer mockups,
applications are displayed exactly the same as they look in the
AppWell.
Another goal was optimizing for speed; for example,
application search was pushed mostly down into C, and we avoid
lowercasing and normalizing every item over and over.
https://bugzilla.gnome.org/show_bug.cgi?id=603523
The distinction between the inactive and running was silly; just
have one class which can handle both running states. However for
a future search patch, we do want a separation between an icon which
just has icon + name + glow, and a well icon which does the menu
integration.
https://bugzilla.gnome.org/show_bug.cgi?id=603523
We has poor performance if we try to allocate hundreds of actors;
a bit more ideally, we'd keep pulling as much as we can, but really
no one should have more than 50 in the list as is now except on
unreasonably large screen sizes.
In the future we should change this to be pull-on-demand thing
in a chunked fashion.
https://bugzilla.gnome.org/show_bug.cgi?id=603522
Rather of calling .exists() synchronously for all documents, use
ShellDocSystem's async API to only stat docs we're showing.
Use the doc opening functionality in ShellDocSystem.
Also, more intelligently do redisplay(); don't recreate actors
for recent docs if we already have one for that URI. We may
need more intelligent caching here; if e.g. just the associated
application changes, we should probably reread the info.
https://bugzilla.gnome.org/show_bug.cgi?id=603522
Previously we had various things watching for notify::mapped so
we could be more lazy about updating non-visible actors, but it
was fairly ad-hoc.
The deferred work system unifies these callbacks, and also adds
a timeout so that we don't delay changes arbitrarily; this way we
avoid a storm of work if you stay out of the overview for a while,
then go in.
https://bugzilla.gnome.org/show_bug.cgi?id=603522
The altTab.js and app well code weren't sharing really
any functionality anymore; un-merge the appIcon code back
into appWell, and have a simple icon + text display for
altTab.
Port AppWell to St and CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=602131
StClickable replaces ShellButtonBox. Reduce the number of
button-like things by deleting button.js.
To do so, add CSS style for the actitivies button.
https://bugzilla.gnome.org/show_bug.cgi?id=602131
It's nicer to have ShellDrawingArea as a St widget so it can
participate more cleanly in CSS styling, such as queuing a redraw
automatically on style changes, and allowing subclasses to use
CSS styling.
https://bugzilla.gnome.org/show_bug.cgi?id=602131
Some applications show a confirm dialog before closing, which the close
button happily ignores.
Detect newly created windows which are transient for the window we try to
close and switch to them.
https://bugzilla.gnome.org/show_bug.cgi?id=602532
We had previously been leaving the scaled workspace at a non-integral
position which didn't look obviously ugly, but now that we're
constraining the popup pane to the workspace size, we really need
to ensure that we're using integral positions here.
https://bugzilla.gnome.org/show_bug.cgi?id=601854
We need to check if the display actor is an instance of Shell.OverflowList
or St.BoxLayout to use the appropriate function for getting its child
with a given index.
Rather than the popup panes taking up the whole non-panel height,
constrain them to the height of the workspaces, which is also the
"dash content area".
https://bugzilla.gnome.org/show_bug.cgi?id=600734
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
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
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
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
For the purposes of determining which application is focused, don't
skip "uninteresting" windows. The old get_focused_window code
was used for usage tracking, but here we want reliable application
association.
Also convert a .text= to .set_text that was missed with the last
patch.
https://bugzilla.gnome.org/show_bug.cgi?id=599206
The two parts were mapping windows to applications, and
recording application usage statistics. The latter part
(now called ShellAppUsage) is much more naturally built on top of
the former (now called ShellWindowTracker).
ShellWindowTracker retains the startup-notification handling.
ShellWindowTracker also gains a focus-app property, which is
what most things in the shell UI are interested in (instead of
window focus).
ShellAppSystem moves to exporting ShellApp from more of its
public API, rather than ShellAppInfo. ShellAppSystem also
ensures that ShellApp instances are unique by holding
a hash on the ids.
ShellApp's private API is split off into a shell-app-private.h,
so shell-app.h can be included in shell-app-system.h.
Favorites handling is removed from ShellAppSystem, now inside
appFavorites.js.
Port all of the JavaScript for these changes.
https://bugzilla.gnome.org/show_bug.cgi?id=598646
Previously, we had ShellAppInfo, which contains fundamental
information about an application, and methods on ShellAppMonitor
to retrieve "live" information like the window list.
AppIcon ended up being used as the "App" class which was painful
for various reasons; among them that we need to handle window
list changes, and some consumers weren't ready for that.
Clean things up a bit by introducing a new ShellApp class in C,
which currently wraps a ShellAppInfo.
AppIcon then is more like the display actor for a ShellApp. Notably,
the ".windows" property moves out of it. The altTab code which
won't handle dynamic changes instead is changed to maintain a
cached version.
ShellAppMonitor gains some more methods related to ShellApp now.
In the future, we might consider changing ShellApp to be a GInterface,
which could be implemented by ShellDesktopFileApp, ShellWindowApp.
Then we could axe ShellAppInfo from the "public" API and it would
return to being an internal loss mitigation layer for GMenu.
https://bugzilla.gnome.org/show_bug.cgi?id=598227
If we had a pending search processing, finish it when the user
activates the entry.
This is a small conceptual change; the large diff is simply
moving the search implementation (unedited otherwise) from
an anonymous inline to a named function so it can be called
sanely in _activate.
https://bugzilla.gnome.org/show_bug.cgi?id=598111
POTFILES.in was missing some files.
"Activities" is not easily translatable into some languages, e.g. Russian,
so suggest using the word for "Overview" instead.
The down arrow is shown when an application with more than one
window is selected, but the window list is not always displayed.
This patch fixes the fact that the arrow was not hidden when one
focus an app with a single window when coming from an app with
multiple windows, if the window list was not displayed.
https://bugzilla.gnome.org/show_bug.cgi?id=597791
When we get a ClutterModifierType from Clutter, it might contain
bits not in the enumeration. See bug 59771 for a similar problem
with GdkModifierType.
Add a wrapper Shell.get_event_state() around clutter_event_get_state()
to mask these bits out and only return approved bits.
https://bugzilla.gnome.org/show_bug.cgi?id=597735
When tweening the overview in, tween it to appear on the correct
position of the primary monitor, not at (0,0); position
the 'backOver' actor to cover all monitors properly.
Reported by Rui Matos
https://bugzilla.gnome.org/show_bug.cgi?id=597721
Being able to display all applications in a category based on the search
string with a category name is generaly useful.
Prepare all the applications that match a search term based on their
category name up-front.
Remove unused this._appCategories and a call to non-existing
itemInfo.get_categories()
gdk_display_get_pointer() sometimes returns values for the mask that
aren't part of the GdkModifierType enumeration, which gjs doesn't like
(bug 597292). Work around that by adding a C wrapper that strips out
the extra flags.
https://bugzilla.gnome.org/show_bug.cgi?id=597559
Before we were badly leaking AppIcons by not disconnecting from the
window signal handlers when our actor got destroyed. This caused
us to repeatedly re-sort the windows for each AppIcon that
had ever been displayed with obvious bad consequences.
Besides simply chaining the signals to the lifetime of the AppIcon
actor, we also only do the sorting if we're mapped. This decreases
the amount of work to do in the not-mapped case.
https://bugzilla.gnome.org/show_bug.cgi?id=597120
Add a "size" parameter to allow changing the AppIcon size, and then
simplify the constructor by taking an object with parameters like
gobject-introspection constructors do, rather than taking a large
number of miscellaneous arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=597498
For some unknown reason we were connecting to app-added and
app-removed on ShellAppMonitor in the AppDisplay class, which
never made any use of the data. Simply don't connect to those
signals for now. In the future we should have AppDisplay
be using the AppIcon class which will more correctly handle
dynamic changes.
In the AppWell, avoid doing the full relayout until we're
actually mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=597169
Add String formatting by extending the String object with a
format method.
Now we can do stuff like "Text: %s, %d".format(somevar, 5)
This is required for proper translation of some strings.
https://bugzilla.gnome.org/show_bug.cgi?id=595661
This slightly changes the behaviour of the alt+tab window, this way:
when using alt-tab on a workspace that contains two or more windows from
the same window, the application selected when hitting alt+tab is the
currently selected application, but the highlighted window is the next
one.
Intended goal is to make it easier to cycle around windows of the same
application while not having to cycle through all the applications first.
https://bugzilla.gnome.org/show_bug.cgi?id=590563
By sorting the windows in the current workspace first, we ensure that
when using alt+tab to switch windows, we will pick a window on the
active workspace as the default focused window for the application if
the application has at least one window on the current workspace (that
is, if it is on the left of the app switcher separator).
This makes the behaviour of alt+tab more predictable for the user, as
an user will expect alt+tab to switch to the window he/she can see right
now rather than the one on the workspace he just left (presumably to do
something else on the workspace he's currently on).
https://bugzilla.gnome.org/show_bug.cgi?id=590563
