Rename beginModal/endModal to pushModal/popModal. All of the current callers
just want to ensure that we're in a modal state; they don't actually need to
fail if we already are.
These functions also now take the Clutter keyboard focus, while recording
the previous focus.
https://bugzilla.gnome.org/show_bug.cgi?id=595116
When we had a filtered set of windows, and want to exit the overview
into a particular window, what we do is re-show all the old windows
first, but don't reset the scaling on them. This will involve
some overlapping, but that's not a big deal because we'll immediately
get overlap anyways in the normal case zooming the windows back.
https://bugzilla.gnome.org/show_bug.cgi?id=594699
When the user click+hold+release over the icon, the effect we want
is for the menu to stick around.
Also, allow the user to mouse over the actual windows and select
them directly. If the user mouses over a window, reflect that in
the menu.
https://bugzilla.gnome.org/show_bug.cgi?id=594699
Callers will generally expect _popup and _popdown to be a no-op if
the menu is already in that state; make it so.
Also change the 'popdown' signal to be 'cancelled'; this is
clearer and allows us to avoid having activate also call popdown.
https://bugzilla.gnome.org/show_bug.cgi?id=594699
There are ton of different kinds of mouse even handlers in the overview;
WindowClone has several mouse-enter/leave handlers, we still have a variety
of classes not ported to ButtonBox and so incorrectly handling double-click,
etc.
Since we at present don't have anything in the overview area for which
it makes sense to interact with during the animation, create a transparent
event-eating box which we raise to the top during the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=594074
controls if there is only one page of results
This makes the search results display more streamlined.
Make sure that we move the selection to a different section if we are going
from displaying a single section to displaying all and the section that
used to be displayed alone doesn't have any results.
When the user click+hold+release over the icon, the effect we want
is for the menu to stick around.
Also, allow the user to mouse over the actual windows and select
them directly. If the user mouses over a window, reflect that in
the menu.
We will be adding more search results sections, so we should store the intended
order of the search results sections and their properties in an array of data
structures.
This information allows us to have generic code for creating the search results
sections, moving the selection between them and transitioning between showing
all sections and a single section.
Rather than starting lightboxing only when the mouse enters the
menu, start it when an application filter is set.
Also delete a stale function in WindowClone from previous work.
http://bugzilla.gnome.org/show_bug.cgi?id=594555
Before Clutter gained accessors for event information, we had
shell_global_ functions. Now that Clutter has them, use them and
delete the ShellGlobal code.
http://bugzilla.gnome.org/show_bug.cgi?id=594561
Show the errors to the user instead of silently logging them to the terminal,
also rework positioning to get rid of magic numbers.
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
http://bugzilla.gnome.org/show_bug.cgi?id=593840
When we have multiple windows for an application, implement the following
behavior:
* On click + immediate release, go to the most recently used
* On click, hold for 0.6s, pop up a menu with windows, filtering
the window list to just those windows.
Mouse over on the window list highlights the moused-over window.
Implement this by splitting well item into InactiveWellItem
and RunningWellItem, sharing a base class BaseWellItem.
Checking if an item is under the pointer by calling stage.get_actor_at_pos()
synchronously will trigger a too-early allocation of the stage. Use an idle
at Meta.PRIORITY_BEFORE_REDRAW. (Before 553503d it was using a 5 msec timeout,
553503d made it synchronous.)
http://bugzilla.gnome.org/show_bug.cgi?id=592608
Display the mounted volumes in the places section of the overlay.
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: Colin Walters <walters@verbum.org>
For some use cases we have other behavior on mouse press and want
to manually control when a drag starts. Split out the drag initiation
code into startDrag.
There is no need to show two headers when we are only displaying a single
section of search results, so we merge the section header with the main
header in that case.
Show a back button on the left of the main header to get back to the results
for all sections.
Remove this._showTooltip flag from SearchSectionHeader because we no longer
show this type of header when we want to suppress the tooltip.
Add this._appSearchResultsOnlyShown and this._docSearchResultsOnlyShown
flags to track when a single section is shown more cleanly.
We no longer need the timeout for checking if an item is drawn under
the pointer because we display search results in the main pane and there is
no lowering/raising of other overview actors going on as the results are
being displayed.
Select an item by default when the search results are displayed.
Enable moving from one section of search results to another with key navigation.
Reset the selection when the search is updated or a new page is displayed
or the transition between viewing multiple sections and viewing just one is made.
The windows we considered for both the app monitor and the overview
workspaces were the same, but the code was duplicated once in C, once
in Javascript.
Make Button class purely about adding visuals, and use ShellButtonBox
for behavior. API equivalences:
shell.button => shell.actor [for consistency]
staysPressed parameter to constructor => replaced by manually setting
the 'active' property of button.actor as appropriate
pressIn/release => button.actor.active = true/false
enter-event/leave-event signals => button.actor notify::hover
Along the way, this fixes a bug with the user status menu where it was
not getting set to active because the button was getting a leave
(triggered by the menu popping up and grabbing the pointer) before for
button release, which disabled the staysPressed behavior.
Reported by Michael Meeks
http://bugzilla.gnome.org/show_bug.cgi?id=593471
Use bigger font and brighter color for the search results section headers.
Add more padding.
Display "(see all)" tooltip in the section headers on mouse-over.
(Still TODO: supressing that tooltip when all results are already being shown.)
All our font sizes were in px, other than the size for the text in
the search entry. Switch that from 12 to 16px (which is the same size
at the standard 96dpi), it doesn't become out of scale if the DPI
is different. (Using fixed px sizes isn't probably what we want to
do in the long term; moving to style sheets will be a good place to
fix that. But better to be consistent.)
http://bugzilla.gnome.org/show_bug.cgi?id=593212
When we are modal, examine keypresses and look for:
- 'Print': Run the screenshot command in any mode; very useful for
bug filing, reviews, etc.
- Release of Super_L/Super_R - if in the overview, toggle back
out of the overview.
http://bugzilla.gnome.org/show_bug.cgi?id=593427
shell-global.[ch]: Add shell_global_display_is_grabbed() that
uses the newly added meta_display_get_grab_op() to check
for existing grabs.
shell-status-menu.[ch]: Add shell_status_menu_is_active() to
check if the menu is popped up. Check for active grabs before
popping the menu up. Use gtk_menu_popdown() rather than
gtk_widget_hide(). Remove an excess gtk_widget_show() and
some excess casts.
panel.js: Check whether the status menu is popped up after button
release, and if it's not popped up, unhighlight the button.
Reported by Nuno Donato
http://bugzilla.gnome.org/show_bug.cgi?id=593362
For Firefox/OpenOffice, right now we have a workaround in the
code where we look at their "title" property. However, we
weren't monitoring that property for changes, and I'm fairly
certain Firefox at least was mapping a window and then very
quickly changing its title after. So we need to handle
dynamic changes.
Split out the wm_class mapping from the title hack. It was
messy and weird to have the two mixed because they're not
at all related, and we're not trying to handle WM_CLASS changes
right now.
Explicitly connect to notify::title in the case where we had
a title fallback. When a title changes, just treat it as
an add+remove.
In the Application Menu area in the panel, hook up to app-added
and app-removed so we get notification of the active app changing.
Display only first page of search results by default for each section and
allow clicking on the section header to view all the results for a given
section. This design will allow us to easily move from paging to scrolling
without having to stack multiple scrollbars in a single pane.
Display a total results count next to the section name. This serves as an
indicator that there are more results. The section header pre-lights to
indicate that it can be clicked on.
Make sure we go back to the first page of results when we exit a single
section mode. Make sure we re-instate all result sections if the search
mode is left.
Close the only section search mode on Esc, and only close the search
when Esc is hit again.
We now have functionality in Mutter to grab the keyboard on behalf
of a plugin. This avoids interactions with the key handling code
in Mutter that could leave the user with an inconsistent state
and no way to get out of it.
src/shell-global.[ch]: Change shell_global_grab_keyboard() and
shell_global_grab_keyboard() to shell_global_begin_modal()
shell_global_end_modal() and call mutter_plugin_begin_modal()
mutter_plugin_end_modal() rather than directly grabbing the
keyboard.
main.js: Call global.begin_modal/end_modal from Main.startModal()
and Main.endModal()
altTab.js; Remove call to Main.startModal() - we're letting Mutter
handle modality for Alt-Tab.
main.js lookingGlass.js overview.js runDialog.js: Rename
Main.startModal() to Main.beginModal() for consistency with
naming in mutter and ShellGlobal.
http://bugzilla.gnome.org/show_bug.cgi?id=590686
Display search results in the dash instead of showing them in a separate pane.
We get dynamic allocation for the section height based on the number of
results, but a lot of the problems with the previous search results display,
such as displaying empty sections and paging overflow are still present.
Also, we don't yet close the browse pane for applications or documents when
we display the search results and only replace it if we are showing the
details pane, so all that looks weird. We'll need to work out the interaction
for these cases.
This fixes a bug where we were already using this._hotCorner
in _onHotCornerEnvironsLeft() and were incorrectly setting
this._hotCornerEntered to false when the hot corner was
re-entered from the environs.
Rather than just launching if we weren't already running, always
relaunch, which happens to make Firefox, etc. work. See
the comment in the commit for more explanation.
Add drag and drop. We need to be able to recreate the icon texture,
so instead of passing it directly into PlaceDisplay, pass
a factory function which knows how to create a new texture.
The design has smaller icons in two columns. Add a new
custom display to docDisplay for it.
Clean up some of the texture cache handling for recent URIs so
it's not size-dependent, since the dash size is now different
from the default GenericDisplay size.
We had multiple copies of the code to position a drag actor given a particular
source. Instead, just put it inside dnd.js.
Second, rather than test for GenericDisplay/WellDisplayItem etc.,
in various places, add a new method on each source "shellWorkspaceLaunch"
which both marks the item as being droppable on a workspace, and is
called by the workspaces code to launch the item.
Use MetaGroup for a window when looking up applications. If
we know the application for a TYPE_NORMAL window in the group,
use that.
However, we aren't always going to know the application for a window. In
that case, create a fake one.
ShellAppInfo has a "transient" flag so we know not to write these
fake apps to the usage file.
Clean up the idle focus handler to better handle the case where
no window is focused, and where we don't want to track the
particular window.
Update track_window to create the fake window.
When a window goes away, we want to delete the usage.
Rewrite shell_app_monitor_get_running_apps to be based
on the window_to_app hash, because that's what has the pointer
to ShellAppInfo*. Before we were looking up all ids through
ShellAppSystem, but that shouldn't be holding a ref to transients.
Change the well display icon to be centered, since our icons for
window apps aren't 48 pixels.
Using a larger area around the hot corner to decide if the user has left the
hot corner prevents triggering the hot corner multiple times due to an
accidental jitter.
We need to use the -lib variant which in turn uses the
GETTEXT_PACKAGE define, because the default translation
domain is actually mutter, not gnome-shell.
We don't have a lot of strings, and what ones we do have we've
been avoiding duplication. This patch adds calls to _() i.e. gettext
for those strings we do have.
The maximize effect looked really ugly. In the absence of any cooler
effects, none at all is better than what we have. Current compiz
doesn't have one either.
Note that in the future when we merge the frame into the panel
in the maximize case, we may want an effect for that.
Instead of counting on the implicit sizing of ClutterGroup, which isn't
going to work well because of current limitations of ClutterClone, set
the size of workspace explicitly based on the screen size.
This should fix various problems with drag-and-drop being unreliable;
if a workspace was sized to big it could overlap other workspaces or
elements of the overview.
http://bugzilla.gnome.org/show_bug.cgi?id=591643
There was some weirdness relating to when the search pane is shown
in a timeout, and how that relates to setSearch. Instead of doing
this in the timeout, just call setSearch() in the timeout. The
pane hide/show state is directly controlled from the handler.
Currently ShellAppMonitor relies on all the .desktop files being
loaded. We should initialize it very early to ensure that anything
that uses it has up-to-date information right away.
Remove the last use of passing width into Dash by having the
Pane with the previews scaling dynamically and relying on
Clutter scaling.
If we only have one workspace, don't display a selection frame
for it.
Rework Dash into a searchArea and sectionArea, which get
explicitly sized by overlay.js. We use the workspaces size
to choose the size of those dash areas.
Switch dash colors/boxes etc. to ones from shell-black02.
Add a gradient to the panel.
Add a magnifier.svg for use in search.
minWidth and minHeight arguments of the Button class were not used.
Panel buttons need their height to be explicitly specified as
PANEL_HEIGHT to take up full panel height. This fixes the problem with the
user not being able to click at the very top edge of the panel to activate
the button.
This is a start at the "Active Appliction Item" component of the
shell design. Currently we just show the currently focused
application. When launching a new application, we show that as well.
The implementation here is not complete; basically when launching
we de-focus the active one, and the application well shows the
most recent startup sequence.
This kind of fails in the case of multiple sequences, and we
also don't correctly de-focus the current window in other
launch paths.
There was lots of fixed positioning in the Panel; now it is completely
dynamic, and width/height is driven from main.js. We still have a
global constant Panel.PANEL_HEIGHT, but this is a big step towards
eliminating it.
Also, this avoids overdraw in the "way too many tray icons" case. The
clock will shift left.
Replace 'overlay' with the more descriptive name 'overview'
where the Activities Overview is meant. Call it Overview
(capitalized) in code comments.
The overlay-group and overlay-key provided by Mutter are not
affected, since they may be used for other components than
the Activities Overview.
Instead of only transforming the active workspace, create a
zooming effect when showing or hiding the overlay. This makes
the transitions simpler: the workspaces are now fixed to the
overlay actor group and will not slide over the Dash.
overlay.js: Add zoom animations, fade in/out Dash during those,
remove obsolete Dash clipping and stacking logic, add public
get[Scale|Position]() and getZoomedIn[Scale|Position]()
functions.
workspaces.js: Remove zoom animations, add fade animations for
the remove button, add helper functions for the overlay
zooming, keep the movement of windows linear to that of
their workspaces, remove the updatePosition() and
updateInOverlay() functions and fullSize variables that
were left from the old overlay design.
The "expanded background" that is behind the workspaces etc. in the overview
should be removed. It isn't in the designs, it is distracting, and it breaks
the overview metaphor.
At least temporarily, just make the background of the overview black.
Change the pane popup to black as well, but keep a blue border so that
it is visually distinguished from the background.
Based on a patch by Colin Walters, with fixes from Marina Zhurakhinskaya.
It's both intuitive to go to the corner of the screen
and click the activities button at the same time.
Both actions bring up the overlay, but combined
they cancel each other out. This commit makes
clicking the hot corner not cancel the act of
going to the hot corner.
Based on a patch from Ray Strode.
The scale of windows within a workspace is determined by the
scale of the workspace since we never scale a window bigger
than the original size of the window. So when we rescale
workspaces we have to rerun Workspace.positionWindows().
http://bugzilla.gnome.org/show_bug.cgi?id=591124
The onComplete when positioning windows may come before the
final stage of the workspace positioning animation. So we can't
use actor.get_transformed_position() to figure out where to put
the icons. Compute the final position manually ourselves instead.
http://bugzilla.gnome.org/show_bug.cgi?id=591123
Both the position and size of the frame actor depend on the scale
of the workspace, so update them both when the scale changes.
On the other hand, the the frame actor doesn't need to be
repositioned when the workspace moves (since it is relative to the
workspace). We do base the frame position of the desktop actor, but
that will presumably stay fixed (at 0,0) in most all cases.
http://bugzilla.gnome.org/show_bug.cgi?id=591122
