MEP22 doc

Development matplotlib-devel
1

Hello everybody

I just added some documentation for the MEP22 new classes and methods.
Please take a look https://github.com/matplotlib/matplotlib/pull/2759

I ran into some problems, when trying to decide if some methods where
public or not.

If the method was used only for backend implementation pourposes I put
it as private (name starts with underscore) but still documented them
in the Notes section of the class.
I don't know if this is the correct way to do it, but I couldn't decide.
If you prefer any other way to do it, please let me know.

Thank you
Federico

···

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

2

Hi Federico,

I just wanted to say that I’ve been a little busy lately, but your MEP is really shaping up - I really like the concepts that are being proposed and think it will make a huge difference to people who want to implement custom UIs.

Keep up the great work, and continue trying to get feedback from all of us on this!

Thanks,

Phil

···

On 24 January 2014 18:43, Federico Ariza <ariza.federico@…149…> wrote:

Hello everybody

I just added some documentation for the MEP22 new classes and methods.

Please take a look https://github.com/matplotlib/matplotlib/pull/2759

I ran into some problems, when trying to decide if some methods where

public or not.

If the method was used only for backend implementation pourposes I put

it as private (name starts with underscore) but still documented them

in the Notes section of the class.

I don’t know if this is the correct way to do it, but I couldn’t decide.

If you prefer any other way to do it, please let me know.

Thank you

Federico

–

Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

– Antonio Alducin –

CenturyLink Cloud: The Leader in Enterprise Cloud Services.

Learn Why More Businesses Are Choosing CenturyLink Cloud For

Critical Workloads, Development Environments & Everything In Between.

Get a Quote or Start a Free Trial Today.

http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

3

Hello everybody

I just added "click_tool" to simulate a click programatically.

Is there anything missing or that you want to change?
I'm saturated so I don't see anything anymore.

I would like to have some input specially in the `ToolbarBase` class.
I am ready to start the implementation on the other backends, and this
is the "new class" that have to be implemented for all the backends.
`Navigation` is mostly copy paste from existing toolbar

Thanks
Federico

···

On Mon, Jan 27, 2014 at 11:07 AM, Phil Elson <pelson.pub@...149...> wrote:

Hi Federico,

I just wanted to say that I've been a little busy lately, but your MEP is
really shaping up - I really like the concepts that are being proposed and
think it will make a huge difference to people who want to implement custom
UIs.

Keep up the great work, and continue trying to get feedback from all of us
on this!

Thanks,

Phil

On 24 January 2014 18:43, Federico Ariza <ariza.federico@...149...> wrote:

Hello everybody

I just added some documentation for the MEP22 new classes and methods.
Please take a look MEP22 Navigation toolbar coexistence TODELETE by fariza · Pull Request #2759 · matplotlib/matplotlib · GitHub

I ran into some problems, when trying to decide if some methods where
public or not.

If the method was used only for backend implementation pourposes I put
it as private (name starts with underscore) but still documented them
in the Notes section of the class.
I don't know if this is the correct way to do it, but I couldn't decide.
If you prefer any other way to do it, please let me know.

Thank you
Federico

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.

http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

4

I left some comments on the wiki (in ). Not sure what the best way
to leave comments is.

···

On Mon, Jan 27, 2014 at 5:04 PM, Federico Ariza <ariza.federico@...149...> wrote:

Hello everybody

I just added "click_tool" to simulate a click programatically.
MEP22 Navigation toolbar coexistence TODELETE by fariza · Pull Request #2759 · matplotlib/matplotlib · GitHub

Is there anything missing or that you want to change?
I'm saturated so I don't see anything anymore.

I would like to have some input specially in the `ToolbarBase` class.
I am ready to start the implementation on the other backends, and this
is the "new class" that have to be implemented for all the backends.
`Navigation` is mostly copy paste from existing toolbar

Thanks
Federico

