IRC channel logs


back to list of logs

<daviid>rotty1: it's a very simple struct:
<daviid>struct ClutterParamSpecColor {
<daviid> ClutterColor *default_value;
<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
<rotty1>although, it looks like 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> 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>struct ClutterParamSpecColor {
<daviid> ClutterColor *default_value;
<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>me neither
<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>rotty1: here is a copy of clutter-color.h, it is small
<rotty1>daviid: I have that open in emacs already
<daviid>ah, ok, sorry
<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>[ I just asked on #clutter ]
<daviid>rotty1: do you have a working guile-clutter [cone from clutter-devel I mean]?
<rotty1>I've "apt-get source"-ed it
<daviid>it's not on debian
<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...
<rotty1>(2:30 am here)
<daviid>sure! i was curious, thanks a lot for your help
<daviid>let's talk later ... good night
<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
<dsmith-work>Wednesday Greetings, Guilers
***michel_mno is now known as michel_mno_afk
<stis>evening guilers!