pythoncard-users Mailing List for PythonCard (Page 178)

> From: Patrick K. O'Brien
>
> If you examine an object in the PyCrust namespace tree you will
> see that it
> is easy to get the source code for a particular method of an object. So it
> wouldn't be impossible to do a VB-like edit-the-code-behind-the-object IDE
> environment. Or at least position the user on the relevant
> starting point in
> the code file. (Which Kevin's FindFiles app already does as well.)

The problem in a Python editor is that because there is no type information
until a variable has been evaluated it is difficult to supply documentation,
a list of methods or attributes.

From http://diveintopython.org/odbchelper_funcdef.html
"So Python is both dynamically typed (because it doesn't use explicit
datatype declarations) and strongly typed (because once a variable has a
datatype, it actually matters)."

The command completion I can get from a VB or Java or C++ editor is one of
the things I miss most about Python. In some cases the editor could work
like the shell (PyCrust) where you have a lot of clues about the objects
being used and provide autocompletion for variables. PythonWin does this for
a script once it has been executed, but it is haphazard and if you change
the type of a variable it gets confused. This probably falls under the hard
category until Python provides optional type info for variables.

Ideas or corrections are welcome.

ka

> > -----Original Message-----
> > Kevin Altis wrote:
> >
> [snip]
> >
> > We already have the Shell component, we just continue to use PyCrust.
> >
> >
> > In the "six blind men describe the beast" thread, Neil Hodgson said:
> >    "Writing a small editor isn't all that hard. I don't expect
> the initial
> > version of an editor for PythonCard that handled the vast
> > majority of needed
> > features would take long at all. You can get tied up in details
> > though. The
> > biggest question to me would be how do you determine which files
> > are part of
> > a PythonCard project and where within those files are the event
> > handlers? Do
> > you do VB style file segmentation or just present the whole file to the
> > user?"
> >
> > ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Likewise, in a grossly oversimplified way, ZODB can be seen as just
shelve-on-steroids - it still pickles objects and any object that can be
pickled can be stored in the ZODB.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Saturday, January 26, 2002 11:26 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] fwd: pickle compatibility
>
>
> This is probably relevant to the shelve investigation.
>
> The Google URL was a bit long, so here's an ASPN link
> http://aspn.activestate.com/ASPN/Mail/Message/python-list/1001109
>
> ka
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

> From: Dan Shafer
>
> But in the near term, I'd personally prefer to use ZODB for a lot of
> reasons, some technical and some selfish. However, I wonder about
> what this does to the already limited universality of PythonCard.
> We'd require people to download a standalone ZODB as part of
> installing PythonCard (or bundle it with the install, bloating it in
> the process). We get shelve for free in Python.

Issues
1. There is ZODB in Zope and there are different versions of Zope, so we
probably have to specify a minimum required version. I don't think we should
require someone to install Zope in order to use PythonCard, but if they have
Zope it would probably be nice for them to be able to use ZODB without an
additional install.

2. There is also StandaloneZODB, which is available in an old form from
Andrew Kuchling and a newer form from the StandaloneZODB group, but they've
only done release candidates so far. Andrew's release and the new one
differ, and in particular the new release is missing the PersistentList
class which the textIndexer sample happens to require. There isn't a
StandaloneZODB 1.0 final, nor is there a binary installer for Windows or Mac
OS. The lack of a binary installer is a major limitation for non-Linux
users.

3. I got the impression that StandaloneZODB would eventually be rolled into
the standard Python distribution, but I may just be dreaming.

4. My stock answer on any install issues at this point is that PythonCard is
still alpha, so it is okay to expect developers and users to use cvs if they
want to keep current and download additional packages for some samples.

5. At some point (late beta stage?) I think we need an easy to use installer
at least for Windows and the Mac and if possible, Linux. Robin Dunn and I
talked about that the first time PythonCard was brought up. This could be a
single big Python/wxPython/PythonCard/StandaloneZODB/etc. distribution. A
better solution would probably be a binary installer that installed Python
if it wasn't already available on the users machine and then automatically
run through the other package installs automatically, downloading the latest
versions of the packages, unzipping, running more installers, etc. This is
actually a generic Python problem, so if one or more people in our group
want to actively pursue this as a more generic Python solution I'm sure
other volunteers would pop out of the woodwork.

6. Even with a lot of samples, we're a long way from download size bloat.

7. One of my biggest concerns with ZODB as our general mechanism is also
valid for Shelve, but Shelve would be easier to deal with. Namely, there are
no good ways of dealing with data stuffed into an object database when you
go and change the classes. Perhaps versioning and careful attention to
backward compatible class changes will help, but this is a pretty
fundamental issue.

People interested in ZODB should join or at least follow the ZODB-dev list
http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/ZODB-dev

ka

Ooh, ooh, yes! I agree completely. At least at this point in the game. Let's
pick one object persistence method and take it to the extreme. I think we
should decide between MetaKit and ZODB. They seem to be the strongest
options at this point. Anyone who wants to do SQL can still do so. But I'd
really like to pursue one way of persisting Python objects from Pythoncard.

---
Patrick K. O'Brien
Orbtech

> Dan Shafer wrote:
>
> I'm inclined to buy into the idea of a broader solution integrating
> the persistent store at the core of the document model into the
> framework architecture more tightly than just using an existing
> storage mechanism sort of "as is." Smalltalk, in particular, has
> developed some very strong and nicely generic design for
> change-notification mechanisms (though its native object persistence
> has always been a major gap).
>
> OTOH, I think we need a sort of default mode for persistence that is
> simplified from a generic architecture and that can be transparent to
> end users (inventive users, scripting users, power users, whatever we
> want to call them), including those who want to create applications
> that rely on auto-storage of objects and documents without worrying
> about how that happens or understanding it.
>
> So I'd suggest we architect the persistence mechanism into the
> framework API in such a way that the designer who is cognizant of
> storage alternatives or who is designing in an environment where the
> store is pre-determined can either use an existing component that
> handles that effort or follow clear guidelilnes for writing a
> component for a specific data storage need.
>
> I'm also strongly predisposed to suggest that we emphasize _object_
> store rather than relational models, which are always kludges when it
> comes to serializing and storing objects of any depth or complexity
> at all. Not to say we shouldn't allow SQL data storage of information
> stored in PythonCard applications, but only that our design and our
> default ought to be OO to the core, like the beautiful language we
> are using to craft it.
> --
> Dan Shafer, Author-Consultant
> http://www.danshafer.com
> http://www.shafermedia.com
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Patrick suggested that we use ZODB for our PythonCard persistence. 
After looking into the shelve stuff and then looking at ZODB, my 
sense is that eventually we'd like to support both via an API that 
just deals with persistence.transparently.

But in the near term, I'd personally prefer to use ZODB for a lot of 
reasons, some technical and some selfish. However, I wonder about 
what this does to the already limited universality of PythonCard. 
We'd require people to download a standalone ZODB as part of 
installing PythonCard (or bundle it with the install, bloating it in 
the process). We get shelve for free in Python.

So while I really agree with Patrick and would be inclined to prefer 
ZODB for all my projects, I just wanted to raise the issue about ZODB 
on the list for feedback.


-- 
Dan Shafer, Personal Creativity Trainer and Consultant
Trained Hartman Value Profile Analyst
http://www.danshafer.com/valueprofile.html