On Mon, Jan 27, 2014 at 11:07 AM, Phil Elson <pelson.pub@...149...> wrote:

Hi Federico,

I just wanted to say that I've been a little busy lately, but your MEP is
really shaping up - I really like the concepts that are being proposed and
think it will make a huge difference to people who want to implement custom
UIs.

Keep up the great work, and continue trying to get feedback from all of us
on this!

Thanks,

Phil

On 24 January 2014 18:43, Federico Ariza <ariza.federico@...149...> wrote:

Hello everybody

I just added some documentation for the MEP22 new classes and methods.
Please take a look MEP22 Navigation toolbar coexistence TODELETE by fariza · Pull Request #2759 · matplotlib/matplotlib · GitHub

I ran into some problems, when trying to decide if some methods where
public or not.

If the method was used only for backend implementation pourposes I put
it as private (name starts with underscore) but still documented them
in the Notes section of the class.
I don't know if this is the correct way to do it, but I couldn't decide.
If you prefer any other way to do it, please let me know.

Thank you
Federico

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.

http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Thomas A Caswell
PhD Candidate University of Chicago
Nagel and Gardel labs
tcaswell@...1038...
jfi.uchicago.edu/~tcaswell
o: 773.702.7204

5

@tacaswell I modified the wiki reflecting the changes and trying to
answer the questions.
Please let me know if I answered your questions/concerns. We can
iterate as muchs as needed on this, I have no problem modifying the
names or functionnality.

Sorry for the long email
Here a list of things that I changed

ToolBase
description = '': Small description of the tool

persistent = False: If True, the instance of the Tool is registered
with Navigation for reuse.
This is needed because some tools are keept alive in the background,
for example SubplotTool.

position = None: Where is it positionned in the toolbar?. -1 = at the
end, None = Not in the toolbar.
The default tools are all ordered by their position in the Navigation
_default_tools array. This argument is mainly used by User created
tools that are added after the Toolbar creation.
My idea was that for the user created tools, the user could set the
position without having to subclass the Navigation class.
So this information has to be included in the Tool.

activate(self, event): This is the main method of the Tool, it is
called when the Tool is triggered by:
  * Toolbar button click
  * keypress associated with the Tool Keymap
  * Call to navigation.click_tool(name)

ToolPersistentBase
unregister(self, *args): ... Because ToolBase is intened for single
use, there is no need of registration for the instances, persistent
tools, need to be registered so __init__ is called only onece during
the first trigger

NavigationBase
locks.... I tend to agree with you.
The idea that I had in mind, and maybe was more complex than expected.
Was to redirect the events to the tool without need to call the
mpl_connect within the tool. So I provided the methods to handle those
events directly.
This is also from the idea that if we implement the
MultiFigureManager, when there is a change on the 'active_figure'
Navigation knows about the change and changes the event handlers, in
this case the Tools don't need to do anything.
It was just to simplify the Tool creation eliminating the need for
basic event connection in case of figure changes.

Even if we remove the locks we need two locks:
canvaslock (for the input)
keypress lock, to give the tool the option to absorb the keypress
completely. (Tool for anotations comes to mind)

I didn't remove the comment for the locks, because I am not sure what
is the best option.

ToolbarBase
I tried to clarify the use of the methods. Most of the methods that
you mentionned, are for internal use only but are mandatory for
backend implementation.
Also I updated the wiki with the "_" that was missing from the private methods.

···

On Mon, Jan 27, 2014 at 9:12 PM, Thomas A Caswell <tcaswell@...1038...> wrote:

I left some comments on the wiki (in ). Not sure what the best way
to leave comments is.

On Mon, Jan 27, 2014 at 5:04 PM, Federico Ariza > <ariza.federico@...149...> wrote:

Hello everybody

I just added "click_tool" to simulate a click programatically.
MEP22 Navigation toolbar coexistence TODELETE by fariza · Pull Request #2759 · matplotlib/matplotlib · GitHub

