RE: [Pythoncard-users] preliminary grid success

> From: Jeff Turner
>
> i was able to port the grid and vcr widgets
> to work under the new components/ framework.
> a simple demo of using a grid is attached.
>
> i can work with grid.py two different ways:
>     - just drop it in components/
>         - this is the "standard" way
>     - keep it local, and explicitly import it

I do want to support a search path in the future, but this works. Because of
the way py2exe builds it is necessary do explicit imports of any widget an
app uses.

> the grid demo should be self-contained - it uses an explicit
> import.  it's almost as stunted as before, but it does
> convert clicks into SelectEvents now.  the second two
> grids don't do anything, but they are there because
> i soon want to demonstrate three
> different ways of supplying the data to the grid.

I don't see any documentation for wxGrid events, I guess I need to delve
into the source code for wxGrid or look at what Robin is doing in demo.py.
Are you using something else as a reference?

> here are some questions and observations that
> came up during the experiment:
>
> - how are GridSpec's "self.events.extend()" and Widget's _events
>   related?

Actually, I don't think the events attribute of the Spec is being used.
Rowland probably put it in there for completeness, but the _events variable
such as the following for the Button class
  _events = [ event.MouseClickEvent ] + event.MOUSE_EVENTS
is what is used to handle binding. I'll have to go back and look through the
framework again to verify this. For now, just continue providing events in
the spec as well.

>     - in list.py
> 	- ListSpec only extends with 'select', but
>         - List adds SelectEvent *and* MouseDobuleClickEvent
>         - should ListSpec add "doubleclick", too?

That is sort of a bug. mouseDoubleClick (there is nothing named
'doubleclick') is being used for two separate wxPython event types. ListSpec
doesn't need 'mouseDoubleClick' because it is already included in the
standard mouse events for all widgets.

I haven't looked at this since we first defined events in July. There is an
overlap for the double click between a wxMouseEvent and wxCommandEvent. The
wxMouseEvent has EVT_LEFT_DCLICK as the binding macro and wxEVT_LEFT_DCLICK
as the event generated. wxListBox also has a wxCommandEvent for a double
click, EVT_LISTBOX_DCLICK is the binding macro and
wxEVT_COMMAND_LISTBOX_DOUBLE_CLICKED is the event generated. This is
precisely the kind of event confusion that I was hoping to hide.

Your grid.py uses EVT_GRID_CELL_LEFT_DCLICK which appears to be similar to
what list.py is doing.

If the event handler doesn't expect to access the elements of the
wxCommandEvent or wxMouseEvent passed to the handler, then in the case of
List (wxListBox) it doesn't really matter which one is used, but it will
matter for other controls.

We need to support more events and a different binding methodology in order
to deal with all the events for a complex control such as wxTreeCtrl, which
has a separate class, wxTreeEvent for all the different event types. In
addition, we probably won't want to bind all events, but only those which
have handlers defined, so there will no longer be "unused events" as
reported by the Message Watcher.

Does this clear up the issue or just make it more confusing?

> - the import scheme masks syntax errors
>     - res.loadComponentModule should log the error
>     - makes it hard to find problems
> 	- only shows up as
>     - might have been a problem with the old import, too

We probably want something like this:

def loadComponentModule(moduleName):
    try:
        exec("from components import " + moduleName)
    except ImportError, e:
        log.error(e)
        raise ImportError
    else:
        log.debug("imported " + moduleName)

That doesn't cover all the possibilities, so there should be more except
blocks or the exception should be handled differently. I think an
ImportError is basically a show stopper since a missing component would lead
to a KeyError when the app later tries to instantiate a widget.

My Python skills are lacking in the exception handling area, so Python
wizards please step forward with a more complete solution.

> - can i develop a spec in the old "declarative" format?
>     - it's now python code
>     - composite widgets will want to

I switched to classes for the specs because it seems like a cleaner way of
handling subclassing and using the specs in other parts of the framework.
The current form is a bit of a hack in order to remain compatible with the
existing Spec handling in res.py. What we have now is actually pretty close
to the plain dictionary we used to use. What problems is the class form
causing you? In the future, the spec attributes should just be rolled into
the component class itself, but we have to migrate away from the old
Resource to Spec mangling in res.py first.

What are you proposing as an alternative?

> - how is GridSpec bound to Grid?
>     - is it implicit in GridSpec.name?
>     - is it implicint in that they are in the same file?

    _spec   = GridSpec()

is the important line in your Grid class.

> finally, if you want to add grid.py to the base distribution,
> what are the "minimum essential requirements"?  if there is
> interest, i will take responsibility for grid.py, at least
> until it is minimally useful.  there is
> a long todo list at the top of grid.py, to get things started,
> but not all of the items are critical

If you want, you can just include grid.py and your gridtest as a separate
sample. Then as it is fleshed out, grid.py can be moved into the components
directory. I'm sure a lot of people would love to have a grid control, but I
also know that wxGrid has generated quite a lot of questions on
wxPython-users and I have no experience with wxGrid, so I don't know how
much grief it may cause you. If it is just in a sample, then you can play
with the attributes, events, and methods, all you want without impacting any
other samples or apps users might write since it will clearly be
"experimental". As we move to direct subclasses of wxPython windows and
controls I expect your methods will change as well. You might want to go
ahead and use method names that match the wxGrid method when you aren't
providing additional capabilities. For example, the TextField widget has

    def canCopy( self ) :
        return self._delegate.CanCopy()

but in anticipation of TextField just being a direct subclass of wxTextCtrl,
the method should be named:

    def CanCopy( self ) :
        return self._delegate.CanCopy()

then when there is no longer a _delegate, the user code will still work
without any changes.

ka