I tried this. It disables the dynamic workspaces. But unfortunately it does
not give horizontal workspace navigation. All the workspaces are in one big
vertical column. So, it is not much of a use to me sadly :(
I see what you are saying, it only solves one issue (static-workspaces),
while
On 05/23/2011 06:47 PM, Allan E. Registos(x-mail) wrote:
On Monday, 23 May, 2011 10:13 PM, Ryan Peters wrote:
Before I say anything, let me state that I am not a developer or
designer of this project. From what I've read *from* the designers,
though, the decision was made for consistency's
On 05/24/2011 01:45 AM, Jesper Andersen wrote:
MUTTER
Definitely Want to Have:
How about this one:
https://bugzilla.gnome.org/show_bug.cgi?id=597190
Window switcher and focus follows mouse
It certainly would be useful to me.
That patch hasn't even been committed yet, and so has gotten
Le lundi 23 mai 2011 à 12:24 +1000, Tim Cuthbertson a écrit :
On Mon, May 23, 2011 at 5:25 AM, Adam Tauno Williams
awill...@whitemice.org wrote:
Why? This is normal. Most projects have -devel lists / forums and user
lists / forums.
On this point, is there such a distinction for
If you don't mind having it, please try installing it.
On Tue, May 24, 2011 at 3:31 PM, philip ballinger p...@eyemotions.com wrote:
i wouldnt mind this extension.
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
Hi:
I want to know from the gnome-shell maintainers/developers
Which is the preferred way of sending notifications in gnome-shell ?
I can think of more than one, And some been hard than others to
implement but, and that's why, there should be one way to do it
according with the shell design, so
Il giorno mar, 24/05/2011 alle 13.12 -0400, Erick Pérez ha scritto:
Hi:
I want to know from the gnome-shell maintainers/developers
Which is the preferred way of sending notifications in gnome-shell ?
I can think of more than one, And some been hard than others to
implement but, and
What do you mean?
From an extension:
For short lived message, use
let source = new MessageTray.SystemNotificationSource();
let notification = new MessageTray.Notification(source, Title,
Content, { body: Additional content that won't be shown in the
banner });
source.notify(notification);
Il giorno mar, 24/05/2011 alle 13.41 -0400, Erick Pérez ha scritto:
What do you mean?
From an extension:
For short lived message, use
let source = new MessageTray.SystemNotificationSource();
let notification = new MessageTray.Notification(source, Title,
Content, { body: Additional
Now I have this problem:
I manage to create a Source and a new Notification subclass to add a
pair of buttons to the notification, One for Closing and one for doing
something else.
1. When the user don't interact with the first notification, the
notification stays in the notification bar, and
On this point, is there such a distinction for gnome-shell? I'd love
to be able to distinguish between devel and user discussions in my
mail client...
Actually, the #gnome-shell IRC channel and Bugzilla play the role of a
development list, so very few discussions between core developers
On 05/24/2011 04:50 PM, gnome-shell-list-requ...@gnome.org wrote:
Message: 1
Date: Tue, 24 May 2011 08:03:11 -0500
From: Ryan Petersslosh...@sbcglobal.net
To: Allan E. Registos\(x-mail\)allan_regis...@lavabit.com,
gnome-shell-list@gnome.org
Subject: Re: The good, the bad, the insane
Although you can change this behaviour with an extension, I tend to
agree.
If only one option, Power Off should be the one appearing by default.
In fact I see no compelling reason to have only one option. I would
rather have all the power option appearing in the menu than the dialog
asking you to
For gnome-shell, I've integrated below a list sent to me by Ionut Biru
and information about patches in the Fedora 3.0.1 RPM (mostly
suggestions from Dan Williams.)
Because of the number of patches *on* these lists, I'm not going to look at all
at stuff on master nobody proposed or outstanding
On Mon, 2011-05-23 at 00:30 -0400, jordan wrote:
This is one I think is a valid concern, I will also be using Multimedia
apps for recording and it looks like GNOME Shell is not the right _desktop_
_shell_ at this rate. I remember one poster here who complains, but with no
solution for the
I've had the opposite experience. With compiz and multi-head (second
display) acceleration usually got disabled and was at best hit-n-miss.
I have 2 displays and am running compiz 0.9.5 (with nvidia), no
problems at all - full hardware acceleration. Even with 0.8.6 running
2 displays, i didn't
First of all, Mutter is not the shell. Performance issues may be in either
Clutter/Cogl, Mutter, or the Shell/St, all things that didn't exist under
gnome2.
Mutter is now a library, but because of hysterical raisins, it also has its
own base WM that's extremely similar to metacity. If you're
17 matches
Mail list logo