Is there anything missing or that you want to change?
I'm saturated so I don't see anything anymore.

I would like to have some input specially in the `ToolbarBase` class.
I am ready to start the implementation on the other backends, and this
is the "new class" that have to be implemented for all the backends.
`Navigation` is mostly copy paste from existing toolbar

Thanks
Federico

On Mon, Jan 27, 2014 at 11:07 AM, Phil Elson <pelson.pub@...149...> wrote:

Hi Federico,

I just wanted to say that I've been a little busy lately, but your MEP is
really shaping up - I really like the concepts that are being proposed and
think it will make a huge difference to people who want to implement custom
UIs.

Keep up the great work, and continue trying to get feedback from all of us
on this!

Thanks,

Phil

On 24 January 2014 18:43, Federico Ariza <ariza.federico@...149...> wrote:

Hello everybody

I just added some documentation for the MEP22 new classes and methods.
Please take a look MEP22 Navigation toolbar coexistence TODELETE by fariza · Pull Request #2759 · matplotlib/matplotlib · GitHub

I ran into some problems, when trying to decide if some methods where
public or not.

If the method was used only for backend implementation pourposes I put
it as private (name starts with underscore) but still documented them
in the Notes section of the class.
I don't know if this is the correct way to do it, but I couldn't decide.
If you prefer any other way to do it, please let me know.

Thank you
Federico

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.

http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Thomas A Caswell
PhD Candidate University of Chicago
Nagel and Gardel labs
tcaswell@...1038...
jfi.uchicago.edu/~tcaswell
o: 773.702.7204

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

6

Hello again

I have been playing with the locks to find a solution.
What we need is a way to let tools absorb the events (lock its use).

The problem that I'm facing is that Navigation itself needs to capture
two different events.

key_press_event for tool triggering
motion_notify_event for setting the message with the pointer position
and cursor changing.

Now the options that I see are:

Let the tools disconnect and reconnect this signals in navigation.
self.figure.canvas.mpl_disconnect(self.navigation.id_move)
....
self.navigation.id_move =
self.figure.canvas.mpl_connect('motion_notify_event',
self.navigation.mouse_move)

Create helper methods to disconnect and reconnect this signals in navigation
self.navigation.disconnect('mouse_move')
....
self.navigation.connect('mouse_move')

