pythoncard-users Mailing List for PythonCard (Page 176)

> From: rog...@gl...
>
> I noticed from the resources editing tool kit that the choices
> component does
> not have a border property, and, looking at the wxWindows
> documentation it looks
> like it could be added in. How easy would this be to do?

Do you mean these styles for wxWindow?

wxSIMPLE_BORDER  Displays a thin border around the window. wxBORDER is the
old name for this style.
wxDOUBLE_BORDER  Displays a double border. Windows only.
wxSUNKEN_BORDER  Displays a sunken border.
wxRAISED_BORDER  Displays a raised border. GTK only.
wxSTATIC_BORDER  Displays a border suitable for a static control. Windows
only.
wxTRANSPARENT_WINDOW  The window is transparent, that is, it will not
receive paint events. Windows only.

If so, this is the kind of style option we'll have to add, there isn't
support right now. I don't see a special border attribute for wxChoice.

As a side note, this reminds me that I always wanted to rename Choice to
PopupMenu, which seems like a better name.

ka

I noticed from the resources editing tool kit that the choices component does
not have a border property, and, looking at the wxWindows documentation it looks
like it could be added in. How easy would this be to do?

Roger

Thank you Kevin.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.320 / Virus Database: 179 - Release Date: 1/30/2002
=20

It sounds like the right thing to do. Any dissent?

If not, I'll go ahead and convert dialog.py, dialognew.py and all the
samples and their dialogs so all modal dialog results are placed in a
dictionary return value. If I run into any issues I won't check the changes
in until I've brought the issue up on the list. This is probably going to
take a few days because I might need to rethink how the GenericDialog class
works, so if you see a fundamental problem with this approach please speak
up now, before I dive in.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> Patrick K. O'Brien
> Sent: Wednesday, February 13, 2002 2:31 PM
> To: Kevin Altis; pythoncard-Users
> Subject: RE: [Pythoncard-users] dictionary return values for dialogs?
>
>
> Sounds like a good thing to me.
>
> ---
> Patrick K. O'Brien
> Orbtech
>
> > -----Original Message-----
> > From: pyt...@li...
> > [mailto:pyt...@li...]On Behalf Of Kevin
> > Altis
> > Sent: Wednesday, February 13, 2002 3:41 PM
> > To: pythoncard-Users
> > Subject: [Pythoncard-users] dictionary return values for dialogs?
> >
> >
> > I've been thinking about redoing the general dialog interface so
> > that rather
> > than creating a dialog and then getting all of the elements via
> > methods such
> > as:
> >
> >   dlg.accepted()
> >
> > The return value would always be a dictionary with named
> > parameters for all
> > the options {'accepted':1, 'returned':'Ok'}, something like
> that. You can
> > look at the dialogs.py sample to see how method calls are
> > currently used. We
> > can already do dialog one-liners for the simplest dialogs as this shell
> > session shows:
> >
> > >>> from PythonCardPrototype import dialog
> > >>> dialog.AlertDialog(None, 'a message', 'a title')
> >
> > But this isn't possible with more complex dialogs. Using a
> > dictionary return
> > value seems simpler and more Pythonic since the user doesn't have to
> > explicitly call ShowModal or Destroy and regardless of the
> dialog type the
> > result will always be a dictionary of name/value pairs.
> >
> > It may cause issues where previously some dialog setup was done after
> > __init__, but I won't know until I dig a little deeper. The ModalDialog
> > class (dialog.py) in PythonCard already hides ShowModal and Destroy, but
> > still requires the use of methods after the dialog returns to
> get results.
> > GenericDialog (dialognew.py) hides less and would also need to be
> > upgraded.
> >
> > Opinions?
> >
> > ka

I'm forwarding this comp.lang.python post just as another data point in the
complexity discussion. It is actually relatively easy to get duplicate
functionality by programming interactively in the Shell. You can also call a
big linear function or method from the openBackground handler which will get
called after the app starts, but maybe that is still too complex? Anyway,
this is another perspective to consider.

You can see more at http://home.att.net/~stephen_ferg/easygui/

ka
ps. The mention of REXX on the easygui page brought back horrible memories
of IBM Mainframes. Ah, punch cards, 3270 terminals, JCL and green bar
printouts. Ack!
---

"Stephen Ferg" <st...@fe...> wrote in message
news:<b16...@po...>...

Here's a bit more about what I was trying to do in EasyGui.  It took a
message from Kevin Altis really to make it clear.  Kevin wrote:

> I went ahead and looked at what you have
> done so far and it looks like all
> you're doing is throwing up different
> sorts of dialogs. Are you just wanting
> dialogs for input and output in a linear
> program? GUI programs are generally
> event driven.

Kevin pinpointed exactly what is different about EasyGui ... it is
just putting up dialogs for simple input and output in a linear
program.

What makes EasyGui different from other GUIs is that it is NOT
event-driven.

The reason is this:  For some (a few? many?) novice Pythonistas (or
even novice programmers?), the event-driven paradigm is new -- it will
take some learning and some mental re-adjusting.  EasyGui is designed
to meet their immediate needs until they can make that transition.
Until he/she is ready to move on to an event-driven paradigm, EasyGui
will allow a programmer accustomed to a linear programming style to do
simple GUI functions so he/she can be productive (with very basic
tasks) immediately.  When he/she is ready, he/she can move on to an
event-driven style with a more powerful GUI package such as anygui,
PythonCard, Tkinter, wxPython, etc.

