PluginMixin proposal #1

wxPython Users
1

Hi,

Please find at http://www.snakecard.com/PY my first PluginMixin proposal.

It shows a minimum implementation in PyAlaMode:

-) Py.Frame holds (for simplicity) the stub class PluginFrame wich would
eventually disappear as the code would be inserted in wx.Frame => the point
is to have the prototype self-contained so it can run without touching
wx.Frame until all agree
-) Py.Frame holds the PluginMixing class which would eventually be moved to
wx.PluginMixin
-)Py.Frame derives from the stub class PluginFrame which in turn derives from
wx.Frame and PluginMixin
-) All plugins are loaded at the initialization of Py.Frame
-) Once the frame is loaded and all other application's widgets are
installed 'OnInit in the install procedure of PyAlaMode" calls
PluginMixing.InitPlugins() which loops through the loaded plugins and calls
their "Init" method so they can add their own widgets

This first proposal simply installs new menus as the architecture would be the
same for other widgets ... I followed Kevin's suggestion to have a "Plugin"
menu automatically installed and all plugin menus installed under it ... I am
still debating as to whether this is flexible enough, but at least it keeps
multiple plugins from making the menu bar "too busy" ... cohabitation between
plugins is an issue I think.

Should all plugins be in the same hierarchy (as it is now) or should there be
a ways to have them spread around the file system / maybe the net ?

I am looking forward to receiving your feedback.

Regards,

Philippe

···

--
_________________________
Philippe C. Martin
www.snakecard.com
_________________________

2

Hi Philippe,

Hi,

Please find at http://www.snakecard.com/PY my first PluginMixin proposal.

It shows a minimum implementation in PyAlaMode:

-) Py.Frame holds (for simplicity) the stub class PluginFrame wich would
eventually disappear as the code would be inserted in wx.Frame => the point
is to have the prototype self-contained so it can run without touching
wx.Frame until all agree
-) Py.Frame holds the PluginMixing class which would eventually be moved to
wx.PluginMixin
-)Py.Frame derives from the stub class PluginFrame which in turn derives from
wx.Frame and PluginMixin
-) All plugins are loaded at the initialization of Py.Frame
-) Once the frame is loaded and all other application's widgets are
installed 'OnInit in the install procedure of PyAlaMode" calls
PluginMixing.InitPlugins() which loops through the loaded plugins and calls
their "Init" method so they can add their own widgets

The main issue I have with this implementation is that it is so tied into the Py framework that it's hard to follow the code flow or see exactly how it works. i.e. it seems various bits are scattered about the Py framework, rather than having a standalone implementation. I think we need something closer to a minimal sample if we're to review this for general inclusion into wxPython.

Also, BTW, why do you duplicate the entire Py framework? Wouldn't it be difficult for you to keep up with any changes to the wxPython version (i.e. bug-fixes, etc.) this way?

Regards,

Kevin

···

On Jan 10, 2007, at 11:42 PM, Philippe C. Martin wrote:

This first proposal simply installs new menus as the architecture would be the
same for other widgets ... I followed Kevin's suggestion to have a "Plugin"
menu automatically installed and all plugin menus installed under it ... I am
still debating as to whether this is flexible enough, but at least it keeps
multiple plugins from making the menu bar "too busy" ... cohabitation between
plugins is an issue I think.

Should all plugins be in the same hierarchy (as it is now) or should there be
a ways to have them spread around the file system / maybe the net ?

I am looking forward to receiving your feedback.

Regards,

Philippe

--
_________________________
Philippe C. Martin
www.snakecard.com
_________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

3

Hi Philippe,

> Hi,
>
> Please find at http://www.snakecard.com/PY my first PluginMixin
> proposal.
>
> It shows a minimum implementation in PyAlaMode:
>
> -) Py.Frame holds (for simplicity) the stub class PluginFrame wich
> would
> eventually disappear as the code would be inserted in wx.Frame =>
> the point
> is to have the prototype self-contained so it can run without touching
> wx.Frame until all agree
> -) Py.Frame holds the PluginMixing class which would eventually be
> moved to
> wx.PluginMixin
> -)Py.Frame derives from the stub class PluginFrame which in turn
> derives from
> wx.Frame and PluginMixin
> -) All plugins are loaded at the initialization of Py.Frame
> -) Once the frame is loaded and all other application's widgets are
> installed 'OnInit in the install procedure of PyAlaMode" calls
> PluginMixing.InitPlugins() which loops through the loaded plugins
> and calls
> their "Init" method so they can add their own widgets

