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

[Rowland S. <sn0...@ea...>]

On Saturday, January 12, 2002, at 03:44 PM, David LeBlanc wrote:

>
>
>> -----Original Message-----
>> From: pyt...@li...
>> [mailto:pyt...@li...]On Behalf Of Kevin
>> Altis
>> Sent: Friday, January 11, 2002 19:33
>> To: pythoncard-Users
>> Subject: RE: [Pythoncard-users] six blind men describe the beast
>>
>>
>> David didn't think I answered him before, so prepare for a more 
>> exhaustive
>> attempt ;-)
>>
>> Some of the comments below are definitely in the realm of how things 
>> get
>> done in open source. If somebody provides an implementation for
>> an idea and
>> everyone likes both the idea and implementation or are interested
>> in working
>> on "fixing" the implementation it gets used, otherwise ideas can
>> fall by the
>> wayside. Ideas and wish lists without code to back them up are still 
>> good
>> for the list, but ultimately somebody has to code them to make
>> them real, so
>> you sometimes have to build consensus to get your idea in.
>>
>> My own philosophy is that I'm not interested in good ideas that can't
>> actually be built. Since most of the development effort right now 
>> falls on
>> my shoulders, I've been scaling back from what we said we wanted
>> to do back
>> in July. I'm lazy and pragmatic and take shortcuts whenever
>> possible to get
>> to a solution. I would rather refactor than get the design right the 
>> first
>> time because later on I know why I'm refactoring and that isn't 
>> generally
>> possible when you try and do good design up front.
>
> What ideas did I suggest that can't be built?

Anything can be built - it's just a matter of time.  Currently Kevin's 
doing most of the work, and one person can only take things so far.

I would like to see a fairly sophisticated app builder - but for that to 
happen more people, including myself, are going to have to jump in and 
help.

>
>> Apparently I have an attitude today (a verbose attitude to boot), so
>> beware...
>>
>>> From: David LeBlanc
>>>
>>>> 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?
>>
>> If someone is already familiar with one of the above solutions and is
>> willing to learn Python to take advantage of all the great things
>> it has to
>> offer, then PythonCard should help fill the void they would find
>> in the area
>> of building GUI apps.
>>
>>>> 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.
>>
>> I was just talking about supported platforms. wxWindows supports all 
>> the
>> different Windows OSes, so as long as we use wxPython we get a free 
>> ride.
>
> I was just saying that, in supporting windows, prefer later versions. If
> something is supported in NT/2K/XP but not 9X/ME then don't let that 
> stop
> the feature being used.
>
>>>> uses wxPython as the cross-platform GUI toolkit
>>>>     simplifies writing wxPython programs
>>>
>>> Will PythonCard further simplify creating GUI's?
>>
>> Yes. It already does, or at least it seems that way to me compared to 
>> the
>> alternatives available for Python. Vigorous debate on this topic would 
>> be
>> good if someone thinks using wxPython, PyQT, tkinter, etc. is actually
>> simpler either with or without one of the free/commercial IDE
>> solutions for
>> each GUI toolkit. In particular I would like to hear about where
>> tkinter is
>> a superior solution given the current prototype; other than the
>> old argument
>> "tkinter ships with Python" that is.
>
> I suspect tkinter is somewhat easier for people to use then WxWindows 
> "out
> of the box". That's not meant to be a defense of tkinter though :>

I don't have any experience with tkinter, other than using a few apps 
writtin with it, and for the most part they are pretty lame - the 
limiting factor seems to be tkinter itself, but like I said, i don't 
have enough experience with it to really know.

One of the things that we're trying to get to is at least the first rev 
of a component model that will allow us and others to build some more 
value added components out of the wxPython widgets.  If the model is 
easy to understand and use, then we'll get a body of components that 
make it easier to build a non-trivial app in a short amount of time.

Personally, I think my ideas on a component model are overly 
complicated, I'm currently trying to figure out what is the very minimum 
needed to build and use real-world components.