Kevin mentions what's been done in EasyGui "so far".   At least in my
vision of it, EasyGui shouldn't go much farther.  EasyGui is there
just to do very simple, very basic stuff.   More elaborate stuff
should be done with more powerful tools.

I honestly don't know if there is a need for such an animal as
EasyGui.  But I think there might be...

-- Steve  (st...@fe...)

> i'm looking to develop apps like games (eg tetris & the stuff at
> www.shockwave.com). Also, i'm interested in developing interactive
> courseware (eg
> http://www.macromedia.com/resources/elearning/examples/ucsf.html).

Games and courseware are certainly doable, but there aren't many examples
out there to draw from yet. PyGame http://www.pygame.org/ is focused on
building games in Python and has an active mailing list and many examples.
It does not come with a large set of pre-built GUI widgets, menus, etc. so
additional libraries that people in the PyGame community have been working
on would be necessary depending on what you want on screen.

PythonCard should be effective in the interactive courseware area, but again
nobody has done specific samples that I know of. You could ask on the
edu-sig mailing list to see what tools people might already be using.

> Can pythoncard apps work in a web browser?

No

> What is webware? Is this required if i want to accomplish the task in
> the previous question?

WebWare is geared towards building web applications which mostly means stuff
server-side. I doubt this is what you are looking for.

> Is SVG and SMIL supported in pythoncard?

I don't know what those are, so I'm guessing the answer is no.

> Can pythoncard buttons be "bitmappeable"? Can i create round or
> triangular buttons?

You can create buttons with bitmaps (Image and ImageButton) and with a mask
the shape will be that of the bitmap, not a rectangle. However, the button
will still be rectangular as far as mouseClicks. As long as your rectangles
don't overlap that shouldn't be a problem. If you do need to have them
overlap, then more likely you need to do your own hit detection, which is
the kind of support PyGame already has since that is a common need in games.

> Can MP3 sound be used in pythoncard apps?

Not directly, you would have to drive an external MP3 player. I don't know
when direct cross-platform MP3 playback will be supported by Python. I think
the SDL library which PyGame sits on top of does MP3, but I don't know of a
general solution for playback that any Python/wxPython/PythonCard program
could use today.

> Can pythoncard apps have a custom-shaped bitmap mapped on eg. a triangle
> or a bean shape? Can they be "skinnable" like Winamp?

Same answer as above for bitmaps. There is no direct skin support today, but
it is possible.

> Is 3D supported in pythoncard? What is my path to create interactive 3d
> games using pythoncard (eg Stuntracer
> http://stuntracer.sourceforge.net/)?

wxPython and thus PythonCard can use OpenGL. Again, for game stuff in Python
you are probably better off using PyGame if for no other reason it has a
better mailing list group to answer the types of questions you'll have once
you start your game programming.

ka

This is another one of those minor bugs that has been around for a while.
Apologies to anyone that has had messed up background colors while using the
resourceEditor.

Line 1295 of the current file should be:

defaultBgColor = wx.wxSystemSettings_GetSystemColour(wx.wxSYS_COLOUR_3DFACE)

I previously had the constant wx.wxSYS_COLOUR_3DLIGHT, which happens to have
the same default value under Windows 2000, but not uder Win98 and probably
other versions of Windows. Somebody will have to test that this still works
for wxGTK too.

If you had edited with the resourceEditor when the wrong value was being
used you likely had a background that was a lighter gray than you expected
and when you went to run your application the background of the panel would
be correct, but components like the buttons and static text would be light.
Dan Shafer's counter sample had this problem, so I went ahead and fixed that
too by getting rid of the lines such as:

    'backgroundColor':(224, 224, 224),

I've updated cvs with the fixes.

ka

Hi Kevin (& fellow hypercarders),

Thank you for your KIND & SPEEDY feedback.

i'm looking to develop apps like games (eg tetris & the stuff at
www.shockwave.com). Also, i'm interested in developing interactive
courseware (eg
http://www.macromedia.com/resources/elearning/examples/ucsf.html).

Can pythoncard apps work in a web browser?

What is webware? Is this required if i want to accomplish the task in
the previous question?

Is SVG and SMIL supported in pythoncard?

Can pythoncard buttons be "bitmappeable"? Can i create round or
triangular buttons?

Can MP3 sound be used in pythoncard apps?

Can pythoncard apps have a custom-shaped bitmap mapped on eg. a triangle
or a bean shape? Can they be "skinnable" like Winamp?

Is 3D supported in pythoncard? What is my path to create interactive 3d
games using pythoncard (eg Stuntracer
http://stuntracer.sourceforge.net/)?

i would be very, very grateful for a reply. Thank you for your kindness.

[Onward, free developers!]

God Bless you.

"For God so loved the world that he gave his only Son that whoever
believes in him will not perish but have eternal life." John 3:16.

from,
Simon





---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.320 / Virus Database: 179 - Release Date: 1/30/2002
=20

> From: Simon
>
> Please tell me if i can create an executable Win32 app for end-users
> without needing them to install Python &/or wxPython.

Yes. The minimal and textRouter samples have example scripts for building
standalones using py2exe and Gordon McMillan's installer.

> Also, i'm from a Macromedia Flash/Director background. Please tell me
> what are the similarities/differences of Macromedia's RAD tools compared
> to pythoncard.

PythonCard is free and uses Python as the scripting language. I don't use
Flash/Director, so somebody else that does will have to comment on the
quality of the language and tools.

In general, if your focus is publishing inside the browser or on a tight
integration of audio, animated graphics, and video then Flash is almost
certainly a better choice this early in the development of PythonCard, but
without a specific example of what you are trying to do, it is difficult to
say for sure. You can do audio and graphics in PythonCard.

ka

Hi there,

Please tell me if i can create an executable Win32 app for end-users
without needing them to install Python &/or wxPython.=20

Also, i'm from a Macromedia Flash/Director background. Please tell me
what are the similarities/differences of Macromedia's RAD tools compared
to pythoncard.=20

i would be very grateful for a reply. Thank you very much.

from, Simon

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.320 / Virus Database: 179 - Release Date: 1/30/2002
=20

I missed a few crucial spots in the first check-in where I still made
references to _delegate or a cached attribute. I think I've caught them all
now, but if you checked out from cvs earlier today after my initial check-in
you definitely need to get the latest files which fix model.py, image.py,
and imagebutton.py

ka

Kevin Altis:

> Just for comparison, I opened up Visual Basic, created a Button then
opened
> the editor and typed the button name followed by a dot (period) and up
> popped a list of 50 attributes and methods for the button. Of that list of
> 50, around 32 were directly changeable via the Properties editor, so I'm
> assuming the rest are methods. A text field had a list of 67 items with 42
> of those changeable in the Properties editor. In VB what you see is what
you
> get, so that level of complexity is always shown and you can't get anymore
> functionality.

   Gahh, that's nothing compared to .Net. I wanted to use a scrollbar and
the most interesting thing about a scrollbar is its current location.
Searching through the more than 230 properties and methods and around 60
events led to me being so lost I gave up and subclassed from
ScrollableControl instead. About half of the methods are 'protected' so are
only visible to subclasses but that still means you have to do too much
reading to create code.

   The properties include many less than useful items such as 'CompanyName'
which tells you the name of the company that made the application. Why this
is directly exposed on a scrollbar rather than requiring navigation to an
application object is beyond me.

   BTW, the current position property of a scrollbar in .Net is called
'Value'.

   Neil

I basically agree with what Dan says about complexity, so I won't include it
all again here.

> From: Dan Shafer
>
> In any programming language or OS, there is a collection of readily
> accessible "stuff" that the primary intended market -- or the least
> savvy intended user, depending on perspective -- is expected to be
> able to see, grasp, and deal with. Then there is a tablecloth. Then
> there is the "other stuff" that only system-level programmers (in the
> case of an OS) or the Language Priesthood (in the case of the
> programming tool) is expected to grok.

Just for comparison, I opened up Visual Basic, created a Button then opened
the editor and typed the button name followed by a dot (period) and up
popped a list of 50 attributes and methods for the button. Of that list of
50, around 32 were directly changeable via the Properties editor, so I'm
assuming the rest are methods. A text field had a list of 67 items with 42
of those changeable in the Properties editor. In VB what you see is what you
get, so that level of complexity is always shown and you can't get anymore
functionality.

I tried to figure out the same numbers for a HyperCard Button and Field but
due to how properties and messages are listed in the references and the fact
that HyperCard Buttons and Fields are also popup menus, lists, radio
buttons, checkboxes, etc. I don't know how to do a direct comparison. Maybe
it was good that HyperTalk didn't have autoComplete? ;-)

In Python, we don't have declarative static typing, so I can't get
autoComplete in a Python-aware editor, unless the editor is going to do some
evals on the source as I type and make some assumptions about the variable
type when have code that can't be evaluated because a calling function isn't
written yet, the function or method I'm writing isn't done, etc. PythonWin
does some guessing and it is a mixed blessing. So, in general, lack of
explicit typing means only the runtime environment can give you an
autoComplete list, any editor we eventually do probably won't be showing any
attributes or methods.

Anyway, the level of exposed complexity is probably relatively easy to
control, but if we want to hide anything it will require extra work. The
runtime environment tools such as the Shell can have a setting to control
how much is shown and any documentation that is created can be built with
one or more users in mind.

Patrick hides the complexity of wxStyledTextCtrl in the shell by only
showing those attributes and methods he explictly defined to be shown.

We can remember the users level of "sophistication" just like other
properties so you don't have to constantly change back and forth.

The framework automatically binds all applicable events to a component, but
again this is something that we could change so that only events with
handlers are bound and so "Hide unused events" in the Message Watcher would
go away. We originally bound all events because it was simpler to code that
way and it more closely matched what HyperCard did.

The one big problem with juggling what you show and don't show is that if I
user defined their own variables or methods that match something already
defined in the underlying classes, but not shown, then they will probably
get confusing results.

ka

Sounds like a good thing to me.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Wednesday, February 13, 2002 3:41 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] dictionary return values for dialogs?
>
>
> I've been thinking about redoing the general dialog interface so
> that rather
> than creating a dialog and then getting all of the elements via
> methods such
> as:
>
>   dlg.accepted()
>
> The return value would always be a dictionary with named
> parameters for all
> the options {'accepted':1, 'returned':'Ok'}, something like that. You can
> look at the dialogs.py sample to see how method calls are
> currently used. We
> can already do dialog one-liners for the simplest dialogs as this shell
> session shows:
>
> >>> from PythonCardPrototype import dialog
> >>> dialog.AlertDialog(None, 'a message', 'a title')
>
> But this isn't possible with more complex dialogs. Using a
> dictionary return
> value seems simpler and more Pythonic since the user doesn't have to
> explicitly call ShowModal or Destroy and regardless of the dialog type the
> result will always be a dictionary of name/value pairs.
>
> It may cause issues where previously some dialog setup was done after
> __init__, but I won't know until I dig a little deeper. The ModalDialog
> class (dialog.py) in PythonCard already hides ShowModal and Destroy, but
> still requires the use of methods after the dialog returns to get results.
> GenericDialog (dialognew.py) hides less and would also need to be
> upgraded.
>
> Opinions?
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Fear not. There are a number of ways that we can achieve the goal of "simple
things are simple and difficult things are possible." The Pythoncard shell
(PyCrust) itself already implements one way of hiding complexity without
limiting functionality. When you type "shell." the autocomplete list you see
is a subset of all the available methods and properties. If you happen to
know the right name of a hidden one and type it in, it still works. If you
want to see the full list, shell.other is a pointer to the real shell that
is hidden behind the simplified facade. Typing "shell.other." will show you
a huge list of attributes.

The particular approach I took with the shell object may not be the best way
to go for Pythoncard components in general. But I'm completely confident
that we can devise a technique that does everything we want. Worst case, we
just modify the introspection built into PyCrust to do what we want.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Dan
> Shafer
> Sent: Wednesday, February 13, 2002 3:40 PM
> To: pyt...@li...
> Subject: RE: [Pythoncard-users] bye bye _delegate, hello direct
> subclasses
>
>
> I'm probably a minority voice in the wilderness here, but that's
> never slowed me down. :-)
>
[snip]
>
> I have little interest in helping to develop a programming aid for
> wxWindows and I would likely never make use of such a beast. But I am
> _passionate_ about a need for a souped-up HyperCard done in Python
> with Python as a scripting language and a strong subset of easily
> used and scripted components with which to assemble new apps and
> create new componentry.
> --
> Dan Shafer, Personal Creativity Trainer and Consultant
> Trained Hartman Value Profile Analyst
> http://www.danshafer.com/valueprofile.html
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

> > >
> > > wxPython uses British English spellings for most if not all of
> > its classes
> > > and methods (colour instead of color). PythonCard has been
> > using American
> > > English.
> >
> > You may want to expose both variants as people already using wxPython
will
> > be used to the 6 letter spelling.
>
> wxWindows/wxPython provides two spellings in the case of some methods:
> Center, CenterOnParent, CenterOnScreen, Centre, CentreOnParent,
> CentreOnScreen. How difficult would it be to add name variations for Color
> in wxPython if the wxWindows team didn't want to add them?

Yes, it's doable, and actually fairly easy to do now compared to when I
first started.

> Maybe all us
> yanks should just learn to use British English? ;-)

That's what I've done.  I always have to correct myself when typing colou^Hr
in other contexts.


> > > Most of the PythonCard component methods simply call their
> > counterparts in
> > > wxPython and we can probably safely get rid of these duplicated
methods.
> > For
> > > example:
> > >
> > >     def setInsertionPointEnd(self):
> > >         self.SetInsertionPointEnd()
> >
> > An easier way to take care of 1-1 mappings like this is to do
> > this at class
> > scope:
> >
> >     setInsertionPointEnd = wxTextCtrl.SetInsertionPointEnd
>
> Good point. When Rowland and I wrote the original code I had only been
> programming Python for about four months and Rowland even less and the
> solution above didn't occur to me. This is why we need more Python pros in
> the development group. So I wonder its possible to do something similar
for
> methods from the Widget class:
>
>     def _setPosition(self, aPosition):
>         self.Move(aPosition)
>
>     def _getPosition(self):
>         return self.GetPositionTuple()
>
> where the Widget class doesn't know about wxTextCtrl or wxWindow?

As long as Widget is always mixed with something that derives from wxWindow
(pretty safe bet) then yes it should work.

> I would like to have the first letter of a method lowercased, but since
one
> of the main points of this transition is to reduce the amount of work
> necessary to create a component on top of wxPython, we probably need to
> follow the wxPython naming conventions.

