The setting in org.gnome.desktop.default-applications.at
has been removed, use the corresponding setting in
org.gnome.desktop.a11y.applications instead.
The setting in org.gnome.desktop.default-applications.at
has been removed, use the corresponding setting in
org.gnome.desktop.a11y.applications instead.
If you left the overview immediately after entering it (either
intentionally or due to a bug), the app menu would mistakenly end up
hidden due to flaky interaction between its show() and hide() methods.
Based on a patch by Dan Winship <danw@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=641117
When we have more thumbnails than can fit in the vertical space, scale
them down. This is implemented by using a generic container so we can
compute positions and sizes on the fly and do the appropriate
width-for-height behavior.
The usage of clutter constraints to position the indicator is droppped
since it less complicated to just position the indicator in the right
place ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
The scale we zoom to in the "zoomed out" mode depends on the width of the
controls area. Once we rescale the workspaces dynamically, we'll need to
update the zoom scale as we add and remove workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
We will change the workspace thumbnail size as we get more thumbnails; it doesn't
really make sense to always show 1/5 of the thumbnails how big or small they are,
so instead show a CSS-configurable length.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
Fix a bug in the computation of the zoomed-out scale and use a StBin
instead of an unnecessary StBoxLayout. Using the StBin will allow
correct width-for-height behavior for the controls.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
Add WorkspaceThumbnail.ThumbnailsBox to handle managing the array
of workspace thumbnails; the logic will get more complex as we add
scaling and animation.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
The settings in org.gnome.desktop.default-applications.at
have been removed, use the corresponding settings in
org.gnome.desktop.a11y.applications instead.
gsettings-desktop-schemas had two conflicting settings for showing
the magnifier: 'show-magnifier' in org.gnome.desktop.a11y.magnifier
and 'screen-magnifier-enabled' in org.gnome.desktop.a11y.applications.
The former has been removed in favor of the latter, so adjust to this
change.
Add the machinery to cancel the notification when a new playing a
new one (wrapping ca_context_cancel), then use it when scrolling
the status icon.
Not doing it for the slider because it causes noise, either with the
keyboard, with mouse drag or with mouse wheel.
https://bugzilla.gnome.org/show_bug.cgi?id=633667
The original icon doesn't exist, which results in empathy summary
items in the tray showing no icons (invisible) at all. With this fix
users can now at least see where the icons are (they are no longer
invisible).
https://bugzilla.gnome.org/show_bug.cgi?id=639468
As Main.overview is now usable from the view selector's constructor,
move the setup of signal connections there and remove the show/hide
methods which were used as workaround.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
To enable find-as-you-type when entering the overview and disabling
it when leaving, we used a chain of functions calls from ViewSelector
over SearchTab to SearchEntry. As find-as-you-type should be enabled
while the overview is shown, the activation/deactivation can be
handled entirely by the SearchEntry itself by tying it to the entry's
visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
As Main.overview is now usable from the dash's constructor, move
the setup of signal connections there and remove the show/hide
methods which were used as workaround.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
The Overview does not only hold the different elements visible in
the overview, but is also a central point to manage drag signals.
As objects which are constructed in the overview constructor cannot
access Main.overview (as its constructor has not finished yet), we
use misnamed show/hide methods to work around this limitation, which
are called when entering/leaving the overview.
A better way to handle this problem is to remove the limitation
altogether by splitting the overview constructor between internals,
which remain in the constructor, and more complex objects which
need to access Main.overview, and whose initialization is moved
to a public init() function which is called by main.js after the
overview has been constructed.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
This patch fixes the summary notification reappearing if you click on the
summary item to hide it and hover away. It also ensures that when you click
on any summary item which doesn't correspond to the summary notification
being shown, a new summary notification will replace it right away.
What used to happen is that we'd unset the clicked item in _unlock() that
was called when the focus was ungrabbed because the user clicked outside
of the summary notification, but then would have this._clickedSummaryItem
be null in _onSummaryItemClicked() , and set it to the clicked item all
over again. This patch ensures that we unset the clicked item only when
it is necessary.
We also needed to add the code to call _updateState() again to show a new
summary notification when a previous one was hidden, but
this._clickedSummaryItem was set.
https://bugzilla.gnome.org/show_bug.cgi?id=642005
Follow-up to commit 09717aae58 so
title changes also support markup instead of the ugly "<i></i>"
status.
Additionally, make sure to escape the contact's title as that
may accidentally contain unsafe markup or characters.
https://bugzilla.gnome.org/show_bug.cgi?id=642209
We were adding pango markup to the message in ContactManager.setPresence,
but weren't correctly marking the message as containing pango markup,
allowing for uglyness such as "User is <i>away</i>." being shown to the
user.
https://bugzilla.gnome.org/show_bug.cgi?id=642209
As the dash is one of the primary drop targets for dragging application
launchers, it's reasonable to use the dash icon size for app icons'
drag actors, especially with the larger size now used in the application
view.
https://bugzilla.gnome.org/show_bug.cgi?id=639428
