A pressure barrier is a barrier that activates after the user pushes
against the bottom of the screen in a short time. Implement this using
the new XInput 2.3 features that provide extended information about
pointer barriers, and use it so that pushing against the bottom of
the screen edge brings up the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
As pressure barriers need a signalling mechanism to provide
information about when and where they are hit, an object which
provides a signal is a more appropriate abstraction for a pointer
barrier than a functional ID-based approach. Mutter has gained
pointer barrier wrappers, so use its objects instead of ours.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
If the screen lock is enabled, lock the screen before suspension.
When using systemd, this will cover both explicitly suspending from
the user menu and suspension initiated by g-s-d (lid close, power
button).
https://bugzilla.gnome.org/show_bug.cgi?id=686482
While it is possible to keep track of removed sources by tracking
their summary items' actor:.destroy signal, a dedicated signal
mirroring the existing 'source-added' one is more convenient.
https://bugzilla.gnome.org/show_bug.cgi?id=693220
The panel used to provide an .in-overview class which was removed after
the theme stopped using it. Classic mode should use a different top bar
style in the overview, so bring it back (but use a pseudo class this
time for consistency with MessageTray and ActivitiesButton).
https://bugzilla.gnome.org/show_bug.cgi?id=693218
LTE-only modems need to be treated as GSM/HSPA modems, as they all are 3GPP
modems and they all need the same kind of configuration (APN, user, password,
PIN...).
https://bugzilla.gnome.org/show_bug.cgi?id=688144
ModemManager >= 0.7 comes with a new DBus interface. This patch makes the shell
work with the new interface if the modem is detected as being exposed by the new
ModemManager (based on the device.udi string reported by NM).
https://bugzilla.gnome.org/show_bug.cgi?id=687359.
Gnome session started to track the session's active state a while
ago, so use that instead of our own ConsoleKit/logind abstraction
in LoginManager.
https://bugzilla.gnome.org/show_bug.cgi?id=693161
Now that we have an explicit active-but-not-locked state, we should
use different signals to notify changes. lock-status-changed is
renamed to active-changed, and a new locked-changed is introduced.
https://bugzilla.gnome.org/show_bug.cgi?id=693007
While we handle the case where ibus_bus_get_global_engine() returns
NULL, this case actually generates an exception we have to catch to
avoid some (harmless) console spam.
https://bugzilla.gnome.org/show_bug.cgi?id=692995
In time span between idle and lock the shield should behave like autologin,
but should prevent accidental reactivation (for example when using a touch
screen) by showing the curtain.
https://bugzilla.gnome.org/show_bug.cgi?id=692560
gnome-settings-daemon wants to use ActiveChanged to drive screen
blanking policies.
I also added two big comments that should cover all cases, to clear
up what's happening when the idle timers fire.
https://bugzilla.gnome.org/show_bug.cgi?id=691964
We must remove music notifications before we're destroyed, otherwise
they get destroyed with us.
Also, integrate a review comment I previously forgot.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
Some notifications, despite being emitted by shell code, should appear
to be from application or "separable" system components. Do that by
associating them with a notification-daemon policy.
Note that for this to look really good, empathy should rename itself
to Chat.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
The designs says that only music notifications should be shown in full
in the screenshield, the others should be either shown as a summary or
with very light details.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
Allow message tray sources to provide a NotificationPolicy object,
that will configure how and if the source is displayed. For notification
daemon sources, this object is hooked to GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
Use the new Hash.Map class, and store signal connections along with
the source and summaryItem. This allows to remove sources without destroying
them.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
syncSectionTitle looks at device list for the section, to understand if
the section should be visible or not, so obviously it needs to see the
new device.
I wonder when this broke.
https://bugzilla.gnome.org/show_bug.cgi?id=692749
During the box pointer animation, other events can trigger an updateState,
losing the information that the summary is hiding and thus never disconnecting
the signals. Then, this stale connections can cause stacktraces, as they
fire when summaryBoxPointerItem is null.
https://bugzilla.gnome.org/show_bug.cgi?id=692693
Hiding notificationWidget with a telepathy notification causes
unfocused to be emitted, which causes a reentrant updateState.
If another notification is queued, it is shown before the old
one is cleared.
https://bugzilla.gnome.org/show_bug.cgi?id=683986
The two classes have been gaining each other's functionality for a little
while, adding the new code wherever it was more convenient. Rather than
have a clear delineation between "This Manages Shell Chrome" and "This
Manages Shell Layout", I think it's better off if we just accept that
the responsibilities are pretty much the same.
https://bugzilla.gnome.org/show_bug.cgi?id=692677
In the overview, when there is no text in the search entry, this._searchActive
will be set to false. Moving the Clutter.Return code block ensures that
pressing enter in the search field after deleting the characters of a search
will no longer launch the #1 application for the previous search.
https://bugzilla.gnome.org/show_bug.cgi?id=692391
gnome-control-center is planning on removing its own tree in the
future. Since it already installs these applications into
/usr/share/applications, just use this for now.
https://bugzilla.gnome.org/show_bug.cgi?id=692483
The one we had before could make unmaximized windows appear to be bigger
than maximized ones, for a few reasons. Ensure that this doesn't happen
again, and add some comments to explain the whys and needs for twiddling
the individual thumbnail size.
https://bugzilla.gnome.org/show_bug.cgi?id=686944
We clamp the overall layout's scale to WINDOW_CLONE_MAXIMUM_SCALE, but since
we do a bit of tweaking to try and make super small windows a tad larger, it's
theoretically possible that windows may become larger than the proper maximum
scale. Fix this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=686944
On large displays, we don't want the search results list to expand
across the whole screen; set a maximum width of 1000px.
Unfortunately, since in St max-width only affects size requisition, we
need a little custom layout manager to have it applied to the allocation
too.
https://bugzilla.gnome.org/show_bug.cgi?id=692453
'active' isn't terribly clear about just what is active; also, make it
private, remove an useless extra object state we were saving, and
refactor some messy code.
Based on a patch by Tanner Doshier.
https://bugzilla.gnome.org/show_bug.cgi?id=692454
In a gdm session, we may not know what mouse orientation the user
may be in, so it makes sense to support both the left and right
mouse buttons to activate login or other items.
Additionally, add the behavior to all modal dialog items, even in
a user session, because it's unlikely that the user will right-click
on buttons, and it makes for an easier implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=688748
These were lost when we moved away with StIconType. The idea was that
apps needed to include -symbolic in their action IDs, but apps were
not updated, and it never makes sense to have non symbolic icons there,
so let's restore the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=692091
This fixes the image and scrollbars peeking through in banner mode,
because StTable wasn't able to allocate them at the restricted height
imposed by CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=692091
We must set the image after calling .update(), because we're passing
clear: true and thus we're removing the image too.
Also, we need to specify an explicit icon size, or St.Icon will use
the default (48px)
https://bugzilla.gnome.org/show_bug.cgi?id=692091
destroy() checks if we are visible to decide whether to destroy the
actor immediately or after a fade out animation. Since actors are
visible by default it would always end up destroying only after the
animation time.
https://bugzilla.gnome.org/show_bug.cgi?id=691963
If nothing references the idle monitor, it can be finalized at GC,
causing it to have no effect. Worse, if the finalization happens at
wrong time, the pointer watcher can be permanently off, disabling the
message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=691976
Switching style on Overview::hiding creates a weird effect, as the noise
texture is shown while the overview is still visibile. Instead, wait for
the tray to be fully hidden, then apply the new style.
As now the switch is invisible, there is no need for the transition
(which introduced the same problem on overview showing)
https://bugzilla.gnome.org/show_bug.cgi?id=689091
Add an style class targetting workspaces located outside the overview,
and use it for extra padding around the window clones. Padding is passed
down and applied inside LayoutStrategy, consolidating code that previously
handled the bottom side only.
https://bugzilla.gnome.org/show_bug.cgi?id=690171
The "flash" effect looks awkward when it fades in and out. Real
camera have an immediate flash of light, which then seems to fade
out as our eyes readjust the rapid change in lighting.
https://bugzilla.gnome.org/show_bug.cgi?id=691875
This is similar to how the dateMenu already allows opening the calendar
application. However, the new entry only appears if GNOME Clocks is
installed, as it is not a core GNOME application.
https://bugzilla.gnome.org/show_bug.cgi?id=644390
NM 0.9.7 is still not released even as a tarball, so fix this to work
with 0.9.6 again for now (although it doesn't do any device name
disambiguation in this case now).
https://bugzilla.gnome.org/show_bug.cgi?id=691720
If the setting is enabled, we record the last activated input source
for the currently focused window and switch to it when focusing back
that window. The Overview is considered a window for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=691414
The current code parses the button-layout setting because MetaButtonLayout
was not usable from introspection. With that fixed, we can switch to
using meta_prefs_get_button_layout().
https://bugzilla.gnome.org/show_bug.cgi?id=689263
Due to limitations and bugs in SpiderMonkey's GC, wrapper objects
for cairo contexts and similar may not get cleaned up immediately
after repainting, leading to leaking memory. Explicitly disposing
of such objects after they're not needed can clean up large portions
of memory for cairo surfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=685513
With panel buttons changing dynamically on session mode changes we can
no longer rely on a corner's respective box style-changed signal to
find the nearest button.
Instead, make the panel take care of telling the corners to look for a
new button when buttons are changed.
https://bugzilla.gnome.org/show_bug.cgi?id=690180
Acting on each Show/Hide DBus call immediately may cause a lot of
jittery movement when Alt+Tabbing or even just switching tabs in
e.g. gnome-terminal.
To make the OSK feel sturdier, we wait a bit before actually showing
or hiding it so that we can coalesce tight sequences of Show/Hide
calls. I.e. the last call wins which means that we might end up not
doing anything.
https://bugzilla.gnome.org/show_bug.cgi?id=688646
We can't pushModal() when showing the subkeys popup because that will
cause the application to lose focus and thus we get a Hide() call for
the whole OSK.
Instead, capture events on the main OSK actor while the subkeys popup
is shown so that we can both prevent events from reaching the main
keys but also cancel the subkeys if the user clicks away in the OSK.
https://bugzilla.gnome.org/show_bug.cgi?id=674955
Since we're breaking API already, take this as an occasion to use a
separate interface for all the screenshot-related methods. The interface
name is org.gnome.Shell.Screenshot.
Internally, move all the related code to screenshot.js.
https://bugzilla.gnome.org/show_bug.cgi?id=688004
Since we also support passing a basename now, clients might be
interested in knowing the path used to save the file.
Add an out argument to the interface for that.
https://bugzilla.gnome.org/show_bug.cgi?id=688004
If a non-absolute path is passed to the screenshot methods, treat it as
a basename for the output image, and automatically try to save it in
$XDG_PICTURES_DIR, falling back to $HOME if it doesn't exist.
https://bugzilla.gnome.org/show_bug.cgi?id=688004
The screensaver schema has a key that it is meant for locking down
the ability to switch user when the screen is locked, but support
for it was not implemented in the new screenshield.
Fix that by checking the key before creating the button.
https://bugzilla.gnome.org/show_bug.cgi?id=691042
When you click Suspend from the user menu, the following things happen:
- we lock the screen internally by calling Main.screenShield.lock() and waiting
for lock-screen-shown
- logind emits a Lock signal, which causes us to lock again
- gnome-settings-daemon notices PrepareForSleep, and calls org.gnome.ScreenSaver.Lock,
just in case, so we lock once more
This means that, if you're lucky, you can see the curtain fall down multiple times,
as each .lock() call resets the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=690858
It's common to do actor.grab_key_focus() before the actor is mapped
which means that we can't reliably determine where the actor is at
notify::key-focus time and thus might end up showing the keyboard on
the wrong monitor.
This is happening, in particular, with the run dialog. Delaying until
we hit the main loop allows us to know where the actor finally is
before showing the OSK.
https://bugzilla.gnome.org/show_bug.cgi?id=685856
Rather than add invalid results to the place where you enter JavaScript
commands when you use the eyedropped, add an inspect() function and add
a fake call to it.
https://bugzilla.gnome.org/show_bug.cgi?id=690726
org.gnome.desktop.screensaver.lock-delay contains the grace period
of the screensaver: if deactivated within that many seconds from the
start of the idle period, the shell should not prompt for a password.
This setting correspond to the "Lock screen after" combo in screen
and privacy panels.
https://bugzilla.gnome.org/show_bug.cgi?id=690766
Use the new meta_window_check_alive() to verify if the application is
responding after the user activates an action from the app menu.
This in particular restores the ability to force quit applications
from the menu, even if the use a custom GMenu.
https://bugzilla.gnome.org/show_bug.cgi?id=684340
Calculate an icon based on our current state, not a mess of
signal emissions and callbacks. This is a preliminary basic
cleanup patch in preparation for the next one.
https://bugzilla.gnome.org/show_bug.cgi?id=690539
Instead of faking it by adding a bunch of main icons and secondary
icons to our own box, try and recreate the original button box
with the original icons.
https://bugzilla.gnome.org/show_bug.cgi?id=690589
As we may be flipping the box pointer in response to re-allocation,
like the addition of a new actor to the boxpointer, we can't queue
a re-layout while in a re-layout, so defer.
https://bugzilla.gnome.org/show_bug.cgi?id=690608
Depending on the current state of arrowSide, the box allocation may be
wrong; e.g. if the user requested a TOP, but we flipped to a BOTTOM, the
next request would look to the y2 value of the flipped BOTTOM, which is
wrong.
Instead, use the origin, plus the calculated preferred size of the box.
https://bugzilla.gnome.org/show_bug.cgi?id=690608
Make sure we re-allocate after we flip sides, to ensure that
padding around the child actor is updated correctly. Additionally,
ensure that we flip after we setPosition, as we won't get re-allocated
auotmatically by just changing the position.
https://bugzilla.gnome.org/show_bug.cgi?id=690608
Given that it's modifying state, there's no reason it can't be
using it instead. This makes it easier to use, so we aren't passing
in a bunch of instance variables every time.
https://bugzilla.gnome.org/show_bug.cgi?id=690608
Allow users to smoothly scroll on the volume indicator icon
to adjust the volume. Do this by simply passing the scroll
event to the slider inside the menu.
https://bugzilla.gnome.org/show_bug.cgi?id=687573
After the first time the title was placed, we were setting its width,
thus forcing get_preferred_width() to return that as the minimum and
natural width.
To workaround that, explicitly reset the width to -1, -1, causing
StLabel->get_preferred_width() to be called, which would give us a meaningful
value for minimum and natural width.
https://bugzilla.gnome.org/show_bug.cgi?id=688234
WindowOverlay was at times seeing bogus values reported as WindowClone
sizes. Fix that by storing and passing the value from the authoritative
source, that is, the LayoutStrategy.
https://bugzilla.gnome.org/show_bug.cgi?id=688234
If present, InfiniBand devices show up with the ethernet devices (and
the presence of an InfiniBand connection will cause "Wired" to be
renamed to "Ethernet").
https://bugzilla.gnome.org/show_bug.cgi?id=677150
Both WorkspacesDisplay and ThumbnailsBox need to know when windows have been
restacked. Instead of each tracking changes on their own or trying to call
each other, have the overview keep track and do the calculations, emitting
a signal with the result.
https://bugzilla.gnome.org/show_bug.cgi?id=690175
meta_display_add_keybinding() returns a keybinding action ID for
dynamically registered keybindings which can be used to match a
keycode/mask pair to the action it is bound to.
https://bugzilla.gnome.org/show_bug.cgi?id=682315
Instead of storing them globally and having an hardcoded list of
engines which are allowed to change their indicator symbol when the
InputMode property changes.
https://bugzilla.gnome.org/show_bug.cgi?id=682318
We previously scaled windows to (primary.x, 0), which is wrong if the
primary monitor is not at y == 0. At the same time, change the policy
to pick the hot corner on the monitor the window is on, because that's
closest to where it will appear in the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=690241
This makes the method usable in places where the associated window actor
might not have the right size (such as from window manager animations).
Also, make the method public from LayoutManager.
https://bugzilla.gnome.org/show_bug.cgi?id=690241
If we overwrite a map animation (for example because the actor is now destroyed),
we need to complete it first, otherwise it starts off from a random
middle point. This is the same treatment opacity gets for normal windows.
https://bugzilla.gnome.org/show_bug.cgi?id=690241
The thumbnail controls are not a separate actor in the overview group
yet, so we need to ensure a spacing between them and the workspaces
view.
Instead of exporting the overview spacing, just add a temporary style
class to the workspaces-view actor for it. It will be removed in the
future when we change the layout of overview elements.
https://bugzilla.gnome.org/show_bug.cgi?id=690174
Adjust the layout of the overview and window thumbnails to make them
bigger. Also, make the background shade darker to compensate for the
increased thumbnail density.
https://bugzilla.gnome.org/show_bug.cgi?id=689876
Recreating icons on every style change -- like hover, can have
disasterous effects. Not only is the quick creation/destruction of
the actors bad, but adding/removing actors at runtime queues many
relayouts, which makes the whole system slower as a lot of unnecessary
reallocations are figured out.
While an optimization was here before, it was broken because it
broke high-contrast themes. Connect explicitly to the texture cache
to know when the icon theme has changed, instead of removing a valuable
optimization.
https://bugzilla.gnome.org/show_bug.cgi?id=672941
The message tray actor also includes notifications themselves. We want
our ghost to be sized as the base part of the tray instead.
Just make sure to use the same style class as the base actor then, as
its height is specified by the CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=690174
The new privacy panel offers separate settings for the user name
visibility in lock screen and normal mode. The code to support
either setting is already in place, but we need to make sure to
update the user name on session mode changes to pick up the correct
one.
https://bugzilla.gnome.org/show_bug.cgi?id=690049
This is causing more confusion than anything else these days; the DBus
API is properly documented now and that's what people are expected to
use, the rest are implementation details we're not interested in
exposing.
https://bugzilla.gnome.org/show_bug.cgi?id=681797
These are for all search results except apps (and Wanda).
We also simplify a bit the packing of search results, which removes some
ugly code in navigateFocus() where we needed to call
st_widget_navigate_focus() twice, since the grid icon was composed by
two nested boxes, both focusable.
https://bugzilla.gnome.org/show_bug.cgi?id=681797
Display a '+' icon on the provider icon if there are more results that are
hidden. If the provider icon is clicked, ask the provider to launch itself and
perform a search with the current terms.
https://bugzilla.gnome.org/show_bug.cgi?id=681797
When pressing the overlay key three times, things went like this:
* show(), push a modal
* hide(), will pop a modal after hiding is done
* show(), push a modal
Thus, when the showing is done, and then it activated the hiding,
it popped one modal, but not the other. This patch changes things
to be:
* show(), push a modal
* hide(), will pop a modal after hiding is done
* hide(), no-op
That is, mashing the overlay-key when it's showing will always make
it hide, not mashing an odd number of times.
https://bugzilla.gnome.org/show_bug.cgi?id=688589
BoxPointer's API changed to take a BoxPointer.PopupAnimation
enumeration value, but the code was accidentally replaced with
older code when porting the PopupMenuManager code to GrabHelper.
https://bugzilla.gnome.org/show_bug.cgi?id=689954
"toggle" is used when clicking on the source actor. As we don't
actually have a menu, we don't want to actually take any grabs
through the menu system, so make it a no-op rather than have it
toggle the menu state.
https://bugzilla.gnome.org/show_bug.cgi?id=689954
This is necessary for child popups in menus, e.g. while in a combo box,
clicking outside of the user menu should drop the entire menu, but
clicking on the user menu itself should only drop the combo box.
https://bugzilla.gnome.org/show_bug.cgi?id=689109
I have no idea why we used 'event' rather than 'captured-event' before.
'event' has some really strange quirks that came up when porting PopupMenu
to the GrabHelper
https://bugzilla.gnome.org/show_bug.cgi?id=689109
this._gnomecc is currently unused; we actually need a GAppInfo for this
provider if we want to display an icon next to it (see future commits),
so just turn it into one.
We might move this to an external provider altogether in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=689735
This allows us to fix the shortcomings of the original ActivateResult()
method. In particular:
- allow to pass the search terms to the provider
- allow to pass a user interaction timestamp
https://bugzilla.gnome.org/show_bug.cgi?id=689735
The only case when we're interested in using those parameters nowadays
is for DnD, which is handled in a separate method already.
Since we're not going to support DnD for non-app search results anyway,
drop the params from all the activateResults() calls; this will be
useful later since we're going to add another parameter to it.
https://bugzilla.gnome.org/show_bug.cgi?id=689735
We read the implemented version from the search provider's keyfile, and
then create a RemoteSearchProvider object from the right class
accordingly.
Wire ActivateResult() to the new method (without actually passing the
new parameters along) - an actual implementation will be added in a
future commit.
https://bugzilla.gnome.org/show_bug.cgi?id=689735
Defining a mode that differs significantly from the default one
can get rather cumbersome. For convenience, allow mode definitions
to inherit from an existing mode.
https://bugzilla.gnome.org/show_bug.cgi?id=689308
As currently envisioned, the fallback replacement in 3.8 should be
a separate session at the login screen. As we will use extensions
to implement this mode, we need a way to specify extensions per
session rather than per user, so add a session-mode property for
extensions that should be loaded in addition to the user-defined
ones.
https://bugzilla.gnome.org/show_bug.cgi?id=689305
Currently adding a new session mode requires patching the sources.
As defining custom modes can be desirable in some circumstances
(for instance for administrators of kiosk setups), load additional
modes from JSON files.
https://bugzilla.gnome.org/show_bug.cgi?id=689304
Now that we use the new 'switch-applications' keybinding for the
application-based alt-tab popup, we can use the 'switch-windows'
keybinding for a more traditional switcher.
Based heavily on the alternate-tab extension from Giovanni Campagna.
https://bugzilla.gnome.org/show_bug.cgi?id=688913
The Shell's alt-tab popup is application-based, so using the
'switch-windows' keybinding for it never really made sense.
Use the newly added 'switch-applications' keybinding instead.
https://bugzilla.gnome.org/show_bug.cgi?id=688913
If the chosen action is not open, the tray should not be closed, to
let the user further interact with it (for example to mute or remove
more sources)
https://bugzilla.gnome.org/show_bug.cgi?id=689296
This is meant to expose the global.session_mode to applications such
as the gnome-tweak-tool, which would need it to differentiate between
the vanilla GNOME Shell mode and the fallback replacement mode.
https://bugzilla.gnome.org/show_bug.cgi?id=689300
Currently we assume that either the initial sessionMode will have
the overview or none of the pushed modes - starting without the
overview and pushing a mode that adds it fails spectacularly.
However this is exactly what we are going to do when loading external
modes asynchronously - we'll initially use the default mode while
the modes are loading, and switch to the mode passed on the command
line when finished. So make sure that the overview UI gets initialized
properly in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=689304
Since commit 0c807bddaf, the run dialog no longer handles Escape
key presses itself but uses the action key mechanism of modal dialogs.
As the latter uses key-release events, our own handling of the Escape
key runs on key-press.
Fix this by bailing out early if anything has pushed a modal in addition
to the overview (like system modals, looking glass, ...).
https://bugzilla.gnome.org/show_bug.cgi?id=688196
Invalid ID errors from that function are normal, because the set
of IDs to acknowledge may not match the set in the connection manager
due to race conditions.
This is also what empathy does.
https://bugzilla.gnome.org/show_bug.cgi?id=683449
MessageTray._tween sets the state variable to the in-progress value,
so it must be sure that at the end of the animation the value will
be the corresponding final and nothing else will happen in between.
https://bugzilla.gnome.org/show_bug.cgi?id=683986
Since the introduction of overlay hover borders, there has a been
a timing disconnection between hiding the border and button, and
this creates noise and reduces the effect of the window+overlay
as a single unit.
Solve that by animating the close button too, so that the two actors
are shown and hidden always at the same time.
Also, consolidate the code to make it clear to future authors that
those two items need to stay coordinated.
https://bugzilla.gnome.org/show_bug.cgi?id=688966
Turns out that tweener has a very complex logic to decide when a new
tween on the same properties overrides completely the old, and unfortunately
what we were doing was not enough in all cases.
Just be explicit, and don't let anything else mess with the state.
https://bugzilla.gnome.org/show_bug.cgi?id=688895
On additional monitors the workspacesView takes up the entire monitor
and in some cases windows in overview can end up hard against the
edge of the monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=688133
The panel should change appearance according to the sessionMode,
so add a new panelStyle sessionMode property which allows to
specify a mode specific style class for the panel actors.
https://bugzilla.gnome.org/show_bug.cgi?id=684573
The panel corners overlap the panel in order to hide the underline
used for active buttons where it is supposed to arc downwards
following the roundness of the corner.
Unfortunately this prevents us from using a transparent panel background,
as the overlapped area ends up with the wrong transparency. Work around
this limitation by only overlapping the panel if there is a visible
border.
https://bugzilla.gnome.org/show_bug.cgi?id=684573
Commit c3cab28 removed bits setting the password char that was used to
allow typing the password after a failure but before the first question
for the new attempt came.
Without that code, in complex PAM setups you can end up with a visible
password.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
Desktop files can specify if the application should only be shown for
specified desktops with OnlyShowIn and NotShowIn directives options.
If a menu category only contained entries for a different desktop, we
were still creating the category.
We now only add a category button if there is at least one application
to be displayed in this category.
https://bugzilla.gnome.org/show_bug.cgi?id=687970
We need to do a better job of indicating login process. This can
sometimes take a few seconds (particularly if you get your password
wrong): we need to give better feedback of what's going on.
This adds a spinner next to the login button if the authorization takes
some time.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
The login dialog had these issues:
- the entry was not really disabled, you could still edit text
- the sensitivity state was not reset on verification failure
- the session list was not disabled
The unlock dialog had these issues:
- "Login as another user..." was not insensitive
- redundant password char setting, overwriting the one given by the
question
The entry insensitive style was also wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
The "Sign In" button of the login dialog has its look disabled when the
entry is empty, but it can still be triggered by the Enter key.
This fixes the modal dialog so it does not trigger the action of an
insensitive button, and also means we do not need to connect to the
"activate" signal of the entry anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
Make the button layout public for callers to be able to have more
control over like adding custom widgets. Also, the clearButtons and
addButton methods are added as convenience for the most frequent usage.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
Open a modal dialog, try to open the message tray -> no effect, the message
tray is blocked by the dialog.
Close the dialog, try to open the message tray by pointer -> still
no effect, because the old timeout id was not cleared the first time,
so the dwell callback thinks the tray is about to open.
https://bugzilla.gnome.org/show_bug.cgi?id=688750
Windows in the overview should be highlighted when hovered, to indicate
they are an active target.
Based on a patch by Marc Plano-Lesay <marc.planolesay@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=665310