I like the leading-lower convention myself, but had to go with the
leading-upper to make the wrappers not be a nightmare.  If you want the
framework to be a mostly complete insulation from wxPython then I think
changing to leading-lower is okay.  Otherwise, if it's going to be a mixture
then consistency is best.  Just be sure that any framework names that
replace the wxPython names have the same parameters and behaviours as the
original to help keep if non-confusing for the user.

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

I'm probably a minority voice in the wilderness here, but that's 
never slowed me down. :-)

I'm more of a Python newbie than probably anyone on this list, and 
I'm also a strong advocate for the non-programmer user (a la 
HyperTalk scripter) that I am drawn to love and nurture and advocate 
for.

For me, it doesn't matter so much whether it is _possible_ to do the 
more complex stuff Kevin outlined in his first message on this topic. 
I do feel like the incredibly long list of properties and methods 
associated with a component in wxWindows is unbelievably daunting for 
most people (even, I would dare to suggest, most professional 
coders). But what's far more important for me is where we choose to 
"drop the tablecloth."

The meaning of that phrase may be self-evident but indulge me while I 
explain just to be sure.

In any programming language or OS, there is a collection of readily 
accessible "stuff" that the primary intended market -- or the least 
savvy intended user, depending on perspective -- is expected to be 
able to see, grasp, and deal with. Then there is a tablecloth. Then 
there is the "other stuff" that only system-level programmers (in the 
case of an OS) or the Language Priesthood (in the case of the 
programming tool) is expected to grok.

