pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] transitions

[Kevin A. <al...@se...>]

PythonCard is going through a number of transitions starting with
PythonCardPrototype release 0.5.3. I want to make sure that all the changes
are out in the open so anyone that wants to participate or comment can do
so. I'll try and provide a brief roadmap as well.

wxPython 2.3.1 and 2.3.2 and later
Release 0.5.3 added the wxTE_RICH text style to the TextArea widget, so
release 0.5.3 requires wxPython 2.3.1 or later. I'm already using wxPython
2.3.2b7 and once wxPython 2.3.2 final is released, I will be incorporating
some additional 2.3.2-specific features to the framework. 2.3.2 fixes
numerous bugs present in 2.3.1, including the menu accelerator bug which
prevents menu shortcuts from working.


wxPython as the only GUI toolkit
The original intent of the project was to wrap all the underlying GUI
toolkit API calls and events so that any number of toolkits might be used
later. The number of developers on the project simply won't support that
initial goal. In order to reduce the amount of code and overall complexity
of the framework I decided to reduce the supported GUI toolkits to just
wxPython and remove or refactor parts of the framework that simply duplicate
wxPython functionality with little or no added benefits. I've already
checked in one modification to the event dispatch mechanism so that the
actual event object passed to an event handler is the native wxPython event
object. The change is described in the following post:

http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/932492


Directly subclassing wxPython controls (widgets)
The biggest change that the user code (samples) are likely to see is if we
move the existing widgets from using wxPython classes as delegates (HAS A
relationship) to making widgets direct subclasses of wxPython classes (IS
A). Rowland is experimenting with this right now and we'll be discussing
this on the list more since it dramatically reduces the amount of code
necessary for a given widget class. PythonCard currently uses a naming
convention of lowercasing the first letter of a method, and many methods
such as the TextField getSelection method will no longer be needed:

    def getSelection( self ) :
        return self._delegate.GetSelection()

User code would just use GetSelection() if TextField was a subclass
wxTextCtrl.

Using the native wxPython class methods means that it will be easier to
refer to the existing wxPython documentation or auto-generate a variation of
the documentation specific to PythonCard.

We will continue to support dot notation for standard attributes, so in some
cases there will be overlap between wxPython methods and wrapper methods or
variables we provide to support dot notation.


Modular Widgets
In the last two weeks, we've talked about modularizing the widget.py file
and supporting user-defined widgets. Jeff Turner submitted some changes to
the framework to support modular widgets, but it hasn't been checked into
cvs. I'm currently working on splitting widget.py and incorporating some of
Jeff's code and ideas to support modular widgets and I'll discuss and check
these changes into cvs in the next week or so. Splitting up widget.py,
spec.py, and wxPython_binding.py shouldn't have any impact on user code such
as the samples.


Components
The discussion of modular widgets quickly switched to the idea of full-blown
components. Rowland has been working on a separate framework to support
components, but it is different enough that I'm recommending that it have
its own cvs tree and we develop in parallel in the short term. We can
incorporate pieces of the new framework into the existing one as it is
solidified or simply wait until Rowland's new code is up to at least the
level of the current framework before calling it the first real alpha
release of PythonCard.

ka

RE: [Pythoncard-users] components framework

[Kevin A. <al...@se...>]

> Also, we might want to think about using XML as the spec format.  Kevin
> mentioned supporting the wxWindows XML format.  I don't know if we could
> support it directly, but we could provide a translator that converted a
> wxWindows spec to a PythonCard spec.
>
> XML is obviously more verbose, but at least it's self-describing, and
> that can be a plus.

XML may be workable, but the wxWindows XML resource format is not suitable
for representing the spec, it is designed for loading wxWindows/wxPython
layouts and menus. The source code and associated README is the only real
documentation right now.

http://cvs.wxwindows.org/cgi-bin/viewcvs.cgi/wxWindows/contrib/src/xrc/

http://cvs.wxwindows.org/cgi-bin/viewcvs.cgi/wxWindows/contrib/src/xrc/FORMA
T.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup

demo.py included in wxPython includes a sample. See XML_Resource under
Window Layout.

There is no DTD for the XML resource format because a DTD apparently can't
describe all the format needs. The main benefit of using the wxWindows XML
resource format is to leverage other wxWindows layout tools such as
wxDesigner. Before we would be able to do that we will have to get more
involved so that the tools and resource format support classes other than
the base wxWindows classes. The format may also need to be enhanced to
support two-step initialization and names for non-window resource items such
as menus.

I would like to have a wxWindows/wxPython/PythonCard compatible resource
format, but a lot more work needs to be done at the wx-dev C++ level to make
this happen. We can use XML for the resource spec, but that is a separate
topic and for now I recommend using the dictionary/list format until we know
all our requirements and standardize the fields, type info, order, etc.

ka

Re: [Pythoncard-users] components framework

[Rowland S. <sn0...@ea...>]

On Monday, December 3, 2001, at 08:32 PM, Andy Todd wrote:

> A component architecture in PythonCard is a killer feature.
>
> I love components. I've played with Delphi and VB in the past and think 
> that at least some of their success stems from the ability to easily 
> combine standard, 3rd party and custom built components into complex 
> applications.
>
> However, a couple of points about Rowland's proposal below sprung to 
> mind.
>
> Do we need to know the 'type' of a component attribute? Given the 
> dynamic typing of Python wouldn't it be best to leave this out of the 
> specification. Having dynamically typed attributes should also 
> (theoretically) aid people who subclass components. I don't have a 
> strong opinion either way on this but thought I should at least mention 
> it. The same goes for component arguments. With arguments, should we 
> support the * and ** special cases?

One of the reasons for typing component attributes and methods is to 
support sophisticated visual tools that can present type-specific 
editors for attributes and method parameters.

I'm also playing with some connector classes that can be generated by a 
visual environment for wiring up events/attributes/methods between 
components, and the typing will probably come in handy here as well.

>
> XML. Hmm, I like the resource format we have at the moment. As 
> mentioned previously on the list, as soon as we put resources into an 
> XML format we lose the ability to edit by hand. If the only purpose is 
> to interoperate with the wxWindows format then my vote is to write a 
> parser and only invoke it when necessary. Having resources as native 
> Python parseable data types is a good thing, I think we should keep it

I prefer the dictionary format as well.  for the near term there's 
really no reason to go to XML.  I would prefer to work on more 
interesting stuff like components, etc. , than write XML->Python 
translators ;)


