Closed davisford closed 12 years ago
It must have something to do with the order of operations as plugins are called.
If I do this in my application code (outside any plugin) after the graph has rendered: console.log(plot.getAxes().xaxis.ticks)
the ticks are there, but when your plugin is executed in the chain the ticks have not been initialized yet. Any idea why?
Hm I can't reproduce this. Are you using other plug-ins? In what order are they loaded? Can you give me more code, or can you reproduce this using one of the stock flot examples? I tried including tickrotor and adding your options to the timezones.html example, and it worked fine. Well, the positioning and scaling was a bit off, but this is a known issue. There were no JS errors.
I am using other plugins. They are loaded in this order:
I'll see if I can reproduce the problem with one of the examples, but in order to make forward progress, I took an alternative path. I noted that there were some pull requests that added label angle support. I forked flot/flot myself davisford/flot and I used the code in those pull requests -- now my trunk davisford/flot has your last commit, and the label angle support, so I may be all set for now.
But if I can reproduce the issue with an example, I'll let you know. Seems like there might be something funny going on with order of execution.
Hm still working after including all those plug-ins in the timezones example. This is doubly weird because the draw hook, in which the tickrotor code executes, is called after the ticks are set. It's like something is clearing the ticks ahead of tickrotor executing... very strange.
In any case, I think tick rotation, along with most things related to the displaying of ticks, is something that belongs in the main flot code eventually. Which pull request did you use, and does it work well?
Hi Mark, here's my branch with the single commit I made that incorporates several pull requests off the main flot/flot.
https://github.com/davisford/flot/commits/master
The last commit is my only commit -- so far it is working well for me. Here's a screen-shot
I hand-merged most/all of the pull requests seen here: https://github.com/flot/flot/pull/15. Once I forked flot/flot, I couldn't seem to deduce how to get at the pull requests. When you fork a repo, you lose the history on the pull requests it seems. Is it possible to get at a master repo's pull requests after you fork?
This solution is indeed a lot cleaner than my plug-in. I'll look into merging it in at some point.
As for pull requests, no, I don't think you can automatically apply pull requests from another fork into your own. I think you'd just have to grab the diff and merge it yourself, probably as you were already doing.
Ok, thanks Mark. I'll just close this issue, as I've got my workaround. If you do end up merging the label rotation pull requests in, I'll revert my local commit and fetch upstream, or just switch back to flot/flot proper.
Thanks for filling the void on the flot maintenance, by the way. It is such a great library - so much versatility. We need to keep it going. I may be able to help down the road a bit if you need it.
FYI, I found two interesting solutions to the fork/pull problem posted as answers on this SO question:
http://stackoverflow.com/questions/8891339/github-how-to-add-open-pull-requests-to-local-repo
Two different solutions to the same problem:
That would have been easier than what I did :) Live and learn...as they say.
I'm using your last commit to flot/flot https://github.com/flot/flot/commit/854292986d9177e41799b1dc610c9eb78956d04e and I tried this plugin, but it blows up on line 100 because
ticks = plot.getAxes().xaxis.ticks;
returns undefined, and then you try to use it here:In my flot options object, I have this specified: