Commit Graph

53 Commits

Author SHA1 Message Date
Florian Müllner
fd50b9a45e cleanup: Use destructuring for imports from GI
This is *much* nicer than repetitive "imports.gi" lines ...

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/399
2019-02-09 07:39:20 +01:00
Florian Müllner
a1534dab02 cleanup: Clean up unused imports
Spotted by eslint.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/399
2019-02-09 05:05:07 +01:00
Carlos Garnacho
c59c5eb893 st: Add StDirectionType enum
In order to replace GTK+'s GtkDirectionType. It's bit-compatible with it,
too. All callers have been updated to use it.

This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
2019-01-30 22:50:01 +01:00
Florian Müllner
bacfdbbb03 cleanup: Port non-GObject classes to JS6 classes
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
2019-01-25 14:02:44 +00:00
Florian Müllner
213e38c2ef cleanup: Use arrow notation for anonymous functions
Arrow notation is great, use it consistently through-out the code base
to bind `this` to anonymous functions, replacing the more overbose
Lang.bind(this, function() {}).

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
2018-02-21 13:55:00 +00:00
Florian Müllner
76f09b1e49 cleanup: Use method syntax
Modern javascript has a short-hand for function properties, embrace
it for better readability and to prepare for an eventual port to
ES6 classes.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
2018-02-21 13:54:58 +00:00
Florian Müllner
2582d16ca7 Define classes with 'var' instead of 'const'
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.

https://bugzilla.gnome.org/show_bug.cgi?id=785084
2017-07-18 21:52:06 +02:00
Florian Müllner
d85f97c744 grabHelper: Adjust to property name change
Commit bbfa616f27 renamed _ignoreRelease to _ignoreUntilRelease
in some places, but not others, which broke GrabHelper.ignoreRelease().
Complete the name change to fix the fallout (e.g. app launcher menus
closing on button release).
2014-08-28 19:49:51 +02:00
Carlos Garnacho
42b54aaa21 grabHelper: handle touch events during grab modality
The "pointer emulating" touch sequence will be handled in order to dismiss
the grab, while the others are just propagated.

https://bugzilla.gnome.org/show_bug.cgi?id=733633
2014-07-31 10:55:25 +02:00
Carlos Garnacho
bbfa616f27 grabHelper: consume the press/motion/release sequence if a press dismisses the grab
The grab would previously just consume the button release, while propagating
motion events, possibly down to clients in wayland. This would produce
inconsistent streams there.

On pointer events, the inconsistency would just be having clients receiving
events with the button 1 set in the mask, with no implicit grab. When touch
events are handled, this would be more hindering as the client would receive
touch_motion events with no prior touch_down nor later touch_up, something
never supposed to happen.

https://bugzilla.gnome.org/show_bug.cgi?id=733633
2014-07-31 10:55:11 +02:00
Florian Müllner
deb2f30b37 js: Use EVENT_PROPAGATE/EVENT_STOP constants in event handlers
Just as SOURCE_CONTINUE/SOURCE_REMOVE in source functions, these
constants increase code clarity over plain true/false.

https://bugzilla.gnome.org/show_bug.cgi?id=719567
2013-12-16 18:27:19 +01:00
Jasper St. Pierre
8d9aa6388d grabHelper: Introduce a stack of grab helpers
GrabHelpers use a 'captured-event' to steal events and emulate
modality or grab-like semantics. There can be issues when you try to
use multiple GrabHelpers stacked on each other. As Clutter follows
the DOM-like semantics of "first come, first serve", when a second
GrabHelper connects to 'captured-event', its callback will only be
processed *after* the first GrabHelper's callback is called.

This breaks the expectation of narrowing modality where new modals
take priority over the old ones.

Solving this globally in a cleaner manner would require a rewrite of
pushModal/GrabHelper. As a stopgap fix for now, use one shared
'captured-event' handler between all GrabHelper instances, and
delegate to the individual GrabHelpers.

