Filter out all applications which have the NoDisplay, Hidden or
Not/OnlyShowIn bits, as those are not meant to be launched directly.
This also allows the user to filter apps from the frequent view
using alacarte.
https://bugzilla.gnome.org/show_bug.cgi?id=696949
ClutterBinLayout uses the maximum width/height of all children in
size requests and positions children according to the expand/align
properties. This means that the vertical position of folder popups
is not considered in size requests, so if the main view is smaller
than a folder popup's height and offset, the popup will be truncated
and/or mispositioned. Fix those cases by using a custom LayoutManager
that behaves like ClutterFixedLayout for height requests and like
ClutterBinLayout otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=694371
If the AllView is scrolled, the vertical scrollbar will take away
some horizontal space on one side, resulting in the content ending
up slightly off-center.
Account for this by using overlay-scrollbars instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
The frequent view should not be scrolled, but to work around the
icon grid overflowing, we used a (non-scrolling) scroll view anyway.
Now that IconGrid:fillParent allows us to avoid overflow, we can
remove this hack.
https://bugzilla.gnome.org/show_bug.cgi?id=694256
PopupMenuManager eats the next release event, which would otherwise close
the menu, so we need to tell dnd that we're handling it, and no drag should
be started, so it can ungrab the pointer and restore state.
https://bugzilla.gnome.org/show_bug.cgi?id=694276
The arrow origin must be in the coordinate space of the box pointer,
but it cannot be calculated when the box pointer is shown, because it's
not allocated yet, so pass the source to the boxpointer and adjust
the arrow at the next paint.
https://bugzilla.gnome.org/show_bug.cgi?id=694264
According to the design mockups, the app picker should follow the
recent view pattern as used by applications, where the user is first
offered a subset of applications he/she is likely to start, and only
then allow switching to the full set of installed applications.
So implement the ability to manage several views in AppDisplay and add
FrequentView as additional view, which uses the existing ShellAppUsage
to display a list of frequently used applications.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
While a group is open, we want to block events on items underneath,
but still allow interaction with components outside the app display
as well as scrolling of the view as a whole.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
App folders are intended for grouping some applications, not to
assign a category to every single application, so we will only
create folders for a selected subset of the existing categories.
Software/Alacarte will eventually allow to create/modify those
folders, so store the setting in GSettings so that it can be
shared with those applications.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
At the moment when loading the applications, each app is inserted
at its correct (alphabetical) position. Avoid this overhead by
loading all apps first, then sort them once and fill the grid with
the sorted actors.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
AllView will be updated to allow app folders in addition to app
launchers. Folders will pop up in the existing view, so add an
additional stack widget into the hierarchy which popups will use
as parent.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
We are going to introduce app folders, which will also present an
alphabetical list of applications, but use a different UI. In
preparation for that, split out the item logic into an abstract
base class.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
With categories removed, the separation between AllAppDisplay and
ViewByCategories no longer makes sense. Also use this opportunity
to rename the outdated AllAppDisplay to AppDisplay; it will
eventually be used to manage different views.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
AppIcon is just a tiny wrapper around BaseIcon, which does not add
anything over using BaseIcon directly, so merge its code with
AppWellIcon. As the concept of the "app well" has not been used
since well before 3.0, use AppIcon as name for the merged class.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
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
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
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
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 simply hide the label when the popup is opened instead of relying
on the popup state when the hover state change.
To do this we replace the flag isMenuUp by a 'menu-state-changed' signal
on the AppWellIcon. This simplifies the dash label visibility handling
code that need additional changes for the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=657315
We explicitly include NoDisplay applications in the ShellAppSystem because
we want app tracking for them, but we explicitly filter NoDisplay applications
out when showing them to the user because we don't want to show them to the
user. We also based our "All" apps view on a flattened list of apps. While
we did check for NoDisplay on the app item itself, we didn't check against
its parents. Refactor the app display view to not use a separate flat list
of applications, but instead a concatenation of all the applications in all
the loaded categories.
https://bugzilla.gnome.org/show_bug.cgi?id=658176
As shown in the previous commits, synchronous search is easily implemented
by the asynchronous search API. The only reason we still have a
synchronous search API is of historical reasons. Well, we're not a museum,
and git log can keep our fossils safe if need be....
https://bugzilla.gnome.org/show_bug.cgi?id=675328
Instead of using an St.Tooltip to show the app's name under the icon,
manually position a new St.Label ourselves. Make sure to keep the label
hidden when right-clicking so it doesn't get in the way of the popup menu.
Only one tooltip/label will be displayed at a time.
https://bugzilla.gnome.org/show_bug.cgi?id=666166
The last patch in the sequence. Every place that was previously
setting prototype has been ported to Lang.Class, to make code more
concise and allow for better toString().
https://bugzilla.gnome.org/show_bug.cgi?id=664436
All classes that have at least one other derived class (and thus
benefit from the framework) have been now ported. These includes
NMDevice, SearchProvider, AltTab.SwitcherList, and some other
stuff around.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
The Lang module in gjs has recently gained a small yet powerful
Class framework, that should help improve the readability of code
when using complex inheritance.
This commit starts porting shell code, by rewriting all classes in
popupMenu.js (and all derived classes) to Lang.Class.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
The dash object is currently exposed as a public object.
It's only used outside of the overview for the dash object's
iconSize property though.
This commit makes the dash object private and proxies the dash
iconSize property to the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
Since almost all of the callers of shell_app_activate were using the
default workspace (by passing -1), remove that parameter.
Add a new shell_app_activate_full() API which takes a workspace as
well as a timestamp; previously we might have been ignoring event
timestamps from elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=648149
This dramatically thins down and sanitizes the application code.
The ShellAppSystem changes in a number of ways:
* Preferences are special cased more explicitly; they aren't apps,
they're shortcuts for an app), and we don't have many of them, so
don't need e.g. the optimizations in ShellAppSystem for searching.
* get_app() changes to lookup_app() and returns null if an app isn't
found. The semantics where it tried to find the .desktop file
if we didn't know about it were just broken; I am pretty sure no
caller needs this, and if they do we'll fix them.
* ShellAppSystem maintains two indexes on apps (by desktop file id
and by GMenuTreeEntry), but is no longer in the business of
dealing with GMenuTree as far as hierarchy and categories go. That
is moved up into js/ui/appDisplay.js. Actually, it flattens both
apps and settings.
Also, ShellWindowTracker is now the sole reference-owner for
window-backed apps. We still do the weird "window:0x1234beef" id
for these apps, but a reference is not stored in ShellAppSystem.
The js/ui/appDisplay.js code is rewritten, and sucks a lot less.
Variable names are clearer:
_apps -> _appIcons
_filterApp -> _visibleApps
_filters -> _categoryBox
Similarly for function names. We no longer call (for every app) a
recursive lookup in GMenuTree to see if it's in a particular section
on every category switch; it's all cached.
NOTE - this intentionally reverts the incremental loading code from
commit 7813c5b93f. It's fast enough
here without that.
https://bugzilla.gnome.org/show_bug.cgi?id=648149
The specs call for a 2 pixel gap between the panel and its menus,
though we need to specify this as 4 pixels, since it's relative to the
bottom of the icon/title, not the bottom of the panel (up until now,
the point of the menu arrow was actually overlapping the menu's
highlight underline).
Also, move the gap specification into the CSS, since it makes more
sense there.
https://bugzilla.gnome.org/show_bug.cgi?id=655627
Theme authors now have the power (and responsibility) of creating fade
effects with the new CSS length property '-st-fade-offset'. A value of
0 disables the effect.
This new CSS approach replaces the current programmatic toggle of
the 'vfade' property. A new CSS style class name 'vfade' is used as
a replacement for the old property.
https://bugzilla.gnome.org/show_bug.cgi?id=651813
A "cosmetic" code arrangement I requested in code review resulted
in one too few items being removed from the queue for each incremental
chunk of icons added. Fix.
https://bugzilla.gnome.org/show_bug.cgi?id=648739
ViewByCategories._removeAll clears the sections, but the filter passed
to view still expects them to exists. Therefore, refresh the view
after the section has been rebuilt and the All filter reapplied.
https://bugzilla.gnome.org/show_bug.cgi?id=645801
While we have menu for an app icon open, we want to show the prelight
for the item instead of removing the prelight when the user mouses
away from the item and into the menu, and if there's a tooltip
(like for the dash), we want to show the tooltip immediately when
the menu is popped up.
https://bugzilla.gnome.org/show_bug.cgi?id=642871
When right-clicking on an AppWellIcon, the icon will become focused,
which (presumably via style-changed) invalidates its current
allocation, causing "icon.y" to return 0 until it has been
reallocated, messing up our idea of where in the AppDisplay the icon
is. Work around this by calling get_allocation_box() instead.
https://bugzilla.gnome.org/show_bug.cgi?id=645162
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
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
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.
As the dash is one of the primary drop targets for dragging application
launchers, it's reasonable to use the dash icon size for app icons'
drag actors, especially with the larger size now used in the application
view.
https://bugzilla.gnome.org/show_bug.cgi?id=639428
The view might get mapped before the filters have been added, so
trying to reset to the "All" filter will throw an exception. Fix
by only do the reset if the filters have been initialized.
When switching to the app view, it is unlikely that a user is
going to select an application from the same filter list as the
last time the view was used, so reset the view to the "All" filter
on switch.
https://bugzilla.gnome.org/show_bug.cgi?id=641987
When switching to the application view, the view is still scrolled
to the position it had when left previously. Given that it is rather
unlikely that the application the user wants to select is located close
to that position, it appears beneficial to start at a predictable
position, so make sure that the scroll position is always reset to
the top.
https://bugzilla.gnome.org/show_bug.cgi?id=641987
With workspace thumbnails, we don't switch workspaces when dragging windows
between workspaces or adding new workspaces, so we also shouldn't switch
on launch.
* Add workspace parameters to shell_doc_system_open(),
shell_app_activate, shell_app_open_new_window()
* Pass a 'params' object when activating items in the overview with
two currently defined parameters: workspace and timestamp. (timestamp
is only implemented where it is easy and doesn't require interface
changes - using the global current timestamp for the shell is almost
always right or at least good enough.)
https://bugzilla.gnome.org/show_bug.cgi?id=640996
With automatic workspace management, explicit controls to add and
remove workspaces are no longer necessary. We also can remove the
use of addWorkspace for middle-button-click on a launcher since
launching on the last empty workspace will do the right thing.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
When checking the type of a DND source, instead of checking
'instanceof Workspaces.WindowClone' accept any actor with realWindow
and metaWindow properties. This will be useful to support a separate
type of actor dragged from workspace thumbnails.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
For historical reasons, we had both StClickable and StButton, which
were nearly identical. StButton was more widely-used, so keep that and
port all StClickable users to that.
https://bugzilla.gnome.org/show_bug.cgi?id=640583
With general support for swipe-scrolling in the overview, there is
no reason to limit the behavior to workspaces. It is equally useful
for scrolling through the grid of available applications, so enable
swipe-scrolling for the app view.
https://bugzilla.gnome.org/show_bug.cgi?id=635034
AppWellIcon is used both in the dash and view selector. As the dash
requires manual sizing, it is not possible to set the icon size used
in the view selector in the CSS, but icons will use the default size
(unless set manually as in the dash).
Expose the params parameter of BaseIcon and enable manual resizing
only for AppWellIcons in the dash.
https://bugzilla.gnome.org/show_bug.cgi?id=639428
The popup menus of application icons in both the dash and the app view
are positioned on the right of the icon. In the case of the dash this
results in the menu being displayed off-screen in RTL locales, so move it
to the opposite side instead.
https://bugzilla.gnome.org/show_bug.cgi?id=635645
Current mockups display all search results as icons as used by
application results, so change the default result display to use
iconGrid/BaseIcon. Remove the custom application results display,
as it is no longer needed.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
Being no longer an independent menu pane, both the toggle() and
close() functions are no longer needed, and the view's structure
can be simplified a bit.
Also update the style to fit into the view selector.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
The new dash implementation is a single-column vertical sidebar,
whose items are scaled dynamically to fit the available height.
If the height is still exceeded after scaling down to a minimum
item size, excess items are cut off.
The now unused old dash implementation is renamed to OldDash, as
its code will be used as a base for the new view selector element.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
Each menu is a focus manager group, but there is also some explicit
focus handling between non-hierarchically-related widgets. Eg, to move
between menus, or from a menubutton into its menu.
https://bugzilla.gnome.org/show_bug.cgi?id=621671
All mockups now use a representation for documents/places similar to
the one used for applications. Rename AppIcon to BaseIcon and move its
code together with WellGrid out of appDisplay to stress their general
usefulness.
https://bugzilla.gnome.org/show_bug.cgi?id=625887
Extend WellGrid with an optional rowLimit parameter and an accessor
function for the grid's items, then use it to replace the custom
container used to display the application search results.
Also adjust the spacing of the search results slightly to make it
consistent with the app well.
https://bugzilla.gnome.org/show_bug.cgi?id=622446
Return a DND.DragMotionResult constant from delegate _handleDragMotion
methods as well as the existing return value from the drag monitor method dragMotion.
https://bugzilla.gnome.org/show_bug.cgi?id=607821
"text-align" allows setting the alignment of text, with respect to
other lines and allocated space, without requiring a reference to
the ClutterText (which is private for most widgets).
If not specified, all text is left-aligned.
https://bugzilla.gnome.org/show_bug.cgi?id=622447
First, we were passing an incorrect timestamp to
meta_display_focus_the_no_focus_window - fix that.
The invocation of set_focus_app to the started app there couldn't
really work, because (if the above call had worked) we'd get the
X reply *after* the started app.
What we need to untangle here is the distinction that's now made in
ShellApp between _STATE_STARTING and _STATE_RUNNING. A nice way to
start doing this is to rebase ShellWindowTracker to only be concerned
with app states. Concretely, the current "has windows implies
running" logic now lives just inside shell-app.c.
Rename the app-running-changed signal to be app-state-changed. This
will ultimately be useful so that inside the panel, we can track
the last started app.
https://bugzilla.gnome.org/show_bug.cgi?id=620899
As the design calls for smooth transitions whenever possible, use
a similar fade effect for the all-apps and more-docs menus as for
the panel menus.
https://bugzilla.gnome.org/show_bug.cgi?id=620775
When the app well doesn't contain any applications, it displays a placeholder text
to indicate that it's a drop target. When porting WellGrid from St.Bin to St.BoxLayout,
the call to set_child() to set the text was overlooked.
https://bugzilla.gnome.org/show_bug.cgi?id=617281
Currently, only the base style class is set in the constructor, the
style update according to the state of the represented app is deferred
until the actor is shown.
As existing icons are destroyed and recreated when the number of icons
changes, this behavior causes the icons of running apps to flicker if
CSS transitions are used.
Set the style directly in the constructor and update the code to not
delay style updates until the actor is shown - StWidget does defer
expensive calculations until the actor is mapped anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=620782
Separate out the main app view into different sections based on the categories
in the desktop file. The configuration is done via gmenu and the desktop menu
specification, we set XDG_MENU_PREFIX="gs-" on startup, so that gmenu reads
gs-applications.menu, which we install.
There is no support for "submenus" - only the menus directly under
Applications will be displayed as categories.
https://bugzilla.gnome.org/show_bug.cgi?id=614131
When dragging windows in linear view, the workspace zooms out to
allow moving the window to other workspaces. Enable the same
behaviour for items dragged from the dash.
https://bugzilla.gnome.org/show_bug.cgi?id=618055
This is our convention.
The only exceptions are double quotes for words in comments that give
them a special meaning (though beware that these quotes are not truly
necessary most of the time) and double quotes that need to be a part
of the output string.
It was previously possible to add a workspace above the maximum workspaces
limit by dragging an item to the "add workspace" button or using the middle
mouse button click.
Provide the user with feedback in the info bar when it is not possible to create
a new workspace or remove the current workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=591645
This ensures that we launch the new instance of an application on the newly
added workspace in the grid view, in which we don't make the newly added
workspace active by default.
https://bugzilla.gnome.org/show_bug.cgi?id=591645
Allow using the middle mouse button to open a new instance of an
application on a new workspace. The middle mouse button function
can be achieved by clicking the left and right mouse buttons
together with a two buttons mouse or holding Ctrl while clicking
with a single button mouse.
https://bugzilla.gnome.org/show_bug.cgi?id=591645
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