The main issue I have with this implementation is that it is so tied
into the Py framework that it's hard to follow the code flow or see
exactly how it works. i.e. it seems various bits are scattered about
the Py framework, rather than having a standalone implementation. I
think we need something closer to a minimal sample if we're to review
this for general inclusion into wxPython.

Also, BTW, why do you duplicate the entire Py framework? Wouldn't it
be difficult for you to keep up with any changes to the wxPython
version (i.e. bug-fixes, etc.) this way?

Regards,

Kevin

> This first proposal simply installs new menus as the architecture
> would be the
> same for other widgets ... I followed Kevin's suggestion to have a
> "Plugin"
> menu automatically installed and all plugin menus installed under
> it ... I am
> still debating as to whether this is flexible enough, but at least
> it keeps
> multiple plugins from making the menu bar "too busy" ...
> cohabitation between
> plugins is an issue I think.
>
> Should all plugins be in the same hierarchy (as it is now) or
> should there be
> a ways to have them spread around the file system / maybe the net ?
>
>
> I am looking forward to receiving your feedback.
>
> Regards,
>
> Philippe
>
>
>
>
>
>
>
>
>
>
>
>
> --
> _________________________
> Philippe C. Martin
> www.snakecard.com
> _________________________
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
> For additional commands, e-mail: wxPython-users-
> help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Hi Kevin,

I did not explain myself correctly.

The reason the classes are in the Py framework is only so you can download and
the package right away without touching wx.
: PuginMixin will eventually be somewhere else (root of wx ?)

Also, BTW, why do you duplicate the entire Py framework? Wouldn't it
be difficult for you to keep up with any changes to the wxPython
version (i.e. bug-fixes, etc.) this way?

Not sure I understand: maybe the same confusion as above ?

So to reiterate:

Class MixinPlugin should be eventually in its own module/file (currently in
py.Frame)

Class PluginFrame is a stub (located again for simplicity in Py.Frame for
testing purpose) that should disappear as its code will be integrated in
wx.Frame itself.

So really, the Py Framework is not linked in anyway to this architecture.

Not sure I fully understand your concern ... am I making sense ?

Regards,

Philippe

···

On Tuesday 16 January 2007 20:23, Kevin Ollivier wrote:

On Jan 10, 2007, at 11:42 PM, Philippe C. Martin wrote:

--
_________________________
Philippe C. Martin
www.snakecard.com
_________________________

4

Hi guys,

As I need to get started I will do the following: implement evenrything I can
think of / need using the "architecture" of proposal #1.

If the functionalities are then to your liking, I will integrate the stub
PluginFrame class into wx.Frame and will present a package which shows not
link with the Py framework.

Regards,

Philippe

···

--
_________________________
Philippe C. Martin
www.snakecard.com
_________________________

5

Hi Philippe,

[snip]

Hi Kevin,

I did not explain myself correctly.

The reason the classes are in the Py framework is only so you can download and
the package right away without touching wx.
: PuginMixin will eventually be somewhere else (root of wx ?)

Also, BTW, why do you duplicate the entire Py framework? Wouldn't it
be difficult for you to keep up with any changes to the wxPython
version (i.e. bug-fixes, etc.) this way?

Not sure I understand: maybe the same confusion as above ?

So to reiterate:

Class MixinPlugin should be eventually in its own module/file (currently in
py.Frame)

Class PluginFrame is a stub (located again for simplicity in Py.Frame for
testing purpose) that should disappear as its code will be integrated in
wx.Frame itself.

So really, the Py Framework is not linked in anyway to this architecture.

Not sure I fully understand your concern ... am I making sense ?

As we're talking about contributing code to wxPython, what I am interested in seeing is a "Hello World" example of how the PluginMixin code you'd like to contribute would be used to allow a(ny) wx.Frame class to add a plugin menu and register plugins using a standardized system. This way Robin and I (or anyone else) can easily review and test only the code that is to be contributed. But since you've embedded your code in the Py framework, I need to go through each file in the Py framework looking for code that is part of the plugin code you want to contribute, and I have to have some understanding of how the Py framework works in order to see the flow of events in your code. The Py framework is hundreds, if not thousands, of lines of code that have nothing to do with this contribution, but yet I have to sift through all that to try and get a comprehensive picture of the code that you want to contribute.

I hope this is more clear. I really don't know how else to explain it but it is pretty much standard for contributors to not include any code that is irrelevant to the contribution when submitting code for review, and as you say, the Py framework is really not tied to this code at all.

