Re: Workspaces slowing me down.
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 still leaving you stuck with the workspaces in a vertical column - which you cannot change. It sounds to me like someone really needs to come along and write as expo type plugin, or at the very least - give the user the ability to decide how workspaces are stacked and how they appear. sorry, i wasn't of more help. i had thought atleast being able to do static-workspaces might be useful to you. jordan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: The good, the bad, the insane
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 sake, not necessarily saving energy. The menu has the same function that the power button and closing the window list do: suspending. Shutting down, when you think about it, is something that you rarely have to do (some people don't shut down their desktops for long periods of time, while others only shut them down once or twice per day). Compared to navigating a program's GUI, switching workspaces/windows, and launching applications, this is something that is rarely done, so, for the sake of consistency, it would make sense to optimize towards a behavior that, for most users, would be preferable when walking away (suspending). The preferred way to shut down, which indicates that you're done using the computer, is to log out first and use GDM (which takes a few more seconds, but I can't think of a situation where you have to shut down a computer faster that that). Pressing the alt-button shows the Power Off button, logging out so that you can shutdown requires more work and delay especially after work where a quick shutdown is badly needed. That design decision again was discussed in length and that is invalid, it works obviously to the designer's laptops while the rest of the desktop world are suffering. When was this made invalid; are there plans to reverse the decision? I haven't read of this. Or, by invalid, do you mean we would like it the other way? I'm not saying you're wrong, I only want to clarify, as I haven't read anything about the decision being reversed. Also, I use a desktop, and I can't see how holding the Alt key for a second or logging out is really such a big deal. It's unnecessary, sure, but it isn't exactly the end of the world as I hear so many people saying. It reminds me of the decision to not use minimize/maximize buttons by default; you can still maximize other ways, and it makes the desktop feel more consistent and minimal by default. How much harder is it to press the Alt key and click? I don't mean to sound rude, and I'm sorry if I come across as that, but it really is an incredibly small regression if you think about it, relative to some other problems like over-crowded settings dialogs not being visible on small screens. Even yelp, the GNOME 3 help program, tells users how to shut down (with the Alt key as well as the preferred method), so the new behavior is just as discoverable as any other keyboard shortcut. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Gnome bugs for 3.0.2 Push
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 no serious testing, and so is not a candidate for 3.0.2. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: List / Support [Was: We want task bar back. Pretty please.]
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 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 usually happen on this list. It's more used to help users and occasional developers (extensions), or to get feedback. Cheers ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: gnote integration
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 http://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Sending notification
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 again: Which is the preferred way of sending notifications in gnome-shell ? Erick Thxs -- El derecho de expresar nuestros pensamientos tiene algún significado tan sólo si somos capaces de tener pensamientos propios. El miedo a la libertad, Erich Fromm ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Sending notification
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 that's why, there should be one way to do it
according with the shell design, so again:
Which is the preferred way of sending notifications in gnome-shell ?
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);
For anything else, and in particular for things that should be
associated with objects (apps, people, folders, tasks...), write your
own Source class.
You find extensive docs in js/ui/messageTray.js, and examples in
NotificationDaemon, TelepathyClient and some extensions. It is extremely
flexible (in the end you can just replace the whole contents of the
notification and have your own widgets) and should be enough for
anybody.
From an application:
Use libnotify. No other method is currently supported.
notify_init(Your App Name)
notification = notify_notification_new(Summary, Content of the
notification, face-smile);
notify_notification_show(notification, error);
(There was discussion for allowing libappindicator, but it hasn't
happened yet)
If you want to do something more complex than that from an app, expose
your use case and we'll see about improving the API.
Giovanni
PS: if you're an app, and want a quick and dirty method for sending
complex notifications, without an extension, you can inject JS code with
org.gnome.Shell.Evaluate(s) - (b, s) on /org/gnome/Shell at
org.gnome.Shell.
signature.asc
Description: This is a digitally signed message part
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Sending notification
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);
For anything else, and in particular for things that should be
associated with objects (apps, people, folders, tasks...), write your
own Source class.
You find extensive docs in js/ui/messageTray.js, and examples in
NotificationDaemon, TelepathyClient and some extensions. It is extremely
flexible (in the end you can just replace the whole contents of the
notification and have your own widgets) and should be enough for
anybody.
This was what I meant, the application part I knew it
I tried this way but I wan't able to let the notification source
resident, until the user click on it.
I was even using the resident hint, anyway I'll try it again, I'll let
u know if anything else
BTW this should go into some tutorial or developer's preview of
gnome-shell or something like that
Erick
Thxs, really thxs for quick, super quick reponse
PS: if you're an app, and want a quick and dirty method for sending
complex notifications, without an extension, you can inject JS code with
org.gnome.Shell.Evaluate(s) - (b, s) on /org/gnome/Shell at
org.gnome.Shell.
This sound hackish
--
El derecho de expresar nuestros pensamientos tiene algún significado
tan sólo si somos capaces de tener pensamientos propios.
El miedo a la libertad, Erich Fromm
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Sending 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 content that won't be shown in the
banner });
source.notify(notification);
For anything else, and in particular for things that should be
associated with objects (apps, people, folders, tasks...), write your
own Source class.
You find extensive docs in js/ui/messageTray.js, and examples in
NotificationDaemon, TelepathyClient and some extensions. It is extremely
flexible (in the end you can just replace the whole contents of the
notification and have your own widgets) and should be enough for
anybody.
This was what I meant, the application part I knew it
I tried this way but I wan't able to let the notification source
resident, until the user click on it.
I was even using the resident hint, anyway I'll try it again, I'll let
u know if anything else
You need to call notification.setResident(true) before calling
source.notify(), and you need to have your own custom Source
(SystemNotificationSource calls .setTransient(true))
Note that resident will not force the notification into staying in
banner mode (that is, in the middle of the screen), it will just make
clicks on actions and on the background have no effect.
If you want to destroy on click, but not on action button press, connect
to clicked and call .destroy(). If you want to destroy on any action,
use the default behavior (.setTransient(false) and .setResident(false)).
Giovanni
signature.asc
Description: This is a digitally signed message part
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Sending notification
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 that's what I want 2. The problem is when the user click 'Close' button I added to the notification (which I connected to 'this.destroy'). That close the notification, and the source disappears from the notification bar if there was just one notification, and then if I launch a notification again and the user don't interact with it, the new notification does not stay in the bar, cause the sources is missing. Why this.destroy from the notification class remove the source from the notification bar ? Erick You need to call notification.setResident(true) before calling source.notify(), and you need to have your own custom Source (SystemNotificationSource calls .setTransient(true)) Note that resident will not force the notification into staying in banner mode (that is, in the middle of the screen), it will just make clicks on actions and on the background have no effect. If you want to destroy on click, but not on action button press, connect to clicked and call .destroy(). If you want to destroy on any action, use the default behavior (.setTransient(false) and .setResident(false)). Giovanni -- El derecho de expresar nuestros pensamientos tiene algún significado tan sólo si somos capaces de tener pensamientos propios. El miedo a la libertad, Erich Fromm ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: List / Support [Was: We want task bar back. Pretty please.]
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 usually happen on this list. It's more used to help users and occasional developers (extensions), or to get feedback. Thanks for the clarification Milan, that makes total sense, as IRC is used commonly used in development projects ~ an excellent way to do things in realtime...and obviously any bug reporting/tracking is commonly used in software development. So i would suppose that the distinction would be; the Gnome-Shell-list is mainly a user list, but also has shades of grey ~ as it is also used by the odd gnome-developer, and sometimes checked for feedback... gnome-shell doesn't not specifically have a devel-list, as other avenues are used instead... that's good to know. ~ as i do belong to other lists - where the distinction between user-lists and devel-list, is much more clear as in, there is a user-list and a devel-list. lol. :) anyways, thanks again - you have a great day! jordan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: gnome-shell-list Digest, Vol 31, Issue 107
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 Message-ID:4ddbac8f.6030...@sbcglobal.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 05/23/2011 06:47 PM, Allan E. Registos(x-mail) wrote: On Monday, 23 May, 2011 10:13 PM, Ryan Peters wrote: Pressing the alt-button shows the Power Off button, logging out so that you can shutdown requires more work and delay especially after work where a quick shutdown is badly needed. That design decision again was discussed in length and that is invalid, it works obviously to the designer's laptops while the rest of the desktop world are suffering. When was this made invalid; are there plans to reverse the decision? I haven't read of this. Or, by invalid, do you mean we would like it the other way? I'm not saying you're wrong, I only want to clarify, as I haven't read anything about the decision being reversed. Also, I use a desktop, and I can't see how holding the Alt key for a second or logging out is really such a big deal. It's unnecessary, sure, but it isn't exactly the end of the world as I hear so many people saying. It reminds me of the decision to not use minimize/maximize buttons by default; you can still maximize other ways, and it makes the desktop feel more consistent and minimal by default. How much harder is it to press the Alt key and click? I don't mean to sound rude, and I'm sorry if I come across as that, but it really is an incredibly small regression if you think about it, relative to some other problems like over-crowded settings dialogs not being visible on small screens. Even yelp, the GNOME 3 help program, tells users how to shut down (with the Alt key as well as the preferred method), so the new behavior is just as discoverable as any other keyboard shortcut. Of course it's not hard to press the Alt key, it just doesn't make any sense. And you really expect a user to open yelp in order to find out, how to power off his system ? Why is there a need to only have one option in the user menu ? a menu you open maybe once or twice a day ? If you only want one option, default should be Power Off, because you can suspend your laptop by closing the lid or with a function Key or Hardware button. Martin ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: gnome-shell-list Digest, Vol 31, Issue 107
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 confirm that you really intended to click on the Power Off button (but I'm getting off topic here). I have activated the extension, and I see the Suspend, Hibernate, Power Off buttons ... and that is not in the slightest a cluttered menu. It remains quite simple in fact. I understand the benefits of both approach, but I think the extension and the core functions should be reversed. The default should show the Suspend and Power Off buttons, and the extension should allow me to show only the Suspend button (and the Power one by pressing Alt). -Cyril On Tue, 2011-05-24 at 21:54 +0100, Martin Häsler wrote: 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 Message-ID:4ddbac8f.6030...@sbcglobal.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 05/23/2011 06:47 PM, Allan E. Registos(x-mail) wrote: On Monday, 23 May, 2011 10:13 PM, Ryan Peters wrote: Pressing the alt-button shows the Power Off button, logging out so that you can shutdown requires more work and delay especially after work where a quick shutdown is badly needed. That design decision again was discussed in length and that is invalid, it works obviously to the designer's laptops while the rest of the desktop world are suffering. When was this made invalid; are there plans to reverse the decision? I haven't read of this. Or, by invalid, do you mean we would like it the other way? I'm not saying you're wrong, I only want to clarify, as I haven't read anything about the decision being reversed. Also, I use a desktop, and I can't see how holding the Alt key for a second or logging out is really such a big deal. It's unnecessary, sure, but it isn't exactly the end of the world as I hear so many people saying. It reminds me of the decision to not use minimize/maximize buttons by default; you can still maximize other ways, and it makes the desktop feel more consistent and minimal by default. How much harder is it to press the Alt key and click? I don't mean to sound rude, and I'm sorry if I come across as that, but it really is an incredibly small regression if you think about it, relative to some other problems like over-crowded settings dialogs not being visible on small screens. Even yelp, the GNOME 3 help program, tells users how to shut down (with the Alt key as well as the preferred method), so the new behavior is just as discoverable as any other keyboard shortcut. Of course it's not hard to press the Alt key, it just doesn't make any sense. And you really expect a user to open yelp in order to find out, how to power off his system ? Why is there a need to only have one option in the user menu ? a menu you open maybe once or twice a day ? If you only want one option, default should be Power Off, because you can suspend your laptop by closing the lid or with a function Key or Hardware button. Martin ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Gnome bugs for 3.0.2 Push
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 uncommitted patches that we might to grab at the last minute. ! Already merged * Planning to merge x Not planning to merge After notes in detail on everything, I've grouped things into categories of what I'm planning to merge and not merge. - Owen GNOME Definitely Want To Have: == * d104f9210a8aed12bab7b99f433fe289b96bf808 [Ionut] PopupSliderMenuItem: intercept clicks outside the slider https://bugzilla.gnome.org/show_bug.cgi?id=646660 Sound indicator should provide a mute button Simple patch, fixes an easily reproducible, if minor issue x d2a16bca10fcc3be39895a99a1607483f4e65fdc [Ionut] altTab: Fix the appSwitcher's allocation https://bugzilla.gnome.org/show_bug.cgi?id=647807 App Switcher scrolling is broken This one is simple, but depends on fe08ebd for correct operation, and it's almost imposible to trigger alt-Tab scrolling. x fe08edbe2bf88aa43b643a8f8449dd49a3bafabe [Ionut] altTab: fix Alt+Tab scrolling on initial display https://bugzilla.gnome.org/show_bug.cgi?id=647807 App Switcher scrolling is broken Looks pretty safe, considering that we have undiagnosed crashes when showing altTab already, I'm not really comfortable changing around ordering by forcing an allocation. Does it make it better? Does it make it worse? Who knows. * bafd9c777ade647b2e31f3265ed8970f39f1843c [Ionut] https://bugzilla.gnome.org/show_bug.cgi?id=648765 history: Fix navigation when entering a repeat Safe, localized patch, easy to test and test the fix, but impact is very minor (misbehavior in looking glass only? in chat?) x 0d440bb0a2b3bb277533eb0177b3c7810bf544ea [Ionut] https://bugzilla.gnome.org/show_bug.cgi?id=648894 StTooltip: add missing break statement No user visible impact. (Only possible reason to add this would be an extension using tooltips) * 56d584b7c62bb5d04460d1e0d7abf5c3ac292468 https://bugzilla.gnome.org/show_bug.cgi?id=648983 workspace opacity is wrong after canceled drag Only affects a minor misbehave of a portion of the user interface that people don't usually touch. Patch is superficially completely safe, and easy to test. ! 88de26138a8b79d89884ff2eb6471c5a8e3b39ca shell-xfixes-cursor: missing XFree https://bugzilla.gnome.org/show_bug.cgi?id=642652 Major memory leak on mutter when using gnome-shell ! 72f9f482d6f1bcb53ea2bd1606818af1f33a5a8c st-private: Fix memory leak ! c975740f9228b2c53d79ac08ad704fca5f1c5b6e st-private: Correct fix for memory leak https://bugzilla.gnome.org/show_bug.cgi?id=649497 st-private: Fix memory leak x dcd07eb23ff763c84d898a4d9ec886001220eb49 [Ionut] https://bugzilla.gnome.org/show_bug.cgi?id=649508 StTextureCache: plug leak in not-found icon case Patch is not (fully) correct from my reading, don't think the part of the leak that is fixed is big enough to be worth cherry-picking the patch x fb384fc2910091f86058ae3b0021602796b5e0fe https://bugzilla.gnome.org/show_bug.cgi?id=649633 shell-tp-client: enable client recovery Doesn't make sense in the 3-0 branch - telepathy-glib usage is new in master. x https://bugzilla.gnome.org/show_bug.cgi?id=631576 Use upstream gettext instead the Glib one No end user impact, not a candidate x https://bugzilla.gnome.org/show_bug.cgi?id=649981 Use Shell.get_file_contents_utf8_sync over GLib.file_get_contents No end user impact, not a candidate * 63b1699a35b6206747dac0e8ed2ac583618a9e64 [Ionut] panel: Don't propagate button-release-event in _onCornerClicked() https://bugzilla.gnome.org/show_bug.cgi?id=649427 After triggering the Activities hotcorner, ignore clicks for a split second Very small patch, I gave it some pretty extensive testing; impact isn't big, but if the user happens to have the wrong timing could be annoying. x 48acc41698f21a122f5f920d171fd120218acd35 [Ionut] Don't crash when removing nameless user https://bugzilla.gnome.org/show_bug.cgi?id=647893 gnome-shell restarts when adding/remove an username without a name Sounds like it fixes a major problem, but I can't reproduce, and the patch doesn't make sense to me. x 986d72d9de055a4871e5a213bac5c022ddfd6c49 [Ionut] configure: remove support for evolution-data-server 1.2 https://bugzilla.gnome.org/show_bug.cgi?id=647395 Can't build due to calendar-server/calendar-sources.h:29:25: fatal error: glib-object.h: No such file or directory Just a cleanup, not relevant for 3.0.x x 71dfab97113d03d0ea722e071f513f53f8572eae [Ionut] altTab: remove erroneous/superflous pick https://bugzilla.gnome.org/show_bug.cgi?id=650317 crash in Alt+Tab due to bad pick I don't think we've root-caused this problem or fixed the crash x bee37b5bc4aa89174b6dc56289383d0f5bb4a200 [Ionut] lookingGlass: make Esc work on any page
Re: Applications Compatibility
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 moment, and for sure he switch to another DE. So my question is, how is GNOME shell was designed from the ground-up with compatibility between applications especially for those 3D apps? Is this a valid concern? I hope for 3.2 things will get easier. I've had issues in with 3D acceleration, on my 2 desktop machines (nvidia)... Some applications i use, recommend not using compositors at all however, compiz plays quite nice and works, so i use it - I've had the opposite experience. With compiz and multi-head (second display) acceleration usually got disabled and was at best hit-n-miss. GNOME3 is now working with a second display [not in fail-over mode] which is much appreciated. For me GNOME3's OpenGL based shell seems both faster and more robust than compiz + GNOME2. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Applications Compatibility
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 have any real issues. GNOME3 is now working with a second display [not in fail-over mode] which is much appreciated. For me GNOME3's OpenGL based shell seems both faster and more robust than compiz + GNOME2. and what sort of heavy-duty 3D applications are you actually using with your setup? You know, the kinds of applications that can turn compositors on their head? ie: gaming, transgaming, 3d animation, etc... faster? - it's not... you can't even reduce/increase the speed of your effects with the click of a mouse. the defaults for transitions in gnome-shell have slow timing - smooth yes, but slow moving from start to finish time so what exactly are you basing this on??? - possibly biased benchmarks made by developers, who clearly want people to use Mutter/gnome-shell and not compiz? your own eyes?? (in which case, you have no way of being able to tell the difference, as you probably can't stress mutter, and test against compiz - frame for frame). more robust? - if that was true -- then in any and all circumstances gnome-shell/mutter should have zero tearing, zero graphical errors, in situations that would break compiz. If you had read my comments to Allen, you would have noticed i gave examples as to where gnome-shell/mutter was anything BUT robust. One trip to youtube and watching gnome-shell reviews will show you that it isn't as robust as you think. You've (im assuming) even saw my screenshots from Maya (that i posted a month or so ago on the list). Compiz handles all this stuff fine, gnome-shell/mutter does not I'm not saying it's not going to get there, it probably will - but it ain't there yet. Also, Mutter doesn't even have much to compare with Compiz. I haven't seen mutter produce even a fraction of types of transitions/plugins/GFX that compiz can. When Mutter starts doing more complicated types of effects (like 3D, not just scale/zoom) we will see how it performs then. until you can speed up the effects, and there are more hardcore transitions/effetcs to equally compare - i think it's pretty hard to compare mutter to anything but metacity, or possibly cairo-compmgr. fail-over mode..? lol. fallback is what has kept gnome on my desktops (and many other users), i would hardly associate that with failure. it potentially means, down-the-line if gnome-shell gets to be more to my liking (or other people who aren't using it with gnome3) ~ we won't have already moved on to something like KDE, and completely ditched gnome! ~ that to me, means fallback mode is a success, and a good thing. jordan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Applications Compatibility
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 running F15, try
'mutter --replace' and see if your performance problems persist. It could
very well be a performance problem existing in Shell, but not in Mutter...
so, try there.
On Wed, May 25, 2011 at 12:20 AM, jordan triplesquaredn...@gmail.comwrote:
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 have any real issues.
GNOME3 is now working with a second display [not in fail-over mode]
which is much appreciated. For me GNOME3's OpenGL based shell seems
both faster and more robust than compiz + GNOME2.
and what sort of heavy-duty 3D applications are you actually using
with your setup? You know, the kinds of applications that can turn
compositors on their head? ie: gaming, transgaming, 3d animation,
etc...
faster? - it's not... you can't even reduce/increase the speed of your
effects with the click of a mouse. the defaults for transitions in
gnome-shell have slow timing - smooth yes, but slow moving from start
to finish time so what exactly are you basing this on??? -
possibly biased benchmarks made by developers, who clearly want people
to use Mutter/gnome-shell and not compiz? your own eyes?? (in which
case, you have no way of being able to tell the difference, as you
probably can't stress mutter, and test against compiz - frame for
frame).
OK, there's two things that people mean when they say fast or slow, and
I want to know which one you're thinking of.
Do the designed effects look smooth, but take too long to complete in your
mind? That's a design and UX issue, not at all a performance issue. With a
little hackery, you can see if this helps it a bit.
Alt+F2 'lg' to open the Looking Glass, and paste in:
St.set_slow_down_factor(0.5)
This is a developer tool to make animations slower for debugging cases where
they don't look right, but it's hard to see, but in your case it can make
animations faster. It will go away when you restart the shell... you can
make an extension that will run some code like this every time you start the
shell... or maybe it's worth making a gsetting for gnome-tweak-tool to pick
up (it's not a hard patch).
If the animations and effects look choppy, that's a performance issue, and I
truly apologize if you've experienced anything in the transitions like that.
more robust? - if that was true -- then in any and all circumstances
gnome-shell/mutter should have zero tearing, zero graphical errors, in
situations that would break compiz. If you had read my comments to
Allen, you would have noticed i gave examples as to where
gnome-shell/mutter was anything BUT robust. One trip to youtube and
watching gnome-shell reviews will show you that it isn't as robust as
you think. You've (im assuming) even saw my screenshots from Maya
(that i posted a month or so ago on the list). Compiz handles all this
stuff fine, gnome-shell/mutter does not I'm not saying it's not
going to get there, it probably will - but it ain't there yet.
I'm sorry. I haven't read up on many of your previous emails, and I've
probably asked this again before, but can you give some hardware and driver
details?
I read you are running on nvidia: what card or chipset, and I assume
you're running on the proprietary drivers here.
For something as simple as screen tearing, there's actually a lot of
complicated factors going into play here.
Also, Mutter doesn't even have much to compare with Compiz. I haven't
seen mutter produce even a fraction of types of
transitions/plugins/GFX that compiz can. When Mutter starts doing more
complicated types of effects (like 3D, not just scale/zoom) we will
see how it performs then. until you can speed up the effects, and
there are more hardcore transitions/effetcs to equally compare - i
think it's pretty hard to compare mutter to anything but metacity, or
possibly cairo-compmgr.
Both the Shell and Mutter are based on Clutter, which is OpenGL and has
pretty much supported 3D from day one.
Don't believe me? Alt+F2 'lg' to open the Looking Glass, and paste in:
global.get_window_actors().forEach(function(a) { a.rotation_angle_y =
a.rotation_angle_x = 5; });
To reset:
global.get_window_actors().forEach(function(a) { a.rotation_angle_y =
a.rotation_angle_x = 0; });
Feel free to try out something maybe a little more stressful:
Mainloop.timeout_add(1000/24, function() {
global.get_window_actors().forEach(function(a) { a.rotation_angle_y += 1;
}); return true; });
You can
