Commit Graph

7706 Commits

Author SHA1 Message Date
Jasper St. Pierre
bc317bf3f2 popupMenu: Remove 'sensitive' input param
It's hard to implement properly, was broken, and unused. If somebody
really wants it, they can call setSensitive after constructing the item.

https://bugzilla.gnome.org/show_bug.cgi?id=702539
2013-07-15 12:34:22 -04:00
Jasper St. Pierre
5c036eadf9 popupMenu: Only allow one submenu to be open at a time
When the user opens another submenu, close the first one.

https://bugzilla.gnome.org/show_bug.cgi?id=702539
2013-07-15 12:34:22 -04:00
Jasper St. Pierre
263474705b popupMenu: Emit open-state-changed at the start of animating a submenu
Doing it at the end has confusing semantics, especially as there is
this point where isOpen is true, but the corresponding open-state-changed
has not been emitted.

https://bugzilla.gnome.org/show_bug.cgi?id=702539
2013-07-15 12:34:22 -04:00
Jasper St. Pierre
1e781ec78f popupMenu: Remove connectSubMenuSignals
The code here is a bit messy, as the signal disconnection is handled
in two different places. Share code in a better, different way.

https://bugzilla.gnome.org/show_bug.cgi?id=702539
2013-07-15 12:34:22 -04:00
Jasper St. Pierre
ef1eabf033 popupMenu: Ignore submenus when getting the column widths
The new designs don't want these to be aligned the same way.

https://bugzilla.gnome.org/show_bug.cgi?id=702539
2013-07-15 12:34:22 -04:00
Jasper St. Pierre
2fa40555e6 popupMenu: Simplify allocation code
Use ClutterActor.allocate_align_fill() so we don't have to do
this math ourselves. At the same time, clean up the RTL handling
so that it's easier to follow.

https://bugzilla.gnome.org/show_bug.cgi?id=702539
2013-07-15 12:34:22 -04:00
Jasper St. Pierre
2aae272d86 popupMenu: Don't close submenus when the toplevel container is closed
It seems this behavior at one time was intentional, but I (along with
the designers) think it looks ugly having the menu having its insides
shrinking and shifting around while fading out of existence.

There's two cases where we currently explicitly try to animate the
submenu closed -- when an item is clicked inside the submenu, and
when the toplevel closes. This removes both of those.

The user expectation is that submenus will be closed the next time the
toplevel is open even if they were open before, so force submenus closed
when the toplevel finishes fading out, without any animation.

https://bugzilla.gnome.org/show_bug.cgi?id=702539
2013-07-15 12:24:27 -04:00
Jasper St. Pierre
7db0900cc8 popupMenu: Introduce a way of closing toplevels from sections
As the aggregate menu will be built out of sections from each
of the menus, we need to ensure that activating an item in one
of these sections can close the main menu, even when it is not
a menu item. The new API also needs to be flexible enough to
ensure that animations can be controlled, like the buttons that
lock the screen or launch a new session.

Port the user menu to use this new API as well.

https://bugzilla.gnome.org/show_bug.cgi?id=702539
2013-07-15 12:01:07 -04:00
Jasper St. Pierre
c1e2d66abd popupMenu: Add a simple way to get the toplevel for a submenu / section
This will be used to avoid some nasty signal propagation when wanting to
rework how sections / submenus work.

https://bugzilla.gnome.org/show_bug.cgi?id=702539
2013-07-15 12:01:07 -04:00
Florian Müllner
78b1ba56ce calendar: Make the events-list a fixed width
Commit 929636ebd0 removed the fixed width of the calendar, while
commit cb45a38838 only added it back at max-width (resulting in
width changes of the calendar while browsing days).

https://bugzilla.gnome.org/show_bug.cgi?id=704200
2013-07-14 17:32:46 +02:00
Jiro Matsuzawa
5385205b8e l10n: Update Japanese translation 2013-07-14 23:57:58 +09:00
Dušan Kazik
5c8bbb511e Updated slovak translation 2013-07-14 14:37:21 +02:00
Lionel Landwerlin
fde01f0b71 st-theme-node: invalidate cached size when initializing paint state
https://bugzilla.gnome.org/show_bug.cgi?id=703997
2013-07-13 08:31:18 +01:00
Lionel Landwerlin
1c04ae3216 st-theme-node: fix obvious size comparison error
https://bugzilla.gnome.org/show_bug.cgi?id=703997
2013-07-13 08:31:14 +01:00
Ray Strode
35b4907e52 loginDialog: force user list and prompt to be the same width 2013-07-12 14:38:40 -04:00
Ray Strode
2431b8e021 loginDialog: make prompt entry wider
This makes it match mock ups better and looks more visually
pleasing.

https://bugzilla.gnome.org/show_bug.cgi?id=702308
2013-07-12 11:53:09 -04:00
Ray Strode
bd5c04b923 loginDialog: drop padding between buttons and entry
Now that we preallocate space for the prompt message there is
a lot of loose space between the entry and the buttons.

