Re: [Pythoncard-users] Kevin's PythonCard goals

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

Kevin Altis wrote:

> In no particular order and with as much rambling as I can muster ;-), here
> are some of my goals for what we're currently calling PythonCard. I'll
> expand on some of these issues in other emails. Comment please.
> 
> A GUI application framework written in Python and using Python as the
> scripting language for building apps.
> Among other things this means that in HyperCard terms we aren't creating a
> HyperTalk (xTalk) language clone. For a Python user it means that to
> effectively use PythonCard they will need some familiarity with object
> oriented programming. They will need to understand classes, objects,
> methods, functions and the differences between them, at least in terms of
> Python. The good news is that object oriented programming doesn't get much
> easier than it does in Python. It lacks the discipline of strongly typed
> languages so you can really create a mess if you want or accidentally, but
> the power is there, so you just have to be pythonic and go with the flow.
> 
> Ability to leverage existing Python libraries with a minimal of fuss
> This includes being able to put simple GUI front-ends on command-line tools
> and interfacing to well understood Python libraries like NumPy and PIL, etc.
> 
> Simple apps should be simple and easy to build
> I'm willing to give up some flexibility and power if it makes smaller apps
> dramatically easier to build and maintain. I've stated this before, but
> almost every sample application was done in anywhere from less than an hour
> to an afternoon of work and a lot of that time was often spent on layout.
> Later modifications were simple incremental additions, not rewrites. The
> current framework is not a traditional Rapid Application Development (RAD)
> tool, but because of the power and simplicity of Python it has enabled me to
> make some useful stuff with very little planning. When I look at books that
> spend hundreds of pages doing nothing but toy apps in tkinter it makes me
> sad.
> 
> Cross-platform
> I still think a cross-platform solution is the right thing to do, though it
> puts some pretty severe limitations on exploiting the richness of the
> underlying OS. I'm specifically talking about the major desktop OS
> platforms: Windows (98/ME/NT/2K/XP), Windows 3.1 and 95 are not worth
> supporting IMHO, Mac (Classic/OS X), and Linux. I'll add Solaris in there
> since wxPython already supports it. I'm also going on the assumption that
> there will be a Mac wxPython port soon and that we won't have to wait until
> next year. The wxMac port of wxWindows is getting a lot of attention right
> now on wx-dev.


> 
> wxPython
> More on this in another message. The short story is that I still don't know
> of any other cross-platform solution for Python that is as capable. If you
> want to make the argument for supporting tkinter, do so now. If I'm missing
> a different solution, please speak up as well. I'm not including Jython
> since I consider that a completely different type of solution space.
> 

Being a Java guy, and having seen how rich Swing is, I'm not so sure 
that wouldn't be a good solution for cross platform gui.  The standard 
Swing class library is pretty rich, and there are tons of Swing 
components out there.  Of course this would require knowing both Swing 
and Java to develop, and would require both Python and a Java Runtime 
Environment, so installation would be freakin' HUGE.

Doesn't it seem strange that people regularly install 50MB of runtime 
for a 20K app ;)


> Its the apps stupid
> I'm not really that interested in building a better mousetrap, aka the
> framework. My interest is really in having a great way of building apps in
> Python. Consequently, I would like to have something usable yesterday, not a
> year or two from now. When we started I promised that what we built along
> the way would be usable on its own even though it was just a prototype and I
> think that goal has been met. Any future work should be focused on results
> with incremental improvements. I'm probably not willing to spend a month or
> two designing a framework spec before starting to implement it, I'm just not
> a good designer, I like to take too many shortcuts.


I agree.  I'm backing off on the whole 'grand illusion/delusion' idea 
and want to work on someting more pragmatic.  We still need a well 
defined object model, but that's mostly just clarifying what we already 
have and making some refinements.


> Multimedia support
> This is a tough one because of the cross-platform issue. We can't use COM,
> do QuickTime, or play back MPEG and MP3s in a standard way. We can play WAV
> sounds files. The SDL library, which PyGame uses can play back some MPEGs
> and MP3s and I have had some discussions and done a few tests with Pete
> Shinners, the PyGame author, about how we might add those capabilities, but
> there is still a lot of work to do.


Man, I'm so tired of having to boot up my iMac to watch porn!  Just 
kidding ( really ;), why in the hell isn't QuickTime available on Linux 
yet?  Maybe with OSX being based on BSD there will be some movement in 
that area.