> Rowland Smith wrote:
>
>> I thought about some issues with doing a component model today.  I'm
>> thinking ahead to the model requirements that are necessary to support
>> visual tools.
>> We need to provide metadata about the attributes and methods of any
>> PythonCard component, as well as packaging the spec with the class 
>> that it describes, as Jeff Turner suggested.  Putting each component 
>> in it's own module is helpful for managing the components ( drop them 
>> in a directory ) as well as for organization - a component's module 
>> can contain the component class itself as well as any support classes 
>> and resources.
>> We need to add type information to both attribute and method 
>> definitions for visual tool support:
>> For attributes:
>>     name, type
>> For methods:
>>     name, # args, <arg-name, arg-type>, <return-type>
>> For example, right now we have the following in Button's spec.
>>     'label' : { 'presence' : 'mandatory' }
>> This would become something like
>>     'label' : { 'type' : 'string', 'presence' : 'mandatory' }
>> We then add a new section called 'methods'.  Each method entry contains
>> the name of the method, followed by an ordered list of args.  each arg
>> specifies the arguments name and type. A 'returns' element specifies 
>> the
>> return type, where None is like void in Java/C.
>> 'SetLabel' : {
>>     'args' : [ { 'name' : 'label', 'type' : 'string' } ],
>>     'returns' : None
>> }
>> Also, we might want to think about using XML as the spec format.  
>> Kevin mentioned supporting the wxWindows XML format.  I don't know if 
>> we could support it directly, but we could provide a translator that 
>> converted a wxWindows spec to a PythonCard spec.
>> XML is obviously more verbose, but at least it's self-describing, and 
>> that can be a plus.
>> I have an alternative framework that i'm using to test component 
>> registration, as well as a component model for PythonCard.  Below is 
>> an example for a Button component that extends wxPython and is self 
>> contained.
>> Button inherits component behavior from widget.Widget ( which extends 
>> component.Component, not shown ), and extends a wxPython Button.
>> A single event is defined, 'mouseClick'.
>> The component has a single attribute, 'label', of type 'string'.
>> A new class attribute, 'methods', has been added to define a 
>> component's public interface.
>> each method is described by name, argument names and types, and return 
>> type.
>> It's not shown below, but it might also be helpful to explicitly 
>> define whether a method is a getter/setter for a particular 
>> attribute.  This could be inferred from the method name, but might not 
>> work in all cases.  This would be useful for auto-magically binding 
>> dot notation for attributes.
>> ----------
> [snip example code]
>
> Regards,
> Andy
> -- 
> -----------------------------------------------------------------------
> From the desk of Andrew J Todd esq.
> "Another year older, still no wiser." - Me, on my birthday
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Re: [Pythoncard-users] why is the framework changing?

[Andy T. <an...@ha...>]

Kevin,

As silence counts as acceptance on this list I think your proposal is 
unanimously approved.

For what its worth, I don't mind exposing more of wxPython in the 
framework as long as it is as simple and pythonic as possible.

I'd like to echo your point below, as long as PythonCard is a powerful, 
but simple to use framework I believe it will be useful. Providing more 
meaningful and straight forward ways to build GUI applications can only 
be a good thing. We just need to focus on that goal and always apply the 
KISS principle. That way we may go down some dead ends but we will 
always be moving in the right direction. Simplicity for me has two 
meanings here; the code a developer writes to get a working application 
in PythonCard should be as simple as possible and the framework itself 
should be simple and easy to understand. I'll leave it to the TimBot to 
justify my ramblings;

"""
1. Beautiful is better than ugly.
2. Explicit is better than implicit.
3. Simple is better than complex.
4. Complex is better than complicated.
5. Flat is better than nested.
6. Sparse is better than dense.
7. Readability counts.
8. Special cases aren't special enough to break the rules.
9. Although practicality beats purity.
10. Errors should never pass silently.
11. Unless explicitly silenced.
12. In the face of ambiguity, refuse the temptation to guess.
13. There should be one -- and preferably only one -- obvious way to
do it.
14. Although that way may not be obvious at first unless you're
Dutch.
15. Now is better than never.
16. Although never is often better than *right* now.
17. If the implementation is hard to explain, it's a bad idea.
18. If the implementation is easy to explain, it may be a good idea.
19. Namespaces are one honking great idea -- let's do more of those!

     -- Tim Peters' 19 Pythonic Theses, 4 Jun 1999
"""

And yes, number 3 is my favourite.

Kevin Altis wrote:

> 0.5.3 is the last prototype release that will make any pretense of hiding
> wxPython. The changes that Rowland and I started checking into cvs today are
> going to expose wxPython directly. The main focus of these changes is to
> leverage the power of wxPython and provide helper classes and wrappers where
> needed to simplify some of the more difficult aspects of wxPython. I'll go
> into the details of these changes in another message. First I want to
> clarify the "why". This is a big deal for the future of PythonCard.
> 
> First of all, I see only two usable solutions for a cross-platform GUI
> toolkit for Python. Tkinter is the obvious choice because it ships with
> Python and works on just about every platform that Python runs on. For
> various reasons outlined in past messages to the list I don't like or want
> to use tkinter. The other solution is wxPython and that is where I'm putting
> my effort.
> 
> Last month I spent time trying to create interest in a wxPython-specific
> application framework. While the idea didn't get much attention on the
> wxPython-users list, at least from people willing to do development work, it
> did help my thinking about PythonCard. I still wanted PythonCard features
> such as resource files, default attribute initialization, automatic event
> binding, and dot notation attributes. I also wanted to use more of the
> wxPython classes without having to wrap them with PythonCard-specific
> classes and method names. If possible, I also wanted to be able to rely on
> the wxPython documentation for most of the classes rather than having to
> create a completely separate documentation set. The 'state of the framework
> messages' and 'future direction of PythonCard' threads on the list also
> helped focus my thinking. You might want to go and read through some of the
> archives.
> 
> In the end, it didn't seem like there was anything particularly bad or
> difficult about the wxPython events or classes. The problem is the code
> overhead and learning curve you have to climb in order to use them even for
> a simple app. Another big issue, is that the documentation is presented from
> the standpoint of C++ instead of Python. Robin has said that the
> documentation issue will be addressed sometime after 2.3.2 is released. That
> probably fits into the same Real Soon Now universe that the Mac wxPython
> port exists in, but I'm confident it will get done; wxPython Mac is
> compiling now, it just isn't running correctly.
> 
> So, while exposing wxPython is a major change in the framework and requires
> some reworking of the existing samples, I don't think it strays from the
> real purpose of PythonCard (to me at least), which is to create a powerful,
> but simple to use, cross-platform GUI software construction kit for Python.
> 
> This is an open source project, if you feel this move is bad and disagree
> with the direction we're taking, then you need to speak up. You can always
> use release 0.5.3 or any earlier releases for projects that you want to hide
> wxPython or to use as the basis for a framework that might work on top of
> another GUI toolkit such as tkinter. I won't be spending any effort in that
> direction. The PythonCardPrototype 0.5.3 zip is in the files section and all
> of the files are tagged as proto-0_5_3 in cvs, so anyone can go back to
> 0.5.3 if they need to.
> 
> ka
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Another year older, still no wiser." - Me, on my birthday