https://bugzilla.gnome.org/show_bug.cgi?id=699272
2013-08-19 09:35:09 -04:00
Jasper St. Pierre
393577ee78 grabHelper: Remove explicitly having to select modal
https://bugzilla.gnome.org/show_bug.cgi?id=700735
2013-07-08 16:51:51 -04:00
Jasper St. Pierre
eef593a34e messageTray: Don't use focus grabs
We can easily implement much of the same behavior ourselves by
keeping track of Clutter's focus events. Reintroduce heavily
modified FocusGrabber to do the work for us.

This will temporarily break when the user selects a window until
we can make gnome-shell automatically set the stage focus.

This also removes our only use of focus grabs, so remove those
as well.

https://bugzilla.gnome.org/show_bug.cgi?id=700735
2013-07-08 16:51:50 -04:00
Jasper St. Pierre
3790e924e9 grabHelper: Rewrite documentation for GrabHelper.grab()
The previous docs were badly maintained. This does not mention
grabFocus grabs, as they'll be removed shortly.

https://bugzilla.gnome.org/show_bug.cgi?id=700735
2013-07-08 16:17:01 -04:00
Jasper St. Pierre
9a79c71e88 global: Remove support for the NONREACTIVE input mode
As it's unused, this is a quick cleanup before we can go onto
more important things.

https://bugzilla.gnome.org/show_bug.cgi?id=700735
2013-05-22 12:11:19 -04:00
Florian Müllner
f8ea825577 grabHelper: Consider events that release the grab handled
Currently, if a button-press event results in releasing the last modal
grab (e.g. clicks outside the grabbed actors), we don't consider the
event handled and allow its emission to continue. If we consider
dismissing a grab as an action of its own, any additional action
triggered by the same event becomes an unexpected side effect.
Tweak the capture handler accordingly.

https://bugzilla.gnome.org/show_bug.cgi?id=696422
2013-03-25 10:43:29 +01:00
Jasper St. Pierre
aec0e75d73 grabHelper: Ensure we reset ignoreRelease when we drop our event handler
Since we drop our event handler, we won't see ever the release event
from the button press, so unset the flag so it doesn't muck with the
next time somebody takes a grab.

https://bugzilla.gnome.org/show_bug.cgi?id=696102
2013-03-18 16:49:12 -04:00
Jasper St. Pierre
8301acd4d6 grabHelper: Use a round trip for focusing the default window
We may release the focus grab at any time, so it's not guaranteed
we'll be in event processing. In particular, hovering over and out
of a notification will cause this to happen, as the notification
is hidden on a timeout.

https://bugzilla.gnome.org/show_bug.cgi?id=695659
2013-03-12 11:58:50 -04:00
Jasper St. Pierre
6ffe3a424c grabHelper: Fix indentation
https://bugzilla.gnome.org/show_bug.cgi?id=694038
2013-02-18 04:31:45 -05:00
Jasper St. Pierre
3628c81885 grabHelper: Ignore key focus changes when ungrabbing
Calling onUngrab() may change key focus, either directly or
indirectly (e.g. hiding the actor). Such key focus changes
would cause an extra actor to be ungrabbed, so make sure to
ignore such focus changes while we're ungrabbing.

https://bugzilla.gnome.org/show_bug.cgi?id=693975
2013-02-16 13:33:45 -05:00
Jasper St. Pierre
180000a531 grabHelper: Track the grab before trying to set key focus
If we don't this for a nested grabFocus grab, the notify::key-focus
will be called, not think that the new key focus is part of the
grab, and cancel the full grab. This leaves the grab helper in an
inconsistent and confused state, as the grab is pushed onto the
grab stack after.

https://bugzilla.gnome.org/show_bug.cgi?id=693975
2013-02-16 13:33:45 -05:00
Jasper St. Pierre
5f995c64d4 grabHelper: Correct typo preventing focus-window-changed disconnect
While debugging, I found that the signal to focus-window-changed
was never getting disconnected, making a call to ungrab every time
the focus window changed, even if there were no focus grabs anymore.