For me, in the world of HyperThings -- of which I hope PythonCard 
will be a shining example -- this tablecloth needs to dropped very 
high in that food chain. When we describe PythonCard by saying, as we 
do, that simple programs should be easy and complex programs should 
be possible, we beg the question: easy for whom and possible to whom? 
For me, "whom" is the HyperTalk scripting level user.

I think I know that user as well as anyone, since on many levels I am 
one and since I've spent most of my computing career trying to 
understand and advocate for and support this group.

Allowing for the myopia that creeps in as a result of that focus, I 
want to suggest that as we struggle with this incredibly important 
defining moment in the development of PythonCard, we err consistently 
on the side of hiding complexity under the tablecloth.

What do I mean by this? Let me give a specific example.

In his original message on this subject, Fearless Leader said:

"Most of these methods can simply be ignored, just as most programs only need
the mouseClick and select events and can ignore mouseDown, mouseMove,
mouseContextClick, etc. For programming from the shell we can add a toggle
to automatically hide the base wxPython methods to simplify the autoComplete
list that the user sees most of the time."

I would like to see us take this basically sound approach one step 
farther. Object introspection should be layered so that a 
scripting-level user never even _sees_ the dozens of additional 
methods available for a given component. Those events and attributes 
defined in the present release of PythonCard (subject to further 
investigation and to learning from experience) should be the _only_ 
methods and properties the scripting-level user _can_ get at. For 
this user, the world is simple.

This approach implies that we create another level of PythonCard 
user, the Programming Level User (or perhaps something scarier like 
"Python God" or even "Programming Priest" :-) ) should be able to get 
at all of this directly inherited behavior.

I realize this makes PythonCard terribly schizoid. In fact, this 
design may not even be really feasible given the current level of 
resources available to make it happen. I clearly understand Kevin 
when he says that getting rid of the _delegate mechanism and moving 
to direct subclassing will make his job and that of other people 
helping to develop PythonCard more manageable. If, at the end of the 
day, that means we have to have an environment that exposes all of 
this additional complexity, then I think we need to openly abandon 
any notion of creating this product as the tool for Inventive Users 
for which I remain a staunch advocate.

Perhaps, in point of fact, what we need to do is to create PythonCard 
as a GUI app builder for wxWindows and then create what I now think 
of as PythonCard on _top_ of that platform.

I have little interest in helping to develop a programming aid for 
wxWindows and I would likely never make use of such a beast. But I am 
_passionate_ about a need for a souped-up HyperCard done in Python 
with Python as a scripting language and a strong subset of easily 
used and scripted components with which to assemble new apps and 
create new componentry.
-- 
Dan Shafer, Personal Creativity Trainer and Consultant
Trained Hartman Value Profile Analyst
http://www.danshafer.com/valueprofile.html

I've been thinking about redoing the general dialog interface so that rather
than creating a dialog and then getting all of the elements via methods such
as:

  dlg.accepted()

The return value would always be a dictionary with named parameters for all
the options {'accepted':1, 'returned':'Ok'}, something like that. You can
look at the dialogs.py sample to see how method calls are currently used. We
can already do dialog one-liners for the simplest dialogs as this shell
session shows:

>>> from PythonCardPrototype import dialog
>>> dialog.AlertDialog(None, 'a message', 'a title')

But this isn't possible with more complex dialogs. Using a dictionary return
value seems simpler and more Pythonic since the user doesn't have to
explicitly call ShowModal or Destroy and regardless of the dialog type the
result will always be a dictionary of name/value pairs.

It may cause issues where previously some dialog setup was done after
__init__, but I won't know until I dig a little deeper. The ModalDialog
class (dialog.py) in PythonCard already hides ShowModal and Destroy, but
still requires the use of methods after the dialog returns to get results.
GenericDialog (dialognew.py) hides less and would also need to be upgraded.

Opinions?

ka

> From: Robin Dunn
> >
> > wxPython uses British English spellings for most if not all of
> its classes
> > and methods (colour instead of color). PythonCard has been
> using American
> > English.
>
> You may want to expose both variants as people already using wxPython will
> be used to the 6 letter spelling.

wxWindows/wxPython provides two spellings in the case of some methods:
Center, CenterOnParent, CenterOnScreen, Centre, CentreOnParent,
CentreOnScreen. How difficult would it be to add name variations for Color
in wxPython if the wxWindows team didn't want to add them? Maybe all us
yanks should just learn to use British English? ;-)

> >
> > We need to be careful to avoid name conflicts with internal wxPython
> > attributes and methods such as this, thisone, etc.
>
> You probably mean thisown, right?

Yes.

> > Most of the PythonCard component methods simply call their
> counterparts in
> > wxPython and we can probably safely get rid of these duplicated methods.
> For
> > example:
> >
> >     def setInsertionPointEnd(self):
> >         self.SetInsertionPointEnd()
>
> An easier way to take care of 1-1 mappings like this is to do
> this at class
> scope:
>
>     setInsertionPointEnd = wxTextCtrl.SetInsertionPointEnd

