Re: [Feedback] hybrid GPU + multimonitor: partial success with Gnome-shell / Mutter 3.27.1 in Wayland mode
On Tue, Feb 06, 2018 at 05:06:02PM +0100, Cyrille Chépélov wrote: > Hi Jonas, > > responding slightly out of order (both below an inline); plus we've pretty > much already started to bring this onto the issue tracker where this > belongs: Thanks for filing those issues. > > > It'd also be good if you used the top of the master branch instead of > > 3.27.1 (both mutter and gnome-shell), as otherwise you might hit a set > > of bugs fixed during the development cycle. > > Now rebuilding to work top-of-master for Mesa, mutter & gnome-shell: > > * mesa: master at a5053ba27e > * mutter: master at 70fcf745 > * gnome-shell: master at 0b51ead00 > * gnome-shell-extensions: master at ae65a82 /(not strictly necessary >but to keep dpkg happy)/ > ... snip ... > > > > > * When /un/pluggin an external display through HDMI, the machine keeps > > > working, and could withstand an unlimited number of plug/unplug > > > cycles. > > This is also indeed expected to work. > > > > Note that when I did this work, I hit a nouveau bug that triggered > > freezes. I have not checked whether those have been fixed. > > Noted. As an aside, I noticed that when shutting down gnome-session + the > gdm3 service (going back to text mode), the "nouveau" kernel module remains > "used" (it increases by 1 each time gdm starts), which makes difficult > removing it for the purpose of powering down the GPU. Would eventually > report it on > https://bugs.freedesktop.org/buglist.cgi?component=Drivers%2FDRI%2Fnouveau_id=636975=Mesa=--- Should probably double check that we close nouveau KMS fd when terminating, but either way, the driver should be able to handle a process with a KMS fd open crashing either way. > ... snip ... > > > FWIW, when rendering the content for your nouveau connected monitor, we > > do so using the Intel GPU. After eglSwapBuffers(), we take the result, > > blit it onto a buffer on the nvidia GPU using nouveau, and hand that > > over to the monitor. > Ah, I wasn't aware of this. So basically for now 'hybrid mode' is > effectively using the iGPU for most tasks, while the dGPU is used as > effectively a PCI-to-HDMI bitmap-shipping dongle. > > So perhaps there may be an interesting alternative to GPU hotplug, if there > is a way to start nouveau (and the GPU) permanently but shut down most of > the engines (https://nouveau.freedesktop.org/wiki/KernelModuleParameters/ # > grep for "list of engines). Paying a /few /watts at idle to gain easy enough > monitor plug might be a good enough option for a while (I'll > investigate separately) FWIW, we still use OpenGL etc for the bitmap-shipping as long as the driver for the dedicated GPU supports the GLES 3 features we depend on. > ... snip ... > > > > 3. I had once a crash in native code called by javascript code, but > > > lost the backtrace before I could save it > > If it was a segmentation fault, you could set the SHELL_DEBUG env > > variable to "backtrace-segfaults" (in a way that gnome-shell will see it > > when starting). This will make gnome-shell to print Javascript > > backtraces to the journal when it hits a segmentation fault. > It was a segfault indeed. Added SHELL_DEBUG=backtrace-segfaults for next > time > > > * I once managed to move a Firefox (Quantum) window with a moving > > YouTube video from the main (i915) to the external (nouveau) screen, > > without an obvious causality on the crash that happens seconds later. > > FWIW, this wouldn't cause Firefox to switch to using the nvidia GPU for > > rendering, as we don't have a way to tell applications to change what to > > render with yet. > Makes sense. Again, the iGPU is plenty adequate for my needs, I really wish > GTX 1060 didn't omit the hardware muxer (or Gigabyte provided a no-nonsense > option without unnecessary hardware). You can still use the dGPU for rendering application content. IIRC using "DRI_PRIME=1 some-egl-application" worked as expected. There are optimizations to be done (e.g. skip going via the iGPU driver when possible) but should at least be possible to use it. Jonas ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: [Feedback] hybrid GPU + multimonitor: partial success with Gnome-shell / Mutter 3.27.1 in Wayland mode
On Mon, Feb 05, 2018 at 07:24:46PM +0100, Cyrille Chépélov wrote:
> Hello,
Hi!
>
> first of all, many thanks for the hard work.
Thanks a lot for testing!
>
> I have an Nvidia GeForce 1060 GTX -equipped laptop, which also has a
> perfectly functional and entirely adequate Intel i915-based video adapter.
> Unfortunately, the Nvidia GPU is the only one connected to the laptop's
> external outputs, which I need to use on occasion.
>
> The system is a debian-based machine, running GNOME 3.26. In the default
> setup, the GNOME-Session can run either in X11 (traditional) or Wayland
> mode. It used to work fine (under prior versions) using a combination of
> /bbswitch/, /bumblebee/ and the NVidia proprietary driver for the purpose of
> enabling high-powered features such as using the external HDMI port for
> presentations.
>
> Looking at the Mutter 3.27.1 announcement that "hybrid GPU" would start to
> be supported, I've modified the setup this way:
>
> * recompiled mutter 3.27.1 (and eventually, gnome-shell 3.27.1) using
>local Debian package derived from the system-provided 3.26.x packages
> * removed the NVidia proprietary driver in favour of "nouveau"
>
> What I expected:
>
> * by default, the GNOME Session works in Wayland mode without wasting
>energy powering up the NVidia GPU, unless somehow explicitly invited
>to ("/optirun foo/" etc.)
The work done in mutter so far does not deal with any turn on/off
functionality. All it tries to do is to read the state given by KMS.
> * When plugging an external display through HDMI (or at worst, while
>also running some 'magic tool' as in the old /intel-virtual-output
>-f/ days), the additional screens just work
This is indeed expected to work.
> * When /un/pluggin an external display through HDMI, the machine keeps
>working, and could withstand an unlimited number of plug/unplug cycles.
This is also indeed expected to work.
Note that when I did this work, I hit a nouveau bug that triggered
freezes. I have not checked whether those have been fixed.
>
> I *didn't* get to that level, but there's good hope.
>
> The following are the three best outcomes I could reach:
>
> *1. single-screen setup: working (ish)
> *
>
> * power up the machine (it starts with "bbswitch OFF" i.e. the NVidia
>GPU is powered off except for PCI enumeration purpose)
> * /(as a consequence, the 'nouveau' kernel module refuses to boot)/
> * start a GNOME Session in default (Wayland) mode: the session comes
>up and appears usable until it freezes solid at a certain point. /—
>calling "lspci" twice appears to reliably trigger the lockup/
> * The idle power consumption at medium screen brightness is around 18W
> * Except from the occasional lockup, the session feels nice and fast
>and would make for a pleasant working environment.
Could you report a bug for this lockup? You should not be able to hit
the lockup nouveau bug I mentioned earlier, as for this scenario you
should only be using the intel driver. I'll provide instructions for how
to help finding out what is locking up.
>
> *2. static multi-screen setup: not working*
>
> * power up the machine
> * switch to a text mode console
> * echo ON > /proc/acpi/bbswitch ; modprobe nouveau /; this starts the
>NVidia GPU/
> * switch back to gdm3; start a GNOME Session in Wayland mode
> * The session hits both monitors, appears to be operational for half a
>second to 2 seconds, then immediately stops.
This is unfortunate, because this worked before.
> * The primary monitor (laptop internal) goes back to gdm3, while the
>external monitor stays on a frozen image of the GNOME session.
This could be because gdm3 that is running has no idea about the
secondary GPU and will leave the state untouched. We don't yet support
hotplugging of GPUs. If you want, you can report a bug for this too, so
we can track missing features in the bug tracker.
> * There is a core dump which belongs to the gnome-shell process. I
>could isolate a couple distinct failure modes:
> 1. the most frequent by far is a core dump with a top backtrace in
>"gbm_bo_get_stride_for_plane" (crash-18h45.txt, attached here)
>
>a very reliable way to trigger this is to edit the relative
>positions of the monitors (the external monitor is physically to
>the left, but started logically to the right of the laptop's
>integrated monitor) and attempt to hit the "Keep changed screen
>settings" button.
>Sometimes the system crashes with this stack even faster.
>
> 2. the second most frequent is a core dump with a top backtrace
>where clutter draws text (crash-18h43.txt, attached here)
>
>the stack is quite deep (83 levels) but what is strange is that
>near the top, I see:
>
>#2 0x7fe159a2e8e7 in copy_array_to_vbo_array
> (brw=brw@entry=0x5588defea4d0, min=min@entry=4, max=max@entry=91,
>
Re: AppMenu design feedback
On Sun, 2013-03-10 at 10:08 +0100, Donato Marrazzo wrote: In Files app, there is an engine wheel in the top right corner, where some options have place, and even there is an arrow button near the engine wheel with other option: so you have to remember which actions are in the AppMenu, in the engine wheel and in the arrow button. The Files / Nautilus application in GNOME Shell is certainly the most confusing. I'm a system and network administrator for 25+ years... I have no idea what that gear icon / drop-down menu is supposed to mean. In most apps I don't have any real issues with the menus - Files / Nautilus is currently a mess. The other problem with AppMenu is that iit's far from the window content so it requires a long trip for the mouse. But we already discuss these concerns in the list and almost everybody agreed that the AppMenu requires a deep redesign. I'm not sure what a deep redesign is; but, for the record, I'm certain I would not agree with that. The intent of the AppMenu seems quite clear and it works just fine in current versions even with focus-follows-mouse. It needs some polish, and some consistency across applications [which, really, is up to the applications to do]. I do not see any deep problems. Mostly, it just seems a bit arbitrary; but that is not surprising, categorization is actually really hard. What is obvious to one is oblivious to another; that doesn't give either side a moral high-ground [and it is really JUST A @*$*@ MENU AFTER ALL]. It will probably settle down to a defacto standard given time. -- Adam Tauno Williams GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
In Files app, there is an engine wheel in the top right corner, where some options have place, and even there is an arrow button near the engine wheel with other option: so you have to remember which actions are in the AppMenu, in the engine wheel and in the arrow button. The other problem with AppMenu is that iit's far from the window content so it requires a long trip for the mouse. But we already discuss these concerns in the list and almost everybody agreed that the AppMenu requires a deep redesign. On Fri, Mar 8, 2013 at 4:48 PM, Sam Bull sam.hack...@sent.com wrote: In the Files app? Atleast on my machine, there is no classic menu, so the AppMenu IS the only place to look. The only program I can name that uses both places and is confusing, would be devhelp. I see no problem with the way it is implemented in Files, everything is in one place and it keeps the interface clean. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
I think that this extension could be convenient, but does not solve the problem radically. The key aspect is that the AppMenu as it is implemented in Files app is not the only place where to look for action/option, so it's confusing. From my point of view, the possible solution are: 1) remove it 2) make it more functional and comfortable, so it can embrace all application action/options menus and become a single point of control. On Thu, Mar 7, 2013 at 5:35 PM, Summers Pittman ℝ second...@gmail.comwrote: I just thought of a idea and will try to hack an extension together if the lists likes it. Super + Scroll down on mouse opens the menu, (on a non primary monitor it opens centered from the top), continue scrolling to select a menu item, click or Enter activates the menu item. If I can get that working, perhaps the next step would be to add gestures for track pads. Two finger swipe from the top to open the menu, drag up and down to select. wdyt? Summers Pittman ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
On Fri, 2013-03-08 at 16:40 +0100, Donato Marrazzo wrote: The key aspect is that the AppMenu as it is implemented in Files app is not the only place where to look for action/option, so it's confusing. In the Files app? Atleast on my machine, there is no classic menu, so the AppMenu IS the only place to look. The only program I can name that uses both places and is confusing, would be devhelp. I see no problem with the way it is implemented in Files, everything is in one place and it keeps the interface clean. signature.asc Description: This is a digitally signed message part ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
I just thought of a idea and will try to hack an extension together if the lists likes it. Super + Scroll down on mouse opens the menu, (on a non primary monitor it opens centered from the top), continue scrolling to select a menu item, click or Enter activates the menu item. If I can get that working, perhaps the next step would be to add gestures for track pads. Two finger swipe from the top to open the menu, drag up and down to select. wdyt? Summers Pittman Phone:404 941 4698 Java is my crack. On Mon, Feb 25, 2013 at 6:07 AM, Adam Tauno Williams awill...@whitemice.org wrote: On Mon, 2013-02-25 at 10:36 +0100, Donato Marrazzo wrote: Developers have regular meetings on IRC. I expect that IRC channel is for people actively involved in developing and design. Yes, exactly. As normal user, I'd like left an asynchronous feedback... and since it seems that many share my concerns, I hope that somebody from design team take it in count. I agree and very much understand what you mean but after 20+ years in Open Source... it just doesn't really work that way. If you feel strongly about something you need to dig in to be heard, to have influence. Making comments just isn't going to make it happen. I don't know if there is an 'official' term for the people - but I call them 'pitchers'. They drive by and 'pitch' messages, ideas, thoughts, criticisms, criticisms, criticisms, and more criticisms, etc... over the fence at developers. Most never even slow down. Here is there idea/comment/criticism/... and a set of tail lights receding to the horizon. If, as a developer, you took time to deal with every message that came over the fence you'd actually never do any development. And it would be REALLY depressing as most of what comes over is ad-hoc, misinformed, and generally content free. [aside... I could be doing development right now I slap the back of my own head] Corporations have teams of people to take that stuff, make people ***FEEL HEARD***, and - most importantly - to shield developers from the noise; so that developers can develop. Open Source doesn't have that. Developers need to insulate themselves [many won't call it this, but again 20 years that is what is happening]. You've completed the important step of filing a bug or following a bug. Now it helps just to mention it as many places as possible [but all *appropriate places], so maybe it slides across the right persons field-of-view. That helps. I do not think this list counts, AFAIK, I haven't seen anything that indicates much developer involvement here. At leasing popping onto the right IRC channel and mentioning the bug might help.Or post a bounty on something like http://www.freedomsponsors.org/, one never knows, you might get a comp-sci student to take a look for beer money. And with all things human, being known helps [having karma]. Having a couple developers who recognize your e-mail address, name, etc... I know I am much more likely to respond to messages from people I recognize from over the years - they get some automatic credibility. So I always recommend to get involved in a project at least a little bit; if you enjoy and use GNOME why not throw in a little time on the bug squad https://live.gnome.org/Bugsquad/ That doesn't require developer know-how, can make a real difference for the project, and builds karma. You'll learn stuff and meet fun people. Often I use vmware for my daily job, so maybe that it's the root cause... I really appreciate when after killing gnome-shell, it restart without killing apps... but I have a dream: working without gnome-shell freeze/restarts. Agree. I have not been able to nail down what exactly happens here. I've filed a bug, but maybe there something wrong because nobody answer: https://bugzilla.redhat.com/show_bug.cgi?id=913095 Is there a reason the bug is on RedHat and not the GNOME bugzilla? I'd guess that upstream is a better place. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
Hi Adam, thank you for your answers: Developers have regular meetings on IRC. I expect that IRC channel is for people actively involved in developing and design. As normal user, I'd like left an asynchronous feedback... and since it seems that many share my concerns, I hope that somebody from design team take it in count. Often I use vmware for my daily job, so maybe that it's the root cause... I really appreciate when after killing gnome-shell, it restart without killing apps... but I have a dream: working without gnome-shell freeze/restarts. I've filed a bug, but maybe there something wrong because nobody answer: https://bugzilla.redhat.com/show_bug.cgi?id=913095 Thank you, Donato ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
On Mon, 2013-02-25 at 10:36 +0100, Donato Marrazzo wrote: Developers have regular meetings on IRC. I expect that IRC channel is for people actively involved in developing and design. Yes, exactly. As normal user, I'd like left an asynchronous feedback... and since it seems that many share my concerns, I hope that somebody from design team take it in count. I agree and very much understand what you mean but after 20+ years in Open Source... it just doesn't really work that way. If you feel strongly about something you need to dig in to be heard, to have influence. Making comments just isn't going to make it happen. I don't know if there is an 'official' term for the people - but I call them 'pitchers'. They drive by and 'pitch' messages, ideas, thoughts, criticisms, criticisms, criticisms, and more criticisms, etc... over the fence at developers. Most never even slow down. Here is there idea/comment/criticism/... and a set of tail lights receding to the horizon. If, as a developer, you took time to deal with every message that came over the fence you'd actually never do any development. And it would be REALLY depressing as most of what comes over is ad-hoc, misinformed, and generally content free. [aside... I could be doing development right now I slap the back of my own head] Corporations have teams of people to take that stuff, make people ***FEEL HEARD***, and - most importantly - to shield developers from the noise; so that developers can develop. Open Source doesn't have that. Developers need to insulate themselves [many won't call it this, but again 20 years that is what is happening]. You've completed the important step of filing a bug or following a bug. Now it helps just to mention it as many places as possible [but all *appropriate places], so maybe it slides across the right persons field-of-view. That helps. I do not think this list counts, AFAIK, I haven't seen anything that indicates much developer involvement here. At leasing popping onto the right IRC channel and mentioning the bug might help.Or post a bounty on something like http://www.freedomsponsors.org/, one never knows, you might get a comp-sci student to take a look for beer money. And with all things human, being known helps [having karma]. Having a couple developers who recognize your e-mail address, name, etc... I know I am much more likely to respond to messages from people I recognize from over the years - they get some automatic credibility. So I always recommend to get involved in a project at least a little bit; if you enjoy and use GNOME why not throw in a little time on the bug squad https://live.gnome.org/Bugsquad/ That doesn't require developer know-how, can make a real difference for the project, and builds karma. You'll learn stuff and meet fun people. Often I use vmware for my daily job, so maybe that it's the root cause... I really appreciate when after killing gnome-shell, it restart without killing apps... but I have a dream: working without gnome-shell freeze/restarts. Agree. I have not been able to nail down what exactly happens here. I've filed a bug, but maybe there something wrong because nobody answer: https://bugzilla.redhat.com/show_bug.cgi?id=913095 Is there a reason the bug is on RedHat and not the GNOME bugzilla? I'd guess that upstream is a better place. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
I understand your pain... but strictly speaking you can switch window with just one click: 1) move to active corner 2) pick the window (one click) Anyway, it require 2 mouse trip... and yes it's mouse intensive operation. However there is an intersting extension called dash to dock, give it a try! From quality point of view... well... 3.6.2 was really unstable 3.6.3 seems better but it happens one time per day that gnome-shell restart... Please developers: give a look to stability (SIG11 fault, etc). ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
On Sun, 2013-02-24 at 12:19 +0100, Donato Marrazzo wrote: I understand your pain... but strictly speaking you can switch window with just one click: 1) move to active corner 2) pick the window (one click) Alt-Tab, Alt-` work too. Very fast. You even get pretty pictures of the windows so you land on the one you wanted. Anyway, it require 2 mouse trip... and yes it's mouse intensive operation. Using a task bar at the bottom of the screen required two mouse trips - so six of one / half-dozen of the other. If speed is a concern then use the keyboard. GNOME Shell is *VERY* keyboard navigable [which really shoots to hell the constant and incorrect GNOME-Shell-Is-For-Tablets meme - Yo, idjits! Tablets do not have keyboards!] Keyboard control of the workspace is much more streamlined then in GNOME2. However there is an intersting extension called dash to dock, give it a try! I use dash-to-dock, it is nice extension. The dash for starting applications just hangs out unless it is in the way [overlapped by something] then it auto-hides. From quality point of view... well... 3.6.2 was really unstable 3.6.3 seems better but it happens one time per day that gnome-shell restart... 3.6 overall has been very stable for me. Only time it seems to break down is when I'm running VMware-workstations. The focus seems to get bound up so I can't click on anything - but HUP'ing the gnome-shell brings it back to working without having to exit any applications, etc... Please developers: give a look to stability (SIG11 fault, etc). Always; stability is a must. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
On Sat, 2013-02-23 at 11:42 +0100, Donato Marrazzo wrote: My feedback is about the current design, let me know if there is another place where to share such kind of feedbacks. Developers have regular meetings on IRC. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
On Sat, 2013-02-23 at 02:35 +0100, Florian Scandella wrote: On 23/02/13 00:30, Sriram Ramkrishna wrote: If you make the case that something is not fulfilling or violating the design goals then it should be put in as a bug. Then it is up to the designers and the maintainer to figure out what the right solution is. It might be the correct solution is remove AppMenu, or perhaps the solution is to fix X11 in some shape way or form. there are quite a few bug reports concerning this ... could'nt find one with useful developer feedback (except to enable the fallback mode) Bugs I file regularly get resolved, so I don't know what your comment about feedback means. The bug on the app-menu and sloppy focus got resolved, with a fair amount of commentary. Bugzilla is a bug management tool, not a discussion forum. Bugs needs to be *specific* and actionable. If you want to *discuss* design then I imagine you need to join the design team. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
My feedback is about the current design, let me know if there is another place where to share such kind of feedbacks. My opinion is that AppMenu initially is charming, something different from the old windows style: but usage experience is uncomfortable! I like new design idea, but the design should address a better ergonomics. So, UI Designers: let's impress us with new ideas! Cheers, Donato ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
On Sat, Feb 23, 2013 at 10:42 AM, Donato Marrazzo donato.marra...@gmail.com wrote: My feedback is about the current design, let me know if there is another place where to share such kind of feedbacks. My opinion is that AppMenu initially is charming, something different from the old windows style: but usage experience is uncomfortable! I like new design idea, but the design should address a better ergonomics. So, UI Designers: let's impress us with new ideas! Cheers, Donato ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list Yes, I also want to stress that I really like the new Gnome UI (Gnome Shell), people always tend to think that if you make a negative comment about part of it that it means you hate it, this is not he case! There were really 2.5 annoying things about it to me for which I wrote extensions for (the 0.5 is for the notification bar at the bottom, it might as well go away because I never see it since it's hidden unless you go look at it explicitly, which is against the principal of a notification bar IMO, you should always see the things that are in there, but I found an extension that puts my IM icons on the top bar so it's ok). I like GS so much that I use it at work too and I am going to install it on my mom's computer soon. Great work guys! Gabriel ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
I completely disagree: cinnamon or kde are just a copy of an old design with some superficial changes. Gnome 3 is a radical re-think of human-computer interaction. I love the activities overview: one place to see open applications and workspaces, to launch other applications... Fantastic! On other hand there are some ideas that need a re-think: AppMenu and Notification area... ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
AppMenu design feedback
Hi All, Files 3.6 is the first app that I use which leverage AppMenu design. I feel a bit confused because I don't know where to search an option: every time I check the engine wheel that is near the mouse then I remember the AppMenu!!! I think that AppMenu is not a graet design for the following reason: - it is far from the window content, the mouse pointer have to cover a longer distance - it's slow because you need to click before see the menu list - if like for Files, you need another place to put other actions (the engine wheel), well it's even confusing!!! Please remove AppMenu! Last thought: I like the Unity idea to place the window menu in the top bar when the mouse hover on it, but I would prefer if it works in such manner only for the maximized windows. -- Ciao* Donato* http://it.linkedin.com/in/donatomarrazzo ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
RE: AppMenu design feedback
Hi, I wrote an extension that does this Remove Panel App Menu as I find the AppMenu counter-productive, confusing (why have menus in two different places?) and it breaks the sloppy mouse focus (you can't access the AppMenu since it changes when the mouse goes over another window when you try and access it). Unfortunately I don't have Gnome Shell 3.6 yet and from what the users say the extension doesn't work on 3.6/3.7. I will try to upgrade my Ubuntu next week and see if I can fix this issue. In any event, just keep on looking on the extension's page and I will announce when it is fixed, hopefully soon. Cheers, Gabriel From: gnome-shell-list [gnome-shell-list-boun...@gnome.org] on behalf of Donato Marrazzo [donato.marra...@gmail.com] Sent: Friday, February 22, 2013 11:48 To: gnome-shell-list@gnome.org Subject: AppMenu design feedback Hi All, Files 3.6 is the first app that I use which leverage AppMenu design. I feel a bit confused because I don't know where to search an option: every time I check the engine wheel that is near the mouse then I remember the AppMenu!!! I think that AppMenu is not a graet design for the following reason: * it is far from the window content, the mouse pointer have to cover a longer distance * it's slow because you need to click before see the menu list * if like for Files, you need another place to put other actions (the engine wheel), well it's even confusing!!! Please remove AppMenu! Last thought: I like the Unity idea to place the window menu in the top bar when the mouse hover on it, but I would prefer if it works in such manner only for the maximized windows. -- Ciao Donato [http://www.linkedin.com/img/webpromo/btn_viewmy_160x33.png]http://it.linkedin.com/in/donatomarrazzo This email and any attachments are confidential and access to this email or attachment by anyone other than the addressee is unauthorised. If you are not the intended recipient please notify the sender and delete the email including any attachments. You must not disclose or distribute any of the contents to any other person. Personal views or opinions are solely those of the author and not of Trafigura. Trafigura does not guarantee that the integrity of this communication has been maintained nor that the communication is free of viruses, interceptions or interference. By communicating with anyone at Trafigura by email, you consent to the monitoring or interception of such email by Trafigura in accordance with its internal policies. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
Hi, Does the extension put the options from the App Menu anywhere in the application or are they just lost? 2013/2/22 Gabriel Rossetti gabriel.rosse...@trafigura.com Hi, I wrote an extension that does this Remove Panel App Menu as I find the AppMenu counter-productive, confusing (why have menus in two different places?) and it breaks the sloppy mouse focus (you can't access the AppMenu since it changes when the mouse goes over another window when you try and access it). Unfortunately I don't have Gnome Shell 3.6 yet and from what the users say the extension doesn't work on 3.6/3.7. I will try to upgrade my Ubuntu next week and see if I can fix this issue. In any event, just keep on looking on the extension's page and I will announce when it is fixed, hopefully soon. Cheers, Gabriel From: gnome-shell-list [gnome-shell-list-boun...@gnome.org] on behalf of Donato Marrazzo [donato.marra...@gmail.com] Sent: Friday, February 22, 2013 11:48 To: gnome-shell-list@gnome.org Subject: AppMenu design feedback Hi All, Files 3.6 is the first app that I use which leverage AppMenu design. I feel a bit confused because I don't know where to search an option: every time I check the engine wheel that is near the mouse then I remember the AppMenu!!! I think that AppMenu is not a graet design for the following reason: * it is far from the window content, the mouse pointer have to cover a longer distance * it's slow because you need to click before see the menu list * if like for Files, you need another place to put other actions (the engine wheel), well it's even confusing!!! Please remove AppMenu! Last thought: I like the Unity idea to place the window menu in the top bar when the mouse hover on it, but I would prefer if it works in such manner only for the maximized windows. -- Ciao Donato [http://www.linkedin.com/img/webpromo/btn_viewmy_160x33.png] http://it.linkedin.com/in/donatomarrazzo This email and any attachments are confidential and access to this email or attachment by anyone other than the addressee is unauthorised. If you are not the intended recipient please notify the sender and delete the email including any attachments. You must not disclose or distribute any of the contents to any other person. Personal views or opinions are solely those of the author and not of Trafigura. Trafigura does not guarantee that the integrity of this communication has been maintained nor that the communication is free of viruses, interceptions or interference. By communicating with anyone at Trafigura by email, you consent to the monitoring or interception of such email by Trafigura in accordance with its internal policies. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
RE: AppMenu design feedback
GTK supports two modes, one where the WM draws the AppMenu (as with GS) or one where the Application draws it (like when you use xfce). The extension simply tells GTK to make the application draw it (so you get an extra menu item on the menu bar). It would not be very useful to loose the options :-) Cheers, Gabriel From: Rovanion Luckey [rovanion.luc...@gmail.com] Sent: Friday, February 22, 2013 13:01 To: Gabriel Rossetti Cc: Donato Marrazzo; gnome-shell-list@gnome.org Subject: Re: AppMenu design feedback Hi, Does the extension put the options from the App Menu anywhere in the application or are they just lost? 2013/2/22 Gabriel Rossetti gabriel.rosse...@trafigura.commailto:gabriel.rosse...@trafigura.com Hi, I wrote an extension that does this Remove Panel App Menu as I find the AppMenu counter-productive, confusing (why have menus in two different places?) and it breaks the sloppy mouse focus (you can't access the AppMenu since it changes when the mouse goes over another window when you try and access it). Unfortunately I don't have Gnome Shell 3.6 yet and from what the users say the extension doesn't work on 3.6/3.7. I will try to upgrade my Ubuntu next week and see if I can fix this issue. In any event, just keep on looking on the extension's page and I will announce when it is fixed, hopefully soon. Cheers, Gabriel From: gnome-shell-list [gnome-shell-list-boun...@gnome.orgmailto:gnome-shell-list-boun...@gnome.org] on behalf of Donato Marrazzo [donato.marra...@gmail.commailto:donato.marra...@gmail.com] Sent: Friday, February 22, 2013 11:48 To: gnome-shell-list@gnome.orgmailto:gnome-shell-list@gnome.org Subject: AppMenu design feedback Hi All, Files 3.6 is the first app that I use which leverage AppMenu design. I feel a bit confused because I don't know where to search an option: every time I check the engine wheel that is near the mouse then I remember the AppMenu!!! I think that AppMenu is not a graet design for the following reason: * it is far from the window content, the mouse pointer have to cover a longer distance * it's slow because you need to click before see the menu list * if like for Files, you need another place to put other actions (the engine wheel), well it's even confusing!!! Please remove AppMenu! Last thought: I like the Unity idea to place the window menu in the top bar when the mouse hover on it, but I would prefer if it works in such manner only for the maximized windows. -- Ciao Donato [http://www.linkedin.com/img/webpromo/btn_viewmy_160x33.png]http://it.linkedin.com/in/donatomarrazzo This email and any attachments are confidential and access to this email or attachment by anyone other than the addressee is unauthorised. If you are not the intended recipient please notify the sender and delete the email including any attachments. You must not disclose or distribute any of the contents to any other person. Personal views or opinions are solely those of the author and not of Trafigura. Trafigura does not guarantee that the integrity of this communication has been maintained nor that the communication is free of viruses, interceptions or interference. By communicating with anyone at Trafigura by email, you consent to the monitoring or interception of such email by Trafigura in accordance with its internal policies. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. ___ gnome-shell-list mailing list gnome-shell-list@gnome.orgmailto:gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
+1 for removing AppMenu, it's very annoying when using multiple monitors.
As a temporary workaround theres a gsettings key:
gsettings set org.gnome.settings-daemon.plugins.xsettings overrides
'{Gtk/ShellShowsAppMenu: int32 0}'
But it adds a whole second menu to programms using the AppMenu with just
one entry (see totem).. a waste of space.
I think if there's need for an appmenu, the title bar would be a nice
place to put it (like firefox on windows). I opened a bug some time ago
about this: https://bugzilla.gnome.org/show_bug.cgi?id=688105
On 22/02/13 14:00, Rovanion Luckey wrote:
Hi,
Does the extension put the options from the App Menu anywhere in the
application or are they just lost?
2013/2/22 Gabriel Rossetti gabriel.rosse...@trafigura.com
mailto:gabriel.rosse...@trafigura.com
Hi,
I wrote an extension that does this Remove Panel App Menu as I
find the AppMenu counter-productive, confusing (why have menus in
two different places?) and it breaks the sloppy mouse focus (you
can't access the AppMenu since it changes when the mouse goes over
another window when you try and access it).
Unfortunately I don't have Gnome Shell 3.6 yet and from what the
users say the extension doesn't work on 3.6/3.7. I will try to
upgrade my Ubuntu next week and see if I can fix this issue.
In any event, just keep on looking on the extension's page and I
will announce when it is fixed, hopefully soon.
Cheers,
Gabriel
From: gnome-shell-list [gnome-shell-list-boun...@gnome.org
mailto:gnome-shell-list-boun...@gnome.org] on behalf of Donato
Marrazzo [donato.marra...@gmail.com
mailto:donato.marra...@gmail.com]
Sent: Friday, February 22, 2013 11:48
To: gnome-shell-list@gnome.org mailto:gnome-shell-list@gnome.org
Subject: AppMenu design feedback
Hi All,
Files 3.6 is the first app that I use which leverage AppMenu design.
I feel a bit confused because I don't know where to search an
option: every time I check the engine wheel that is near the
mouse then I remember the AppMenu!!!
I think that AppMenu is not a graet design for the following reason:
* it is far from the window content, the mouse pointer have to
cover a longer distance
* it's slow because you need to click before see the menu list
* if like for Files, you need another place to put other
actions (the engine wheel), well it's even confusing!!!
Please remove AppMenu!
Last thought: I like the Unity idea to place the window menu in
the top bar when the mouse hover on it, but I would prefer if it
works in such manner only for the maximized windows.
--
Ciao Donato
[http://www.linkedin.com/img/webpromo/btn_viewmy_160x33.png]http://it.linkedin.com/in/donatomarrazzo
This email and any attachments are confidential and access to this
email or attachment by anyone other than the addressee is
unauthorised. If you are not the intended recipient please notify
the sender and delete the email including any attachments. You
must not disclose or distribute any of the contents to any other
person. Personal views or opinions are solely those of the author
and not of Trafigura. Trafigura does not guarantee that the
integrity of this communication has been maintained nor that the
communication is free of viruses, interceptions or interference.
By communicating with anyone at Trafigura by email, you consent to
the monitoring or interception of such email by Trafigura in
accordance with its internal policies. Unless otherwise stated,
any pricing information given in this message is indicative only,
is subject to change and does not constitute an offer to deal at
any price quoted.
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org mailto:gnome-shell-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list
RE: AppMenu design feedback
Yes, I forgot to mention the multi-monitor thing, you are right. I think we
should make a list of the pros/cons of it, here is my updated list of cons
(sorry, I can't find any pros but please fill the list in if you have some):
Cons:
1) impractical with multi-monitor setup: your window is on one monitor but you
have to go to the monitor with the top panel/AppMenu to select the menu items.
2) confusing to have menu items/options in two places: in the menu bar and in
the AppMenu situated on the top panel of the main screen. You could offer the
option to have one or the other but it should be a CHOICE, if the user chooses
to have it then the menu bar disappears and the menu is put into the AppMenu
(like in Firefox), if the user chooses not to have it then the AppMenu
disappears and is rendered in the Menu bar if it is really needed, if not then
it is not rendered at all.
3) it completely breaks sloppy mouse window focus (where you focus the windows
just by moving the mouse over them without clicking): when you move the mouse
away from the application to access the AppMenu it either, de-focuses thus the
AppMenu does too, or it focuses on a window that unfortunately was in the
path to the AppMenu thus the AppMenu switches to it.
As a personal choice, I think that the application's options should be on the
application's window since that is what I am using at the moment. Like I say
this is personal, some people may like it the other way around (like in Mac)
which is why this could be a user choice as described in #2.
Gabriel
From: gnome-shell-list [gnome-shell-list-boun...@gnome.org] on behalf of
Florian Scandella [f...@chilicode.com]
Sent: Friday, February 22, 2013 13:46
To: gnome-shell-list@gnome.org
Subject: Re: AppMenu design feedback
+1 for removing AppMenu, it's very annoying when using multiple monitors.
As a temporary workaround theres a gsettings key:
gsettings set org.gnome.settings-daemon.plugins.xsettings overrides
'{Gtk/ShellShowsAppMenu: int32 0}'
But it adds a whole second menu to programms using the AppMenu with just
one entry (see totem).. a waste of space.
I think if there's need for an appmenu, the title bar would be a nice
place to put it (like firefox on windows). I opened a bug some time ago
about this: https://bugzilla.gnome.org/show_bug.cgi?id=688105
On 22/02/13 14:00, Rovanion Luckey wrote:
Hi,
Does the extension put the options from the App Menu anywhere in the
application or are they just lost?
2013/2/22 Gabriel Rossetti gabriel.rosse...@trafigura.com
mailto:gabriel.rosse...@trafigura.com
Hi,
I wrote an extension that does this Remove Panel App Menu as I
find the AppMenu counter-productive, confusing (why have menus in
two different places?) and it breaks the sloppy mouse focus (you
can't access the AppMenu since it changes when the mouse goes over
another window when you try and access it).
Unfortunately I don't have Gnome Shell 3.6 yet and from what the
users say the extension doesn't work on 3.6/3.7. I will try to
upgrade my Ubuntu next week and see if I can fix this issue.
In any event, just keep on looking on the extension's page and I
will announce when it is fixed, hopefully soon.
Cheers,
Gabriel
From: gnome-shell-list [gnome-shell-list-boun...@gnome.org
mailto:gnome-shell-list-boun...@gnome.org] on behalf of Donato
Marrazzo [donato.marra...@gmail.com
mailto:donato.marra...@gmail.com]
Sent: Friday, February 22, 2013 11:48
To: gnome-shell-list@gnome.org mailto:gnome-shell-list@gnome.org
Subject: AppMenu design feedback
Hi All,
Files 3.6 is the first app that I use which leverage AppMenu design.
I feel a bit confused because I don't know where to search an
option: every time I check the engine wheel that is near the
mouse then I remember the AppMenu!!!
I think that AppMenu is not a graet design for the following reason:
* it is far from the window content, the mouse pointer have to
cover a longer distance
* it's slow because you need to click before see the menu list
* if like for Files, you need another place to put other
actions (the engine wheel), well it's even confusing!!!
Please remove AppMenu!
Last thought: I like the Unity idea to place the window menu in
the top bar when the mouse hover on it, but I would prefer if it
works in such manner only for the maximized windows.
--
Ciao Donato
[http://www.linkedin.com/img/webpromo/btn_viewmy_160x33.png]http://it.linkedin.com/in/donatomarrazzo
This email and any attachments are confidential and access to this
email or attachment by anyone other than the addressee is
unauthorised. If you are not the intended recipient please notify
the sender
Re: AppMenu design feedback
On Fri, 2013-02-22 at 14:41 +0100, Florian Scandella wrote:
+1 for removing AppMenu, it's very annoying when using multiple monitors.
Agree, I don't get the point in the first place... but with my displays
it is *36 INCHES FROM THE APPLICATION WINDOW*! Yikes.
BTW, is there a hotkey bound to the current applications AppMenu? That
would make it somewhat less silly.
As a temporary workaround theres a gsettings key:
gsettings set org.gnome.settings-daemon.plugins.xsettings overrides
'{Gtk/ShellShowsAppMenu: int32 0}'
Oh, sweet!!!
But it adds a whole second menu to programms using the AppMenu with just
one entry (see totem).. a waste of space.
Argh!
I think if there's need for an appmenu, the title bar would be a nice
place to put it (like firefox on windows). I opened a bug some time ago
about this: https://bugzilla.gnome.org/show_bug.cgi?id=688105
Nice, I've added myself to the CC of that one.
--
Adam Tauno Williams GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
On Feb 22, 2013 3:13 PM, Adam Tauno Williams awill...@whitemice.org wrote: BTW, is there a hotkey bound to the current applications AppMenu? That would make it somewhat less silly. superf10 ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
On Fri, 2013-02-22 at 14:08 +, Gabriel Rossetti wrote: Yes, I forgot to mention the multi-monitor thing, you are right. I think we should make a list of the pros/cons of it, here is my updated list of cons (sorry, I can't find any pros but please fill the list in if you have some): This is an entirely academic exercise unless developers are participating this this thread. Just saying - it might be pointless. This is primarily a *users* list. Cons: 1) impractical with multi-monitor setup: your window is on one monitor but you have to go to the monitor with the top panel/AppMenu to select the menu items. 2) confusing to have menu items/options in two places: in the menu bar and in the AppMenu situated on the top panel of the main screen. You could offer the option to have one or the other but it should be a CHOICE, if the user chooses to have it then the menu bar disappears and the menu is put into the AppMenu (like in Firefox), if the user chooses not to have it then the AppMenu disappears and is rendered in the Menu bar if it is really needed, if not then it is not rendered at all. 3) it completely breaks sloppy mouse window focus (where you focus the windows just by moving the mouse over them without clicking): when you move the mouse away from the application to access the AppMenu it either, de-focuses thus the AppMenu does too, or it focuses on a window that unfortunately was in the path to the AppMenu thus the AppMenu switches to it. Well, #3 is factually *NOT* true. There was a bug for this, but it has since been closed - because it was RESOLVED. I am using sloppy focus in GNOME Shell and the app menu works just fine. Ah, here it is. https://bugzilla.gnome.org/show_bug.cgi?id=678169 Personally I would add 4) Most of the time there is little to anything useful in it. Often it contains the option Quit. My 4 would be 3 since I do not accept your 3. -- Adam Tauno Williams GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
On Fri, 2013-02-22 at 15:16 +0100, Florian Müllner wrote: On Feb 22, 2013 3:13 PM, Adam Tauno Williams awill...@whitemice.org wrote: BTW, is there a hotkey bound to the current applications AppMenu? That would make it somewhat less silly. superf10 Ah! Nice, thanks. Now I can pop the menu and navigate it with the old arrow yes. -- Adam Tauno Williams GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
Having global menu commands in a menu in a single place seems to be a great idea, but the implementation feels a bit off. Maybe it is time to bring back the style from Windows 3.0 where the app menu was in the top left of the titlebar? Does anyone have a link to any archived discussion when the app menu was initially proposed? Summers Pittman Phone:404 941 4698 Java is my crack. On Fri, Feb 22, 2013 at 9:21 AM, Adam Tauno Williams awill...@whitemice.org wrote: On Fri, 2013-02-22 at 15:16 +0100, Florian Müllner wrote: On Feb 22, 2013 3:13 PM, Adam Tauno Williams awill...@whitemice.org wrote: BTW, is there a hotkey bound to the current applications AppMenu? That would make it somewhat less silly. superf10 Ah! Nice, thanks. Now I can pop the menu and navigate it with the old arrow yes. -- Adam Tauno Williams GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
On Fri, 2013-02-22 at 12:06 +, Gabriel Rossetti wrote: I find the AppMenu counter-productive, confusing (why have menus in two different places?) and it breaks the sloppy mouse focus (you can't access the AppMenu since it changes when the mouse goes over another window when you try and access it). In 3.6, sloppy focus has a short delay, so if you flick the cursor to the top of the screen, it won't change focus and the menu works just fine. The AppMenu seems like a nice idea to remove the menu bar from applications that only use it for a couple of trivial menu items (like preferences and quit). But, it can be confusing when an application actually chooses to split menu items between the two places (e.g. Devhelp). I think applications should choose one option or the other, and never use both menus. I don't think it's confusing if only one is used. If there is no menu bar on the application, then it is obvious that any additional options will be on the AppMenu. -- Sam Bull Twitter/Identi.ca: @sambull signature.asc Description: This is a digitally signed message part ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
On Fri, Feb 22, 2013 at 8:37 PM, Sam Bull sam.hack...@sent.com wrote: On Fri, 2013-02-22 at 12:06 +, Gabriel Rossetti wrote: I find the AppMenu counter-productive, confusing (why have menus in two different places?) and it breaks the sloppy mouse focus (you can't access the AppMenu since it changes when the mouse goes over another window when you try and access it). In 3.6, sloppy focus has a short delay, so if you flick the cursor to the top of the screen, it won't change focus and the menu works just fine. The AppMenu seems like a nice idea to remove the menu bar from applications that only use it for a couple of trivial menu items (like preferences and quit). But, it can be confusing when an application actually chooses to split menu items between the two places (e.g. Devhelp). I think applications should choose one option or the other, and never use both menus. I don't think it's confusing if only one is used. If there is no menu bar on the application, then it is obvious that any additional options will be on the AppMenu. -- Sam Bull Twitter/Identi.ca: @sambull Thanks Sam, I wasn't aware, it was fixed. Yes, agreed, that is basically the same idea as what I wrote. I may have expressed myself in a wrong manner, what I meant by confusing is that it is confusing if the app has both the AppMenu and the normal Menu bar, if it has one or the other ALL THE TIME it is ok. I stress that it must be one or the other, switchable by a user setting (I could care less what the default is as long as you can change it) and be consistent,. That last point is because nothing is worst than having inconsistent ways of doing things. Currently, to have it switchable you need someone to code an extension (which is why I wrote it) and maintain it (which I have to do to update it to 3.6, I know :-)), and it's confusing because the options are split into the AppMenu AND the menu bar (if it has one) if you decide not to use the extension. Gabriel ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
On Fri, Feb 22, 2013 at 3:47 AM, Donato Marrazzo donato.marra...@gmail.comwrote: Please remove AppMenu! If I could make a suggestion. When making such requests, it's best to simply state the problem and not recommend the solution. I for one am not so arrogant to know what the solution should be. In this case, the problem is for the designer to solve. It's their design. :-) If you make the case that something is not fulfilling or violating the design goals then it should be put in as a bug. Then it is up to the designers and the maintainer to figure out what the right solution is. It might be the correct solution is remove AppMenu, or perhaps the solution is to fix X11 in some shape way or form. A lot of people seem think that the lower layers are immutable and cannot be changed to support the design. But they can be, so you need to think bigger. A lot of the designs for notifications for instance required changing X instead of scrapping the whole thing and reverting. sri ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: AppMenu design feedback
On 23/02/13 00:30, Sriram Ramkrishna wrote: On Fri, Feb 22, 2013 at 3:47 AM, Donato Marrazzo donato.marra...@gmail.com mailto:donato.marra...@gmail.com wrote: Please remove AppMenu! If I could make a suggestion. When making such requests, it's best to simply state the problem and not recommend the solution. I for one am not so arrogant to know what the solution should be. In this case, the problem is for the designer to solve. It's their design. :-) There are many mails in the thread stating the con's. The thing is, i can't think of any pro's, maybe someone can enlighten me? :) The feature as it currently is implemented is just annoying if you use anything other than a single small screen. If it's there to stay, please fix the fallback mode to not introduce a whole extra menubar with just one entry. Like merge the menus or put it in the title bar. If you make the case that something is not fulfilling or violating the design goals then it should be put in as a bug. Then it is up to the designers and the maintainer to figure out what the right solution is. It might be the correct solution is remove AppMenu, or perhaps the solution is to fix X11 in some shape way or form. there are quite a few bug reports concerning this ... could'nt find one with useful developer feedback (except to enable the fallback mode) A lot of people seem think that the lower layers are immutable and cannot be changed to support the design. But they can be, so you need to think bigger. A lot of the designs for notifications for instance required changing X instead of scrapping the whole thing and reverting. sri ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
feedback
guess i am going to cancel this mailing list, as it seems it is not meant for users who want to give feedback. i gave gnome 3.2 a try, due to switching a faulty boot ssd... i knew that if i want to use it it wont be an easy task to get all the stuff running as i like it. as i wrote on this list ages ago that i need the alt key for all my major apps(3d stuff, rotating the camera) i never got a sufficient answer, so i was willing to try to fix this on my own. unfortunalety i did not get to this point because resizing all windows was very slow, resizing the nick list inside empathy also was slow. very anoying. what the idea is behind no minimize buttons in the title bar is beond me, everything is cluttering up the desktop... the online contacts thing could not connect to google... gnote closes all open notes if i end the main gnote app(the prog that lists my notes). i am not complaining about the whole concept of gnome3. i really like the design, finally there is something to configure my wacom tablets, but that is not enough for a workstation. also this mailing list with all the approval stuff going on delaying emails... it feels like talking to a big cooperation which just wants to get me of their backs i will give g3 another try when the next version comes out... side note, i installed fedora 16 + the nvidia drivers for opengl. greetings, phil ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Experience feedback
On Thu, 2011-08-18 at 22:07 +0200, Olav Vitters wrote: On Thu, Aug 18, 2011 at 09:47:26PM +0200, Rovanion Luckey wrote: It already works, there is no dark magic behind having a visible Power Off button. The Gnome Shell UI however seems to wish it could communicate that the user has to press down Alt before the Power Off button becomes visible via magic. This was already explained, I am not going to repeat. This needs to go in the FAQ, with a pointer to the rationale behind the decision. Would you mind adding it? As far as I can tell, this is not answered in either of these: https://live.gnome.org/GnomeShell/FAQ https://live.gnome.org/GnomeShell/Design/FAQ And this page says *what* happens (and how to access the power off option), but not *why*: https://live.gnome.org/GnomeShell/Design/Whiteboards/SystemStopRestart In the Comments section of that page, Sri and others ask the same question, but it is not answered there yet. Federico ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Experience feedback
Am 19.08.2011 16:28, schrieb Federico Mena Quintero: On Thu, 2011-08-18 at 22:07 +0200, Olav Vitters wrote: On Thu, Aug 18, 2011 at 09:47:26PM +0200, Rovanion Luckey wrote: It already works, there is no dark magic behind having a visible Power Off button. The Gnome Shell UI however seems to wish it could communicate that the user has to press down Alt before the Power Off button becomes visible via magic. This was already explained, I am not going to repeat. This needs to go in the FAQ, with a pointer to the rationale behind the decision. Would you mind adding it? As far as I can tell, this is not answered in either of these: https://live.gnome.org/GnomeShell/FAQ https://live.gnome.org/GnomeShell/Design/FAQ And this page says *what* happens (and how to access the power off option), but not *why*: https://live.gnome.org/GnomeShell/Design/Whiteboards/SystemStopRestart In the Comments section of that page, Sri and others ask the same question, but it is not answered there yet. If such a rationale is added, I would be especially interested in how the environmental concerns are adressed - given that for situations such as turning a computer off over night, suspending takes much more power in the long term. Regards, Denis ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Experience feedback
Hi designers, I joined this list to give you my opinion about gnome 3. I'll first give the good news and then the bad news. First of all: I love the software architecture. The javascript integration is great. It allows me to customize the shell, just as I customize my bash shell. Second: it takes some getting used to. Initially there was a lot I didn't like, as I'm a very conservative person. But I learned to like many things, especially the overlay/shell view is great. It does away with the need for gnome-do. Some things I never learned to like, so I changed them (such as alt-tab over all desktops, it doesn't work for me, I use each desktop for another task I'm working on. Each desktops has some browsers, some editors, some terminals and some more. Alt tabbing between browsers just doesn't work, as it breaks the context) Third: I hate the way you paternalize me. I acknowledge the fact that you are infinitely superior to me as UI designers. Really, I suck, you rule. But you should acknowledge that I know my particular situation much better than you will ever do. So I get angry when I read things like But specifically for shutdown we do think that suspend should be encouraged. It is the easiest way to use your system.. I assure you, to me, it is NOT. If I want to shut it down that is for a reason. So don't tell me what to do, you don't know anything about my situation, so you can't draw any conclusion. The same problem is in the UI: many configuration options have gone. I can't even move icons on the panel, I can't add content to it. When I read about it, it seems that this is a feature and not a bug, to get a more uniform experience. While, for you, as a designer, uniformity over the userbase is a requirement, you should acknowledge that for each individual member of that userbase, it is not. Each one of us has specific needs. So don't try to sell uniformity as something that benefits me. It doesn't, it benefits you. And to make it absolutely clear, I think you have the right to do as you want. You work on it, I just use it. But please, don't tell me you do it for me. It just makes me angry. So my general conclusion is: great job, but if you really intend to make common tasks easier, you should acknowledge that for a part of the userbase customization is a common task. And while the javascript integration allows unprecedented power for customization, the current design makes small customizations very hard. I hope I didn't hurt any feelings. I really appreciate the work you do. I tried to express my discomfort as well and polite as I could. I hope this feedback is useful and may help you understand the outraged responses you get from a lot of people. Wouter ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Experience feedback
On Thu, Aug 18, 2011 at 12:17:46PM +0200, Wouter De Borger wrote: Third: I hate the way you paternalize me. I acknowledge the fact that you are infinitely superior to me as UI designers. Really, I suck, you rule. But ?!? It is not about individual people, just trying to determine what is best for most. This was explained by a designer at the Desktop Summit. First make it work for most, then try and figure out how to make it work for the rest + long tail. you should acknowledge that I know my particular situation much better than you will ever do. So I get angry when I read things like But specifically for shutdown we do think that suspend should be encouraged. It is the easiest way to use your system.. I assure you, to me, it is NOT. If I want Encouraged is something different than making things impossible. It is still possible to do something else. But if you have loads and loads of users, determining what is good for most is difficult. It is just the first release, give it a bit of time. -- Regards, Olav ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Experience feedback
2011/8/18 Olav Vitters o...@vitters.nl It is not about individual people, just trying to determine what is best for most. This was explained by a designer at the Desktop Summit. First make it work for most, then try and figure out how to make it work for the rest + long tail. Making it work for the most of your users? Tell me how did you determine that the larger part of your users *exclusively* use suspend. It already works, there is no dark magic behind having a visible Power Off button. The Gnome Shell UI however seems to wish it could communicate that the user has to press down Alt before the Power Off button becomes visible via magic. -- www.twitter.com/Rovanion ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Experience feedback
On Thu, Aug 18, 2011 at 09:47:26PM +0200, Rovanion Luckey wrote: Making it work for the most of your users? Tell me how did you determine that the larger part of your users *exclusively* use suspend. This was already explained, I am not going to repeat. It already works, there is no dark magic behind having a visible Power Off button. The Gnome Shell UI however seems to wish it could communicate that the user has to press down Alt before the Power Off button becomes visible via magic. This was already explained, I am not going to repeat. -- Regards, Olav ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: feedback
i really would appreciate some kind of input how i can get my alt key back meanwhile i found the keyboard layout settings, tough i cant find an option that frees the alt keythanks in advance.phil On 05/06/2011 09:18 PM, philip ballinger wrote: hi all, gnome3 is starting to work out for me. nice job! i do 3d and composite for a living and will, at some point i will migrate to gnome 3 on my workstation. right now its on my office/testing pc. ill keep it short and just list a few things i miss or still need. wish list: cpu / weather / hamster time tracker applet wacom cintiq / intuos configuration utility easy way of reducing the bling a bit, like the window shadows, reducing the size of the window bar, etc... what i really need: free the alt key shortcut. i need the alt key for rotating my cam in my 3d app and could not find anything in dconf / keyboard shortcuts settings. (in gnome 2 i switched the alt with the super key) what i don't understand: the notification bar, id rather have it in the top bar also my feeling is that i would use the workspace widget if it would be switched with the dash, i anyway use the keyboard for those sort of things, and not so much the mouse, just now i never use it cause i don't want to move my curser across the whole screen. and for the excessive application bar email thread i got used to it...all good - so far on a non production machine :) anyways... gnome 3 is looking really great. gj again. phil ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: GNOME 3.0 feedback and suggestions (for 3.2+)
tir, 03 05 2011 kl. 16:28 -0430, skrev Dokuro: On Mon, May 2, 2011 at 5:45 PM, Frederik Hertzum frederik.hert...@gmail.com wrote: Horizontal desktops missing: = snip ctrl+alt+up/down to change workspaces (virt desktops) That key-combo (or any other for that matter) doesn't allow me to do what I want. I often need more than one set of apps open, which are related in some way, which take up more space (conveniently) than my monitors allows. Simply stacking them in a long list of workspaces will only help if I only have one task (which I often don't). I always set up a 3x3 or 4x4 set of virtual desktops when I'm working on GNOME 2 machines because it allows me to do exactly this; group my apps horizontally and keep several sets of apps open at the same time. Frederik Hertzum so grabbing the app icon and moving it to the workspace you want and then using ctrl+alt+up/down does not work for you, because you need more rows in order to navigate them easier? or another way would be, to have it like the new alt+tab with mouse and all? It would allow me to do something similar, but it quickly becomes cumbersome to remember where things are, it's difficult to set up, since, if I want to have it sorted by task, I sometimes have to rearrange everything, which can take a very long time. Not having workspaces in two dimensions really takes the fun out of using them. Frederik Hertzum ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Starting an app on another workspace? [Was: GNOME 3.0 feedback and suggestions (for 3.2+)]
tir, 03 05 2011 kl. 16:28 -0430, skrev Dokuro: so grabbing the app icon and moving it to the workspace you want and then using ctrl+alt+up/down does not work for you, because you need more rows in order to navigate them easier? Huh. Should that work? I'm in the activity view, so I see the tiled apps of the current workstation, the left hand applications bar [what is the official name of that thing] and on the right hand the tiled workspaces. I grab an app and drag it to a workspace and it opens [starts] in the current workspace. Is that incorrect [something isn't working] or am I misunderstanding the above? [because that would be an awesome feature - especially for apps that take some time to start] ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: GNOME 3.0 feedback and suggestions (for 3.2+)
On Thu, 2011-05-05 at 08:41 +0200, Frederik Hertzum wrote: tir, 03 05 2011 kl. 16:28 -0430, skrev Dokuro: On Mon, May 2, 2011 at 5:45 PM, Frederik Hertzum frederik.hert...@gmail.com wrote: Horizontal desktops missing: = snip ctrl+alt+up/down to change workspaces (virt desktops) That key-combo (or any other for that matter) doesn't allow me to do what I want. I often need more than one set of apps open, which are related in some way, which take up more space (conveniently) than my monitors allows. Simply stacking them in a long list of workspaces will only help if I only have one task (which I often don't). I always set up a 3x3 or 4x4 set of virtual desktops when I'm working on GNOME 2 machines because it allows me to do exactly this; group my apps horizontally and keep several sets of apps open at the same time. It would allow me to do something similar, but it quickly becomes cumbersome to remember where things are, it's difficult to set up, since, if I want to have it sorted by task, I sometimes have to rearrange everything, which can take a very long time. Not having workspaces in two dimensions really takes the fun out of using them. I find I use workspaces far more in GNOME3 than I did previously. They are simpler and much better integrated into the whole scheme of things. [aside: GNOME3 seems a lot snappier/faster to me, switching workspaces is *fast*]. I wonder how common your use-case is; I really can't imagine the great majority of people having greater than 4 or 5 workspaces. That becomes a mentally encumbering workload. I consider myself a 'power' user and I typically end the day with five workspaces, which is few enough to easily navigate in one dimension. 3x3 is 9, 4x4 is 16. That is a lot of workspaces. I know I'd never be able to quickly remember what is where. For 4 -5 workspaces one falls into an easy routine. For me its 1.) Email, xchat, im, SM crap, etc... 2.) Some gnome-terminals, nautilus 3.) Monodevelop, some OOo documents, a browser window for looking at docs. 4.) DbVisualizer, a spreadsheet, maybe a terminal window 5.) Some other documents ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Starting an app on another workspace? [Was: GNOME 3.0 feedback and suggestions (for 3.2+)]
Le jeudi 05 mai 2011 à 09:00 -0400, Adam Tauno Williams a écrit : Huh. Should that work? I'm in the activity view, so I see the tiled apps of the current workstation, the left hand applications bar [what is the official name of that thing] and on the right hand the tiled workspaces. I grab an app and drag it to a workspace and it opens [starts] in the current workspace. Is that incorrect [something isn't working] or am I misunderstanding the above? [because that would be an awesome feature - especially for apps that take some time to start] That's currently working with GTK apps, try with Nautilus for example. But some non-GTK apps don't support this for some reason, and there's a bug open for that in Bugzilla. Regards ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Starting an app on another workspace? [Was: GNOME 3.0 feedback and suggestions (for 3.2+)]
The specification that applications have to support is called startup-notification. http://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt On Thu, May 5, 2011 at 9:40 AM, Adam Tauno Williams awill...@whitemice.orgwrote: On Thu, 2011-05-05 at 15:11 +0200, Milan Bouchet-Valat wrote: Le jeudi 05 mai 2011 à 09:00 -0400, Adam Tauno Williams a écrit : Huh. Should that work? I'm in the activity view, so I see the tiled apps of the current workstation, the left hand applications bar [what is the official name of that thing] and on the right hand the tiled workspaces. I grab an app and drag it to a workspace and it opens [starts] in the current workspace. Is that incorrect [something isn't working] or am I misunderstanding the above? [because that would be an awesome feature - especially for apps that take some time to start] That's currently working with GTK apps, try with Nautilus for example. But some non-GTK apps don't support this for some reason, and there's a bug open for that in Bugzilla. Yep, it appears to work for gnome-terminal and banshee. Not working for Nautilus or Evolution (but opening nautilus and evolution windows always seems odd if you already have an instance open). It doesn't work for DbVisualizer (Java app) or LibreOffice apps. ___ 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
Suspend / Resume [Was: Feedback]
On Sun, 2011-05-01 at 23:40 -0400, Jasper St. Pierre wrote: I'm not suggesting the Terminal for everyday usage. I'm just trying to get some hardware and pm-utils stats so we can solve the problem for other users... all that command will do is print out Supported or Not Supported, just as a starting point for the hellish journey ahead of us: Debugging Linux Power Management Is pm-utils [mentioned below] meant to be a literal command? I have no such command [openSUSE 11.4 x86_64]. I have pm-is-supported, both pm-is-supported --hibernate and pm-is-supported --suspend produce no output and have an exit status of zero (which according to the man page means State available. Suspend worked perfectly for this laptop with GNOME 2.32; after the update suspend/resume is lethal. System resumes to a black screen with a pointer and usually, but not always, some artifact of a window in the center of the screen. Ctrl-Alt-F1 will take me to a console where I can kill X and log in again. I've also walked away from the machine and come back, twice, to find a black screen with nothing but a pointer with even Ctrl-Alt-F1 not working. But while I'm using it GNOME 3 has been fast and stable; I just can't turn my back on it. In System Settings / Power I've unchecked both On AC Power and On Battery suspend options. nVidia Corporation GT216 [GeForce GT 230M] (rev a2) NVIDIA GPU GeForce GT 230M (GT216) at PCI:1:0:0 (GPU-0) 2.6.37.6-0.5-desktop On Sun, May 1, 2011 at 11:25 PM, Allan E. Registos allan.regis...@smpc.steniel.com.ph wrote: Generally I like the gnome philosophy of simplifying things by removing options. But leaving non-technical users with a default setting that does not work is not a good choice Can you give us some hardware details, and try: pm-utils --suspend echo Supported || echo Not supported ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Suspend / Resume [Was: Feedback]
Whoops. I meant 'pm-is-supported', I was just being an idiot when I wrote the email. I'm also even more of an idiot and got the exit statuses reversed: pm-is-supported --suspend echo Not Supported || echo Supported pm-utils is the package that has all this stuff: http://cgit.freedesktop.org/pm-utils/ On Mon, May 2, 2011 at 9:26 AM, Adam Tauno Williams awill...@whitemice.orgwrote: On Sun, 2011-05-01 at 23:40 -0400, Jasper St. Pierre wrote: I'm not suggesting the Terminal for everyday usage. I'm just trying to get some hardware and pm-utils stats so we can solve the problem for other users... all that command will do is print out Supported or Not Supported, just as a starting point for the hellish journey ahead of us: Debugging Linux Power Management Is pm-utils [mentioned below] meant to be a literal command? I have no such command [openSUSE 11.4 x86_64]. I have pm-is-supported, both pm-is-supported --hibernate and pm-is-supported --suspend produce no output and have an exit status of zero (which according to the man page means State available. Suspend worked perfectly for this laptop with GNOME 2.32; after the update suspend/resume is lethal. System resumes to a black screen with a pointer and usually, but not always, some artifact of a window in the center of the screen. Ctrl-Alt-F1 will take me to a console where I can kill X and log in again. Obviously that's not supposed to happen.. All gnome-shell does is defer this to UPower, and the Linux backend eventually calls pm-utils. Can you try running '/usr/sbin/pm-suspend' and see what happens? It could be a fault of gnome-screensaver's locking stuff. I've also walked away from the machine and come back, twice, to find a black screen with nothing but a pointer with even Ctrl-Alt-F1 not working. But while I'm using it GNOME 3 has been fast and stable; I just can't turn my back on it. That sounds even more like the fault of the screensaver. In System Settings / Power I've unchecked both On AC Power and On Battery suspend options. nVidia Corporation GT216 [GeForce GT 230M] (rev a2) NVIDIA GPU GeForce GT 230M (GT216) at PCI:1:0:0 (GPU-0) 2.6.37.6-0.5-desktop Are you running nvidia proprietary or nouveau? On Sun, May 1, 2011 at 11:25 PM, Allan E. Registos allan.regis...@smpc.steniel.com.ph wrote: Generally I like the gnome philosophy of simplifying things by removing options. But leaving non-technical users with a default setting that does not work is not a good choice Can you give us some hardware details, and try: pm-utils --suspend echo Supported || echo Not supported ___ 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: Feedback
Actually that command gives Not supported on my laptop, which doesn't stop me from suspending and resuming without hiccups. Curious. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Feedback
I apologize, I messed it up entirely. pm-is-supported --suspend echo Not supported || echo Supported On Mon, May 2, 2011 at 12:45 PM, Bidossessi SODONON bidossessi.sodo...@yahoo.fr wrote: Actually that command gives Not supported on my laptop, which doesn't stop me from suspending and resuming without hiccups. Curious. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: GNOME 3.0 feedback and suggestions (for 3.2+)
Horizontal desktops missing: = snip ctrl+alt+up/down to change workspaces (virt desktops) That key-combo (or any other for that matter) doesn't allow me to do what I want. I often need more than one set of apps open, which are related in some way, which take up more space (conveniently) than my monitors allows. Simply stacking them in a long list of workspaces will only help if I only have one task (which I often don't). I always set up a 3x3 or 4x4 set of virtual desktops when I'm working on GNOME 2 machines because it allows me to do exactly this; group my apps horizontally and keep several sets of apps open at the same time. Frederik Hertzum ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Feedback
I think it's fine to have the option under the ALT key... the problem is how does the normal user find out? Although with that said... would we want to be more green and go full hibernate? On Mon, May 2, 2011 at 10:28 PM, Allan E. Registos allan.regis...@smpc.steniel.com.ph wrote: - Original Message - From: G. Michael Carter mi...@carterfamily.ca To: Adam Williamson awill...@redhat.com Cc: gnome-shell-list gnome-shell-list@gnome.org Sent: Tuesday, May 3, 2011 10:17:58 AM Subject: Re: Feedback If I'm powering off it's because I'm unplugging the computer. If I'm rebooting it's to update to the new kernel. The, what I that was a lack, of other options was annoying. This is one of the reasons why the GNOME Shell was being accused of being designed by software developers for software developers. End users should have options available. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Feedback
On Tue, 2011-05-03 at 10:28 +0800, Allan E. Registos wrote: If I'm powering off it's because I'm unplugging the computer. If I'm rebooting it's to update to the new kernel. The, what I that was a lack, of other options was annoying. This is one of the reasons why the GNOME Shell was being accused of being designed by software developers for software developers. End users should have options available. That really doesn't make any sense unless you believe that software developers never update kernels, which is pretty clearly not the case. The design discussions specifically highlighted cases where powering off does make sense; the case where an update requires a reboot is intended to be handled through the package update system, which makes sense. The case where you are rebooting to a different operating system was also considered and acknowledged as something that should be handled, AIUI, but an acceptable design hasn't yet been implemented. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Feedback
On Saturday, 30 April, 2011 09:40 PM, Jasper St. Pierre wrote: == Suspend instead of Shutdown == Surely this has been discussed extensively, I just want to mention that suspend simply does not work for me (tested on two computers, both do not wake up correctly). I guess they do not want to listen as I recall. Generally I like the gnome philosophy of simplifying things by removing options. But leaving non-technical users with a default setting that does not work is not a good choice. It should only be a default if we detect you computer can support it. Can you give us some hardware details, and try: pm-utils --suspend echo Supported || echo Not supported in a terminal? IMO, the presence of Suspend should be only available to development builds(or optional in stable releases). I only once use Suspend in my system because it will mess the system and I will be forced to use the _reset_ button and I will never use it again as it may physically damage the Hard Drive. Calling the terminal is just a band aid, it doesn't work at large. Regards, Allan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Feedback
I'm not suggesting the Terminal for everyday usage. I'm just trying to get some hardware and pm-utils stats so we can solve the problem for other users... all that command will do is print out Supported or Not Supported, just as a starting point for the hellish journey ahead of us: Debugging Linux Power Management On Sun, May 1, 2011 at 11:25 PM, Allan E. Registos allan.regis...@smpc.steniel.com.ph wrote: On Saturday, 30 April, 2011 09:40 PM, Jasper St. Pierre wrote: == Suspend instead of Shutdown == Surely this has been discussed extensively, I just want to mention that suspend simply does not work for me (tested on two computers, both do not wake up correctly). I guess they do not want to listen as I recall. Generally I like the gnome philosophy of simplifying things by removing options. But leaving non-technical users with a default setting that does not work is not a good choice. It should only be a default if we detect you computer can support it. Can you give us some hardware details, and try: pm-utils --suspend echo Supported || echo Not supported in a terminal? IMO, the presence of Suspend should be only available to development builds(or optional in stable releases). I only once use Suspend in my system because it will mess the system and I will be forced to use the _reset_ button and I will never use it again as it may physically damage the Hard Drive. Calling the terminal is just a band aid, it doesn't work at large. Regards, Allan ___ 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: Feedback
On Sun, May 1, 2011 at 8:25 PM, Allan E. Registos allan.regis...@smpc.steniel.com.ph wrote: On Saturday, 30 April, 2011 09:40 PM, Jasper St. Pierre wrote: == Suspend instead of Shutdown == Surely this has been discussed extensively, I just want to mention that suspend simply does not work for me (tested on two computers, both do not wake up correctly). I guess they do not want to listen as I recall. Well, I wouldn't say that.. I'm sure there at least in Fedora that the distros will be trying to get suspend working. Suspend has to work. It needs to be exactly like the Mac. My wife for instances, always closes, she never shuts down her laptop. The same can be said of both desktop and laptop. It is a matter of getting distros to fix it. Personally, gnome 3 is about pushing distros to start fixing as much of this stuff as possible. sri ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Feedback
After installing Ubuntu Natty with Gnome Shell from the PPA and using it for a few hours, I also want to give some feedback. First of all Gnome Shell appears conceptually nice and consistent (this is my main criticism regarding Unity, which is inconsistent and buggy in many places). I am not sure yet if I like the new workflow better than the traditional one, but I will definitely test it for a longer period of time. My main points are the following ones: == Suspend instead of Shutdown == Surely this has been discussed extensively, I just want to mention that suspend simply does not work for me (tested on two computers, both do not wake up correctly). Generally I like the gnome philosophy of simplifying things by removing options. But leaving non-technical users with a default setting that does not work is not a good choice. == Switching Applications == Before actually testing Gnome Shell in production use with many open windows, I had imagined that switching applications in the expose view would work a bit faster and more efficient. With many windows I often find myself spending time on searching for the right one, as their minified versions look very similar. I think in the expose view, each application's icon should be shown in the minified window. This way finding the right window would be easier. Also for my feeling, the animation when opening and leaving the activities view takes a bit too much time. == Minor remarks == - I really miss a way to launch applications on startup. In Ubuntu the gnome-session-properties dialog can still be accessed from the command line, but settings are ignored. - When opening a picture in Gimp, only one of Gimp's multiple windows (the actual picture) appears in the Gnome Shell expose view. When I move this window to a different desktop, the other windows (the toolboxes) stay on the old desktop. Obviously I can not work with Gimp without toolboxes and I have no way of getting them to the new Desktop using Gnome Shell. Using the context menus of the Toolboxes title bars is a workaround, but not a nice one. - I would suggest adding hotkeys to snap windows in different ways, i.e. to use only the top right quarter of the screen (i.e. Super - Keypad 9). Such a feature would be nice for power users and it would not disturb regular users. - One nice thing: Gnome Shell works well with Guake. Regards, Marc ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Feedback
On Sat, Apr 30, 2011 at 9:12 AM, Marc Fouquet marc.fouq...@gmx.de wrote: After installing Ubuntu Natty with Gnome Shell from the PPA and using it for a few hours, I also want to give some feedback. First of all Gnome Shell appears conceptually nice and consistent (this is my main criticism regarding Unity, which is inconsistent and buggy in many places). I am not sure yet if I like the new workflow better than the traditional one, but I will definitely test it for a longer period of time. My main points are the following ones: == Suspend instead of Shutdown == Surely this has been discussed extensively, I just want to mention that suspend simply does not work for me (tested on two computers, both do not wake up correctly). Generally I like the gnome philosophy of simplifying things by removing options. But leaving non-technical users with a default setting that does not work is not a good choice. It should only be a default if we detect you computer can support it. Can you give us some hardware details, and try: pm-utils --suspend echo Supported || echo Not supported in a terminal? == Switching Applications == Before actually testing Gnome Shell in production use with many open windows, I had imagined that switching applications in the expose view would work a bit faster and more efficient. With many windows I often find myself spending time on searching for the right one, as their minified versions look very similar. I think in the expose view, each application's icon should be shown in the minified window. This way finding the right window would be easier. Also for my feeling, the animation when opening and leaving the activities view takes a bit too much time. You can use the dash to switch between running applications too! I'm not sure why, but most people don't discover this... == Minor remarks == - I really miss a way to launch applications on startup. In Ubuntu the gnome-session-properties dialog can still be accessed from the command line, but settings are ignored. There should be something in the new control center. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Feedback
There's a gradient background for apps that are running. Look at gnome-terminal vs. Brasero in the mockup: http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-application-picker.png On Sat, Apr 30, 2011 at 12:04 PM, Sriram Ramkrishna s...@ramkrishna.mewrote: On Sat, Apr 30, 2011 at 6:40 AM, Jasper St. Pierre jstpie...@mecheye.netwrote: == Switching Applications == Before actually testing Gnome Shell in production use with many open windows, I had imagined that switching applications in the expose view would work a bit faster and more efficient. With many windows I often find myself spending time on searching for the right one, as their minified versions look very similar. I think in the expose view, each application's icon should be shown in the minified window. This way finding the right window would be easier. Also for my feeling, the animation when opening and leaving the activities view takes a bit too much time. You can use the dash to switch between running applications too! I'm not sure why, but most people don't discover this... I think it is because one can't really differentiate a running app and one that is just a launcher. I think on the Mac, there is some indication that it is a running app, by a dot or something. I have to look at OSX really. So if you were to enhance the icon saying that it is running that would be a good step towards getting people to use it more. If there is no bug on it, I'll file one. sri ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Feedback
On Sat, Apr 30, 2011 at 3:40 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: You can use the dash to switch between running applications too! I'm not sure why, but most people don't discover this... I believe it's some kind of muscle memory. The dash reminds a lot the old panels, and the buttons in the old panels are for launching new application instances. In fact, this was annoying me when I started using the Shell, and one of the first things I searched was how to actually open another instance of the same app. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Feedback
On Sat, Apr 30, 2011 at 6:07 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: There's a gradient background for apps that are running. I always though it was a bit too subtle, I hope it can evolve in something more obvious for 3.2 -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: GNOME 3.0 feedback and suggestions (for 3.2+)
2011/4/29 Jasper St. Pierre jstpie...@mecheye.net: On Thu, Apr 28, 2011 at 6:06 PM, Frederik Hertzum Just for clarification, desktop means workspace? Yes: I was thinking in the term virtual desktop. snip Maximized windows and title bars: snip This has been suggested a significant number of times before, for mostly the same reasons. I'm unsure of why it hasn't been done, but I'm quite sure it's for technical limitations. No need for me to propose it again then, I suppose. Horizontal desktops missing: = snip I'm really confused at what you mean by this. Why do you feel you need horizontal workspaces? I would really like to have related workspaces grouped in some way -- for example, I would like to have all of my work related workspaces in a group of it's own and all of my slack based workspaces in another group. Horizontal workspaces would allow me to do this. Volume control: = snip This is a good idea, but I'm curious how it would be implemented. Me too. I have some ideas, but I'm afraid it will mess up the UI and I'm not even sure if it's possible -- depending on how pulseaudio works. snip This sort of file management stuff is a big focus for gnome-shell 3.2, under the name Finding and Reminding. I don't think the designers have an idea of how it would look yet, but I know Seif and Federico have been working extremely hard on getting Shell-based search and a journal overview ready. Awesome. Hiding/minimizing windows: = snip What are hidden windows? Minimzied windows.This is just a random idea though and I'm not sure it's even worth considering any further. I was hoping to fix the hidden/minimized window issue. Program menus: = snip Again, I'm unsure of what you mean by this. If there is anything missing entirely from the Applications tab in the overview, that's an extremely bad bug. Can you give examples of what's missing? system-config-services for example -- but I just found out the reason: apparently Fedora no longer carries the .desktop files, so this is not a GNOME issue. snip Programmes remembering their desktop: = snip There is no which workspace in the dynamic workspaces of the shell. The most you really can do is the current workspace and a new workspace, and while it may be useful to mark an application as starting on a new workspace, I think good ol' drag and drop is fine here. Well, the idea was basically to have some sort of workspace session which could be launched all at once, rather than having to launch each individual app. Thinking more about it, maybe it should simply be possible to create an icon which would launch a set of apps in a new workspace, rather than remembering a grouping automatically (I never really liked that idea anyway). I hope this is helpful. Frederik Herzum -- Date stamps are your friends ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list Again, I hope this is helpful and a bit clearer than before. Frederik Hertzum -- Date stamps are your friends ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
GNOME 3.0 feedback and suggestions (for 3.2+)
This was inspired by the discussion Window controls for GNOME 3 by Owen Taylor -- https://mail.gnome.org/archives/gnome-shell-list/2011-February/msg00192.html = I think it's important for people to know a bit about how I use my computer if they are to get anything out of reading my feedback -- so here goes: I am a CS student who frequently use SSH from terminals while reading junk in Firefox or epiphany and having several editors open (either gedit or anjuta) and compiling stuff in more terminals and talking to people in Pidgin and listening to music almost all of the time. I have two monitors. The primary monitor is 22 and the secondary is 20. I group my windows so that my main editor is maximized on the primary monitor, have a gnome-terminal with multiple tabs taking up half the left of the secondary monitor and (usually) one IM session upon to talk to people about the code I'm editing on the right half of the secondary monitor. I usually have everything else in separate desktops. = The important stuff: (De)Maximize/Minimize buttons: = I don't miss the (de)maximize/minimize buttons at all Close button: = Getting rid of the close button didn't hurt at all. I now close by hitting ALT+F4 or killing it in the overview. Maximized windows and title bars: = The extra bar below the top bar bar is annoying when maximizing a window I suggest fusing the title bar of a window with the top bar when maximized and possibly moving the clock to the side: Current layout AI C MU --- T --- Becomes one of AI T --- CMU or AI T --- MCU A = Activity area I = current Icon (may want to get rid of that as well) T = Title C = Clock M = Menu area (volume control, networkmanager interface etc) U = User menu This is especially nice on low resolution monitors since the top bar + a title bar takes up a lot of space (I, for example, always go fullscreen when I can on my EEE, which does not have GNOME 3). Problems: It may be confusing for people when there's nothing that separates the window from the rest of the desktop. It may be even more confusing if maximized windows on secondary monitors look different from a maximized window on the primary monitor. Horizontal desktops missing: = This is really annoying. Especially when GNOME 3.0 is so focused on using desktops. My ideal interface would be having horizontal desktops, with each vertical desktop having it's own list of with one of them being marked current (which means this is the desktop to switch to when switching to that desktop) -- new desktops would be created by moving a desktop (ctrl+alt+right arrow) to a new desktop or by clicking some icon on the desktop in the overview (an empty desktop for example) Problems: May take up too much space in the overview. May be confusing if people have more than one physical monitor Volume control: = Since pulseaudio has per-application volume control it may be a good idea to allow the user to control the volume of an app in the window of that app, rather than forcing the user to open the volume control, pick a tab with a list of connected apps, look for the app and then change the volume. Problems: can't really see any, except that it means GNOME 3 is tied up with pulseaudio. But that may not be a real problem. Could be done using plugins if that's in place. Otherwise it might be a good reason to put plugins in place. Music: = I'm missing a music tab (correct term?) in the overview; I'll make it myself, if possible, some time after may 19 (date for BA project hand in) -- unless someone beats me to it (naturally). Mind you I have no experience with any of the interfaces involved at all. Documents: = I'm missing a Document tab too. Should contain files grouped by type (may want to make a tab per document type) found in either $HOME or a set of designated document directories (text, audio, video, source, whatever). Tags: = Tags for documents to allow grouping in the Documents tabs. When I'm reading roleplaying books, I would be likely to also want to read other roleplaying books -- usually from the same set of books -- and wouldn't care much about x86 processor manuals. Hiding/minimizing windows: = I'm not sure about this, but maybe a hiden window should appear
Re: GNOME 3.0 feedback and suggestions (for 3.2+)
On Thu, Apr 28, 2011 at 6:06 PM, Frederik Hertzum frederik.hert...@gmail.com wrote: This was inspired by the discussion Window controls for GNOME 3 by Owen Taylor -- https://mail.gnome.org/archives/gnome-shell-list/2011-February/msg00192.html = I think it's important for people to know a bit about how I use my computer if they are to get anything out of reading my feedback -- so here goes: I am a CS student who frequently use SSH from terminals while reading junk in Firefox or epiphany and having several editors open (either gedit or anjuta) and compiling stuff in more terminals and talking to people in Pidgin and listening to music almost all of the time. I have two monitors. The primary monitor is 22 and the secondary is 20. I group my windows so that my main editor is maximized on the primary monitor, have a gnome-terminal with multiple tabs taking up half the left of the secondary monitor and (usually) one IM session upon to talk to people about the code I'm editing on the right half of the secondary monitor. I usually have everything else in separate desktops. Just for clarification, desktop means workspace? snip Maximized windows and title bars: = The extra bar below the top bar bar is annoying when maximizing a window I suggest fusing the title bar of a window with the top bar when maximized and possibly moving the clock to the side: Current layout AI C MU --- T --- Becomes one of AI T --- CMU or AI T --- MCU A = Activity area I = current Icon (may want to get rid of that as well) T = Title C = Clock M = Menu area (volume control, networkmanager interface etc) U = User menu This is especially nice on low resolution monitors since the top bar + a title bar takes up a lot of space (I, for example, always go fullscreen when I can on my EEE, which does not have GNOME 3). Problems: It may be confusing for people when there's nothing that separates the window from the rest of the desktop. It may be even more confusing if maximized windows on secondary monitors look different from a maximized window on the primary monitor. This has been suggested a significant number of times before, for mostly the same reasons. I'm unsure of why it hasn't been done, but I'm quite sure it's for technical limitations. Horizontal desktops missing: = This is really annoying. Especially when GNOME 3.0 is so focused on using desktops. My ideal interface would be having horizontal desktops, with each vertical desktop having it's own list of with one of them being marked current (which means this is the desktop to switch to when switching to that desktop) -- new desktops would be created by moving a desktop (ctrl+alt+right arrow) to a new desktop or by clicking some icon on the desktop in the overview (an empty desktop for example) Problems: May take up too much space in the overview. May be confusing if people have more than one physical monitor I'm really confused at what you mean by this. Why do you feel you need horizontal workspaces? Volume control: = Since pulseaudio has per-application volume control it may be a good idea to allow the user to control the volume of an app in the window of that app, rather than forcing the user to open the volume control, pick a tab with a list of connected apps, look for the app and then change the volume. Problems: can't really see any, except that it means GNOME 3 is tied up with pulseaudio. But that may not be a real problem. Could be done using plugins if that's in place. Otherwise it might be a good reason to put plugins in place. This is a good idea, but I'm curious how it would be implemented. snip This sort of file management stuff is a big focus for gnome-shell 3.2, under the name Finding and Reminding. I don't think the designers have an idea of how it would look yet, but I know Seif and Federico have been working extremely hard on getting Shell-based search and a journal overview ready. Hiding/minimizing windows: = I'm not sure about this, but maybe a hiden window should appear as a tab in the overview (either individual tabs for each window or one huge one for all hidden windows). What are hidden windows? Program menus: = I am badly missing the set of menu entries which are not in Programmes. I usually get around it though, but some times I really need the menus and don't remember the name of the binary, meaning I can't even launch it from a terminal before desperately searching the web and where ever I think it might be. This quickly gets
Re: Just another Feedback Post
On Sat, Mar 12, 2011 at 10:08 AM, Christoph Hack christ...@tux21b.org wrote: Dear Gnome Shell Team! I started trying out gnome-shell via jhbuild the day before yesterday and I am deeply impressed! Well done! The things I like most are the new automatic workspace management, the notification system, the maximize (half) function per DnD, single instances per default and a few more features. :) Even going through the activities overview when switching windows starts to makes sense now. First I liked it, then on the next day I was a bit annoyed, but now I think I have already adapted to the less distracting working habit. Hopefully the new notification system will finally bring the remaining constant window switching habit to an end once the applications are starting to use it. So, and here comes the list of things I don't currently like: (1) Currently the most annoying thing is when I try to click on an Icon in the bottom notification bar. Let's say Banshee. Whenever my mouse pointer reaches the icon, the icon moves away and the title of the Application (in that case Banshee) appears beside it. Unfortunately, I can't simply click on the text (that took me some time to find out, first I just thought the system isn't always reacting), so I have to start chasing the small icon... Please change that :) This is bug https://bugzilla.gnome.org/show_bug.cgi?id=630842. The fix will land before code freeze. (2) When I click to adjust the volume bar in the system panel, the audio bubble stays open, so I can re-adjust it and so on, which is good. But when I click on Bluetooth on/off the bubble closes immediately, so I can't see the button toggling its state (Have i hit the correct entry?) and I can't change additional options like Bluetooth Visibility on/off. Imho all those bubbles should stay open until I click somewhere else. It's been talked about, gcampax should be able to give more information. (3) Pressing Strg+Alt+Tab in the overview to gain keyboard support is not very intuitive and the combination is hard to type. (4) Switching open windows by name (by hitting Super_L, typing Terminal or Chrome and pressing Enter) is nearly unusable on my small Eee (Atom CPU) since the search feature takes quite long to react, blocking the whole workflow. This is due to icons taking so long to load, and the biggest workflow breaker for me right now. Not sure if there is going to be a fix before gnome3 is released, but I hope so. (5) The fonts in the shell theme are far too big. I've changed the font settings on my Eee to 78 dpi, but the shell fonts aren't affected so they are now twice as big (felt sense) as the application fonts. There is already a bug report with patches, so please integrate it. (6) The gnome-terminal (and maybe other transparent windows) has only an transparent background when its fully maximized and a solid one when it's in normal mode or maximized to only one half of the screen. Bug or intention? Sounds like https://bugzilla.gnome.org/show_bug.cgi?id=635268 So, that's all. Keep up the good work! Regards, Christoph ___ 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: Feedback on gnome-shell 2.29.0-3
Johannes Schmid j...@jsschmid.de writes: (Note: I am not a gnome-shell developer, I hope those will also answer because I think you make some interesting points) They are probably busy coding, so I submitted some bug reports instead. It would be nice to have more meta data describing each program. If I search for a string such as calendar, schedule or appointment or date then I would like to find evolution-calendar. If I search for a part of a mime-type such as ogg and excel, then I would like to find the programs that can handle the given mime-type. Guess that can be fixed with better desktop files. Probably a nice idea to file a meta-bug for this. Looks like a good GNOME Goal. The desktop file already contains a list of mime-types. As an example the file gnumeric.desktop already contains the string excel. I reported this bug, but it turned out to be a duplicate. https://bugzilla.gnome.org/show_bug.cgi?id=622166 https://bugzilla.gnome.org/show_bug.cgi?id=609207 As far as I xcan see the freedesktop.org standard does not allow you to add metadata such as calendar, schedule or appointment or date to a desktop file. Perhaps this feature requires higher politics. http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html Thank you for the answers Niels ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Feedback on gnome-shell 2.29.0-3
Johannes Schmid j...@jsschmid.de writes: Am Freitag, den 18.06.2010, 13:03 +0200 schrieb Niels L. Ellegaard: Today I made gnome-shell work for the first time, and I have spend a few hours toying around in gnome-shell 2.29.0-3 on Debian. It looks shiny, but I also discovered some problems. I don't know how many of these are fixed in the newest version of gnome-shell, so feel free to ignore selectively. It not really makes sense to discuss things when you only tested 2.29.0 which is very pre alpha. You should at least try one of the 2.31.x builds to get a useful impression. That is a good point. Here is an updated version of my mail. I use the following instructions to build, and I had no problem compiling. I like the way that the script suggested me which debian packages to install http://live.gnome.org/GnomeShell It would be nice to have a simple and visible way to disable gnome-shell animations. Perhaps the animations should be disabled by default. It is difficult for a new user to guess you can use the find-dialog to search for a general string such as game or CD or spreadsheet. Therefore it is difficult to use the activities dialog to find a program to burn a CD or to create a spreadsheet. One suggestion is to add a few links such as as office program, Internet, video, or game to the extended application menu. If I pressed a link then the corresponding text could be typed in to the find dialog, and I could get the search results. That would teach me how to use the system. Alternatively you could use vertical lines to part the extended application menu in to sections. It would be nice to have more meta data describing each program. If I search for a string such as calendar, schedule or appointment or date then I would like to find evolution-calendar. If I search for a part of a mime-type such as ogg and excel, then I would like to find the programs that can handle the given mime-type. I like the idea of having 6 visible application icons in the activities menu, but it is confusing that these 6 icons are a mixture between a favorite list and a kind of windows list. The icons corresponding to running programs disappear when I close the program, but the favorites do not disappear when I close the program. That leaves an impression that gnome-shell is somewhat unpredictable. If I right click on one of the 6 application icons then I get a menu that mixes up configuration behavior (changing favorites) with navigation behavior (find a running instance of a given program). I find that confusing, and it slows me down because I am afraid of pressing a menu entry that adds or removes a favorite. If you train new users to use the 6 icons in the activities menu as a windows switcher then they may run in to problems as soon as their browser creates two windows. The problem is that new users will not automatically guess that they have to use the right click menu to find the hidden browser window. Maybe the best solution is to remove the icons of running programs from the applications section of the activities menu. This will not cause problems because the user can always use the workspace selector to move between windows. Of course some vision imparted users will find fit distinguish be between the windows in the window selector, but perhaps you can solve this by placing icons on top of the programs on top of the windows in the workspace selector. (Place a firefox icon on to of the firefix window... etc.) If the activities menu is open then I cannot press an icon to open a minimized program such as empathy, gnotes, or gnome-xchat. Ideally pressing an icon on the menu bar should close the activities dialog. (Omar suggested that this was a gtk issue) If I use the workspace selector and press in the space between two windows in one of the minimized work spaces then nothing happens. I have to press exactly on top of a window in a minimized workspace. That requires me to spend extra time aiming with the mouse. I don't think that users should be allowed to use the workspace selector to close a running program. I think that the danger of closing a program by mistake is too high. If a user makes this mistake once, he may gain a lasting mistrust to the workspace selector. Between the activities menu and the clock I found a widget dsiplaying the name of the window that is presently open. Maybe this widget work in progress, but right now it is not so useful. Maybe it would be better to place a window list or a list of active programs here. If you are afraid of using too much space, then you can remove the text and just put the icons coprespnoding to the active windows. I would like the calendar dialog to contain information from evolution calendar and evolution tasks. The menu in the upper right corner has an IM-icon and it allows me to set my IM-status, but it doesn't allow me to send an IM-message. I find that confusing. Perhaps you could rename the menu in the upper right corner into account.
Re: Feedback on gnome-shell 2.29.0-3
Hi! (Note: I am not a gnome-shell developer, I hope those will also answer because I think you make some interesting points) It would be nice to have a simple and visible way to disable gnome-shell animations. Perhaps the animations should be disabled by default. Well, besides the fade in/fade out and some little bling for the activities button there aren't really many animations. It's using opengl anyway so you gain nothing on the driver issues site (like you would in the metacity/compiz case). But it could be an option. It is difficult for a new user to guess you can use the find-dialog to search for a general string such as game or CD or spreadsheet. Therefore it is difficult to use the activities dialog to find a program to burn a CD or to create a spreadsheet. One suggestion is to add a few links such as as office program, Internet, video, or game to the extended application menu. If I pressed a link then the corresponding text could be typed in to the find dialog, and I could get the search results. That would teach me how to use the system. Alternatively you could use vertical lines to part the extended application menu in to sections. I think the text-entry is a but work-in-progress right now but having buttons seems suboptimal. I would rather use some kind of tooltip (maybe force when you open the shell first) to explain the field. It would be nice to have more meta data describing each program. If I search for a string such as calendar, schedule or appointment or date then I would like to find evolution-calendar. If I search for a part of a mime-type such as ogg and excel, then I would like to find the programs that can handle the given mime-type. Guess that can be fixed with better desktop files. Probably a nice idea to file a meta-bug for this. Looks like a good GNOME Goal. If you train new users to use the 6 icons in the activities menu as a windows switcher then they may run in to problems as soon as their browser creates two windows. The problem is that new users will not automatically guess that they have to use the right click menu to find the hidden browser window. Well, 80% of the space in the overview shows the windows on the right and that's what should be used to switch windows. If the activities menu is open then I cannot press an icon to open a minimized program such as empathy, gnotes, or gnome-xchat. Ideally pressing an icon on the menu bar should close the activities dialog. (Omar suggested that this was a gtk issue) Yeah, that's not intended. If I use the workspace selector and press in the space between two windows in one of the minimized work spaces then nothing happens. I have to press exactly on top of a window in a minimized workspace. That requires me to spend extra time aiming with the mouse. Looks like a valid point, you should file a bug about it. I don't see a design reason why that shouldn't work. Between the activities menu and the clock I found a widget dsiplaying the name of the window that is presently open. Maybe this widget work in progress, but right now it is not so useful. Maybe it would be better to place a window list or a list of active programs here. If you are afraid of using too much space, then you can remove the text and just put the icons coprespnoding to the active windows. It's the yet unfished application menu. This will show menu items that work on the whole application in distinction from the normal menu items that work on the current document. I would like the calendar dialog to contain information from evolution calendar and evolution tasks. As far as I know that is planned. Regards, Johannes 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
Feedback on gnome-shell 2.29.0-3
Today I made gnome-shell work for the first time, and I have spend a few hours toying around in gnome-shell 2.29.0-3 on Debian. It looks shiny, but I also discovered some problems. I don't know how many of these are fixed in the newest version of gnome-shell, so feel free to ignore selectively. It would be nice to have a simple and visible way to disable gnome-shell animations. Perhaps the animations should be disabled by default. It is difficult for a new user to guess you can use the find-dialog to search for a general string such as game or CD or spreadsheet. Therefore it is difficult to use the activities dialog to find a program to burn a CD or to create a spreadsheet. Perhaps the extended application menu could contain a links to a few predefined searches such as office program, internet, video, or game. If I pressed a link then the coresponding text could be typed in to the find dialog, and I could get the search results. This would teach me how to use the system. If the activities menu is open I cannot open the menu in the upper right corner. Ideally opening one menu should close the other. If the activities menu is open and I then I cannot press an icon on the menu bar to open a minimized program such as empathy, gnotes, or gnome-xchat. Ideally pressing an icon on the menu bar should close the activities dialog. It would be nice to be able to use alt-ctrl-left/right while the activities dialog is open. On my laptop I have to press three buttons simultaneously to use the shortcut alt-f1 to open the activities dialog. The problem is that f1 is a two button combination. Perhaps you could change this shortcut to something like ctrl-esc. Once the activities dialog is open, I would like to be able to use the tab key or arrow keys to select a program or document to open. Right now I have to use the mouse. The menu bar contains a small graphic with the name of the window that is presently open. As far as I can see this graphic doesn't do anything. Perhaps you can replace it with a window-list. I would like the calendar dialog to contain information from evolution calendar and evolution tasks. The menu in the upper right corner allows me to set my IM-status, but it doesn't allow me to send an IM-message. I find that confusing. The menu in the upper right corner has my name as a title. That makes it difficult for me to search for help on google and in the gnome help system. If I type my name in to google I don't get help on the gnome-shell menu system. The sidebar contains the same information as the activities menu, so perhaps it is redundant. It would be nice to have something like the windows sidebar where I can place a list of small helpful gadgets. The workspace selector applet of gnome 2.28 tells me which program is opened in which workspace. This information is always visible, so I do not have to press any buttons to get it, and that allows me to use ctrl-alt-left/right very efectively. In gnome shell I have to open the activities dialog and have a look at the work spaces, before I can make a choice of where I want to go. That slows me down. Perhaps you could solve this problem by adding more information to the popup that appears when I press ctrl-alt-left/right. That is all for now. I am looking forward to seeing how the gnome-shell will evolve. Niels ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Feedback on gnome-shell 2.29.0-3
If the activities menu is open I cannot open the menu in the upper right corner. Ideally opening one menu should close the other. Last I tried gnome shell I was able to click my name in the overlay made so I guess the same will happen for system indicators too. If the activities menu is open and I then I cannot press an icon on the menu bar to open a minimized program such as empathy, gnotes, or gnome-xchat. Ideally pressing an icon on the menu bar should close the activities dialog. I face the same problem in unity as well so the problem certainly is not in gnome shell. maybe gtk? On my laptop I have to press three buttons simultaneously to use the shortcut alt-f1 to open the activities dialog. The problem is that f1 is a two button combination. Perhaps you could change this shortcut to something like ctrl-esc. Super key also gets you to overlay mode so its a single key. Once the activities dialog is open, I would like to be able to use the tab key or arrow keys to select a program or document to open. Right now I have to use the mouse. Not sure about this but I *think* its fixed. The menu bar contains a small graphic with the name of the window that is presently open. As far as I can see this graphic doesn't do anything. Perhaps you can replace it with a window-list. Not getting you but if you are referring to the name of the window in the top panel in the latest versions its a menu but its not finished. currently clicking on it reveals a menu with 'quit' The menu in the upper right corner allows me to set my IM-status, but it doesn't allow me to send an IM-message. I find that confusing. I dont think its confusing at all. its used to set your status not chat. though gnome shell have message tray in the bottom. The menu in the upper right corner has my name as a title. That makes it difficult for me to search for help on google and in the gnome help system. If I type my name in to google I don't get help on the gnome-shell menu system. Its the name of the user what do you expect? The sidebar contains the same information as the activities menu, so perhaps it is redundant. It would be nice to have something like the windows sidebar where I can place a list of small helpful gadgets. sidebar is removed in the later versions. it was indeed annoying. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Feedback on gnome-shell 2.29.0-3
Omer Akram om2...@ubuntu.com writes: The menu in the upper right corner has my name as a title. That makes it difficult for me to search for help on google and in the gnome help system. If I type my name in to google I don't get help on the gnome-shell menu system. Its the name of the user what do you expect? Thank you for the answers. If the menu in the upper right corner was renamed the menu into account then I could search for the strings account and gnome-shell to find help. That would be helpful. A title such as account would also help me understand what the entries in the menu have in common. Niels ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Feedback on gnome-shell 2.29.0-3
Hi! Am Freitag, den 18.06.2010, 13:03 +0200 schrieb Niels L. Ellegaard: Today I made gnome-shell work for the first time, and I have spend a few hours toying around in gnome-shell 2.29.0-3 on Debian. It looks shiny, but I also discovered some problems. I don't know how many of these are fixed in the newest version of gnome-shell, so feel free to ignore selectively. It not really makes sense to discuss things when you only tested 2.29.0 which is very pre alpha. You should at least try one of the 2.31.x builds to get a useful impression. Regards, Johannes 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
UX feedback after few days
Hello. After using gnome-shell for a few days I think it's great! And as there always is something to improve I would like to share some observations. 1. Right click menus are hardly discoverable. I had no clue how to add apps to favourites until I read cheat sheet. I even resorted to editing GConf keys directly. I would suggest small pin in the corner. Or making the application name on the icon separate clickable area, that shows the dropdown menu. 2. All applications menu is hard to use with apps that have longer names. With apps like Opera it is no problem, but if I see Editor ... I really have no idea what the app does. 3. Bottom notification area telepathy chat client is great. But I think it should be provided by separate application utilising gnome-shell provided infrastructure. It may be a killer feature, so it may be a mandatory (but switchable) dependency. And it does not play nice with Empathy. It eats messages before they reach Empathy, so I have no chance of seeing them later in Empathy chat history. -- Tomasz Sterna Instant Messaging EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/ ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Quick feedback: I love gnome-shell for task-switching
Instead of right-clicking for #1 you can also drag and drop the icon on to the workspace to launch a new instance I think the favourites area of the overview is supposed to replace the panel shortcuts, you can add to favourites with dnd. 2010/1/7 nodata l...@nodata.co.uk: Some thoughts after testing gnome-shell-2.28.0-3.fc12 for two days. I really really like using gnome-shell for switching applications and would be happy to use it for just that. I made a few notes specific to the way I use gnome. 1. Make it easy to launch a new instance of an application I use lots of gnome terminals filled with tabs. One window of tabbed sessions for prod servers, one for test, etc. Clicking to start a terminal would always switch to the current terminal I had open. Right-clicking showed me that I could open a new instance of the application, but this was so much harder than the old way: clicking the terminal icon in the panel at the top of the screen. While writing this e-mail I decided to check if Shift+click did what I expected: nope. Just before sending this e-mail I tried Ctrl+click: bingo! Much better, but gnome-shell either needs to hint at this behaviour, or it needs to provide the old simple clickable icon in panel. For someone who religously starts and stops terminals for separate tasks (actually for starting applications generally) the old panel is more efficient: one click without anything else. 2. Could make it easier for users to test People have their common apps in their panel. Can they be imported? I'm not allowed to drag and drop them, the panels is gone! This would save the frustration of adding apps there. 3. Window behaviour I really like the way the windows are spaced apart in the app switcher view, and the way new virtual desktops can be added and deleted. If a specific desktop could be removed rather than the last, I would have no suggestions here, other than to let desktops be movable to change their order. 4. Probable bugs I need to be able to see the date: please use my date format at the top of the screen. Volume control needs to expand like under metacity. nd ___ 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: Quick feedback: I love gnome-shell for task-switching
I just reread what you meant by #2, if you had a custom launcher on the panel have a look in the folder .gnome2/panel2.d/default/launchers for now 2010/1/7 Bob Hazard linuxoflon...@googlemail.com: Instead of right-clicking for #1 you can also drag and drop the icon on to the workspace to launch a new instance I think the favourites area of the overview is supposed to replace the panel shortcuts, you can add to favourites with dnd. 2010/1/7 nodata l...@nodata.co.uk: Some thoughts after testing gnome-shell-2.28.0-3.fc12 for two days. I really really like using gnome-shell for switching applications and would be happy to use it for just that. I made a few notes specific to the way I use gnome. 1. Make it easy to launch a new instance of an application I use lots of gnome terminals filled with tabs. One window of tabbed sessions for prod servers, one for test, etc. Clicking to start a terminal would always switch to the current terminal I had open. Right-clicking showed me that I could open a new instance of the application, but this was so much harder than the old way: clicking the terminal icon in the panel at the top of the screen. While writing this e-mail I decided to check if Shift+click did what I expected: nope. Just before sending this e-mail I tried Ctrl+click: bingo! Much better, but gnome-shell either needs to hint at this behaviour, or it needs to provide the old simple clickable icon in panel. For someone who religously starts and stops terminals for separate tasks (actually for starting applications generally) the old panel is more efficient: one click without anything else. 2. Could make it easier for users to test People have their common apps in their panel. Can they be imported? I'm not allowed to drag and drop them, the panels is gone! This would save the frustration of adding apps there. 3. Window behaviour I really like the way the windows are spaced apart in the app switcher view, and the way new virtual desktops can be added and deleted. If a specific desktop could be removed rather than the last, I would have no suggestions here, other than to let desktops be movable to change their order. 4. Probable bugs I need to be able to see the date: please use my date format at the top of the screen. Volume control needs to expand like under metacity. nd ___ 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
Thoughtful feedback
Friends-- I've been using gnome-shell for a couple months now (and computers for almost 30 years) and there are a couple things I hope you adjust as you go along. First of all I am a generalizing thinker. It occurs to me that the Activities overlay is like nothing so much as the XP Start Menu. It has all the same components. We have reinvented the wheel, and Lo! It is round! Research says there are four main personality types / learning styles. How about optimizing the shell for different thinking styles? You already have Search, and a Recently Used space for both apps and files. That covers people who think a couple different ways. But be careful, please, as you whittle down non-essentials, not to take away the best parts of Linux. Don't let user-friendliness become a creeping fog that hides the transparency we love. If Windows and Mac are like black boxes, Linux is kind of like a grandfather clock where you can see the gears. My solution? From my point of view what I use most (on any OS I'm on at the moment) is the Tree sidebar in the file browser. I like to organize my thoughts in files and directories. How about, instead of just trying to make the best window manager possible, you combine functionalities with the file browser? When the overlay comes up it should have the functionality of the Nautilus sidebar, give or take. That means if I want a tree menu, or a semitransparent icon overlay inside a directory, that's an option. I know, that's been the default since Windows 3. Is that a bad thing? There you have it, kind of. Different navigation styles for different folks. Search, file types (which at this point is your App menu), history, and logical organization. I really like the new shell. I find myself hunting for that hot corner (and being disappointed) when I'm at work or the college on a borrowed Windows box. Besides, I don't know how to uninstall it :D It's kind of Wii-like. That's a good direction, IMHO. I wouldn't mind more icons (as an option), like a phone. If I could make a Christmas wish for a couple more things it'd be that I hope you guys are working on making the overlay skinnable (e.g. CSS) and that you're focusing on whittling down the number of clicks or mouseovers it takes to begin a given task. Hope that's an encouragement, Cool runnings, Coby ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
