In preparation for adding magnification, "uiGroup.patch", organizes the stage
along the following lines:
Stage
*Magnifier
UI group
Window group
Chrome group
Overlay group
Alt tab
App display
Chrome
...
This allows a magnifier actor to clone and magnify the UI group. The magnifier
is a sibling of the UI Group in this stage oraganization -- see the next patch,
"Magnifier.patch".
This patch combines several high level changes which are conceptually
independent but in practice rather intertwined.
* Add a "state" property to ShellApp which reflects whether it's
stopped, starting, or started. This will allow us to later clean
up all the callers that are using ".get_windows().length > 0" as
a proxy for this property
* Replace shell_app_launch with shell_app_activate and shell_app_open_new_window
A lot of code was calling .launch, but it's signficantly clearer
if we call this ".open_new_window()", and later if we gain the ability
to call into an application's menu, we can implement this correctly rather
than trying to update all .launch callers.
* Because ShellApp now has a "starting" state, rebase panel.js on top of
this so that when we get a startup-notification sequence for an app
and transition it to starting, it becomes the focus app, and panel.js
cleanly just tracks the focus app, rather than bouncing between SN
sequences. This removes display of non-app startup sequences, which
I consider an acceptable action in light of the committed changes
to startup-notification and GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=614755
Also, remove a lot of cruft from genericDisplay.js leftover from
previous St-ifications, and remove the pre-gtk-2.16 hacks from the
status tray in panel.js (which are much less needed with the
nearly-all-black panel anyway).
https://bugzilla.gnome.org/show_bug.cgi?id=614516
The actual changes to shell-menu.[ch] are pretty minimal; most of the
changes there are just style/spacing/indentation.
Also, removed shell_menu_append_separator() since it wasn't needed;
the separators would already have been behaving as intended just
because they were non-reactive.
https://bugzilla.gnome.org/show_bug.cgi?id=614516
Left-clicking an app icon and holding the button used to pop up the
app menu, but regressed when rewriting appDisplay.
Restore the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=609013
The hover rewrite added a freeze/thaw_notify to
st_clickable_leave_event() (to match the one already in
st_clickable_enter_event()), which broke code in two places that
assumed "pressed" would still be TRUE when "hover" changed to FALSE.
Fix that by exposing the "held" property as well.
If track-hover is set, update the hover property automatically, and
the "hover" pseudo class to match, as StClickable used to do. (Remove
the corresponding code in StClickable). Tweak the tooltip handling to
use track-hover, which also makes it slightly more reliable in the
presence of reactive children, etc.
Since style_class and pseudo_class are space-separated lists of names,
add new methods to add and remove individual names rather than just
re-setting the entire name.
Update existing code to use the new pseudo-class methods where
appropriate. In some cases, this may result in actors having multiple
pseudoclasses where previously they only had one at a time, but there
don't seem to be any visible differences.
(There are some places that could usefully use the new style_class
methods as well, but this patch doesn't change them.)
Also, update test-theme.c to test the new methods.
https://bugzilla.gnome.org/show_bug.cgi?id=604943
Having StDrawingArea use ClutterCairoTexture causes circularity
problems with sizing - StDrawingArea wants to use its allocation for
the size of the texture, but ClutterTexture wants to use the size of
the texture to determine the requited size.
Avoid this by making StDrawingArea directly use Cairo and CoglTexture;
while doing this, the API is changed a bit for simplicity and to
match our use case:
- Instead of clutter_cairo_texture_create(), we have
st_drawing_area_get_context() to retrieve an already created
context. This can only be called in the ::repaint signal.
- The ::redraw signal is changed to ::repaint so we can have
st_drawing_area_queue_repaint() that doesn't collide with
clutter_actor_queue_redraw()
- ::repaint is now emitted lazily when painting the actor rather
than synchronously at various different points.
https://bugzilla.gnome.org/show_bug.cgi?id=611750
The top part of the application pane closes the pane, while outside
the menu only the workspace area accepts clicks for closing the pane.
Let the user close the pane by clicking anywhere outside the menu, but
not inside.
https://bugzilla.gnome.org/show_bug.cgi?id=611641
Brute force merge these two by essentially replacing St.TextureCache
with a (renamed) Shell.TextureCache.
One function was added for convenience, namely "st_texture_cache_load_file_simple".
St.TextureCache had a function to load a texture from a filename, and it
returned NULL on error but only half the callers actually checked this. This
function is better.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
The previous commit broke activation when selecting an actor
from a custom renderer. Fix this by explicitly defining a method
activateSelected on the search renderer.
Switch to using an application icon as per design.
We need to drop the 4 pixels padding to ensure we fit 3 icons.
There was a typo where getVisibleCount should have been getVisibleResultsCount.
https://bugzilla.gnome.org/show_bug.cgi?id=610740
Add a 'vshadow' property to StScrollView, which, when turned on,
overlays gradient shadows on the top and bottom of the StScrollView.
Turn this on for the StScrollView used for the app browser.
https://bugzilla.gnome.org/show_bug.cgi?id=609604
This way, clicking a message tray icon while the overview is open will
close the overview when activating its window.
Remove some other overview-related activation code which is now
redundant.
Also, remove calls to "global.get_current_time()" when calling
Main.activateWindow, since it's unnecessary (activateWindow will call
it itself if you don't pass in that arg).
https://bugzilla.gnome.org/show_bug.cgi?id=609765
Currently, activating a search result always opens a new window. Change
this behavior, so that if an application has open windows, the most
recently used one is activated instead.
Also change the implementation of dnd of search results to allow providers
to treat results activated via dnd differently.
https://bugzilla.gnome.org/show_bug.cgi?id=610027
We need to return the "thing that is being dragged" from
getDragActorSource() so that dnd.js can figure out the right
relationship between the dragged object and cursor.
https://bugzilla.gnome.org/show_bug.cgi?id=607351
Matching the 20091114 mockup, the default workspace view
is now a scrollable horizontal list, with a control to
switch between this and the previous grid view.
https://bugzilla.gnome.org/show_bug.cgi?id=593844
Make the event blocking done by Lightbox optional - leave it activated
when displaying the run dialog, but deactivate it when highlighting
windows in the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=602774
The high level goal is to separate the concern of searching for
things with display of those things; for example in newer mockups,
applications are displayed exactly the same as they look in the
AppWell.
Another goal was optimizing for speed; for example,
application search was pushed mostly down into C, and we avoid
lowercasing and normalizing every item over and over.
https://bugzilla.gnome.org/show_bug.cgi?id=603523
The distinction between the inactive and running was silly; just
have one class which can handle both running states. However for
a future search patch, we do want a separation between an icon which
just has icon + name + glow, and a well icon which does the menu
integration.
https://bugzilla.gnome.org/show_bug.cgi?id=603523
Previously we had various things watching for notify::mapped so
we could be more lazy about updating non-visible actors, but it
was fairly ad-hoc.
The deferred work system unifies these callbacks, and also adds
a timeout so that we don't delay changes arbitrarily; this way we
avoid a storm of work if you stay out of the overview for a while,
then go in.
https://bugzilla.gnome.org/show_bug.cgi?id=603522
The altTab.js and app well code weren't sharing really
any functionality anymore; un-merge the appIcon code back
into appWell, and have a simple icon + text display for
altTab.
Port AppWell to St and CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=602131
The two parts were mapping windows to applications, and
recording application usage statistics. The latter part
(now called ShellAppUsage) is much more naturally built on top of
the former (now called ShellWindowTracker).
ShellWindowTracker retains the startup-notification handling.
ShellWindowTracker also gains a focus-app property, which is
what most things in the shell UI are interested in (instead of
window focus).
ShellAppSystem moves to exporting ShellApp from more of its
public API, rather than ShellAppInfo. ShellAppSystem also
ensures that ShellApp instances are unique by holding
a hash on the ids.
ShellApp's private API is split off into a shell-app-private.h,
so shell-app.h can be included in shell-app-system.h.
Favorites handling is removed from ShellAppSystem, now inside
appFavorites.js.
Port all of the JavaScript for these changes.
https://bugzilla.gnome.org/show_bug.cgi?id=598646
Previously, we had ShellAppInfo, which contains fundamental
information about an application, and methods on ShellAppMonitor
to retrieve "live" information like the window list.
AppIcon ended up being used as the "App" class which was painful
for various reasons; among them that we need to handle window
list changes, and some consumers weren't ready for that.
Clean things up a bit by introducing a new ShellApp class in C,
which currently wraps a ShellAppInfo.
AppIcon then is more like the display actor for a ShellApp. Notably,
the ".windows" property moves out of it. The altTab code which
won't handle dynamic changes instead is changed to maintain a
cached version.
ShellAppMonitor gains some more methods related to ShellApp now.
In the future, we might consider changing ShellApp to be a GInterface,
which could be implemented by ShellDesktopFileApp, ShellWindowApp.
Then we could axe ShellAppInfo from the "public" API and it would
return to being an internal loss mitigation layer for GMenu.
https://bugzilla.gnome.org/show_bug.cgi?id=598227
When we get a ClutterModifierType from Clutter, it might contain
bits not in the enumeration. See bug 59771 for a similar problem
with GdkModifierType.
Add a wrapper Shell.get_event_state() around clutter_event_get_state()
to mask these bits out and only return approved bits.
https://bugzilla.gnome.org/show_bug.cgi?id=597735
Being able to display all applications in a category based on the search
string with a category name is generaly useful.
Prepare all the applications that match a search term based on their
category name up-front.
Remove unused this._appCategories and a call to non-existing
itemInfo.get_categories()
Add a "size" parameter to allow changing the AppIcon size, and then
simplify the constructor by taking an object with parameters like
gobject-introspection constructors do, rather than taking a large
number of miscellaneous arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=597498
For some unknown reason we were connecting to app-added and
app-removed on ShellAppMonitor in the AppDisplay class, which
never made any use of the data. Simply don't connect to those
signals for now. In the future we should have AppDisplay
be using the AppIcon class which will more correctly handle
dynamic changes.
In the AppWell, avoid doing the full relayout until we're
actually mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=597169
Also have inactive applications pop up a menu.
Add/Remove from favorites is now in the menu.
Concatenate the favorites/not-favorites instead of having a gap only
if you happened to have a not-divisible-by-4 number of favorites.
https://bugzilla.gnome.org/show_bug.cgi?id=596371
Fix displaying documents in the document browse and refreshing the selection
when the results have changed.
Make sure we are passing the appropriate flag to _redisplay() in GenericDisplay.
Make sure we set this._appsStale to true if there was a change in the
applications set.
Don't call _refreshCache() from the AppDisplay constructor.
Don't short-circuit the call to _refreshCache() from _redisplay() on initial load.
Rename _redisplayFull() to recreateDisplayItems() and remove adding an
actor to the actual result list in _addDisplayItem() because we redo adding the
actors to the list in _redisplayReordering() anyway to ensure that we add
them in the right order.
Based on a patch from Colin Walters.
Unlike icons in the application well, do not show the glow used to
indicate running apps. It is somewhat redundant here. These are all
running apps and it is fairly clear from the window list if there are
multiple instances available, according to mccann.
https://bugzilla.gnome.org/show_bug.cgi?id=590563
- Add spacing after Frequent, reduce it for the other app categories.
Put a small gap (one line) between Frequent and the other
categories to make it clear that it is something a little
different.
- Remove category icons from the applications menu.
Remove category icons; they aren't particularly helpful
(they are gone from the GNOME-2.28 menus too) and having them
in Applications Browse draws the eye to the wrong thing - the
category - rather than the right thing - the application icons.
https://bugzilla.gnome.org/show_bug.cgi?id=596435
There are now 3 code paths in decreasing speed:
First, optimize subsearching more by just hiding the actors
that didn't match, since we know the ordering has to be right.
For initiating a search (or backspacing an existing one), again
instead of destroying and recreating actors, just temporarily
remove them and re-add them in the desired order.
Finally for when data has changed, use the old code path of
destroying all actors. (This itself could obviously be optimized
if we had a way to know that just one application changed, but
at the moment we don't).
https://bugzilla.gnome.org/show_bug.cgi?id=596119
