If we're dragging a window around and we need to reposition the windows,
due to e.g. the sliding in of the thumbnails or some other reason, then we
need to consider the original position of the dragged window, rather than
the currend drag position. Otherwise we will unnecessarily rearrange the
other windows for instance on snap-back if you moved the dragged window
past some other window.
https://bugzilla.gnome.org/show_bug.cgi?id=643786
We currently show the workspace in the overview in a rectangle
with the same aspect ratio as the screen. Originally this was
probably done since it showed the desktop, but we don't do this
anymore, and the positioning of the windows in the overview is
strictly a grid, so its not in any way related to monitor geometry.
Additionally, in the multihead case the screen aspect ratio is
very different from the overview monitor geometry, so a lot of
space is lost.
So, instead we just fill the entire inner rectangle of the overview
with the workspace. However, the way the zoom into and out of the
workspace right now is by scaling the workspace so that it covers
the entire monitor. This cannot really work anymore when the workspace
is a different aspect ratio. Furthermore the coordinates of the
window clone actors are of two very different types in the "original
window" case and the "window in a slot case". One is screen relative,
the other is workspace relative. This makes it very hard to compute
the cost of window motion distance in computeWindowMotion.
In order to handle this we change the way workspace actor positioning
and scaling work. All workspace window clone actors are stored in
true screen coordingates, both the original window positions and the
in-a-slot ones. Global scaling of the workspace is never done, we
just reposition everything in both the initial zoom and when the
controls appear from the side.
There is one issue in the initial and final animations, which is that
the clip region we normally have for the workspacesView will limit the
animation of the clones to/from the original positions, so we disable
the clip region during these animations.
https://bugzilla.gnome.org/show_bug.cgi?id=643786
When closing a workspace due to the last window on that workspace
closing, switch to the overview and show the always empty workspace
rather then just going to the adjacent workspace.
Based on a patch from Adel Gadllah <adel.gadllah@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=642188
During a drag-and-drop, our pointer grab keeps enter/leave events from
being delivered. That means that after the DND ends, whatever actor is
under the pointer won't have received the enter event it should have,
and any state or hover effect dependent on that won't work right.
By paying attention to the actors we leave and enter we can figure out
what widgets we need to call st_widget_sync_hover() on after the drag.
https://bugzilla.gnome.org/show_bug.cgi?id=640974
Showing the right click menu causes errors when ungrabbing focus in this case.
It will soon be impossible to get to the right click menu anyway when a new
notification is showing, because we are never going to show the summary
and the new notification at the same time.
Add Ctrl-Alt-Tab support to ViewTab, and fix the Applications pane to
scroll to track the keyboard focus.
The Windows pane can be switched to, but navigation within the pane is
not yet implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=618887
Fix the "panel" icon to be symbolic. Make the overview parts only show
up when in the overview, and the non-overview parts (eg, the Desktop
window, if there is one) only show up when not in the overview. Sort
the different items consistently with their locations on the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=618887
Unset this._expandedSummaryItem if it is the summary item that is being removed.
This avoids "this._sourceTitle.clutter_text is null" error.
Destroy the summary item actor only after calling _unsetClickedSummaryItem()
that disconnects from one of its signals.
https://bugzilla.gnome.org/show_bug.cgi?id=644043
PopupMenuManager was pretending that it knew nothing about the menu's
sourceActors, while also trying to handle keynav between them. This
was a big mess, and resulted in bugs in navigation between panel menus
and the Activities button, and it totally gets in the way when trying
to add keynav to the dash (whose menu sources are arranged vertically
rather than horizontally).
Fix this up by moving the panel-specific parts to PanelMenuButton
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=641253
It already doesn't work right, because the PanelMenuButton code
assumes that Left and Right won't be used as part of keynav within a
menu. And the gnome-panel calendar isn't keyboard accessible either,
so this isn't a regression. To be fixed later.
https://bugzilla.gnome.org/show_bug.cgi?id=641253
To deal with different CSS in RTL locales, we used to manually add
an :rtl pseudo class to some actors. With automatically assigned
:ltr/:rtl selectors this is no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=643835
CtrlAltTabPopup was using a St.BoxLayout and relied on anchor_gravity
center for positioning. This does not guarantee correct pixel alignment,
so use a St.GenericContainer instead and do the positioning similar to
that of the appSwitcher.
https://bugzilla.gnome.org/show_bug.cgi?id=643820
Make GSettings support optional, refactor text entry handling,
fix some off-by-one bugs in the management itself, use Params
for parsing, fix other typos and bugs.
https://bugzilla.gnome.org/show_bug.cgi?id=642793
Currently the icon texture is only updated on style changes when
the icon size is set from CSS and differs from the previously used
icon size.
As the style change may have been triggered by an icon theme change,
textures that are created for themed icons should always be recreated;
given that this is the case for most uses (with the exception of
file thumbnails), recreate the icon texture unconditionally to avoid
complexity.
https://bugzilla.gnome.org/show_bug.cgi?id=643738
Commit b1654af406 moved the panel positioning (and thus that of its
corners) before the panel startup animation. As the panel corners now
are mapped while the panel animation is active, the initial style-changed
signal which triggers another repositioning is received after the
initial layout and the corners end up at wrong positions.
To fix, animate the corner positions as well during the startup
animation - if anyone could actually see the animation, the corners
should animate with the panel anyway ...
https://bugzilla.gnome.org/show_bug.cgi?id=643804
Mutter really expects this, as this is how app-specified struts
happen. For instance, if the primary display is beside a taller
screen and is not positioned at the top, then we extend the struts
for the panel with the size of the unused area above the primary
monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
Right now we require a strut to be as wide as the full screen to
create a TOP strut. This means that in a multi-monitor scenario (at
least if the primary monitor is leftmost) we will make the panel strut
be Meta.Side.LEFT due to the random side picking for corner objects.
This changes the width/height comparison to the primary monitor rather
than the screen to get this right. Also adds some docs about how
struts work in a multi-monitor situation.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
We need to do the initial relayout before we start up the startup
animation, and the startup animation can't hardcode the position
of the panel to zero.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
1. disconnect destroy signals in popModal (actors can have great lifetime and then pushed again)
2. incorrect pushModal/popModal pair in overview
https://bugzilla.gnome.org/show_bug.cgi?id=64078
Increase the icon size of search results for consistency with the
application view. To account for the larger icons, only display
a single row of results per section.
https://bugzilla.gnome.org/show_bug.cgi?id=643632
Search results' meta info currently is expected to have an 'icon'
property holding a Clutter.Texture of a fixed icon size. This
property is used to implement the createIcon() function of BaseIcon,
which is used to actually display the result, ignoring the size
parameter due to the fixed icon size.
Given that all available search providers create this property for
the desired icon size using a function with the same signature, it
appears logical to replace the fixed-sized 'icon' property with
such a function, so that the icon size will be defined by the display
actor rather than the search system.
https://bugzilla.gnome.org/show_bug.cgi?id=643632
Currently section headers in the search view are reactive and run
the corresponding provider's expandSearch() function when clicked,
which should launch an external program displaying all search
results for the section. Unfortunately it is only implemented for
the "Settings" provider, and does not work properly (as it ignores
the search and just launches System Settings).
Also current mockups deemphasize the section header, making the
feature pretty much indiscoverable (except by accident when
interfering with swipe-scrolling).
In conclusion, the feature does not make much sense in its current
form, so remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=643632
Currently the total number of matches for a particular section is
displayed on the left of the section's header. While it made sense
in the old layout where it was close to the section's title, it is
now rather disconnected, and has been removed in current mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=643632
When UPower has not yet collected enough data to calculate a time
to discharge, it will report 0 minutes. Show "Estimating..." in
that case instead.
https://bugzilla.gnome.org/show_bug.cgi?id=642753
Currently we remove a workspace when last window on that workspace closes,
which turned out to be too agressive as some apps open either a splashscreen
or a "I have crashed last time" dialog at startup.
Try to detect such apps and give them a chance to open their "real window(s)"
on the workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=642188
_ungrabActor disconnects the event signal handler but does not
check whether it is connected before doing so which can result into
an exception like:
JS ERROR: !!! Exception was: Error: disconnect() takes one arg, the signal handler id
JS ERROR: !!! lineNumber = '0'
JS ERROR: !!! fileName = 'gjs_throw'
JS ERROR: !!! stack = 'Error("disconnect() takes one arg, the signal handler id")@:0
Unfortunately the evolution-data-server client-side libraries seem to
block the calling thread. This is a major problem as we must never
ever block the main thread (doing so causes animations to flicker
etc.). In the worst case, this problem causes login to hang (without
falling back to fall-back mode) and in the best case it slows down
login until a network connection is acquired.
Additionally, in order to sanely use these evolution-data-server
libraries, GConf has to be involved and GConf is not thread-safe. So
it's not really feasible just moving the code to a separate
thread. Therefore, move all calendar IO out of process and use a
simple (and private) D-Bus interface for the shell to communicate with
the out-of-process helper.
For simplification, remove existing in-process code since internal
interfaces have been slightly revised. This means that the shell is no
longer using any native code for drawing the calendar dropdown.
https://bugzilla.gnome.org/show_bug.cgi?id=641396
Signed-off-by: David Zeuthen <davidz@redhat.com>
See commit f2158218bef0c51 in mutter. Basically, we need
to grab org.freedesktop.Notifications before anything else
in the session gets started.
Note: I intentionally removed the Util.killall bits. I believe that
for notification-daemon at least, if we specify
DBUS_NAME_FLAG_REPLACE_EXISTING, we'll take over the name. Not sure
about notify-osd; if that's still a problem, then what we need to do
is add killing (and possibly respawning) of notify-osd to
"gnome-shell --replace", and not have it embedded randomly in a JS file.
https://bugzilla.gnome.org/show_bug.cgi?id=642666
The DBus JS binding will complain if the signature of a method
or of a signal is undefined, so we need to define it even if it
is an empty string, and we need to use the correct property name
for signals.
https://bugzilla.gnome.org/show_bug.cgi?id=643374
For applications with no proper desktop file, the window icon is
used as application icon in the tab switcher, but it won't have
the correct icon size. The current approach is to add additional
padding to these icons - the size turns out inconsistent with
other icons, but the icon appears sharp. For the dash it has been
decided that unsharp icons are less evil than differing icon sizes,
so icons are scaled up to the "right" size - for consistency, do the
same in the alt-tab switcher.
https://bugzilla.gnome.org/show_bug.cgi?id=643300
Mainly due to StTextureCache's way of handling fallback icons, an
implementation of BaseIcon.createIcon() may return an icon smaller
than the requested size. Given that BaseIcon is not used for isolated
elements, but rather for groups of related items (App view, Dash,
Search Results, ...), having some elements end up with the wrong
size is more annoying than having some elements end up ugly due to
scaling, so explicitly enforce the requested icon size.
https://bugzilla.gnome.org/show_bug.cgi?id=642043
As gnome-shell now switched to use the menu file from gnome-menus,
we no longer have direct control over category names. If such a name
contains unescaped markup, the shell will crash when trying to create
the filter label, so make sure to escape markup in category names.
Fix a typo in panel.js, and ensure that all variables used in
functions are scoped to the block (using let), to avoid polluting
the global namespace.
https://bugzilla.gnome.org/show_bug.cgi?id=643210
Rather than connecting to stage::capture-event and then trying to
guess whether or not a given key-press should be handled by us or not,
handle the end-search-on-Escape case from entry::key-press-event
(since it only makes sense when the entry is focused anyway) and the
start-search-on-printable-key case from stage::key-press-event (which
will only get the events that no other actor wanted for itself).
Similarly, do exit-overview-on-Escape and switch-panes cases from
stage::key-press-event, rather than
viewSelector.actor::key-press-event, so that they will work correctly
even if the keyboard focus is somewhere else. (Also fix a longstanding
bug in the pane-switching code, which was supposed to be disabled when
a search was active, but was checking a non-existent variable.)
https://bugzilla.gnome.org/show_bug.cgi?id=642502
The search entry was taking a sort of grab when it was in the
focused-but-empty state, and would eat up most events for other actors
(except, confusingly, for panel actors). The only bit of "modality" we
really need here is that the entry is supposed to go back to the
unfocused state if you click somewhere outside it when it was in the
focused-but-empty state. So do that.
https://bugzilla.gnome.org/show_bug.cgi?id=642502
The division of labor between the two was quite muddled. Rather than
try to invent a clean distinction of what belongs where, just merge
them together.
https://bugzilla.gnome.org/show_bug.cgi?id=642502
When the user cancels the drag while hovering over a window the timeout
handler will throw an exception because the drag actor will be destroyed
at this point.
Fix that by removing the timeout in _onDragEnd.
The xdnd timestamp gets updated on every xdnd-position event,
so while waiting for the window timeout to fire we need to make sure we
update the timestamp when getting on motion to activate the window
with the correct timestamp.
Commit 259c84ed9a refactored out HotCorner into its own class
and added this line and a variable, but it was left behind
when the variable disappeared in commit 7cf311dac0.
See https://bugs.freedesktop.org/show_bug.cgi?id=27788#c1 for details
about the problem this patch is solving
In particular, we should never bring up the dialog if there is no
password on the account. While this sounds like a weird corner case,
it's not.. the Live CD, for example, does not have a root password.
This also avoids the initial dialog resize.. before the patch the
authentication dialog appears and a split-second later an StEntry
widget is added.
Also print out more diagnostic information if showing the modal dialog
fails. Also add a comment about how to easily make this happen.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Currently the panel is positioned from main.js, move that code into
a method in panel.js instead and call it from main.js, which is
consistent with what we do for the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=643064
This is required since we can have chrome on multiple monitors (due to
per-monitor hot-corners).
Windows are primary associated with the monitor that their center is on.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
This is needed so that we can have several instances, one per
monitor.
This also makes the hot corner environments a container which
contains the corner.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
In the mockups the bottom border of active panel buttons is drawn
on top of the panel's border. To get this effect, move the panel
border into the background, so that it is not subtracted from the
vertical space given to the buttons. Adjust the drawing of the rounded
corners to reflect that change.
https://bugzilla.gnome.org/show_bug.cgi?id=643001
This allows PolicyKit applications to disambiguate between when the
authentication dialog is dismissed versus when authentication fails
(e.g. the wrong password has been entered).
See https://bugs.freedesktop.org/show_bug.cgi?id=30653 for more
information.
Signed-off-by: David Zeuthen <davidz@redhat.com>
We never get enter events anyway due to the menu code, and if
the user clicks on a non-menu the menu is removed and ungrabbed
before the target actor gets the event anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
Currently the menu has a hardcoded width which result into the hover
effect of the "Open Calendar" item being "cut off" in the middle rather
then reaching to the edge.
To be consistent with other menu items, make it expand to fill the available
space.
This is special menu item that can alternate
between two choices when you hit the alt key.
It will be useful for getting a hybrid
suspend/power off menu item.
https://bugzilla.gnome.org/show_bug.cgi?id=636680
PopupMenuManager relies on menus being added in the order of the
menu buttons they are attached to, so defer adding the user status
menu until the status icon menus have been added to make the manager
happy.
This patch modifies MessageTray behaviour so that normal (not urgent)
notifications are not shown when the user is Busy (they're sent
immediately to the Summary area). When status is then changed,
notifications still pending are shown again.
Additionally, when status is modified from Idle to anything other than
Busy, the message tray is forced open for 4 seconds, so that summary
icons are visible.
https://bugzilla.gnome.org/show_bug.cgi?id=617225
A PolicyKit Authentication Agent is a construct used to authenticate
one or more identities. See the PolicyKit documentation for more
details on authentication agents and how PolicyKit works:
http://hal.freedesktop.org/docs/polkit/
Since gjs does not support subclassing a GObject class from Javascript
code, we bring in a native class to bridge the VFuncs to GObject
signals. Additionally, this native class also queues up authentication
requests so the user of the native class only has to deal with a
single outstanding request at any one time.
The file js/ui/polkitAuthenticationAgent.js introduces a singleton
that listens for authentication requests via the native class. This
singleton uses the PolkitAgent machinery to do the actual heavy-weight
lifting required for authentication (essentially a PAM conversation).
We currently don't allow the user to pick the identity to be
authenticated.
https://bugzilla.gnome.org/show_bug.cgi?id=642886
Signed-off-by: David Zeuthen <davidz@redhat.com>
Complex popup menus require the ability to manager sequences of items
as "sections", to which you can add and and remove items, as well
as hide and show.
PopupMenuSection does exactly that, leveraging the existing machinery
for submenus, but without being exposed as a submenu to the user.
Also, make getMenuItems() private, since it is used for different things
now and may change semantics in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=621707
Make all subclasses of PopupMenuBase accept a params argument, which
can be used to make the item non reactive, not responsive to hover
and, as a new feature, with a different style class.
https://bugzilla.gnome.org/show_bug.cgi?id=621707
If the Shell is started with HighContrast enabled, it will never
see another value for the GSettings keys. In that case, we just
reset to the default.
https://bugzilla.gnome.org/show_bug.cgi?id=642641
We need the view selector to extend all the way to the right edge of the
monitor, so size and position the view selector in a way that the sum of
its X position and its width add up to the primary monitor width.
https://bugzilla.gnome.org/show_bug.cgi?id=642834
So far transitions do not work for the custom drawn corners, so to
avoid a visible glitch when transitioning a button in the panel corner
while updating the style of the apparently attached corner instantly,
remove transition of those panel buttons until we make it work for the
custom drawn parts as well.
https://bugzilla.gnome.org/show_bug.cgi?id=642697
Current mockups show the panel curving downwards at the edges to
frame the work area and look awesome. Implement those as separate
actors to not affect the struts set by the panel, and synchronize
their state with the corresponding panel buttons so they blend in
with the panel. It might be worth considering whether the corners
should be hidden with maximized windows on the current workspace,
though this might affect the illusion of them being part of the
panel. As the corners don't affect the input region, the small
overlap with windows might not be too bad after all.
https://bugzilla.gnome.org/show_bug.cgi?id=642697
The groups at the panel sides use different left/right padding, so
a slightly different CSS is required for RTL locales. Add :rtl
pseudo classes as necessary and adjust the CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=642697
We now use a border image on active panel buttons to underline the
button's content. As the property does not affect the content's
allocation, the app icon ends up being drawn on top of the border
image. To prevent this, use a custom property to clip the bottom of
the app icon when the button is active.
https://bugzilla.gnome.org/show_bug.cgi?id=642697
While related to the status area, the user status button is clearly
not a status icon, and it does not make too much sense in
startStatusArea(), which is about filling the status area with
icons. Also, the status icon container is added to the panel in
the constructor, in fact, the user status button is the only "toplevel"
panel element which is initialized elsewhere. Not a crucial change,
but makes for a nice read anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=642697
When we are dragging a window over its current workspace or workspace
thumbnail, we show show "no drop possible" feedback instead
of "move here" feedback.
https://bugzilla.gnome.org/show_bug.cgi?id=642329
We don't necessarily get a syncStacking call when an actor is added
at the top of the workspace, so make sure to set the stackAbove value
for it correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=642329
'Search your computer' is problematic for various reasons:
- it specifies the kind of device
- it focuses on local search (while we also do web search)
- it does not advertise the instant search functionality
Change the hint text to 'Type to search' as proposed by Allan Day.
https://bugzilla.gnome.org/show_bug.cgi?id=642287
This starts saving lookingGlass history in gsettings, and also adds
the ability to clear the text field by pressing 'down' on the last
entry, like the run dialog and readline allow.
https://bugzilla.gnome.org/show_bug.cgi?id=642237
runDialog and lookingGlass both implement a home-made history
manager, each working slightly differently than each other in
behavior and implementation.
Extract the behavior and implementation from runDialog, which
reads and saves to GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=642237
We try to position the boxpointer centered above the calendar,
which swaps position with the events list when using a RTL locale,
so make the menu alignment dependent on the text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=642721
As the dash uses different widths and radii for left and right
borders, we need to use different CSS when it is positioned at
the right of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=642721
- When tweening a workspace to collapse it, round the multiplied
height so that we don't change other workspace sizes via rounding
differences.
- Use separate horizontal and vertical scales, so that every thumbnail
has the same horizontal scale.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
Allow defining a "porthole" that is the visible area of a workspace
thumbnail, and use this to clip the portion under the panel off the
workspace thumbnails. (This is wrong for fullscreen windows, but not
very wrong, and hopefullly the few missing pixels will be
unnoticeable.)
https://bugzilla.gnome.org/show_bug.cgi?id=641880
Because the overall parent allocation width immediately when the workspace
count changes, we were sometimes drawing the indicator in the wrong place
in the indicator animation that proceeded the remove-workspace animation.
Fix this by tweening only the Y position of the indicator and computing
the X position and size in our allocate() method. This also is considerably
simpler than switching the indicator between fixed position and geometry
managed.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
Rather than killing the workspace indicator indicator when we remove
workspaces because the source and target locations might have changed,
do it as a separate first step. This provides a better explanation
than doing it simultaneously with the addition/removal or not at all
and also keeps our computations simple.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
When we animating the scale for the thumbnails, the border and
background should wrap around the current size of the thumbails.
The technique that we are using to animate the scale breaks that
since we don't animate the overall size of the thumbnails box -
we just animate our child actors within the allocation.
To fix this, switch from drawing the background by packing in another
container to drawing the background with a separate actor that
is under the other actors and allocated by our custom logic.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
To explain to the user what is happening, instead of abruptly changing
updating the workspace thumbnail list, slide thubmnails in and out
as they are added and removed.
To implement this, we track a state for each thumbnail and when things
change go through a process of first sliding removed thumbnails out,
then ollapsing the left-over spaces and rescaling the thumbnails, then
finally sliding newly added thumbnails in.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
For historical reasons, StEntry always did hover tracking when you had
visible hint_text, even if track_hover was FALSE. Remove that special
case, and make entries track hover just like all other widgets do.
If we actually needed to distinguish hovered-with-hint-text from
hovered-without-hint-text (which, at the moment, we don't), we could
do that by setting separate CSS for :hover and :hover:indeterminate.
https://bugzilla.gnome.org/show_bug.cgi?id=642483
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
