Hello all,
Actually, I have an icon constructed with an image and a label, each packed
inside two separate Eventbox.
I was writing code for capturing DnD signals on the eventboxes but it was
not working. I tried altering the GDK event mask to GDK_ALL_EVENTS_MASK but
in vain.
Then I set the eventb
OK, I shouldn't have mentioned memory. Trying again.
Why was
void gtk_widget_get_allocation(GtkWidget *widget, GtkAllocation *allocation)
chosen, rather than
GtkAllocation *gtk_widget_get_allocation(GtkWidget *widget)
?
Cheers,
Patrick
___
gtk-
Any idea?
2010/5/30 John Williams :
> Don't work. Using gtk_button_new_from_stock I got no image in the
> button, just the label "my-icon". Using gtk_scale_button_new I got
> Segmentation fault again.
>
> Code:
> iconFactory = gtk_icon_factory_new();
>
> gtk_icon_factory_add(iconFactory, "my
Hello gtk-list,
I'm using
g_mem_set_vtable(glib_mem_profiler_table);
g_atexit(g_mem_profile);
as the first calls in the main function.
Even the most simple test app leaks memory about 125 KB
with 90% freed.
Do i have to call some cleanup methods ("gtk_exit" is deprecated
and doesnt work well) ?
Hi.
There are two distinct stock things in GTK+: stock items[1] and stock
icons[2]. Connection between them is purely conventional by virtue of
using the same ID for both stock item and icon, but nothing is
preventing you from having only item or only icon. It's developer's
responsibility to provi
On Wed, Jun 2, 2010 at 7:50 AM, Lothar Scholz wrote:
> Hello gtk-list,
>
> I'm using
>
> g_mem_set_vtable(glib_mem_profiler_table);
> g_atexit(g_mem_profile);
don't even waste your time. gtk does not leak. you are not the first
(and will not be the last) to ask this question. determining memory
u
On Wed, 2010-06-02 at 12:17 +0100, Patrick Welche wrote:
> OK, I shouldn't have mentioned memory. Trying again.
>
> Why was
>
> void gtk_widget_get_allocation(GtkWidget *widget, GtkAllocation *allocation)
>
> chosen, rather than
>
> GtkAllocation *gtk_widget_get_allocation(GtkWidget *widget
On Wed, 2010-06-02 at 13:50 +0200, Lothar Scholz wrote:
> Hello gtk-list,
>
> I'm using
>
> g_mem_set_vtable(glib_mem_profiler_table);
> g_atexit(g_mem_profile);
>
> as the first calls in the main function.
> Even the most simple test app leaks memory about 125 KB
> with 90% freed.
"leaks" how?
On Wed, Jun 02, 2010 at 01:31:30PM +0100, Emmanuele Bassi wrote:
> On Wed, 2010-06-02 at 12:17 +0100, Patrick Welche wrote:
> > OK, I shouldn't have mentioned memory. Trying again.
> >
> > Why was
> >
> > void gtk_widget_get_allocation(GtkWidget *widget, GtkAllocation
> > *allocation)
> >
> >
Hi.
> No it doesn't, which is why GtkAllocation is causing the problem with
> GSEAL_ENABLE, viz:
>
> GdkWindow *gtk_widget_get_window(GtkWidget *widget);
>
> not
>
> void gtk_widget_get_window(GtkWidget *widget, GdkWindow *window);
>
> and not the other accessor functions.
You missed the most i
On Wed, Jun 02, 2010 at 02:47:26PM +0200, Tadej Borov??ak wrote:
> Hi.
>
> > No it doesn't, which is why GtkAllocation is causing the problem with
> > GSEAL_ENABLE, viz:
> >
> > GdkWindow *gtk_widget_get_window(GtkWidget *widget);
> >
> > not
> >
> > void gtk_widget_get_window(GtkWidget *widget,
Hi.
> OK - you did see my constructor example, no? It would be cleaner the other
> way, wouldn't it?
I'm not a GTK+ developer and cannot speak for them, but having
consistent API is far more important to me than having some parts of
the code being brief.
Also, if you think about what this functi
On Wed, Jun 02, 2010 at 03:01:18PM +0200, Tadej Borov??ak wrote:
> Hi.
>
> > OK - you did see my constructor example, no? It would be cleaner the other
> > way, wouldn't it?
>
> I'm not a GTK+ developer and cannot speak for them, but having
> consistent API is far more important to me than having s
Hello.
> #if GTK_CHECK_VERSION (2,18,0)
> static GtkAllocation *dasher_get_widget_allocation(GtkWidget *w)
> {
> GtkAllocation a;
>
> gtk_widget_get_allocation(w, &a);
>
> return &a;
> }
> #endif
Just don't do this. Returning a pointer to a stack-allocated structure
is just s
On Wed, Jun 02, 2010 at 03:23:21PM +0200, Tadej Borov??ak wrote:
> Hello.
>
> > #if GTK_CHECK_VERSION (2,18,0)
> > static GtkAllocation *dasher_get_widget_allocation(GtkWidget *w)
> > {
> > GtkAllocation a;
> >
> > gtk_widget_get_allocation(w, &a);
> >
> > return &a;
> > }
> >
Hello Emmanuele,
EB> "leaks" how? some internal objects are singletons, and won't be freed
EB> for the entire duration of the application's lifetime.
A good libary/toolkit should always free singletons inside an exit
handler.
Just for the reason that using memory debugging tools is confusing
if
Hello Paul,
PD> enough. there have, on occasion, been small bugs found that cause
PD> leakage under particular circumstances. but in my experience of this
PD> mailing list (10 years now) just about every "leak" turns out to be a
PD> misunderstanding about how memory is allocated, used and freed.
On Wed, 2010-06-02 at 15:36 +0200, Lothar Scholz wrote:
> Hello Emmanuele,
>
> EB> "leaks" how? some internal objects are singletons, and won't be freed
> EB> for the entire duration of the application's lifetime.
>
> A good libary/toolkit should always free singletons inside an exit
> handler.
On Wed, 2010-06-02 at 14:31 +0100, Patrick Welche wrote:
> > Just don't do this. Returning a pointer to a stack-allocated structure
> > is just screaming "SIGSEGV".
>
> Which is why this isn't committed ;-) But finally you see the point?
yes. it sucks to maintain an application.
> > I can agre
On Wed, 2010-06-02 at 15:39 +0200, Lothar Scholz wrote:
> By the way, is there any way to find out what the reference count of
> an object is?
you really don't want to know that - because threads and
auto-vivification during dispose cycles might change that value beneath
your seat.
if you want t
On Wed, 02 Jun 2010 14:41:39 +0100 Emmanuele Bassi wrote:
> you are, of course, free to start asking people to use atexit()
> handlers to free up one-off allocations, starting from the bottom of
> the stack (font-config, freetype, X11, glibc, Mesa, etc.) and moving
> up towards gtk+.
No, please,
On Wed, Jun 02, 2010 at 02:45:56PM +0100, Emmanuele Bassi wrote:
> because if you get a pointer to an internal data structure you're
> allowing people to use it. using const would also not work because of
> the (lax) semantics of const in C. it would, in essence, allow you to
> poke around with int
Hello.
> By the way, is there any way to find out what the reference count of
> an object is?
There is no need to know this. All you need to take care of is your
references on GObject. Most of the time this means calling
g_object_unref() when you don't need GObject that you created or
received it
--- On Wed, 6/2/10, Paul Davis wrote:
> From: Paul Davis
> Subject: Re: Does GTK leak memory
> To: "Lothar Scholz"
> Cc: gtk-list@gnome.org
> Date: Wednesday, June 2, 2010, 5:22 AM
> On Wed, Jun 2, 2010 at 7:50 AM,
> Lothar Scholz
> wrote:
> > Hello gtk-list,
> >
> > I'm using
> >
> > g_mem_
Hi.
> This all seems odd to me because the widget contains the allocation already.
> I don't give the address of a GtkWidget to some_widget_new() for it to
> fill in the structure. I call some_widget_new() and it returns a pointer
> to the widget which contains the allocation... All I need is a po
On Wed, Jun 2, 2010 at 10:11 AM, Sergei Steshenko wrote:
>
>
> --- On Wed, 6/2/10, Paul Davis wrote:
>> don't even waste your time. gtk does not leak.
>
> I have never laughed more. Just go through gtk+ release notes and look for
> the fixed bugs related to memory leaks.
>
> gtk+ propaganda mach
How would one go about testing their own application, with the fact that GTK
does not free some of its memory, in order to make sure the application isn't
leaking memory? I suppose that you could just look at a list of processes and
note when a repeated task (Opening/closing a window, connecting
--- On Wed, 6/2/10, Paul Davis wrote:
> From: Paul Davis
> Subject: Re: Does GTK leak memory
> To: "Sergei Steshenko"
> Cc: "Lothar Scholz" , gtk-list@gnome.org
> Date: Wednesday, June 2, 2010, 8:37 AM
> On Wed, Jun 2, 2010 at 10:11 AM,
> Sergei Steshenko
> wrote:
> >
> >
> > --- On Wed, 6/2
Hello Emmanuele,
EB> personally, no: I don't think it's at all necessary. and I've been doing
EB> memory profiling of glib- and non-glib based libraries and applications
EB> for a while.
I'm programming C for 25 years and i still don't feel safe without
tools. And this is not really a feeling but
Hello Emmanuele,
Wednesday, June 2, 2010, 3:49:04 PM, you wrote:
EB> On Wed, 2010-06-02 at 15:39 +0200, Lothar Scholz wrote:
>> By the way, is there any way to find out what the reference count of
>> an object is?
EB> you really don't want to know that - because threads and
EB> auto-vivificatio
On Jun 2, 2010 1:36pm, Lothar Scholz wrote:
Maybe GTK is really just another toy?
Interesting way to ask for help.
Best regards,
Indeed.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Hello american,
Wednesday, June 2, 2010, 11:35:21 PM, you wrote:
>
On Jun 2, 2010 1:36pm, Lothar Scholz wrote:
> Maybe GTK is really just another toy?
Interesting way to ask for help.
> Best regards,
Indeed.
Well its the impression i get from GTK after spending
30 days writing
On Wed, Jun 2, 2010 at 4:36 PM, Lothar Scholz wrote:
> And a tool that just dumps me which objects are still alive would be
> very helpfull too. MacOSX and MFC have features like this. Maybe GTK
> is really just another toy?
and to think that i was trying to save you time and effort. here
endeth
Anybody?
On Wed, Jun 2, 2010 at 4:27 PM, Debmalya Sinha wrote:
>
> Hello all,
>
> Actually, I have an icon constructed with an image and a label, each packed
> inside two separate Eventbox.
>
> I was writing code for capturing DnD signals on the eventboxes but it was
> not working. I tried alteri
Hello Paul,
Thursday, June 3, 2010, 4:22:44 AM, you wrote:
PD> On Wed, Jun 2, 2010 at 4:36 PM, Lothar Scholz wrote:
>> And a tool that just dumps me which objects are still alive would be
>> very helpfull too. MacOSX and MFC have features like this. Maybe GTK
>> is really just another toy?
PD>
Greetings,
LS >>> By the way, is there any way to find out what the reference count of
LS >>> an object is?
LS > Experimental printf statements to dump ref counter values are good to
LS > understand which API function is adding a reference and which takes
LS > ownership.
G_OBJECT(gtk_widget)->ref
36 matches
Mail list logo
