pythoncard-users — PythonCard Users and Developers

RE: [Pythoncard-users] What Do We Call These Things?

[David L. <wh...@oz...>]

Wow, if Bill Aitkinson is the God of Hypercard, Danny Goodman is surely one
of the prophets ;)

There's a reason why we're (well, you're) trying to implement Hypercard for
a wider audicence 20+ years after it's debut (not without a fight from Apple
i've read), and that is that it had/has a _simple_ NON programerish feel
about it - lots of people who felt intimidated by the idea of programming
where able to, and did, cope with Hypercard quite handily. It was simple
enough for Suzy Teen to keep her record collection on, yet capable enough
for the budding college biology student to start a species catalog on - and
even could work as a catalog for a business.

That original idea of a (3x5") card in a stack of cards is as sound now as
it was then. I suggest avoiding "compugeek speek" wherever possible - unless
you want to restrict your audience to that genre. Of course, there's a
surfeit of products for geeks...

Now, having said that (and, I realize, repeating to some extent the Good
man's post), I don't want to stifle any creativity/enhancements that are
possible. People _are_ more computer literate in general these days and that
implies a more computeresque interface and terminology, but I still say the
more of that you use, the less inclined "Aunt Doris", now retired, is going
to be inclined to take a stab at putting her award winning recipe collection
as a pass time for her "golden" years.

As for taking a leaf out of Microsoft's book... firstly, they bought or
stole the book or the idea for the book from someone else, drove all the
other book makers out of business and now sell poorly crafted books that
you're stuck with paying what _they_ think it, in their vastly self inflated
opinion, is a reasonable price for their Mediocre "books". (Now writing on
an Athelon running Windows 2000 Professional with Office 2000 and Visual C++
6.0 lurking. I hate Microsoft - every damned day. Of course, my other
computers are or will be running Linux :).) Secondly, I refer you to my
opinion wrt to using programerish jargon (valid and valuable though it might
be to a knowledgable user).

What I would hope to see in a Windows context, is a little control panel
sort of thing with the menubar and the stack itself floating on the desktop
with no menubar or other adornments the user didn't put there. This is
possible on Windows; you just have to write a new class (not a C++ class, a
Windows class) that doesn't use the non-client window styles (dunno how
easily that sort of thing is done in WxPython though). This "card" should be
able to get as close to looking like anything from a type-written 3x5 card
on up to something that looks like it was a 3-color press job, all depending
on the effort the user wants to put into their stack. The little control
panel thingie should be able to open several stacks at once and maybe
maintain a list of stacks it knows about (the "library").

No notion here that cards should be any particular size btw... although, I
think it makes sense to have all the cards in a single stack be the same
size - and maybe have "fold-outs"?

I guess my bottom line is that if you keep it simple, direct and
non-technical it will go far. Turn it into another forms-based application
generator and you're competing with the Microsurfs of Redmond - and, it
being a matter of legal judication, they cheat. The Hypercard paradigm has
stayed fresh enough to interest a new generation of developers 20+ years
after it's debut and there are few programs around that you can say that of.

Before I go, i've been meaning to mention that i've got some potential
resources: The original Hypercard spec book from Apple, Danny Goodman's
Hypercard book(s) up through 2.2, an actual Hypercard Manual and maybe even
still a book on an early Windows clone called SuperCard.

I now return to vigilant lurking :)

Dave LeBlanc
Seattle, WA USA

P.S. Oh geesh, I realize i've pretty much recapitulated what's already been
said, but i'm sending it anyway :)

"Near, but not of, the evil empire"

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Monday, January 07, 2002 14:12
> To: pythoncard-Users
> Subject: RE: [Pythoncard-users] What Do We Call These Things?
>
>
> > From: Dan Shafer
> >
> > Kevin suggested that he was thinking of moving away from HyperCard's
> > stack-background-card metaphor for a number of reasons. But he
> > remains appropriately adamant about keeping the simple-is-good
> > philosophy behind PythonCard. He ran up the flagpole the idea of
> > using Application, Form, and Panel. What follows is my thinking on
> > the subject, FWIW.
> >
> > Whether it's good, bad or indifferent for PythonCard to "lose" its
> > "HyperCard-ness" is, I think, less important in the long run than the
> > simple-is-good philosophy. But I think there's something
> > fundamentally sound and intuitive about the stack-background-card
> > metaphor that shouldn't get lost, at least for the Inventive User
> > audience. These non-programmers don't want to think in terms of
> > applications, forms and panels. Those are "geeky" things.
>
> The reasoning goes like this...
> Application is pretty obvious. A script is really an application.
> Applications are what everyone runs on their desktops. We even
> use the term
> WebApp which is really a horrible name. I suppose you could use the term
> "Program", but my gut tells me that if you say "Application" even newbie
> programmers and creative users know what you're talking about. Since there
> is no required runtime environment to use a PythonCard application, the
> stack/document confusion can go away.
>
> Form is 100% from my experience with Microsoft (MS) and wanting
> to leverage
> the "education" they've already given 3 million plus VB coders.
> Visual Basic
> programmers design Forms. .NET uses the terms WinForms for things outside
> the browser and WebForms inside the browser. [As a side note, the current
> implementation of WinForms and WebForms does not provide an easy way to
> translate between the two, which I'm told is because MS is a large company
> with two large programming groups that are not communicating very well :)]
> Whether you like it or not you are going to here about Forms a
> lot as the MS
> marketing kicks into high-gear this year.
>
> In MS terms, a Form can have "decorators" like a menubar, statusbar, and
> various window styles. That is what we are doing with Background in the
> resource file. I would like something that is just the stuff inside the
> Form. In wxPython, this can be a wxPanel and PythonCard is using a Panel,
> but for the most part it is hidden from the user code. MS also uses Panels
> inside Forms. You can nest Panels.
>
> For PythonCard, there is not much difference between the GenericDialog
> (modal dialogs) and Background classes except that GenericDialog is modal
> and needs buttons with specific button ids for OK and Cancel. You
> should be
> able to use the same layouts for either "window style".
>
> The only real reason PythonCard doesn't do scrolling windows
> right now is I
> couldn't decide where to split the panel/background/window
> settings. I did a
> working scrolling window demo back in August which just contained a really
> big Panel and it worked fine, but the window has a different window size
> than the Panel and at the time we still had 'size' in the 'stack' and we
> still don't distinguish between window and panel size. The same issue
> applies to other window styles.
>
> > I'm not certain that stack, card, background is the requisite
> > terminology set, but I do feel that something _like_ that set of
> > terms is necessary.
>
> Another possibility is what I suggested back in October when I started to
> get more serious about making PythonCard wxPython specific.
> PythonCard is a
> simplified way of doing wxPython applications. A more direct clone of the
> HyperCard stack/background/card metaphor could be used in an application
> written in PythonCard and would provide the lightweight database
> persistence
> expected of HyperCard apps. Even if/when we get the document classes in
> shape to support automatic saving of data and metadata for components, it
> will still be optional because not all applications need it.
>
> In fact, this could be a commercial possibility for someone or
> some company
> that wants to cater to ex-HyperCard users. Just an idea. I
> specifically want
> to avoid the GPL so that this kind of thing is at least a possibility.
>
> When PythonCard started I was definitely thinking in terms of stack,
> background, and card. All PythonCard apps use a Single Document Interface
> (SDI) style instead of Multiple Document Interface (MDI) and the resource
> format reflects the further restriction that there is only one menubar,
> which is more of a Mac thing, that Windows or Linux SDI where
> each "Window"
> can have its own menubar.
>
> As we progress the sweet spot I have in mind is somewhere between an
> "inventive user" and a VB-programmer and I would like to cater to both.
> PythonCard should be appropriate for someone learning Python as
> their first
> programming language in addition to someone coming from
> HyperCard, HyperCard
> clones, Visual Basic, REALBasic, and the tired masses of people
> like me that
> beat our heads against Java trying to build GUIs and eventually gave up. I
> don't particularly care about meeting the needs of teams of
> "sophisticated"
> programmers that would be more happy with Delphi or Microsoft
> Visual Studio,
> though hopefully PythonCard will be useful to those folks as well.
>
> Obviously, this stuff is not entirely crystal in my mind and we have a lot
> of room to morph the existing structure.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Re: [Pythoncard-users] What Do We Call These Things?

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

