implementing guile-gtk drag & drop...

implementing guile-gtk drag & drop...

[Stanislas Pinte]

hello,

when trying to implement the drag & drop bindings for guile-gtk, I am 
facing the following problem:

-I need to define new strucs, used by GTK: GtkTargetEntry; for example.

	How do I define a new struct? define-struct is not that documented, and 
I suppose I will have to play with C (I looked at the GTimer struct, 
define in gdk-1.2-defs), to define creator and destructor functions,

I will also have to define in C the functions needed from guile to 
create and access my new structs, like "g-timer-start", 
"g-timer-elapsed",....

thank you very much,

Stan.

Re: implementing guile-gtk drag & drop...

[Marius Vollmer]

Stanislas Pinte <alto_stan@wanadoo.be> writes:

> -I need to define new strucs, used by GTK: GtkTargetEntry; for example.
> 
> 	How do I define a new struct? define-struct is not that
> documented, and I suppose I will have to play with C (I looked at the
> GTimer struct, define in gdk-1.2-defs), to define creator and
> destructor functions,

Hmm, that's a difficult thing, in general.  I'd say that you should
probably first decide how you would like the function to appear in
Scheme. I.e., what would be convenient to use, in contrast to what is
currently easily done with guile-gtk.

Then, try to write a wrapper function by hand (based on examples from
gtk-glue.c, for example), and then we can discuss whether it is useful
to extend build-guile-gtk to make writing your wrapper function
easier.

For example, since GtkTargetEntry seems only to be used as a read-only
struct when passing parameters to gtk_drag_source_set, it might be
best to use a list in Scheme:

    (gtk-drag-source-set widget '(button1-mask) '((foo (same-app)))
                         '(default))

We could then write a function to fill a GtkTargetEntry struct from
'(foo (same-app)) and tell build-guile-gtk to use it.  (I don't know
the details right now.)  The .defs file entry might then look like

    (define-func gtk_drag_source_set
      none
      ((GtkWidget widget)
       (GdkModifierType start_button_mask)
       ((cvecr GtkTargetEntry) targets)
       (GdkDragAction actions)))

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405

Re: implementing guile-gtk drag & drop...

[Daniel Skarda]

Hello,

  last few hours I played with guile-gtk and drag'n'drop and I wrote bindings
for dnd functions. I was able to to write working scheme sibling of testdnd.c.
  
  The biggest problem was GtkSelectionData - a Gtk structure without "classic"
