Stephane Peiry <[EMAIL PROTECTED]> wrote:
> The only issue I see atm is if parrot wants to call the callback it-
> self while in the "waiting for callback loop", mean it would run into
> some race conditions if for some reasons parrot invokes the callback,
> and somebody triggers the callback via g
Well, still about getting callbacks to work on GTK, thaught that before
going for this:
On Tue, Aug 24, 2004 at 09:44:56AM +0200, Leopold Toetsch wrote:
> >Otherwise, already thaught of actually unrolling the gtk_main function
> >and have it handled/implemented within parrot directly (mainly gtk_
On Tue, Aug 24, 2004 at 09:44:56AM +0200, Leopold Toetsch wrote:
> Whatever you'll try the current scheme is not compatible with this GTK
> callback. Parrot needs a PMC as user_data. GTK awaits a GObject.
> Yes. But draining the event queue still needs a running Parrot runloop.
This made me rem
Stephane Peiry wrote:
dlfunc P2, P1, 'g_signal_connect_object', 'lptppi'
Whatever you'll try the current scheme is not compatible with this GTK
callback. Parrot needs a PMC as user_data. GTK awaits a GObject.
Parrot stuffs the interpreter and the Sub PMC into user_data and unpacks
that when th
mh.. guess P is an actuall pointer to PMC, in that case forget that part.. :)
Stephane
On Mon, Aug 23, 2004 at 11:15:03PM +0200, Stephane Peiry wrote:
[signatures question gone]
> > *If* that is solved then the next problem is of course that by calling
> > gtk_main() the GTK event loop is runnin
On Mon, Aug 23, 2004 at 12:14:51PM +0200, Leopold Toetsch wrote:
> Leopold Toetsch wrote:
> >Stephane Peiry wrote:
> >
> >> g_return_val_if_fail (G_IS_OBJECT (gobject), 0); Fails here
>
> >gtk shouldn't make assumption on the user_data argument IMHO.
[...]
> call is NULL, because of the
Leopold Toetsch wrote:
Leopold Toetsch wrote:
Stephane Peiry wrote:
g_return_val_if_fail (G_IS_OBJECT (gobject), 0); Fails here
gtk shouldn't make assumption on the user_data argument IMHO.
The whole idea behind callbacks is, that there is a userdata argument
that get's passed through tr
Leopold Toetsch wrote:
Stephane Peiry wrote:
g_return_val_if_fail (G_IS_OBJECT (gobject), 0); Fails here
gtk shouldn't make assumption on the user_data argument IMHO.
I now tried calling g_cclosure_new_object() and
g_signal_connect_closure() directly. Doesn't segfault anymore (at least,
Stephane Peiry wrote:
g_return_val_if_fail (G_IS_OBJECT (gobject), 0); Fails here
anyway I just dont see what could be wrong with the way parrot could be
passing the "user_data"?
gtk shouldn't make assumption on the user_data argument IMHO.
Whats the difference between the way parrot calls
On Thu, Aug 19, 2004 at 01:21:33PM +0200, Leopold Toetsch wrote:
> [ segfaulting example ]
> >g_signal_connect_object (G_OBJECT (button), "clicked",
> > G_CALLBACK (hello), NULL, 0);
>
> Are you sure, that these two G_foo() aren't doing something with the
> function a
Stephane Peiry wrote:
[ segfaulting example ]
g_signal_connect_object (G_OBJECT (button), "clicked",
G_CALLBACK (hello), NULL, 0);
Are you sure, that these two G_foo() aren't doing something with the
function arguments?
I've beautified the example a bit, segfaults
On Wed, Aug 18, 2004 at 09:11:17AM +0200, Leopold Toetsch wrote:
> You've mixed up the function parameters.
>
> > P0 = global "Gtk::gtk_window_new"
> > null I5
> > invoke
>
> > P15 = P5
>
> I presume that's "instance" ...
actually shouldnt the callback is for the button
> > # -- funct
Stephane Peiry <[EMAIL PROTECTED]> wrote:
> ow.. ok, this one is actaully a macro.. the actual function is
> gulong g_signal_connect_object (gpointer instance,
> const gchar *detailed_signal,
> GCallback c_handler,
>
On Tue, Aug 17, 2004 at 09:01:39AM +0200, Leopold Toetsch wrote:
> >> It returns a PerlUndef.
> > 60 dlfunc P2, P1, "g_signal_connect", "lptpP" - \
> > P2=NCI=PMC(0x8363fd0), P1=ParrotLibrary=PMC(0x8364108), ,
> > 65 store_global "Gtk::g_signal_connec", P2 - , \
> >P2=Per
Stephane Peiry <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 16, 2004 at 10:20:46AM +0200, Leopold Toetsch wrote:
>> "gtk-signal-connect" or "g-signal-connect" isn't found here. I can't
>> check the symbols of the lib, this dam** OS has symbols stripped. The
>> other box has only gtk-1.2.
> actually
On Mon, Aug 16, 2004 at 10:20:46AM +0200, Leopold Toetsch wrote:
> "gtk-signal-connect" or "g-signal-connect" isn't found here. I can't
> check the symbols of the lib, this dam** OS has symbols stripped. The
> other box has only gtk-1.2.
actually it should run as well against gtk-1.2 if "g_signal
Stephane Peiry <[EMAIL PROTECTED]> wrote:
> The problem is that as soon as it goes onto installing the callback
> parrot returns with a "get_string() not implemented in class
> 'UnManagedStruct'".
> So what is happening there?
"gtk-signal-connect" or "g-signal-connect" isn't found here. I can't
17 matches
Mail list logo