Kevin Altis wrote:

>>From: Dan Shafer
>>
>>Kevin suggested that he was thinking of moving away from HyperCard's
>>stack-background-card metaphor for a number of reasons. But he
>>remains appropriately adamant about keeping the simple-is-good
>>philosophy behind PythonCard. He ran up the flagpole the idea of
>>using Application, Form, and Panel. What follows is my thinking on
>>the subject, FWIW.
>>
>>Whether it's good, bad or indifferent for PythonCard to "lose" its
>>"HyperCard-ness" is, I think, less important in the long run than the
>>simple-is-good philosophy. But I think there's something
>>fundamentally sound and intuitive about the stack-background-card
>>metaphor that shouldn't get lost, at least for the Inventive User
>>audience. These non-programmers don't want to think in terms of
>>applications, forms and panels. Those are "geeky" things.
>>


I think the application/form/panel model or something like it is 
appropriate for the base level of PythonCard.  We need simple conceptual 
models that we can then use to build more complex, value-added 
components/frameworks.

A higher level framework, built on top of app/form/panel might trade off 
some flexibility for built-in goodies like automatic persistence, 
stack/background/card navigation, etc., and these objects could use the 
stack/background/card naming scheme.


> 
> The reasoning goes like this...
> Application is pretty obvious. A script is really an application.
> Applications are what everyone runs on their desktops. We even use the term
> WebApp which is really a horrible name. I suppose you could use the term
> "Program", but my gut tells me that if you say "Application" even newbie
> programmers and creative users know what you're talking about. Since there
> is no required runtime environment to use a PythonCard application, the
> stack/document confusion can go away.


I like Application - like you said, most people have a pretty good idea 
of what an application is.


> Form is 100% from my experience with Microsoft (MS) and wanting to leverage
> the "education" they've already given 3 million plus VB coders. Visual Basic
> programmers design Forms. .NET uses the terms WinForms for things outside
> the browser and WebForms inside the browser. [As a side note, the current
> implementation of WinForms and WebForms does not provide an easy way to
> translate between the two, which I'm told is because MS is a large company
> with two large programming groups that are not communicating very well :)]
> Whether you like it or not you are going to here about Forms a lot as the MS
> marketing kicks into high-gear this year.


Form doesn't give me a warm fuzzy, but it seems pretty reasonable since 
most PythonCard users would correctly guess that a form is a container 
for organizing components without having to be told so explicitly.  Most 
users would expect a Form to be persistable - either auto-magically or 
by using some persistence API.


> In MS terms, a Form can have "decorators" like a menubar, statusbar, and
> various window styles. That is what we are doing with Background in the
> resource file. I would like something that is just the stuff inside the
> Form. In wxPython, this can be a wxPanel and PythonCard is using a Panel,
> but for the most part it is hidden from the user code. MS also uses Panels
> inside Forms. You can nest Panels.


The MS decorators don't seem particularly intuitive to me.  I would 
think that a Window could contain a Form.  A Form could contain one or 
more Panels, and Panels can be nested.  In my mind, a Window ( not a 
Form ) has Decorators ( MenuBar, StatusBar, etc ) that are not directly 
related to the form.  I'm fuzzy on this one.

A Dialog is an extension of Window, so any Form could be placed in a Dialog.


> 
> For PythonCard, there is not much difference between the GenericDialog
> (modal dialogs) and Background classes except that GenericDialog is modal
> and needs buttons with specific button ids for OK and Cancel. You should be
> able to use the same layouts for either "window style".
> 
> The only real reason PythonCard doesn't do scrolling windows right now is I
> couldn't decide where to split the panel/background/window settings. I did a
> working scrolling window demo back in August which just contained a really
> big Panel and it worked fine, but the window has a different window size
> than the Panel and at the time we still had 'size' in the 'stack' and we
> still don't distinguish between window and panel size. The same issue
> applies to other window styles.
> 
> 
>>I'm not certain that stack, card, background is the requisite
>>terminology set, but I do feel that something _like_ that set of
>>terms is necessary.
>>
> 
> Another possibility is what I suggested back in October when I started to
> get more serious about making PythonCard wxPython specific. PythonCard is a
> simplified way of doing wxPython applications. A more direct clone of the
> HyperCard stack/background/card metaphor could be used in an application
> written in PythonCard and would provide the lightweight database persistence
> expected of HyperCard apps. Even if/when we get the document classes in
> shape to support automatic saving of data and metadata for components, it
> will still be optional because not all applications need it.
> 
> In fact, this could be a commercial possibility for someone or some company
> that wants to cater to ex-HyperCard users. Just an idea. I specifically want
> to avoid the GPL so that this kind of thing is at least a possibility.
> 
> When PythonCard started I was definitely thinking in terms of stack,
> background, and card. All PythonCard apps use a Single Document Interface
> (SDI) style instead of Multiple Document Interface (MDI) and the resource
> format reflects the further restriction that there is only one menubar,
> which is more of a Mac thing, that Windows or Linux SDI where each "Window"
> can have its own menubar.


FYI, I've been out of the loop for some number of weeks now due to 
selling my house and moving - hopefully I'm not rambling too much in my 
effort get back into the game ;)

All of our PythonCard work so far has really been view-centric.  We 
haven't spent any time on data models.  To use the unofficial new 
terminology, we have a type of view called Window.  A Form is also a 
view, but it indicates a supporting data model, say FormModel.  The data 
model isn't there yet.  If we could provide a set of classes that 
allowed a developer to develop a data model that could respond to and 
generate events, and be passed to an abstract persistence mechanism for 
storage/retrieval, then building an app like addressbook, etc., would be 
fairly trivial.  This would get us closer to the automatic persistence 
that was so nice in HyperCard.


