IRC channel logs

2019-12-31.log

back to list of logs

<str1ngs>hello daviid when you have time can you look at this <gtk-application> example when you have time.http://paste.debian.net/1123263 mainly the 'key-press-event issue
<str1ngs>daviid: and also the application property for <gtk-application-window> does not seem right. I can put smaller example together if you like.
<str1ngs>daviid: my paste was truncated please use http://paste.debian.net/1123264 instead
<daviid>str1ngs: will look at it asap
<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
<str1ngs>is the best method?
<str1ngs>use a 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>np"
<daviid>np!
<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
<daviid>what is the enum lib name?
<alextee[m]>oh wow theres glib/gtk in guile
<str1ngs>daviid: say GApplicationFlags found in Gio IIRC
<daviid>alextee[m]: guile-nome is almost 20y old :):)
<alextee[m]>wow
<daviid>str1ngs: when in doubt, you can always 'cache show' was has been imported and define
<daviid> (gi-cache-show 'flag)
<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
<str1ngs>alextee[m]: welcome then :)
<alextee[m]>:D
<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 ...
<daviid>*just make sure ...
<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>:) you're welcome
<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.
<str1ngs>err gdk-event*
<str1ngs>s/once/one