Re: where is alloc_color called

[Mitchell Laks <mlaks verizon net>]

On 20:50 Thu 26 Apr     , Chris Vine wrote:
> 
> Gdk::Color objects are not "created" in the sense of requiring a special
> create function returning a pointer (or in the case of gtkmm, a
> Glib::RefPtr<>).  They are just a wrapper for the GdkColor struct, and
> you can create them in local scope, as the example does, and they can be
> passed to any of the Gdk/Gtk functions to which they are an argument
> without their life having to be extended beyond that of the function
> call in question.
> 
> You do not always have to allocate a colour with
> Gdk::Colormap::alloc_color().  Some (in fact, most of the Gtk functions
> which take a Color object as an argument) do not require it, nor
> according to the documentation does Gdk::GC::set_rgb_fg_color() (which
> is the function which the example calls) or its Gtk equivalent
> Gtk::Widget::modify_fg().  These functions will allocate it themselves.
> Gdk::Colormap::alloc_color() is required for those functions which do
> not do that, such as Gdk drawing functions.

Thank you, I had not  noticed the information in the gtkmm API doc indicating that the
functions Gdk::GC::set_rgb_fg_color() work on unallocated colors.

I guess my next point was: I was noting that the documentation example did not unref the allocated 
colors explicitly. For instance if the convenience function Gdk::GC::set_rgb_fg_color() itself 
does the allocation automatically and assign the pixel struct element in _GdkColor.

Somehow I thought, and please correct me if I am wrong,  that unless you unref the Color,  
even though the struct will go away outside of local scope here in C/C++
at the level of the program (ie the X client), I worried that 
you will still get a memory leak at the X server level, unless you run
the free_colors function. 
I am still uncertain how the client and server  are 'coupled' with respect to this.

> 
> I may have misunderstood your last question, but the Gdk::Color object
> in the example will be destroyed when it goes out of scope - objects of
> local scope are on the stack.  That is how C++ works (and also C for
> that matter, although C will not call a destructor for you).  So far as
> concerns server side resources, you rarely need to call
> Gdk::Color::free_color(), unless you allocate the colour as writeable.

What do you mean by allocate the colour as writeable?

Here  is an old message I found while going through the archive of gtkmm mailing list...

From: Antonio Coralles 
Subject: Re: colormap assertion errors
Newsgroups: gmane.comp.gnome.gtkmm
Date: 2004-11-29 21:05:15 GMT (2 years, 21 weeks, 21 hours and 38 minutes ago)

B.Hakvoort wrote:

> On Mon, 2004-11-29 at 09:51 -0600, Rob Benton wrote:
>> Hey I've been working with the drawarea widgets lately and I've run into
>> a strange problem.  I don't know if I've found a bug or if something is
>> missing from my code.
>>
>> Basically what I have is a window with an eventbox which holds a
>> drawarea widget.  When clicked it pops up a dialog with another drawarea
>> widget.  If I open this dialog 10 times or more, when I close the main
>> window I get lots of GDK_IS_COLORMAP assertion errors.
>>
>
>
> Hi Rob,
>
>
> A while ago i experienced something similar.. It turned out i didn't
> free colors i had allocated before with alloc_color() .
>
>
> To free them i use free_colors()
>
>
> I'm not sure if this will help you, but's it's worth the try ;)
>
>
> Bart
>
so maybe you know what the ncolors argument in
void Gdk::Colormap::free_colors(Color&        colors,    int      ncolors)
is for ? i asked this some time ago, and murray told me i should file a 
bug, which i did ...
http://bugzilla.gnome.org/show_bug.cgi?id=157744

ps: in gtkmm-2.2 this function looks different: void free_colors 
(GdkColor* colors, int ncolors) which seems to
      make more sense ....

antonio


> 
> Chris
> 
> 

Thank you very much for your help!

Mitchell