Re: [Pythoncard-users] components framework

[Andy T. <an...@ha...>]

A component architecture in PythonCard is a killer feature.

I love components. I've played with Delphi and VB in the past and think 
that at least some of their success stems from the ability to easily 
combine standard, 3rd party and custom built components into complex 
applications.

However, a couple of points about Rowland's proposal below sprung to mind.

Do we need to know the 'type' of a component attribute? Given the 
dynamic typing of Python wouldn't it be best to leave this out of the 
specification. Having dynamically typed attributes should also 
(theoretically) aid people who subclass components. I don't have a 
strong opinion either way on this but thought I should at least mention 
it. The same goes for component arguments. With arguments, should we 
support the * and ** special cases?

XML. Hmm, I like the resource format we have at the moment. As mentioned 
previously on the list, as soon as we put resources into an XML format 
we lose the ability to edit by hand. If the only purpose is to 
interoperate with the wxWindows format then my vote is to write a parser 
and only invoke it when necessary. Having resources as native Python 
parseable data types is a good thing, I think we should keep it.

Rowland Smith wrote:

> I thought about some issues with doing a component model today.  I'm
> thinking ahead to the model requirements that are necessary to support
> visual tools.
> 
> We need to provide metadata about the attributes and methods of any
> PythonCard component, as well as packaging the spec with the class that 
> it describes, as Jeff Turner suggested.  Putting each component in it's 
> own module is helpful for managing the components ( drop them in a 
> directory ) as well as for organization - a component's module can 
> contain the component class itself as well as any support classes and 
> resources.
> 
> We need to add type information to both attribute and method definitions 
> for visual tool support:
> 
> For attributes:
> 
>     name, type
> 
> For methods:
> 
>     name, # args, <arg-name, arg-type>, <return-type>
> 
> 
> For example, right now we have the following in Button's spec.
> 
>     'label' : { 'presence' : 'mandatory' }
> 
> This would become something like
> 
>     'label' : { 'type' : 'string', 'presence' : 'mandatory' }
> 
> We then add a new section called 'methods'.  Each method entry contains
> the name of the method, followed by an ordered list of args.  each arg
> specifies the arguments name and type. A 'returns' element specifies the
> return type, where None is like void in Java/C.
> 
> 'SetLabel' : {
>     'args' : [ { 'name' : 'label', 'type' : 'string' } ],
>     'returns' : None
> }
> 
> Also, we might want to think about using XML as the spec format.  Kevin 
> mentioned supporting the wxWindows XML format.  I don't know if we could 
> support it directly, but we could provide a translator that converted a 
> wxWindows spec to a PythonCard spec.
> 
> XML is obviously more verbose, but at least it's self-describing, and 
> that can be a plus.
> 
> I have an alternative framework that i'm using to test component 
> registration, as well as a component model for PythonCard.  Below is an 
> example for a Button component that extends wxPython and is self contained.
> 
> Button inherits component behavior from widget.Widget ( which extends 
> component.Component, not shown ), and extends a wxPython Button.
> 
> A single event is defined, 'mouseClick'.
> 
> The component has a single attribute, 'label', of type 'string'.
> 
> A new class attribute, 'methods', has been added to define a component's 
> public interface.
> 
> each method is described by name, argument names and types, and return 
> type.
> 
> It's not shown below, but it might also be helpful to explicitly define 
> whether a method is a getter/setter for a particular attribute.  This 
> could be inferred from the method name, but might not work in all cases. 
>  This would be useful for auto-magically binding dot notation for 
> attributes.
> 
> 
> ----------
[snip example code]
> 
> 
> 

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Another year older, still no wiser." - Me, on my birthday

RE: [Pythoncard-users] native wxPython events checked in

[Kevin A. <al...@se...>]

Some clarifications...

All events still go through a dispatcher. This way we can support event
'listeners' like the Message Watcher. It also allows us to bind some events
such as a mouse drag that are not explicitly defined in wxPython.

We will continue to use the simple event names already defined in spec.py
such as 'mouseClick', 'mouseDown', 'keyPress', etc. rather than using the
wxPython event macro names like wxEVT_COMMAND_BUTTON_CLICKED and
wxEVT_COMMAND_CHECKBOX_CLICKED; both of those macro names refer to a mouse
click in a control but different names are used in wxWindows/wxPython for
different controls. At some point, we will document the mapping of
PythonCard names to wxPython names for those people that need to debug some
complex wxPython logic or mix direct wxPython event bindings and those going
through the PythonCard dispatcher. The event name list will be expanded as
we start supporting more wxPython event types.

In addition, event handlers will continue to get the event source as the
second argument of the handler since that has proven to be very convenient.

These are some of the ways PythonCard hopefully simplifies the use of
wxPython events.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Monday, December 03, 2001 3:17 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] native wxPython events checked in
>
>
> cvs now has a slightly modified event dispatch that always sends native
> wxPython events to handlers. This impacted the following samples:
> dbBrowser,
> doodle, resourceEditor, textEditor, textRouter, and widgets. All
> occurances
> of skip() (lowercase) were changed to Skip() and getNativeEvent() is no
> longer used, since the native wxPython event info is now
> available directly.
> For example, here is the code in textRouter prior to the change:
>
>     def on_area1_keyPress(self, target, event):
>          nEvent = event.getNativeEvent()
>          if nEvent.GetKeyCode() == 9:
>              target.replaceSelection("\t")
>          else:
>              event.skip()
>
> Here's the new version:
>
>     def on_area1_keyPress(self, target, event):
>         if event.GetKeyCode() == 9:
>             target.replaceSelection("\t")
>         else:
>             event.Skip()
>
> The event being sent for keyPress is a wxKeyEvent, so you can look at the
> wxWindows/wxPython docs to see the properties and methods of the
> wxKeyEvent
> class. Here are the docs for GetKeyCode:
>
>
> "wxKeyEvent::GetKeyCode
> int GetKeyCode() const
>
> Returns the virtual key code. ASCII events return normal ASCII
> values, while
> non-ASCII events return values such as WXK_LEFT for the left
> cursor key. See
> Keycodes for a full list of the virtual key codes."
>
>
> Most of the time, a PythonCard handler doesn't need to access the event
> directly, which is why so few samples were impacted. Most of the handlers
> that did need to be fixed were dealing with key presses or tracking the
> mouse location during a mouse move or drag event. You can do
> diffs in cvs if
> you need to see detailed changes.
>
> ka

Re: [Pythoncard-users] components framework

[Rowland S. <ro...@we...>]

I thought about some issues with doing a component model today.  I'm
thinking ahead to the model requirements that are necessary to support
visual tools.

We need to provide metadata about the attributes and methods of any
PythonCard component, as well as packaging the spec with the class that 
it describes, as Jeff Turner suggested.  Putting each component in it's 
own module is helpful for managing the components ( drop them in a 
directory ) as well as for organization - a component's module can 
contain the component class itself as well as any support classes and 
resources.