>
>> My own tkinter sucks bias started with the non-native widget issue and 
>> TCL
>> reliance. The native widget problem is apparently solved with
>> version 8 and
>> above. But now it comes down to tkinter just feels wrong and I
>> haven't seen
>> many tkinter/Python apps out there. Most of the book material on 
>> tkinter
>> I've looked at falls into the "toy" apps category. You spend a lot of 
>> time
>> learning how to get even something simple up on the screen and
>> then when you
>> want to leverage your hard won knowledge to do something useful a 
>> solution
>> like tkinter runs out of steam.
>
> I'm a former user (and still lover) of Tcl/Tk since it was barely 
> usable on
> Windows.
>
>> But I would love to hear pro tkinter opinions, what's good about it, 
>> good
>> for beginners and pros, etc. If PythonCard isn't a better solution than
>> tkinter then we've probably failed.
>
> Not suggesting that one is better then the other. I wonder if the 
> PythonCard
> abstraction couldn't encompass both (and Fox/FLTK too)?
>
>>>> does not preclude the creation of OS-specific applications
>>>
>>> Sounds like an extension API would be desirable.
>>
>> It would be nice to have obvious naming conventions for 
>> platform-specific
>> constants, classes, and methods in wxWindows/wxPython, but those
>> don't exist
>> in wxPython so you just have to pay attention to where the docs say 
>> "Win32
>> only" or "GTK only" and do appropriate checks in your code. I
>> have checks in
>> the addresses sample to have it do the right thing depending on what
>> platform it is running on and whether Outlook is installed on the users
>> machine. The graphic.py module has similar checks for whether
>> Python Imaging
>> Library (PIL) is available.
>
> Not my point at all. PythonCard _tool_ should have a standard API to the
> extent possible (without rewriting core components like WxPython etc.).
>
>> A long time ago I suggested we might want to have an automatic check 
>> for
>> common components which would go into a dictionary or class so that all
>> PythonCard apps would check for OS platform, availability of PIL,
>> etc. in a
>> standard way. However, we won't be able to cover everything and
>> people will
>> always end up having to use their own try/except blocks and
>> asserts to check
>> for features that might not always be available.
>>
>> If I wanted to write a really slick Windows app and don't care about it
>> running on Linux and the Mac I definitely am going to use COM
>> components, so
>> I just need some appropriate startup checks specific to my app.
>>
>>>> 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
>>
>> I've never seen that in HyperCard. Maybe the most recent
>> SuperCard does it,
>> but it has been a long time since I've used it.
>
> SuperCard offers something called "FlameThrower" (sheesh, marketing 
> guys are
> clueless <g>) and latest at www.apple.com/hypercard also advertizes 
> such a
> feature in the latest rev of HC.
>
>>> Office that
>>> supports Word, XL and PowerPoint exports to HTML (better XML for
>>> us IMO). As
>>
>> These are document exports, not apps. Neil already has the .hta
>> examples in
>> the PythonCardPrototype directory as an example layout reuse. I can't
>> imagine anyone doing real web layout wanting to design something in
>> PythonCard and then export to HTML using our standard tools. The HTML 
>> in a
>> web browser paradigm is generally quite different from a normal
>> desktop app
>> layout. I'm not ruling it out, I just don't see an obvious path to 
>> pursue.
>
> I keep getting mislead by the "card" in PythonCard. HyperCard is 
> primarily a
> means of creating (possibly interactive) documents imo. Stacks get read 
> more
> then written or added to (depending on the application of course).
>
>> Exporting the document format as HTML/XML... that a particular 
>> PythonCard
>> app uses obviously makes sense, but that is a design decision for
>> the person
>> building the app. Cliff made a post about his CSV module which
>> seems like a
>> useful addition and isn't available as part of the Python Standard
>> Libraries.
>
> PythonCard keeps sounding like a generic GUI builder - and given 
> antipathy
> towards automatic code generation, only that.

I think gui builder with app framework is closer.

>
>> Regardless, there is a very low chance of us producing something
>> that would
>> generate the HTML and JavaScript for an active web page.
>
> I didn't mention Javascript.
>
>>> 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".
>>
>> See JavaScript comment above. Dumb HTML/XML data export, maybe.
>> Smart forms
>> with script, highly unlikely. If somebody wants to pursue this as
>> an app and
>> is successful we can roll it into our design. I think this goes
>> back to the
>> Dave Winer posts which hinted at the Radio Userland 8 approach to 
>> layout,
>> but I haven't looked at Radio 8 yet, so I can't comment further.
>> This topic
>> should get its own discussion thread.
>
> I still never mentioned Javascript. An example of what I had in mind is
> creating an HTML form that gathers data and returns it to a python app 
> that
> might be it's own webserver. NOT at the level of sophistication of Zope 
> or
> whatever, merely a simple way to create a browser visible GUI.
>
>> I will say that I do not want to intrude directly into the domain of
>> solutions provided by WebWare, Zope, and other web-centric Python
>> projects.
>> There are more than enough projects and people working in that space
>> already. What would we add?
>
> See above.
>
>>>> 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.
>>
>> Actually, they have to follow the convention or they can't program with
>> PythonCard. All components in PythonCard have a unique name
>> within its scope
>> which acts as its id. Numeric ids are only used internally and hidden 
>> from
>> user code. So, btn1 was just a name, it could have been
>> "aReallyCoolFeature'
>> to give us
>>   on_aReallyCoolFeature_mouseClick
>>
>> I have been using the abbreviations like 'btn' and 'fld' in most
>> of my code
>> to make the type of a component obvious. This follows the recommended 
>> VB
>> naming conventions. In some cases I used 'button' and 'field'.
>>
>> The enforced convention is that of using 'on' to start an event
>> handler name
>> and underscores to separate the component name. The naming can still be
>> changed, but I want to hear a good reason for doing so. The current way
>> makes the handlers easy to parse, easy for coders to read and write, 
>> and
>> doesn't seem clumsy, at least to me.
>
> I looked at the PC codebase, and can't find any place where handlers are
> parsed...
> I did notice that "OnEvent" (where Event could be any word(s)) and
> "on_event" where both used.
>
>>>> make it simple to change and reuse parts of PythonCard apps
>>>
>>> More API-ness. Packages.
>>
>> I was thinking of plain modules and resource files or pieces of both. 
>> What
>> are you suggesting?
>
> Component object model? Standard entry points for modules?
>
>>>> 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.
>>
>> I don't know what you mean by dynamic layout? A full IDE could
>> certainly do
>> what you're talking about, I'm assuming that what you object to is 
>> that a
>> layout editor doesn't know about the source code. I am not in
>> favor of code
>> generators myself, but method stubs are okay.
>
> Different definitions of "dynamic" used here. I can think of several
> definitions. You're using the definition of code creating the interface 
> as
> opposed to something like a resource file (a la' windows) which is a 
> static
> layout. My definition was about layouts that dynamically adjust 
> themselves
> depending on host constraints (640x480 vs. 1024x768 for example) or 
> resizing
> done by the user. AKA "sizers" in WxWindows parlance. I think this 
> should be
> a fundamental attribute of the foundation panel/canvass/window/whatever 
> that
> users base their design on.

Sizers are something that we've discussed as being necessary for 
PythonCard to succeed.  The trick is figuring out how to 1) specify 
sizers/constraints in a gui builder and 2) how to capture the 
sizers/constraints in a resource file.

>
>>>> 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?
>>
>> The automatic event bindings, resource files, a buffered bitmap
>> canvas, dot
>> notation attributes to name a few. Coming up with a decent list
>> was part of
>> the reason for the "marketing caps" post I made earlier. In some ways 
>> I'm
>> too close to the framework to describe it well.
>
> It's hard to know what PythonCard is absent any document describing it's
> overall design philosphy and vision. It's got widgets, events, 
> attributes
> and resource files: so do WxPython, WxWindows (duh), MFC, and for all I
> know, Gnome and KDE.

We're certainly shooting for a framework that is at a higher level of 
abstraction than wxPython and that adds application development features 
that sit on top of wxPython.

>
>>>> should be a complete replacement of tkinter for those wanting
>>>>     to program GUIs with Python
>>>
>>> This is distinct from WxPython how?
>>
>> You can think of PythonCard as a simpler way to use wxPython if you 
>> like.
>> Whether it is or not is debatable. I have yet to meet anyone though 
>> that
>> could use wxPython and be productive quickly after first being
>> introduced to
>> it. We are reaching a decent usability level with PythonCard, but
>> we have a
>> long ways to go.
>
> I wouldn't mind seeing PythonCard as a simpler way to use WxPython, but
> after looking at some PC code and some WxP code (in their demo), I 
> don't see
> a significant difference in the complexity of the code.
> What am I missing?
>
>>>> 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?
>>
>> No idea, maybe. Good task for someone to work on other that me.
>> Someone also
>> needs to make an equivalent installer script for Gordon
>> McMillan's installer
>> that works on Linux, Windows, and possibly other platforms. We only 
>> have
>> py2exe installer scripts now and they just generate an EXE for Windows.
>>
>>>> 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).
>>
>> SOAP doesn't cut it and neither does XML-RPC. They aren't
>> component models.
>> CORBA is but it is too complex. Anyway, components are the direction 
>> we've
>> started to head and they will be a clear benefit over other Python GUI
>> solutions if we manage to make them real. If we stumble we'll
>> back off, but
>> otherwise they are going to happen.
>
> You might not see SOAP as a component model, but that doesn't stop it's
> being (at least usable as) one. Can you name one component model that 
> isn't
> complex to some extent (possibly Java Beans)? What is your notion of a
> component model?
To me, SOAP is a a communication protocol.  From what I've read, SOAP 
combined with WSDL ( service description ) is something of a distributed 
component model.

IMHO, what we're looking for with PythonCard is a component model closer 
to the JavaBeans model.  JavaBeans is pretty simple until you get into 
the serialization of live beans and complex bean editors, both of which 
we need some level of in PythonCard.

>
>>>> does not force the use of Model View Controller (MVC) on user code
>>>
>>> Does WxWindows use that paradigm?
>>
>> No.
>>
>>>> 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".
>>
>> I made the comment above because the low-level stuff to make it happen
>> simply doesn't exist cross-platform and we aren't going to be able to
>> provide it. We can wrap it when it is available. I just don't want 
>> people
>> thinking this is a full multimedia tool or the equivalent of Flash. 
>> Yes we
>> can do good stuff using ActiveX under Windows but Linux would be out of
>> luck.
>
> At this point you're talking about platform independence, yet earlier 
> you
> said you wanted to be able to use COM on Windows if you wanted to.
>
>>>> 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.
>>
>> Neil can comment on the time, effort, and difficulty of writing a good
>> editor. It won't be a walk in the park, but yet that is what we'll most
>> likely use when the editor in the IDE effort starts or if we do some
>> experiments with runtime editing of scripts which is possible
>> within limits.
>>
>> As a notepad clone, the textEditor sample (not in the same league as a
>> source code editor) took me less than 45 minutes to write
>> http://aspn.activestate.com/ASPN/Mail/Message/805090
>> at least for the first version. I wasted a lot more time on the
>> New/Open/Save/Save As logic, but overall I've got less of a day into 
>> it,
>> mostly because it doesn't do much.
>>
>>> **********************************************************
>>> 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.
>>
>> This is certainly doable, in a way that is what the minimal sample is. 
>> The
>> resourceEditor already using a template.rsrc.py file as its
>> default and you
>> can change it to suit your most common defaults to save time when
>> building a
>> new layout.
>>
>>> SWIG: Relatively effortlessly slurp up "foreign" libraries.
>>
>> Do you have examples of why we would need direct support of this in
>> PythonCard?
>
> I guess that would all depend on what PythonCard is meant to be. See 
> below.
>
>>> 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.)
>>
>> Why? What is the particular benefit you expect to gain from using
>> XML or any
>> other Xthingy? I'm not saying it is bad, but we've had this 
>> conversation
>> before on the list and I know what XML will be good for, but I also 
>> know
>> where it is extremely bad or at least less useful than some other
>> solutions.
>> XML is not magic. My standard position is that XML should never be 
>> seen by
>> human eyes except for debugging purposes. It should be
>> program-generated and
>> program-consumed and if you have humans typing it you have a lame
>> solution.
>> On a related note, it is interesting that the wxWindows XML
>> resource format
>> does not have a DTD, because nobody has been able to figure out how to
>> express all the possibilities. XML without a DTD has very limited
>> usefulness
>> outside of the people/programs that agree to share the free form set of
>> fields.
>
> Well, for starters, XML would be a better representation for resource 
> files
> then what's currently in PythonCard. XML without DTD's are widely and
> successfully used. I don't recall suggesting that XML be typed by 
> humans.
> However, it's easier to read xml then (for example) CSV if you have to 
> read
> it at all. If I had to create a resource file by hand for some reason, 
> i'd
> FAR prefer to do it in XML then in PC resource format.

The Python dictionary format is quite powerful for describing resource 
files, and has the added value of being easily parsed from a textual 
representation.

XML is certainly more verbose than dictionary syntax, but personally I'm 
still not convinced it's easier to read or understand.  Using the native 
dictionary format doesn't exclude the use of XML - someone could define 
an XML resource format and a translator that parses the XML and produces 
a PythonCard resource description, or vice-versa.

>
>>> How is this different from Boa?
>>
>> Boa is modeled on Delphi and has a whole lot of other stuff thrown in 
>> like
>> Zope support. While it seems impressive, I also find it slow to
>> start, hard
>> to figure out how to use, it seems to lack focus, it is a code
>> generator - I
>> have never found a code generator that didn't cause me problems
>> in the long
>> run - and overall it just seems bloated and too difficult to use
>> especially
>> for a beginner. Every time I give it another chance I go away
>> disappointed,
>> perhaps I'm just missing something, I really wanted to like it the 
>> first
>> time I used it. Riaan has put a huge amount of effort into it, but
>> unfortunately it is a one man project. If someone knows wxPython and is
>> comfortable with it and likes Boa, there is no particular reason they
>> shouldn't just continue to use Boa. Choice is good.
>
> I agree that BOA is pretty opaque and i've yet to use it successfully -
> alas. You didn't point out what i've finally realized - that PythonCard
> isn't intended as a project to create a development tool, but rather a
> framework.
>
>> Now, PythonCard is...well, time will tell. Maybe it will only appeal 
>> to me
>> and a few other people, but that's okay. I know wxPython pretty
>> well and I'm
>> still amazed that I have a hard time writing a wxPython program
>> from scratch
>> and I certainly can't do many of the PythonCard samples using raw
>> wxPython,
>> there is just too much to remember.
>>
>> ka
>>
>
> Having realized that this is a project to create a framework and not a
> development tool, it seems to me to be, at this point, WxPython-Lite. 
> What
> am I missing? That's not intended as a criticism or condemnation, only a
> comment.
>

I think wxPython-Plus would be more descriptive.

Talk to ya,
Rowland


> Regards,
>
> Dave LeBlanc
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>