Now that I'm not on my phone, I can probably do a better job at
replying to this email.
On 21 March 2017 at 23:21, Emmanuele Bassi wrote:
>
> On Tue, 21 Mar 2017 at 21:23, S. Jacobi wrote:
>>
>> On Tue, 21 Mar 2017 20:53:04 +
>> Emmanuele Bassi wrote:
>>
>> >
>> > Also, do not store a priva
On Tue, 21 Mar 2017 at 21:23, S. Jacobi wrote:
> On Tue, 21 Mar 2017 20:53:04 +
> Emmanuele Bassi wrote:
>
> >
> > Also, do not store a private pointer in your instance structure, and
> > use the get_private_instance() function that the G_DEFINE_TYPE macro
> > creates for you.
> >
> So you s
On Tue, 21 Mar 2017 20:53:04 +
Emmanuele Bassi wrote:
>
> Also, do not store a private pointer in your instance structure, and
> use the get_private_instance() function that the G_DEFINE_TYPE macro
> creates for you.
>
So you say whenever I need access to the objects private data I should
c
Don't use g_type_class_add_privat(). Either use the define type with
private macro, or the define type with code macro with G_ADD_PRIVATE.
Also, do not store a private pointer in your instance structure, and use
the get_private_instance() function that the G_DEFINE_TYPE macro creates
for you.
The
Il Tue, 21 Mar 2017 17:55:31 + Tristan Van Berkom
scrisse:
> ...
> o I believe the lookups with G_TYPE_INSTANCE_GET_PRIVATE() are just
> as cheap as the pointer dereference (as it will be implemented
> using simple pointer arithmetic).
Hi Tristan,
the lookup indeed is quite expen
On Tue, 2017-03-21 at 18:27 +0100, S. Jacobi wrote:
> On Mon, 20 Mar 2017 16:01:39 +
> Tristan Van Berkom wrote:
>
> >
> >
> > Use instance private data, this will not need any priv pointer and
> > can be done with th G_DEFINE_TYPE_WITH_PRIVATE() macro, and another
> > to lookup your privat
On Mon, 20 Mar 2017 16:01:39 +
Tristan Van Berkom wrote:
>
> Use instance private data, this will not need any priv pointer and
> can be done with th G_DEFINE_TYPE_WITH_PRIVATE() macro, and another
> to lookup your private data inside your C file (under the hood, this
> uses negative instanc
Hello Mr. Jacobi
What I personally like to see is doing events. It makes your OOP extensible.
And is the usual way how things are done in GUI programming.
But it is not limited to GUI. For instance this event is handled by a
GUI callback
to toggle a button.
http://git.savannah.nongnu.org/cgit/gs
Hi
You don't have to use myWidget->parent since you dereference the pointer.
A pointer to a struct always points to the first field of the topmost
nesting level.
so it would be:
gtk_widget_set_name(myWidget);
Bests,
Joël
On Mon, Mar 20, 2017 at 6:29 PM, S. Jacobi wrote:
> On Mon, 20 Mar 20
On Mon, 20 Mar 2017 18:10:16 +0100
Joël Krähemann wrote:
> Hi
>
> As Tristan told you. The struct contains the other struct as not using
> a pointer.
>
> struct MyCompositeWidget
> {
> GtkAlignment alignment;
>
> GtkBox *box;
> };
>
The parent-is-a-pointer mistake was just me not thinking
On Mon, 20 Mar 2017 16:01:39 +
Tristan Van Berkom wrote:
>
> Use instance private data, this will not need any priv pointer and
> can be done with th G_DEFINE_TYPE_WITH_PRIVATE() macro, and another
> to lookup your private data inside your C file (under the hood, this
> uses negative instanc
Hi
No, you can talk in C of direct inheritance. Or implementing an interface.
As Tristan told you. The struct contains the other struct as not using
a pointer.
struct MyCompositeWidget
{
GtkAlignment alignment;
GtkBox *box;
};
The properties are inherited, too. As long you use
g_type_regis
On Mon, 2017-03-20 at 16:36 +0100, S. Jacobi wrote:
> First of all, inheritance may be the wrong word here in plain c, but
> I
> don't know how else to name it.
Sorry replied to this from my phone and missed some things...
> In different projects I see different approaches how to derive custom
>
Hi
> On Mar 20, 2017, at 3:36 PM, S. Jacobi wrote:
>
> First of all, inheritance may be the wrong word here in plain c, but I
> don't know how else to name it.
>
> In different projects I see different approaches how to derive custom
> widgets from existing ones. I can roughly group them into 2
14 matches
Mail list logo