Re: Enabling drag destination



Below is the gir snippet to fix it..

  <record name="TargetList"
            c:type="GtkTargetList"
            glib:type-name="GtkTargetList"
            glib:get-type="gtk_target_list_get_type"
            c:symbol-prefix="target_list">
      <doc xml:whitespace="preserve">A #GtkTargetList structure is a reference counted list
of #GtkTargetPair. It is used to represent the same
information as a table of #GtkTargetEntry, but in
an efficient form. This structure should be treated as
opaque.</doc>

      <field name="list" writable="1">
        <type name="GLib.List" c:type="GList*">
          <type name="gpointer" c:type="gpointer"/>
        </type>
      </field>
      <field name="ref_count" writable="1">
        <type name="guint" c:type="guint"/>
      </field>



I ended up using a reference set of gir's and always using the typelibs generated from there. It's not very future proof, but at least it solves some of the worse gir bugs..
https://github.com/roojs/gir-1.2-gtk-3.0

This installs locally,
https://github.com/roojs/gitlive/blob/master/install1.2.sh

And this code 'prefers' the libs in seed (gjs should be pretty similar)
GI = imports.gi.GIRepository;
GLib = imports.gi.GLib;
// we add this in, as it appears to get lost sometimes if we set it using the ENV. variable in builder.sh
GI.Repository.prepend_search_path(GLib.get_home_dir() + '/.Builder/girepository-1.2');
I normally actually overwrite the GLib/GIRepository distribution gir's, as there are so many other little things that are broken.

Ideally, it would be better if g-ir-compiler could merge two gir files (system+overrides) so maintaining the workarounds was easier (and easier to report upstream)..

Regards
Alan

On Tuesday, November 22, 2011 08:22 PM, Chris Vine wrote:
On Tue, 22 Nov 2011 07:24:40 +0800
"Alan Knowles" <alan akbkhome com> wrote:
http://roojs.com/blog.php/View/186/Drag%20and%20Drop%20with%20seed%20(_javascript_)%20and%20Gtk

works with seed, should be ok on gjs

i did not have much luck with mime type dragging, it works ok with
strings, but everything else was problematic.

Never had time or need to investigate further.
Thanks for the reply.

I did check this out before posting and with
gobject-introspection-1.30.0 it doesn't work for the same reason that
constructing a Gtk.TargetEntry object doesn't work, namely that this;

var targets = new Gtk.TargetList();

generates this error in gjs:

Unable to construct boxed type TargetList since it has no zero-args
<constructor>, can only wrap an existing one"

and this error in seed-3.2.0, complete with segfault:

CRITICAL **: Struct/union of type: TargetList has size 0 in
introspection data. Please check GIR
Segmentation fault

I don't mind re-implementing this in python but I suspect python users
using the introspection bindings (rather than the old pygtk bindings)
are going to have the same problem.  Do you think so?

I have to say that I have had less than stellar results with gobject
introspection.  I have noticed that the asynchronous line reading
functions of Gio.DataInputStream are busted in
gobject-introspection-1.30.0, about which a bug report seems to have
been ignored.  Every new release brings a game of chase, some of which
have work arounds and some of which (like this one) appear not to.
gobject-introspection-0.10 seems to be more reliable but unfortunately
gnome-3.2 requires the later version.

A naive observer might conclude that as long as gobject-introspection
provides the calls that gnome-shell needs, then it is ready for release:
whether the remainder of the bindings work seems to be a matter of
chance.

Chris



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]