If you examine an object in the PyCrust namespace tree you will see that it
is easy to get the source code for a particular method of an object. So it
wouldn't be impossible to do a VB-like edit-the-code-behind-the-object IDE
environment. Or at least position the user on the relevant starting point in
the code file. (Which Kevin's FindFiles app already does as well.)

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> Kevin Altis wrote:
>
[snip]
>
> We already have the Shell component, we just continue to use PyCrust.
>
>
> In the "six blind men describe the beast" thread, Neil Hodgson said:
>    "Writing a small editor isn't all that hard. I don't expect the initial
> version of an editor for PythonCard that handled the vast
> majority of needed
> features would take long at all. You can get tied up in details
> though. The
> biggest question to me would be how do you determine which files
> are part of
> a PythonCard project and where within those files are the event
> handlers? Do
> you do VB style file segmentation or just present the whole file to the
> user?"
>
> ka

I've written a general event/signal dispatching mechanism that you might
find useful for this. The code is available on the Python Cookbook site:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/87056

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> Rowland Smith wrote:

[snip]

> Advanced Features
>
> 8.  Allow a user to somehow connect the events generated by
>      one component to the methods published by another component.
>      Some number of logical 'connector' classes will be required
>      to allow the wiring together of events and methods
>      to build complex behaviors.

[snip]

> Events
>
> Components generate Events. Components publish the names of the
> Events that they support.
>
> Components register Listeners.  Components notify registered Listeners
> when Events occur.  Each Event contains a reference to the Component
> that generated the Event.

Yes, yes, yes! I think the next major push should be to focus on the model,
and I intend to help. I would also like to suggest that ZODB is where we
should go to persist these objects.

---
Patrick K. O'Brien
Orbtech

Rowland Smith wrote:
>
> 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.

My take on this is that a Hypercard application could be seen as a
collection of persistent object instances. In this case, each object
instance also knew about its display properties and could override them. So
the *class* would be "defined" to have a particular background (with a set
of buttons, etc.), but each *instance* (card) could have specific additions
(different background).

It seems to me that one could replicate much of this behavior using the
ZODB. But that would imply that we wanted the display mechanism and the
object data to be tightly intertwined and both stored in the database. That
is not how the Pythoncard framework is designed now. And I'm not sure
everyone would agree that this is a good idea. At the same time, I don't
think it would be too much of a stretch to imagine all the Pythoncard
resource files existing in the ZODB for the app. But then we have the same
problem as Zope - programmers want these kinds of things to be text files,
not buried in the database.

Just a bit of rambling.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> Francois Granger
> Sent: Sunday, January 06, 2002 3:22 PM
> To: pyt...@li...
> Subject: Re: [Pythoncard-users] What Do We Call These Things?
>
>
> 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.
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

I'm finally getting back to Pythoncard and catching up on the previous
discussions. Between your explanations and the O'Reilly article I finally
understand the HyperCard metaphors. Thanks, Kevin. Your efforts were not in
vain.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Sunday, January 06, 2002 6:58 PM
> To: pythoncard-Users
> Subject: RE: [Pythoncard-users] What Do We Call These Things?
>
>
> > 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.
[snip]
>
> 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

Thanks Neil! I started using it today when I did the radioclient screen
shot. This is a great simple little utility that produces good results and
is easy to use.

I thought there were some browsers that couldn't display PNG, but I guess
they are going to be out of luck.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Neil
> Hodgson
> Sent: Sunday, February 03, 2002 3:24 PM
> To: pythoncard-Users
> Subject: Re: [Pythoncard-users] better GIF screen shots on Windows
>
>
>    Hi Kevin,
>
> > Then I bring up Microsoft Paint which comes with Windows and paste that
> into
> > a new document and save in GIF format. When the image is
> converted to GIF,
> > the colors are reduced to 256 (8-bit) and at that point any smooth color
> > gradients get messed up.
>
>    On Windows, I save screenshots as true colour BMPs from Paint
> and the use
> bmp2png to convert to PNG format. This preserves gradiants and
> other images
> and compresses reasonably well.
> http://hp.vector.co.jp/authors/VA010446/b2p-home/index.html
>
>    Neil
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Another day, another typo found. Line 1185 of resourceEditor.py should be

desc += SPACES * 4 + "   'command':'%s',\n" % menuItem.command

Somehow I managed to delete the c in 'command'. Any edits on resource files
that use menu commands would result in bogus output text of 'ommand' which
you can search for in your own .rsrc.py files if you know you've done some
edits with the resourceEditor.

Anyway, cvs is fixed.

ka

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp
e/samples/radioclient/

This is a program for playing around with XML-RPC, SOAP, and the Blogger API
using a Radio Userland 8 server. The sample used to be called bloggertest,
but I renamed it.

The big readme.txt file is included at the end of this message.

I've spent a lot of time in the last two weeks playing with XML-RPC, Blogger
and SOAP and I wanted to have a sample that was simpler to modify and
experiment with than Simon's textRouter. You should not use radioclient
without the understanding that you are working on live data and could
corrupt your blog, so user beware (see the readme). radioclient starts up
the shell automatically and imports xmlrpclib and Mark Pilgrim's blogger
module, which I included with the sample. This makes it relatively simple to
run additional tests from the shell, so I also included a tests directory of
various XML-RPC, SOAP, and blogger tests I've run so far.

I expect that Dan Shafer, myself and possibly others will have more to say
about this sample in the future. I hope we might do some tutorials to
introduce people to client web services using PythonCard as well as
modifications to the app so it can interact with other blog sites.

ka
---
readme.txt:

This app is a playground of sorts for testing XML-RPC, the Blogger API, and
SOAP using a local Radio Userland 8 server. The interface is designed for
easy testing and experimenting in Python, so it is not particularly user
friendly. If you know the IP address, username, and password for a remote
server, radioclient can also talk to that box by changing the following line
in the on_openBackground method:

        # username, password, server url
        self.blog = RadioBloggerSite('', '', 'http://127.0.0.1:5335/RPC2')

*** A WARNING ***
This is not a commercial tool supported by Userland or connected in any way
with the Radio Userland 8 product. This is a development app done by open
source developers that use Radio and is part of the PythonCard samples
designed to help stress and show off the PythonCard framework.

Since this app is talking to a live server, you are viewing, adding,
editing, and deleting real data. If you are using the default Radio
settings, your changes will be upstreamed to the public Radio server as
changes are made. You should keep backups of your data, templates, and
generated pages.
*** YOU HAVE BEEN WARNED ***

WINDOWS ONLY
Radio 8 is only available for Windows and the Macintosh. PythonCard, which
relies on wxPython, works on Windows and Linux/GTK, but isn't available on
the Mac yet, except using a Windows emulator or running wxGTK on Mac OS X.
So, for the time being this sample is effectively just for Windows users
that also have Radio 8.

RADIO AND THE BLOGGER API
Radio implements the Blogger API as defined at
http://plant.blogger.com/api/index.html
As of Radio 8.0.2
  it doesn't implement getUserInfo
  getUsersBlogs returns info about the public Radio server not the local
server
  getTemplate and setTemplate appear to only work with the 'main' template
This test app will be updated as changes are made to the blogger api in
Radio


Over time, this app might be expanded to include additional tests against
other XML-RPC, Blogger API, and SOAP web services. The tests folder contains
interactive shell sessions using various web service libraries.

Note that wxPython has a great multi-column list control called wxListCtrl
that will eventually be supported in PythonCard. Until then, the columns are
being simulated with tabs and/or spaces in a plain List.



WEBLOGS PING
Mark is supposed to just wrap this one-liner into blogger.py, so I'm not
going
to add it to my own wrapper classes unless he doesn't do that soon.

# http://diveintomark.org/archives/00000054.html
"Actually, XML-RPC is easier in Python than almost any other language,
because the XML-RPC library uses a very cool feature of Python called
"dynamic binding" to create a kind of virtual proxy that lets you call
remote functions with exactly the same syntax as calling local functions.

import xmlrpclib
remoteServer = xmlrpclib.Server("http://rpc.weblogs.com/RPC2")
remoteServer.weblogUpdates.ping(SITE_NAME, SITE_URL)

This short example pings weblogs.com to tell it that your weblog has
changed. I use this script to connect this Greymatter weblog to the
weblogs.com community (since Greymatter has no weblogs.com support built
in). But the point here is the syntax of that third line: it's the same
syntax as calling a local function. Once the proxy (remoteServer) is set up,
the XML-RPC library makes the object act as if it has a weblogUpdates object
within it and a ping method within that. It's all a lie, of course; under
the covers it's constructing an XML-RPC request and sending it off, and then
receiving an XML-RPC response and parsing it and returning a native Python
object. But I, as a Python developer, don't have to worry about all that if
I don't want to, and I don't have to learn a new syntax for calling remote
functions."


REFERENCES

Python
http://www.python.org/

win32 extensions
http://starship.python.net/crew/mhammond/win32/Downloads.html

wxPython
http://www.wxpython.org/
windows binaries at: http://www.wxpython.org/download.php#binaries

PythonCard
http://pythoncard.sourceforge.net/

xmlrpclib (use 0.9.9 if you have Python 2.1.x, it is included as part of
Python 2.2)
http://www.pythonware.com/downloads/index.htm#xmlrpc

pyblogger
http://sourceforge.net/projects/pyblogger/

The Blogger API
http://plant.blogger.com/api/index.html

Radio Userland 8
http://radio.userland.com/

emulatingBloggerInRadio
http://radio.userland.com/emulatingBloggerInRadio

emulatingBloggerInManila
http://scriptingnews.userland.com/backissues/2001/08/24#manilaSupportsTheBlo
ggerApi
http://frontier.userland.com/emulatingBloggerInManila
http://bloggerapitest.manilasites.com/

textRouter (a manila/blogger app written in PythonCard by Simon Kittle)
http://simon.kittle.info/textrouter

Python.Scripting: Python, XML-RPC and SOAP
http://python.scripting.com/

Python and XML: An Introduction
http://www.infector.com/Paul/Python/XML_intro.html

Randy Lea wrote:

> I'm writing an RPN calculator app as a tool for learning PythonCard 
> (which is really cool, thanks ka!). For the result window, I think 
> I need the wxRightTextCtrl widget recently added in wxPython 2.3.2 to 
> display right justified text. I don't believe wxRightTextCtrl is 
> available in PythonCard yet, so if thats the case, will it be added 
> soon? If not, maybe I can try to create a PythonCard widget.
> 
>  
> 
> rlea
> 

Randy,

Welcome, and glad you like PythonCard. Kevin will probably give you a 
more specific answer to your questions but in the mean time ...

We haven't wrapped wxRightTextCtrl yet, but that shouldn't stop you 
using it in your application. All of the wxPython widgets, events and 
classes are available to you so you should be able to use them as you 
would from any wxPython program. Don't forget that PythonCard is 
(partly) a framework sitting above wxPython.

For an example of this (using the wxHtmlWindow widget) have a look at 
this message Kevin posted to the mailing list last year;

http://aspn.activestate.com/ASPN/Mail/Message/758404

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

No, it doesn't exist yet. I've been putting off the move to direct
subclasses of wxPython controls, but I'll go ahead and dig into it and see
what problems crop up. Assuming the switch isn't a total disaster, then
adding new components will be much simpler.

However, if you want to do it today for yourself you would probably need to
copy the textfield.py component (see the components directory) and then
substitute wxRightTextCtrl for wxTextCtrl and then change the names like
TextField to RightTextField or something like that, but I think almost
everything else would be the same.

You can give it a try and then let me know what troubles you run into, if
any. The Property Editor (debug.py) and resourceEditor.py would also have to
be modified if you want the component available when doing layouts, but I
don't recommend you delve into that code.

ka
  -----Original Message-----
  From: pyt...@li...
[mailto:pyt...@li...]On Behalf Of Randy Lea
  Sent: Tuesday, February 05, 2002 10:58 PM
  To: pyt...@li...
  Subject: [Pythoncard-users] wxRightTextCtrl


  I'm writing an RPN calculator app as a tool for learning PythonCard (which
is really cool, thanks ka!). For the result window, I think I need the
wxRightTextCtrl widget recently added in wxPython 2.3.2 to display right
justified text. I don't believe wxRightTextCtrl is available in PythonCard
yet, so if thats the case, will it be added soon? If not, maybe I can try to
create a PythonCard widget.

  rlea