Use locks and let navigation redirect these events to the appropiate
place (what I'm doing right now).
self.navigation.movelock(self)
self.navigation.movelock.release(self)

Do you see other options?

One thing that is clear, is that for the moment Navigation needs only
two handlers, so I can reduce the number of locks to two....

Thanks
Federico

···

On Tue, Jan 28, 2014 at 11:05 AM, Federico Ariza <ariza.federico@...149...> wrote:

@tacaswell I modified the wiki reflecting the changes and trying to
answer the questions.
Please let me know if I answered your questions/concerns. We can
iterate as muchs as needed on this, I have no problem modifying the
names or functionnality.

Sorry for the long email
Here a list of things that I changed

ToolBase
description = '': Small description of the tool

persistent = False: If True, the instance of the Tool is registered
with Navigation for reuse.
This is needed because some tools are keept alive in the background,
for example SubplotTool.

position = None: Where is it positionned in the toolbar?. -1 = at the
end, None = Not in the toolbar.
The default tools are all ordered by their position in the Navigation
_default_tools array. This argument is mainly used by User created
tools that are added after the Toolbar creation.
My idea was that for the user created tools, the user could set the
position without having to subclass the Navigation class.
So this information has to be included in the Tool.

activate(self, event): This is the main method of the Tool, it is
called when the Tool is triggered by:
  * Toolbar button click
  * keypress associated with the Tool Keymap
  * Call to navigation.click_tool(name)

ToolPersistentBase
unregister(self, *args): ... Because ToolBase is intened for single
use, there is no need of registration for the instances, persistent
tools, need to be registered so __init__ is called only onece during
the first trigger

NavigationBase
locks.... I tend to agree with you.
The idea that I had in mind, and maybe was more complex than expected.
Was to redirect the events to the tool without need to call the
mpl_connect within the tool. So I provided the methods to handle those
events directly.
This is also from the idea that if we implement the
MultiFigureManager, when there is a change on the 'active_figure'
Navigation knows about the change and changes the event handlers, in
this case the Tools don't need to do anything.
It was just to simplify the Tool creation eliminating the need for
basic event connection in case of figure changes.

Even if we remove the locks we need two locks:
canvaslock (for the input)
keypress lock, to give the tool the option to absorb the keypress
completely. (Tool for anotations comes to mind)

I didn't remove the comment for the locks, because I am not sure what
is the best option.

ToolbarBase
I tried to clarify the use of the methods. Most of the methods that
you mentionned, are for internal use only but are mandatory for
backend implementation.
Also I updated the wiki with the "_" that was missing from the private methods.

On Mon, Jan 27, 2014 at 9:12 PM, Thomas A Caswell <tcaswell@...1038...> wrote:

I left some comments on the wiki (in ). Not sure what the best way
to leave comments is.

On Mon, Jan 27, 2014 at 5:04 PM, Federico Ariza >> <ariza.federico@...149...> wrote:

Hello everybody

I just added "click_tool" to simulate a click programatically.
MEP22 Navigation toolbar coexistence TODELETE by fariza · Pull Request #2759 · matplotlib/matplotlib · GitHub

Is there anything missing or that you want to change?
I'm saturated so I don't see anything anymore.

I would like to have some input specially in the `ToolbarBase` class.
I am ready to start the implementation on the other backends, and this
is the "new class" that have to be implemented for all the backends.
`Navigation` is mostly copy paste from existing toolbar

Thanks
Federico

On Mon, Jan 27, 2014 at 11:07 AM, Phil Elson <pelson.pub@...149...> wrote:

Hi Federico,

I just wanted to say that I've been a little busy lately, but your MEP is
really shaping up - I really like the concepts that are being proposed and
think it will make a huge difference to people who want to implement custom
UIs.

Keep up the great work, and continue trying to get feedback from all of us
on this!

Thanks,

Phil

On 24 January 2014 18:43, Federico Ariza <ariza.federico@...149...> wrote:

Hello everybody

I just added some documentation for the MEP22 new classes and methods.
Please take a look MEP22 Navigation toolbar coexistence TODELETE by fariza · Pull Request #2759 · matplotlib/matplotlib · GitHub

I ran into some problems, when trying to decide if some methods where
public or not.

If the method was used only for backend implementation pourposes I put
it as private (name starts with underscore) but still documented them
in the Notes section of the class.
I don't know if this is the correct way to do it, but I couldn't decide.
If you prefer any other way to do it, please let me know.

Thank you
Federico

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.

http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Thomas A Caswell
PhD Candidate University of Chicago
Nagel and Gardel labs
tcaswell@...1038...
jfi.uchicago.edu/~tcaswell
o: 773.702.7204

--
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 --

7

@tacaswell regarding your last comments on the wiki

Again, please let me know if something is not clear or you have suggestions

Again, sorry for the long email, but please don't forget the previous
one about the locks.....

activate: I agree with you, renamed to trigger

[I don't understand. The `__init__` gets called when the tool object
is created (and it gets registered with a particular
`NavigationBase`/`Figure`/`canvas`. The tool object then sits around
doing nothing waiting to be triggered. I can see wanting to remove
one of these buttons, in which case it will need to be un-registered]

I am not expressing myself correctly, what I am trying to say is that
the Tool object is only created when the tool is triggered.
The tool.trigger method is called in the ToolBase.__init__ method
For ToolBase tools, the object is not registered, so there is no
reference to it anywhere, so it should be garbage collected. I can add
a del to the object but I think is unnecesary.

ToolPersistentBase
[shouldn't `__init__` be called when the tool is created?
I think the confusion here is that I don't create the tools until they
are triggered, until then, is just a reference to the class. in the
navitaion._tools dict.

ToolToggleBase
[I would give them enable/disable methods, and make their `triggered`
action to call their own `enable`]
Actually it makes more sense, thanks.

···

On Tue, Jan 28, 2014 at 6:17 PM, Federico Ariza <ariza.federico@...149...> wrote:

Hello again

I have been playing with the locks to find a solution.
What we need is a way to let tools absorb the events (lock its use).

The problem that I'm facing is that Navigation itself needs to capture
two different events.

key_press_event for tool triggering
motion_notify_event for setting the message with the pointer position
and cursor changing.

Now the options that I see are:

Let the tools disconnect and reconnect this signals in navigation.
self.figure.canvas.mpl_disconnect(self.navigation.id_move)
....
self.navigation.id_move =
self.figure.canvas.mpl_connect('motion_notify_event',
self.navigation.mouse_move)

Create helper methods to disconnect and reconnect this signals in navigation
self.navigation.disconnect('mouse_move')
....
self.navigation.connect('mouse_move')

Use locks and let navigation redirect these events to the appropiate
place (what I'm doing right now).
self.navigation.movelock(self)
self.navigation.movelock.release(self)

Do you see other options?

One thing that is clear, is that for the moment Navigation needs only
two handlers, so I can reduce the number of locks to two....

Thanks
Federico

On Tue, Jan 28, 2014 at 11:05 AM, Federico Ariza > <ariza.federico@...149...> wrote:

@tacaswell I modified the wiki reflecting the changes and trying to
answer the questions.
Please let me know if I answered your questions/concerns. We can
iterate as muchs as needed on this, I have no problem modifying the
names or functionnality.

Sorry for the long email
Here a list of things that I changed

ToolBase
description = '': Small description of the tool

persistent = False: If True, the instance of the Tool is registered
with Navigation for reuse.
This is needed because some tools are keept alive in the background,
for example SubplotTool.

position = None: Where is it positionned in the toolbar?. -1 = at the
end, None = Not in the toolbar.
The default tools are all ordered by their position in the Navigation
_default_tools array. This argument is mainly used by User created
tools that are added after the Toolbar creation.
My idea was that for the user created tools, the user could set the
position without having to subclass the Navigation class.
So this information has to be included in the Tool.

activate(self, event): This is the main method of the Tool, it is
called when the Tool is triggered by:
  * Toolbar button click
  * keypress associated with the Tool Keymap
  * Call to navigation.click_tool(name)

ToolPersistentBase
unregister(self, *args): ... Because ToolBase is intened for single
use, there is no need of registration for the instances, persistent
tools, need to be registered so __init__ is called only onece during
the first trigger

NavigationBase
locks.... I tend to agree with you.
The idea that I had in mind, and maybe was more complex than expected.
Was to redirect the events to the tool without need to call the
mpl_connect within the tool. So I provided the methods to handle those
events directly.
This is also from the idea that if we implement the
MultiFigureManager, when there is a change on the 'active_figure'
Navigation knows about the change and changes the event handlers, in
this case the Tools don't need to do anything.
It was just to simplify the Tool creation eliminating the need for
basic event connection in case of figure changes.

Even if we remove the locks we need two locks:
canvaslock (for the input)
keypress lock, to give the tool the option to absorb the keypress
completely. (Tool for anotations comes to mind)

I didn't remove the comment for the locks, because I am not sure what
is the best option.

ToolbarBase
I tried to clarify the use of the methods. Most of the methods that
you mentionned, are for internal use only but are mandatory for
backend implementation.
Also I updated the wiki with the "_" that was missing from the private methods.

On Mon, Jan 27, 2014 at 9:12 PM, Thomas A Caswell <tcaswell@...1038...> wrote:

I left some comments on the wiki (in ). Not sure what the best way
to leave comments is.

On Mon, Jan 27, 2014 at 5:04 PM, Federico Ariza >>> <ariza.federico@...149...> wrote:

Hello everybody

I just added "click_tool" to simulate a click programatically.
MEP22 Navigation toolbar coexistence TODELETE by fariza · Pull Request #2759 · matplotlib/matplotlib · GitHub

Is there anything missing or that you want to change?
I'm saturated so I don't see anything anymore.

I would like to have some input specially in the `ToolbarBase` class.
I am ready to start the implementation on the other backends, and this
is the "new class" that have to be implemented for all the backends.
`Navigation` is mostly copy paste from existing toolbar

Thanks
Federico

On Mon, Jan 27, 2014 at 11:07 AM, Phil Elson <pelson.pub@...149...> wrote:

Hi Federico,

I just wanted to say that I've been a little busy lately, but your MEP is
really shaping up - I really like the concepts that are being proposed and
think it will make a huge difference to people who want to implement custom
UIs.

Keep up the great work, and continue trying to get feedback from all of us
on this!

Thanks,

Phil

On 24 January 2014 18:43, Federico Ariza <ariza.federico@...149...> wrote:

Hello everybody

I just added some documentation for the MEP22 new classes and methods.
Please take a look MEP22 Navigation toolbar coexistence TODELETE by fariza · Pull Request #2759 · matplotlib/matplotlib · GitHub

I ran into some problems, when trying to decide if some methods where
public or not.

If the method was used only for backend implementation pourposes I put
it as private (name starts with underscore) but still documented them
in the Notes section of the class.
I don't know if this is the correct way to do it, but I couldn't decide.
If you prefer any other way to do it, please let me know.

Thank you
Federico

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.

http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Thomas A Caswell
PhD Candidate University of Chicago
Nagel and Gardel labs
tcaswell@...1038...
jfi.uchicago.edu/~tcaswell
o: 773.702.7204

--
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 --

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

8

If you do not instantiate the object until the button get pushed, why
even bother with a class, can't this just be a function? I still
think it would be better create the `Tool` objects when you create the
figure and then call their `trigger` function when the button gets
pushed. For one thing, this makes it dead-simple to rig up the gui
side of things (at least in Qt, I would assume the others are similar
`button.clicked.connect(self._home_tool.trigger)` ) as the functions
we care about already look like call-backs. I am not sure that the
benefit of doing it the way you wrote it (with the button-push-time
object creation) is worth the added complexity.

I think we only need two kinds of tools, the kind you push once and
they fire off an action (simple push button, need one public function
`trigger` this works for simple actions home, quit, back and things
that create extra windows) and the kind you can toggle on and off
(need two public functions `enable` and `disable` which are what they
do when you turn them on (set up call backs to grab input) and turn
them off (tear down/disconnect the canvas call backs) which eliminates
much of the need for keeping track of locks (I think). The toggle
kind may or may not be group in to exclusion groups (pan/zoom) but I
could see doing 'toggle grid lines' as this type as well.

Tom

···

On Tue, Jan 28, 2014 at 7:27 PM, Federico Ariza <ariza.federico@...149...> wrote:

activate: I agree with you, renamed to trigger

[I don't understand. The `__init__` gets called when the tool object
is created (and it gets registered with a particular
`NavigationBase`/`Figure`/`canvas`. The tool object then sits around
doing nothing waiting to be triggered. I can see wanting to remove
one of these buttons, in which case it will need to be un-registered]

I am not expressing myself correctly, what I am trying to say is that
the Tool object is only created when the tool is triggered.
The tool.trigger method is called in the ToolBase.__init__ method
For ToolBase tools, the object is not registered, so there is no
reference to it anywhere, so it should be garbage collected. I can add
a del to the object but I think is unnecesary.
ToolPersistentBase
[shouldn't `__init__` be called when the tool is created?
I think the confusion here is that I don't create the tools until they
are triggered, until then, is just a reference to the class. in the
navitaion._tools dict.

--
Thomas Caswell
tcaswell@...149...

9

The idea to pass the reference of the tool, is just to have a
collection of instantiable classes.
This allows me to create the toolbar and keymap with their class
attributes without instantiating the classes. And leave the __init__
method available for more important things, as window creation and
that kind of things.

If I don't handle the tool trigger in navigation then I have to check
for toggled tools, to untoggle others. And if toggled from keypress
then toggle toolbar without calling callback, etc...... Right now this
problem doesn't exist because the buttons are not toggle, but I
definitively want to use Toggle buttons, I hate that I don't know if
zoom is active or not.

Why to keep the instances alive? take the example of configuresuplots,
in this case if I don't keep the instance alive, I will end with many
windows, or having to deal with singletons that I think is not a good
idea. Other examples comes to mind, for example if you want to make a
logger, you want it to be alive in the background and not being a
toggle.

Federico

···

On Tue, Jan 28, 2014 at 9:32 PM, Thomas Caswell <tcaswell@...149...> wrote:

On Tue, Jan 28, 2014 at 7:27 PM, Federico Ariza > <ariza.federico@...149...> wrote:

activate: I agree with you, renamed to trigger

[I don't understand. The `__init__` gets called when the tool object
is created (and it gets registered with a particular
`NavigationBase`/`Figure`/`canvas`. The tool object then sits around
doing nothing waiting to be triggered. I can see wanting to remove
one of these buttons, in which case it will need to be un-registered]

I am not expressing myself correctly, what I am trying to say is that
the Tool object is only created when the tool is triggered.
The tool.trigger method is called in the ToolBase.__init__ method
For ToolBase tools, the object is not registered, so there is no
reference to it anywhere, so it should be garbage collected. I can add
a del to the object but I think is unnecesary.
ToolPersistentBase
[shouldn't `__init__` be called when the tool is created?
I think the confusion here is that I don't create the tools until they
are triggered, until then, is just a reference to the class. in the
navitaion._tools dict.

If you do not instantiate the object until the button get pushed, why
even bother with a class, can't this just be a function? I still
think it would be better create the `Tool` objects when you create the
figure and then call their `trigger` function when the button gets
pushed. For one thing, this makes it dead-simple to rig up the gui
side of things (at least in Qt, I would assume the others are similar
`button.clicked.connect(self._home_tool.trigger)` ) as the functions
we care about already look like call-backs. I am not sure that the
benefit of doing it the way you wrote it (with the button-push-time
object creation) is worth the added complexity.

I think we only need two kinds of tools, the kind you push once and
they fire off an action (simple push button, need one public function
`trigger` this works for simple actions home, quit, back and things
that create extra windows) and the kind you can toggle on and off
(need two public functions `enable` and `disable` which are what they
do when you turn them on (set up call backs to grab input) and turn
them off (tear down/disconnect the canvas call backs) which eliminates
much of the need for keeping track of locks (I think). The toggle
kind may or may not be group in to exclusion groups (pan/zoom) but I
could see doing 'toggle grid lines' as this type as well.

Tom

--
Thomas Caswell
tcaswell@...149...

--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

10

@tacaswell I have been thinking about what we discussed last time.

Again, sorry for the long email

Locks:
I reduced the number of locks to 2.
This is what navigation actually uses,:
* keypress: to know if it can process the keypress
* message: to know if it can print stuff to the message area.

Radio/toggling logic inside GUI toolkit:
We can put it inside the toolbar because the toolkit already have the
mechanics (as you mentionned),
The problem is that we have to replicate all this logic inside the
navigation in case there is no toolbar. And we have to make sure the
two are in sync all the time.
Think of sequence, click to trigger tool1, keypress to trigger
tool2.... According to me, it becomes messy to know exactly what is
going to happen in the toolbar.

Radio/toggling logic inside the tools:
This can be done, but I don't like the idea of the tools knowing about
the other tools, all the tools of the same group have to be registered
with the other tools, and adding and removing them at runtime can
become messy, if navigation keeps a central register of all the tools,
it can make changes without a problem.
If a tool wants to know about other tools, they can acces them
throught self.navigation.

Use tool instances instead of tool clases
For this one I am almost on your side.
The only downside that I see with this, is:
To make GUI tools, it becomes a little bit more work.
The tool has to keep track of the window state (open/close) and
recreate its gui if it has been closed/destroyed etc..
If we instantiate at first trigger time (as it is right now), the tool
can be a standard GUI window with a trigger method, and calling
unregister at destroy. No open/close state.

Federico

···

On Tue, Jan 28, 2014 at 9:51 PM, Federico Ariza <ariza.federico@...149...> wrote:

The idea to pass the reference of the tool, is just to have a
collection of instantiable classes.
This allows me to create the toolbar and keymap with their class
attributes without instantiating the classes. And leave the __init__
method available for more important things, as window creation and
that kind of things.

If I don't handle the tool trigger in navigation then I have to check
for toggled tools, to untoggle others. And if toggled from keypress
then toggle toolbar without calling callback, etc...... Right now this
problem doesn't exist because the buttons are not toggle, but I
definitively want to use Toggle buttons, I hate that I don't know if
zoom is active or not.

Why to keep the instances alive? take the example of configuresuplots,
in this case if I don't keep the instance alive, I will end with many
windows, or having to deal with singletons that I think is not a good
idea. Other examples comes to mind, for example if you want to make a
logger, you want it to be alive in the background and not being a
toggle.

Federico

On Tue, Jan 28, 2014 at 9:32 PM, Thomas Caswell <tcaswell@...149...> wrote:

On Tue, Jan 28, 2014 at 7:27 PM, Federico Ariza >> <ariza.federico@...149...> wrote:

activate: I agree with you, renamed to trigger

[I don't understand. The `__init__` gets called when the tool object
is created (and it gets registered with a particular
`NavigationBase`/`Figure`/`canvas`. The tool object then sits around
doing nothing waiting to be triggered. I can see wanting to remove
one of these buttons, in which case it will need to be un-registered]

I am not expressing myself correctly, what I am trying to say is that
the Tool object is only created when the tool is triggered.
The tool.trigger method is called in the ToolBase.__init__ method
For ToolBase tools, the object is not registered, so there is no
reference to it anywhere, so it should be garbage collected. I can add
a del to the object but I think is unnecesary.
ToolPersistentBase
[shouldn't `__init__` be called when the tool is created?
I think the confusion here is that I don't create the tools until they
are triggered, until then, is just a reference to the class. in the
navitaion._tools dict.

If you do not instantiate the object until the button get pushed, why
even bother with a class, can't this just be a function? I still
think it would be better create the `Tool` objects when you create the
figure and then call their `trigger` function when the button gets
pushed. For one thing, this makes it dead-simple to rig up the gui
side of things (at least in Qt, I would assume the others are similar
`button.clicked.connect(self._home_tool.trigger)` ) as the functions
we care about already look like call-backs. I am not sure that the
benefit of doing it the way you wrote it (with the button-push-time
object creation) is worth the added complexity.

I think we only need two kinds of tools, the kind you push once and
they fire off an action (simple push button, need one public function
`trigger` this works for simple actions home, quit, back and things
that create extra windows) and the kind you can toggle on and off
(need two public functions `enable` and `disable` which are what they
do when you turn them on (set up call backs to grab input) and turn
them off (tear down/disconnect the canvas call backs) which eliminates
much of the need for keeping track of locks (I think). The toggle
kind may or may not be group in to exclusion groups (pan/zoom) but I
could see doing 'toggle grid lines' as this type as well.

Tom

--
Thomas Caswell
tcaswell@...149...

--
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 --