Using gdbus for communicating between process
I am trying to understand GDBus and novice to dbus .. I have 2 daemons( A and B) running and to communicate between these 2 process , I would like to use gdbus . I could not figure out any examples of using gdbus in C with this regard. Any pointers or examples in this regard would be helpful. -- Tom :) /*It's too complicated, Lets make it simple*/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk4: gtk_box_pack_start()/end() porting
On Fri, 2017-04-28 at 17:50 +0200, Murray Cumming wrote: > On Fri, 2017-04-28 at 17:20 +0200, Timm Bäder wrote: > > I've added notes about the fill and expand child properties to the > > migration guide: > > https://git.gnome.org/browse/gtk+/commit/?id=bb1deaafa42ccb03929d3c > > d5 > > fdab685218bbac29 > > Thanks. I guess it's that last part about hexpand/vexpand affecting > the > parent widgets too that explains what I've seen so far. So there is > really no simple mapping from the old API to the new API. Porting is > going to be rather awkward. Have some container widgets changed, or lost, some default spacing/padding/margins too? For instance, it looks like GtkActionBar used to have some hard-coded spacing between its child widgets (added via gtk_action_bar_pack_start()), but not with gtk4. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk4: gtk_box_pack_start()/end() porting
On 03.05, Murray Cumming wrote: > On Fri, 2017-04-28 at 17:50 +0200, Murray Cumming wrote: > > On Fri, 2017-04-28 at 17:20 +0200, Timm Bäder wrote: > > > I've added notes about the fill and expand child properties to the > > > migration guide: > > > https://git.gnome.org/browse/gtk+/commit/?id=bb1deaafa42ccb03929d3c > > > d5 > > > fdab685218bbac29 > > > > Thanks. I guess it's that last part about hexpand/vexpand affecting > > the > > parent widgets too that explains what I've seen so far. So there is > > really no simple mapping from the old API to the new API. Porting is > > going to be rather awkward. > > Have some container widgets changed, or lost, some default > spacing/padding/margins too? For instance, it looks like GtkActionBar > used to have some hard-coded spacing between its child widgets (added > via gtk_action_bar_pack_start()), but not with gtk4. Yes, iirc GtkPopover with .menu and GtkFileChooserButton, etc. lost their spacing. Since GtkBox supports border-spacing via CSS now, I think themes should handle that instead, but Adwaita doesn't care yet. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-devel-list Digest, Vol 157, Issue 3
On 3 May 2017 at 13:00, wrote: > From: Murray Cumming > To: Timm B?der > Cc: gtk-devel-list > Subject: Re: gtk4: gtk_box_pack_start()/end() porting > Message-ID: <1493810933.18452.1.ca...@murrayc.com> > Content-Type: text/plain; charset="UTF-8" > > On Fri, 2017-04-28 at 17:50 +0200, Murray Cumming wrote: > > On Fri, 2017-04-28 at 17:20 +0200, Timm B?der wrote: > > > I've added notes about the fill and expand child properties to the > > > migration guide: > > > https://git.gnome.org/browse/gtk+/commit/?id=bb1deaafa42ccb03929d3c > > > d5 > > > fdab685218bbac29 > > > > Thanks. I guess it's that last part about hexpand/vexpand affecting > > the > > parent widgets too that explains what I've seen so far. So there is > > really no simple mapping from the old API to the new API. Porting is > > going to be rather awkward. > > Have some container widgets changed, or lost, some default > spacing/padding/margins too? For instance, it looks like GtkActionBar > used to have some hard-coded spacing between its child widgets (added > via gtk_action_bar_pack_start()), but not with gtk4. > Based on some commits I remember seeing, I think the new policy is that widgets should not enforce such properties. Which, IMO, is a good thing, though again potentially a pain for porting. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk4: gtk_box_pack_start()/end() porting
On Wed, 2017-05-03 at 14:22 +0200, Timm Bäder wrote: > > Have some container widgets changed, or lost, some default > > spacing/padding/margins too? For instance, it looks like > > GtkActionBar > > used to have some hard-coded spacing between its child widgets > > (added > > via gtk_action_bar_pack_start()), but not with gtk4. > > Yes, iirc GtkPopover with .menu and GtkFileChooserButton, etc. lost > their > spacing. Since GtkBox supports border-spacing via CSS now, I think > themes should handle that instead, but Adwaita doesn't care yet. So, applications shouldn't generally need to specify any spacing at all between child widgets in containers? For instance - Gtk::Box::spacing - margin of child widgets in a Gtk::ActionBar - Gtk::Grid column-spacing and row-spacing ? GTK 3 and GTK 4 themes are separate, right? -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk4: gtk_box_pack_start()/end() porting
On 03.05, Murray Cumming wrote: > On Wed, 2017-05-03 at 14:22 +0200, Timm Bäder wrote: > > > Have some container widgets changed, or lost, some default > > > spacing/padding/margins too? For instance, it looks like > > > GtkActionBar > > > used to have some hard-coded spacing between its child widgets > > > (added > > > via gtk_action_bar_pack_start()), but not with gtk4. > > > > Yes, iirc GtkPopover with .menu and GtkFileChooserButton, etc. lost > > their > > spacing. Since GtkBox supports border-spacing via CSS now, I think > > themes should handle that instead, but Adwaita doesn't care yet. > > So, applications shouldn't generally need to specify any spacing at all > between child widgets in containers? For instance > - Gtk::Box::spacing > - margin of child widgets in a Gtk::ActionBar > - Gtk::Grid column-spacing and row-spacing > ? No, I'm talking about individual widgets, not applications and their UI[1]. The default values of the properties are gone in GTK+, but not the properties itself. GtkActionBar lost its spacing property I think, but that's just because I didn't know if there's a real use case for it, it seems like something the theme should control in this case. Right now we still have all the spacing properties in GtBox, GtkGrid, etc. as you mentioned and of course the widget margin properties you can use and they still work like they did in gtk3. [1]Even though spacing *should* probably be handled by the theme, so the theme can decide whether UIs are more spacey or more narrow, nobody has come up with a proper way for applications to specify that. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk4: gtk_box_pack_start()/end() porting
On Wed, 2017-05-03 at 15:45 +0200, Timm Bäder wrote: [snip] > [1]Even though spacing *should* probably be handled by the theme, so > the > theme can decide whether UIs are more spacey or more narrow, nobody > has > come up with a proper way for applications to specify that. Yes, I've never liked how applications have all these magic values sprinkled through their code. Thanks for the explanation. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 3.24?
Will there absolutely positively never be any GTK+ 3.23/24 releases? After all these years of not adding API, or deprecating API, in micro releases, I feel very uneasy about doing that in gtkmm 3.22.* just because GTK+ seems to be doing it. But if there will never be a GTK+ 3.24, we could have a gtkmm 3.24 that adds and deprecates API without causing too much confusion in the future. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 3.24?
On Wed, May 3, 2017 at 2:55 PM, Murray Cumming wrote: > Will there absolutely positively never be any GTK+ 3.23/24 releases? > > After all these years of not adding API, or deprecating API, in micro > releases, I feel very uneasy about doing that in gtkmm 3.22.* just > because GTK+ seems to be doing it. > No plans for a 3.24, no. I don't think there is much of a problem with adding deprecations - they are really a tool to help people prepare for the jump to the next version. If you want to stick with 3.22.x, there is no reason to chase deprecations. As for new API, we have been pretty careful so far, and only allowed some very minor additions in 3.22.x. Any examples you are thinking of ? > > But if there will never be a GTK+ 3.24, we could have a gtkmm 3.24 that > adds and deprecates API without causing too much confusion in the > future. I'm afraid that a gtkmm 3.24 that is based on gtk+ 3.22 would cause quite a bit of confusion. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
