<str1ngs>daviid: and also the application property for <gtk-application-window> does not seem right. I can put smaller example together if you like. <sneek>Welcome back daviid, you have 1 message. <sneek>daviid, str1ngs says: no problem. will test this out. <str1ngs>daviid: thank you. the important issue is 'key-press-event but I am concerned about the #:application property form a GC and memory safety standpoint. ***jao is now known as Guest52228
***ng0_ is now known as ng0
<roelj>Is there some kind of static-analysis tool for Guile to spot unnecessary “use-module” declarations? <daviid>str1ngs: so, (a) key-press-event signals receive (among other things) and event argument, which are GdkEvent instances, and GdkEvent is a union type, described in GI using GIUnionInfo, which are mising and I am working on this with 'high priority', as I did mention to you when pasting the 'hello world' example a few days ago <daviid>(b) the <gtk-application-window> #:application init-keyword is indeed mandatory at make time, since it is mandatory argument of the gtk_application_window_new ... you can(should) use (!g-inst app) - accessors are compiled - instead of (slot-ref ...) - slot-ref is interpreted <mwette>roelj: I don't know, but that sounds useful; like a guile-lint; maybe one could compile to tree-il and check that code <str1ngs> daviid ah I did not realize that the GdkEvent issue might be somehow related to events being remove. as long as you are aware. thanks <str1ngs>err event removable caveat you mentioned I meant <str1ngs>daviid: just to clarify the issue with the property is not so much it requirement as I'm concerned that using the g-inst pointer. using a goops class just seems safer, but if you deem it safe I'm okay with that. I would use gtk-application-new but this is being used in an inherited class so it's easier to a property. unless of course I could use g-object-new or g-golf providing gtk_application_init hierarchy. I'm thinking the property <daviid>both will return a goops instance, but i'd rather always use the goops interface rather then the 'contructor' provided by the gnome lib you're using - all will return goops instances ... <daviid>there is no problem refering to the g-inst slot of a goops instance classs, and in this particular case, you have to anyway, this is not g-golf, this is the gtk-application protocl <str1ngs>I agree, apologies I'm still translating from C scheme. good to hear about reference g-inst as needed. <daviid>you should never ever have to use g-object-new <str1ngs>one other thing and I apologize for this because you mentioned it already. can you point in the manual how to use an enumerator again. the only example can't think of a simple example right now sorry <str1ngs>example as in a simple use case function <str1ngs>daviid: say GApplicationFlags found in Gio IIRC <daviid>alextee[m]: guile-nome is almost 20y old :):) <daviid>str1ngs: when in doubt, you can always 'cache show' was has been imported and define <RhodiumToad>alextee[m]: guile-gnome works as long as you avoid idle and timeout events (those tend to crash it) <daviid>str1ngs: then you may -ref those like this: (gi-cache-ref 'flag 'g-application-flags) <str1ngs>daviid: also for C classes I generally use private struct members for widget building and reference. where I would init those then in the GOjbects init function. with g-golf I have replicated this by using initialize in conjunction with (next-method) then I initialize set and initialize the slots there. I think this is pretty safe from a goops perspective. does the method seem okay to you? <str1ngs>daviid: thanks for the enumerator snippet I will write this down this time. <str1ngs>also noted I need move this to using the setter not slot-set, thanks for that tidbit <daviid>alextee[m]: i have no idea why you didn't know about guile-gnome, guile-clutter, but anyway, there are two 'modern' gnome bindings projects, under active development, guile-gi and g-golf *alextee[m] has never used guile before besides writing guix package definitions <daviid>alextee[m]: it's ok, i did ask becaue of the way you wrote about this, as if you did search and did not find ... <daviid>str1ngs: i don't understand the question about 'C classes ...' <alextee[m]>daviid: im just surprised at how many languages gnome/gtk has been ported into <daviid>alextee[m]: fwiw, gnome is not 'ported' into a language, but rather, languages do bind the GObject Introspection api, then can instantenaously provide access to any GI typelib ... <str1ngs>daviid: I did not have explained will let me rephrase. for inherited g-golf goops classes is it safe to set slots with new gopps classes within initialize? <alextee[m]>yeah i remember seeing something like that in the guides. that's pretty cool <daviid>str1ngs: it's ok, kust make sure not to 'hide' users provided init-keyword value for those slts then ... <str1ngs>daviid okay that makes sense. also are you open to contributed examples? if so would you prefer in texinfo? or maybe something like ./contrib/examples? <str1ngs>./contrib/examples would be easier for me texinfo is kinda a learning curve I've been avoiding <daviid>str1ngs: in the near future 'maybe', but not now - what i am interested in, now, is to have you as a user <str1ngs>understandable, I have some examples here that I've been refining mayb later when you are not busy with more important things we can revisit. <str1ngs>daviid: I think g-golf signals was my best holiday present. thanks again. <daviid>tx for the nice words ... i should have those event (gdk-event) working soon as well <str1ngs>no problem. the gdk-even I can work around meantime so it's not a huge rush. I can create typelib function to setup up that once signal. it's not ideal but it's not a huge blocker either.