This commit helps tighten things up by getting rid
of the large top padding set above the login buttons.

https://bugzilla.gnome.org/show_bug.cgi?id=702308
2013-07-12 11:52:52 -04:00
Ray Strode
6e00b6e214 loginDialog: pre-allocate prompt message height
Right now things jump around if a message comes in.
This commit makes sure there's room for a message to start.

https://bugzilla.gnome.org/show_bug.cgi?id=702308
2013-07-12 11:52:39 -04:00
Emilio Pozuelo Monfort
c9b079cbb5 StWidget: use a handler id to disconnect the callback
g_signal_handlers_disconnect_by_func() is much more expensive
than g_signal_handler_disconnect(), so use the latter.

https://bugzilla.gnome.org/show_bug.cgi?id=704077
2013-07-12 13:38:47 +02:00
Victor Ibragimov
9163372786 Tajik translation updated 2013-07-12 16:06:48 +05:00
Florian Müllner
dabcd29fb6 panelMenu: Close menu when hiding the corresponding button
A PanelMenuButton added to the top bar might not be visible at all
times. If it is hidden while the corresponding menu is open, we
currently don't do anything at all, e.g. the menu remains open
pointing to an arbitrary location in the top bar.
Instead, close the menu automatically in that case.

https://bugzilla.gnome.org/show_bug.cgi?id=703540
2013-07-11 17:14:02 +02:00
eternalhui
d36e435801 update Simplified Chinese (zh_CN) translation 2013-07-11 18:11:52 +08:00
Lionel Landwerlin
a18fb27d0f st-theme-node: let paint states take weak ref on theme nodes
When the St theme is changed, the StThemeContext unrefs all the theme
nodes cached in it's internal hash table, then emits a signal to
notify all theme nodes that the current theme has changed.

The problem is that the first StWidget to catch a theme changed signal
will trigger a "style-changed" signal catched by its children first.
So the theme changed signal can't be processed properly to cleanup
StThemeNodePaintState before recomputing the theme.

This patch adds a weak ref to the StThemeNode in the
StThemeNodePaintState to ensure paint states are properly cleaned up
when the associated StThemeNode is freed.

https://bugzilla.gnome.org/show_bug.cgi?id=703859
2013-07-10 20:27:38 +01:00
Florian Müllner
2dbe511519 Bump version to 3.9.4
Update NEWS.
2013-07-10 19:50:29 +02:00
Florian Müllner
e031a5d28b st-theme-node: Update corner textures on allocation size changes
Commit 318283fc70 optimized box-shadow rendering by not recreating
shadow materials on every allocation change. Other handles cannot
be reused and are updated regularly, however the patch missed the
cached corner materials - while those can be reused, we still need
to ensure that the currently used paint state references them.

https://bugzilla.gnome.org/show_bug.cgi?id=703909
2013-07-10 17:35:11 +02:00
Florian Müllner
f9b32474b0 st-theme-node: Don't update resources on each paint
Up to commit 318283fc70, resources were only updated when
the allocated size had changed. There is no good reason to change
this for theme nodes without box shadows.

https://bugzilla.gnome.org/show_bug.cgi?id=703909
2013-07-10 17:35:11 +02:00
Florian Müllner
53d268a7ef st: Remove support for fixed positioning in BoxLayout
It is the job of layout containers to arrange their children; having
a hidden feature that *also* allows children to be positioned freely
outside the parent's allocation is just odd.
With the last user of the feature gone, kill it.

https://bugzilla.gnome.org/show_bug.cgi?id=703808
2013-07-09 23:19:20 +02:00
Florian Müllner
70da558802 overview: Add coverPane to stack instead of BoxLayout
The event catcher that covers the entire primary monitor during
transitions is currently inside a BoxLayout, relying in its
odd support for fixed position actors.
We already have a proper stack widget in place, move it there.

https://bugzilla.gnome.org/show_bug.cgi?id=703808
2013-07-09 23:19:20 +02:00
Florian Müllner
11215374ff lookingGlass: Use uiGroup as parent instead of panelBox
Currently lookingGlass relies on some odd BoxLayout behavior, which
allows children to use fixed positioning without affecting the parent's
size request. As this behavior is scheduled for removal, add the
looking glass dialog directly to Main.uiGroup.

https://bugzilla.gnome.org/show_bug.cgi?id=703808
2013-07-09 23:19:20 +02:00
Florian Müllner
cb45a38838 calendar: Fix line-wrapping of calendar events
Commit 929636ebd0 broke line-wrapping of longish calendar events,
add back the required CSS width.

https://bugzilla.gnome.org/show_bug.cgi?id=703893
2013-07-09 23:19:19 +02:00
Florian Müllner
bb4d430ebf style: Fix extension list style in looking glass
No idea how this got unnoticed since forever, but code and stylesheet
didn't quite agree on the same name ...

