matplotlib-devel Mailing List for matplotlib

No there is no pull request.
I wanted to get some feedback before, as the development workflow suggested.
Federico
On Wed, Sep 25, 2013 at 3:25 PM, Michael Droettboom <md...@st...> wrote:
> Is there a pull request open for this? If not, could you create one?
>
> Mike
>
> On 09/25/2013 03:04 PM, Federico Ariza wrote:
>> Hello
>>
>> To address the concern of display multiple figures at the same time.
>> I added detach and re-parent methods to the figure manager, so figures
>> can be programatically redistributed between containers.
>>
>> Also I added a couple of tools that I use a lot, one for line
>> properties and one for axes properties.
>>
>> I got rid of the non working linedialog and replaced completely the
>> FigureManagerGtk3 and Toolbar2Gtk3
>>
>> I would greatly appreciate some feedback to see if I am going in the
>> right direction.
>>
>> As I mentioned before, there is not much in terms of documentation
>> yet, because I do not want to spend time documenting something that I
>> am not sure is useful to somebody else.
>>
>> Thanks
>> Federico
>>
>>
>>
>>
>> On Wed, Sep 18, 2013 at 12:13 PM, Federico Ariza
>> <ari...@gm...> wrote:
>>> I forgot about the diff link.
>>>
>>> https://github.com/fariza/matplotlib/compare/tabbed-gtk3-figuremanager
>>>
>>> I try to place everything where it is supposed to go (backend_bases)
>>>
>>>
>>>
>>>
>>> On Wed, Sep 18, 2013 at 8:38 AM, Phil Elson <pel...@gm...> wrote:
>>>> No need to be nervous. We are a friendly bunch and this is cool stuff.
>>>>
>>>> I haven't looked at your code (a diff link would be useful), but the obvious first questions would be:
>>>>
>>>
>>>
>>>> Can I display multiple tabs at the same time (i.e. tab splitting)
>>> At first sight, I do not see why not, the multiFigureBackend just
>>> controls adding, removing and switching from one figure to another.
>>> Giving the toolbar control to the active figure.
>>>
>>>> If so, can I programatically control the splitting?
>>> I was thinking about this, and I think it is possible to add as many
>>> instances of the MultiFigureManager as we want, and place figures in
>>> the desired one. Removing and adding them is also possible.
>>>
>>>> On that front, did you consider looking at implementing the tabbing in matplotlib itself? Obviously there is nothing there at the moment, but it is conceivable that "tab" buttons could be added to a special "figure" which when clicked change which figure is being rendered in the plot area. Doing so would mean that your GUI doesn't look like native tabs, but it would mean that it would instantly work on all interactive backends. Just a thought.
>>>>
>>> I did not think about this, but to be honest, I do not like the
>>> matplotlib widgets :(
>>>
>>>> Anyway, I'm not sure how we take this forward - I can't imagine we would want to take on a whole new set of backends for tabbed browsing specifically, but it could potentially be integrated together with the existing backends I suppose.
>>> As I tried to implement it, if the corresponding MultiFigureBackend is
>>> implemented for the selected backend, and
>>> matplotlib.rcParams['backend.single_window'] = True
>>> This will be loaded if not, the traditional backend work as always.
>>>
>>> Of course all of these possibilities have to be tested, to see...
>>>
>>>> Nice work!
>>>>
>>>> Phil
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 18 September 2013 01:07, Federico Ariza <ari...@gm...> wrote:
>>>>> Hello everybody:
>>>>>
>>>>> This is my first post here, I am a little bit nervous, because this is my first post :D, and also because I want to talk about a touchy subject....
>>>>>
>>>>> In my work I have developped several backends to manage multiple figures at the same time, from what I see around, this is something that could be of interest for many people.
>>>>> I have done it in gtk, wx, tk, and now I am doing it again in gtk3.
>>>>>
>>>>> So I thought it would be nice to try to run this idea by you.
>>>>> If you look at the attached images, you will see what I mean.
>>>>>
>>>>> The code is in
>>>>> https://github.com/fariza/matplotlib/tree/tabbed-gtk3-figuremanager
>>>>>
>>>>>
>>>>> I know I should have done another file for the figure manager, but because it sits in between backend_bases.py and backend_gtk3xxx.py It was easier for me to test directly inside backend_gtk3.py
>>>>>
>>>>> Other think that I dislike, is that to extend the current backend, you have to get your hands pretty dirty and understand alot of things to make sense of how things work.
>>>>>
>>>>> I modified examples/pylab_examples/multiple_figs_demo.py
>>>>> to show it working.
>>>>>
>>>>> In the example, I added a stupid class, to show how can we attach external tools to the toolbar without complex manipulations.
>>>>> Also, this could be used to produce a tools library, and keeps things clean, in gtk3 backend there is a DialogLineprops, in qt there are other things similar, but all of them are separated and can not be reused....
>>>>>
>>>>> Take a look and let me know what you think.
>>>>> The only think needed to run with other examples is to use (gtk3 agg or cairo) and set the rcparam
>>>>>
>>>>> matplotlib.use('gtk3agg')
>>>>> matplotlib.rcParams['backend.gtk3.tabbed'] = True
>>>>>
>>>>> I tried to comment the code, but not to document it, because I want to have feedback before investing time in documenting something that maybe will be only for me.
>>>>>
>>>>> Thanks
>>>>> Federico
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>>>>
>>>>> -- Antonio Alducin --
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> LIMITED TIME SALE - Full Year of Microsoft Training For Just 49ドル.99!
>>>>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
>>>>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
>>>>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>
>>>
>>>
>>> --
>>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>>
>>> -- Antonio Alducin -
>>
>>
>
>
> --
> _
> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
> http://www.droettboom.com
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --

Is there a pull request open for this? If not, could you create one?
Mike
On 09/25/2013 03:04 PM, Federico Ariza wrote:
> Hello
>
> To address the concern of display multiple figures at the same time.
> I added detach and re-parent methods to the figure manager, so figures
> can be programatically redistributed between containers.
>
> Also I added a couple of tools that I use a lot, one for line
> properties and one for axes properties.
>
> I got rid of the non working linedialog and replaced completely the
> FigureManagerGtk3 and Toolbar2Gtk3
>
> I would greatly appreciate some feedback to see if I am going in the
> right direction.
>
> As I mentioned before, there is not much in terms of documentation
> yet, because I do not want to spend time documenting something that I
> am not sure is useful to somebody else.
>
> Thanks
> Federico
>
>
>
>
> On Wed, Sep 18, 2013 at 12:13 PM, Federico Ariza
> <ari...@gm...> wrote:
>> I forgot about the diff link.
>>
>> https://github.com/fariza/matplotlib/compare/tabbed-gtk3-figuremanager
>>
>> I try to place everything where it is supposed to go (backend_bases)
>>
>>
>>
>>
>> On Wed, Sep 18, 2013 at 8:38 AM, Phil Elson <pel...@gm...> wrote:
>>> No need to be nervous. We are a friendly bunch and this is cool stuff.
>>>
>>> I haven't looked at your code (a diff link would be useful), but the obvious first questions would be:
>>>
>>
>>
>>> Can I display multiple tabs at the same time (i.e. tab splitting)
>> At first sight, I do not see why not, the multiFigureBackend just
>> controls adding, removing and switching from one figure to another.
>> Giving the toolbar control to the active figure.
>>
>>> If so, can I programatically control the splitting?
>> I was thinking about this, and I think it is possible to add as many
>> instances of the MultiFigureManager as we want, and place figures in
>> the desired one. Removing and adding them is also possible.
>>
>>> On that front, did you consider looking at implementing the tabbing in matplotlib itself? Obviously there is nothing there at the moment, but it is conceivable that "tab" buttons could be added to a special "figure" which when clicked change which figure is being rendered in the plot area. Doing so would mean that your GUI doesn't look like native tabs, but it would mean that it would instantly work on all interactive backends. Just a thought.
>>>
>> I did not think about this, but to be honest, I do not like the
>> matplotlib widgets :(
>>
>>> Anyway, I'm not sure how we take this forward - I can't imagine we would want to take on a whole new set of backends for tabbed browsing specifically, but it could potentially be integrated together with the existing backends I suppose.
>> As I tried to implement it, if the corresponding MultiFigureBackend is
>> implemented for the selected backend, and
>> matplotlib.rcParams['backend.single_window'] = True
>> This will be loaded if not, the traditional backend work as always.
>>
>> Of course all of these possibilities have to be tested, to see...
>>
>>> Nice work!
>>>
>>> Phil
>>>
>>>
>>>
>>>
>>>
>>> On 18 September 2013 01:07, Federico Ariza <ari...@gm...> wrote:
>>>> Hello everybody:
>>>>
>>>> This is my first post here, I am a little bit nervous, because this is my first post :D, and also because I want to talk about a touchy subject....
>>>>
>>>> In my work I have developped several backends to manage multiple figures at the same time, from what I see around, this is something that could be of interest for many people.
>>>> I have done it in gtk, wx, tk, and now I am doing it again in gtk3.
>>>>
>>>> So I thought it would be nice to try to run this idea by you.
>>>> If you look at the attached images, you will see what I mean.
>>>>
>>>> The code is in
>>>> https://github.com/fariza/matplotlib/tree/tabbed-gtk3-figuremanager
>>>>
>>>>
>>>> I know I should have done another file for the figure manager, but because it sits in between backend_bases.py and backend_gtk3xxx.py It was easier for me to test directly inside backend_gtk3.py
>>>>
>>>> Other think that I dislike, is that to extend the current backend, you have to get your hands pretty dirty and understand alot of things to make sense of how things work.
>>>>
>>>> I modified examples/pylab_examples/multiple_figs_demo.py
>>>> to show it working.
>>>>
>>>> In the example, I added a stupid class, to show how can we attach external tools to the toolbar without complex manipulations.
>>>> Also, this could be used to produce a tools library, and keeps things clean, in gtk3 backend there is a DialogLineprops, in qt there are other things similar, but all of them are separated and can not be reused....
>>>>
>>>> Take a look and let me know what you think.
>>>> The only think needed to run with other examples is to use (gtk3 agg or cairo) and set the rcparam
>>>>
>>>> matplotlib.use('gtk3agg')
>>>> matplotlib.rcParams['backend.gtk3.tabbed'] = True
>>>>
>>>> I tried to comment the code, but not to document it, because I want to have feedback before investing time in documenting something that maybe will be only for me.
>>>>
>>>> Thanks
>>>> Federico
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>>>
>>>> -- Antonio Alducin --
>>>>
>>>> ------------------------------------------------------------------------------
>>>> LIMITED TIME SALE - Full Year of Microsoft Training For Just 49ドル.99!
>>>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
>>>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
>>>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>
>>
>> --
>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>
>> -- Antonio Alducin -
>
>
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

Hello
To address the concern of display multiple figures at the same time.
I added detach and re-parent methods to the figure manager, so figures
can be programatically redistributed between containers.
Also I added a couple of tools that I use a lot, one for line
properties and one for axes properties.
I got rid of the non working linedialog and replaced completely the
FigureManagerGtk3 and Toolbar2Gtk3
I would greatly appreciate some feedback to see if I am going in the
right direction.
As I mentioned before, there is not much in terms of documentation
yet, because I do not want to spend time documenting something that I
am not sure is useful to somebody else.
Thanks
Federico
On Wed, Sep 18, 2013 at 12:13 PM, Federico Ariza
<ari...@gm...> wrote:
> I forgot about the diff link.
>
> https://github.com/fariza/matplotlib/compare/tabbed-gtk3-figuremanager
>
> I try to place everything where it is supposed to go (backend_bases)
>
>
>
>
> On Wed, Sep 18, 2013 at 8:38 AM, Phil Elson <pel...@gm...> wrote:
>>
>> No need to be nervous. We are a friendly bunch and this is cool stuff.
>>
>> I haven't looked at your code (a diff link would be useful), but the obvious first questions would be:
>>
>
>
>
>> Can I display multiple tabs at the same time (i.e. tab splitting)
>
> At first sight, I do not see why not, the multiFigureBackend just
> controls adding, removing and switching from one figure to another.
> Giving the toolbar control to the active figure.
>
>> If so, can I programatically control the splitting?
> I was thinking about this, and I think it is possible to add as many
> instances of the MultiFigureManager as we want, and place figures in
> the desired one. Removing and adding them is also possible.
>
>>
>> On that front, did you consider looking at implementing the tabbing in matplotlib itself? Obviously there is nothing there at the moment, but it is conceivable that "tab" buttons could be added to a special "figure" which when clicked change which figure is being rendered in the plot area. Doing so would mean that your GUI doesn't look like native tabs, but it would mean that it would instantly work on all interactive backends. Just a thought.
>>
> I did not think about this, but to be honest, I do not like the
> matplotlib widgets :(
>
>> Anyway, I'm not sure how we take this forward - I can't imagine we would want to take on a whole new set of backends for tabbed browsing specifically, but it could potentially be integrated together with the existing backends I suppose.
>
> As I tried to implement it, if the corresponding MultiFigureBackend is
> implemented for the selected backend, and
> matplotlib.rcParams['backend.single_window'] = True
> This will be loaded if not, the traditional backend work as always.
>
> Of course all of these possibilities have to be tested, to see...
>
>>
>> Nice work!
>>
>> Phil
>>
>>
>>
>>
>>
>> On 18 September 2013 01:07, Federico Ariza <ari...@gm...> wrote:
>>>
>>> Hello everybody:
>>>
>>> This is my first post here, I am a little bit nervous, because this is my first post :D, and also because I want to talk about a touchy subject....
>>>
>>> In my work I have developped several backends to manage multiple figures at the same time, from what I see around, this is something that could be of interest for many people.
>>> I have done it in gtk, wx, tk, and now I am doing it again in gtk3.
>>>
>>> So I thought it would be nice to try to run this idea by you.
>>> If you look at the attached images, you will see what I mean.
>>>
>>> The code is in
>>> https://github.com/fariza/matplotlib/tree/tabbed-gtk3-figuremanager
>>>
>>>
>>> I know I should have done another file for the figure manager, but because it sits in between backend_bases.py and backend_gtk3xxx.py It was easier for me to test directly inside backend_gtk3.py
>>>
>>> Other think that I dislike, is that to extend the current backend, you have to get your hands pretty dirty and understand alot of things to make sense of how things work.
>>>
>>> I modified examples/pylab_examples/multiple_figs_demo.py
>>> to show it working.
>>>
>>> In the example, I added a stupid class, to show how can we attach external tools to the toolbar without complex manipulations.
>>> Also, this could be used to produce a tools library, and keeps things clean, in gtk3 backend there is a DialogLineprops, in qt there are other things similar, but all of them are separated and can not be reused....
>>>
>>> Take a look and let me know what you think.
>>> The only think needed to run with other examples is to use (gtk3 agg or cairo) and set the rcparam
>>>
>>> matplotlib.use('gtk3agg')
>>> matplotlib.rcParams['backend.gtk3.tabbed'] = True
>>>
>>> I tried to comment the code, but not to document it, because I want to have feedback before investing time in documenting something that maybe will be only for me.
>>>
>>> Thanks
>>> Federico
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>>
>>> -- Antonio Alducin --
>>>
>>> ------------------------------------------------------------------------------
>>> LIMITED TIME SALE - Full Year of Microsoft Training For Just 49ドル.99!
>>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
>>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
>>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>
>
>
> --
> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>
> -- Antonio Alducin -
-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --

On 2013年09月24日 10:19 PM, mark wrote:
> hi matplotlib developers
>
> I have been considering the matplotlib user guide structure and it
> has occured to me that there are two user guides interleaved here:
> 1. Introduction for new users
> 2. Library tour for developers
>
> I think that this structure makes it challenging for new users to
> benefit from the user guide as much as they could.
>
> I would like to see the user guide separated into two sections, with
> the two different audiences in mind. I feel this would enable new
> users of the library to have a more targeted introduction to some of
> the neat features without getting bogged down in details they are
> unlikely to need (or comprehend).
>
> I am very happy to have a go at this and put up a set of suggested
> changes but I would value input from the community on this approach and
> my category suggestions before I submit a pull request.
Mark,
There is no doubt that the documentation can be improved, both via 
changes in organization and wording, and by adding missing parts. I'm 
happy to see you work on this, and look forward to the next increment of 
detail regarding your strategy.
Eric
>
> many thanks
> mark
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Thanks for the interest. I agree there's lots that can be done to 
improve it.
You may want to familiarize yourself with MEP10 ( 
https://github.com/matplotlib/matplotlib/wiki/Mep10) though that mainly 
deals with docstrings and not the narrative documentation.
Perhaps as a starting point, you'd want to write a MEP with your 
specific proposals -- maybe as a set of guidelines for how the docs 
should be laid out (with a few concrete examples of such changes, but 
without going through the laborious process of making all such 
changes). The nice thing about writing a MEP is that then we can point 
other people who want to help out to it and say "this is what we're 
trying to do", rather than the burden of all of the work being on just a 
single person. At least that's the idea ;)
Mike
On 09/25/2013 04:19 AM, mark wrote:
> hi matplotlib developers
>
> I have been considering the matplotlib user guide structure and it
> has occured to me that there are two user guides interleaved here:
> 1. Introduction for new users
> 2. Library tour for developers
>
> I think that this structure makes it challenging for new users to
> benefit from the user guide as much as they could.
>
> I would like to see the user guide separated into two sections, with
> the two different audiences in mind. I feel this would enable new
> users of the library to have a more targeted introduction to some of
> the neat features without getting bogged down in details they are
> unlikely to need (or comprehend).
>
> I am very happy to have a go at this and put up a set of suggested
> changes but I would value input from the community on this approach and
> my category suggestions before I submit a pull request.
>
> many thanks
> mark
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

For the record, I've spoken to Mark about this face-to-face in the past,
and I think he has some great ideas about how the user guide should look.
Personally I would agree that the user guide is currently not targeted
enough (it takes 3 pages full of text before getting to a simple plt.plot()
) and even then, I don't think it is sympathetic enough to really new
users. Clearly matplotlib's success shows that the documentation must be
doing something right, but I think the user guide could definitely be
improved.
Mark, from what I remember your changes were along the lines of moving
sections around, and splitting some sections into beginner & advanced
pages. I think detailing a few examples of the types of changes you have in
mind might help us to have a bit more clarity on what you are proposing.
Thanks for getting involved in improving the docs!
On 25 September 2013 09:19, mark <ma...@me...> wrote:
> hi matplotlib developers
>
> I have been considering the matplotlib user guide structure and it
> has occured to me that there are two user guides interleaved here:
> 1. Introduction for new users
> 2. Library tour for developers
>
> I think that this structure makes it challenging for new users to
> benefit from the user guide as much as they could.
>
> I would like to see the user guide separated into two sections, with
> the two different audiences in mind. I feel this would enable new
> users of the library to have a more targeted introduction to some of
> the neat features without getting bogged down in details they are
> unlikely to need (or comprehend).
>
> I am very happy to have a go at this and put up a set of suggested
> changes but I would value input from the community on this approach and
> my category suggestions before I submit a pull request.
>
> many thanks
> mark
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

hi matplotlib developers
I have been considering the matplotlib user guide structure and it
has occured to me that there are two user guides interleaved here:
 1. Introduction for new users
 2. Library tour for developers
I think that this structure makes it challenging for new users to
benefit from the user guide as much as they could. 
I would like to see the user guide separated into two sections, with
the two different audiences in mind. I feel this would enable new
users of the library to have a more targeted introduction to some of
the neat features without getting bogged down in details they are
unlikely to need (or comprehend). 
I am very happy to have a go at this and put up a set of suggested
changes but I would value input from the community on this approach and
my category suggestions before I submit a pull request.
many thanks
mark

Oops, and I missed the last point: we monitor our public chat room on hipchat:
http://www.hipchat.com/ghtNzvmfC
where anyone can post questions, follow ups, etc, that they don't want
to record persistently on hackpad in the minutes.
On Tue, Sep 24, 2013 at 5:50 PM, Fernando Perez <fpe...@gm...> wrote:
> Great! I just wanted to say that for us (ipython), that has worked really well.
>
> Our workflow is:
>
> 1. G+ hangout, with an invite list of ~ 15 (the limit), and we're
> always happy to offer an invite to anyone who wants to speak.
>
> 2. As soon as we start, we post the public link on g+, twitter and our hackpad.
>
> 3. We take running notes on a shared, public hackpad session that
> serves as our 'minutes' document:
>
> https://hackpad.com/IPython-dev-meetings-6wTSjJt7TZK
>
> 4. A summary of prior meetings and logistics info is kept here:
>
> https://github.com/ipython/ipython/wiki/Dev:-Lab-meetings-on-Air
>
>
> Very simple, lightweight and surprisingly effective at giving the core
> team a high-bandwidth channel for in-depth discussions while
> maintaining the openness we want to engage the broader community.
>
> Cheers,
>
> f
-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

Great! I just wanted to say that for us (ipython), that has worked really well.
Our workflow is:
1. G+ hangout, with an invite list of ~ 15 (the limit), and we're
always happy to offer an invite to anyone who wants to speak.
2. As soon as we start, we post the public link on g+, twitter and our hackpad.
3. We take running notes on a shared, public hackpad session that
serves as our 'minutes' document:
https://hackpad.com/IPython-dev-meetings-6wTSjJt7TZK
4. A summary of prior meetings and logistics info is kept here:
https://github.com/ipython/ipython/wiki/Dev:-Lab-meetings-on-Air
Very simple, lightweight and surprisingly effective at giving the core
team a high-bandwidth channel for in-depth discussions while
maintaining the openness we want to engage the broader community.
Cheers,
f