I'm writing an RPN calculator app as a tool for learning PythonCard =
(which is really cool, thanks ka!). For the result window, I think I =
need the wxRightTextCtrl widget recently added in wxPython 2.3.2 to =
display right justified text. I don't believe wxRightTextCtrl is =
available in PythonCard yet, so if thats the case, will it be added =
soon? If not, maybe I can try to create a PythonCard widget.=20

rlea

Unfortunately, we have to wait a little to get wxPython running on 
MacOS 9 without needing a C compiler.

But I have been able to get RealPC, then Windows 98, then wxPython, 
then PythonCard running. I have a screen shot to prove it for those 
interrested.

Running on a G4 400, it is not the fastest ever, but it is usable.

At least, I'll will be able to bother you with localisation issues.

So, Andy, what did you think? I read some of the docs and plan to read more.
And it looks like my next project will be a Webware/Pythoncard hybrid, so
this is soon to be my top priority.

---
Patrick K. O'Brien
Orbtech

>
> Thanks Patrick, looks like you have just identified my weekend reading.
> Has anyone on the list got any experience with webware and/or get any
> comments?
>
> Regards,
> Andy
> --

> From: Simon
>
> Hello,
> Is it possible to embed an MPEG video complete with control buttons
> inside a PythonCard app?
> i would very much appreciate a reply.
> Thank you.
>
> from, Simon

