<daviid>rotty1: it's a very simple struct: <daviid>but I cano find any similar example in previous binding, the only occurences of CLUTTER_PARAM_SPEC in cluter-1.12.2.h|c files are clutter-units.h and clutter-color.h <daviid>but all marked as to be ignored in gw/overrides subdirs. <rotty1>daviid: hmm, can't answer off-hand -- I'd start by putting some debugging print statements into h2def.py:find_obj_defs <rotty1>although, it looks like h2def.py isn't supposed to handle non-GObject structs <daviid>yeah, I'm a bit lost I must admit <daviid>I don't get the picture because I can't find any example [previous] <daviid>h2def.py proper extract clutter_param_spec_color [a function] but it is marked as ignore later on [which is done manually] <daviid>looking to guile-gnome, the warning gets printed by ./glib/gnome/gobject/gparameter.c: g_warning ("param type not implemented: %s", <daviid>but the question is should I have to manually wrap that struct ? <daviid>rotty1: ^^ [thanks for responding, I understnbd it's old matters but that's what we have ...] <daviid>I'm ready to release guile-clutter-1.12.2 if I solve this problem/warning <rotty1>do you have any (other) examples of bindings making use of GParamSpec? <daviid>rotty1: I can't find another, the only would be CLUTTER_PARAM_SPEC_UNITS, in CLUTTER_PARAM_SPEC_UNITS, but marked as 'ignored' [all unit related type functions and methods] <daviid>rotty1: here, line 418, you see all param_spec being marked as ignore <daviid>maybe GParamSpec types must always be manually defined, don't know <daviid>rotty1: maybe i can find an example in guile-gnome <daviid>./defs/gnome/defs/gtk.defs: (return-type "GParamSpec*") <daviid>no, all are funcytions or methods <daviid>rotty1: at this point, I still don't understand how GParamSpec types are created, and still could not find an example, neithe a guile-gnome nor a guile-clutter <rotty1>I must admit that I'm totally unfamiliar with Clutter, and my g-wrap/guile-gnome hacking days are far back -- and I also don't see what GParamSpec/ClutterParamSpecColor are actually used for <daviid>A GParamSpec subclass for defining properties holding a ClutterColor. <rotty1>yeah, it looks like you'd use it if you'd define a GObject which had a ClutterColor as property <daviid>since 1.0 [extract from the manual 1.12.2] [i don't have a link because i installed it locally as part of 1.12.2, don't even know if it exists still on their web pages <rotty1>but I can't find (at a cursory glance) an instance of that happening in clutter <daviid>honestly I think I can safely ignore this warning, but I really would like to understand and get rid of any warnings for users <daviid>my g-wrap, C and goject knowledge is very very low as well, and I regularly get traped into other things to do, hence it seems I have to learn it again ... <daviid>if I could find a single GParamSpec type properly binded either in guile-gnome or guile-clutter I could study and reproduce <daviid>but i see all sort of functions returning (return-type "GParamSpec*"), such as gtk_container_class_find_child_property, but not a single GParamSpec subclass binding example <daviid>clutter-color.h defines it like this: <daviid>#define CLUTTER_PARAM_SPEC_COLOR(pspec) (G_TYPE_CHECK_INSTANCE_CAST ((pspec), CLUTTER_TYPE_PARAM_COLOR, ClutterParamSpecColor)) <rotty1>daviid: I have that open in emacs already <rotty1>seems the perl guys have done something about it... <daviid>rotty1: don't anything about perl. but do you think it should be wrapped manually ? <daviid>and someone says ClutterColor is a struct, I think you need a param spec to use that as a property <rotty1>I think param specs are used to specify the type (and name, blurb, decription) of GObject properties <rotty1>ClutterColorParamSpec allows to additionally specifying a default value <rotty1>in guile-gnome:glib/gnome/gobject/gparameter.c, there seeems to be support for a fixed list of GParamSpec subtypes <daviid>ah, that would make sence toi have to do something for clutter [manually] then <daviid>and yes I agree with you for the explanation <rotty1>I'd look/ask for a concrete usage example of ClutterColorParamSpec (i.e. some library defining objects with such a property) and then, based on that try construct a minimal test case inside the clutter bindings, and make it work <daviid>the funny thing is that implementing their grid example using guile-clutter, it raises the warning, but I can't figure out why in this example and not the others, since the grid exaple uses grid-layout [since 1.12] and has nothing to do with colours [but of course I create a stage, an actor which has a grid-layout ... so somewhere in that example it triggers the use <daviid>I'm about to release clutter examples as well, but there are quite complex and I don't have a snipset to paste right now <daviid>but basically, (define-class <clus-grid> (<clutter-actor>) ...) which then initializes as this <daviid>(define-method (initialize (self <clus-grid>) initargs) (let ((grid-layout (make <clutter-grid-layout>))) ... (set-layout-manager self grid-layout))) <daviid>rotty1: so it appears something is triggerd when the layout manager of the actor is a grid-layout, but not when using previ0us layout such as bin-layout ... <daviid>rotty1: even if they paste a link with a concrete example, I still have to undsrstand how to implement ClutterParamSpec in general, and ClutterParamSpecColor in particular, suggestion super mnore then welcome <daviid>rotty1: do you have a working guile-clutter [cone from clutter-devel I mean]? <daviid>also, to compile the latest you will have to compile/install cogl and clutter 1.12.2 [from a git clone; git checkout 1.12.2 from the clutter project itself ... not exactly a peice of cake <rotty1>ah sorry, I'd read 'clutter'. I guess it's time for bed... <daviid>sure! i was curious, thanks a lot for your help <daviid>better to wait a couple of days still, guile-clutter, I have commits to push ***michel_mno is now known as michel_mno_afk
<taylanub>I thought this was impossible when I pondered on it a year or two ago, but I finally found a way using procedural macros to make a syntactic API from the procedural API of my bytestructures. this means all bytevector offset calculation can be done at compile-time, just like a static type system :) <taylanub>of course it's a limited form of the procedural API, but these are limitations inherent to syntactic APIs (no access to run-time data) ***michel_mno_afk is now known as michel_mno
***michel_mno is now known as michel_mno_afk