We need to add type information to both attribute and method definitions 
for visual tool support:

For attributes:

     name, type

For methods:

     name, # args, <arg-name, arg-type>, <return-type>


For example, right now we have the following in Button's spec.

     'label' : { 'presence' : 'mandatory' }

This would become something like

     'label' : { 'type' : 'string', 'presence' : 'mandatory' }

We then add a new section called 'methods'.  Each method entry contains
the name of the method, followed by an ordered list of args.  each arg
specifies the arguments name and type. A 'returns' element specifies the
return type, where None is like void in Java/C.

'SetLabel' : {
     'args' : [ { 'name' : 'label', 'type' : 'string' } ],
     'returns' : None
}

Also, we might want to think about using XML as the spec format.  Kevin 
mentioned supporting the wxWindows XML format.  I don't know if we could 
support it directly, but we could provide a translator that converted a 
wxWindows spec to a PythonCard spec.

XML is obviously more verbose, but at least it's self-describing, and 
that can be a plus.

I have an alternative framework that i'm using to test component 
registration, as well as a component model for PythonCard.  Below is an 
example for a Button component that extends wxPython and is self contained.

Button inherits component behavior from widget.Widget ( which extends 
component.Component, not shown ), and extends a wxPython Button.

A single event is defined, 'mouseClick'.

The component has a single attribute, 'label', of type 'string'.

A new class attribute, 'methods', has been added to define a component's 
public interface.

each method is described by name, argument names and types, and return type.

It's not shown below, but it might also be helpful to explicitly define 
whether a method is a getter/setter for a particular attribute.  This 
could be inferred from the method name, but might not work in all cases. 
  This would be useful for auto-magically binding dot notation for 
attributes.


----------
from wxPython.wx import *

import widget

wxCLIP_SIBLINGS = 0x20000000

class Button( widget.Widget, wxButton ) :
     """
     A simple push-button with a label.
     """

     events = [ 'mouseClick' ]

     attributes = {
         'label' : { 'type' : 'string', 'presence' : 'mandatory' }
     }

     methods = {

         'SetLabel' : {
             'arguments' : [ { 'name' : 'label', 'type' : 'string' } ],
             'returns' : None
         }
     }

     def __init__( self, parent, resource ) :

         widget.Widget.__init__( self, parent, resource )

         r = resource

         wxButton.__init__( self,
                            self.parent,
                            self.getId(),
                            r.label,
                            wxPoint( r.position[ 0 ], r.position[ 1 ] ),
                            wxSize( r.size[ 0 ], r.size[ 1 ] ),
                            style = wxCLIP_SIBLINGS,
                            name = r.name )
         self._bindEvents()

     def _bindEvents( self ) :
         EVT_BUTTON( self.parent, self.getId(), self._dispatchClicked )

     def _dispatchClicked( self, event ) :
         self.fireEvent( 'mouseClicked', event )
---------------



-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
     quoted in the book
     A Word a Day

RE: [Pythoncard-users] components framework

[Patrick K. O'B. <po...@or...>]

That sounds *very* nice.

---
Patrick K. O'Brien
Orbtech.com - Your Source For Python Development Services


> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Monday, December 03, 2001 4:49 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] components framework
>
>
> Components are another big issue that was brought up in the app framework
> threads on wxPython-user. Windows COM is the most widely used form of
> components, but there are also other forms of components like JavaBeans.
> When Rowland and I started work on the very first pieces of
> PythonCard back
> in July a friend of ours pointed out that the only way we could create a
> framework with long-lasting appeal was by supporting a component model.
>
> There are a number of problems with trying to do components while
> trying to
> do something that works with multiple computer languages, across multiple
> operating systems, and multiple GUI toolkits, that makes a component model
> an almost impossible problem to solve.
>
> If you limit your solution space to a single language such as Python and a
> single GUI toolkit such as wxPython that already works across
> platforms then
> the problem space is limited enough that it appears to be doable,
> yet still
> powerful.
>
> Jeff Turner's message and code having to do with modularizing the
> organization of widgets rather than spreading out the class definitions,
> specs, and event bindings brought this issue back to the top of the
> framework issues. Rather than just modularizing the widgets, why not go
> ahead and turn them into components?
>
> Rowland is working on a component base that will let us treat the existing
> widgets as components and make it possible to build compound
> components and
> subclass standard components in the framework. This should also
> address the
> issue of an app having its own custom components.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

[Pythoncard-users] native wxPython events checked in

[Kevin A. <al...@se...>]

cvs now has a slightly modified event dispatch that always sends native
wxPython events to handlers. This impacted the following samples: dbBrowser,
doodle, resourceEditor, textEditor, textRouter, and widgets. All occurances
of skip() (lowercase) were changed to Skip() and getNativeEvent() is no
longer used, since the native wxPython event info is now available directly.
For example, here is the code in textRouter prior to the change:

    def on_area1_keyPress(self, target, event):
         nEvent = event.getNativeEvent()
         if nEvent.GetKeyCode() == 9:
             target.replaceSelection("\t")
         else:
             event.skip()

Here's the new version:

    def on_area1_keyPress(self, target, event):
        if event.GetKeyCode() == 9:
            target.replaceSelection("\t")
        else:
            event.Skip()

The event being sent for keyPress is a wxKeyEvent, so you can look at the
wxWindows/wxPython docs to see the properties and methods of the wxKeyEvent
class. Here are the docs for GetKeyCode:


"wxKeyEvent::GetKeyCode
int GetKeyCode() const

Returns the virtual key code. ASCII events return normal ASCII values, while
non-ASCII events return values such as WXK_LEFT for the left cursor key. See
Keycodes for a full list of the virtual key codes."


Most of the time, a PythonCard handler doesn't need to access the event
directly, which is why so few samples were impacted. Most of the handlers
that did need to be fixed were dealing with key presses or tracking the
mouse location during a mouse move or drag event. You can do diffs in cvs if
you need to see detailed changes.

ka

[Pythoncard-users] components framework

[Kevin A. <al...@se...>]

Components are another big issue that was brought up in the app framework
threads on wxPython-user. Windows COM is the most widely used form of
components, but there are also other forms of components like JavaBeans.
When Rowland and I started work on the very first pieces of PythonCard back
in July a friend of ours pointed out that the only way we could create a
framework with long-lasting appeal was by supporting a component model.

There are a number of problems with trying to do components while trying to
do something that works with multiple computer languages, across multiple
operating systems, and multiple GUI toolkits, that makes a component model
an almost impossible problem to solve.

If you limit your solution space to a single language such as Python and a
single GUI toolkit such as wxPython that already works across platforms then
the problem space is limited enough that it appears to be doable, yet still
powerful.