There is no direct support for MPEG video in PythonCard or wxPython, which
PythonCard relies on. Under Windows you should be able to play MPEG video by
wrapping the Windows Media Player ActiveX control or another control that
handles MPEG such as the QuickTime or Real players. There are examples of
using ActiveX controls in the demo.py file that ships with wxPython.

Last fall I did some tests with mapping a PyGame surface to a native window
in PythonCard that sort of worked, but I haven't followed up on it since
then to know whether PyGame (which uses the SDL library) could be used for
reliable cross-platform MPEG playback in PythonCard; there is a good chance
it might work.

ka

Hello,
Is it possible to embed an MPEG video complete with control buttons
inside a PythonCard app?
i would very much appreciate a reply.
Thank you.

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

   Hi Kevin,

> Then I bring up Microsoft Paint which comes with Windows and paste that
into
> a new document and save in GIF format. When the image is converted to GIF,
> the colors are reduced to 256 (8-bit) and at that point any smooth color
> gradients get messed up.

   On Windows, I save screenshots as true colour BMPs from Paint and the use
bmp2png to convert to PNG format. This preserves gradiants and other images
and compresses reasonably well.
http://hp.vector.co.jp/authors/VA010446/b2p-home/index.html

   Neil

I just added a story to my blog about the stockprice sample.
  http://altis.manilasites.com/2002/02/03

