[visionegg] potential future changes

I recently posted this to <a href="http://www.visionegg.org/future.html";>. I thought I'd send it to everyone on the list as a "heads up", since you're presumably the ones to whom it matters most.

The future
----------

There is a (long) list of things that could be improved about the Vision Egg. For your information, here is a list of changes and additions I'm thinking about making to the Vision Egg. I've listed below several things which have have the potential to break code that already exists. If you feel strongly about any of these issues, please let me know.

If you want to pitch in and get your hands dirty, these changes will happen a lot more quickly! I'm currently quite busy, and may not get to any of these items for months.

Changing the default windowing system to wxPython from Tkinter
--------------------------------------------------------------

I like Tkinter because it is the unofficial GUI of Python and therefore is often included in binary distribution of Python. However, I have frequently been stumped by bugs in the Mac OS X port, often costing me days of productivity. Finally, doesn't look native on any platform.

I recently started using wxPython. wxPython has a large array of powerful widgets, better documentation, better demos, a more active user community, and just looks better.

Therefore, I propose to move the Vision Egg's GUI widgets elements to wxPython. Changing the initial startup screen to wxPython won't be much work, but probably doesn't matter that much either. More imporant is the EPhysGUI. If you've written your own plug-in modules for the EPhysGUI with Tkinter code, please let me know your feelings on this issue.

Requiring Python 2.2 or greater
-------------------------------

I have maintained the Vision Egg's compatibility with Python 2.1 because I saw no need to force users to upgrade to Python 2.2 or Python 2.3. However, there are a number of new features and performance boosts that could be gained by requiring Python 2.2. I think most users are probably already using Python 2.2.

In particular, I would like to follow the suggestions of PEP 290, "Code Migration and Modernization" .

Improving the type-checking system
----------------------------------
When an instance of the Stimulus class is created, all arguments are type-checked. (But they are not checked every time they are changed or when the stimulus is drawn.) Currently, the types module is used extensively, but this module will disapper in a future version of Python. Therefore, I propose to re-implement the type-checking system in a similar manner to the current version, but by specifying values with a type identifier. This proposed identifier would be VisionEgg.SequenceType , for example.

This has the additional advantage that it would eliminate unnecessary type restrictions. For example, in many cases, I have required a TupleType where any sequence would work. This should only affect users who have written their own Stimulus sub-classes, and should be fairly easy to update code. 

======================================
The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

Other related posts: