Re: [Pythoncard-users] six blind men describe the beast

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

David LeBlanc wrote:

> Well hmmmm... I just went and looked at the PythonCard homepage again and
> still couldn't find an exposition anything like this one. Comments and
> questions below.
> 
> 
>>For inspiration...
>>  http://www.wordfocus.com/word-act-blindmen.html
>>
>>It has been a while since we had the "what is it?" discussion. I
>>didn't list
>>everything and some people will/should object to some of the statements
>>below, so go ahead and throw in your two cents (or possibly a hong kong
>>dollars worth). Maybe we'll put the results up on the web site and keep it
>>up-to-date as the project progresses so our goals are clear.
>>
>>ka
>>---
>>
>>built with Python
>>
>>uses Python for the scripting language
>>
>>suitable for people just learning Python
>>
> 
> I think the above 3 points constrains the likely user domain to programmers
> more then John and Jane Q. Public. Not a criticism, just a point - but is
> that the desired target audience? HyperCard (HC here after) gave the the
> average "toaster" user the ability to drag objects into a pleasing (to them)
> arrangement and viola! they had something usable...


A sophisticated visual development environment is a must for non 
programmers.


> 
>>the primary focus is on small and simple
>>    GUI programs written by one person or at most a few people,
>>    not a team working on a large six-month or multi-year project.
>>
>>if simple programs are not simple to create and maintain we've failed.
>>
> 
> I think that at a certain level, if anyone has to actually write code to get
> the simplest application, that's a miss.
> 


This comes back to the Visual Development Environment ( VDE ) - We 
really need to start spec'ing it out from a requirements standpoint.


>>simple yet powerful enough for people familiar with HyperCard,
>>    Visual Basic, SuperCard, Revolution, and other assorted
>>    HyperCard "clones"
>>    PythonCard should be a viable alternative to proprietary
>>    languages and application builders.
>>
> 
> How does this conform to the idea of using Python as the scripting language?
> 
Leveraging Python as the scripting language is a must.  It's pretty easy to learn and is

much more powerful than anything we could create on our own with limited 
resources.

 
>>is cross-platform supporting at least the major OS platforms:
>>    Windows (95/98 and above), Linux (GTK), Mac (at least OS X)
>>
> 
> IMO, prefer NT/2000/XP over any of the Windows 9X/ME ilk.
> 
> 
>>uses wxPython as the cross-platform GUI toolkit
>>    simplifies writing wxPython programs
>>


We're really only limited by the platforms that Python AND wxPython 
support, right?


> Will PythonCard further simplify creating GUI's?
> 
> 
>>does not preclude the creation of OS-specific applications
>>
> 
> Sounds like an extension API would be desireable.
> 
> 
>>is not designed to run inside a web browser
>>
> 
> While not designed to _run_ inside a web browser, I think it ought to be
> able to produce content to be _viewed_ in a web browser. Both HyperCard and
> SuperCard offer this ability to my knowledge, not to mention MS Office that
> supports Word, XL and PowerPoint exports to HTML (better XML for us IMO). As
> I think about it, an ability to produce a form that would run both in an app
> window and a browser window wouldn't be a bad thing either - and XRCed might
> offer a foundation for that? Don't constrain tool abilities by this option -
> some designs can't be exported as "presentation XML".
> 


I don't think this should really be a goal of the PythonCard development 
team.  It's way too much work for the few people that are actively 
developing PythonCard itself.  However, this would be a great side 
project for others after PythonCard becomes stable.


> 
>>establishes naming and coding conventions to make programming
>>    GUI applications more pythonic, easier to read and write
>>    for example, the handler names such as on_btn1_mouseClick
>>
> 
> "OnButtonClick Button1" worketh too IMO :-). Since Python still adheres to
> parens for arguments (alas!), "OnButtonClick(Button1)" worketh ok enough.
> Contractions like Btn1 are nice for programmer or more experienced folk and
> should be provided, but I think they're confusing to newbies. Rather then
> creating naming and coding conventions (newbies aren't going to follow those
> anyway), Hide as many implementation details as possible behind more
> common-man idioms. Favor language independence to the extent possible.
> 


Hopefully we can produce a development environment that allows 
non-programmers to build simple apps without seeing actual code.  This 
is a big task but would go a long way to getting PythonCard accepted by 
a larger audience.


>>make it simple to change and reuse parts of PythonCard apps
>>
> 
> More API-ness. Packages.
> 
> 
>>separate resources/layouts from source, but also support
>>    defining layouts in code for dynamic layouts
>>
> 
> Hammer and Tongs. Any pressing reason why dynamic layouts couldn't be done
> via a GUI design tool? I think the efficacy of a 3-tiered design model is
> well established: Presentation, Logic, Storage. The more you mix them, the
> less flexible and (often) more convoluted your design becomes. OTOH, the
> development model could just as well be quite different: I sure don't want
> to have to go somewhere else in the design tool to enter attribute values or
> event handlers for a GUI object I just added to my presentation layer.
> 


We need to look at some sophisticated VDE's, HyperCard, etc, and get 
some ideas on what kind of VDE we would like to build for PythonCard.


>>provides built-in classes, methods, and functions for tasks
>>    common to GUI applications that is not provided in the
>>    Python Standard Libraries, wxPython, or a common Python
>>    library such as Python Imaging Library (PIL) or NumPy
>>
> 
> Examples?
> 
> 
>>should be a complete replacement of tkinter for those wanting
>>    to program GUIs with Python
>>
> 
> This is distinct from WxPython how?
> 
> 
>>open source
>>
>>uses the Python license or a rough equivalent, not GPL, so there
>>    is the possibility of commercial applications, components, etc.
>>
> 
> Good.
> 
> 
>>supports simple builds of standalone executables using py2exe
>>    and/or Gordon McMillan's installer
>>
> 
> I wonder if it's possible to reduce this to  a menu item: "Create Installer"
> with the option to "go manual" if needed for more complex apps?
> 
> 
>>component architecture to support more than just wxPython controls
>>    including compound components. PythonCard components are
>>    roughly analogous to COM and JavaBeans
>>
> 
> <Cough> I suggest putting this in the development context in the form of
> "leave room for this idea" - this is probably a fairly substantial task in
> it's own right, and probably has an impact on WxPython and possibly even
> WxWindows itself. Also, keep CORBA in mind as the component model - or
> SOAP!! (I'm in favor of SOAP myself).


I believe that we're heading toward a Python specific component model 
that leverages the power of the language/runtime as much as possible. 
Once that component model is in place, we can create adapters to other 
component models.


> 
>>does not force the use of Model View Controller (MVC) on user code
>>
> 
> Does WxWindows use that paradigm?
> 


Model-View-Controller is being used internally in the PythonCard 
framework, but we probably won't force it on users - although it would 
be good if we could facilitate the use of MVC by end users.


>>the cross-platform aspect means that it won't have the same
>>    capabilities as an OS-specific app/framework that can take
>>    advantage of platform-specific code. in particular, there
>>    is no support for QuickTime, Real, Windows Media Format, MPEG,
>>    MP3s, etc. in some cases, you can do platform-specific apps
>>    using these technologies. you are not going to be able to do
>>    all the things you could do say with Flash, at least not in the
>>    near future.
>>
> 
> Hmmm... here is how I can see merging the idea of Component Objects,
> platform independence and taking advantage of platform specific formats: I
> don't think anyone would argue that having a "Movie" objec would be nice;
> just let it have an attribute "media" specifying the format (from a list of
> available formats controlled by a project attribute "Platform" which would
> have as one choice "independent".
> 
> 
>>as wxWindows/wxPython improves, so will the capabilities of
>>   PythonCard
>>
> 
> Ditto for Python one would assume. Actually, I suggest using Python 2.2 as
> the initial target - the unification of the class hierarchy is just too good
> to pass up. (Frankly, I think this was a big enough change in the language
> to warrant a full bump to 3.0, but so far Guido hasn't sought my counsel ;).
> One wonders what's in store for Python 3.0.)
> 


I'm not familiar with this change  -Kevin?


>>support editing programs in standard editors (vi, vim, emacs,
>>   PythonWin, IDLE, etc.) and not be forced to edit in and IDE
>>
> 
> As a option for sure ("For Editing use: {Built-in, Vim, Vi, Emacs, Idle,
> Scite}"), but having a built-in editor based on Scintilla is pretty much a
> (WxWindows supported) no-brainer IMO.
> 
> **********************************************************
> A few thoughts of my own in no particular order...
> 
> Templates: basis for "standard" apps. Conceptually similar to the Visual C++
> Dev Studio project types, but possibly more sophisticated (how hard could
> that be? <g>). Creates the coceptual framework for reusable components.
> 
> SWIG: Relatively effortlessly slurp up "foreign" libraries.
> 
> The XML family of protocols - whereever and however they might be useful. A
> strongly influencing design bias should be: "can this be expressed in X*L?"
> (where X*L is XML, XSLT, XSchema, XPointer, XLink etc.)
> 
> How is this different from Boa?
> 
> Dave LeBlanc
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 



-- 
Talk to ya,
Rowland

---------------------------
Truth: Accept No Substitute
---------------------------