pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] nasty size bug exposed

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

Normally, I don't go into the details of a bug fix, but this is starting to
look like a big one that is going to impact more than the resourceEditor, so
I'm going to detail it here.

Almost since the first version of the resourceEditor was created there has
been a strange bug that caused the sizing handles to be positioned
incorrectly but not all the time. I noticed today that the problem could
definitely be reproduced for some widgets if the View Attributes menu was
used and I traced the problem to the widgetAttributes method:

        size = getattr(aWidget, 'size')
        if aWidget.__class__.__name__ != 'BitmapCanvas':
            bestWidth, bestHeight = aWidget._delegate.GetBestSize()
            if bestWidth == size[0]:
                size[0] = -1
            if bestHeight == size[1]:
                size[1] = -1
        if size != (-1, -1):
            dStr += "    'size':%s, \n" % size

The problem is that size should be a tuple such as (10, 10) but it isn't and
in addition the line:

        size = getattr(aWidget, 'size')

means that size isn't really a local variable copy of the widget size, but
instead points to the same memory because size is a list, so any changes to
size also change the widget size as a side-effect. And that was what was
causing the problem. If size was a tuple, then something like:
    size[0] = -1
would generate a runtime error. What misled me is that wxSize apparently
returns a representation so that when you print a wxSize it looks like a
tuple, even though it isn't.

Here's the corrected version in cvs:

        # try and determine default sizes
        width, height = aWidget.size
        if aWidget.__class__.__name__ != 'BitmapCanvas':
            bestWidth, bestHeight = aWidget._delegate.GetBestSize()
            if bestWidth == width:
                width = -1
            if bestHeight == height:
                height = -1
        if width != -1 or height != -1:
            dStr += "    'size':(%d, %d), \n" % (width, height)

That fixes that bug in the resourceEditor sample, but there could be
problems in more of the samples, basically any place that the size of a
widget is manipulated as a list instead of a tuple. The real culprits are
the _setSize and _getSize methods of the Widget class which are invoked when
you use something like:
    print self.components.btn1.size

    def _setSize(self, aSize):
        self._delegate.SetSize(aSize)
        # get the actual size, not (-1, -1)
        self._size = self._delegate.GetSize()

    def _getSize(self):
        return self._size

When I went back to read the wxPython docs it became apparent that I should
have been using GetSizeTuple(). Doh!

I don't remember why we decided to cache the _size attribute, it was lost in
the shuffle to dot notation, but I'm going to leave it until I can go
through all the samples and widget classes and make sure we don't need _size
before changing it so that _getSize just does:

    def _getSize(self):
        return self._delegate.GetSizeTuple()

In conclusion, the resourceEditor has another fix and I'm currently chasing
down widget size issues in the samples.

ka
ps. I wonder how many email filters will catch "nasty" and "exposed" above
and filter this email ;-)

RE: [Pythoncard-users] alternative resource file loading fixed, plus an example

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

I managed to introduce a bug last night in the code for loading the default
resource file, but I've fixed it in cvs. If you try and use the samples
launcher with release 0.6 it won't work unless you change the __init__
method from PythonCardApp (model.py)

        if aFileName == None:
            base, ext = os.path.splitext(sys.argv[0])
            aFileName = base + ".rsrc.py"