Jeff Turner's message and code having to do with modularizing the
organization of widgets rather than spreading out the class definitions,
specs, and event bindings brought this issue back to the top of the
framework issues. Rather than just modularizing the widgets, why not go
ahead and turn them into components?

Rowland is working on a component base that will let us treat the existing
widgets as components and make it possible to build compound components and
subclass standard components in the framework. This should also address the
issue of an app having its own custom components.

ka

[Pythoncard-users] why is the framework changing?

[Kevin A. <al...@se...>]

0.5.3 is the last prototype release that will make any pretense of hiding
wxPython. The changes that Rowland and I started checking into cvs today are
going to expose wxPython directly. The main focus of these changes is to
leverage the power of wxPython and provide helper classes and wrappers where
needed to simplify some of the more difficult aspects of wxPython. I'll go
into the details of these changes in another message. First I want to
clarify the "why". This is a big deal for the future of PythonCard.

First of all, I see only two usable solutions for a cross-platform GUI
toolkit for Python. Tkinter is the obvious choice because it ships with
Python and works on just about every platform that Python runs on. For
various reasons outlined in past messages to the list I don't like or want
to use tkinter. The other solution is wxPython and that is where I'm putting
my effort.

Last month I spent time trying to create interest in a wxPython-specific
application framework. While the idea didn't get much attention on the
wxPython-users list, at least from people willing to do development work, it
did help my thinking about PythonCard. I still wanted PythonCard features
such as resource files, default attribute initialization, automatic event
binding, and dot notation attributes. I also wanted to use more of the
wxPython classes without having to wrap them with PythonCard-specific
classes and method names. If possible, I also wanted to be able to rely on
the wxPython documentation for most of the classes rather than having to
create a completely separate documentation set. The 'state of the framework
messages' and 'future direction of PythonCard' threads on the list also
helped focus my thinking. You might want to go and read through some of the
archives.

In the end, it didn't seem like there was anything particularly bad or
difficult about the wxPython events or classes. The problem is the code
overhead and learning curve you have to climb in order to use them even for
a simple app. Another big issue, is that the documentation is presented from
the standpoint of C++ instead of Python. Robin has said that the
documentation issue will be addressed sometime after 2.3.2 is released. That
probably fits into the same Real Soon Now universe that the Mac wxPython
port exists in, but I'm confident it will get done; wxPython Mac is
compiling now, it just isn't running correctly.

So, while exposing wxPython is a major change in the framework and requires
some reworking of the existing samples, I don't think it strays from the
real purpose of PythonCard (to me at least), which is to create a powerful,
but simple to use, cross-platform GUI software construction kit for Python.

This is an open source project, if you feel this move is bad and disagree
with the direction we're taking, then you need to speak up. You can always
use release 0.5.3 or any earlier releases for projects that you want to hide
wxPython or to use as the basis for a framework that might work on top of
another GUI toolkit such as tkinter. I won't be spending any effort in that
direction. The PythonCardPrototype 0.5.3 zip is in the files section and all
of the files are tagged as proto-0_5_3 in cvs, so anyone can go back to
0.5.3 if they need to.

ka

[Pythoncard-users] PythonCardPrototype release 0.5.3

[Kevin A. <al...@se...>]

You can get the latest PythonCardPrototype at:
http://sourceforge.net/project/showfiles.php?group_id=19015

Remember to backup or just delete your old PythonCardPrototype directory
before installing a new version, so that the old files aren't still in the
package directory. As always, report any problems to the list.

Release 0.5.3 2001-11-30
*** wxPython 2.3.1 or later is now required to use PythonCard ***
added assert wxc.__version__ >= "2.3.1" to model.py
changed TextArea to use wxTE_RICH style
  modified getStringSelection, replaceSelection code
  updated samples that were counting newlines for find operations
fixed assertion error with FontDialog
added getString method to TextField and its subclasses
changed FindDialog so that it automatically selects the search text
  and sets the focus to the search field when the dialog comes up
numerous textEditor sample changes
  New and Save menu items
  reworked all the file operations so the user has a chance to save changes
  filename and line number arguments are accepted on the command-line
  Find Next and Go To
commented out 'file' reference in Pyker.hta
added setBackColor('white') to reset method in BitmapTurtle
modified turtle sample
  added a check to sync the auto refresh state after drawing with
  the turtle sample and removed the Refresh menu item
added more sample screen shots to web site
added a new documentation page
  http://pythoncard.sourceforge.net/toc.html
findfiles updated
  commented out the directory list, moved other widgets to the right
  added open and save as menu items
  fixed file launching using textEditor.pyw to do the launching
updated samples.py to properly launch textEditor.pyw
removed KillFocus from widget.py
added getStringSelection/setStringSelection to Choice widget
  and added check for type of selection in setSelection
changed all _getDelegate() references to _delegate
changed all _getParent() references to _parent
changed the default selection for Choice, List, and RadioButton to None
updated setSelection in Choice, List, and RadioButton to accept either
  an integer or a string or None
fixed some assertion bugs with the Property Editor

ka

[Pythoncard-users] making PythonCard events just wxPython events

[Kevin A. <al...@se...>]

Rowland and I were discussing the requirements for reworking the current
PythonCard event system. The transcript is below. Since we're considering
several major changes I'm going to go ahead and tag what's in cvs as version
0.5.3 before starting in on the changes. The event system change won't have
a major impact on the current samples, we'll still be doing
on_widgetName_eventName, but it is a major change to the framework.
Splitting widget.py into separate files of "components" is also a big
change. I'll go ahead and do a 0.5.3 zip later today. *** 0.5.3 will require
wxPython 2.3.1 or later ***

This event system change is going to bind PythonCard pretty tightly to
wxPython. As I've mentioned in other messages, I don't have a problem with
that. If you have some issues with PythonCard only working on top of
wxPython, now is the time to speak up.

ka
---

altis: PythonCard events are wxPython events

altis: PythonCard event names for handlers stay the same, mouseClick,
keyDown

altis: a dispatcher is still used in order to support a Message Watcher or
other listeners

altis: and provide the target of an event in addition to the native event