Good point. When Rowland and I wrote the original code I had only been
programming Python for about four months and Rowland even less and the
solution above didn't occur to me. This is why we need more Python pros in
the development group. So I wonder its possible to do something similar for
methods from the Widget class:

    def _setPosition(self, aPosition):
        self.Move(aPosition)

    def _getPosition(self):
        return self.GetPositionTuple()

where the Widget class doesn't know about wxTextCtrl or wxWindow? We could
do it by overriding _setPosition and _getPosition in Button, TextField...
but that reduces the usefulness of the common code in Widget.

I would like to have the first letter of a method lowercased, but since one
of the main points of this transition is to reduce the amount of work
necessary to create a component on top of wxPython, we probably need to
follow the wxPython naming conventions.

> > As we transition, should we keep the old methods around for a release or
> two
> > or just make a clean break?
>
> If you transition away from the PythonCard *Prototype* to the PythonCard
> *Framework* (or whatever) at the same time then I would make a
> clean break.
> It will probably be simpler in the long run that way.

I can see doing one more release, say 0.6.4 that keeps the old wrapper
methods and then doing a release 0.7 that drops the old methods. Maybe
that's when we should bump up the requirements to Python 2.2 and drop the
Prototype from the package name as well?

I've checked the changes I've made so far into cvs.

ka

>
> wxPython uses British English spellings for most if not all of its classes
> and methods (colour instead of color). PythonCard has been using American
> English.

You may want to expose both variants as people already using wxPython will
be used to the 6 letter spelling.

>
> We need to be careful to avoid name conflicts with internal wxPython
> attributes and methods such as this, thisone, etc.

You probably mean thisown, right?


>
> Most of the PythonCard component methods simply call their counterparts in
> wxPython and we can probably safely get rid of these duplicated methods.
For
> example:
>
>     def setInsertionPointEnd(self):
>         self.SetInsertionPointEnd()

An easier way to take care of 1-1 mappings like this is to do this at class
scope:

    setInsertionPointEnd = wxTextCtrl.SetInsertionPointEnd

That way you get the new name without the overhead of another function call,
and if you ever need to do something extra in a future release then the
assignment can just be replaced with the def.  You can also use this
technique to allow both spellings of colour mentioned above:

    setForegroundColour = setForegroundColor = \
           wxWindow.SetForegroundColour

>
> Should we continue to have separate PythonCard components such as
TextField,
> PassworldField, TextArea or expose all of the possible styles for
wxTextCtrl
> and just have a single text field control? I lean towards the former
because
> it reduces the initial complexity of use and allows us to follow usage
> conventions such as always using wxTE_RICH for multi-line text fields to
> make GTK and Windows behave the same.

I think it depends on the perceptions of the newbie user.  Do they perceve
the three kinds of components as three different kinds of entry fields, or
three of the same kind with different options selected?


>
> As we transition, should we keep the old methods around for a release or
two
> or just make a clean break?

If you transition away from the PythonCard *Prototype* to the PythonCard
*Framework* (or whatever) at the same time then I would make a clean break.
It will probably be simpler in the long run that way.

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

The attribute is 'defaultBackgroundPosition'.

Mine is set as
'defaultBackgroundPosition':(5, 5),

The relevant code is around line 668 of model.py

        # override for application defined position
        position = config.getOption('defaultBackgroundPosition')
        if position is None:
            position = aBgRsrc.position

I think this has always been a manual option that you had to add yourself,
otherwise whatever default we provided would always end up overriding the
position defined in a sample.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Andy
> Todd
> Sent: Tuesday, February 12, 2002 3:23 AM
> To: Pythoncard-Users
> Subject: [Pythoncard-users] Playing with pythoncard_user_config.py
>
>
> Evening all,
>
> I've just been playing with PythonCard on my home machine and one of the
> first things I did was to set up my own pythoncard_user_config.py. I
> checked the documentation and couldn't find any way to specify the
> position of the application window in the config file. I can tell the
> framework where to place the shell window ('shellPosition':(10, 10)) or
> any of the other debug windows but there is no mention of how to specify
> a default position for the actual application window. If I use the "Save
> Configuration" option on the debug menu an entry is written to the user
> configuration file ('position':( x, y )) but this *seems* to be ignored
> the next time I start up the application.
>
> I started to trace this through the framework but gave up when my
> headache really kicked in. So, I'm going for the easy option - anyone
> want to explain to this rank amateur what I'm missing?
>
> BTW, as part of the install instructions we should/could provide a
> pythoncard.pth file with the name of the directory we install PythonCard
> into. If this is subsequently placed in the Python home directory (e.g.
> c:\Python22 on Windows) it automatically puts PythonCard on the Python
> path, no mucking about with $PATH variables or registry settings. Just a
> thought.
>
> Regards,
> Andy
> --
> -----------------------------------------------------------------------
>  From the desk of Andrew J Todd esq.
> "So I curtailed my Walpoling activities, sallied forth and infiltrated
>   your place of purveyance to negotiate the vending of some cheesy
>   comestibles." - Monty Python.
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Evening all,

I've just been playing with PythonCard on my home machine and one of the 
first things I did was to set up my own pythoncard_user_config.py. I 
checked the documentation and couldn't find any way to specify the 
position of the application window in the config file. I can tell the 
framework where to place the shell window ('shellPosition':(10, 10)) or 
any of the other debug windows but there is no mention of how to specify 
a default position for the actual application window. If I use the "Save 
Configuration" option on the debug menu an entry is written to the user 
configuration file ('position':( x, y )) but this *seems* to be ignored 
the next time I start up the application.