https://bugzilla.gnome.org/show_bug.cgi?id=693975
2013-02-16 13:33:45 -05:00
Jasper St. Pierre
fe2c2014de grabHelper: Use a mode: js header
This brings us into consistency with the rest of the modelines

https://bugzilla.gnome.org/show_bug.cgi?id=693975
2013-02-16 13:33:45 -05:00
Florian Müllner
ad1b9b71ae grabHelper: Merge _navigateActor() with its only user
https://bugzilla.gnome.org/show_bug.cgi?id=693570
2013-02-14 19:17:32 +01:00
Florian Müllner
60257f422a grabHelper: Restore the actually saved focus on ungrab
GrabHelper saves the actor that had key focus when taking over the grab
(if any). On ungrab, the key focus is either restored or moved to some
child of the saved actor. The latter is unexpected and causes some odd
behavior, so don't be fancy and only restore the actual focus.

https://bugzilla.gnome.org/show_bug.cgi?id=693570
2013-02-14 19:17:32 +01:00
Jasper St. Pierre
52ca15b514 grabHelper: Allow pressing escape on grab focus grabs
We didn't install the captured event handler on grab focus grabs,
leading to the case where we didn't ungrab correctly.

https://bugzilla.gnome.org/show_bug.cgi?id=690897
2013-01-02 12:32:29 -05:00
Jasper St. Pierre
b42af9aa99 popupMenu: Don't slide menus when we're changing them
As calling close() will drop the grab, we were inadverdently
re-closing menus, causing them to re-animate with a full animation.

https://bugzilla.gnome.org/show_bug.cgi?id=689954
2012-12-10 14:38:07 -05:00
Jasper St. Pierre
9dfc3af9d7 popupMenu: Port to GrabHelper
https://bugzilla.gnome.org/show_bug.cgi?id=689109
2012-12-07 19:55:28 -05:00
Jasper St. Pierre
8dc63932fc grabHelper: Fix up event handling for ignoring releases
We need to return 'true' to signify that we handled the event.

https://bugzilla.gnome.org/show_bug.cgi?id=689109
2012-12-07 19:55:23 -05:00
Jasper St. Pierre
066e5cddb5 grabHelper: Drop to the actor clicked on
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
2012-12-07 19:54:46 -05:00
Jasper St. Pierre
27ffad2148 grabHelper: Treat the current grabbed actor as a grabbed actor
This should be obvious, but I guess it wasn't necessary for the
message tray case.

https://bugzilla.gnome.org/show_bug.cgi?id=689109
2012-12-07 19:53:47 -05:00
Jasper St. Pierre
41db363b06 grabHelper: Use captured-event for escape ungrabs
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
2012-12-07 19:53:46 -05:00
Jasper St. Pierre
4153feeb15 grabHelper: Use focus_default_window
This prevents us from having to track the previously focused window.

https://bugzilla.gnome.org/show_bug.cgi?id=689653
2012-12-06 12:25:37 -05:00
Florian Müllner
5f367248c5 grabHelper: Support optional parameters to pushModal()
https://bugzilla.gnome.org/show_bug.cgi?id=688202
2012-11-17 01:44:22 +01:00
Florian Müllner
2e63709450 grabHelper: Ignore events from On-Screen-Keyboard
GrabHelper automatically releases grabs when the user clicks outside
the grabbed actors. However at least for the message-tray (which is
the only user of grabHelper at the moment), we must ignore any events
from the On-Screen-Keyboard, to prevent the tray from hiding at every
key press.

https://bugzilla.gnome.org/show_bug.cgi?id=683546
2012-09-25 08:25:24 +02:00
Jasper St. Pierre
2acb097662 grabHelper: Fix regression for dwelling with mouse down
b203a95a78 introduced a regression
where we forgot to bail out if the pushModal didn't succeed properly.

