Graphical User Interface SIG

WPY

• Portability
  • Linux, NT, 95, Windows 3.1 (sortof - with win32s)
  • NT port funs on Win95, Win3.1, LAF: Native
  • No port (yet) to MAC
  • Strong port to UNIX using Tk
• Language
  • Python class library, high OO design
  • Python on UNIX/Tk, has C++ interface for NT port
  • No port for OS/2, but you can run it on OS/2 using a win32s or a new OS/2 LAF windows
• Documentation
  • 2000 lines of UNIX like documentation describes all
  • classes and methods. Discussion of app creation and drawing
  • Can read wpy.py sources, has all classes and methods
• Performance
  • under UNIX it uses tkinter -> TCL -> Tk
  • under Windows, it passes pretty quickly to C++ layer which makes MFC calls
  • Good performance for both
  • Special C++ support for scrolling on NT (native on Tk)
• Features
  • Document/View model class
  • under windows you get templates
  • Dialog classes (modal, modless)
  • Drawing classes, Brush, font, txt, line, circle, others
  • Images: gif, ppm, on all, bmp and dib on NT)
  • Control Classes: Push Button, Check Button, Radio Button (these check themselves on Tk, not MFC), Label, Message
  • Menus: Bar, Popup, cascading, popups
  • Geometry management is very different from Tk (MFC lacks geometry management)
  • WPY Geometry management is most like Tk placer
  • Geometry mangement is more like explicit placement, Controls have a default size, even the the GUI has not yet made the control
  • Footprint
    • On unix: uses stock build of Python 1.3 with Tk4.0 and tkinter.c Requires wpy.py (2300 lines), wpy_tk.py (1500 lines) and wpycon.py (600 lines)
    • On NT requires Python 1.2 (soon 1.3) plus 12 C++ modules with 6400 lines of C++, plus wpy.py, wpycon.py.
  • small code exerpts from the demo program (lot's of stuff omitted)

    # Make some brushes to draw points
    ignoreBrush = wpy.CBrush((127,127,127)).Create()
    mainBrush = wpy.CBrush((127,127,0).Create()
    
    # The View
    class GraphView(wpy.CScrollView):
    	def OnCreate(self, event):
    	def OnSize(self, rect): # Initial size or resize of window
    	def SetSelected(self, new): # Change the selected point
    	def DrawGraph(self, DC): # draw the graph
    	def OnDraw(self, DC): # Draw the view
    
    # Create the app
    app = GraphApp()
          

Demo of WPY

• Written by Jim Ahlstrom
• Slicker app than the Tk app (drag and drop annotations)
• WPY is based on little tkinter.c
• code is 546 lines
• Jim F: how would you do table widgets?
• Jim A: first I'd have to find the table widget in MFC and figure out how it works, then do the same thing for Tk, next figure out the simmilarities and differences, make some design decisions, implement the wpy wrapper
• Demo'd first under Solaris then under Windows 95
• slight quirk under 95 where the cross-hairs are not redrawn upon damage from a drag operation of a point object until the drop
• MFC has a document-view architecture where X11 is a callback architecture
• WPY uses MFC as a high-level model but mapps it into Tk as a medium level model
• Guido: How do you handle fonts?
• Jim A: Fonts are a nightmare, on X you can assign a font attribute (e.g. a font string), on Windows, you can specify three styles (which boil down to helvetica, Coriour, and whatever) then a font style (bold , italic), and MFC makes the best choice. MFC has the higher level model, so this is what WPY uses
• Should you need a call that does not exist, you need to write a C interface
• If you do something that's not documented under WPY, you run the risk of doing something that's not portable

PNET (HTML-based GUI)

By: Tyler Brooks

• Implemented as a plugin module - netscape style
• applet extension for wpy, except that it's more like grail extensions because there's no safety and downloading capabilities
• have multiple Microsoft's reusable software model (OCX) based plugin's
• have a python interpreter plugin
• I want to extend the model to the GUI using wpy
• motivation for using python is the cross platform capabilities of wpy... If just windows we're just the intended audience, I would go with straight MFC

wxWindows

• Presentation written by Harri Panasen(sp?)
• a C++ multiplatform GUI toolkit
• wxPython is a tin vaneer of to make wxPython accessable in python
• Freely available, object-oriented, mult-platform for Motif, Windows 3.1, XView (OS/2 and NeXT ports in limbo but partially complete)
• simplicity through abstraction and OOP
• Power though high functionality
• vendor independence via access to source (C++)
• wxWindows is in intended to compete as a commercial product
• feedback and fixes from user community
• online and printed manuals
• 150 classes - GUI and OS operations
• window clipboard support
• canvas, postscript, bitmaps, metafiles
• bindings to CLIPS, python, perl, scheme, prolog
• contraint layout system (not in python yet)
• utility for generating help files and manuals
• DDE/MDI/GDI support under Windows, DDE under UNIX
• libraries include tree drawing, toolbars, forms, hypertext
• moving toward MFC and a new imaging model
• Libraries...
  • 3D style controls, bitmap buttons, toolbars, messages and radio buttons
  • Tiny titlebars under Windows
  • Guage Classes
  • XPM pixmap functionality for icons and bitmaps
  • support for retriving GIF, raster, BMP files
• Platforms
  • XView 3.2 Motif 1.2, Most UNIX
  • Windows 3.11, Windows NT, WIN32S
  • VMS
  • Linux, IRIX, most main UNIX OS's
• wxBuilder a GUI builder for wxWindows
  • Interactively builds GUI code
  • generates C++ and wxResource files
  • Can load bitmaps and canvases
  • Runs under all wxWindows platforms
• Other utilities
  • Tex2RTF for online manuals
  • wxHelp a help view for UNIX
  • Under development: wxMedia (a multimedia container class)
• On the horizon
  • Document/View/Persistant storage architecture
  • Mulitmedia editor widget
  • WinSock and UNIX networking support
  • image manipulation class wxImage
  • Windows 95 and Mofif 2.0 support
  • MAC, OS/2 and NEXTSTEP ports coming on line
  • Begin OLE 2.0/OpenDoc wrapper

Demo of wxWindows

• Spent a very little amount time over Thanksgiving
• wxPython is not complete implementation of wxWindows
• On windows 95, an open gives you a windows 3.1 dialog!
• On UNIX you get a motif dialog
• Jim F. assertion: wxWindows people have made alot of the same design decisions as Jim (WPY) has - MFC (for better or for worse)
• Jim F. assertion: it's good to have some standard layout conventions MFC supports this heavily (you get something the user is familiar with)
• Create a dialog with no geometry management requirment (appears in the middle with default button placement etc.)
• Documentation is fairly extensive and complete
• Jim F. assertion: I have some minor complaints about the implementation, but nothing major
• 395 lines - without the regression module, so probably close to Jim A:

• Help menu on the right instead of the left (as it should be)
• seems to work the same...
• Motif Look and Feel

Where to we go from here?

• Reminder, stress the common GUI
• Robin Assertion: Doesn't think Tkinter is going to be able to fill the gap of the complex things he wants to do
• Guido: MFC gives you more abstraction than Tk (e.g. Most applications have a menu bar, a scrollbar) which you don't really need in Grail
• Roger Assertion: I don't completely agree, I can forsee many applications that create there own menus and there own TopLevel windows, etc.
• Assertion: last workshop we began this debate without the notion of grail or applets
• A: problem is now applets are here and need to be addressed
• Jim F: What about the technical developer who's not a computer scientist? All these API's are probably fine, but native L&F is probably very import
• Ken: Two big issues 1) simplicity 2) native L&F
• Tyler: let me add a third... applets
• Jim A: Is anyone else worried about TK under windows?
• Guido: Tk is there, it's tkinter that's not
• Michael: Simplicity is key
• Jim A: I don't believe that Osterhout's stuff runs under windows
• Guido: I belive that timing needs to be added to the list of important things
• Tyler: As a MFC programmer I found the wpy learning curve to be zero and if the windows audience is one you want, you may want to consider that
• Assertion (Kurt?): What we need os a standard, powerful, cross-platform, object model for a GUI interface with native look and feel, NeXT OPENSTEP is that model.
• Roger: I love OPENSTEP, but I also feel the timing is still early for it
• Kurt: The API *is* the most important thing, choose the most elegant, powerful API
• Guido: Mark Lutz's book has a chapter on tkinter
• Does that mean it's a defacto standard?
• No, but it helps push it out
• Jim F: Tk *is* the defacto standard... but not in the windows community
• Guido: python is more like basic than like C++, so it needs to be simple
• Robin: wxwindow and tkinter's API's are very close, wxWindows is just more evolved
• The concern is that Tk is not going to be ported well enough to Windows... otherwise we would not be here, we would already have chosen Tk... so the windows crowd want to go with something that's more proven
• Jim F: We have seen two tools today that can do both
• Assertion: Power users are the audience (e.g. from NASA and USGS)
• Jim F: one thing that makes wpy more attractive is the configuration management issue.
• Guido: the same argument works for tkinter
• Robin: as a common tool wxWindows is the *heavyest* of the choices but to me that's necessary to get close enough to the native kits
• Guido: we have different user populations, and depending on whom you focus you come up with a different choice
• Tyler: In my area, footprint is important (web situation)
• Jim: It seems like there is a tie between wpy and Tk so let's include wpy and tkinter in the python standard distribution
• Roger: I like Jim's idea, let's give wpy a chance to compete with tkinter, and in six months we'll have a much better idea that tk is going to be acceptable on Windows and the MAC. We'll rediscuss at the next meeting in six months. :-)