On Thu, 2017-01-05 at 17:02 +0100, infirit wrote:
> Op 01/05/2017 om 03:39 PM schreef Richard Shann:
> > I see that pango_scan_string() is deprecated since version 1.38
> > but the documentation doesn't indicate what it should be replaced with -
> > anyone got any ideas?
>
> See [1] for the
Op 01/05/2017 om 03:39 PM schreef Richard Shann:
> I see that pango_scan_string() is deprecated since version 1.38
> but the documentation doesn't indicate what it should be replaced with -
> anyone got any ideas?
See [1] for the reasoning. Its now deprecated but from the looks of it
there is no
I see that pango_scan_string() is deprecated since version 1.38
but the documentation doesn't indicate what it should be replaced with -
anyone got any ideas?
Richard Shann
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
Hi,
so you mean that the getter/setter usually internally calls the dynamic
„property“ version where the property is passed as a string?
Thus it would make sense that language bindings are fine using the
get/set_property methods since there is no overhead.
Best regards,
Tobias
> Am
Thanks, do you know what the Python gtk bindings (3.x) are using?
Tobias
> Am 05.01.2017 um 11:05 schrieb Debarshi Ray :
>
> On Tue, Jan 03, 2017 at 10:46:13PM +0100, Tobias Knopp wrote:
>> - Is any accessor backuped with a property and vice versa?
>
> Nicola already
On Tue, Jan 03, 2017 at 10:46:13PM +0100, Tobias Knopp wrote:
> - Is any accessor backuped with a property and vice versa?
Nicola already answered this.
> - Which one is to prefer?
It depends.
For simple setting and getting of values from C, I prefer the
accessors because (a) it lets the
Hi,
Il Tue, 3 Jan 2017 22:46:13 +0100 Tobias Knopp scrisse:
> ...
> - Is any accessor backuped with a property and vice versa?
Only the second part stands, i.e. any property should have its
own accessors. There is some exception though, e.g.
GtkContainer:child, but that is
Il Thu, 05 Jan 2017 07:27:10 + Gergely Polonkai
scrisse:
> Hello,
>
> I don't know about others, but in my own code, my_obj_set_property() does
> nothing else just calls the setter functions (and the same for getters). It
> makes much more sense, and I saw it in a lot