> Richedit control
> Like multimedia this is another toughie due to cross-platform issues. It
> turns out that under Windows, wxWindows/wxPython uses a control limited to
> 32K of text for wxTextCtrl. In order to get a 2GB text limit and styled text
> in the same control you have to specify the wxTE_RICH and wxTE_MULTILINE
> styles. However, under Linux the richedit control was coded specifically for
> wxGTK and does not use a native control or have all the features of the
> richedit DLL under Windows, so the wxWindows rich text API is extremely
> limited. Typically, people are directed towards Neil's Scintilla in its
> wrapped form if they want more control, but Scintilla, while nice for doing
> a text editor is not nice for simply mixing styled text in the same control.
> I have no idea what the wxMac situation will be. What I do know is that an
> additional layer of logic is going to be needed to make styled text simple
> and easy to use in wxPython. For speed reasons, whatever Python logic is
> added to make the rich text control more useful will probably have to be
> moved back to C++ at some point. Neil or Robin, please correct me on any
> mistakes above.
> 
> Separate GUI descriptions and layout from source code
> Mixing code and layout is not good. "Bad monkey, no banana!"


Righty ho :)


> Graphical layout tools for widgets, menus, etc.
> 
> Runtime shell for interactive programming and output
> 
> Interactive editing while the app is running with reloads if possible,
> otherwise a simple edit/run cycle.
> 
> Message Watcher
> For those of you that never used HyperCard this may seem dumb. I also know
> people that used HyperCard that never saw the point in the Message Watcher.
> Think of it as just another debugging tool. As soon as I had the first
> message watcher working in PythonCard I identified two event bugs in
> wxWindows/wxPython. Who knows how long those have been around? It is also a
> nice learning tool to see what is going on with events.
> 
> Native controls/widgets, so that apps look like native apps under each OS.


I would totally give this up for a rich gui toolkit like Swing.


> Helper classes in the framework
> Find, transparent storage of data and metadata. These classes should
> complement what is available in the underlying GUI toolkit, but not reinvent
> something that is available via the Python Standard Libraries or a common
> library such as NumPy.


Leveraging existing libraries is definitely a good thing, like Andy and 
Patrick are doing with Zope.


> 
> Direct manipulation instead of Model View Controller?!
> This is a separate thread. I don't mind MVC in the framework, but I am wary
> of exposing it such that user code has to do MVC. While powerful and quite
> standard these days, I still think that it is conceptually difficult to
> grasp and can make simple projects difficult because of extra planning
> required to do MVC right, but I'm an MVC newbie so what do I know? This
> really deserves its own thread. I'll get back to this later today or
> tomorrow.


There should be some kind of compromise here that will promote good 
software design without requiring a user to be some kind of OO god just 
to get a simple app up and running.  Thinking...


> Desktop apps are my focus
> However, if we can do something that will allow more integration with web
> solutions then that would be nice, but not at the expense of turning the
> framework/environment into yet another web applications template tool, etc.
> Python is not a full citizen in the browsers of today, so there is no point
> in pursuing that area. The one thing we should seriously consider, which
> Neil has brought up before is modeling our framework on the DOM, so that it
> would be simpler to share layouts and program flow. Who knows, maybe someone
> would even get inspired to write a Python to/from JavaScript translator if
> the document/application models were compatible.


As for me, I'm not interested in supporting browsers either.


> A component architecture
> At one point I thought we might be able to do this with XPCOM. Unless I'm
> missing something, XPCOM and PyXPCOM are comatose. I posted recently on the
> XML-RPC list about XML-RPC for local app to app communication and got a very
> disappointing response. The Mac has AppleEvents and Windows has COM and COM
> works extremely well and has been very successful. However, it is too hard
> of a problem for even a small developer group to tackle, so I'm not gonna
> waste much more time worrying about a cross-platform solution.


Something simple and elegant should do the trick.  We sure as hell can't 
reinvent COM/CORBA/XPCOM,etc.


> HyperCard as inspiration, not gospel
> I've used a lot of IDEs and just about every major OS available since 1979
> or so. For me, HyperCard was the environment that was the most pleasurable
> to program in and use to build stuff. Ultimately, its limitations killed it,
> but it was fun and if "you got it" then you could be extremely productive
> with it. I think that the combination of a scripting language and a simple
> environment were the reasons it worked well. If you wanted to build
> something beyond its capabilities then it could be trying, for one you can
> to resort to external commands and functions. I still like the name
> PythonCard, but another name might be more appropriate.


Losing the HyperCard aggage without losing the spirit might be good. 
Maybe we could leverage the concepts but not the metaphors ( Stack, 
Card, Background ).


> 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