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 698525 - turn gnome-clocks into a GApplication service
turn gnome-clocks into a GApplication service
Status: RESOLVED FIXED
Product: gnome-clocks
Classification: Applications
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Clocks maintainer(s)
Clocks maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-04-21 19:56 UTC by Allison Karlitskaya (desrt)
Modified: 2013-04-22 06:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
application: turn us into a service (6.51 KB, patch)
2013-04-21 19:56 UTC, Allison Karlitskaya (desrt)
committed Details | Review

Description Allison Karlitskaya (desrt) 2013-04-21 19:56:13 UTC
See patch.
Comment 1 Allison Karlitskaya (desrt) 2013-04-21 19:56:15 UTC
Created attachment 242097 [details] [review]
application: turn us into a service

Start using GApplication 'service' mode for gnome-clocks.  This allows
us to launch via D-Bus activation.

Provide a 'launcher' helper to install in /usr/bin so we can still be
started from the commandline.
Comment 2 Paolo Borelli 2013-04-21 20:58:07 UTC
Review of attachment 242097 [details] [review]:

Feel free to push, but create the 3-8 branch first.

A couple of silly nitpicks below

::: src/launcher.vala
@@ +17,3 @@
+ */
+
+namespace Clocks {

maybe let's drop the namespace for a single file launcher

@@ +19,3 @@
+namespace Clocks {
+
+public class Application : Gtk.Application {

I do not recall the vala scoping rules... can the class be private since it is all in this file?
Comment 3 Paolo Borelli 2013-04-21 21:13:29 UTC
On a more generic note, should we be able to query the version from the service? With your patch it is just handled in the wrapper, but maybe we should add a version field in the service description file, that way a launcher like this one could be autogenerated
Comment 4 Allison Karlitskaya (desrt) 2013-04-21 23:26:54 UTC
You're always going to have the libexec and the bin versions of the program installed at the same time... and the entire point of handling --version locally is that you don't need to start up the remote program...

Do you mean that we should open the D-Bus service file for ourselves and query it?
Comment 5 Allison Karlitskaya (desrt) 2013-04-21 23:34:57 UTC
Comment on attachment 242097 [details] [review]
application: turn us into a service

Attachment 242097 [details] pushed as abe5c22 - application: turn us into a service


Pushed with the suggested changes.

Once I update GIO (and the desktop file spec) we can finish up here by
adding 'DBusActivatable=true' to the .desktop file.
Comment 6 Paolo Borelli 2013-04-22 06:57:01 UTC
(In reply to comment #4)
> You're always going to have the libexec and the bin versions of the program
> installed at the same time... and the entire point of handling --version
> locally is that you don't need to start up the remote program...
> 
> Do you mean that we should open the D-Bus service file for ourselves and query
> it?

No, I meant two things:

 - maybe we should think of a way to autogenerate these silly launchers from the metadata (like the version) instead of having to cut&paste the same silly program

 - I expect that in the long run it is the shell or something else that will start the service instead of the launcher, so maybe it should be able to right click show version or something like that (though I guess that is better handled in the real .desktop file, not in the service definition)


Anyway, I am closing this