https://bugzilla.gnome.org/show_bug.cgi?id=684344
2012-09-19 08:10:12 -03:00
Florian Müllner
ef7b74a104 grabHelper: Remove support for untracked grabs
https://bugzilla.gnome.org/show_bug.cgi?id=682243
2012-09-18 18:45:41 +02:00
Florian Müllner
809cbf58c6 grabHelper: Ungrab the entire stack on "outside clicks"
Currently clicks outside the grabbed actors are handled the same as
the user pressing Escape - a single actor is popped from the grab stack.
However according to the design, outside clicks should release all grabs.

https://bugzilla.gnome.org/show_bug.cgi?id=682243
2012-09-18 18:45:41 +02:00
Florian Müllner
ff31ccdd30 grabHelper: Remove unused parameters
Some left-overs from commit b203a95a7 ...

https://bugzilla.gnome.org/show_bug.cgi?id=683546
2012-09-17 21:53:53 +02:00
Florian Müllner
f6645a41d2 grabHelper: Set _grabbedFromKeynav
This one got lost in commit b203a95a7.

https://bugzilla.gnome.org/show_bug.cgi?id=683546
2012-09-17 21:53:53 +02:00
Jasper St. Pierre
b203a95a78 grabHelper: Rework grabbing code to properly handle stacking
When Dan Winship wrote the GrabHelper code originally, it didn't
handle a grab stack. I wrote the grab stack code hastily when landed
the message tray, not understanding all of the code that was involved
here.

Fix it so that we properly do the operations for each type of grab
when we first need to, and not sometimes when the first grab is taken.

https://bugzilla.gnome.org/show_bug.cgi?id=683546
2012-09-15 10:32:31 -03:00
Giovanni Campagna
5a259dd6b0 GrabHelper: always navigate focus when grabbing
Users of GrabHelper.grab() espect that the actor parameter (or one of its
children) will receive focus, irrespective of the previous focus location.
This fixes the key focus on the chat entry when expanding the notification.

https://bugzilla.gnome.org/show_bug.cgi?id=683449
2012-09-06 15:20:14 +02:00
Jasper St. Pierre
be5df17a4a grabHelper: Clean up the code a bit
I don't remember why I added needsGrab in the first place.
2012-09-05 14:28:45 -03:00
Owen W. Taylor
3902e8bff0 messageTray: fix dwelling during mouse-down
If the user has the mouse down - for example when they are selecting
text and dragging - then the attempt to get a modal grab will fail.

grabHelper: allow the .grab() function to fail and do nothing in this
modal case if the grab fails.

messageTray: handle grab failure and don't pop up the tray. Change the
logic for tray dwelling so that we only try to pop up the tray once
while the pointer is in the dwell area - this avoids the possiility
that the tray will pop up once the user releases the mouse.

https://bugzilla.gnome.org/show_bug.cgi?id=682385
2012-08-23 01:49:21 -04:00
Jasper St. Pierre
eebab34b62 grabHelper: Make sure to return not null when the stack contains fake grabs
We did this if there's nothing in the grab stack, but didn't do this
when there's no real grabs in the grab stack.
2012-08-19 21:15:52 -04:00
Jasper St. Pierre
4dfe3d21e1 messageTray: Always close the tray when clicking outside of it
Even when a summary box pointer item is up.
2012-08-19 21:15:50 -04:00
Jasper St. Pierre
3568e6d42d grabHelper: Only connect to specific signals when actually taking a grab
When we enter the overview, we don't explicitly don't take a grab, so we
shouldn't connect to key-focus-changed and things like that, otherwise
random overview code will drop our grab for us.

This fixes escape in the overview not dropping when a notification is up.
2012-08-19 21:15:50 -04:00
Jasper St. Pierre
c3ae4542b2 grabHelper: Fix ungrabbing properly
Make sure to account for modalCount properly, rather than just
tracking modalCount for the last actor on the stack. Additionally,
traverse the popped actors in the reverse order so that onUngrabbed
callbacks are called at the proper place in time.
2012-08-19 21:15:50 -04:00
Jasper St. Pierre
3031036cb0 grabHelper: Make sure to call onUngrabbed for all popped actors 2012-08-19 21:15:50 -04:00