Re: Extension/Preferences shared variables

[Vadim <vadim dbfin com>]

This is no secret. I just did not want to pollute the list with all the details.

Right now my extension leaves some messages in a file that it creates. Those messages are organized hierarchically and help me to understand if something goes wrong. What I wanted instead is to direct those messages (on demand) to a window/widget, and I thought that a widget in a preferences dialog would be a perfect place for that.

Now I am thinking about creating a Gtk+ window in the extension process itself.

Vadim.

On 04/11/2013 02:05 PM, Jasper St. Pierre wrote:

We might be able to give you some ideas if you told us more about your situation.

On Thu, Apr 11, 2013 at 3:04 PM, Vadim <vadim dbfin com> wrote:

Sorry, I meant to write "no" instead of "know". Anyway, it seems to me that you are right about DBus: this is just too "heavy". I will try to think differently and implement a different approach.

Vadim.

On 04/11/2013 02:00 PM, Jasper St. Pierre wrote:

No. They are in separate processes. You can set up some form of communication using DBus if you want, but it's not recommended.

On Thu, Apr 11, 2013 at 2:51 PM, Vadim <vadim dbfin com> wrote:

It's not that it needs to know about it. The preferences are mainly intended to be specified through Gtk+ widgets. And there is even explicit requirement to return a Gtk+ widget in prefs.js. But as far as I understand now, there is know other connection between the running extension and Gtk+ preferences dialog except for GSettings. Am I right?

Vadim.

On 04/11/2013 07:42 AM, Jasper St. Pierre wrote:

GNOME Shell is not built with GTK+. Why does GNOME Shell need to know about a GTK+ widget?

On Thu, Apr 11, 2013 at 1:41 AM, Vadim <vadim dbfin com> wrote:

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 <vadim 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

--
  Jasper

--
  Jasper

--
  Jasper