I started to trace this through the framework but gave up when my 
headache really kicked in. So, I'm going for the easy option - anyone 
want to explain to this rank amateur what I'm missing?

BTW, as part of the install instructions we should/could provide a 
pythoncard.pth file with the name of the directory we install PythonCard 
into. If this is subsequently placed in the Python home directory (e.g. 
c:\Python22 on Windows) it automatically puts PythonCard on the Python 
path, no mucking about with $PATH variables or registry settings. Just a 
thought.

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"So I curtailed my Walpoling activities, sallied forth and infiltrated
  your place of purveyance to negotiate the vending of some cheesy
  comestibles." - Monty Python.

Over the weekend I got direct subclasses of wxPython controls working. I
haven't checked it into cvs yet because I wanted to discuss the issues
before we cross over to this new way of doing things, plus I'm still
pondering the changes I've made. [If you want to test what I have so far,
email me directly and I'll send you a zip.]

I've been struggling with this email for the last couple of days trying to
cover as many issues as possible so that most of it should at least make
sense to those of you that have used wxPython and PythonCard even if you
might not have delved into much of the PythonCard framework itself. It is
likely that I've still overlooked some crucial issue that I won't think of
until I've pressed Send, but this should get us started. Please discuss any
and all issues below.

A little mantra to keep in mind while we ponder these issues...
"Simple apps should be simple, complex apps should be possible."

Let me start with a little history. Rowland Smith and I put together the
first PythonCard modules last summer after a week of discussion about basic
capabilities and design goals. At the time we thought it would be a good
idea to hide everything about the underlying GUI toolkit (wxPython was our
first target) so that it would be possible to substitute different toolkits
at a later date. The other big reason for wrapping the underlying API was so
that we could, at least in our minds, simplify the API and make it more
consistent.

That was a noble goal but completely unrealistic if we ever wanted to finish
it. There simply weren't enough people to do all the work. Also, it is hard
enough to not suffer lowest common denominator disease when dealing with one
toolkit that works on multiple platforms and probably impossible with
multiple toolkits on multiple platforms. [I'm hoping Magnus will prove me
wrong with anygui, but I wasn't willing to wait for a version of anygui that
does everything I need.] So, in the fall the decision was made to focus on
and leverage just one very powerful backend, wxPython. The trick is adding
value on top of wxPython while simplifying its use.

Some Goals
1. Get rid of _delegate attribute that used to be the actual reference to a
wxPython control
2. Reduce the amount of effort required to make a wxPython control available
as a native PythonCard component
3. Make PythonCard components compatible as parameters to existing wxPython
methods. The new form should allow us to pass our classes to other wxPython
methods transparently, but I haven't done extensive testing of this.
4. Dot notation for common attributes. For example, the ability to use
fld1.text instead of fld1.GetValue() and fld1.SetValue(). Dot notation also
ends up hiding some differences in wxPython method names.
5. Load layouts and menus from resources, including component default
initialization beyond wxPython and post-initialization (backgroundColor,
foregroundColor, font, toolTip, etc.)
6. Automatically bind events to components
7. Enforce a spec for each component
8. Leverage the existing wxPython documentation
9. Standardize on using an alphanumeric name attribute as the unique id for
components, windows, and menus.
10. Make the components self-describing, including type information.

Items 4, 5, 6, and 7 are things that PythonCard components currently do that
are not provided by the default wxPython controls. Item 9 is something that
is doable in wxPython for anything derived from the wxWindow class; menus
require additional wrapping to get that functionality. Item 10 has to do
with our move toward a true component model, which I won't get into in this
email.

Complexity exposed
Some components in PythonCard release 0.6.3.2 and earlier only have
attributes and no additional methods. However, once the switch is made to
direct subclasses of wxPython controls, all of the functionality and
complexity of a wxPython control is exposed.

To give you a better idea of what I'm talking about at the end of this
message I've listed the attributes and methods of the Button component
before (release 0.6.3.2 and earlier) and after I removed the _delegate
attribute and made Button derive from both the Widget class and wxButton.
There are over 160 additional methods and attributes exposed.

Do the new classes end up being more complex to use?

Most of these methods can simply be ignored, just as most programs only need
the mouseClick and select events and can ignore mouseDown, mouseMove,
mouseContextClick, etc. For programming from the shell we can add a toggle
to automatically hide the base wxPython methods to simplify the autoComplete
list that the user sees most of the time.

wxPython uses British English spellings for most if not all of its classes
and methods (colour instead of color). PythonCard has been using American
English.

wxPython uppercases the first letter of a method (AppendText) while
PythonCard has been following the convention of lowercasing the first letter
of a method (appendText).

We need to be careful to avoid name conflicts with internal wxPython
attributes and methods such as this, thisone, etc.

Most of the PythonCard component methods simply call their counterparts in
wxPython and we can probably safely get rid of these duplicated methods. For
example:

    def setInsertionPointEnd(self):
        self.SetInsertionPointEnd()

But there are some methods in PythonCard components that provide extra
functionality over their wxPython counterparts either to hide differences
between Windows and GTK or to correct some behavior of the wxPython method.

Should we continue to have separate PythonCard components such as TextField,
PassworldField, TextArea or expose all of the possible styles for wxTextCtrl
and just have a single text field control? I lean towards the former because
it reduces the initial complexity of use and allows us to follow usage
conventions such as always using wxTE_RICH for multi-line text fields to
make GTK and Windows behave the same.