https://bugzilla.gnome.org/show_bug.cgi?id=703807
2013-07-09 22:06:13 +02:00
Florian Müllner
c17f84ca23 style: Fix focused app view controls
Moving from fixed width to horizontal padding for the app view control
buttons broke the focus style, in that buttons may change size on
keyboard focus changes. Fix this by using the correct horizontal padding
when focused.

https://bugzilla.gnome.org/show_bug.cgi?id=703807
2013-07-09 22:06:13 +02:00
Florian Müllner
0ae1f9ffc7 modalDialog: Minor coding style fix
https://bugzilla.gnome.org/show_bug.cgi?id=703807
2013-07-09 22:06:13 +02:00
Ray Strode
d15bcd9845 loginDialog: don't call nonexistent setInitialKeyFocus function
commit ea02380c15 changed the login
dialog to not use ModalDialog anymore.  There's still one lingering
setInitialKeyFocus method call in the source, which will cause an
exception to be thrown when users have their user list disabled.

This commit fixes that.

https://bugzilla.gnome.org/show_bug.cgi?id=703874
2013-07-09 12:52:18 -04:00
Lionel Landwerlin
f79a11d993 st-theme-node: init cached state properly 2013-07-09 11:25:28 +01:00
Lionel Landwerlin
9391d9d11b st-theme-node: reuse box-shadow materials between paint states when possible 2013-07-09 11:25:24 +01:00
Lionel Landwerlin
aee90a3116 st-theme-node: refactor calls to render css box 2013-07-09 11:24:26 +01:00
Lionel Landwerlin
ffac5279a7 tests: add animated box-shadow test to demo optimized painting 2013-07-09 11:24:26 +01:00
Lionel Landwerlin
318283fc70 st: optimize box-shadow rendering
Currently the box-shadow is rendering is done like this :

The first time we want to render a node that requires a box-shadow, St
creates an cogl offscreen surface of the size of the allocation and
renders the box into this offscreen buffer using modulation on the
alpha channel, this buffer is then blurred according to the CSS
parameters.

The problem with this method is that every time an StWidget is
resized, its box-shadow offscreen buffer has to be resized and
therefore rendered and blurred.

This patches propose an optimization for this use case by rendering
the box-shadow only once but at a size that is independent of the
StWidget's size. Then every time we need to paint this box-shadow, we
just render this offscreen buffer using a 9-slices.

This method only works when the allocation of the widget is bigger
than the minimum shadow size on which we can apply a 9-slices, that is
given my the radius of the corners. If the allocation is smaller than
this minimum size, we then fallback to the fully render/blur the
shadow (like before this patch).

https://bugzilla.gnome.org/show_bug.cgi?id=689858
2013-07-09 11:24:26 +01:00
Jasper St. Pierre
3582ba0c77 layout: Don't use the input mode to block events to windows
Instead, use the standard Clutter scene graph and our Chrome system.

This also removes our last use of the input mode, so remove that as
well.

https://bugzilla.gnome.org/show_bug.cgi?id=700735
2013-07-08 17:05:17 -04:00
Jasper St. Pierre
985d0c786c global: Automatically unshape the stage X window when we take a modal
This prevents the "client" from having to do it, and removes one part
of the FULLSCREEN input mode.

https://bugzilla.gnome.org/show_bug.cgi?id=700735
2013-07-08 17:05:17 -04:00
Jasper St. Pierre
9c8c282e08 global: Clean up the code that actually sets the shape on the stage
Instead of having "dummy" setters that do work, split out the parts
that do work into their own function.

https://bugzilla.gnome.org/show_bug.cgi?id=700735
2013-07-08 17:05:16 -04:00
Jasper St. Pierre
93dc7a51c0 Rework window / actor focus handling
The duality of the Clutter's key focus and mutter's window focus has long been
a problem for us in lots of case, and caused us to create large and complicated
hacks to get around the issue, including GrabHelper's focus grab model.

Instead of doing this, tie basic focus management into the core of gnome-shell,
instead of requiring complex "application-level" management to get it done
right.

Do this by making sure that only one of an actor or window can be focused at
the same time, and apply the appropriate logic to drop one or the other,
reactively.

Modals are considered a special case, as we grab all keyboard events, but at
the X level, the client window still has focus. Make sure to not do any input
synchronization when we have a modal.

At the same time, remove the FOCUSED input mode, as it's no longer necessary.

https://bugzilla.gnome.org/show_bug.cgi?id=700735
2013-07-08 17:05:16 -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
Trần Ngọc Quân
2f165aade8 Updated Vietnamese translation 2013-07-06 18:29:12 +07:00
Nguyễn Thái Ngọc Duy
2c502aec45 po/vi: import from Damned Lies 2013-07-06 18:24:32 +07:00
Benjamin Steinwender
6bbf246752 Updated German translation 2013-07-05 17:24:23 +02:00
Andika Triwidada
0b3e8e29cf Updated Indonesian translation 2013-07-05 10:23:35 +07:00