altis: there should be a way of binding events at runtime such as
bindEvent(self.components.btnRun, 'mouseClick') or
bindEvent(self.components.btnRun, 'mouseClick',
self._handlers['on_btnRun_mouseClick']

altis: so that's a place where we could be more general in our even binding,
so that the autobinding of on_name_event is a specific case, but actually
you could bind an event name to any method

altis: that would allow for binding outside the main background class and is
probably the right thing to do

altis: any helper methods such as posting an event would also use the
shortcut names like 'mouseClick'

altis: the event names have to be expanded to include "close", "size" "idle"
and many other common events
Rowland Smith: what do you mean by 'expanded'?
altis: right now we don't handle close and size events

altis: question, should we ditch the message hierarchy and just support
binding the same handler to multiple widgets, menus, widgets directly?
altis: explicit versus implicit
altis: so explicit is probably better

altis: your command events probably have to be reworked

Rowland Smith: does explicit mean if it's not bound nobody sees it - i.e. no
hierarchy
altis: i was thinking explicity would mean there isn't a hierarchy search,
either you bind buttons 1 - 9 to handle on_mouseClick or they don't get
handled, so no implicity background and stack handlers
Rowland Smith: i think javabeans and other models just use explicit
binding - a message is only fired to bound handlers
altis: i'm fine with it, yet another deviation from hypercard and that's
fine too

Re: [Pythoncard-users] splitting widget.py into multiple files

[Rowland S. <ro...@we...>]

Kevin Altis wrote:

> Jeff has made a good point about modularizing the current widget
> organization. Right now, all the widgets are defined in widget.py and other
> related elements are in spec.py, event.py, wxPython_binding.py. Part of the
> reason I went to the trouble of cleaning up the import statements in the
> framework was to simplify breaking widget.py up into separate modules, which
> I've wanted to do for a long time. Ideally, it would be nice to have one
> widget class per module file or to put all related widgets in a file. For
> example, TextField, PasswordField, and TextArea are all related text field
> classes.
> 
> I don't actually know how to do a sub-package for the widget modules or what
> impact this would have on the rest of the framework. Sometimes, there are
> references to a widget class such as:
>   PythonCardPrototype.widget.Button
> 
> Ideally, rather than needing explicit imports, maybe the import statements
> could be wrapped in a for loop to import all of the modules in a widget
> directory? That would allow you to add additional widget modules without
> changing the rest of the framework. I need some help and suggestions from
> the Python wizards here.


Not sure how to do it, but I vote for this solution.  Dynamic loading of 
the widget library would be sweet.


> If we can do a reasonable split of widget.py, then the next step is to
> incorporate Jeff's ideas so that the spec and event classes specific to a
> given widget are contained in its module. Each widget module could also
> contain its own unit tests, which would be very nice.


Yep, this sounds good to me.  I'd be glad to help on this one.  I 
haven't looked at Jeff's code yet but it sounds like he's on the right 
track.


> These changes would move us much closer to treating widgets like real
> components.
> 
> I think for py2exe to process the files correctly, you need real import
> statements, you can't rely on the framework doing some magic parsing of each
> module.
> 
> I'm still trying to grok Jeff's code, so some or all of the answers to the
> questions above may be waiting in his code.
> 
> ka
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 



-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day

[Pythoncard-users] splitting widget.py into multiple files

[Kevin A. <al...@se...>]

Jeff has made a good point about modularizing the current widget
organization. Right now, all the widgets are defined in widget.py and other
related elements are in spec.py, event.py, wxPython_binding.py. Part of the
reason I went to the trouble of cleaning up the import statements in the
framework was to simplify breaking widget.py up into separate modules, which
I've wanted to do for a long time. Ideally, it would be nice to have one
widget class per module file or to put all related widgets in a file. For
example, TextField, PasswordField, and TextArea are all related text field
classes.

I don't actually know how to do a sub-package for the widget modules or what
impact this would have on the rest of the framework. Sometimes, there are
references to a widget class such as:
  PythonCardPrototype.widget.Button

Ideally, rather than needing explicit imports, maybe the import statements
could be wrapped in a for loop to import all of the modules in a widget
directory? That would allow you to add additional widget modules without
changing the rest of the framework. I need some help and suggestions from
the Python wizards here.

If we can do a reasonable split of widget.py, then the next step is to
incorporate Jeff's ideas so that the spec and event classes specific to a
given widget are contained in its module. Each widget module could also
contain its own unit tests, which would be very nice.

These changes would move us much closer to treating widgets like real
components.

I think for py2exe to process the files correctly, you need real import
statements, you can't rely on the framework doing some magic parsing of each
module.

I'm still trying to grok Jeff's code, so some or all of the answers to the
questions above may be waiting in his code.

ka

[Pythoncard-users] findFiles update, wrapped lines, platform specific options

[Kevin A. <al...@se...>]

Time for the morning ramble...

I've been doing lots of cleanup in the framework and samples.

I hadn't looked at the findFiles sample since I first slapped it together
and it wouldn't even run. This is one of those samples that I found useful,
but I stopped using it because I wanted it to do a lot more and got out of
the habit of using it. Now it not only works (or should work), but it can
open and save .grep files just like the PythonWin IDE. I also added a
feature to load a file with the textEditor sample and jump to a particular
line when you double-click on line in the result list. So, now the sample is
at least useful again (okay, useful to me).

It turns out that the following methods in the wxPython wxTextCtrl (the
PythonCard versions of these methods are in parens:
  GetNumberOfLines (getNumberOfLines)
  GetLineLength    (getLineLength)
  GetLineText      (getLineText)
  PositionToXY     (positionToXY)
  XYToPosition     (xyToPosition)

all count a wrapped line in their calculations under Windows, but not on
Linux; the Linux wxTextCtrl does all its calculations based just on
newlines. If you use the wxHSCROLL (horizontal scrollbar) style under
Windows, then text won't wrap and the method results will always match
Linux. The horizontal scrollbar does not show up under Windows unless the
longest line in the control is wider than the control width; Linux (GTK)
never shows a horizontal scrollbar.

I think I'm going to add an attribute to TextArea called "hscroll" which can
be 1 (true) or 0 (false). Under Linux, if this attribute is true it will
have no effect. I haven't added it yet, because I would prefer to have a
solution to toggle the horizontal scrollbar and wrapping and I don't know
how to pull that off. Also, I think this is the first attribute that is
Windows specific and we should probably have a clear naming convention for
platform specific methods and attributes.

For now, if you are using the textEditor sample under Windows and it goes to
the wrong line on a Go To, it is most likely because of line wrapping.

Vadim (wx-dev) confirmed that as of 2.3.2 there is no way to suppress style
info when pasting styled text or doing a drag and drop into a wxTextCtrl, so
we'll just have to live with that limitation in TextArea.

ka

[Pythoncard-users] patch to support "modular widgets"

[Jeff T. <sjt...@ya...>]

Here's the patch i mentioned last night (made against fresh cvs
trunk at 0830 EST today, 11/29).  It is a modification
to PythonCard to support "modular, self-describing" widgets
(i.e., bundle the class, spec, and event bindings in a single file).
Much more detail below.

I hope this change (or something like it) can be added to PythonCard.
Most of my interesting ideas about PythonCard involve nonstandard or 
composite widgets, which are difficult to quickly prototype, clone,
mod, ..., when i have to touch three different files.

Comments are welcome.  I tried to make the changes as unobtrusive, and
obvious, as possible.  If the code, or this rationale, are not lucid,
let me know.  (I'll go get my asbestos suit from the dry cleaner).
I'm on the mailing list, so you don't have to cc: me.


How to apply the patch
----------------------

I finally created the patch by checking out another copy of PythonCard,
and doing a regular, local diff:

$ cd <myworkingdir>/PythonCardPrototype
$ diff -c -N ../../pythoncard-cvs/PythonCardPrototype . >
../mod-widgets.patch


I was able to patch it into a fresh PythonCardPrototype and run it:

$ cd <newdir>/PythonCardPrototype
$ patch < ../mod-widgets.patch

Then, make sure the new version is the only one on your PYTHONPATH,
and try the examples.

Note: it will be obvious that the idea is not fully fleshed out.
      In particular, there are no awesome new modular widgets yet.
      However, i only have a couple hours a week to play, and
      i have been spending most of that just trying to keep up
      with the cvs tree, rather than making progress on my apps.
      
I have not had a chance to test it on windows, but I don't think
there should be any issues.



Patch manifest:
---------------
     modified files: (see change details, below)
	spec.py
	res.py
	binding.py
     new files:
	WidgetLoader.py
	NOTES.modular widgets (this file)



Refactoring PyCard to support modular widgets
---------------------------------------------

This is an experiment to support loading widgets that are not
part of the standard widget library.  Each widget is self-contained.

The main inspiration for this work was how hard it was for me to
create a fairly simple composite widget that i wanted to reuse.
But, now that it works, there's a lot we can do with it.

For this experment, the widgets must be in the same directory
as the app (i.e., the widget path is [ "." ]).  That will be easy
to change, to support local libraries, dynamic exchange of widgets,
dynamic creation of composite widgets, etc.


Examples
--------

The are two examples right now:
    - "modular"		extremely simple
    - "halfassgrid"	more interesting, but extremely immature

"modular" is a slight modification of the "minimal" app,
but uses a local MyTextField, instead of TextField.  It really
just shows that it can be done, and may be a guide for starting 
other widgets.

"halfassgrid" is the start of wrapping the wxGrid.  But, it just
barely works.  There's a ton of work to do on it.  Again, it's really
just an example of how you would get started prototyping a wrapper.

I have a couple of others (including a pretty flexible VCR control),
but they need to bake some more.



Overview of changes
-------------------

Right now, a widget is composed of three main pieces:

	- the main class		typically wraps a wx widget
					(usually found in widget.py)
	- a "spec"			metadata, including slots, 
					events it wants from toolkit, ...
					(usually found in spec.py)
	- event adapter			translate events from toolkit to
					the PythonCard event system
					(usually found in wxPython_binding.py)

In PythonCard, these three pieces are found in three different files,
and it is somewhat of a hassle to add a new one.

This patch allows you to put all three pieces in a single .py file,
that is loaded on-demand.


This first change puts all three components in a single file,
and hacks the main application file (e.g., AudioNotesTool.py) to 
"register" each component with its respective subsystem, *before*
creating the PythonCardApp.

Note that the _spec must now include a _class slot, in the
'info' section.  It should point to the new widget class, e.g.

          'info': {
              'parent' : 'Widget',
              '_class' : Grid,
	      ...



Limitations/Disadvantages
-------------------------

1) The main disadvantage that i can think of is that there's no single
   place you can go to get all specs, or even the complete list of
   widgets you have available.

   This limitation should be easily resolvable with a simple tool,
   though, that either just grabs them and stuffs them in a single
file,
   or generates some pretty pydoc-style html

2) More difficult to do a mass-refactor (like changing _getDelegate()
   to _delegate).

3) I'm not sure I understand py2exe, so i don't know what will be
   involved in ensuring that all necessary widgets are included
   in a standalone app.  It may require some sort of "rsrc analyzer"?