While I was trying variations on making screen shots I finally realized why
the GIF images I make often look bad. I don't like to use JPEG for screen
shots since without a decent anti-aliasing algorithm such as you might find
in Photoshop or GIMP, the text in a JPEG screenshot generally gets fuzzy
with unsightly artifacts. A screen shot of a sample that uses a lot of
colors such as proof or hopalong has to be done as a JPEG.

Most of the time I run my system in True Color (32 bit). I use Alt+Print
Screen in order to capture a screen shot of the front most window or just
Print Screen to capture the whole screen including any open menu and cursor.
This is on Windows 2000. Other versions of Windows may be slightly
different.

Then I bring up Microsoft Paint which comes with Windows and paste that into
a new document and save in GIF format. When the image is converted to GIF,
the colors are reduced to 256 (8-bit) and at that point any smooth color
gradients get messed up.

Windows 2000 by default uses a color gradient for the Active and Inactive
Title Bars, but if you set Color and Color 2 in the dialog to the same color
then you'll no longer have a gradient and screen shots converted to GIF
won't look messed up.

I've attached a screen shot of the Display Properties dialog in Windows
showing where you set the Active Title Bar and Inactive Title Bar colors.

ka

I've spent a lot of time the last week working with XML-RPC, SOAP, and the
Blogger API which uses XML-RPC. I'll have more to say about blogger later.
This note is just to let you know that I checked in a very simple SOAP
client example for getting the stock price from a remote SOAP web service. I
read the O'Reilly article mentioned below and felt compelled to whip up a
simple clone.

