From: Gregory Ewing on
Lie Ryan wrote:

> Doesn't Mac uses an X server as well?

You can run one optionally if you want, but its native
graphics system is *not* based on X11. It has a window
server, but the protocol is completely different. The
details are shrouded in mysteries known only to Apple,
but I gather it's based on PDF drawing operations.

As far as I know, there is no separate "window manager"
process -- the window server itself takes care of
drawing and managing the window decorations, and there
is no published way of overriding how it does that.

From: Gregory Ewing on
Ethan Furman wrote:

> *Alert* Potentially dumb question following: On the MS Windows
> platform, Gtk is not required, just win32?

That's correct. The current version of PyGUI includes
a pywin32-based implementation.

From: Martin v. Loewis on
> Is the Tkinter GUI also the basic way that Python handles a graphics
> display? (I've never tried it.)

No. Python, in itself, does not "handle" graphics displays at all. For
any output to the graphics display, it uses some kind of library,
whether it's console output, or a GUI application. One specific GUI
library is Tkinter. A standard "print" command (which eventually also
outputs to the graphics display) instead uses the terminal emulation of
the operating system.

From: Gregory Ewing on
Brian Blais wrote:

> I wonder if that sort of philosophy would work: a really nice and
> clear, pythonic wrapper around a sophisticated, complex, and complete
> GUI framework. ... Depending on how it is designed, it might even be
> possible to have a multi-framework wrapping, so that someone could have
> a Qt-based wrapper, and another using the same module choose to have it
> wrap wx.

That's more or less what PyGUI is meant to be, except that the
frameworks currently wrapped are Cocoa, Gtk and pywin32. There's
also a slight difference in emphasis, since PyGUI aims to leverage
platform functionality as much as possible, rather than rely on
a large third-party library that duplicates much of that functionality.

> It should be thin enough that the underlying GUI
> library can be called directly, however, or its usefulness will be
> greatly diminished.

Hmmm... you probably *could* do that with PyGUI if you wanted, but
it would require delving under the covers and dealing with some
stuff that's a bit on the hairy side and wasn't meant to be seen
by ordinary mortals. Also the resulting app would no longer be
cross-platform, and might be tied to details of a particular
version of PyGUI. Possibly some hooks could be added to the API
to make this sort of thing cleaner, though.

From: Martin v. Loewis on
> That said, PerlTk didn't use Tcl did it?

If you are referring to -
this also has a full Tcl interpreter, in pTk/mTk, and uses Tcl_Interp
and Tcl_Obj throughout. From the Perl/Tk FAQ (*):

"However, from a Perl perspective, Perl/Tk does not require any
familiarity with Tcl, nor does its installation depend on any Tcl code
apart from that packaged within Perl/Tk."

They also explain

"The pTk code proper is an externally callable Tk toolkit (i.e. a
re-write of the Tk 8.0 code that allows easier external linking &
calling, especially by perl)."

I couldn't quite understand what they mean by that: the sources for
tcl/generic (for example) look fairly unmodified.