|
|
Ian
This was plenty helpful . Thank you !
I noticed that some drawing functions do not care about the current transform. I think fl_pie() is one of them. A fl_translate() call before it does not seem to affect the origin so i think will follow your method here by adding xo and yo to the parameters. I did not know about the FLUID part so i will definitely explore that.
Will check out Greg's widget too. sure there is a lot to learn there
Thanks again On Tuesday, May 25, 2021 at 5:06:12 AM UTC-4 Ian MacArthur wrote:
On Tuesday, 25 May 2021 at 07:31:02 UTC+1 fmeg... wrote:
Is this the default behavior ? i thought that the draw function uses the widgets 0,0 and not the window. do i need to explicitly call the x() and y() in the custom draw() function and apply transforms and/or offsets to correct this ?
Yes, all fltk drawing (in the 1.x series) is Window Relative, not Widget Relative.
The adjustment I usually use is, at the start of my draw() methods, do:
int xo = x(); int yo = y();
The add (xo, yo) to the root of any integer drawing I do.
I think, if you use fluid to generate a derived widget, you can also ask it to do that offsetting for you.
Or you can use the transform based drawing methods of course, which are handy for more complex scenes but can be slower than the basic integer methods, of course.
Greg as a nice demo of an Aircraft Altimeter widget here: Which I think embraces these issues (though TBH it is probably more elaborate than you really needs, since Greg was attempting to illustrate some more "advanced" techniques with that demo...)
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/144485c6-7fbf-49bd-a7ba-9f78effa5e7cn%40googlegroups.com.
[ Direct Link to Message ] | |
|
| |