I was going to include the SOAP.py module, but there are so many examples
and docs that come with the full distribution that is better if people just
download the file for themselves.

ka
---
from the readme.txt:
This sample is a clone of the AppleScript Studio example at:
  http://www.oreillynet.com/pub/a/mac/2002/02/01/applescript_macosx.html

It requires the SOAP.py module from SOAP.py 0.9.7 available at:
  http://sourceforge.net/projects/pywebsvcs

Also see the SOAP.py authors article at:
  http://www-106.ibm.com/developerworks/webservices/library/ws-pyth2/

XML pickle is another thing to keep in mind as we look at file storage
alternatives. David's articles (Charming Python, XML Matters, etc.) can be
found at
http://gnosis.cx/publish/tech_index.html

ka
-----Original Message-----
From: Dr. David Mertz [mailto:me...@gn...]
Sent: Saturday, February 02, 2002 9:58 AM
To: Kevin Altis
Subject: Re: more on xml pickle module


Hi Kevin,

There are several articles you might want to look at.  I recently
compared the object models of xml_pickle and XML-RPC, which might be
relevant to you:

    http://www-106.ibm.com/developerworks/library/x-matters15.html

The update on xml_pickle (through June 2001) is at:

    http://www-106.ibm.com/developerworks/library/x-matters11.html

And the original introduction was at:

    http://www-106.ibm.com/developerworks/library/xml-matters1/index.html

I give you all the IBM URLs because they are the "official" publication.
But the same articles (formatted slightly differently) should be at my
own site (I'm not sure if I got up the XML-RPC one yet).

There are actually a bunch of enhancements to xml_pickle underway right
now (by an interested user, with mostly just comments by me... but some
code clarification).  Those may or may not be interesting to you
(mxDateTime was added; we're looking at allowing classes to customize
how they (un)pickle themselves; SREs will be handled; and there will be
a fallback to "rawpickle" format for types the [pickle] module knows
about, but [xml_pickle] doesn't [not much, I hope]).

Yours, David...

--
 mertz@   _/_/_/_/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY:_/_/_/_/ v i
gnosis  _/_/                    Postmodern Enterprises         _/_/  s r
.cx    _/_/  MAKERS OF CHAOS....                              _/_/   i u
      _/_/_/_/_/ LOOK FOR IT IN A NEIGHBORHOOD NEAR YOU_/_/_/_/_/    g s

What this means is that we need to redesign the web pages to always include
the logo if we want to track page views. The HTML IMG tag for this would
look like:

<IMG src="http://sourceforge.net/sflogo.php?group_id=19015&type=1"
width="88" height="31" border="0" alt="SourceForge Logo">

I'll add this to the template and update the existing pages sometime next
week.

ka

-----Original Message-----
Sent: Friday, February 01, 2002 6:39 PM
Subject: [SourceForge] An Important Update for SourceForge.net Project
Administrators


You are receiving this email because you are listed as a project
administrator on SourceForge.net. We try to keep contact such as this to a
mimimum, but when we make changes to project administration, we are
duty-bound to inform you of new services and policies.

Beginning February 10, 2002, SourceForge.net will track hits to all project
websites (<your project>.sourceforge.net) by counting the number of times
the SourceForge.net logo is loaded in your pages. This accomplishes 2
things:

1. The process of tracking web site statistics is greatly simplified and
much easier when counting the number of times an image is loaded, as opposed
to parsing 30,000+ text logs.

2. More traffic is driven to SourceForge.net, which keeps our advertisers
happy. This also has the dual effect of giving more Open Source projects the
exposure that they deserve.

To get an idea of the different logos we offer, please visit the following
page: http://sourceforge.net/docman/display_doc.php?docid=790&group_id=1

Thanks,
John Mark Walker
SourceForge.net