Standard GUI abstraction for Python
James C. Ahlstrom
that other people are working on this, and I am posting this to see who
you are (please reply) and to relate what I found out so far. To keep the
length down I plan to followup later this week. I would appreciate any
criticism you may have.
The idea is that it should be possible to write the GUI part of a program
in Python, and have it run unchanged on several different GUIs using the
native Look and Feel. We could then look forward to complicated Python
programs which would run unchanged on Unix/Motif, Unix/Tk, MS Windows and
OS/2. Python is ideal for GUI work because it is a pure object-oriented
language.
Python would need to provide an interface which supports a rich set of
features available on today's GUIs in a way which could be easily ported
to all of them. Since each GUI has its own view of the world, this is not
easy. The way to do it is to read the Win32, Tk, XVT, SOM, Mac, and
Motif manuals in detail. Then think of what they do and express it in
Python in a natural and object-oriented way.
So, as an exercise, I wrote a short program which displays a resizable di-
alog box with two buttons. I designed the Python code to be compatible
with the systems I am familiar with, namely MS Windows, XTV (XVT Software,
Boulder, CO), and Tk. Regrettably, I know little about the Mac. I have
an actual implementation in Tk using tkinter (not Tkinter.py).
Despite the simplicity of the example, I found many problems. Once I port
it to XVT and WinNT I may find more. Here is the program:
----snip----
# This program will run unchanged on any system which has a "wpy.py".
import wpy # Standard module name on all platforms, but contents
# varies for Motif, Tk, MSW, OS2, etc.
app = wpy.App() # Represents the whole application. Not visible.
dialog = wpy.Dialog("Usual Hello World Demo") # A top-level window.
button1 = wpy.Button(dialog, "OK") # Two buttons. Look and feel
button2 = wpy.Button(dialog, "Quit") # will be different for
# different platforms and
# Make the button widths the same. # implementations.
button1.sizeX = max(button1.sizeX, button2.sizeX) # Buttons come with a size.
button2.sizeX = button1.sizeX
# Place buttons on 1/3 centers near bottom of dialog. The model allows
# an absolute pixel size/position, and a size/position relative to any
# rectangular object, default: the parent. Similar to Tk "placer".
button1.anchor = button2.anchor = "center"
button1.locY = button2.locY = 0.70
button1.locX = 0.3333
button2.locX = 0.6667
# Make function to be called when button is pressed. This button resizes
# the dialog to demonstrate re-size events. Dialog has re-size decoration,
# so user may resize dialog him/herself, and the layout will adjust.
dialog.sizeY = 0.4 # Parent of dialog is app with size of screen.
def OkFunc(self, event): # Standard form of event handler.
if dialog.sizeX == 0.4: # Just toggle between two sizes.
dialog.sizeX = 0.6
else:
dialog.sizeX = 0.4
dialog.SendSizeEvent() # Send a resize event to dialog.
# NOTE: You must generate a resize event yourself if your code changes any
# sizes. If the user changes a size by using the window decoration, the
# system generates the resize event. In general, all code is event driven.
button1.OnPress = OkFunc # Function to call on button press.
button2.OnPress = app.Exit # Use one of app's standard functions.
# Show dialog, start the application, respond to events.
dialog.Show() # All objects must be created with "show". "Show" also
app.MainLoop() # creates all child objects. "MainLoop" must be last.
# In general, the implementation depends only on instance variables and
# events, with no use of getattr/setattr. I will post details shortly.
Brad Midgley
James C. Ahlstrom <j...@interet.com> wrote:
>Recently I have been working on a Python GUI Abstraction Layer. I realize
>that other people are working on this, and I am posting this to see who
>you are (please reply) and to relate what I found out so far. To keep the
>length down I plan to followup later this week. I would appreciate any
>criticism you may have.
These are the projects which are attempting to accomplish the same
goal which I know of:
stdwin
stdwin "2" (ftp://ftp.cwi.nl/pub/fj)
WxWindows (c++, but work has been done on a python binding)
So there has been considerable work thrown against this.
I think this type of functionality will make python incredibly useful
and appealing to application developers. After all, look at what a
single-platform gui set, tk, did for tcl, in spite of tcl's
weaknesses. Python is already more appealing to language purists.
--
Brad (bmid...@sunset.cs.utah.edu)
Jack Jansen
separation in a functionality part and a rendering part. The
functionality part is little more than a description of the abstract
actions the user can take (and what happens in Python if she does) and
the feedback the program can give. The actual details of how the user
takes an action (pressing a button, clicking the mouse) or how the
feedback is represented on the screen (i.e. are numbers printed,
sliders moved, whatever) should be specified in a different place.
I think the first bit, the functionality part, could use the same
interface across GUI platforms. The second bit will probably have to
change to make things look nice.
In my opinion, the functionality bit should be fully written in
python, and the rendering bit can be written in python (by calling to
the appropriate GUI toolbox routines), in a GUI designer or in a mix
of both (e.g. if you use a GUI designer but want to change the color
of boxes occasionally).
--
--
Jack Jansen | If I can't dance I don't want to be part of
Jack....@cwi.nl | your revolution -- Emma Goldman
uunet!cwi.nl!jack G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl
Martin Andrews
: Recently I have been working on a Python GUI Abstraction Layer. I realize
: that other people are working on this, and I am posting this to see who
: you are (please reply) and to relate what I found out so far. To keep the
: length down I plan to followup later this week. I would appreciate any
: criticism you may have.
I am working on a somewhat similar project - a portable windowed user
interface. It is not just for python - the core API is in C - but
could be interfaced to any of the interpreted extension languages.
My goal is a very low common denominator (as some other posters have
feared) - the defining rule of my API is that it must work on a character
terminal. I am targeting the library for custom database applications
that tend to consist of many, many form-like windows. I do want the
user interface to have the native look and feel of the GUI. Drop
me a line if you want more information (the project is still in the
early development phase).
--
Martin Andrews and...@ccfadm.eeg.ccf.org
Dept. of Neurology Phone (216)444-7485
Cleveland Clinic Foundation Fax (216)445-6617
Gregor Schmid
>>>>> James C. Ahlstrom writes:
>> Recently I have been working on a Python GUI Abstraction Layer.
>> I realize that other people are working on this, and I am posting
>> this to see who you are (please reply) and to relate what I found
>> out so far. To keep the length down I plan to followup later
>> this week. I would appreciate any criticism you may have.
>>>>> "MHammond" == @ JM <Hammond> writes:
MHammond> I have been working on an MS Windows layer for Python.
MHammond> One common problem I have always found with cross platform
MHammond> toolkits of any type is their "lowest common demoninator"
MHammond> approach.
MHammond> I think the real challenge in this sort of work is to
MHammond> ensure that the developer has _every_ feature available on
MHammond> their chosen/primary platform.
MHammond> This is especially important for applications which hope
MHammond> to go commercial. In my case, having an MSWindows only
MHammond> product that really exploits the platform is far more
MHammond> important than a cross platform product that really
MHammond> exploits _no_ platforms.
[example deleted]
I just attended a conference held by ISA, a company that is developing
a crossplatform Dialog Manager. There were about 150 users present,
split into two opposing fractions:
Some people want to have their product look identical across all
platforms, even if that means to force some nonstandard (e.g. MS
Windows) behaviour onto some platforms (e.g. Motif).
Others want to fully exploit all the features of their current
platform, regardless of portability.
Unfortunately ISA's approach is the 'least common denominator' one:
"We don't support what your platform does not support and if your
platform has options the others don't have, we won't support them either."
(This is not always true, I don't want to discredit ISA).
IMHO The Right Thing (tm) is a two way approach:
Start with a common interface as James Ahlstrom has suggested. Use
the least common denominator approach. Get it right across all
platforms. Most applications don't need anything else.
Then start adding platform specific things, like OS/2s notebook or
some custom Motif widgets, or MS Windows' combobox. Make sure to
extend the common interface to handle the new stuff. Then others can
start to emulate that object on their platform and soon portability is
reestablished.
For those cases, where no common approach is possible (like some nasty
event handling details), allow access to the platform specific
interface, so one can still write portable code by inquiring the
underlying architecture and handling each case separately.
Never force the user to go out of his way to access platform specific
features. If he doesn't want portable code, don't force it on him.
If he wants the most powerful code for his platform, allow it.
If the efforts of users of different platforms can be coordinated in
this way, we will have one of the most powerful and flexible
crossplatform GUI development systems in no time (and as somebody else
has already noticed, even one that will satisfy most language purists
:-).
Regards,
Greg
James C. Ahlstrom
Here are the details on the implementation using tkinter. All source and
documentation is available from ftp.interet.com. It has been tested on
SunOS 4.1.1 and Linux. Keep in mind that it is a demonstration of concept
rather than something currently useful for writing programs.
The main Python program imports the module "wpy.py", which is meant to be
mostly the same for any platform. This module contains all the class de-
finitions and most of the logic for the window system. It contains its
own geometry manager for example. The Tk geometry managers are not used
because they are not available on other platforms.
The module "wpy.py" imports the module "wpyos.py" which contains the code
which is highly dependent on Tk. The module "wpyos" imports "tkinter" but
not "Tkinter.py". I am hoping that when ported to MS Windows etc., "wpy"
will remain mostly the same and only "wpyos" will be rewritten. If this
proves impractical, I guess we may as well just use one module. For any
platform, there will be a different "wpy" and "wpyos". I envision a
"wpyos.tk", "wpyos.msw", wpyos.os2", etc. with "wpyos.py" a link to the
correct version.
A basic question is whether to use "x = object.locationX" and
"object.locationX = 150" to get/set location, or whether to use "x =
GetLocationX(object)" and "SetLocationX(object, 150)". The first case
seems to need setattr/getattr to notify the underlying system to change
the size. This conundrum applies to any attributes of an object which may
be changed.
The design used relies on instance variables for most purposes, and events
for notification of changes. This enables us to write x=a+b rather than
set_x(get_a() + get_b()). There is no use of getattr/setattr.
The instance variables won't do anything until the programmer sends an
event to the relevant object. This seems natural (at least to me) for
geometry because all modern GUIs are event driven, and the user can change
the size and location of a top level window at any time by using the win-
dow decorations. In that case, an event "EventSize" is generated and must
be handled by the event handler "OnSize". Why not just let the programmer
generate events too? So widget configuration would be done by a large set
of instance variables, a smaller set of methods (functions) and
setattr/getattr only when all else fails. Most variables and methods
would be inherited.
Python events are generic and are not the same as X/MSW/OS2 events. Since
there is not much point to an object oriented language unless inheritance
is used extensively, event handlers are designed to be inherited. If you
do not like the geometry manager, just write your own and replace the On-
Size event handler with it. This works both for individual objects and
for classes of objects.
There is more documentation in the form of comments in the source code.
What do you think?
Robin Friedrich
|
|IMHO The Right Thing (tm) is a two way approach:
|
|Start with a common interface as James Ahlstrom has suggested. Use
|the least common denominator approach. Get it right across all
|platforms. Most applications don't need anything else.
|
|Then start adding platform specific things, like OS/2s notebook or
|some custom Motif widgets, or MS Windows' combobox. Make sure to
|extend the common interface to handle the new stuff. Then others can
|start to emulate that object on their platform and soon portability is
|reestablished.
This is exactly what we concluded at the recent Python workshop!
[http://www.eeel.nist.gov:80/python/workshop11-94/]
Tommy at UVA was given the baton to use his exercise to create a
pure TkPython (sans tcl) to help define a generic GUI API for Python.
[http://server.cs.virginia.edu/~tnb2d/IT/IT.html]
This API is targeted at the many folks who do not need a commercial
grade toolkit support for a particular platform but rather would love
to have an API capable of writing a PORTABLE GUI for their python
software. Mr. Hammond's desire for a fully capable GUI API for Windows
which allows him to write commercial products in Python would not (and
is not intended) be supported by a generic GUI API. He is free to
develop highly focused toolkit bindings for whatever platform he
wishes. Commercial grade bindings should probably come from a
commercial vendor right? (or do you want that to be free too?) There
is a large potential user base for a generic, free, easy to use API
though, where portability is more important that full spiffyness; the
government and university sectors to name just a couple. I'd love to be
able to write a full application at home on my Mac and just carry it to
work and run it on my Sun in Motif. The idea is to satisfy that need
with the generic API. Imagine the cottage industry!
As Gregor mentions, the common denominator approach can be made less
restrictive by allowing folks to implement toolkit specific features in
the generic environment as long as it's easily identifiable as such
(naming?convention). Using a common denominator as a baseline and
growing it from there is perfectly acceptable. (I have hundreds of
engineer-type users of an interpreted Motif GUI programming environment
writing thousands of GUI apps here at NASA and none of them have to
know anything about C or X/Motif window programming.)
...
|If the efforts of users of different platforms can be coordinated in
|this way, we will have one of the most powerful and flexible
|crossplatform GUI development systems in no time (and as somebody else
|has already noticed, even one that will satisfy most language purists
|:-).
Maybe not in _NO_ time;-)
This points to one of the prime reasons for forming a Python Language
Association (also agreed to at the NIST workshop). We need to coordinate
all this great volunteer effort out there. No facism here, just an effort
to minimized duplication of effort (the true evil).
-Robin-
Bill Janssen
Frie...@rose.rso (3013)
> a generic, free, easy to use API
> though, where portability is more important that full spiffyness;
Spiffyness would be nice to have, as well, though. BBN's version of the
Andrew Toolkit looks so nice and polished mainly because they involved
some graphic designers in working out how various widgets should look.
Perhaps such a thing isn't out of question in a volunteer effort...
Bill
Will Duquette
"Visual Basic! Visual BASIC!" (I know it's customary to bash
Microsoft, and also to bash BASIC, but Visual BASIC is an excellent
product within its limitations. Bear with me).
The advantage of Visual BASIC is that the language and the GUI
abstraction are tightly coupled. Here's how you create an
application: you ask for a new window. You place controls (widgets)
in the window. You create a menu with a hierarchical menu editor.
You set the initial properties (resources) of each control (widget)
using a very nice property browser. Then, you select a control
(widget) and ask for a code window. It has a pulldown menu of all of
the events (callbacks) that that control can respond to. Select one;
VB puts the function skeleton in the window. Fill it in.
Repeat for the various controls and menu items. At any time, go back
and add some controls, or move them around. At any time, run the
application and see if it works.
You can get a lot of this functionality with a code generator, but not
all of it.
The disadvantages of Visual BASIC are as follows:
1. The base language is BASIC, after all. It's a very powerful BASIC,
which means it contains a lot of weird, _ad hoc_ stuff. And even
with that, it's still BASIC.
2. It only works with MS Windows (and DOS, I guess).
I've written MS Windows applications in C; I've written Motif programs
in C; VB is much easier (within its limitations).
I'll put this way: IMHO, just as Python is a friendlier, more
comfortable way to do many tasks than C, VB is a friendly, more
comfortable way to do GUI programming than anything else I've seen.
Now, what I *really* want on my Sun workstation is Visual Python.
I don't just want a standard GUI abstraction, I want a standard GUI
abstraction that enables me to create powerful GUIs without 50 pounds
of manuals. I want to be able to draw a GUI and run it immediately.
I want to be able to browse widget resources and set them. And I
want to do it all in Python.
Is that so much to ask? :-)
Seriously, anyone who does X Windows or Mac or MS Windows programming
for a living and hasn't looked at Visual Basic really ought to play
with it for a while. It's not perfect, but they got an awful lot
right.
------------------------------------------------------------------------------
Will Duquette | William.H...@jpl.nasa.gov
Jet Propulsion Laboratory | wi...@hal9000.jpl.nasa.gov
--
------------------------------------------------------------------------------
Will Duquette | William.H...@jpl.nasa.gov
Jet Propulsion Laboratory | wi...@hal9000.jpl.nasa.gov
Paul Everitt
Will--
This was part of the workshop discussion. I agree, VB can be an
illustration of a good design point. However, I would say that the
argument is more:
VB is to (visual) Basic as xf is to tk, and Visual Python is to
Python as tk is to tcl.
In that vein, what is needed is a GUI-builder environment above Visual
Python.
--Paul
Paul Everitt V 703.785.7384 Email Paul.E...@cminds.com
Connecting Minds, Inc. F 703.785.7385 WWW http://www.cminds.com/
John Goodsen
[example deleted]
It's been done for you. It's called Galaxy. Contact Visix Software
in...@visix.com.
--
--
John Goodsen Currently on-site at:
The Dalmatian Group JP Morgan
User Interface Specialists 60 Wall St., New York City
jgoo...@radsoft.com jgoo...@jpmorgan.com
Gregor Schmid
In article <WILL.94D...@hal9000.jpl.nasa.gov> wi...@hal9000.jpl.nasa.gov (Will Duquette) writes:
Will> As I've followed this thread, one phrase keeps ringing in my
Will> head: "Visual Basic! Visual BASIC!" (I know it's customary
Will> to bash Microsoft, and also to bash BASIC, but Visual BASIC is
Will> an excellent product within its limitations. Bear with me).
[goes on to describe VB...]
Will> Now, what I *really* want on my Sun workstation is Visual
Will> Python. I don't just want a standard GUI abstraction, I want
Will> a standard GUI abstraction that enables me to create powerful
Will> GUIs without 50 pounds of manuals. I want to be able to draw
Will> a GUI and run it immediately. I want to be able to browse
Will> widget resources and set them. And I want to do it all in
Will> Python.
Will> Is that so much to ask? :-)
I think you should ask that question when the genric Python GUI
interface is finished. However nice VB may be, you will have to agree
that it cannot function without some language interface.
Will> Seriously, anyone who does X Windows or Mac or MS Windows
Will> programming for a living and hasn't looked at Visual Basic
Will> really ought to play with it for a while. It's not perfect,
Will> but they got an awful lot right.
When the interface is ready for testing, try it out. When I started to
use Tcl/Tk I also took a look at XF, a quite powerful GUI builder,
that does most of what you described about VB. I realized very soon
that I was much better at writing Tk widgets from scratch, than at
using XF to create them. You cannot compare that coding style to
writing GUI stuff in C. With Python it should be even better.
If you then find that you still want "Visual Python", then go ahead
and bring it up again (it will be useful in any case for newbies,
demos, fast prototyping etc.), but maybe you'll change your mind.
Then again, maybe not :-)
Regards,
Greg
Will Duquette
I think you should ask that question when the genric Python GUI
interface is finished. However nice VB may be, you will have to agree
that it cannot function without some language interface.
I'm actually not so much concerned with the generic Python GUI
interface; I'd happily use something that only worked with X. What
I'm after is the tight coupling of the language and the windowing system.
When the interface is ready for testing, try it out. When I started to
use Tcl/Tk I also took a look at XF, a quite powerful GUI builder,
that does most of what you described about VB. I realized very soon
that I was much better at writing Tk widgets from scratch, than at
using XF to create them. You cannot compare that coding style to
writing GUI stuff in C. With Python it should be even better.
I have to confess (shame, shame) I haven't used tk. I'm very curious
about it, and also about XF -- is it freely available?
If you then find that you still want "Visual Python", then go ahead
and bring it up again (it will be useful in any case for newbies,
demos, fast prototyping etc.), but maybe you'll change your mind.
Then again, maybe not :-)
The thing I like about Visual BASIC is that it's easy to remember how
to use it. I haven't written anything in Visual BASIC in over a year,
yet I know I could sit down at my PC, fire it up, and be productive
quickly: the base language is familiar, and the GUI-builder aspect
means that I don't need to remember the names and resources of the
widgets. VB shows me all of the widgets that are available, and
all of the resources, and makes sure that my resource settings are
reasonable.
The thing I like about Python is that I find it as simple and easy
to use, and as easy to remember, as BASIC--yet it's much, much more
powerful. So basically I want the best of both worlds.
Ken Manheimer
think it should be said, before the discussion gets too far, that every
person i know who has really looked at both emphatically assert that
there is *no* comparison. They tend to be distinctly impressed with
visual basic, and conversely unimpressed with xf. I would check out vb
before clumping it with xf (and vice versa).
Ken
Hammond, Mark
> As I've followed this thread, one phrase keeps ringing in my head:
> "Visual Basic! Visual BASIC!" (I know it's customary to bash
> Microsoft, and also to bash BASIC, but Visual BASIC is an excellent
> product within its limitations. Bear with me).
Yes, Yes, Yes :-)
[Im sorry in advance if I get sidetracked here :-)]
My "paid" work involves a lot of Visual Basic coding for small (ie, 1-2
person dev) applications, and I use Python only at home. I am constantly
amused by the VB bashing that goes on. While having a quick glance over the
enourmous threads in the VB news groups about how bad VB is (ie, no
inheritance, no ______), I am knocking up apps in no time flat. Sure, I
would really like to see all the features everyone complains about, but
IMHO, the proof is in the pudding - the users _rave_ about my VB apps, and I
code them _quick_. Python is starting to come close in terms of
productivity, but VB still wins hands down for small GUI applications.
I would really love to see a Python environment that is anywhere near as
productive as VB for creating GUI based applications. Python is in a _very_
good position to do this - it has all the language features, and some of
this GUI work may allow it to head in this direction.
And I may as well come totally out of the closet here :-) When I started on
the Win32 GUI stuff for Python, I really had something like VB in mind - but
I was too shy to actually express this to the Python community at large.
But my designs (if you can call them that :-) for the Win32 GUI stuff
certainly have this in mind.
No one should underestimate the work required to develop something like
this, but if we _could_ get even 1/2 way there, I think we would find Python
becoming very mainstream RSN (whether we are ready for it or not!)
If there is not much support from the "standard GUI abstraction" people for
this concept, then I would be more than happy to see the Win32 GUI stuff
move in this direction. (As a side issue, I would also be more than happy to
see the Win32gui stuff move towards the "standard GUI abstraction"
directions too, as far as this is possible without comprimising the
"platform specific" features)
Cheers...
Mark.
Stephen Benson
In article <WILL.94D...@hal9000.jpl.nasa.gov>, Will Duquette (wi...@hal9000.jpl.nasa.gov) writes:
>In article <GS.94De...@bvg.ivu-berlin.de> g...@ivu-berlin.de (Gregor Schmid) writes:
> When the interface is ready for testing, try it out. When I started to
> use Tcl/Tk I also took a look at XF, a quite powerful GUI builder,
> that does most of what you described about VB. I realized very soon
> that I was much better at writing Tk widgets from scratch, than at
> using XF to create them. You cannot compare that coding style to
> writing GUI stuff in C. With Python it should be even better.
>
>I have to confess (shame, shame) I haven't used tk. I'm very curious
>about it, and also about XF -- is it freely available?
>
From the point of view of a novice with both languages, tcl/tk is even more
easy and immediate than VB in turns of ease of constructing useful little apps.
Then that's something to do with the OS too.
XF is a free tk gui builder (don't have the site available right now); it's
pretty big and produces very complicated code; there is a smaller alternative
called USE (adequate for learning/experimentation). Mail me if no-one else
points you to the right sites.
--
: stephen benson : : : : : : : : step...@scribendum.win-uk.net
James C. Ahlstrom
Will Duquette <wi...@hal9000.jpl.nasa.gov> wrote:
>As I've followed this thread, one phrase keeps ringing in my head:
>"Visual Basic! Visual BASIC!" (I know it's customary to bash
>Microsoft, and also to bash BASIC, but Visual BASIC is an excellent
>product within its limitations. Bear with me).
I agree that that a Visual Python would be GREAT, but it still seems
that the GUI abstraction layer is a different issue. VP should be
written using the GUI so that it too can run on any platform. If
VP is written in (say) tkinter, then it only runs on X. A chicken
and egg problem.
I am really sorry I missed that Python workshop!
Jim Ahlstrom
James C. Ahlstrom
Hammond, Mark <MHam...@cmutual.com.au> wrote:
>
>I would really love to see a Python environment that is anywhere near as
>productive as VB for creating GUI based applications. Python is in a _very_
>good position to do this - it has all the language features, and some of
>this GUI work may allow it to head in this direction.
Yes YES, and Python is a beautiful language too!
>
>If there is not much support from the "standard GUI abstraction" people for
>this concept, then I would be more than happy to see the Win32 GUI stuff
>move in this direction. (As a side issue, I would also be more than happy to
>see the Win32gui stuff move towards the "standard GUI abstraction"
>directions too, as far as this is possible without comprimising the
>"platform specific" features)
I may be missing something, but I don't see a conflict here. A
Visual Python is a lot of work, and if it were written in Win32 it
would only run on Windows (wouldn't it?). If it were written in a
Python GUI abstraction portable to several platforms, then VP
would run on all those on day one. Don't we need a Python GUI
first so that people can start making VP?
Jim Ahlstrom
Robin Friedrich
|> From jan...@parc.xerox.com Tue Dec 6 17:02 CST 1994
|> Date: Tue, 6 Dec 1994 14:41:25 PST
|> Sender: Bill Janssen <jan...@parc.xerox.com>
|> From: Bill Janssen <jan...@parc.xerox.com>
|> To: pytho...@cwi.nl, frie...@rose.rsoc.rockwell.com
|> Subject: Re: Standard GUI abstraction for Python
|> Content-Type: text
|> Content-Length: 492
sophistication with which one can make them behave. This is were the really
mean problems arise in portable API's (do I support a combo box? do I support
auto widget positioning upon resize, etc.). Each toolkit approaches these
features differently and THAT's what's so hard to factor a common denominator
for.
The generic API we are discussing for Python would LOOK just like any other
native (Motif say) application because there would be a runtime layer which
translates generic GUI object specification/manipulation into the native
toolkit calls. That's were you may have to sacrifice some "spiffiness".
A python binding from the generic API to the BBN toolkit would of course
be doable. Volunteers???
--------------------------------------------------------------
| Robin K. Friedrich | frie...@rsoc.rockwell.com |
| Rockwell Space Operations | (713) 282-2974 |
| Houston, TX | |
--------------------------------------------------------------
Robin Friedrich
Mark Hammond writes @Thu, 8 Dec 1994 18:02:00 GMT:
|...I would really love to see a Python environment that is anywhere near as
|good position to do this - it has all the language features, and some of
|this GUI work may allow it to head in this direction.
|
|And I may as well come totally out of the closet here :-) When I started on
|the Win32 GUI stuff for Python, I really had something like VB in mind - but
|I was too shy to actually express this to the Python community at large.
| But my designs (if you can call them that :-) for the Win32 GUI stuff
|certainly have this in mind.
|
|No one should underestimate the work required to develop something like
|this, but if we _could_ get even 1/2 way there, I think we would find Python
|becoming very mainstream RSN (whether we are ready for it or not!)
|
|If there is not much support from the "standard GUI abstraction" people for
|this concept, then I would be more than happy to see the Win32 GUI stuff
|move in this direction. (As a side issue, I would also be more than happy to
|see the Win32gui stuff move towards the "standard GUI abstraction"
|directions too, as far as this is possible without comprimising the
|"platform specific" features)
|
|Cheers...
|
|Mark.
Speaking as one of those "standard GUI abstraction" people, I agree whole-
heartedly with Mark's direction and I think this was indeed the belief at
the workshop. We definately have all the tools needed to make it happen.
There is nothing in our ideas which prohibit "platform specific" features
just a solid core of GUI abstraction which will work on a spectrum of
native toolkits.
I also agree that this GUI environment is the missing link to make Python
"mainstream".
-Robin-
Robin Friedrich
|It's been done for you. It's called Galaxy. Contact Visix Software
|in...@visix.com.
|--
|--
|John Goodsen Currently on-site at:
John, elsewere in this thread I commented that what the Python community
is pursuing is a portable *python* API which is *free*. Galaxy is a C API.
A generic API binding to the Galaxy environment would certainly be possible.
Voluteering?
-Flame ON-
Galaxy: Trying to set the record for the world's most expensive software.
-Flame OFF-
Jim Fulton
A agree, but I think we can go a bit further. I suggest an approach
along the lines of:
1. Start with a least-common-denominator approach with hooks to take
advantage (non-portably) of platform-specific features.
2. Over time, add more and more features, with the goal being to
provide a superset of features that go beyond what is common. That
is, implement features that may not exists in all toolkits by
impementing them on top of the common denominator or by abstracting
them in such away that p[latform specific features are used where
available but sourse code is not site specific. This is
essentially the Galaxy approach. Note that we can do this
gradually, based on experience gained with the common layer.
3. Develop visual Python based on what is common. Visual Python will
get richer over time as the common layer evolves.
--
-- Jim Fulton jfu...@mailqvarsa.er.usgs.gov (703) 648-5622
U.S. Geological Survey, Reston VA 22092
This message is being posted to obtain or provide technical information
relating to my duties at the U.S. Geological Survey.
Robin Friedrich
Agreed.
I guess everyone that was at the workshop has a clear understanding of the
intent behind the generic GUI strategy. Now the trick is to explain it to the
rest of the world. Your list above gives a nice summary of what we're after.
I might re-emphasize that this work doesn't involve establishing any new GUI
widgets just a common python way of addressing them regardless of toolkit used
at run time. There was some confusion on that matter on the net.
Gregor Schmid
In article <JFULTON.94...@dsjfqvarsa.er.usgs.GOV> jfu...@dsjfqvarsa.er.usgs.GOV (Jim Fulton ) writes:
[old refs deleted]
Jim> 1. Start with a least-common-denominator approach with hooks to
Jim> take advantage (non-portably) of platform-specific features.
Jim> 2. Over time, add more and more features, with the goal being
Jim> to provide a superset of features that go beyond what is
Jim> common. That is, implement features that may not exists in all
Jim> toolkits by impementing them on top of the common denominator
Jim> or by abstracting them in such away that p[latform specific
Jim> features are used where available but sourse code is not site
Jim> specific. This is essentially the Galaxy approach. Note that
Jim> we can do this gradually, based on experience gained with the
Jim> common layer.
Jim> 3. Develop visual Python based on what is common. Visual
Jim> Python will get richer over time as the common layer evolves.
Exactly what I said (or meant to say, maybe? :-). Now let's get the
thing going. I tried to acceess the Workshow www pages, but couldn't.
Is anybody already in charge for that project ? How many people are
working on it ? How do I contribute ?
By the way, the X11-stuff in the extension package looks quite useful.
I think it may be possible to to get at least 3 different unix GUIs
under the common interface (Motif, Athena widgets and Tk) plus the
GUIs for other OSs.
Regards,
Greg
Paul Everitt
Gregor--
Yep, we're working on it. A bit more difficult than we originally
imagined, but most of the ideas are shaping up. Hope to have something
published soon (sorry for the delay).
--Paul
Harri Pasanen
Before starting to implement a cross platfrom GUI, which is a *major*
effort, I'd suggest looking into wxWindows, which is a free cross
platform gui across xview, motif, windows.
(see http://www.aiai.ed.ac.uk/~jacs/wxwin.htSml).
In fact, I have written a python interface to wxWindows, which
implement a pretty large subset of wxWindows functionality.
(textfields, buttons, radiobuttons, checkbuttons, listboxes,
menubars/menus, canvas, pens, brush). It still has a few glitches
that I haven't had time to iron out. I'll try to wrap it up for
Christmas :).
Take Care,
Harri
--
------------------------------------------------------
Harri Pasanen p...@tekla.fi
James C. Ahlstrom
at ftp.interet.com in directory pub/python. After writing some programs,
I found it necessary to make some changes in the design.
Ed Miller (e...@infoseek.com) wrote to suggest using setattr/getattr,
and after some more experience I agree. It is just too annoying to generate
events for each change. So the current design uses __setattr__ followed
by a dictionary lookup to trap all changes to variables which require
notification to the underlying native GUI. This is used for changes to
titles, visibility, enable/disable of menu items, etc. Size changes
(currently) still require the programmer to generate a size event.
So a change in title would look like this:
window.title = "New title"
with no further action required. I believe this is better that methods
for everything as in:
window.ChangeTitle("New title")
because the instance variable "window.title" still exists and you can write
the_title = window.title
with no need of a "getattr" or a "get" method.
I also added a few more widgets, namely menus, labels and messages. I also
changed the name of the second included file and a number of variable
names to make them less confusing and more consistent, and (well) prettier.
Barry Merriman
>This is an update on a proposed Python GUI abstraction. Updated code is
>at ftp.interet.com in directory pub/python. After writing some programs,
>I found it necessary to make some changes in the design.
>
Something you may want to take a look at to stimulate your
thinking:
There is a new book on user interfaces out (I could get the title
if you want it) that does a feature by feature comparison of
the Mac, OS/2, Windows, Motif and NextStep (The best! :-) GUI's.
The book is intended for cross platform app designers who want
to understand the differing features and look and feel of these
major GUI options. It is a very nice book---side by side comparisons
of the desktop, windows, icons, menus, dialog boxes, both in terms
of appearance and functionality.
Perhaps this detailed concrete info would allow you to better
abstract a more useful set of features for pythons abstract GUI.
By the way: one thing that sticks in my mind afetr skimming
the book is that these diverse window systems are more
the same than they are different. Also, the new windows
interface ( Windows95, not covered in this book, I don't
think) described in various other books seems to rather closely
resemble NeXTSTEP, which should be considered a good thing.
--
Barry Merriman
UCLA Dept. of Math
UCLA Inst. for Fusion and Plasma Research
ba...@math.ucla.edu (Internet) ba...@arnold.math.ucla.edu (NeXTMail)
James Uther
good, but only runs on X. However, looking at the plans of the tk/tcl group
at sun this is only a temporary problem, to be fixed in the next major release
(they want tk/tcl to be cross platform - scripts run unchanged on X/win/mac)
I suppose if people like tkinter, then counting on a pc/mac release of tk/tcl
might be the way to go... (i'm assuming here of course that tkinter would be
easily portable once this has happened).
BTW, you might like to check out a www page about this stuff;
http://playground.sun.com/~ouster/sunplans.html
just my 2 bits worth
jim
James C. Ahlstrom
Barry Merriman <ba...@redwood.math.ucla.edu> wrote:
>There is a new book on user interfaces out (I could get the title
>if you want it) that does a feature by feature comparison of
>the Mac, OS/2, Windows, Motif and NextStep (The best! :-) GUI's.
Yes, what is the title/author. It may be useful. I have been reading
the WinNt, XVT and Tk manuals and concentrating on function calls,
not the high level appearance.
James C. Ahlstrom
James Uther <ji...@cs.su.oz.au> wrote:
>Are people actually happy with tk? The argument here seems to be that tk is
>good, but only runs on X. However, looking at the plans of the tk/tcl group
>at sun this is only a temporary problem, to be fixed in the next major release
>(they want tk/tcl to be cross platform - scripts run unchanged on X/win/mac)
Yes, and the first beta is out. But only for Unix so far.
>
>I suppose if people like tkinter, then counting on a pc/mac release of tk/tcl
>might be the way to go... (i'm assuming here of course that tkinter would be
>easily portable once this has happened).
This is a big question mark. The Tk people will have all the problems of
cross-platform development too. They are talking about a "Tk portable
subset" that runs on multiple platforms.
BTW, I am trying to hide Tk under a layer that looks good in Python.
>
>BTW, you might like to check out a www page about this stuff;
> http://playground.sun.com/~ouster/sunplans.html
Thanks!