to

        if aFileName == None:
            filename = os.path.split(sys.argv[0])[-1]
            base, ext = os.path.splitext(filename)
            aFileName = base + ".rsrc.py"

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Wednesday, December 26, 2001 7:19 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] alternative resource file loading fixed,
> plus an example
>
>
> I fixed the path handling in the __init__ method of PythonCardApp
> (model.py)
> for loading resource files other than the default and I added an
> example of
> this using an alternative resource file to the SourceForgeTracker sample:
>
> app = model.PythonCardApp(Tracker, 'SourceForgeTracker.original.rsrc.py')
>
> If the default layout for the SourceForgeTracker doesn't look good on your
> system, then you can uncomment the line above in the sample and use the
> alternative resource. Remember, that the normal behavior is to
> take the base
> name of the main app such as "SourceForgeTracker" and append a
> ".rsrc.py" to
> find the default resource file, but there is flexibility in how
> the loading
> is handled.
>
> Here's an example of how you could load different resource files based on
> the OS platform.
>
> if os.sys.platform[:3] == 'win':
>     app = model.PythonCardApp(Tracker)
> else:
>     # Linux, Mac, etc.
>     app = model.PythonCardApp(Tracker,
> 'SourceForgeTracker.original.rsrc.py')
>
> You could even have different main classes for different
> platforms or to use
> while you're experimenting with different versions of your code.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

RE: [Pythoncard-users] 0.6.1 release likely

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

I've checked in changes to give the New/Open/Revert commands some document
changed logic like I used for the textEditor sample. It is overly
aggressive, even selecting a widget counts as a document change, but since
the resourceEditor uses the Property Editor for updating component/widget
properties I don't have much choice until I rewrite the whole thing.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Thursday, December 27, 2001 11:07 AM
> To: pythoncard-Users
> Subject: [Pythoncard-users] 0.6.1 release likely
>
>
> I'm adding some file operations to the resourceEditor: New, Save,
> and Revert
> so there will almost certainly be a 0.6.1 release in the next few days. I
> already updated cvs, but I'm still tweaking.
>
> However, the main point of doing the 0.6 release was to allow
> more people on
> the mailing list to find bugs or odd behavior and report the problems here
> so that I can fix them quickly. So if you have time during the next few
> days, please download the 0.6 release and give it a workout.
>
> I haven't received any comments on the Ctrl-F versus Ctrl+F menu shortcut
> issue, so that is another thing I might end up changing in all
> the .rsrc.py
> files.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] 0.6.1 release likely

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

I'm adding some file operations to the resourceEditor: New, Save, and Revert
so there will almost certainly be a 0.6.1 release in the next few days. I
already updated cvs, but I'm still tweaking.

However, the main point of doing the 0.6 release was to allow more people on
the mailing list to find bugs or odd behavior and report the problems here
so that I can fix them quickly. So if you have time during the next few
days, please download the 0.6 release and give it a workout.

I haven't received any comments on the Ctrl-F versus Ctrl+F menu shortcut
issue, so that is another thing I might end up changing in all the .rsrc.py
files.

ka

[Pythoncard-users] PythonCardPrototype release 0.6

