dash position
Hello, I'd like to put the dash on the other side of screen (because I have another monitor and I don't want it to be in the middle of screen) Is there a way to do that ? Thanks, -- Bastien Durel ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: dash position
Heya, So if you open Displays it will show your two monitors. Drag the black shell bar to the left monitor and the dash will open on the far left from then on. Hope that helps, Nick On 10 Apr 2013 10:50, Bastien Durel bast...@geekwu.org wrote: Hello, I'd like to put the dash on the other side of screen (because I have another monitor and I don't want it to be in the middle of screen) Is there a way to do that ? Thanks, -- Bastien Durel ___ 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: How to get Empathy to always popup msgs
On Mon, 2013-04-08 at 07:53 +, Gabriel Rossetti wrote: so nobody know how to do this? Does this need an extension too? I'm not aware of how to do this [but I'm on GNOME 3.6; I know that 3.8 changes a bunch of notification related stuff]. Generally notifications in GNOME-Shell [at least up to and including 3.6] are *LAME* bordering on useless. Otherwise GNOME-Shell / GNOME3 is great - but the notifications scheme - ARGHHH! If you find a setting / tweak please post back, I'd love to see it. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: How to get Empathy to always popup msgs
On Apr 10, 2013 1:45 PM, Adam Tauno Williams awill...@whitemice.org wrote: On Mon, 2013-04-08 at 07:53 +, Gabriel Rossetti wrote: so nobody know how to do this? Does this need an extension too? I'm not aware of how to do this [but I'm on GNOME 3.6; I know that 3.8 changes a bunch of notification related stuff]. Generally notifications in GNOME-Shell [at least up to and including 3.6] are *LAME* bordering on useless. Otherwise GNOME-Shell / GNOME3 is great - but the notifications scheme - ARGHHH! If you find a setting / tweak please post back, I'd love to see it. Agreed, I eventually gave up, removed all empathy accounts, disabled notifications and installed pidgin as it allows this. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Technical and security implications of using gnome-shell on KMS+evdev
Hello, fellow gnome-shell developers, in the past few weeks I saw that we started laying the plans for gradually moving gnome-shell to wayland, and it's my understanding, based on some wiki pages, that we want to run it straight on KMS/DRM + evdev. I would like to call out for the potential security implications of doing this, in particular on the evdev side: having an open handle to an event char device, however obtained, allows to see all input events in the system, including those from other sessions and virtual terminals. Currently weston handles this by simply refusing to pull events when on a different virtual terminal, but this solution is not acceptable for gnome-shell: we allow running arbitrary code from a variety of places, such as DBus and extensions, so it would be easy for a logged in attacker to keep logging events after the vt switch. On the KMS/DRM side, the risk is not calling drmDropMaster after the switch, thus keeping privileges that are enough to acquire the full content of the screen from a different session. Again, weston solves this assuming that the right message is sent to weston-launch, thus relying on an unprivileged and untrusted process. The simple solution to both these problems is to have a system compositor running as root, which takes care to send events and accept buffers from the appropriate session only. My idea is that this system daemon would implement a small subset of the wayland API, enough to deliver events, monitor configuration and to accept fullscreen buffers ready for scanout. There would be another advantage of using a system compositor, and that brings us to the second part of my email: the relationship between GDK and Clutter in the mutter process. I can't find it right now, but I understood that, given gdk has no KMS+evdev backend, it will keep using the X11 backend with xwayland. This is of course hackish, with multiple steps that reinterpret events. Having a system compositor that talks wayland on the other hand would allow to make gdk the bottommost abstraction layer. Clutter would use the gdk backend, and mutter would learn to get events from gdk, by creating foreign windows in the X11 case, and client-side windows when running as a wayland server. Alternatively, we can remove the gdk/gtk+ dependency completely. For the record, mutter uses gtk+ for the following features: - event retrieval - need to split the X11 parts (propertynotify, selectionnotify, configurerequest, etc.) from actual events, and then we can pull the latter from Clutter - tab/workspace popups - not needed in gnome-shell, I'm ok if we say users of libmutter have to reimplement them - resize popups - should be easy to reimplement in clutter - clipboard (in gnome-shell) - would not work anyway, needs a wayland clipboard implementation in mutter - input methods (in gnome-shell) - would not work anyway - window decorations and menus - this is the hard part, as a clutter/st reimplementation will probably regress them, and it's a lot of code anyway - xsettings and icon theme (in gnome-shell) - again, this is hard to do without Personally, I'm not yet convinced on which way can be the best, but I hope this can be the start of a productive discussion. Giovanni ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: How to get Empathy to always popup msgs
I've never heard you express frustrations before about notifications. Do you have any specific issues with them? On Wed, Apr 10, 2013 at 7:44 AM, Adam Tauno Williams awill...@whitemice.org wrote: On Mon, 2013-04-08 at 07:53 +, Gabriel Rossetti wrote: so nobody know how to do this? Does this need an extension too? I'm not aware of how to do this [but I'm on GNOME 3.6; I know that 3.8 changes a bunch of notification related stuff]. Generally notifications in GNOME-Shell [at least up to and including 3.6] are *LAME* bordering on useless. Otherwise GNOME-Shell / GNOME3 is great - but the notifications scheme - ARGHHH! If you find a setting / tweak please post back, I'd love to see it. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list -- Jasper ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
RE: How to get Empathy to always popup msgs
You are correct, I have never directly voiced miscontempt with the notification system. I didn't do so since other have but maybe I should have. The biggest issue I have is the fact that I have no way of knowing a notification came and went, I have to activate activities or try to get the notification bar to come up when I want it to and not come up when I don't want it to. I eventually installed an extension to deactivate the notification bar from popping up since I activated it too much by mistake and it gets annoying. It gets worst for non-tecky users, I have had to deactivate it for them since they just don't understand what is going on when the move the mouse by mistake and activate it, they say their screen is frozen. If someone writes me a msg on empathy and I am not there to see the notification, I have no clue someone wrote to me, I have often missed important msgs because of this since they are hidden away. It gets even worst for non-supported ones like Skype. If you look at android for example, just by looking at the screen I know I have received emails, chat msgs, etc; if I want more info I can quickly get that. In GS I have to click/move my mouse/kit a key (being proactive) to know I have a notification, which makes them useless IMO since they don't notify my of anything (unless I see the notification popup, I find those to be too distracting and intrusive). Cheers, Gabriel From: gnome-shell-list [gnome-shell-list-boun...@gnome.org] on behalf of Jasper St. Pierre [jstpie...@mecheye.net] Sent: Wednesday, April 10, 2013 17:37 To: Adam Williams Cc: gnome-shell-list Subject: Re: How to get Empathy to always popup msgs I've never heard you express frustrations before about notifications. Do you have any specific issues with them? On Wed, Apr 10, 2013 at 7:44 AM, Adam Tauno Williams awill...@whitemice.orgmailto:awill...@whitemice.org wrote: On Mon, 2013-04-08 at 07:53 +, Gabriel Rossetti wrote: so nobody know how to do this? Does this need an extension too? I'm not aware of how to do this [but I'm on GNOME 3.6; I know that 3.8 changes a bunch of notification related stuff]. Generally notifications in GNOME-Shell [at least up to and including 3.6] are *LAME* bordering on useless. Otherwise GNOME-Shell / GNOME3 is great - but the notifications scheme - ARGHHH! If you find a setting / tweak please post back, I'd love to see it. ___ gnome-shell-list mailing list gnome-shell-list@gnome.orgmailto:gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list -- Jasper 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: How to get Empathy to always popup msgs
In GNOME 3.8, the notifications bar trigger has been much improved, and it shouldn't pop up nearly so often, so look forward to that. In the case of notifications hiding, that should not be happening. When you are idle for more than three seconds or so, notifications should stay open and never close. On Wed, Apr 10, 2013 at 12:01 PM, Gabriel Rossetti gabriel.rosse...@trafigura.com wrote: You are correct, I have never directly voiced miscontempt with the notification system. I didn't do so since other have but maybe I should have. The biggest issue I have is the fact that I have no way of knowing a notification came and went, I have to activate activities or try to get the notification bar to come up when I want it to and not come up when I don't want it to. I eventually installed an extension to deactivate the notification bar from popping up since I activated it too much by mistake and it gets annoying. It gets worst for non-tecky users, I have had to deactivate it for them since they just don't understand what is going on when the move the mouse by mistake and activate it, they say their screen is frozen. If someone writes me a msg on empathy and I am not there to see the notification, I have no clue someone wrote to me, I have often missed important msgs because of this since they are hidden away. It gets even worst for non-supported ones like Skype. If you look at android for example, just by looking at the screen I know I have received emails, chat msgs, etc; if I want more info I can quickly get that. In GS I have to click/move my mouse/kit a key (being proactive) to know I have a notification, which makes them useless IMO since they don't notify my of anything (unless I see the notification popup, I find those to be too distracting and intrusive). Cheers, Gabriel From: gnome-shell-list [gnome-shell-list-boun...@gnome.org] on behalf of Jasper St. Pierre [jstpie...@mecheye.net] Sent: Wednesday, April 10, 2013 17:37 To: Adam Williams Cc: gnome-shell-list Subject: Re: How to get Empathy to always popup msgs I've never heard you express frustrations before about notifications. Do you have any specific issues with them? On Wed, Apr 10, 2013 at 7:44 AM, Adam Tauno Williams awill...@whitemice.orgmailto:awill...@whitemice.org wrote: On Mon, 2013-04-08 at 07:53 +, Gabriel Rossetti wrote: so nobody know how to do this? Does this need an extension too? I'm not aware of how to do this [but I'm on GNOME 3.6; I know that 3.8 changes a bunch of notification related stuff]. Generally notifications in GNOME-Shell [at least up to and including 3.6] are *LAME* bordering on useless. Otherwise GNOME-Shell / GNOME3 is great - but the notifications scheme - ARGHHH! If you find a setting / tweak please post back, I'd love to see it. ___ gnome-shell-list mailing list gnome-shell-list@gnome.orgmailto:gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list -- Jasper 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. -- Jasper ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: How to get Empathy to always popup msgs
On Wed, 2013-04-10 at 16:01 +, Gabriel Rossetti wrote: If someone writes me a msg on empathy and I am not there to see the notification, I have no clue someone wrote to me I can confirm on my system, on 3.6, notifications do not disappear until you interact with the system. That is, notifications will remain until I return and am not idle. In GS I have to click/move my mouse/kit a key (being proactive) to know I have a notification I've not had to do this since updating to 3.6, I'm quite happy with the new implementation. 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: How to get Empathy to always popup msgs
On Wed, Apr 10, 2013 at 1:01 PM, Gabriel Rossetti gabriel.rosse...@trafigura.com wrote: You are correct, I have never directly voiced miscontempt with the notification system. I didn't do so since other have but maybe I should have. The biggest issue I have is the fact that I have no way of knowing a notification came and went, I have to activate activities or try to get the notification bar to come up when I want it to and not come up when I don't want it to. I eventually installed an extension to deactivate the notification bar from popping up since I activated it too much by mistake and it gets annoying. It gets worst for non-tecky users, I have had to deactivate it for them since they just don't understand what is going on when the move the mouse by mistake and activate it, they say their screen is frozen. If someone writes me a msg on empathy and I am not there to see the notification, I have no clue someone wrote to me, I have often missed important msgs because of this since they are hidden away. It gets even worst for non-supported ones like Skype. If you look at android for example, just by looking at the screen I know I have received emails, chat msgs, etc; if I want more info I can quickly get that. In GS I have to click/move my mouse/kit a key (being proactive) to know I have a notification, which makes them useless IMO since they don't notify my of anything (unless I see the notification popup, I find those to be too distracting and intrusive). I created this extension [1] exactly to solve this issue. When I used gnome-shell for the first time (gnome 3.2) I loved it, but I was always missing chat notifications. The extension is very simple! It'll blink the message on the user menu every time there's a notification that needs your attention. It's very generic, so it will work with any kind of notifications (empathy, skype, any notify-send notification, etc). It'll ignore resident notifications (like rhythmbox ones) to avoid false positives and etc. So, if it's blinking, for sure there's a notification requesting your attention. It has some preferences to only alert about chat notifications or alert even if the notifications are set to off (that is, you can turn OFF the notifications on the user menu to avoid the popup, but you will still know when there's a new notification). The color and the blink rate are too configurable. If you try it, let me know if it solves your problem :) [1] https://extensions.gnome.org/extension/258/notifications-alert-on-user-menu/ Cheers, -- Thiago Bellini Ribeiro | http://hackedbellini.org “Real knowledge is to know the extent of one's ignorance.” - Confucius ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Technical and security implications of using gnome-shell on KMS+evdev
On Wed, Apr 10, 2013 at 9:36 AM, Giovanni Campagna scampa.giova...@gmail.com wrote: Hello, fellow gnome-shell developers, Hi Giovanni, in the past few weeks I saw that we started laying the plans for gradually moving gnome-shell to wayland, and it's my understanding, based on some wiki pages, that we want to run it straight on KMS/DRM + evdev. We have had two meetings with krh so far about the technical details of Wayland on GNOME -- one a few weeks ago, and a follow-up meeting yesterday. We talked briefly about this sort of stuff, but glad to see you have a take on it. I would like to call out for the potential security implications of doing this, in particular on the evdev side: having an open handle to an event char device, however obtained, allows to see all input events in the system, including those from other sessions and virtual terminals. Currently weston handles this by simply refusing to pull events when on a different virtual terminal, but this solution is not acceptable for gnome-shell: we allow running arbitrary code from a variety of places, such as DBus and extensions, so it would be easy for a logged in attacker to keep logging events after the vt switch. On the KMS/DRM side, the risk is not calling drmDropMaster after the switch, thus keeping privileges that are enough to acquire the full content of the screen from a different session. Again, weston solves this assuming that the right message is sent to weston-launch, thus relying on an unprivileged and untrusted process. The simple solution to both these problems is to have a system compositor running as root, which takes care to send events and accept buffers from the appropriate session only. My idea is that this system daemon would implement a small subset of the wayland API, enough to deliver events, monitor configuration and to accept fullscreen buffers ready for scanout. Part of the new Wayland work with having Weston directly control KMS would be that Weston would also be able to use special hardware overlays, like supported YUV overlays and and the hardware cursor for acceptable surfaces. The system compositor approach would mean that the system compositor would be involved in setting those surfaces, and that means that there's one or two approaches: * The smarts are kept in mutter, and a protocol is developed to discover and set hardware overlays to specific buffers. This is not insurmountable, but we'd need to keep it flexible to prevent changing it when new hardware with new buffer formats come out. * The smarts are in the system compositor, and a protocol is developed to relay the scene graph to the system compositor. It would use this scene graph information not to composite buffers itself, but simply to pick buffers to use for the overlay, and relay that information back to the system compositor so it can remove it from its buffers. There would be another advantage of using a system compositor, and that brings us to the second part of my email: the relationship between GDK and Clutter in the mutter process. I can't find it right now, but I understood that, given gdk has no KMS+evdev backend, it will keep using the X11 backend with xwayland. This is of course hackish, with multiple steps that reinterpret events. Hm, I didn't think of this. Having a system compositor that talks wayland on the other hand would allow to make gdk the bottommost abstraction layer. Clutter would use the gdk backend, and mutter would learn to get events from gdk, by creating foreign windows in the X11 case, and client-side windows when running as a wayland server. Alternatively, we can remove the gdk/gtk+ dependency completely. For the record, mutter uses gtk+ for the following features: - event retrieval - need to split the X11 parts (propertynotify, selectionnotify, configurerequest, etc.) from actual events, and then we can pull the latter from Clutter - tab/workspace popups - not needed in gnome-shell, I'm ok if we say users of libmutter have to reimplement them I believe it's used right now for Alt+Esc because we haven't bothered implementing a replacement, but yeah, I'm fine with removing all this code. - resize popups - should be easy to reimplement in clutter Well, yeah. - clipboard (in gnome-shell) - would not work anyway, needs a wayland clipboard implementation in mutter - input methods (in gnome-shell) - would not work anyway IM in Wayland is still an open problem. We discussed this at length, and I'm not sure if we came to a clear resolution on whether doing it in the client or compositor is better, but I was a fan of the compositor approach where key events are sent to an IM through some protocol, and then the IM does everything it needs to and eventually sends the client a text event. - window decorations and menus - this is the hard part, as a clutter/st reimplementation will probably regress them, and it's a lot of code anyway So, native wayland
Re: Technical and security implications of using gnome-shell on KMS+evdev
Hi Giovanni - As a general consideration, we need to be do move Wayland incrementally. For 3.10, we want to be able to run GNOME either using X or Wayland. We want people to be able to work on a Wayland-ized GNOME on existing systems. This is one reason I'm not convinced about depending on a system compositor - fundamentally changing the way that virtual terminals and sessions work on the system is not compatible with people developing new versions of GNOME on existing distributions, and being able to log in either to X or to Wayland. The other reason is that a system compositor, especially one that is forwarding events, inevitably involves more context switches, more opportunities for latency. The primary use case for user-switching and multiple sessions is family members, and we shouldn't go overboard in engineering it to make it ultra-secure. There are some considerable limits to the amount of security that can be provided on a single system. Leaving aside things like timing attacks that are present simply by sharing a CPU, consider the following scenario: - I walk up to a computer, someone else is logged in - I go to their user menu, and select Switch User - I get switch to the login screen, I try to log in - On the first attempt, I mistype my password and get an error - The second attempt works and I log into my session What really happened was that the session was trojaned to show a simulation of GDM the first time, steal my password, and *then* switch to GDM. A system compositor and secure key combinations can help prevent this type of attack, but only the most security-aware users will benefit. It may still be interesting to explore a system compositor long-term, but I'd rather we get things going first, incrementally, and had something to benchmark against and compare security against. There are some things we can do short-term to make things better - one thing that Kristian suggested is that evdev could easily have a 'mute' ioctl that would allow a privileged process - whether that's logind or something dedicated - to control which users see events. In terms of the dependency of Mutter on GTK+ - I really don't think we have an immediate problem there. We need support X apps indefinitely, so Mutter needs to continue acting as a window manager, needs to continue linking to Xlib. So we can simply use the X backend for GTK+ What we would need to do upfront is change the primary event path, so events could go: evdev = Mutter = Clutter Mutter = Native wayland application Mutter = XWayland = X application = Mutter = GTK+ So most events would *not* do a round-trip loop through the X server, just events on a GTK+-implemented menu or other UI like that. Over time we could then reduce our dependency on GTK+ by using native Clutter UI for menus, reading settings directly from GSettings and so forth, and eventually we could perhaps avoid connecting to X at all until we had a native client to manage, but I don't really see a reason to do this upfront. Do you see a problem with continuing to use the GTK+ version of X in the short-term? - Owen ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
No keyboard shortcuts in activity view
Hi! I just realized that in gnome3, when I press the command key, i cannot use the arrow keys to choose an active application (As in it has to be the mouse). Is that bit on purpose? Thanks! Dhaval ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Extension/Preferences shared variables
Hi everyone, I was wondering if there is a common way to share a variable between an extension and the preferences dialog. Let say, I want to set some global.variable within the preferences dialog (temporary until it is closed), and the running extension should react on this, i.e. it should see that the variable was set. Thanks in advance, Vadim ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Get current key modifiers
Thanks, man! This works perfectly! Vadim. On 03/29/2013 03:23 PM, Rui Tiago Cação Matos wrote: On 29 March 2013 19:47, Vadim va...@dbfin.com wrote: It seems as an easy question, but cannot find the answer: how do you get in Gjs (writing an extension) all the currently pressed/set key modifiers (such as Ctrl, Shift keys and/or Caps-Lock etc.)? I know how you get this in an event, but need to get it just in a method. For gnome-shell you can do it like that: https://git.gnome.org/browse/gnome-shell/tree/js/ui/switcherPopup.js#n153 Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: No keyboard shortcuts in activity view
Not quite an answer, but you might be interested in the Window Navigator extension: https://extensions.gnome.org/extension/10/windownavigator/ It lets you select windows from the overlay using Alt+[Num]. — Jason On 11 April 2013 06:31, Dhaval Giani dhaval.gi...@gmail.com wrote: Hi! I just realized that in gnome3, when I press the command key, i cannot use the arrow keys to choose an active application (As in it has to be the mouse). Is that bit on purpose? Thanks! Dhaval ___ 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: Extension/Preferences shared variables
Hi Vadim,
Could you just use gsettings (i.e. the same thing that you use with
`prefs.js` to store extension settings) for this?
In the `prefs.js` your widget does a:
let settings = Convenience.getSettings();
settings.set_int('my-setting-name', 1);
and in the extension you connect to the change:
// in your init() say
let settings = Convenience.getSettings();
// in your enable() say
settings.connect('changed::my-setting-name', callback)
So `callback` is called whenever a user changes the setting in the prefs
widget.
(Here Convenience.getSettings is the one from the official gnome shell
extensions -
https://git.gnome.org/browse/gnome-shell-extensions/tree/lib/convenience.js)
On 11 April 2013 08:38, Vadim va...@dbfin.com wrote:
Hi everyone,
I was wondering if there is a common way to share a variable between an
extension and the preferences dialog.
Let say, I want to set some global.variable within the preferences
dialog (temporary until it is closed), and the running extension should
react on this, i.e. it should see that the variable was set.
Thanks in advance,
Vadim
___
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: No keyboard shortcuts in activity view
On Wed, Apr 10, 2013 at 7:21 PM, Jason Heeris jason.hee...@gmail.comwrote: Not quite an answer, but you might be interested in the Window Navigator extension: https://extensions.gnome.org/extension/10/windownavigator/ It lets you select windows from the overlay using Alt+[Num]. Thanks for the pointer So am I right in assuming that this was intentionally done? Thanks! Dhaval ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: No keyboard shortcuts in activity view
No, it's because it's a fairly difficult problem, and nobody has tried to fix it. I'm hoping to land this for 3.10 as a feature. On Wed, Apr 10, 2013 at 10:56 PM, Dhaval Giani dhaval.gi...@gmail.comwrote: On Wed, Apr 10, 2013 at 7:21 PM, Jason Heeris jason.hee...@gmail.comwrote: Not quite an answer, but you might be interested in the Window Navigator extension: https://extensions.gnome.org/extension/10/windownavigator/ It lets you select windows from the overlay using Alt+[Num]. Thanks for the pointer So am I right in assuming that this was intentionally done? Thanks! Dhaval ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list -- Jasper ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extension/Preferences shared variables
Yes, I know about GSettings and use them a lot to store static options.
Thanks a lot in any case.
Here I wanted to store a reference to a gtkWidget that is created in the
preferences dialog.
The way I wanted to do is: gtkWidget is created in pref.js, a global
variable is used to reference the widget, and the extension knows that
the widget is created and directs some output there.
One way I was thinking about before was to direct output to a GSettings
key and react on this change in prefs.js, but that is not efficient.
Another way was to direct output to a file, and read the file in
prefs.js. I do not like either solution.
For me the best deal would be to share some variable space between both
extension and prefs.js, but as far as I know they are in different
processes.
Any other ideas?
Thanks again,
Vadim.
On 04/10/2013 06:55 PM, Amy wrote:
Hi Vadim,
Could you just use gsettings (i.e. the same thing that you use with
`prefs.js` to store extension settings) for this?
In the `prefs.js` your widget does a:
let settings = Convenience.getSettings();
settings.set_int('my-setting-name', 1);
and in the extension you connect to the change:
// in your init() say
let settings = Convenience.getSettings();
// in your enable() say
settings.connect('changed::my-setting-name', callback)
So `callback` is called whenever a user changes the setting in the
prefs widget.
(Here Convenience.getSettings is the one from the official gnome shell
extensions
- https://git.gnome.org/browse/gnome-shell-extensions/tree/lib/convenience.js)
On 11 April 2013 08:38, Vadim va...@dbfin.com
mailto:va...@dbfin.com wrote:
Hi everyone,
I was wondering if there is a common way to share a variable
between an
extension and the preferences dialog.
Let say, I want to set some global.variable within the preferences
dialog (temporary until it is closed), and the running extension
should
react on this, i.e. it should see that the variable was set.
Thanks in advance,
Vadim
___
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