4) Does not do "recursive lazy-load", but should.
   spec.py says that TextField must come before PasswordField.
   If you lazy-load a widget whose parent is not yet loaded, i think
   things will fall apart.
   Should be fixable - just try again, with the parent.  I'll
   look into this

5) It's not clear that putting all event adapters in the file is
   a great idea (same problem as what to do with I18N translation
   files, i think).  Eventually, the two should be split, and some way
   added to look up or fetch adapters for the widget/toolkit
   combination.  It may be a non-issue though, if wx is the only kit.



Change Details
--------------

WidgetLoader.py		

	new file.  tries to look up Widgets on special _widget_path

res.py			

	Spec.getEntry():    changed
		if a ComponentSpec is not found the usual way,
		try lazy-loading it using the WidgetLoader
	Spec.tryLazyLoad(widgetModuleName): new
		call WidgetLoader to try loading the 
	Spec.addEntry(componentSpec):    new
		ability to "register" new specs on-the-fly.
		merges contents from parent
	Spec.addEntryForSpec(specDict): new
		wrapper around addEntry()
	Spec._mergeContentsFromParentSpec(): new
		does the same thing as mergeContents(), but
		starts with ComponentSpecs versus dictionaries

widget.py

	WidgeFactory.createWidget():
		if widget class is not found the "normal" way,
		can Spec entries to see if it has been lazy-loaded


binding.py
	
	add an adapterRegistry: maps from <toolkit>_<className>
		to a subclass of EventBinding
	add registerAdapter()
	EventBinding.__init__()
		check the registry for adapters, before checking
		the standard library of adapters


TODO
----

- unit tests
    - no _spec in .py          - fail gracefully
    - no _eventBindings        - make sure warning shows up in log
    - no _eventBindings["key"] - make sure warning shows up in log
    - make sure there's no "fault" the second time through
	- need rsrc that creates two grids

- tool to gather all _specs into a single documentation set

- can add other metadata to the widget module:
    - what icon to show on a palette, ...


__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

[Pythoncard-users] new documentation links page

[Kevin A. <al...@se...>]

I was going to add the "state of the framework" messages to cvs along with
some other documentation emails from the list archives. After starting the
process I decided it would be better to just start listing the best messages
from the mailing list on a web page until somebody writes up some better
documentation. So, the Documentation link on the home page:

  http://pythoncard.sourceforge.net/

now points to:

  http://pythoncard.sourceforge.net/toc.html

and that points to the not very useful Getting Started page. I will be so
happy if somebody puts together a better getting started page or two.

I made links to all of the "state of the framework" posts and finally I
added a link to the changelog.txt file in cvs.

Suggestions for additional links or content are welcome. There are at least
a few messages in the archives that I've referred to multiple times, so I'll
probably scan back through the archives during the next week looking for
particularly useful ones.

ka

Re: [Pythoncard-users] help making a CVS patch from anonymous checkout

[Andy T. <an...@ha...>]

Jeff,

Jeff Turner wrote:

 > does anyone here have any experience  creating a cvs patch (on
 > linux, if that matters) that includes a brand new file?


