After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 669349 - Adapt to GDBus API changes
Adapt to GDBus API changes
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on: 669350
Blocks:
 
 
Reported: 2012-02-03 22:39 UTC by Jasper St. Pierre (not reading bugmail)
Modified: 2019-02-27 17:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Adapt to GDBus API changes (36.66 KB, patch)
2012-02-03 22:39 UTC, Jasper St. Pierre (not reading bugmail)
reviewed Details | Review

Description Jasper St. Pierre (not reading bugmail) 2012-02-03 22:39:29 UTC
OK, so we're going to be landing a bunch of new GJS stuff pretty soon,
including gobject-inheritance as well as a ton of other things.

While I'm not going to be doing any heavy porting, Giovanni once again
decided to break the GDBus methods, which is nice, because it actually
provides a neat API this time. Unfortunately, it still requires porting.

"See patch."
Comment 1 Jasper St. Pierre (not reading bugmail) 2012-02-03 22:39:31 UTC
Created attachment 206735 [details] [review]
Adapt to GDBus API changes
Comment 2 Jasper St. Pierre (not reading bugmail) 2012-02-03 22:41:00 UTC
Of note, having this ACN and ready to commit would be a nice thing to have so we don't have a broken Shell for a while.
Comment 3 Jasper St. Pierre (not reading bugmail) 2012-02-03 22:52:57 UTC
OK, I decided to land the big branch without the GDBus changes, so I filed a new bug for those. Dep'ing.
Comment 4 Giovanni Campagna 2012-02-06 19:09:04 UTC
Review of attachment 206735 [details] [review]:

It's a shame that you duplicated this work, just because I didn't push it somewhere public...
In any case, should be fine. Not tested though, because it depends on the extension prefs bug.

::: js/misc/consoleKit.js
@@ +45,3 @@
+        this.connect('notify::g-name-owner', Lang.bind(this, this._onGNameOwnerChanged));
+        this._onGNameOwnerChanged();
+        this.parent.apply(this, arguments);

I think this needs be called first, otherwise the first this.connect will fail because there is no GObject yet.

::: js/misc/screenSaver.js
@@ +28,2 @@
+    _init: function() {
+        this.parent();

I'd keep params here, even if unused, just to keep the convention.

::: js/ui/endSessionDialog.js
@@ +333,3 @@
                                       }));
 
+        this._dbusImpl = new EndSessionDialogImpl(this);

Not exactly the nicest way to use the new API, but yeah, it should work.
Comment 5 Jasper St. Pierre (not reading bugmail) 2012-02-06 19:26:56 UTC
(In reply to comment #4)
> Review of attachment 206735 [details] [review]:
> 
> It's a shame that you duplicated this work, just because I didn't push it
> somewhere public...

How can I contact you in this case?

> In any case, should be fine. Not tested though, because it depends on the
> extension prefs bug.
> 
> ::: js/misc/consoleKit.js
> @@ +45,3 @@
> +        this.connect('notify::g-name-owner', Lang.bind(this,
> this._onGNameOwnerChanged));
> +        this._onGNameOwnerChanged();
> +        this.parent.apply(this, arguments);
> 
> I think this needs be called first, otherwise the first this.connect will fail
> because there is no GObject yet.

Fixed locally.

> ::: js/misc/screenSaver.js
> @@ +28,2 @@
> +    _init: function() {
> +        this.parent();
> 
> I'd keep params here, even if unused, just to keep the convention.

What convention?

> ::: js/ui/endSessionDialog.js
> @@ +333,3 @@
>                                        }));
> 
> +        this._dbusImpl = new EndSessionDialogImpl(this);
> 
> Not exactly the nicest way to use the new API, but yeah, it should work.

Given that we already inherit from another thing, how else would you do it? In cases like these where monkey patching is cleaner, I'm thinking we should keep both approaches available in gjs.
Comment 6 Florian Müllner 2019-02-27 17:46:03 UTC
Bug 669350 never happened, so there's little sense in keeping this bug.