The python dictionary type could be wrapped in a set of classes, where 
we define change events, new and delete events, etc., and access parts 
of the model by name like 'address.street' and 'purchase.items'.  We 
would need a mechanism for binding the data model to the form, so when 
data in the form changes, events are generated updating the model, and 
vice-versa.  All of this could be name based, where we link a form 
component by name to part of a model.

The persistence mechanism would then accept/produce FormModel objects, 
and we could have any number of persistence implementations.


> As we progress the sweet spot I have in mind is somewhere between an
> "inventive user" and a VB-programmer and I would like to cater to both.
> PythonCard should be appropriate for someone learning Python as their first
> programming language in addition to someone coming from HyperCard, HyperCard
> clones, Visual Basic, REALBasic, and the tired masses of people like me that
> beat our heads against Java trying to build GUIs and eventually gave up. I
> don't particularly care about meeting the needs of teams of "sophisticated"
> programmers that would be more happy with Delphi or Microsoft Visual Studio,
> though hopefully PythonCard will be useful to those folks as well.
> 
> Obviously, this stuff is not entirely crystal in my mind and we have a lot
> of room to morph the existing structure.
> 
> ka
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 



-- 
Talk to ya,
Rowland

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

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

[Pythoncard-users] SourceForgeTracker now uses DOM parsing

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

The big problem all along with the SourceForgeTracker sample appears to be
that SF is not generating valid XML documents. Anyway, I updated the code
this weekend and unless Mark or someone with more XML/Unicode knowledge than
me (aka everyone) suggests further changes I'm done with it for now.

Thanks to Mark Pilgrim for the DOM parsing code.
http://diveintopython.org/kgp_divein.html
Thanks to Mark Pilgrim and Martin Martin v. Loewis for help
with XML and UNICODE issues.
http://aspn.activestate.com/ASPN/Mail/Message/xml-sig/967244

It still doesn't download the Python Bug Tracker items because of an open
bug in the XML generator SF is using; the server runs out of memory and
chokes before the XML can be sent.

ka

RE: [Pythoncard-users] What Do We Call These Things?

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

> From: Danny Goodman
>
> This thread gets me off my duff because I think the card-ness of
> PythonCard's name and any metaphor used to describe its
> components shackles
> it with too much baggage (both good and bad). Those who know
> HyperCard well
> will have certain expectations that PythonCard is not intended to meet;
> those who may have only heard of HyperCard will feel like they
> have to know
> something else before getting to know PythonCard.

This seems to be the case so far.

> Hemispherical-floating-arm computers notwithstanding, anything

For those that missed it, Danny is referring to the non-event known as the
new iMac.
  http://www.apple.com/imac/
It is cool looking, but hardly earth shaking; many people were expecting the
second coming based on Apple's teasers last week.

> that conjures
> up "Apple" in non-Apple users'/programmers' minds is not a plus for the
> promotion of a new OS-platform-independent technology, IMHO. If
> it's a good
> authoring environment, it will attract old 'Card farts, like me
> (...and hi,
> Dan!) even if you name it something that would get bleeped on
> "South Park."

Agreed!

> And Kevin will be able to spend more time explaining what it is,
> rather than
> defending what it isn't.

Probably :)

I did reserve a project on SourceForge called Monty or wxMontyPython because
I think that this is the kind of project that is going to make Python
complete; remember that Python is from Monty Python not the snake. Pretty
cheeky, probably a bad choice.
  http://sourceforge.net/projects/montywxpython/
but nothing is there. It became pretty clear after a week of messages on
wxPython-users that I would basically just be doing what I thought of as
PythonCard, so until everyone agreed upon a name change I might as well
continue using the same cvs, mailing list, etc.

I like the PythonCard name and how some marketing has already been done for
us, but I guess a lot of anti-marketing has been done as well. If we call it
something like "Biffles" or "Maynard" then we have to start the marketing
from scratch. Just because this is open source doesn't mean that we can
"succeed" without marketing, word of mouth and proactive promotion are both
needed.

I'm still in the camp of not needing a real name until the Prototype is
removed from the package name, but we are very close to that point, so
decision time is coming.

ka

RE: [Pythoncard-users] What Do We Call These Things?

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

> From: Dan Shafer
>
> Kevin suggested that he was thinking of moving away from HyperCard's
> stack-background-card metaphor for a number of reasons. But he
> remains appropriately adamant about keeping the simple-is-good
> philosophy behind PythonCard. He ran up the flagpole the idea of
> using Application, Form, and Panel. What follows is my thinking on
> the subject, FWIW.
>
> Whether it's good, bad or indifferent for PythonCard to "lose" its
> "HyperCard-ness" is, I think, less important in the long run than the
> simple-is-good philosophy. But I think there's something
> fundamentally sound and intuitive about the stack-background-card
> metaphor that shouldn't get lost, at least for the Inventive User
> audience. These non-programmers don't want to think in terms of
> applications, forms and panels. Those are "geeky" things.

The reasoning goes like this...
Application is pretty obvious. A script is really an application.
Applications are what everyone runs on their desktops. We even use the term
WebApp which is really a horrible name. I suppose you could use the term
"Program", but my gut tells me that if you say "Application" even newbie
programmers and creative users know what you're talking about. Since there
is no required runtime environment to use a PythonCard application, the
stack/document confusion can go away.

Form is 100% from my experience with Microsoft (MS) and wanting to leverage
the "education" they've already given 3 million plus VB coders. Visual Basic
programmers design Forms. .NET uses the terms WinForms for things outside
the browser and WebForms inside the browser. [As a side note, the current
implementation of WinForms and WebForms does not provide an easy way to
translate between the two, which I'm told is because MS is a large company
with two large programming groups that are not communicating very well :)]
Whether you like it or not you are going to here about Forms a lot as the MS
marketing kicks into high-gear this year.

In MS terms, a Form can have "decorators" like a menubar, statusbar, and
various window styles. That is what we are doing with Background in the
resource file. I would like something that is just the stuff inside the
Form. In wxPython, this can be a wxPanel and PythonCard is using a Panel,
but for the most part it is hidden from the user code. MS also uses Panels
inside Forms. You can nest Panels.

For PythonCard, there is not much difference between the GenericDialog
(modal dialogs) and Background classes except that GenericDialog is modal
and needs buttons with specific button ids for OK and Cancel. You should be
able to use the same layouts for either "window style".

The only real reason PythonCard doesn't do scrolling windows right now is I
couldn't decide where to split the panel/background/window settings. I did a
working scrolling window demo back in August which just contained a really
big Panel and it worked fine, but the window has a different window size
than the Panel and at the time we still had 'size' in the 'stack' and we
still don't distinguish between window and panel size. The same issue
applies to other window styles.