I'm not a CVS expert but I'll tip in my $0.02. From my research you can
only 'patch' existing files.

 >
 > i would like to submit the patch for review, but can't seem to get
 > the new file included. i always just get a "? WidgetLoader.py" from
 >  cvs diff.


CVS will give you a '?' when it knows nothing about a file. It will not
look at a file unless you tell it what to do (by, for instance, adding
it to the repository).

 > (the rest of the patch looks good, though) it seems like cvs may be
 > expecting the file to be added before i can make the diff, which is
 >  impossible (since my checkout was anonymous)


Since you are an anonymous user probably the best bet is to provide a 
'cvs diff' of the files you have changed and then also include any new 
files in the package you supply.

 >
 > any clues would be appreciated.
 >
 > thanks, jeff
 >

According to Cederqvist
(http://www.cvshome.org/docs/manual/cvs_16.html#SEC129) there is a -N 
option to 'diff' but it doesn't appear to do much when I try it. Perhaps 
a patch guru on the list can cast a brighter light on your problem.

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Another year older, still no wiser." - Me, on my birthday

RE: [Pythoncard-users] help making a CVS patch from anonymous checkout

[Kevin A. <al...@se...>]

Jeff, you can't add files to the PythonCard cvs directory unless you are a
developer.

To add a file to cvs I generally use:
"cvs add filename" or "cvs add -kb filename" (if the file is binary) and
then a "cvs commit"

You can email your file and I'll take a look at it. What is it supposed to
do?

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Jeff
> Turner
> Sent: Wednesday, November 28, 2001 3:39 PM
> To: pyt...@li...
> Subject: [Pythoncard-users] help making a CVS patch from anonymous
> checkout
>
>
> does anyone here have any experience
> creating a cvs patch (on linux, if that matters)
> that includes a brand new file?
>
> i would like to submit the patch for review,
> but can't seem to get the new file included.
> i always just get a "? WidgetLoader.py" from cvs diff.
> (the rest of the patch looks good, though)
> it seems like cvs may be expecting the file to be
> added before i can make the diff, which is impossible
> (since my checkout was anonymous)
>
> any clues would be appreciated.
>
> thanks,
> jeff
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
> http://geocities.yahoo.com/ps/info1
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] help making a CVS patch from anonymous checkout

[Jeff T. <sjt...@ya...>]

does anyone here have any experience 
creating a cvs patch (on linux, if that matters)
that includes a brand new file?

i would like to submit the patch for review,
but can't seem to get the new file included.
i always just get a "? WidgetLoader.py" from cvs diff.
(the rest of the patch looks good, though)
it seems like cvs may be expecting the file to be
added before i can make the diff, which is impossible
(since my checkout was anonymous)

any clues would be appreciated.

thanks,
jeff

__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

Re: [Pythoncard-users] textEditor sample upgrades

[Neil H. <ne...@sc...>]

Kevin Altis:

> I will add a Replace dialog once we are using wxPython 2.3.2. I also
> need to work out how I'm going to do whole word matches in the
> text. I don't think there is an option just using a plain Python string
> operation, so I probably have to resort to using a regular expression.
> Perhaps some text wizard like Neil will enlighten me. :)

   Regular expressions can be used but I find them confusing. If you want to
combine a user entered string with a regular expression search then you need
to check the user string for regular expression metacharacters and quote
them.

   A wizard's hat is reasonably similar to a dunce's cap so I chose the
essentially dumb approach of looping, searching for the string and if found
checking if the match is a word. If it is then report success, else try
again. You can define a word in many ways, often as starting and ending with
a character from the set of word characters (often A-Za-z0-9) and with the
characters before and after the match not being from this set.

   Scintilla's concept of a word is a little more complex than that but that
is because it wants to do a good job on programming text where sequences of
punctuation such as "->" or identifiers next to punctuation such as ".text"
make good "word" searches.

   Neil

[Pythoncard-users] assertion errors

[Kevin A. <al...@se...>]

I've started looking into assertion errors in the framework and samples. I
just fixed the FontDialog assertion that occurs if you Cancel a Font Dialog
rather than clicking okay. To see assert errors you need to be running a
hybrid version of wxPython such as 2.3.2b7.

Please email the list or submit a bug report
http://sourceforge.net/tracker/?atid=119015&group_id=19015&func=browse
for any assertion errors or memory leaks you find.

ka

[Pythoncard-users] textEditor sample upgrades

[Kevin A. <al...@se...>]

Now that the TextArea widget uses the RichEdit control and can work with
files larger than 32K I decided to upgrade the textEditor sample. The
version in cvs has:
  New and Save menu items
  a documentChanged flag
  a filename argument is accepted on the command-line

I reworked all the file operations so the user has a chance to save changes.
The logic can be confusing sometimes, but I think it is working pretty much
like the Windows Notepad application as far as the new/open/save/save
as/exit logic is concerned.

I will add a Replace dialog once we are using wxPython 2.3.2. I also need to
work out how I'm going to do whole word matches in the text. I don't think
there is an option just using a plain Python string operation, so I probably
have to resort to using a regular expression. Perhaps some text wizard like
Neil will enlighten me. :)

Remember to only work on backup copies of files in case there are bugs.
However, I do appreciate any feedback I can get.

The next step is to cleanup and refactor the code so there is a real
document model and then see how it can be abstracted for other apps and what
similarities it has to the addresses sample.

ka

[Pythoncard-users] building a PythonCard standalone EXE with py2exe

[Kevin A. <al...@se...>]

Simon has added some docs for building textRouter with py2exe. These
instructions are applicable to other PythonCard samples, so if you want to
build a standalone Windows EXE for any sample, then the setup.py file and
instructions below should be helpful. Most samples don't have an icon so
that option can be omitted. The data_files section should be changed to
include any resource files, readme.txt or data files needed by the sample.

The --excludes=Image option is to keep the Python Imaging Library (PIL) from
being included, which also prevents Tkinter from being included. None of the
samples use the PIL conversion routines, but if you needed them a different
command-line would be necessary. Thomas sent me some email about this issue,
but I haven't done any experimentation to find the right combination of
imports and excludes to exclude Tkinter, but include the parts of PIL needed
for conversions.

See http://py2exe.sourceforge.net/ for a complete list of options.

ka
---

how_to_build.txt:
Building a Windows EXE using 'py2exe'.

All you have to do, once everything is installed, is just type:

c:\path\to\tr> python setup.py py2exe -w --icon tr.ico --excludes=Image -O1

in the PythonCardPrototype/samples/textRouter directory.


setup.py:
from distutils.core import setup
import py2exe

setup( name = "textRouter",
       scripts = ["textRouter.py"],
       data_files = [ ("docs",
		      ["docs/textRouter_help.html", "docs/readme.html"]),
                      (".",
                      ["strings.txt", "readme.txt", "textRouter.rsrc.py",
                       "tr.ico"])
                    ]
       )