Thanks,

Kevin

···

On Jan 16, 2007, at 4:46 AM, Philippe C. Martin wrote:

Regards,

Philippe

--
_________________________
Philippe C. Martin
www.snakecard.com
_________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

6

Hi Kevin,

Got it ... I'll ship that before Monday.

Regards,

Philippe

···

On Friday 19 January 2007 19:42, Kevin Ollivier wrote:

Hi Philippe,

On Jan 16, 2007, at 4:46 AM, Philippe C. Martin wrote:

[snip]

> Hi Kevin,
>
> I did not explain myself correctly.
>
> The reason the classes are in the Py framework is only so you can
> download and
> the package right away without touching wx.
>
> : PuginMixin will eventually be somewhere else (root of wx ?)
>>
>> Also, BTW, why do you duplicate the entire Py framework? Wouldn't it
>> be difficult for you to keep up with any changes to the wxPython
>> version (i.e. bug-fixes, etc.) this way?
>
> Not sure I understand: maybe the same confusion as above ?
>
> So to reiterate:
>
> Class MixinPlugin should be eventually in its own module/file
> (currently in
> py.Frame)
>
> Class PluginFrame is a stub (located again for simplicity in
> Py.Frame for
> testing purpose) that should disappear as its code will be
> integrated in
> wx.Frame itself.
>
>
>
> So really, the Py Framework is not linked in anyway to this
> architecture.
>
> Not sure I fully understand your concern ... am I making sense ?

As we're talking about contributing code to wxPython, what I am
interested in seeing is a "Hello World" example of how the
PluginMixin code you'd like to contribute would be used to allow a
(ny) wx.Frame class to add a plugin menu and register plugins using a
standardized system. This way Robin and I (or anyone else) can easily
review and test only the code that is to be contributed. But since
you've embedded your code in the Py framework, I need to go through
each file in the Py framework looking for code that is part of the
plugin code you want to contribute, and I have to have some
understanding of how the Py framework works in order to see the flow
of events in your code. The Py framework is hundreds, if not
thousands, of lines of code that have nothing to do with this
contribution, but yet I have to sift through all that to try and get
a comprehensive picture of the code that you want to contribute.

I hope this is more clear. I really don't know how else to explain it
but it is pretty much standard for contributors to not include any
code that is irrelevant to the contribution when submitting code for
review, and as you say, the Py framework is really not tied to this
code at all.

Thanks,

Kevin

> Regards,
>
> Philippe
>
>
>
>
>
>
>
>
> --
> _________________________
> Philippe C. Martin
> www.snakecard.com
> _________________________
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
> For additional commands, e-mail: wxPython-users-
> help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

--
_________________________
Philippe C. Martin
www.snakecard.com
_________________________

7

Kevin Ollivier wrote:

Hi Philippe,

Not sure I fully understand your concern ... am I making sense ?

As we're talking about contributing code to wxPython, what I am interested in seeing is a "Hello World" example of how the PluginMixin code you'd like to contribute would be used to allow a(ny) wx.Frame class to add a plugin menu and register plugins using a standardized system.

Specifically, the contrib should be a module or package implementing the plugin framework, and a module that demonstrates how it can be used. Preferably the demo should be something that can be dropped into the wxPython demo framework, but standalone demo apps are okay to begin with.

···

On Jan 16, 2007, at 4:46 AM, Philippe C. Martin wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

8

Hi Kevin,

At http://snakecard.com/pluginmixin/ , you'll find my proposal for the
pluginmixin.

1) The program creates a frame, requests for a plugin hierachy to be loaded
(note that many hierarchies may be installed)
2) each plugin (1 & 2) add menus ... pluginmixin will create the necessary
resources (ex: menubar) if they do not exist.

Let me know ...

Regards,

Philippe

···

--
_________________________
Philippe C. Martin
www.snakecard.com
_________________________

9

Hi Philippe,

Note that MixinPlugin expects the plugin to have an Init() method and then the Init() methods call AddPluginMenuItem on MixinPlugin. Why not have MixinPlugin immediately call a method on the plugin, e.g. GetPluginMenuItem, that returns the information MixinPlugin needs to add the menu item?

Cheers, Frank

···

2007/1/20, Philippe C. Martin pmartin@snakecard.com:

Hi Kevin,

At http://snakecard.com/pluginmixin/ , you’ll find my proposal for the
pluginmixin.