David Kaplan wrote: > Hi, > > Actually your question is a good one. One of the reasons I never > finished adding an option to text objects to rotate with respect to the > plot (is this the correct terminology?), not the screen, is that I > wasn't sure of the best way to implement this without making it > hopelessly confusing for the user. > > One way is to add a boolean that tells the text object whether or not > the angle is with respect to screen coordinates. In this case, > text_obj.get_rotation() would return the angle in whichever coordinate > system is the active one based on the boolean, unless an option to > get_rotation is specified that would force the angle to the screen > coordinate system (this option would then be used by show methods to > assure they get the correct angle for plotting on the screen). > Similarly, set_rotation would set the angle in the active system. The > disadvantage of this approach is that it can be pretty confusing - > unless you consult the boolean, you don't know what your angle is > measured relative to. > > Another approach would be to add a ._rotationPlot variable, as well > as .get_rotationPlot and .set_rotationPlot text-object methods. In this > case, using set_rotation would set the "active" angle to be the screen > angle, while using set_rotationPlot would set the "active" angle to be > the plot angle. The non-active angle would be set to None and show > calls would test for whether or not ._rotation is none, in which case > the screen angle would be calculated from the transform. In this case, > get_rotation and get_rotationPlot would return angles in the respective > system, regardless of which one is "active". > > What structure would people prefer? > I think the latter choice presents less confusion, particularly after hearing your arguments. It should probably be rotation_plot, just to be consistent with other getters/setters. There should probably also be a check and warning for setting rotation_plot for figure text, where it doesn't make sense, and fall back to the identity transform. > Another reason I never finished this is that I got confused by some of > the code - there was talk of unitful and unitless rotations and > coordinates. Hopefully someone else has some guidance on unit-related issues. I still don't have my head around that stuff. > Also, I wasn't sure what to do with objects that inherit > the text object class - namely, text with a dash. It didn't seem it was > worth adding this non-screen rotation functionality to these objects. > What is the argument against? It seems like this would be straightforward (at least from the outside). But I'm probably missing something. > If anyone can point me in the right direction on these points, I will > try to finish a patch for this functionality. > Thanks.
Mike > Cheers, > David > > On Wed, 2008-11-05 at 10:28 -0500, Michael Droettboom wrote: > >> Darn clogged e-mail queue! ;) >> >> I see you've already addressed my question... >> >> Cheers, >> Mike >> >> David Kaplan wrote: >> >>> Hi, >>> >>> I just wanted to send a note saying that I committed an additional >>> method to the Transforms class that transforms angles. The basic idea >>> is to transform an angle at a point to a new angle at the corresponding >>> point in the transformed coordinate system. The included method is >>> generic and should work well for almost any transform provided that the >>> spatial scale isn't too small or too large. Much faster algorithms that >>> would work regardless of spatial scale can be found for particular >>> transforms, particularly affine transforms, but I haven't added these >>> yet. >>> >>> I also added an example script that shows how to use this method to plot >>> text rotated so that it aligns with a line in a figure >>> ( text_rotation_relative_to_line.py ). >>> >>> I initially intended to use this method to give text objects the option >>> to be rotated with respect to the plot coordinate system (as opposed to >>> the screen coordinate system), but I haven't gotten around to finishing >>> this yet. >>> >>> Cheers, >>> David >>> >>> >>> >>> -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