[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.6 2001-12-27
*** wxPython 2.3.2 or later is now required to use PythonCard ***
added assert wxc.__version__ >= "2.3.2" to model.py
  the move to wxPython 2.3.2 fixes the menu accelerator bugs
*** resourceEditor sample is now a fully functional layout editor ***
updated resourceEditor
  added Run command, Run Options, and dialogs for editing the stack,
  background, and menu for an application
  added commands to change the component order
    component order is shown in the Property Editor
  added a grid option, so components can be aligned to the grid
  this isn't a commercial-quality layout editor since it still uses
    the runtime Property Editor to edit component (widget) properties,
    lacks extensive error checking and field validation and has
    many missing features and some oddball bugs, but overall it works
    well enough to do a fixed position layout quickly and easily
    and there is no Undo!
changed wxPython imports from
  from wxPython.wx import *
  to the more explicit
  from wxPython import wx
  added missing imports such as 'import types' where needed
replaced occurrences of wx.true and wx.false with 1 and 0
added a components directory
merged wxPython_binding.py into binding.py and moved widget-specific
  bindings to individual module files
moved spec.py descriptions for each widget to its respective widget
  module
split widget.py so each widget is in its own file in the components
  directory
  all widgets (components) are now self-contained modules in the
  components directory. each module includes the spec, event bindings,
  and attribute descriptions (formerly in spec.py) in addition to the
  widget class. when the module is imported it "registers" itself, so
  that the class is available for applications.
added drawPointList and drawLineList (2.3.2 feature) to the
  BitmapCanvas widget, switched to drawPointList in hopalong sample
  for a roughly 4x speed improvement
  also added Chaos1ScriptFastest.txt turtle script example
updated the setup.py script for minimal.py and provided some basic
  instructions in the readme.txt. It is necessary to uncomment the
  import in minimal.py prior to using py2exe due to how the dynamic
  imports are done for components
fixed _setFile bug in Image class
updated findfiles open/save code to automatically load and save
  the last grep parameters used to a 'findfiles.grep' file
updated log.py and config.py to use module-level functions in place
  of directly accessing the singleton classes from other modules
  log.info() instead of log.Log.getInstance().info() ...
  added logToStdout option to redirect log output to stdout
changed defaultStackPosition to defaultBackgroundPosition in
  pythoncard_config.py and pythoncard_user_config.py
moved title, position, size, statusBar, and icon attributes from
  the 'stack' to the 'background'
fixed alternative resource file loading
  added example of usage to SourceForgeTracker sample

ka

[Pythoncard-users] alternative resource file loading fixed, plus an example

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

I fixed the path handling in the __init__ method of PythonCardApp (model.py)
for loading resource files other than the default and I added an example of
this using an alternative resource file to the SourceForgeTracker sample:

app = model.PythonCardApp(Tracker, 'SourceForgeTracker.original.rsrc.py')

If the default layout for the SourceForgeTracker doesn't look good on your
system, then you can uncomment the line above in the sample and use the
alternative resource. Remember, that the normal behavior is to take the base
name of the main app such as "SourceForgeTracker" and append a ".rsrc.py" to
find the default resource file, but there is flexibility in how the loading
is handled.

Here's an example of how you could load different resource files based on
the OS platform.

if os.sys.platform[:3] == 'win':
    app = model.PythonCardApp(Tracker)
else:
    # Linux, Mac, etc.
    app = model.PythonCardApp(Tracker,
'SourceForgeTracker.original.rsrc.py')

You could even have different main classes for different platforms or to use
while you're experimenting with different versions of your code.

ka

RE: [Pythoncard-users] title, position, size, and statusbar attributes

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

Okay, I'm on a coding roll; actually it was mostly a cut and paste fest. I
checked the changes described below into cvs, so I can move on. If there is
some dissent on moving the attributes to the background, we can always roll
the changes back (speak up soon). The framework, all samples, and the
resourceEditor are updated.

I would like to announce release 0.6 beyond the pythoncard-users mailing
list since the last time I made an announcement to comp.lang.python was on
September 17th (release 0.4.5) and I think PythonCard has progressed quite a
bit since then. I would also like to get release 0.6 out before the end of
the year (its a symbolic accomplishment for me), so I'll probably go ahead
and do a .zip of cvs today or tomorrow so that more people on the list at
least have a chance to download it and post issues or problems to the list
(I can always hope for feedback ;-) If there are small bugs or other
problems that can be fixed, I'll do a 0.6.1 right away, otherwise release
0.6 will stand.

Then we can dig deeper into the wxPython and components transition and I can
spend some more time on document model classes.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Wednesday, December 26, 2001 9:58 AM
> To: pythoncard-Users
> Subject: [Pythoncard-users] title, position, size, and statusbar
> attributes
>
>
> I would like to move the title, position, size, and statusbar
> attributes of
> the 'stack' to the 'background'. When we move to multiple windows
> we'll need
> those attributes for each independent window. We already have title,
> position, and size for GenericDialog, so this change should also simplify
> using the same layout code for modal dialogs as regular
> background windows.
>
> This won't impact any of sample source code that I know of except the
> resourceEditor, but it does mean updating every resource file. In
> case there
> is any objection, I won't roll this change into cvs for a day or two.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

RE: [Pythoncard-users] title, position, size, and statusbar attributes

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

'icon' will also be moved to the 'background'. I had forgotten to include
'icon' in the resourceEditor, so I'll add that along with the changes below
assuming there are no objections.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Wednesday, December 26, 2001 9:58 AM
> To: pythoncard-Users
> Subject: [Pythoncard-users] title, position, size, and statusbar
> attributes
>
>
> I would like to move the title, position, size, and statusbar
> attributes of
> the 'stack' to the 'background'. When we move to multiple windows
> we'll need
> those attributes for each independent window. We already have title,
> position, and size for GenericDialog, so this change should also simplify
> using the same layout code for modal dialogs as regular
> background windows.
>
> This won't impact any of sample source code that I know of except the
> resourceEditor, but it does mean updating every resource file. In
> case there
> is any objection, I won't roll this change into cvs for a day or two.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] title, position, size, and statusbar attributes

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

I would like to move the title, position, size, and statusbar attributes of
the 'stack' to the 'background'. When we move to multiple windows we'll need
those attributes for each independent window. We already have title,
position, and size for GenericDialog, so this change should also simplify
using the same layout code for modal dialogs as regular background windows.

This won't impact any of sample source code that I know of except the
resourceEditor, but it does mean updating every resource file. In case there
is any objection, I won't roll this change into cvs for a day or two.

ka

RE: [Pythoncard-users] bug fixes for resourceEditor

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

> dialogs. The exception is that once a statusbar is added to the window, it
> won't be removed regardless of the actual setting in the resource. The
> resource you save to disk will be correct, so if you save, quit the
> resourceEditor and restart, the window will be displayed correctly. I've
> posted a question to wx-users to see if there is a way of dynamically
> deleting the statusbar to take care of this issue.

The statusbar is now toggled correctly. Vadim comes to the rescue again.

ka

[Pythoncard-users] bug fixes for resourceEditor

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

I checked in some bug fixes for the resourceEditor, mostly to deal with some
color mangling. However, it gave me time to refactor the code a bit and now
the stack and background properties should be updated appropriately when the
app starts up, you open a file, or edit using the background and stack info
dialogs. The exception is that once a statusbar is added to the window, it
won't be removed regardless of the actual setting in the resource. The
resource you save to disk will be correct, so if you save, quit the
resourceEditor and restart, the window will be displayed correctly. I've
posted a question to wx-users to see if there is a way of dynamically
deleting the statusbar to take care of this issue.

I definitely need more exception handling, so any kind of error or exception
even when entering bad data would be worth noting, even if it isn't fixed
for a while. It will give me a reason to look into field validators in
wxPython. You can email me directly or just post to the list.

I'm also wondering whether the dialogs look okay under Linux. I think I need
to use a wxFlexGridSizer to do rows of StaticText TextField components that
line both the columns correctly like an HTML table, so it is yet another
thing I need to investigate. For now, the layouts use fixed positioning.

ka

[Pythoncard-users] resourceEditor is under the Christmas tree

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

As a holiday present to myself I finished up the biggest missing feature of
the resourceEditor by adding a Menu Editor dialog. There are almost
certainly bugs since I just checked it in, but I'm hoping that we can now
edit a resource file from scratch or edit any existing sample resource file.
I am not supporting dialog editing yet, but users should no longer need to
edit a main resource file using a text editor.

I've attached a JPEG image of the Menu Editor dialog.

The Shortcut field is pretty cool, but perhaps non-obvious. When the cursor
is in the field, simply hold down the key combination you want and it will
be translated into the correct text for the key combination. For example,
hold down the Control key and the f key and 'Ctrl+F' will be inserted into
the field. Not all possible key combos are supported right now, but it does
the most common ones including the function keys. Use the backspace key to
clear the field.

*** There is no Undo support in the resourceEditor ***
So, if you make a major mistake while editing in a dialog, click Cancel so
the changes aren't saved. Use the Attributes menu item under View to look
over what will be saved to disk before doing a Save As... and keep backups
of your resource files between edits. The resourceEditor is still pretty
fragile, aka GIGO. For example, if you don't have a Menu as the first item
in the list and click OK, then the dialog will fail to build the Resource in
a try/except block and you'll end up with no menubar.

I would appreciate feedback and bug reports from those of you braving cvs
during the holidays. I plan to try opening, editing, and then saving every
.rsrc.py file in the current samples and comparing the output to the
originals, but that will take a couple of days, especially since I'm not
smart enough to automate the comparisons or use unit tests like a good
programmer.

I plan to make a 0.6 release before the end of the year, but I want to do
some more testing and hopefully get some feedback on the changes since the
0.5.3 release before I make another zip from cvs.

ka

[Pythoncard-users] menu accelerator conventions, plus vs minus

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

I'm using wxPython 2.3.2 and menu accelerators such as Ctrl+C are working
(they were broken in 2.3.1). Apparently you can use either '-' or '+' for
the key descriptions:
  Shift+Ctrl+O
  Ctrl-Shift-V
  Ctrl-X
  Alt-X

I've been using '-' since that is what I copied out of the very first
wxPython app I borrowed from when we started PythonCard. When I look at
other apps under Windows, '+' seems to be the standard.

So, I'm wondering what is common for Linux, plus or minus? Also, this seems
like another place where the Mac might need a separate resource, since the
Mac would use Command-C or Apple symbol-C (if I remember correctly).

I'll probably do a global replace from the minus to plus form for the menu
accelerators unless Linux uses the minus form, in which case a better
solution may need to be used. Theoretically, the framework could
"auto-correct" the accelerator form based on platform when the resource is
read in.

ka

[Pythoncard-users] grid size and align to grid for resourceEditor

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

I added "Grid Size" and "Align Components to Grid" options to the
resourceEditor to simplify fixed layouts. The default is a grid size of 5
pixels with Align to Grid turned off. You can toggle the "Align Components
to Grid" menu option with Control-G.

Happy Holidays!

ka

RE: [Pythoncard-users] resourceEditor - widget ordering

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

The resourceEditor (aka Layout Editor) continues to improve.

Here's a bit from the cvs checkin message:
added Component menu, moved Add Button... to the Component menu
fixed Duplicate so duplicated component is in front of other components
cleaned up menu names
added Send to Back, Move Backward, Move Forward, Bring to Front commands

I'm starting to use the name 'component' in place of 'widget'.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Thursday, December 20, 2001 1:56 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] resourceEditor - widget ordering
>
>
> When you hide/show a windows/control in wxPython 2.3.x it changes the
> ordering of the controls on the panel. This behavior is a side-effect, but
> as long as it is available, I decided to exploit it.
>
> The widgets for a PythonCard app are in a 'components' list in
> the .rsrc.py
> file for an app. The first widget in the list will always be in
> front of the
> second item, which will always be in front of the third item, and so on.
> This is the only control we have over tab order and layering that
> I know of
> until more options are added to the underlying capabilities of
> wxWindows/wxPython.
>
> So, to take advantage of this I changed the resourceEditor, so
> that when you
> add a new widget using the Edit menu, all of the widgets are
> hidden and then
> reshown so that the new widget is the first item in the list and
> appears in
> front of the other widgets.
>
> I'll experiment later with the logic necessary to change the
> widget ordering
> so we can have menu items for:
>   Send to Back
>   Move Backward
>   Move Forward
>   Bring to Front
>
> The source for the resourceEditor is turning into a messy hack
> job almost as
> bad as the Property Editor, but I think I will continue to glue
> on features
> before doing a complete rewrite. I would still appreciate suggestions, bug
> reports, etc. Once the menu dialog is added it should be okay for building
> non-sizer layouts from scratch even for a newbie.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] I've done some documentation

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

