[matplotlib-devel] matplotlib-grayscale
moved from matplotlib-users: http://sourceforge.net/mailarchive/forum.php?thread_name=CAN06%3DCx2zgh8YrnF2WRaJ%3D0E8i3ROLdYW4VuurtqKrx3mdkeEg%40mail.gmail.com&forum_name=matplotlib-users On 10/22/2011 09:31 AM, Friedrich Romstedt wrote: > 2011/10/21 Friedrich Romstedt: >> I will try to dig out that emails. > > Did that, the email I meant dates back to 10 November 2010! Here's the > snippet: > > > > (Ben Root): >> I am curious, could this approach you have done be generalized to any sort >> of color transformation? Admittedly, a gray mode is probably the most >> common request, but what if someone wants a different transformation? Maybe >> even apply a filter that would produce sepia colors, or high-contrast >> colors, or a different grayscale transform? Heck, I could imagine a use >> where a user might want to do a color substitution? > > Oh Yes, this is *ealily* possible. The new framework in the > ColorConverter class just uses a filter function, if we want to see it > like that, already. It's just the apply_rc_gray_setting() function or > sth like that. If you want to, you can try to add the functionality. > But we should discuss beforehand how to design it. There are several > possibilites. In fact, I like this filter function quite a lot! > > 1) Hardcoding other filters in ColorConverter (what a decent name!), > and switching them on or off > 2) Inserting filters as functions on runtime into the ColorConverter > instance, some hooking mechanism > 3) Providing a dedicated Filter class, that can be fed to > set_filter() instead of set_gray(). This I like best. > > I will, when i find some time, first implement the propagation of gray > settings by allowing objects in set_gray(). Might be a good time to > rename it to set_filter() right away, or maybe not do it, if > set_gray() goes in, and expects a bool, it might break compat when > changing the argument spec later. So later set_gray() would just call > set_filter() or add_filter() or whatever. > > > > So the filter idea was Ben's idea. I still like idea (3) for the > design best. I will check if it is possible to inject the filter code > into the renderer framework, since all colour settings arguments > somewhen flow into a call into the renderer. Pro: No rcParams > addition necessary, no modification of the peculiar colors.py > ColorConverter framework necessary, just leaving those things > untouched and hence no worries and headaches about them. No disabling > of higher-level caching and at the same time negligible small impact > if there is no filter active. Con: I don't know yet if it works. I > vaguely remember there were some problems when I checked that > possibility last time (with pixmaps or something like that). I think > I will find out soon enough. > > Eric, Ben, do you think we should go off-list with this now? I would > prefer on-list now. There might be people following but not > responding. > > Friedrich Friedrich, The matplotlib-devel list is really the place for this, and I think that it will be very helpful to move the discussion there. So, I am doing that now by simply addressing this to matplotlib-devel and removing -users from the address list. Eric -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] RFC: double click support in matplotlib
matplotlib doesn't support double clicks, and I was wondering if that was a design decision, or something that had been relegated to the "to do" box for someday. Hoping that it was still in the "todo" box, I think I can put most of it in without too much trouble, and supply you with a patch. The changes would be: 1) an extra flag MouseEvent, so that in a button_press_event handler, you can can tell if the press was a result of a double click or not, and 2) code in the backends to catch and set the double click flag properly I looked through the backends, and it was clear what to do in order to support double clicks for all but backend_macosx.py. I might be able to deduce what to do there, but will likely need some support from someone in order to get that one done. To support the double clicks, I would rather not create a new event like 'button_doubleclick_event', for backwards compatibility. I believe that if we just stick with 'button_press_event' and set an extra flag within the MouseEvent, any existing mpl code will still work properly, because the normal sequence of events on a double click are; DOWN, UP, DBLCLICK, UP. In current versions of matplotlib, the DBLCLICK event is treated as a DOWN, and the strategy of just adding a extra flag in MouseEvent would mean that existing mpl code would still see the double click event as a DOWN. Anyway, I want to "throw a feeler" out there, and ask if the patch would be accepted were I to go ahead and do it. I didn't want to spend the time working on it if a decision had already been made a while back to not ever support double clicks. -- Daniel Hyams [email protected] -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RFC: double click support in matplotlib
On Saturday, October 22, 2011, Daniel Hyams wrote: > matplotlib doesn't support double clicks, and I was wondering if that > was a design decision, or something that had been relegated to the "to > do" box for someday. Hoping that it was still in the "todo" box, I > think I can put most of it in without too much trouble, and supply you > with a patch. > > The changes would be: > 1) an extra flag MouseEvent, so that in a button_press_event > handler, you can can tell if the press was a result of a double click > or not, and > 2) code in the backends to catch and set the double click flag properly > > I looked through the backends, and it was clear what to do in order to > support double clicks for all but backend_macosx.py. I might be able > to deduce what to do there, but will likely need some support from > someone in order to get that one done. > > To support the double clicks, I would rather not create a new event > like 'button_doubleclick_event', for backwards compatibility. I > believe that if we just stick with 'button_press_event' and set an > extra flag within the MouseEvent, any existing mpl code will still > work properly, because the normal sequence of events on a double click > are; DOWN, UP, DBLCLICK, UP. In current versions of matplotlib, the > DBLCLICK event is treated as a DOWN, and the strategy of just adding a > extra flag in MouseEvent would mean that existing mpl code would still > see the double click event as a DOWN. > > Anyway, I want to "throw a feeler" out there, and ask if the patch > would be accepted were I to go ahead and do it. I didn't want to spend > the time working on it if a decision had already been made a while > back to not ever support double clicks. > My vote would be yes, but I think i would want it as a separate event. Consider some of the widgets like lasso and the zoom bbox. If one were to attach a button_press_event for the purpose of detecting double clicks, I would imagine that there may exist conflicts (or those widget codes would have to be adjusted to exclusively respond only to single clicks). Would existing widgets also fire even if a double-click occured? My 2 cents, Ben Rootl -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