In some areas I think we will need to expose the underlying wxPython
constants and styles. The dialog classes are the first thing that comes to
mind, but it could also apply to the components. Perhaps the solution is to
allow an optional 'styles' parameter that would override our defaults?

PythonCard has used some attribute caching, but that needs to go away to
make sure that if somebody changes an attribute using a native wxPython
method, there is no chance of a cached attribute getting out-of-sync.

If Robin figures out a good way to build Python-specific documentation for
wxPython and provide more meaningful arg lists than (*_args, **_kwargs) then
we should be able to build on top of that. Riaan has already done some work
in this area for Boa.

As we transition, should we keep the old methods around for a release or two
or just make a clean break?

In many ways, PythonCard ends up defining a set of naming and coding
conventions and helper classes to simplify many tasks that can be difficult,
especially for a beginner to grasp when using wxPython by itself. But,
because PythonCard sits on top of wxPython, you have the option of using
wxPython directly when necessary to build more complicated solutions.

ka

---
The following comparison does not include attributes and methods that start
with one or more underscores.

Attributes and methods of the Button component (class) in release 0.6.3.2
and earlier:
attributes:
backgroundColor, command, default, enabled, font, foregroundColor, label,
name, position, size, toolTip, visible

methods:
addEventListener, getId, notifyEventListeners, setFocus

Additional attributes and methods after the change to direct subclasses:
wxButton attributes and methods; wxButton is derived from wxControl,
wxWindow, wxEvtHandler, and wxObject:
AcceptsFocus, AddPendingEvent, CaptureMouse, Center, CenterOnParent,
CenterOnScreen, Centre, CentreOnParent, CentreOnScreen, Clear,
ClientToScreen, ClientToScreenXY, Close, Command, Connect,
ConvertDialogPointToPixels, ConvertDialogSizeToPixels,
ConvertPixelPointToDialog, ConvertPixelSizeToDialog, Create, Destroy,
DestroyChildren, Disconnect, DLG_PNT, DLG_SZE, DragAcceptFiles, Enable,
FindWindowById, FindWindowByName, Fit, Freeze, GetAcceleratorTable,
GetAutoLayout, GetBackgroundColour, GetBestSize, GetCaret, GetCharHeight,
GetCharWidth, GetChildren, GetClassName, GetClientSize, GetClientSizeTuple,
GetConstraints, GetDropTarget, GetEventHandler, GetEvtHandlerEnabled,
GetFont, GetForegroundColour, GetFullTextExtent, GetGrandParent, GetHandle,
GetHelpText, GetId, GetLabel, GetName, GetNextHandler, GetParent,
GetPosition, GetPositionTuple, GetPreviousHandler, GetRect, GetScrollPos,
GetScrollRange, GetScrollThumb, GetSize, GetSizer, GetSizeTuple,
GetTextExtent, GetTitle, GetToolTip, GetUpdateRegion, GetValidator,
GetWindowStyleFlag, Hide, InitDialog, IsBeingDeleted, IsEnabled, IsExposed,
IsExposedPoint, IsExposedRect, IsRetained, IsShown, IsTopLevel, Layout,
LineDown, LineUp, LoadFromResource, Lower, MakeModal, Move, MoveXY, OnPaint,
PageDown, PageUp, PopEventHandler, PopupMenu, PopupMenuXY, ProcessEvent,
PushEventHandler, Raise, Refresh, RefreshRect, ReleaseMouse, RemoveChild,
Reparent, ScreenToClient, ScreenToClientXY, ScrollLines, ScrollPages,
ScrollWindow, SetAcceleratorTable, SetAutoLayout, SetBackgroundColour,
SetCaret, SetClientSize, SetClientSizeWH, SetConstraints, SetCursor,
SetDefault, SetDimensions, SetDropTarget, SetEventHandler,
SetEvtHandlerEnabled, SetExtraStyle, SetFocus, SetFont, SetForegroundColour,
SetHelpText, SetId, SetImageLabel, SetImageMargins, SetLabel, SetName,
SetNextHandler, SetPosition, SetPreviousHandler, SetRect, SetScrollbar,
SetScrollPos, SetSize, SetSizeHints, SetSizer, SetTitle, SetToolTip,
SetToolTipString, SetValidator, SetWindowStyle, SetWindowStyleFlag, Show,
Thaw, this, thisown, TransferDataFromWindow, TransferDataToWindow,
UnsetConstraints, Update, Validate, WarpPointer

Did you ever wish you could paste a big chunk of code (like a class
definition, for example) from your editor directly into the PyCrust shell?
Now you can. Any valid sequence of Python code can now be pasted in from the
clipboard. Multiple commands and multiline commands (with or without
prompts, in the event that you are pasting from one shell to another) will
all be handled intelligently. Pasted in text is broken down into individual
commands which are executed and added to the command history. This new
functionality is bound to the Ctrl+Shift+V key combination.

Available in CVS, until the next release. Hope you like it.

---
Patrick K. O'Brien
Orbtech

A few people are having problems with CVS, which is a useful tool if you
want to be part of the development process, or even just to keep current
with what is being developed. So I thought I'd pass along a link to some
articles and manuals that can help get you over the CVS learning curve. Here
is one of the best places for CVS info:

http://www.cvshome.org/docs/

Hope that helps.

---
Patrick K. O'Brien
Orbtech