All,

Its only a start, and it is only a first cut, but I have created a 
functional and a technical specification for dbBrowser. If you are 
interested you can view them at;

http://www.halfcooked.com/CityDesk

Please let me know what you think. My purpose was two fold, to test out 
CityDesk from FogCreek (http://www.fogcreek.com/CityDesk for those who 
don't read Joel on Software) and to produce documentation in a more 
readable format than doc strings.

I envisage these documents to change and grow as I continue working on 
dbBrowser. I'd also like to produce similar pages for the other samples 
and will get started on some over the next week or so.

The key component to good documentation though is review. If you read 
them and think they are rubbish - let me know. If you read them and love 
them - let me know. If you think something is missing - let me know.

I-think-you-get-the-drift-ly yr's,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"99% of the population is saving up to go somewhere warm for their
holidays and suddenly global warming is a bad thing?" - Sam Kekovitch

[Pythoncard-users] resourceEditor - widget ordering

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

When you hide/show a windows/control in wxPython 2.3.x it changes the
ordering of the controls on the panel. This behavior is a side-effect, but
as long as it is available, I decided to exploit it.

The widgets for a PythonCard app are in a 'components' list in the .rsrc.py
file for an app. The first widget in the list will always be in front of the
second item, which will always be in front of the third item, and so on.
This is the only control we have over tab order and layering that I know of
until more options are added to the underlying capabilities of
wxWindows/wxPython.

So, to take advantage of this I changed the resourceEditor, so that when you
add a new widget using the Edit menu, all of the widgets are hidden and then
reshown so that the new widget is the first item in the list and appears in
front of the other widgets.

I'll experiment later with the logic necessary to change the widget ordering
so we can have menu items for:
  Send to Back
  Move Backward
  Move Forward
  Bring to Front

The source for the resourceEditor is turning into a messy hack job almost as
bad as the Property Editor, but I think I will continue to glue on features
before doing a complete rewrite. I would still appreciate suggestions, bug
reports, etc. Once the menu dialog is added it should be okay for building
non-sizer layouts from scratch even for a newbie.

ka

[Pythoncard-users] Re: Current state of CVS?

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

Problem found, and solved (thanks for the help Kevin).

I wasn't checking  code out of cvs properly. This error message was 
caused by my local copy of the code not having the 'components' 
directory. I was doing a 'cvs update' but that doesn't pick up new 
directories that other people have created in the repository.

Andy Todd wrote:

> Afternoon all. After being slack for the last couple of weeks I got some 
> free time and thought I would continue with some documentation I have 
> been working on. I updated from CVS and now all of the samples are 
> broken (well, I've only tried dbBrowser and minimal). Is CVS currently 
> in a working state?
> 
> If it is, then this is my error;
> 
> """
> C:\Work\Python\PythonCardPrototype\samples\minimal>python minimal.py
> Traceback (most recent call last):
>   File "minimal.py", line 25, in ?
>     app = model.PythonCardApp(Minimal)
>   File "c:\work\python\PythonCardPrototype\model.py", line 112, in __init__
>     self.resource = res.ResourceFile(aFileName).getResource()
>   File "c:\work\python\PythonCardPrototype\res.py", line 47, in getResource
>     return Resource( self.dictionary )
>   File "c:\work\python\PythonCardPrototype\res.py", line 90, in __init__
>     aDictionary[ key ] = Resource( value )
>   File "c:\work\python\PythonCardPrototype\res.py", line 96, in __init__
>     value[ i ] = Resource( item )
>   File "c:\work\python\PythonCardPrototype\res.py", line 96, in __init__
>     value[ i ] = Resource( item )
>   File "c:\work\python\PythonCardPrototype\res.py", line 101, in __init__
>     self.enforceSpec( aDictionary )
>   File "c:\work\python\PythonCardPrototype\res.py", line 133, in 
> enforceSpec
>     loadComponentModule(typeStr.lower())
>   File "c:\work\python\PythonCardPrototype\res.py", line 30, in 
> loadComponentModule
>     raise ImportError
> ImportError
> """
> 
> Regards,
> Andy

As usual, google came to the rescue;

http://groups.google.com/groups?q=cvs+new+directory&hl=en&rnum=3&selm=fa.g2cdd4v.on0kqn%40ifi.uio.no

(excuse wrapping)

This prompted me to actually RTFM, and the appropriate flag is '-d', as 
documented here;

http://www.cvshome.org/docs/manual/cvs_16.html#SEC151

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

[Pythoncard-users] resourceEditor additions

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

added Stack and Background info dialogs for editing the stack and background
attributes
  there is no error checking, so Garbage In Garbage Out (GIGO)
added a Run menu item under File to launch the app associated with the
resource file
  for example, if you are editing minimal.rsrc.py, it will try and Run
minimal.py
  it does not currently prompt to save the resource file
added an Options menu to check/uncheck Run options for the runtime tools

I'll probably work on a basic menu editing dialog in the next few days as
well as start fixing the New/Open/Save/Save As... logic to work like the
textEditor sample.

I suggest working on copies of .rsrc.py documents, but will appreciate any
feedback from those willing to brave cvs.

ka

[Pythoncard-users] Current state of CVS?

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

Afternoon all. After being slack for the last couple of weeks I got some 
free time and thought I would continue with some documentation I have 
been working on. I updated from CVS and now all of the samples are 
broken (well, I've only tried dbBrowser and minimal). Is CVS currently 
in a working state?

If it is, then this is my error;

"""
C:\Work\Python\PythonCardPrototype\samples\minimal>python minimal.py
Traceback (most recent call last):
   File "minimal.py", line 25, in ?
     app = model.PythonCardApp(Minimal)
   File "c:\work\python\PythonCardPrototype\model.py", line 112, in __init__
     self.resource = res.ResourceFile(aFileName).getResource()
   File "c:\work\python\PythonCardPrototype\res.py", line 47, in getResource
     return Resource( self.dictionary )
   File "c:\work\python\PythonCardPrototype\res.py", line 90, in __init__
     aDictionary[ key ] = Resource( value )
   File "c:\work\python\PythonCardPrototype\res.py", line 96, in __init__
     value[ i ] = Resource( item )
   File "c:\work\python\PythonCardPrototype\res.py", line 96, in __init__
     value[ i ] = Resource( item )
   File "c:\work\python\PythonCardPrototype\res.py", line 101, in __init__
     self.enforceSpec( aDictionary )
   File "c:\work\python\PythonCardPrototype\res.py", line 133, in 
enforceSpec
     loadComponentModule(typeStr.lower())
   File "c:\work\python\PythonCardPrototype\res.py", line 30, in 
loadComponentModule
     raise ImportError
ImportError
"""

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

RE: [Pythoncard-users] preliminary grid success

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

> 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

[Pythoncard-users] htmlfield widget

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

As an experiment, I created an HTMLField widget yesterday. The complete
htmlfield.py file that I put in the 'components' directory is below. This is
not a complete interface to wxHtmlWindow, just a simple test.

I modified the minimal.rsrc.py file:
    { 'type':'HTMLField',
      'name':'field1',
      'position':(0, 0),
      'size':(400, 450),
      #'text':'<html><head><title>Hello</title></head><body>hello
world</body></html>' },
      'text':'index.html'},

wxHtmlWindow supports loading of a URL or filename as well as setting the
HTML directly. It handles the HTTP requests internally. wxHtmlWindow is not
intended to build a full-featured browser, but it is more than adequate for
displaying non-editable/non-selectable HTML for help or any place you might
normally use a non-editable TextField or TextArea widget, but want richer
text capabilities with embedded images... There are more elaborate
capabilities such as embedding other wxPython controls in the wxHtmlWindow,
but I don't want to try dealing with that initially.

So, the question is what the component should be named? Then I'll add the
component and we can experiment with the capabilities. I'm tempted to just
name it "HtmlWindow" since once we move to directly subclassing wxPython
controls and windows, using the wxPython name, minus the "wx" prefix might
simplify reading user code and docs.

I also want to add a component for displaying MS HTML Workshop format files
which in handled by wxHtmlHelpController, but I haven't experimented with
this yet. If anyone has experience with the help file format and/or
wxPython/wxWindows classes for using them and would like to do some of the
work, please let me know.

ka
---
htmlfield.py:

from wxPython import wx, html

import sys
from PythonCardPrototype import binding, event, widget


class HTMLFieldSpec(widget.WidgetSpec):
    def __init__(self):
        widget.WidgetSpec.__init__(self)

        self.name = 'HTMLField'
        self.parent = 'Widget'
        self.parentName = self.parent
        self._attributes.update({
            'text' : { 'presence' : 'optional', 'default' : '' },
        })

        self.attributes = self.parseAttributes(self._attributes)
        self.requiredAttributes = self.parseRequiredAttributes()
        self.optionalAttributes = self.parseOptionalAttributes()


class HTMLField(widget.Widget):
    """
    An HTML window.
    """

    _events = event.MOUSE_EVENTS
    _spec = HTMLFieldSpec()

    def __init__( self, aParent, aResource ) :
        widget.Widget.__init__( self, aParent, aResource )
        self._setText(aResource.text)

    def _createDelegate( self, aParent, aResource ) :
        return html.wxHtmlWindow( aParent._delegate,
            self.getId(),
            wx.wxPoint( aResource.position[ 0 ], aResource.position[ 1 ] ),
            wx.wxSize( aResource.size[ 0 ], aResource.size[ 1 ] ),
            #style = wx.wxHW_SCROLLBAR_AUTO | wx.wxCLIP_SIBLINGS,
            name = aResource.name
        )

    def _bindEvents(self):
        adapter = binding.wxPython_EventBinding(self)
        adapter.bindEvents()

    def _getText( self ) :
        return self._delegate.GetOpenedPage()

    def _setText( self, aString ) :
        if aString == '' or aString[0] == '<':
            self._delegate.SetPage(aString)
        else:
            # filename
            self._delegate.LoadPage(aString)
        #self._delegate.Refresh()


widget.WidgetRegistry['HTMLField'] = sys.modules[__name__].HTMLField

[Pythoncard-users] preliminary grid success

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

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 

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.

here are some questions and observations that
came up during the experiment:

- how are GridSpec's "self.events.extend()" and Widget's _events
  related?
    - in list.py
	- ListSpec only extends with 'select', but
        - List adds SelectEvent *and* MouseDobuleClickEvent
        - should ListSpec add "doubleclick", too?

- 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

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

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


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

jeff


__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

RE: [Pythoncard-users] PythonCard cvs tree cleanup

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

I believe Kevin was just pruning a dead branch in preparation for bigger and
better things. In other words, this was not a bad thing.

---
Patrick K. O'Brien
Orbtech.com - Your Source For Python Development Services
Phone: 314-963-3206


> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Roman
> Suzi
> Sent: Tuesday, December 18, 2001 9:59 AM
> To: pyt...@li...
> Subject: Re: [Pythoncard-users] PythonCard cvs tree cleanup
>
>
> On Mon, 17 Dec 2001, Kevin Altis wrote:
>
> >from SF admins: "The contents of the PythonCard module of the
> pythoncard CVS
> >repository have been removed."
> >
> >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/
>
> Why? What's up?
>
> Sincerely yours, Roman Suzi
> --
> _/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
> _/ Tuesday, December 18, 2001 _/ Powered by Linux RedHat 6.2 _/
> _/ ""C++" should have been called "D"" _/
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Re: [Pythoncard-users] PythonCard cvs tree cleanup

[Roman S. <rn...@on...>]

On Mon, 17 Dec 2001, Kevin Altis wrote:

>from SF admins: "The contents of the PythonCard module of the pythoncard CVS
>repository have been removed."
>
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/

Why? What's up?

Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
_/ Tuesday, December 18, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ ""C++" should have been called "D"" _/