> I'm not certain that stack, card, background is the requisite
> terminology set, but I do feel that something _like_ that set of
> terms is necessary.

Another possibility is what I suggested back in October when I started to
get more serious about making PythonCard wxPython specific. PythonCard is a
simplified way of doing wxPython applications. A more direct clone of the
HyperCard stack/background/card metaphor could be used in an application
written in PythonCard and would provide the lightweight database persistence
expected of HyperCard apps. Even if/when we get the document classes in
shape to support automatic saving of data and metadata for components, it
will still be optional because not all applications need it.

In fact, this could be a commercial possibility for someone or some company
that wants to cater to ex-HyperCard users. Just an idea. I specifically want
to avoid the GPL so that this kind of thing is at least a possibility.

When PythonCard started I was definitely thinking in terms of stack,
background, and card. All PythonCard apps use a Single Document Interface
(SDI) style instead of Multiple Document Interface (MDI) and the resource
format reflects the further restriction that there is only one menubar,
which is more of a Mac thing, that Windows or Linux SDI where each "Window"
can have its own menubar.

As we progress the sweet spot I have in mind is somewhere between an
"inventive user" and a VB-programmer and I would like to cater to both.
PythonCard should be appropriate for someone learning Python as their first
programming language in addition to someone coming from HyperCard, HyperCard
clones, Visual Basic, REALBasic, and the tired masses of people like me that
beat our heads against Java trying to build GUIs and eventually gave up. I
don't particularly care about meeting the needs of teams of "sophisticated"
programmers that would be more happy with Delphi or Microsoft Visual Studio,
though hopefully PythonCard will be useful to those folks as well.

Obviously, this stuff is not entirely crystal in my mind and we have a lot
of room to morph the existing structure.

ka

Re: [Pythoncard-users] What Do We Call These Things?

[Danny G. <da...@da...>]

[Offered simply as a non-constructive dart tossed from the back booth by
someone who hasn't contributed anything to the great work done here.]

This thread gets me off my duff because I think the card-ness of
PythonCard's name and any metaphor used to describe its components shackles
it with too much baggage (both good and bad). Those who know HyperCard well
will have certain expectations that PythonCard is not intended to meet;
those who may have only heard of HyperCard will feel like they have to know
something else before getting to know PythonCard.

Hemispherical-floating-arm computers notwithstanding, anything that conjures
up "Apple" in non-Apple users'/programmers' minds is not a plus for the
promotion of a new OS-platform-independent technology, IMHO. If it's a good
authoring environment, it will attract old 'Card farts, like me (...and hi,
Dan!) even if you name it something that would get bleeped on "South Park."

And Kevin will be able to spend more time explaining what it is, rather than
defending what it isn't.

Danny
http://www.dannyg.com

> 
> As much as I've been involved in PythonCard, I still don't know what exactly
> is meant by stack, background and card. Can someone provide definitions of
> these that make sense in wxPython terms, for those of us who never used
> HyperCard?

[Pythoncard-users] running python/wxpython on the Mac with emulation?

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

Note, if you send me a reply directly, I can post a summary to the lists.

I don't currently use a Mac (the old Performa I have with System 7.5 isn't
really that usable), but there are quite a few people interested in the
PythonCard project that only use Macs, so they are waiting for wxPython Mac
to be finished.

What I'm wondering is whether any of the free or commercial emulation
solutions would be good substitutes until wxPython Mac is available for use
with MacPython? Basically, they would just run a version of Python and
wxPython (win32 or GTK) for either Windows or Linux depending on the
emulation solution.

Is anyone already doing this on their Macs? Either OS classic or OS X? If
so, could you provide details of the configuration and installation or any
tricky parts of getting it to work?

Some possibilities:

VirtualPC
http://www.connectix.com/products/vpc5m.html

Bochs
http://bochs.sourceforge.net/

VMWare
http://www.vmware.com/

plex86
http://www.plex86.org/

XFree86
http://www.xfree86.org/
I had one person suggest "Just use wxGTK under Xfree86 in rootless mode..."
on OS X.

Thanks,

ka
---
Kevin Altis
al...@se...

Re: [Pythoncard-users] What Do We Call These Things?

[Francois G. <fgr...@al...>]

At 12:19 -0800 on 6/01/02, in message Pythoncard-users digest, Vol 1 
#123 - 2 msgs, you wrote:

>Solutions. Can we really say, though, that a solution is a book
>(which is what sort of flows naturally out of layouts and pages)? I
>don't think so.

That was the wording for ToolBook from Asymetrix back when they 
introduced the product in 1989 (?).
ToolBook was a HyperCard clone running on Window. A stack was a book, 
and a card was a page.
It is now a fully different product.

RE: [Pythoncard-users] What Do We Call These Things?

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

> As much as I've been involved in PythonCard, I still don't know
> what exactly
> is meant by stack, background and card. Can someone provide definitions of
> these that make sense in wxPython terms, for those of us who never used
> HyperCard?

We have two of the most popular HyperCard authors on this list and one of
the original authors of HyperCard, so one of them should probably be
providing an answer, not me.

There is not a one to one relationship between HyperCard terms and wxPython
windows and controls. I found a quote in "REALbasic for HyperCard Users"
http://www.oreillynet.com/pub/a/mac/2001/09/20/realbasic.html
that is relevant.

"HyperCard's card/background metaphor supports a light database where
storage, display, and searching come more or less free"

The whole article is interesting in that it sort of mirrors where we're at
with PythonCard right now. There is no automatic persistent storage in
PythonCard yet, the user code has to manage that.

wxPython windows, frames, panels, and controls are just GUI widgets, there
is no document model tied to them.

In HyperCard, the stack is more or less an "application" as we typically
think of them, but in reality was a HyperCard document. The stack contains
one or more backgrounds and each background can contain one or more cards.
Graphics, buttons, and fields can be placed on cards or backgrounds. Cards
are roughly equivalent to database records but every object (button, field,
card, background, stack) can have an associated script and the state of
every object is automatically saved as the user moves from card to card or
quits the stack (application). If you copy a card in HyperCard and go to
another stack and do a paste, then the card, it's background, all of its
attributes including the script, buttons, fields, and graphics on the card,
etc. are pasted as well; all the data and metadata stay with the object. The
contents of variables in memory are not preserved when the user quits.
People coding in HyperCard ended up using the buttons and fields on the
cards and backgrounds as variables. This is one of those things that makes
"real programmers" cringe.

If you aren't completely confused yet, then remember that stacks are
documents. So, in HyperCard you could have a lot of different stacks open at
once passing messages and sharing data back and forth. You didn't need to
write monolithic programs, because you could share the work between stacks.
For example, a Notes stack could access the fields in the Addresses stack
and it was a lot simpler than COM or XML-RPC or most of the other methods we
use to share data between apps/documents, but it only worked for HyperCard
stacks.

