* James Henstridge <[EMAIL PROTECTED]> schrieb:
Hi,
> >Its easier than people might think, and it reduces much of the
> >code complexity. glib also makes some other prerequisites, so
> >I dont see why an glib3-user couldn't be expected to go along
> >with an gc ...
> >
> One of the strengths of g
On 22/03/06 17:38, Enrico Weigelt wrote:
>* Behdad Esfahbod <[EMAIL PROTECTED]> schrieb:
>
>
>
>
>
>>Using a GC in glib means every application using glib should
>>drag in the GC in too, which is not what glib developers going to
>>accept I believe.
>>
>>
>
>Its easier than people might thi
* Morten Welinder <[EMAIL PROTECTED]> schrieb:
> What you can do is to have GC in certain subsets of C. But
> before you go there, consider how you want to do without, for
> example, printf("%p",...) and GPOINTER_TO_UINT. There is a
> zillion ways you can hide a C pointer from the GC system,
>
> If now someone's interested, we can talk about this again.
> GC is one of the major points I'd like to get in into glib3 ...
That cat is dead. You cannot do GC in C. And you especially
cannot do it in the slightly-extended C that glib is written
in.
What you can do is to have GC in certain s
* Behdad Esfahbod <[EMAIL PROTECTED]> schrieb:
> Using a GC in glib means every application using glib should
> drag in the GC in too, which is not what glib developers going to
> accept I believe.
Its easier than people might think, and it reduces much of the
code complexity. glib also makes
On Wed, 22 Mar 2006, Enrico Weigelt wrote:
> * Tristan Van Berkom <[EMAIL PROTECTED]> schrieb:
>
> Hi,
>
> > On an involved list such as this; I seriously doubt that nobody
> > listened, alot of people probably put some quality time into deciding
> > not to reply to such a proposal (dont be discou
* Tristan Van Berkom <[EMAIL PROTECTED]> schrieb:
Hi,
> On an involved list such as this; I seriously doubt that nobody
> listened, alot of people probably put some quality time into deciding
> not to reply to such a proposal (dont be discouraged so easily :-D).
well, in fact there was one reply
On Tue, 2006-03-21 at 17:24, Clemens Fruhwirth wrote:
> I'm interested in developing a McCLIM backend for wxcl. McCLIM is a high
> level GUI toolkit for Common Lisp. I want to use wxcl for this
> task. wxcl=bindings for wxWidgets. The reason? The CL commmunity can't
> afford to maintain different b
On Tue, 2006-03-21 at 10:07 -0800, Dave Benson wrote:
> On Tue, Mar 21, 2006 at 11:10:24AM -0500, Owen Taylor wrote:
> > (*) Basically, it's impossible for GObject to know when a type is no
> > longer in use, because we don't have garbage collection in C.
> > So, if you unload and reload GT
Enrico Weigelt wrote:
* Owen Taylor <[EMAIL PROTECTED]> schrieb:
(*) Basically, it's impossible for GObject to know when a type is no
longer in use, because we don't have garbage collection in C.
Well, we could have. There're GC's for C out there, which seem to
work quite good.
I voted
Hi!
If unloading glib together with gtk is acceptable you can replace the
g_atexit function so you keep your own list and call it just before
dlclose()
See (and copy/paste) this great code:
http://download.insomniavisions.com/sources/uncompressed/cplusplus/g_atexit.cpp
Of course this works onl
On Tue, Mar 21, 2006 at 11:10:24AM -0500, Owen Taylor wrote:
> (*) Basically, it's impossible for GObject to know when a type is no
> longer in use, because we don't have garbage collection in C.
> So, if you unload and reload GTK+ again, referencing the
> type "GtkButton" is going to t
* Owen Taylor <[EMAIL PROTECTED]> schrieb:
> (*) Basically, it's impossible for GObject to know when a type is no
> longer in use, because we don't have garbage collection in C.
Well, we could have. There're GC's for C out there, which seem to
work quite good.
I voted for that several year
Hi Clemens,
in my phd project I had plugins for UI generation. One plugin was using gtk and
initialy I also requested a funtion like gtk_done() as a counterpart for
gtk_init(). I understood that this won't work and I just introduced a static
variable in my plugin to avoid double initialization
On Tue, 2006-03-21 at 17:24 +0100, Clemens Fruhwirth wrote:
> Milosz Derezynski <[EMAIL PROTECTED]> wrote:
>
> > From the docs GTK+ API docs:
> >
> > gtk_main():
> > [...] You can nest calls to gtk_main(). In that case gtk_main_quit() will
> > make the innermost invocation of the main loop retur
Clemens Fruhwirth wrote:
Milosz Derezynski <[EMAIL PROTECTED]> wrote:
[...]
Grepping through gtk for g_module_open, there are a few other
places. For instance the "im" modules, the filesystem modules and 3 in
gdk-pixbuf/. I presume there will be a list of loaded modules somewhere,
so I guess it
Milosz Derezynski <[EMAIL PROTECTED]> wrote:
> From the docs GTK+ API docs:
>
> gtk_main():
> [...] You can nest calls to gtk_main(). In that case gtk_main_quit() will
> make the innermost invocation of the main loop return.
> gtk_main_quit():
> Makes the innermost invocation of the main loop re
Sorry i forgot to ask: What do you mean by "gtk assumes a fresh image"? (In which context?)On 3/21/06, Milosz Derezynski <
[EMAIL PROTECTED]> wrote:
>On 3/20/06, muppet <[EMAIL PROTECTED]> wrote:
>
>>Clemens Fruhwirth wrote:
>> I would like to ask how to properly unload gtk from a process image,
>
>On 3/20/06, muppet <[EMAIL PROTECTED]> wrote:
>
>>Clemens Fruhwirth wrote:
>> I would like to ask how to properly unload gtk from a process image,
>> when it has been brought there via dlopen. The initial situation is that
>> I need to enter gtk's main loop in a single process image multiple
>> t
Clemens Fruhwirth wrote:
> I would like to ask how to properly unload gtk from a process image,
> when it has been brought there via dlopen. The initial situation is that
> I need to enter gtk's main loop in a single process image multiple
> times, but that's not possible with gtk as gtk assumes a
On 3/20/06, Clemens Fruhwirth <[EMAIL PROTECTED]> wrote:
> Matthias Clasen <[EMAIL PROTECTED]> wrote:
>
> > That does not work.
>
> With due respect, but I can't image a reply that is less worth the time
> it took to write and read.
>
> Is it either "That does not work, because we don't to support
Matthias Clasen <[EMAIL PROTECTED]> wrote:
> That does not work.
With due respect, but I can't image a reply that is less worth the time
it took to write and read.
Is it either "That does not work, because we don't to support that",
"That does not work because of multi-platform troubles" or "Tha
On 3/20/06, Clemens Fruhwirth <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I would like to ask how to properly unload gtk from a process image,
> when it has been brought there via dlopen. The initial situation is that
> I need to enter gtk's main loop in a single process image multiple
> times, but tha
Hello,
I would like to ask how to properly unload gtk from a process image,
when it has been brought there via dlopen. The initial situation is that
I need to enter gtk's main loop in a single process image multiple
times, but that's not possible with gtk as gtk assumes a fresh image.
Hence, I lo
24 matches
Mail list logo
