Re: Installing DBus interface files for services
On Tue, 2015-01-13 at 10:43 +0800, Cosimo Cecchi wrote: > Hi all, > > > I was wondering if there's any reason we typically don't install on > the system DBus XML interface files for services. On my system, I can > see a bunch of definitions in /usr/share/dbus-1/interfaces, but it's > by no means a complete list of all the services in the system. > Standardizing such a practice would make it easier to write code that > uses e.g. gdbus-codegen to automatically generate code for those > interfaces; currently a lot of projects need to copy/paste the > interface definition in their source tree, which is impractical and > can lead to inconsistencies when one version of the interface is > updated (in a backwards-compatible way) but not the other side. I can’t think of any reasons why not. Perhaps a GDBus automake snippet could be installed by GLib which: 1. Installs D-Bus XML interface files. 2. Includes rules for building documentation and C/H files from them. 3. Validates the XML interface files for well-formedness. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Installing DBus interface files for services
On 13/01/15 08:08, Philip Withnall wrote: > On Tue, 2015-01-13 at 10:43 +0800, Cosimo Cecchi wrote: >> I was wondering if there's any reason we typically don't install on >> the system DBus XML interface files for services. On my system, I can >> see a bunch of definitions in /usr/share/dbus-1/interfaces, but it's >> by no means a complete list of all the services in the system. ... > Perhaps a GDBus automake snippet > could be installed by GLib which: > 1. Installs D-Bus XML interface files. > 2. Includes rules for building documentation and C/H files from them. Be a bit careful with this. It's a good idea up to a point, but most (all?) D-Bus services do not offer any particular guarantees about the ABI of their D-Bus introspection XML. Even if the D-Bus API itself remains stable (which is by no means a given), anything that is sensitive to the order of items in the file is potentially going to break (i.e. it's important that code generated from a third-party D-Bus API has an ABI based on the name of the signal/function/property, not its numeric position). Similarly, if an API consumer generates extern C API from D-Bus introspection XML, it's hard to ensure that symbols don't appear and disappear in a way that does not depend deterministically on the API consumer's own version, depending on the version of the source of the introspection XML that it happened to be built against. This is why telepathy-glib and telepathy-qt each ship their own copy of telepathy-spec, rather than build-depending on an external copy. If the consumer generates internal-only C functions from introspection XML, looks them up by name (explicitly or via the linker), and does not generate anything with an inherent order (enums), then you can probably get away with it: the worst that can happen is failure to build because the introspection XML is too old. S ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Installing DBus interface files for services
On Tue, 2015-01-13 at 11:59 +, Simon McVittie wrote: > On 13/01/15 08:08, Philip Withnall wrote: > > On Tue, 2015-01-13 at 10:43 +0800, Cosimo Cecchi wrote: > >> I was wondering if there's any reason we typically don't install on > >> the system DBus XML interface files for services. On my system, I can > >> see a bunch of definitions in /usr/share/dbus-1/interfaces, but it's > >> by no means a complete list of all the services in the system. > ... > > Perhaps a GDBus automake snippet > > could be installed by GLib which: > > 1. Installs D-Bus XML interface files. > > 2. Includes rules for building documentation and C/H files from them. > > Be a bit careful with this. It's a good idea up to a point, but most > (all?) D-Bus services do not offer any particular guarantees about the > ABI of their D-Bus introspection XML. *interesting details snipped* Good points, but I guess that’s also true (to a lesser extent) with C headers in /usr/include. There are no explicit guarantees about stability which come with being installed in that location. Perhaps we could encourage proper D-Bus API versioning by having a mandatory dbus_service_version variable in the automake snippet, which the user has to set? It wouldn’t force them to bump it at the right time, but at least it would make them think about versioning. (Hopefully.) Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Atomix maintenance
Hi, In lack of active maintenance (last release 9 years ago, namely 2.14.0) I intend to take over the maintenance of the Atomix [1] game from gnome git[2]. As I couldn't reach the previous maintainer, I hereby announce me stepping up as a maintainer of this little game I like since I first saw it a long-long time ago. In short-term I intend to release Atomix 3.16 with the 3.16 release train (regular releases starting from 3.15.4), with the game ported to GTK3 (90% complete at this moment) and some more bug-fixes, the game being in a relatively good and playable shape in spite of it's age. Mid-term plans include bringing the game into the modern age, leveraging GNOME3 features we all know and love, and we have seen work well in other recently redesigned gnome games. If anyone wants to join the party : play the game [3], report bugs and feature requests [4], just for fun. Regards, Robert [1] https://wiki.gnome.org/Apps/Atomix [2] https://git.gnome.org/browse/atomix [3] https://download.gnome.org/sources/atomix/ [4] https://bugzilla.gnome.org/enter_bug.cgi?product=atomix ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Clone of 2048 for Gnome
Hi, Thank you very much!! The bug report for creating a new bugzilla product is already filed, so in the coming weeks we will have it. Anyway I take note of your problem. Right now btw I'm working on improving animations since I have detected that they not always work fine, e.g. sometimes new tiles do not scale back to 1.0. Thank you. Best regards, Juan. On Jan 13, 2015 6:42 PM, "Yosef Or Boczko" wrote: > Hey, > > I just translated gnome-2048 to Hebrew, and I see problem with RTL. > Are you going to create producte for gnome-2048 in the bugzilla? > > See the screenshot to understand the problem... > > Regards, > Yosef Or Boczko > > 2015-01-08 23:33 GMT+02:00 Juan R. : > >> Hi, >> >> Thank you for trying it. Since I do not see any of the program's methods >> involved in the crash, I think it is not my fault :) If this crash >> persists I can try to reproduce it. >> >> Best regards, >> Juan. >> >> On Wed, 2015-01-07 at 23:48 +0100, Bastien Nocera wrote: >> > On Wed, 2015-01-07 at 22:51 +0100, Juan R. García Blanco wrote: >> > > Hi, >> > > >> > > As suggested and following interest from other GNOME developers I just >> > > created the gnome-2048 repo and pushed the code. Please let me know if >> > > there is anything wrong and if I can do something to fix it. >> > >> > It crashes on startup for me: >> > #0 g_type_check_instance_is_fundamentally_a >> (type_instance=type_instance@entry=0x130e920, >> fundamental_type=fundamental_type@entry=80) at gtype.c:4028 >> > #1 0x72b129e7 in g_object_unref (_object=0x130e920) at >> gobject.c:3067 >> > #2 0x7282c59d in g_slist_foreach (list=, >> func=0x72b129d0 , user_data=0x0) at gslist.c:877 >> > #3 0x77907982 in clutter_clock_dispatch () from >> /lib64/libclutter-1.0.so.0 >> > #4 0x7280eba3 in g_main_dispatch (context=0x65fe20) at >> gmain.c:3125 >> > #5 g_main_context_dispatch (context=context@entry=0x65fe20) at >> gmain.c:3750 >> > #6 0x7280efa8 in g_main_context_iterate >> > (context=context@entry=0x65fe20, >> block=block@entry=1, dispatch=dispatch@entry=1, self=) at >> gmain.c:3821 >> > #7 0x7280f04c in g_main_context_iteration (context=0x65fe20, >> context@entry=0x0, may_block=may_block@entry=1) at gmain.c:3882 >> > #8 0x730c5aec in g_application_run >> (application=application@entry=0xd38360, argc=1, argv=0x7fffd8b8) at >> gapplication.c:2290 >> > #9 0x00406349 in application_main (args=0x7fffd8b8, >> args_length1=1) at application.c:1133 >> > #10 0x71f04fe0 in __libc_start_main (main=0x404c50 , >> argc=1, argv=0x7fffd8b8, init=, fini=, >> rtld_fini=, stack_end=0x7fffd8a8) at libc-start.c:289 >> > #11 0x00404c93 in _start () >> > >> > Need a bugzilla product as well? ;) >> > >> > Cheers >> > >> >> >> ___ >> desktop-devel-list mailing list >> desktop-devel-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list >> > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