Most of my later stacks avoided the persistent storage and worked more like
PythonCard does today, just a single background with an external data store.

Here's another brief overview:
http://www.cs.sfu.ca/CourseCentral/SW/HyperCard/TeachHC/hcintro.html

I hesitate to send this message since when I reread the text I don't think
it really answers your question. Maybe somebody else will step in and give a
clear answer.

ka

[Pythoncard-users] PyCrust key bindings and usage

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

Patrick is busy with real work, so consider this temporary documentation for
the Shell (PyCrust) in PythonCard until Patrick comes up for air in a couple
of weeks.

Key bindings:
Home              go to the beginning of the line
Shift+Home        select to the beginning of the line
Shift+End         select to the end of the line
End               go to the end of the line
Ctrl+C            Copy
Ctrl+Shift+C      Copy with prompts
Ctrl+X            Cut
Ctrl+V            Paste
Ctrl+up arrow     Retrieve Previous History item
Alt+P             Retrieve Previous History item
Ctrl+down arrow   Retrieve Next History item
Alt+N             Retrieve Next History item
F8                command-completion of History item
    type a few characters of a previous command and then press F8

The arrow keys navigate up, down, left and right just like a text editor.

The Alt key combinations cause my system to beep.

Typing the period key '.' after a name causes the auto-complete popup menu
to appear. You can then use the up and down arrow keys and mouse to navigate
the menu. Typing letters will do an incremental search through the menu, so
you can often just type the first few characters of an attribute or method
name to jump to the correct item of a long menu. Pressing tab will cause the
currently selected menu item to be inserted after the period. Clicking
outside the menu or pressing the Esc key causes the auto-complete menu to
disappear.

Typing an open parens '(' after a function or method causes a tooltip popup
window to appear with the doc string (if available) for that function or
method. For example, when I do this:

>>> temp = ""
>>> temp.index(

I get the doc string for the index method:
"S.index(sub [,start [,end]]) -> int

Like S.find() but raise ValueError when the substring is not found."

Most of the PythonCard framework is missing doc strings right now, but that
will change as the API settles down. The one exception is the BitmapTurtle
class which is setup and ready to use from the shell if you run the turtle
sample. The tooltips are extremely useful for the Python Standard Library.

Copy with prompts means that the prefix lines will be copied in addition to
the text of the line(s). In general, you'll only need to do Ctrl+Shift+C
when you are doing example documentation such as the two lines below.

>>> bg = pcapp.getCurrentBackground()
>>> comp = bg.components


You can edit functions and other compound statements in the shell as well as
retrieve the compound statements via the command history. This is somewhat
difficult to describe, so just experiment. The one thing you definitely need
to be careful of when editing lines is to go to the end of the end (pressing
the End key is the quickest way) before pressing Return or Enter. Otherwise,
the remainder of the line will be put on the following line and you'll
probably have to backspace up to where you pressed return.

ka

RE: [Pythoncard-users] What Do We Call These Things?

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

As much as I've been involved in PythonCard, I still don't know what exactly
is meant by stack, background and card. Can someone provide definitions of
these that make sense in wxPython terms, for those of us who never used
HyperCard?

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

[Pythoncard-users] What Do We Call These Things?

[Dan S. <da...@gu...>]

Kevin and I were having an off-list dialog about the direction of the 
PythonCard application building technology. I'm most interested in an 
audience I call "Inventive Users." These are people who want to use 
their computers to solve problems that neither software developers 
nor IT shops tend to want to spend time on (or don't have the cycles 
for, or don't see a big enough market to bother with), who are 
willing to learn scripting but not programming, and who need things 
that rapidly prototype and turn into usable application-like things 
with minimal hassle.

Kevin suggested that he was thinking of moving away from HyperCard's 
stack-background-card metaphor for a number of reasons. But he 
remains appropriately adamant about keeping the simple-is-good 
philosophy behind PythonCard. He ran up the flagpole the idea of 
using Application, Form, and Panel. What follows is my thinking on 
the subject, FWIW.

Whether it's good, bad or indifferent for PythonCard to "lose" its 
"HyperCard-ness" is, I think, less important in the long run than the 
simple-is-good philosophy. But I think there's something 
fundamentally sound and intuitive about the stack-background-card 
metaphor that shouldn't get lost, at least for the Inventive User 
audience. These non-programmers don't want to think in terms of 
applications, forms and panels. Those are "geeky" things.

I'm not certain that stack, card, background is the requisite 
terminology set, but I do feel that something _like_ that set of 
terms is necessary.

For some time I've been noodling about this. I like substituting 
layout for background and page for card. I haven't come up with a 
better word for stack and without one, we almost have to revert to 
cards and backgrounds again. What is it people want to build? 
Solutions. Can we really say, though, that a solution is a book 
(which is what sort of flows naturally out of layouts and pages)? I 
don't think so.

Back when Kaleida was trying to figure this stuff out, they had some 
interesting metaphors but the lore seems lost at this point.

This is fertile ground for conversation, but more importantly I think 
it spells the degree to which a product like PythonCard can succeed 
among Inventive Users and that is my central vision for it.
-- 
Dan Shafer, Author-Consultant
http://www.danshafer.com
http://www.shafermedia.com

Re: [Pythoncard-users] Put on Your Maketing Caps

[Dan S. <da...@da...>]

I'm the new kid in town, so I can fearlessly jump into the marketing 
fray. So I will!

I think most of the release announcement is just fine. It just needs 
a little marketing sizzle up front and one or two other places. 
Here's my cut at a new first paragraph. It may be too wordy; I don't 
know the audience or the traditions involved here. But I think it 
captures the essence of PythonCard without setting up false 
expectations.

"PythonCard brings visual software development on Open Source tools 
to the masses, picking up where Apple's immensely popular but 
now-abandoned HyperCard product left off. Written entirely in the 
widely used and respected object-oriented Python scripting language, 
PythonCard enables end users to create applications and interfaces in 
a style that is reminiscent of Microsoft Visual Basic without the 
baggage of over-complexity for non-programmers. It then enables the 
developer with some minimal amount of programming or scripting 
experience to give the user's designs life and power through Python 
scripting."

Then I think it might be helpful to add a few words of description to 
some of the cooler samples and list only those that _are_ cool (to 
the intended audience) rather than trying to be exhaustive.

For the release statement, I'd leave out stuff that won't matter 
until they download the product (e.g., "A description of each....").

Well, there's a start for people to react to at least.


-- 
Dan Shafer, Author-Consultant
http://www.danshafer.com
http://www.shafermedia.com

[Pythoncard-users] fwd: MIME-RPC plus eval() security holes

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

http://www.mime-rpc.com/
"Because sending simple stuff should be easy and sending complex stuff
should be easy too."

MIME-RPC could be relevant to some future PythonCard communication, so this
is just to get it into our email archive.

Mark Pilgrim did a nice piece on the security holes of the current
implementation which is written in Python.
http://diveintomark.weblogger.com/stories/storyReader$196

This is relevant to PythonCard because we also use eval() and exec() in the
framework and in some if not all cases there are other safer ways to get the
same results. At some point, a cleanup will be in order. Lately, One of the
fixes I've been contemplating is a slight mod to the resource files, so we
can just use plain imports. Basically, we just need to add a variable name.
More on this issue later.

I haven't worried about eval() and exec() too much in the past because
anyone running PythonCard is no more vulnerable to attacks than they were
after they installed Python on their system. We aren't dynamically
downloading arbitrary modules and resource files from untrusted sites, so
the same rules apply as any other piece of code on your desktop.

ka

[Pythoncard-users] added position, size window to resourceEditor

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

I've added an example of using multiple windows to the resourceEditor. I
created a positionSize.rsrc.py file and added a PositionSize class to
resourceEditor.py. The class has an openBackground handler to setup a
wxFlexGridSizer, but that's about it.

The window is initialized with:

        rsrc = res.ResourceFile('positionSize.rsrc.py').getResource()
        self.positionSizeWindow = PositionSize(self.stack,
                                               self,
                                               rsrc,
                                               rsrc.stack.backgrounds[0])
        # override resource position
        self.positionSizeWindow.SetPosition((425, 5))
        # deleting the menubar may not be clean
        self.positionSizeWindow.SetMenuBar(wx.NULL)
        self.positionSizeWindow.Show()

And the actual work is done by a revised version of the old setToolTip
method

    def setToolTip(self, target):
        # in case the user closed the window
        self.positionSizeWindow.Show()
        self.positionSizeWindow.components.fldName.text = str(target.name)
        self.positionSizeWindow.components.fldPosition.text =
str(target.position)
        self.positionSizeWindow.components.fldSize.text = str(target.size)

So now as the mouse enters a component and during drag and resize
operations, the Position & Size window will show the component name and its
current position and size as the mouse is moved.

ka

[Pythoncard-users] cvs and changelog.txt

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

The latest version of the PythonCardPrototype is the one in cvs.
  http://sourceforge.net/cvs/?group_id=19015

I generally post to the list as I check in changes, but I also keep a
verbose changelog.txt file which you can visit at any time to see what
changes and bug fixes have been made since the last release zip.

The current changelog.txt is always at:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp
e/docs/changelog.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup

You can also get to the URL above via:
  http://pythoncard.sourceforge.net/toc.html#changelog

If there is demand, I can start making more frequent release zips.

Otherwise, if you would like to keep up with the latest changes, you can
just use anonymous cvs to download updates as they occur. If you don't know
how to use cvs, post a question to the list stating what OS platform you're
using and we'll try and point you in the right direction for the proper
tools and commands.

ka

RE: [Pythoncard-users] Message Watcher fix

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

The Message Watcher has been changed over to wxSTC. Thanks to Neil for the
code.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Neil
> Hodgson
> Sent: Wednesday, January 02, 2002 2:52 PM
> To: pythoncard-Users
> Subject: Re: [Pythoncard-users] Message Watcher fix
>
>
> > I updated the Message Watcher in cvs so that when the list starts to get
> > full it deletes the oldest messages in the list.
>
>    Have you considered using wxSTC for the message watcher? It has no 32K
> limit and avoids flickering better than RichEdit. It does not yet do line
> wrapping which you may want for a message viewer and the version that does
> do line wrapping will be slower. Scintilla has an early version of line
> wrapping now but it will take a while to stabilize and move to
> wxSTC. I will
> send Kevin a version of debug.py that uses wxSTC as its a bit
> large to post
> to the list.
>
>    Neil

RE: [Pythoncard-users] tentative multi-window success

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

I've modified the Background class in model.py so that it accepts a parent
window as its second parameter rather than an id. We weren't using the id
and this simple change makes it possible to use existing backgrounds as
child windows of the main window without any big modifications to the rest
of the framework. For example, I only had to change one line in the example
below, passing self instead of -1.

>         self.doodleWindow = doodle.Doodle(self.stack,
>                                           -1,
>                                           rsrc,
>                                           rsrc.stack.backgrounds[0])

is now:

         self.doodleWindow = doodle.Doodle(self.stack,
                                           self,
                                           rsrc,
                                           rsrc.stack.backgrounds[0])

The initialization of the background used by the samples isn't changed; they
all use the openBackground event to do initialization, rather than relying
on __init__.

This is not the final solution to the multi-window problem, just a simple
way for us to start experimenting. I know Andy wanted multiple backgrounds
for dbBrowser. The Message Watcher correctly shows events for all
backgrounds. The Property Editor will only show components of the main
background window.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Sunday, December 30, 2001 11:09 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] tentative multi-window success
>
>
> I was playing around tonight and decided to try an experiment. I
> duplicated
> the minimal directory and renamed it to 'multiwindow', then I copied the
> doodle.py and doodle.rsrc.py sample files into the 'multiwindow'
> directory.
> I added some imports to the minimal.py source file and an openBackground
> handler to load the resource file for doodle and code to create another
> background window. The source is below. Absolutely no changes were made to
> the doodle files.
>
> Get this, it worked the first time! The minimal window came up along with
> the doodle window and all the events worked fine. Exiting is a problem
> because the doodle window was not really a child of the minimal window, so
> both windows have to be closed separately, but I know how to fix that. I
> love being surprised.
>
> There are a number of places where the Background class needs to
> be tweaked
> and of course there are other issues, especially with the runtime debug
> windows, but it looks very promising. So just imagine that any
> 'background'
> can easily be used as part of your own program. Not a bad way to start the
> new year.
>
> We're more or less already doing this kind of thing with the GenericDialog
> windows and it makes me think that perhaps it might be better if each
> background resource was put in its own file. We also need to move the
> menubar as an attribute of the background instead of the stack, but that's
> another easy change.
>
> I just want to say that Rowland Smith's original framework is still pretty
> excellent kung fu! Kudos to Robin Dunn as well for wxPython and his other
> contributions as well as everyone else on the mailing list that has helped
> get PythonCard this far. This is so cool.
>
> Happy New Year,
>
> ka
> ---
>
> from PythonCardPrototype import model, res
> import doodle
>
> class Minimal(model.Background):
>     def on_openBackground(self, target, event):
>         rsrc = res.ResourceFile('doodle.rsrc.py').getResource()
>         self.doodleWindow = doodle.Doodle(self.stack,
>                                           -1,
>                                           rsrc,
>                                           rsrc.stack.backgrounds[0])
>         self.doodleWindow.Show()
>
>     def on_menuFileExit_select(self, menu, event):
>         self.Close()
>
> if __name__ == '__main__':
>     app = model.PythonCardApp(Minimal)
>     app.MainLoop()
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Re: [Pythoncard-users] anyone have problems launching from samples?

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

Cliff Wells wrote:

> On Thu, 3 Jan 2002 12:49:51 -0800
> "Kevin Altis" <al...@se...> wrote:
> 
> 
>>The popen call is probably the culprit since that is where the lockup
>>occurs, but I don't know enough about the internals of popen to know why.
>>
> If
> 
> Maybe he could verify it's popen() by running a sample from the interactive
> interpreter, e.g.
> 
> 
>>>>import os
>>>>os.popen("start python simpleBrowser.py")
>>>>
> <open file 'python2 simpleBrowser.py', mode 'r' at 0x80f9a80>
> 
>>>>  
>>>>
> 
> Perhaps popen() requires some updated version of some MS .dll to work.
> 
> 

When I started using Python I had all sorts of problems with popen on 
Windows98. There is a known 'problem' with the consumer Windows (95, 98, 
ME?) when trying to use popen if you have a version of Norton Antivirus 
(2 I think) running. Basically they fall over each other and the 
observed result is a big fat zero. I'd turn off NAV if you are running 
it and try again. IIRC an alternative solution is to upgrade to a later 
version of NAV.

Of course, if our user isn't running NAV them I'm stumped too as 
everything works fine on my Win98 box.

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

[Pythoncard-users] put on your marketing caps

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

I would like to update the release announcement for PythonCard. The old text
I have been using is at the end of this message.

This is a good time for the lurkers to come out of hiding and provide some
input. :)

