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 and
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
Accessing an extension's namespace in the looking glass
In Gnome Shell 3.6, is there a way to access the namespace and imports of an extension from the looking glass? For example, to be able to manually call a function defined in an extension? Or say in an extension you have this line: const Convenience = ExtensionUtils.getCurrentExtension().imports.convenience; How would I access the functions in Convenience from the looking glass? — Jason ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: How do I use global.display.add_keybinding?
Sorry to dredge this up again, but it seems that captured-event is
only fired when there's some part of the shell active eg. it seems to
fire when the overview is up, or when switching applications, or when
typing in the looking glass; but it doesn't fire the rest of the time.
Is there a way to set up a keybinding for eg. Alt or Ctrl, that will
fire at *any* time?
— Jason
On 11 February 2013 12:31, Jason Heeris jason.hee...@gmail.com wrote:
Thanks, that seems to work. I would have thought the
'key-{press|release}-events' would work too, and be a bit more
specific, but they seem to only fire when the overview is up. Why is
that?
- Jason
On 10 February 2013 20:31, Amy mathematical.cof...@gmail.com wrote:
I suspect that since 'Alt' on its own is not a valid keybinding for meta you
might be able to just listen to the 'captured-event' signal on the global
stage, and detect a keypress event with Alt. This would lose you mutter's
inbuilt ability to parse the keybindings from the string in gsettings though
(you'd have to parse the string yourself and match it in the captured-event
signal as opposed to a convenient global.display.add_keybinding).
On 10 February 2013 16:14, Jason Heeris jason.hee...@gmail.com wrote:
I've successfully set up a hello world style extension that responds
to a keybinding, thanks in part to the docs posted here, and also to
some code I found in the brightness control extension[1].
I can create a GSettings schema that has a default key for my
extension to bind, like so:
key type=as name=showhw
default
![CDATA[['Altx']]]
/default
summary
The keyboard shortcut to show Hello World
/summary
/key
That works fine. But if I change Altx to just Alt, I get the
following message in .xsession-errors:
Window manager warning: Alt found in configuration database is
not a valid value for keybinding showhw
Binding to Alt might be intrusive if unexpected, but if a user wanted
such a thing, how would it be possible?
(I can't really search the web for this, since it's a very common
error message for users to see.)
— Jason
[1]
http://gitorious.org/gnome-shell-brightness-extension/gnome-shell-brightness-extension/trees/master/brightness_cont...@lmedinas.org
On 5 February 2013 10:58, Amy mathematical.cof...@gmail.com wrote:
On 5 February 2013 09:02, Jason Heeris jason.hee...@gmail.com wrote:
Alan Knowles - Thanks for that, it looks very useful.
On 3 February 2013 21:33, Jasper St. Pierre jstpie...@mecheye.net
wrote:
You can find some (albiet limited) documentation for the Shell
toolkit
here:
http://developer.gnome.org/shell/unstable/
I notice that the docs for ShellGlobal don't specify any signals or
properties - is that by design (as in, they shouldn't be used) or is
it an accidental omission?
I don't think ShellGlobal has any signals which is why they're not
specified.
Most the signals are attached to objects *in* ShellGlobal. For example,
`global.display` is a `Meta.Display` so you have to check out the Mutter
documentation for what signals it has.
As to why the properties are not specified, I'm not sure - perhaps
you're
meant to use `global.get_display()` rather than `global.display` etc??
(BTW, you can do
g-ir-doc-tool /usr/lib/mutter/Meta-3.0.gir -o /path/to/some/folder
to generate the documentation for mutter in that folder. Then do
yelp /path/to/that/folder
to look at it in a help browser.
If it complains Couldn't find include 'XYZ.gir', then you have to
generate
that gir via
g-ir-generate /usr/lib/girepository-1.0/XYZ.typelib
/usr/share/gir-1.0/XYZ.gir
before running g-ir-doc-tool on Meta-3.0.gir again. At some point I had
a
plan to generate the documentation and put it somewhere online for
convenience until the new documentation system is up and running, but
I
guess I forgot about it...
Unfortunately g-ir-doc-tool seems to crash when I try to do the same on
Shell-0.1.gir.)
Note that there is currently work on a new documentation system that
can
generate native JS documentation instead of C
I eagerly await such a thing :)
- Jason
___
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
