Re: [matplotlib-devel] Upstream Matplotlib Qt Designer Plugin
I've included this in openSUSE's matplotlib packages, it seems to work great. -Todd On Mon, Mar 19, 2012 at 10:08 PM, Pierre Raybaut wrote: > Hi all, > > Is anyone interested in including the Matplotlib QtDesigner plugin > which I wrote for Python(x,y)? > > The code is quite simple and hasn't evolved for a while now (3 years) > but apparently it is still appreciated by users even outside > Python(x,y). > > Here are the two files which are necessary to make this plugin work: > http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/matplotlibwidget.py > http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/PyQt4/plugins/designer/python/matplotlibplugin.py > > The directory struture also has its importance: > http://code.google.com/p/pythonxy/source/browse/#hg%2Fsrc%2Fpython%2Fmatplotlib%2FQtDesigner_Plugins > > Cheers, > Pierre > > -- Message transféré -- > De : todd rme > Date : 11 mars 2012 12:14 > Objet : [python(x,y)] Upstream Matplotlib Qt Designer Plugin > À : "python(x,y)" > > > I notice that python(x,y) has a matplotlib plugin for Qt Designer. I > think this would be very helpful for general users of matplotlib > outside of python(x,y). Is there any possibility of submitting this > plugin upstream for inclusion with the official matplotlib release? > That way people who aren't using python(x,y) (for instance Linux users > who are using their official distribution python packages) could > benefit from the plugin as well. Thank you very much. > > -Todd > > -- > You received this message because you are subscribed to the Google > Groups "python(x,y)" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/pythonxy?hl=en. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Upstream Matplotlib Qt Designer Plugin
On Mon, Mar 19, 2012 at 10:08 PM, Pierre Raybaut wrote: > Hi all, > > Is anyone interested in including the Matplotlib QtDesigner plugin > which I wrote for Python(x,y)? > > The code is quite simple and hasn't evolved for a while now (3 years) > but apparently it is still appreciated by users even outside > Python(x,y). > > Here are the two files which are necessary to make this plugin work: > http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/matplotlibwidget.py > http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/PyQt4/plugins/designer/python/matplotlibplugin.py > > The directory struture also has its importance: > http://code.google.com/p/pythonxy/source/browse/#hg%2Fsrc%2Fpython%2Fmatplotlib%2FQtDesigner_Plugins > > Cheers, > Pierre I have been looking at the matplotlib widget code. It is very helpful for putting a widget inside PyQt4 windows. However, it is lacking any signals and slots to let you easily connect other Qt4 widgets with the matplotlib one. Particularly in Qt Designer, using signals and slots to connect widgets together is very convenient. I am willing to implement signals and slots, but I need some advice on the best approach. So far I see three different approaches that may work: 1. The simplest is just to manually add slots for common commands in the widget. I would also probably add some signals for things like mouse clicks. However, this requires manually creating the signals and slots, and will break if matplotlib changes any of its api. I would also need to decide whether to use the matplotlib function naming rules or the Qt4 ones (or both, since I can give the same signal multiple names). 2. Integrate the signals and slots directly into matplotlib. This would probably involve somehow having matplotlib functions exposed as signals and/or slots, probably somewhere in the PyQt4/pyside backend. It would probably entail separating the PyQt4/pyside backend into a PyQt4/pyside widget and a PyQt4/pyside window that contains that widget. All the interaction between settings, buttons, etc would use signals and slots internally. Users could then use the widget in other contexts besides the window, and use the same signals and slots the window uses. This would also eliminate the need for a separate widget to be used for Qt Designer. It would still require manually specifying the signals and slots. I haven't looked in much detail, but this is probably not that much more difficult than 1. 3. Make PyQt4 backend use widgets for everything. Each object would have all of its functions exposed as signals and slots, and all would be usable in Qt Designer. If I understand it correctly, the PyQt4 backend uses Agg for the actual painting, so this would require implementing an entire new backend, so is probably not a good choice initially. Either approach would be -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release
On Wed, Jul 11, 2012 at 5:23 PM, John Hunter wrote: > > > On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall > wrote: >> >> Well, as Ben said, that error fill plot is neato! It doesn't look too >> complicated, either. I'd be more than happy to port it over later today >> when I get bored of typing up my thesis. It'll probably only take me >> about 30 minutes. >> >> If nobody is opposed to this idea, I'll go ahead and submit a PR this >> evening (British Summer (hah!) Time). > > > > While it is a nice graph, I am not sure that the use case is common enough > to justify a new plotting method. One can get the same result with: > > > In [68]: x = np.linspace(0, 2 * np.pi) > > In [69]: y_sin = np.sin(x) > > In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2]) > > In [71]: plot(x, y_sin) > Out[71]: [] > > In [72]: fill_between(np.concatenate([x, x[::-1]]), err, facecolor='red', > alpha=0.5) > Out[72]: > > Admittedly the [::-1] thing is a bit counter-intuitive, but rather than > adding a new plotting method, perhaps we would be better off with a helper > method to create the xs and ys for fill_between > > xs, ys = mlab.pad_line(x, y, 0.2) > fill_between(xs, ys) > > JDH What about adding a property to the existing errorbar to let someone change it to the filled version? This could also, potentially, be extended with other types of error bars if the need arises. -Todd -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue
On Wed, Oct 3, 2012 at 6:20 PM, Michael Droettboom wrote: > I invite comments for a new MEP about improving the situation with respect > to our bundling of third-party Python dependencies. > > In particular, I'd love feedback from the various stakeholders -- those > producing binary installers and packages for the various platforms. > > https://github.com/matplotlib/matplotlib/wiki/MEP11 > > Mike I help with the openSUSE packaging of mpl. At least as openSUSE policies go, bundling dependencies is considered a big no-no. RPM has its own dependency handling, so as long as the dependencies are documented (ideally with version numbers) then there is no issue, either at build-time or at run-time. I think that would likely be the case for any official linux packages. Anyone on Linux who is trying to install matplotlib from source should be prepared to handle dependency resolution manually. If they aren't, then they shouldn't be messing with package installation in the first place. I think the documentation should clearly state this, although more diplomatically of course :) So from a Linux standpoint I think bundling is a bad idea. Further, any solution should be prepared to handle the situation where the dependencies are already available, and not try to download them under this situation. It should also be able to handle installation with no internet connection as long as the dependencies are available, so it can be compatible with automated build systems and hpc environments which may not support internet access for security reasons. For windows, rather than creating independent matplotlib installers, can't the documentation just point people in the direction of a pre-existing bundle like python(x,y)? Since there are groups dedicated to making it easy to install python packages on windows, I don't see the point of going through all the trouble of making your own version. If you really wanted to you might even be able to use their sources to create your own variant that just installs what you need. -Todd -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] PyGTK vs PyGObject
I am trying to do some experimental packages with python 3 and the latest RC, and I am trying to figure out the situation with some of the backends. Some are obvious, like wxwidgets and PyQt (Qt3 version). The issue I am running into is with the gtk backend PyGTK is deprecated. According to the website, all development halted a year and a half ago and they say to use PyGObject instead. PyGTK, as far as I can tell, does not support Python 3 or GTK 3. PyGObject, however, supports both. So I was wondering what I should be doing with this backend. Does matplotlib support PyGObject, or should the GTK backends just be disabled on Python 3 builds? Thanks for your help. -Todd -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