A better release announcement might attract more users and developers and
help speed the development of PythonCard. If you've been using PythonCard
and think other people should too, then tell us why. All suggestions are
welcome.

ka
---

PythonCard is a software construction kit (in the spirit of Apple's
HyperCard) written in Python.

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

Samples included in the latest release: addresses, conversions, dbBrowser,
dialogs, doodle, findfiles, hopalong, minimal, proof, resourceEditor,
samples, searchexplorer, sounds, SourceForgeTracker, textIndexer, tictactoe,
turtle, widgets, worldclock

To see screenshots of some of the samples, visit:
http://pythoncard.sourceforge.net/samples.html
A description of each sample is included in the docs directory and the
readme.txt file in each sample directory.

PythonCard home page
http://pythoncard.sourceforge.net/

SourceForge summary page
http://sourceforge.net/projects/pythoncard/

Mailing list
http://lists.sourceforge.net/lists/listinfo/pythoncard-users


PythonCard requires Python 2.1.x or later and wxPython 2.3.x. wxPython is
available at http://www.wxpython.org/

PythonCard relies on wxPython, it will support the Macintosh once wxPython
has been ported to the Mac.

Re: [Pythoncard-users] anyone have problems launching from samples?

[Cliff W. <log...@ea...>]

On Thu, 3 Jan 2002 12:49:51 -0800
"Kevin Altis" <al...@se...> wrote:

> The popen call is probably the culprit since that is where the lockup
> occurs, but I don't know enough about the internals of popen to know why.
If

Maybe he could verify it's popen() by running a sample from the interactive
interpreter, e.g.

>>> import os
>>> os.popen("start python simpleBrowser.py")
<open file 'python2 simpleBrowser.py', mode 'r' at 0x80f9a80>
>>>   

Perhaps popen() requires some updated version of some MS .dll to work.

-- 
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308

[Pythoncard-users] anyone have problems launching from samples?

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

There is at least one user that gets a lockup when trying to launch a sample
while using the samples.py script under Windows 98. He is using Python 2.1.1
and wxPython 2.3.2.1. I can't reproduce the problem on my Win98 box and I've
never seen this problem under Windows 2000 either. He does not have any
problems running any of the samples from the command-line or double-clicking
to launch them from the Explorer.

He has the same problem with the Run command in the resourceEditor and when
double-clicking a grep result line in the findfiles sample, which attempts
to open the grep result file with textEditor.py. Those scripts use popen
under Windows just like the samples.py script.

The code in samples.py that does the work is shown below.

The popen call is probably the culprit since that is where the lockup
occurs, but I don't know enough about the internals of popen to know why. If
somebody else is having the same problem, at least we can try and isolate
the issue.

ka
---

    def on_btnLaunch_mouseClick(self, menu, event):
        name = self.components.listSamples.selected
        if name == "samples":
            path = ""
        else:
            path = name
        if os.path.exists(os.path.join(path, name + ".pyw")):
            filename = os.path.join(path, name + ".pyw")
            python = os.path.join(os.path.dirname(sys.executable),
'pythonw.exe')
        else:
            filename = os.path.join(path, name + ".py")
            python = sys.executable
        args = self.getCommandLineArgs()
        if sys.platform[:3]=='win':
            os.popen('start ' + python + ' ' + filename + args)
        else:
            os.system(python + ' ' + filename + args)

RE: [Pythoncard-users] HtmlWindows supported HTML tags

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

Here's an updated list of tags in alphabetical order. Vaclav Slavik updated
the docs after my original post.

ka
---
Tags supported by wxHTML
wxHTML is not full implementation of HTML standard. Instead, it supports
most common tags so that it is possible to display simple HTML documents
with it. (For example it works fine with pages created in Netscape Composer
or generated by tex2rtf).

Following tables list all tags known to wxHTML, together with supported
parameters. A tag has general form of <tagname param_1 param_2 ... param_n>
where param_i is either paramname="paramvalue" or paramname=paramvalue -
these two are equivalent. Unless stated otherwise, wxHTML is
case-insensitive.

Table of common parameter values

We will use these substitutions in tags descriptions:


[alignment]     CENTER
                LEFT
                RIGHT
                JUSTIFY

[v_alignment]   TOP
                BOTTOM
                CENTER

[color]         HTML 4.0-compliant colour specification

[fontsize]      -2
                -1
                +0
                +1
                +2
                +3
                +4
                 1
                 2
                 3
                 4
                 5
                 6
                 7

[pixels]        integer value that represents dimension in pixels

[percent]       i%
                where i is integer

[url]           an URL

[string]        text string

[coords]        c(1),c(2),c(3),...,c(n)
                where c(i) is integer


List of supported tags

A               NAME=[string]
                HREF=[url]
                TARGET=[target window spec]
ADDRESS
AREA            SHAPE=POLY
                SHAPE=CIRCLE
                SHAPE=RECT
                COORDS=[coords]
                HREF=[url]
B
BIG
BLOCKQUOTE
BODY            TEXT=[color]
                LINK=[color]
                BGCOLOR=[color]
BR              ALIGN=[alignment]
CENTER
CITE
CODE
DD
DIV             ALIGN=[alignment]
DL
DT
EM
FONT            COLOR=[color]
                SIZE=[fontsize]
                FACE=[comma-separated list of facenames]
HR              ALIGN=[alignment]
                SIZE=[pixels]
                WIDTH=[percent|pixels]
                NOSHADE
