From: Gregory Ewing on 10 Jun 2010 02:40 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. -- Greg
From: Gregory Ewing on 10 Jun 2010 03:42 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. -- Greg
From: Martin v. Loewis on 10 Jun 2010 03:58 > 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. Regards, Martin
From: Gregory Ewing on 10 Jun 2010 04:14 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. -- Greg
From: Martin v. Loewis on 10 Jun 2010 04:13
> That said, PerlTk didn't use Tcl did it? If you are referring to http://search.cpan.org/~srezic/Tk-804.028/ - 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. Regards, Martin (*) http://www.lns.cornell.edu/~pvhp/ptk/ptkFAQ.htm |