reference counting, moreover it is parameter of many gtk callbacks and dnd
stopped working when I use gtk_selection_data_copy/free :-(

  My (temporal) solution is little bit unsafe - or it is save until you copy
signal-data outside of signal handler and use it later. I guess this is very
unlikely but guile-gtk should be adjusted to handle such wild code
(unfortunately, this GtkSelectionData "feature" was not improved in Gtk+ 2.0 :-(

  I post my patch once I clean up my code.

0.

Re: implementing guile-gtk drag & drop...

[Stan Pinte]

At 01:26 6-11-2002 +0100, Daniel Skarda wrote:
>Hello,
>
>   last few hours I played with guile-gtk and drag'n'drop and I wrote bindings
>for dnd functions. I was able to to write working scheme sibling of testdnd.c.
>
>   The biggest problem was GtkSelectionData - a Gtk structure without 
> "classic"
>reference counting,

do you know where I can find a good explanation of the reference counting 
strategies, in GTK?

Because I don't understand what is the problem...(blame my very poor 
knowledge of guile-gtk and gtk)

thanks,

Stan.

>moreover it is parameter of many gtk callbacks and dnd
>stopped working when I use gtk_selection_data_copy/free :-(
>
>   My (temporal) solution is little bit unsafe - or it is save until you copy
>signal-data outside of signal handler and use it later. I guess this is very
>unlikely but guile-gtk should be adjusted to handle such wild code
>(unfortunately, this GtkSelectionData "feature" was not improved in Gtk+ 
>2.0 :-(
>
>   I post my patch once I clean up my code.
>
>0.

Re: implementing guile-gtk drag & drop...

[Daniel Skarda]

 
> Because I don't understand what is the problem...(blame my very poor
> knowledge of guile-gtk and gtk)

  Gtk+ uses reference counting to protect some (!) data - GtkWidgets and so on.
Reference counter is increased when someone wants to "work" with object, counter
is decreased when "user" does not want to use it anymore. When reference counter
drops to zero, Gtk+ object is destroyed.

  Guile uses mark and sweep garbage collector - when GC is invoked, all
"referenced" data are marked and unmarked data are destroyed.

  Guile-gtk has to combine both strategies. When SMOB wraps Gtk object, it
increments counter, when smob is destroyed (nobody use scheme object), counter
is decremented. In fact the situation is a little bit more complicated (because
of callbacks etc), but I hope you got the picture.

  The problem with GtkSelectionData is following: since it does not have
reference counter, multiple "users" (parts of code) can not reference it,
because they do not know how many users it really has and when to destroy
it. You even do not know if you use already "destroyed" GtkSelectionData. You
can not protect it using counter and there is no way how to get to know when
object was destroyed (so you could invalidate it).

  The sad part of the story is, that you even can not copy GtkSelectionData and
work on your local copy - DnD will not work :-(

  My temporal solution is to be "blind" - I presume that nobody wants to shoot
into his foot and GtkSelectionData will be only referenced when it really exists
(otherwise it is the source of possible SIGSEGV..)

0.

ps: If you want to learn more about GC, look for paper by Paul R. Wilson:
Uniprocessor Garbage Collection Techniques.

Re: implementing guile-gtk drag & drop...

[Stan Pinte]

Thanks a lot for the clear answer.

I am ready to test your d&d patch to latest guile-gtk when you release it.

Stan.

Re: implementing guile-gtk drag & drop...

[Marius Vollmer]

Daniel Skarda <0rfelyus@ucw.cz> writes:

>   The biggest problem was GtkSelectionData - a Gtk structure without
> "classic" reference counting, moreover it is parameter of many gtk
> callbacks and dnd stopped working when I use
> gtk_selection_data_copy/free :-(

Using gtk_selection_data_copy/free seems to be the right thing to do.
Can you figure out why they made drag and drop fail?  Maybe there are
bugs in those functions that we can work around.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405

Re: implementing guile-gtk drag & drop...

[Daniel Skarda]

> Using gtk_selection_data_copy/free seems to be the right thing to do.
> Can you figure out why they made drag and drop fail?  Maybe there are
> bugs in those functions that we can work around.

  Unfortunately Gtk creates GtkSelectionData, invokes a handler and expects that
you gtk_selection_data_set on data that Gtk passed to handler, not to its copy :-( 
See gtkselection.c.

0.

Re: implementing guile-gtk drag & drop...

[Marius Vollmer]

Daniel Skarda <0rfelyus@ucw.cz> writes:

> > Using gtk_selection_data_copy/free seems to be the right thing to do.
> > Can you figure out why they made drag and drop fail?  Maybe there are
> > bugs in those functions that we can work around.
> 
>   Unfortunately Gtk creates GtkSelectionData, invokes a handler and
> expects that you gtk_selection_data_set on data that Gtk passed to
> handler, not to its copy :-( See gtkselection.c.

Aha.  So gtk_selection_data_copy is useless and GtkSelectionData
should really be using reference counting, right?

In that case, we need a new kind of life-time management option in
guile-gtk: the Scheme value that represents a GtkSelectionData needs
to be invalidated when the real GtkSelectionData is freed.

We don't have such a mechanism currently, but it should not be that
difficult to add it.  Basically, sgtk_callback_marshal would need to
'destroy' the arguments of the callback when it has returned.

Any takers?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405