H1
H2
H3
H4
H5
H6
I
IMG             SRC=[url]
                WIDTH=[pixels]
                HEIGHT=[pixels]
                ALIGN=TEXTTOP
                ALIGN=CENTER
                ALIGN=ABSCENTER
                ALIGN=BOTTOM
                USEMAP=[url]
KBD
LI
MAP             NAME=[string]
META            HTTP-EQUIV="Content-Type"
                CONTENT=[string]
OL
P               ALIGN=[alignment]
PRE
SAMP
SMALL
STRIKE
STRONG
TABLE           ALIGN=[alignment]
                WIDTH=[percent|pixels]
                BORDER=[pixels]
                VALIGN=[v_alignment]
                BGCOLOR=[color]
                CELLSPACING=[pixels]
                CELLPADDING=[pixels]
TD              ALIGN=[alignment]
                VALIGN=[v_alignment]
                BGCOLOR=[color]
                WIDTH=[percent|pixels]
                COLSPAN=[pixels]
                ROWSPAN=[pixels]
TH              ALIGN=[alignment]
                VALIGN=[v_alignment]
                BGCOLOR=[color]
                WIDTH=[percent|pixels]
                COLSPAN=[pixels]
                ROWSPAN=[pixels]
TITLE
TR              ALIGN=[alignment]
                VALIGN=[v_alignment]
                BGCOLOR=[color]
TT
U
UL


> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Tuesday, January 01, 2002 6:47 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] HtmlWindows supported HTML tags
>
>
> I copied this list from the latest docs. I don't know when the docs were
> last updated, so the current wxWindows sources might actually support more
> than the tags below, but it is unlikely that wxHtmlWindow supports less. I
> would say the tags below are safe to use.
>
> ka
> ---
> Tags supported by wxHTML
> wxHTML is not full implementation of HTML standard. Instead, it supports
> most common tags so that it is possible to display simple HTML documents
> with it. (For example it works fine with pages created in
> Netscape Composer
> or generated by tex2rtf).
>
> Following tables list all tags known to wxHTML, together with supported
> parameters. A tag has general form of <tagname param_1 param_2
> ... param_n>
> where param_i is either paramname="paramvalue" or paramname=paramvalue -
> these two are equivalent. Unless stated otherwise, wxHTML is
> case-insensitive.
>
> Table of common parameter values
>
> We will use these substitutions in tags descriptions:
>
>
> [alignment]     CENTER
>                 LEFT
>                 RIGHT
>                 JUSTIFY
>
> [v_alignment]   TOP
>                 BOTTOM
>                 CENTER
>
> [color]         #nnnnnn
>                 where n is hexadecimal digit
>
> [fontsize]      -2
>                 -1
>                 +0
>                 +1
>                 +2
>                 +3
>                 +4
>                  1
>                  2
>                  3
>                  4
>                  5
>                  6
>                  7
>
> [pixels]        integer value that represents dimension in pixels
>
> [percent]       i%
>                 where i is integer
>
> [url]           an URL
>
> [string]        text string
>
> [coords]        c(1),c(2),c(3),...,c(n)
>                 where c(i) is integer
>
>
> List of supported tags
>
> P               ALIGN=[alignment]
>
> BR              ALIGN=[alignment]
>
> DIV             ALIGN=[alignment]
>
> CENTER
>
> BLOCKQUOTE
>
> TITLE
>
> BODY            TEXT=[color]
>                 LINK=[color]
>                 BGCOLOR=[color]
>
> HR              ALIGN=[alignment]
>                 SIZE=[pixels]
>                 WIDTH=[percent]
>                 WIDTH=[pixels]
>
> FONT            COLOR=[color]
>                 SIZE=[fontsize]
>         FACE=[comma-separated list of facenames]
>
> U
>
> B
>
> I
>
> EM
>
> STRONG
>
> CITE
>
> ADDRESS
>
> CODE
>
> KBD
>
> SAMP
>
> TT
>
> H1
>
> H2
>
> H3
>
> H4
>
> H5
>
> H6
>
> A               NAME=[string]
>                 HREF=[url]
>
> PRE
>
> LI
>
> UL
>
> OL
>
> DL
>
> DT
>
> DD
>
> TABLE           ALIGN=[alignment]
>                 WIDTH=[percent]
>                 WIDTH=[pixels]
>                 BORDER=[pixels]
>                 VALIGN=[v_alignment]
>                 BGCOLOR=[color]
>                 CELLSPACING=[pixels]
>                 CELLPADDING=[pixels]
>
> TR              ALIGN=[alignment]
>                 VALIGN=[v_alignment]
>                 BGCOLOR=[color]
>
> TH              ALIGN=[alignment]
>                 VALIGN=[v_alignment]
>                 BGCOLOR=[color]
>                 WIDTH=[percent]
>                 WIDTH=[pixels]
>                 COLSPAN=[pixels]
>                 ROWSPAN=[pixels]
>
> TD              ALIGN=[alignment]
>                 VALIGN=[v_alignment]
>                 BGCOLOR=[color]
>                 WIDTH=[percent]
>                 WIDTH=[pixels]
>                 COLSPAN=[pixels]
>                 ROWSPAN=[pixels]
>
> IMG             SRC=[url]
>                 WIDTH=[pixels]
>                 HEIGHT=[pixels]
>                 ALIGN=TEXTTOP
>                 ALIGN=CENTER
>                 ALIGN=ABSCENTER
>                 ALIGN=BOTTOM
>                 USEMAP=[url]
>
> MAP             NAME=[string]
>
> AREA            SHAPE=POLY
>                 SHAPE=CIRCLE
>                 SHAPE=RECT
>                 COORDS=[coords]
>                 HREF=[url]
>
> META            HTTP-EQUIV="Content-Type"
>                 CONTENT=[string]

[Pythoncard-users] additional Icon support

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

Thanks to some code from Robin, I've updated the _setIcon method in the
Background class to support additional file types for the application icon
besides .ico files. This should be able to load ICONs and XPMs on both
Windows and Linux, so you aren't just limited to .ico files.

    def _setIcon( self, aResource ) :
        """Set icon based on resource values"""
        if aResource.__dict__.has_key('icon') and aResource.icon != None:
            try:
                icon = wx.wxEmptyIcon()

icon.CopyFromBitmap(wx.wxImage(aResource.icon).ConvertToBitmap())
                self.SetIcon(icon)
            except:
                pass

The background dialog in the resourceEditor was updated too.

ka

Re: [Pythoncard-users] Message Watcher fix

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

> I updated the Message Watcher in cvs so that when the list starts to get
> full it deletes the oldest messages in the list.

   Have you considered using wxSTC for the message watcher? It has no 32K
limit and avoids flickering better than RichEdit. It does not yet do line
wrapping which you may want for a message viewer and the version that does
do line wrapping will be slower. Scintilla has an early version of line
wrapping now but it will take a while to stabilize and move to wxSTC. I will
send Kevin a version of debug.py that uses wxSTC as its a bit large to post
to the list.

   Neil