Manuel and Michael worked on fixing a bug with TextWithDash, but this introduced a bug will all tick labels so I reverted the changes. The problem is that the text layout code in Text (eg draw, get_window_extent) is using "get_position" which in TextWithDash is the dash position, according to the doc string and the original impl. On the branch, the draw and layout methods of Text use _get_xy_display which TextWithDash overrides. That is why it works on the branch and not the trunk. The changes of M&M to make set_position and get_position refer to the x and y locs fixed dash with text for reasons that are not completely clear t me, but broke tick labels which are also TextWithDash instances. I did not write TextWithDash so cannot vouch for its conventions, but I don't have time to dig deeply enough right now to fix this, so I wanted to revert the changes so regular plots would work again and give a head's up here so Manuel, Michael and I would not be doing and undoing each other's changes w/o some understanding of where the discerpancy was arising. Thanks, JDH
John Hunter wrote: > Manuel and Michael worked on fixing a bug with TextWithDash, but this > introduced a bug will all tick labels so I reverted the changes. The > problem is that the text layout code in Text (eg draw, > get_window_extent) is using "get_position" which in TextWithDash is > the dash position, according to the doc string and the original impl. > On the branch, the draw and layout methods of Text use _get_xy_display > which TextWithDash overrides. That is why it works on the branch and > not the trunk. The changes of M&M to make set_position and > get_position refer to the x and y locs fixed dash with text for > reasons that are not completely clear t me, but broke tick labels > which are also TextWithDash instances. > > I did not write TextWithDash so cannot vouch for its conventions, but > I don't have time to dig deeply enough right now to fix this, so I > wanted to revert the changes so regular plots would work again and > give a head's up here so Manuel, Michael and I would not be doing and > undoing each other's changes w/o some understanding of where the > discerpancy was arising. Hm, the patch I applied was exactly because I got also problems with the tick labels -- they were all squashed to one place -- and I thought to have fixed that. Now, it seems this wasn't quite correct ;-) As I have also no deeper understanding what's _really_ going on in TextWithDash, I will now better keep my hands off TextWithDash ... Manuel > Thanks, > JDH > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Hate to say "me too", but I don't really understand text with dash either... I'll have a look when I have adequate time to devote to it, if no one else volunteers. Cheers, Mike Manuel Metz wrote: > John Hunter wrote: > >> Manuel and Michael worked on fixing a bug with TextWithDash, but this >> introduced a bug will all tick labels so I reverted the changes. The >> problem is that the text layout code in Text (eg draw, >> get_window_extent) is using "get_position" which in TextWithDash is >> the dash position, according to the doc string and the original impl. >> On the branch, the draw and layout methods of Text use _get_xy_display >> which TextWithDash overrides. That is why it works on the branch and >> not the trunk. The changes of M&M to make set_position and >> get_position refer to the x and y locs fixed dash with text for >> reasons that are not completely clear t me, but broke tick labels >> which are also TextWithDash instances. >> >> I did not write TextWithDash so cannot vouch for its conventions, but >> I don't have time to dig deeply enough right now to fix this, so I >> wanted to revert the changes so regular plots would work again and >> give a head's up here so Manuel, Michael and I would not be doing and >> undoing each other's changes w/o some understanding of where the >> discerpancy was arising. >> > > Hm, the patch I applied was exactly because I got also problems with the > tick labels -- they were all squashed to one place -- and I thought to > have fixed that. Now, it seems this wasn't quite correct ;-) > As I have also no deeper understanding what's _really_ going on in > TextWithDash, I will now better keep my hands off TextWithDash ... > > Manuel > > >> Thanks, >> JDH >> >> ------------------------------------------------------------------------- >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <md...@st...> wrote: > Hate to say "me too", but I don't really understand text with dash > either... I'll have a look when I have adequate time to devote to it, > if no one else volunteers. Daishi, I don't know if this is still the right email address for you, but if so could you let us know if you could look at the TextWithDash implementation in matplotlib svn trunk. Our transformations have undergone a bit of refactoring, and some relatively minor changes were made in the Text base class positioning code, but these were enough to break the TextWithDash layout. Let us know if you have a minute to look at this and perhaps provide a patch to bring TextWithDash functionality back. Thanks, JDH
On Monday 30 June 2008 09:06:59 am John Hunter wrote: > On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <md...@st...> wrote: > > Hate to say "me too", but I don't really understand text with dash > > either... I'll have a look when I have adequate time to devote to it, > > if no one else volunteers. > > Daishi, > > I don't know if this is still the right email address for you, but if > so could you let us know if you could look at the TextWithDash > implementation in matplotlib svn trunk. Our transformations have > undergone a bit of refactoring, and some relatively minor changes were > made in the Text base class positioning code, but these were enough to > break the TextWithDash layout. Let us know if you have a minute to > look at this and perhaps provide a patch to bring TextWithDash > functionality back. Daishi's original contribution of TextWithDash used delegation, which was causing some trouble with object introspection and the dynamically generated list of properties. I refactored his work way back in March 2006, svn 2226: http://sourceforge.net/mailarchive/message.php?msg_id=200603211837.28678.dd55%40cornell.edu Sorry I'm just now getting to this thread. I recall the behavior of get_position referring to the dash position was strange for a subclass of Text, but this was simply a continuation of the original implimentation. I was only concerned with exposing all of TextWithDash's methods to object introspection when I made my contribution. I also recall seeing strange behavior like what Manuel posted. I'll have a look when I get a chance, hopefully this evening.
On Monday 30 June 2008 10:40:27 Darren Dale wrote: > On Monday 30 June 2008 09:06:59 am John Hunter wrote: > > On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <md...@st...> wrote: > > > Hate to say "me too", but I don't really understand text with dash > > > either... I'll have a look when I have adequate time to devote to it, > > > if no one else volunteers. > > > > Daishi, > > > > I don't know if this is still the right email address for you, but if > > so could you let us know if you could look at the TextWithDash > > implementation in matplotlib svn trunk. Our transformations have > > undergone a bit of refactoring, and some relatively minor changes were > > made in the Text base class positioning code, but these were enough to > > break the TextWithDash layout. Let us know if you have a minute to > > look at this and perhaps provide a patch to bring TextWithDash > > functionality back. > > Daishi's original contribution of TextWithDash used delegation, which was > causing some trouble with object introspection and the dynamically > generated list of properties. I refactored his work way back in March 2006, > svn 2226: > http://sourceforge.net/mailarchive/message.php?msg_id=200603211837.28678.dd >55%40cornell.edu > > Sorry I'm just now getting to this thread. I recall the behavior of > get_position referring to the dash position was strange for a subclass of > Text, but this was simply a continuation of the original implimentation. I > was only concerned with exposing all of TextWithDash's methods to object > introspection when I made my contribution. I also recall seeing strange > behavior like what Manuel posted. I'll have a look when I get a chance, > hopefully this evening. I *think* I found a simple fix: use the Text._x and ._y directly in draw, rather than get_position which refers to the text position in Text and the Dash position in TextWith Dash (thank you for pointing this out, John). Please let me know if something is still amiss, svn 5701. I had another working solution which let get/set_position refer to the text position, and added get/set_dashposition. I didn't like it as much, because the text position could be set by the user and would then be overridden by update_coords. But maybe it was a more coherent way to do it. set_position could recalculate the dash length, and set_dashlength/pad/push would recalculate the text position. (The dash position is always the reference.) I think it might be more trouble than its worth, it would take a lot of work and would cause API breakage. Darren
Darren Dale wrote: > > On Monday 30 June 2008 10:40:27 Darren Dale wrote: >> On Monday 30 June 2008 09:06:59 am John Hunter wrote: >>> On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <md...@st...> > wrote: >>>> Hate to say "me too", but I don't really understand text with dash >>>> either... I'll have a look when I have adequate time to devote to it, >>>> if no one else volunteers. >>> Daishi, >>> >>> I don't know if this is still the right email address for you, but if >>> so could you let us know if you could look at the TextWithDash >>> implementation in matplotlib svn trunk. Our transformations have >>> undergone a bit of refactoring, and some relatively minor changes were >>> made in the Text base class positioning code, but these were enough to >>> break the TextWithDash layout. Let us know if you have a minute to >>> look at this and perhaps provide a patch to bring TextWithDash >>> functionality back. >> Daishi's original contribution of TextWithDash used delegation, which was >> causing some trouble with object introspection and the dynamically >> generated list of properties. I refactored his work way back in March 2006, >> svn 2226: >> http://sourceforge.net/mailarchive/message.php?msg_id=200603211837.28678.dd >> 55%40cornell.edu >> >> Sorry I'm just now getting to this thread. I recall the behavior of >> get_position referring to the dash position was strange for a subclass of >> Text, but this was simply a continuation of the original implimentation. I >> was only concerned with exposing all of TextWithDash's methods to object >> introspection when I made my contribution. I also recall seeing strange >> behavior like what Manuel posted. I'll have a look when I get a chance, >> hopefully this evening. > > I *think* I found a simple fix: use the Text._x and ._y directly in draw, > rather than get_position which refers to the text position in Text and the > Dash position in TextWith Dash (thank you for pointing this out, John). Please > let me know if something is still amiss, svn 5701. > > I had another working solution which let get/set_position refer to the text > position, and added get/set_dashposition. I didn't like it as much, because > the text position could be set by the user and would then be overridden by > update_coords. But maybe it was a more coherent way to do it. set_position > could recalculate the dash length, and set_dashlength/pad/push would > recalculate the text position. (The dash position is always the reference.) I > think it might be more trouble than its worth, it would take a lot of work and > would cause API breakage. With that patch everything is working for me: dashpointlabel is working, tick labels are also correctly drawn, and the dashtick example now also works fine again (both GUI and png output) ! Manuel > Darren > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
On Mon, Jun 30, 2008 at 6:34 PM, Darren Dale <dsd...@gm...> wrote: > I *think* I found a simple fix: use the Text._x and ._y directly in draw, > rather than get_position which refers to the text position in Text and the > Dash position in TextWith Dash (thank you for pointing this out, John). Please > let me know if something is still amiss, svn 5701. That seems like an easy enough fix, and my simple tests are working fine, but it speaks well of you that you found it, because the dash with text innards are sufficiently confusing that it left Michael, Manuel and I scratching our heads. All the better because my email to Daishi bounced. Thanks, Darren. JDH