Didn't mean to exclude the group from this. Outlook, what can I say?
OK and I didn't expect you to send that private answer on a public
mailing list :-(
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/
Didn't mean to exclude the group from this. Outlook, what can I say?
> -Original Message-
> From: Emmanuel Touzery [mailto:emmanuel.touz...@free.fr]
> Sent: Friday, September 11, 2009 1:46 AM
> To: Boggess Rod
> Subject: Re: why do constructors return GtkWidge
Emmanuel Touzery wrote:
It startles me that it doesn't seem to bother people much that all the
widget variables are declared as GtkWidget*.
Well, if you want you can use variables of type GtkWidgetOfTypeX * and
type cast on the call of constructor. You have to type cast back to
GtkWidget * allo
Hi,
Indeed. Not building interfaces manually may save time now and then,
but it hinders your understanding of what is happening. For instance
when you want to dynamically make interface changes at run time your
left with simple hide & show tricks. I can remember more than once
when I wanted t
Tristan Van Berkom wrote:
On Thu, Sep 10, 2009 at 3:24 PM, Thomas Stover wrote:
[...]
Well that's pretty much how I see it, but creating new derived widgets is
not always the same thing as dynamic interface manipulation. The issue that
grabbed my attention more was the notion of always using
On Thu, Sep 10, 2009 at 3:24 PM, Thomas Stover wrote:
[...]
>
> Well that's pretty much how I see it, but creating new derived widgets is
> not always the same thing as dynamic interface manipulation. The issue that
> grabbed my attention more was the notion of always using GtkBuilder. I'm
> just
Tristan Van Berkom wrote:
Im not exactly sure what your trying to say, my understanding is that
in the modern world you create widget subclasses when you need
composite/dynamic widgets, all widgets are generally layed out in some
kind of form, or multiple forms.
Thats my understanding of the bl
On Thu, Sep 10, 2009 at 2:12 PM, Thomas Stover wrote:
>
[...]
>
> Indeed. Not building interfaces manually may save time now and then, but it
> hinders your understanding of what is happening. For instance when you want
> to dynamically make interface changes at run time your left with simple hide
Tristan Van Berkom wrote:
On Wed, Sep 9, 2009 at 2:53 AM, Emmanuel
Touzery wrote:
Hi,
[...]
You know what I'm thinking... I think that this is from times where people
used to build GUIs in the code... When they were writing all the container
embedding and all,
Tristan Van Berkom wrote:
On Wed, Sep 9, 2009 at 2:53 AM, Emmanuel
Touzery wrote:
Hi,
[...]
You know what I'm thinking... I think that this is from times where people
used to build GUIs in the code... When they were writing all the container
embedding and all, in C, building their d
On Wed, Sep 9, 2009 at 2:53 AM, Emmanuel
Touzery wrote:
> Hi,
[...]
> You know what I'm thinking... I think that this is from times where people
> used to build GUIs in the code... When they were writing all the container
> embedding and all, in C, building their dialogs. At that time that
> conven
> I think that this is from times where people
> used to build GUIs in the code... When they were writing all the container
> embedding and all, in C, building their dialogs.
Those times are still very much here. For instance in the application
that gave GTK+ the "G" in its name.
--tml
__
I'm also using the real types in my declarations, though I'm paying
the price with casts.
And here I mean:
GtkMenuItem *dir_or_not = GTK_MENU_ITEM
(gtk_menu_item_new_with_label ("Or not"));
gtk_menu_shell_append (GTK_MENU_SHELL (directory_filter_menu),
GTK_WIDGET (dir_o
Hi,
There is a technical difference when writing GTK+ code in C; for instance
its quite often that you will access methods on the GtkWidgetClass
(like show()/hide()/set_sensitive() etc), also many other apis take GtkWidget *
argument, namely GtkContainer apis which operate on child widgets.
> Fr
On Tue, Sep 8, 2009 at 12:54 PM, Emmanuel
Touzery wrote:
> Hi,
>>
>> Whatever type is returned, you'll have to do lots of casts, so whatever
>> convention is used, there's no avoiding that. And returning GtkWidget*
>> is just the current convention.
>> I personally would prefer correct types to be
Hi,
Whatever type is returned, you'll have to do lots of casts, so whatever
convention is used, there's no avoiding that. And returning GtkWidget*
is just the current convention.
I personally would prefer correct types to be used in the API, just to
show exactly what type to expect at runtime. Bu
On Tue, 2009-09-08 at 13:32 +0200, Emmanuel Touzery wrote:
> It's annoying for me because I find that putting the real types
> in
> my code makes it easier to follow (rather than everything being a
> GtkWidget*), but if I go that route, I must constantly up and
> downcast...
>
> From m
Hello,
I otherwise have a good understanding of GTK and can build
relatively big programs, but I have a poor understanding of gobject. I
use it to make my own gobjects in C but I don't understand all the
implementation details.
In particular, I don't understand why is it normal for G
18 matches
Mail list logo
