gtkDcoding Blog Post for 2019-03-29 - Grid
I'm having trouble replying to the thread I usually use, so... There's a new tutorial for using a GTK Grid. You can find it here: http://gtkdcoding.com/2019/03/29/0022-grids.html
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On Friday, 29 March 2019 at 14:25:16 UTC, Ron Tarrant wrote: I'm having trouble replying to the thread I usually use, so... There's a new tutorial for using a GTK Grid. You can find it here: http://gtkdcoding.com/2019/03/29/0022-grids.html Have shared gtkdcoding.com with some folks and they like it, keep it coming!!
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On Friday, 29 March 2019 at 14:25:16 UTC, Ron Tarrant wrote: I'm having trouble replying to the thread I usually use, so... There's a new tutorial for using a GTK Grid. You can find it here: http://gtkdcoding.com/2019/03/29/0022-grids.html I really wish you would start taking screenshots! It is not hard!
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On Friday, 29 March 2019 at 16:21:59 UTC, aberba wrote: Have shared gtkdcoding.com with some folks and they like it, keep it coming!! Cool. Thanks, aberba.
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On Friday, 29 March 2019 at 20:34:32 UTC, Michelle Long wrote: I really wish you would start taking screenshots! It is not hard! You still think this is about me not knowing how to take a screenshot? :) I guess you didn't read my reply to your last request.
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On Friday, 29 March 2019 at 14:25:16 UTC, Ron Tarrant wrote: There's a new tutorial for using a GTK Grid. You can find it here: http://gtkdcoding.com/2019/03/29/0022-grids.html Thanks! The first link in the blog post to '..the last blog post' links to the 0022 article itself, not to a previous one. BTW, it compiles fine without 'import gtk.c.types', too. Main.d (and maybe others) contains a 'public import gtk.c.types;'
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On Saturday, 30 March 2019 at 10:19:15 UTC, number wrote: The first link in the blog post to '..the last blog post' links to the 0022 article itself, not to a previous one. Corrected. BTW, it compiles fine without 'import gtk.c.types', too. Main.d (and maybe others) contains a 'public import gtk.c.types;' Thanks for catching that. I've made the following changes: - removed all import gtk.c.types statements, - added a comment below the import statement block stating which flags are brought in from c.types, - rewrote all coverage of examples to reflect the above points.
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
Today's the day for (yet) another blog post over on gtkDcoding.com and the subjects are: - the RadioButton, and - the ColorButton. You can find it here: http://gtkdcoding.com/2019/04/02/0023-radio-and-color-buttons.html
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On Tuesday, 2 April 2019 at 11:31:39 UTC, Ron Tarrant wrote: Today's the day for (yet) another blog post over on gtkDcoding.com and the subjects are: - the RadioButton, and - the ColorButton. You can find it here: http://gtkdcoding.com/2019/04/02/0023-radio-and-color-buttons.html Thank you! But if we want one of the others to be active on start-up, as well as syncing up the observed object, we have to call that button’s setActive(true) function. To simplify this two-step process, I broke it out into its own function, setActiveButton(). The function ignores its argument and always uses member variable button2 instead. Changing the parameter type to MyRadioButton and using 'button' instead of 'button2' in the body works, so you could pass another default in RadioBox.this(). Can somebody explain why getRgba() (apparently inherited from ColorChooser) does take an out parameter instead of returning an Gdk.RGBA?
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On Tuesday, 2 April 2019 at 14:13:09 UTC, number wrote: Thank you! You're welcome. :) The function ignores its argument and always uses member variable button2 instead. Changing the parameter type to MyRadioButton and using 'button' instead of 'button2' in the body works, so you could pass another default in RadioBox.this(). Thanks for catching my typos. I gotta stop messing with the code once it's working. :) Fixes are uploaded. Anyway, you can also declare it as a RadioButton and that works, too... as long as the variables inside the function are changed to 'button.' Can somebody explain why getRgba() (apparently inherited from ColorChooser) does take an out parameter instead of returning an Gdk.RGBA? My understanding is this: Returning an object (as opposed to a single value) means returning a pointer rather than the entire object. And the object will cease to exist once the function returns because the scope no longer exists. So, it follows that an out variable passed in will preserve the object itself once program control returns to the caller.
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On 02-04-2019 17:48, Ron Tarrant wrote: On Tuesday, 2 April 2019 at 14:13:09 UTC, number wrote: Can somebody explain why getRgba() (apparently inherited from ColorChooser) does take an out parameter instead of returning an Gdk.RGBA? My understanding is this: Returning an object (as opposed to a single value) means returning a pointer rather than the entire object. And the object will cease to exist once the function returns because the scope no longer exists. So, it follows that an out variable passed in will preserve the object itself once program control returns to the caller. While that would be true for things that live on the stack, this is not the case for RGBA. The C version of getRgba uses the "out" parameter so you can pass in a existing GdkRgba, even tough that would make it more like ref. This doesn't make sense for the d binding since you will always get a new RGBA passed through the out parameter. -- Mike Wey
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On Tuesday, 2 April 2019 at 18:27:10 UTC, Mike Wey wrote: While that would be true for things that live on the stack, this is not the case for RGBA. The C version of getRgba uses the "out" parameter so you can pass in a existing GdkRgba, even tough that would make it more like ref. This doesn't make sense for the d binding since you will always get a new RGBA passed through the out parameter. Glad you're around to step in when I don't really understand what's going on, Mike. Thanks for clearing this up. :)