Re: Gjs DBus bindings questions (introspection, method names and callbacks)

[Giovanni Campagna]

2013/2/25 Jason Heeris :
> I'm trying to figure out how to use DBus from my Gnome Shell
> extension. I have the option of using the GLib DBus interface, but
> then I saw that there's actual Gjs DBus bindings! The Gnome Live Gjs
> page only has a link to here:
>
> http://erick2red.github.com/blog/2011/05/28/dbus-in-gjs-and-gnome-shell/
>
> ...but I still have a few questions:
>
> 1. That page doesn't mention introspection - is it supported? Can I
> get away with not explicitly specifying the signatures on the
> interfaces I want to use?
>
> 2. The method called Notify in the interface definition becomes
> NotifyRemote when it's called. Why is that?
>
> 3. How do the callbacks work - is it a single function with two
> parameters: 'result' and 'error'? Can I instead use two separate
> callbacks? Is 'result' undefined if there's an error, or is it
> something else (ie. how do I test for success)?
>
> 4. Can I make blocking calls instead?
>
> 5. Can I connect to signals?

Hello!
Unfortunately, that page is significantly outdated, and still mentions
the dbus-glib based bindings, which are obsolete since 3.4 and were
removed in 3.8. The modern bindings are offered as a set of overrides
over the GDBus introspected API.
A simple example is:

const Gio = imports.gi.Gio;

const MyIface = 

;
const MyProxy = Gio.DBusProxy.makeProxyClass(MyIface);

let instance = new MyProxy(Gio.DBus.session, 'org.example.BusName',
'/org/example/Path');

Introspection is needed, in E4X or string format. If you don't want
that, you can use a raw Gio.DBusProxy.
The constructor is synchrnous, but you can add an optional callback
with the same conventions as method calls to get the async variant.
Note that constructing a proxy will cause DBus activation to occur.
Method names are exported as Method + "Remote" for the async variant
and Method + "Sync" for the sync variant. They take a variable number
of arguments (depending on the number of actual arguments of the DBus
interface), plus optionally a Gio.Cancellable and Gio.DBusCallFlags.
The aync version takes a callback with two arguments, result and
error. If successful, result contains the out arguments from the DBus
call, as an array, and error is null. If the remote call fails, result
will be null and error will be a GLib.Error. You can use Gio.DBusError
methods to extract the DBus error name from it.
The sync version takes no callback, but returns the result tuple
directly, or throws an exception in case of errors.
You connect to signals with .connectSignal('...', function(proxy,
sender, parameters) { }) and disconnect with disconnectSignals(id);
Note that disconnecting from signals will not remove the AddMatch
rule, you must run_dispose() the proxy for that.
Properties work as getter and setters, and are cached in the
constructor. Errors from setting are ignore. Connect to
'g-properties-changed' GObject signal to receive notification of
changes.

A full example (including the server side version) is in the gjs tree,
as test/js/testGDBus.js

And naturally, if you want to help documenting it better, you're very welcome!

Giovanni
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list

Gjs DBus bindings questions (introspection, method names and callbacks)

[Jason Heeris]

I'm trying to figure out how to use DBus from my Gnome Shell
extension. I have the option of using the GLib DBus interface, but
then I saw that there's actual Gjs DBus bindings! The Gnome Live Gjs
page only has a link to here:

http://erick2red.github.com/blog/2011/05/28/dbus-in-gjs-and-gnome-shell/

...but I still have a few questions:

1. That page doesn't mention introspection - is it supported? Can I
get away with not explicitly specifying the signatures on the
interfaces I want to use?

2. The method called Notify in the interface definition becomes
NotifyRemote when it's called. Why is that?

3. How do the callbacks work - is it a single function with two
parameters: 'result' and 'error'? Can I instead use two separate
callbacks? Is 'result' undefined if there's an error, or is it
something else (ie. how do I test for success)?

4. Can I make blocking calls instead?

5. Can I connect to signals?

Cheers,
Jason
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: AppMenu design feedback

[Adam Tauno Williams]

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

[Donato Marrazzo]

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