From red_hax0r at yahoo.com Wed Oct 13 14:35:42 2010 From: red_hax0r at yahoo.com (Jason Benjamin) Date: Wed, 13 Oct 2010 05:35:42 -0700 (PDT) Subject: [Pygui] Use with PIL Message-ID: <601817.45058.qm@web81902.mail.mud.yahoo.com> Is there a way to use PyGUI with Python Imaging Library, as in displaying the images that it loads?? Can't seem to find anything on the subject, so don't even know if it's possible.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Wed Oct 13 22:42:49 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 14 Oct 2010 09:42:49 +1300 Subject: [Pygui] Use with PIL In-Reply-To: <601817.45058.qm@web81902.mail.mud.yahoo.com> References: <601817.45058.qm@web81902.mail.mud.yahoo.com> Message-ID: <4CB619C9.6000801@canterbury.ac.nz> Jason Benjamin wrote: > Is there a way to use PyGUI with Python Imaging Library, as in > displaying the images that it loads? Nothing officially in the API yet. If you dig into the internals you could probably find a way of creating a PyGUI image from a PIL one, although the details would be different for each platform. I'll make a note to do something about this. -- Greg From greg.ewing at canterbury.ac.nz Sun Oct 17 10:31:00 2010 From: greg.ewing at canterbury.ac.nz (Gregory Ewing) Date: Sun, 17 Oct 2010 21:31:00 +1300 Subject: [Pygui] ANN: PyGUI 2.3 Message-ID: <4CBAB444.9080701@canterbury.ac.nz> PyGUI 2.3 is available: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ This version works on Snow Leopard with PyObjC 2.3. What is PyGUI? -------------- PyGUI is a cross-platform GUI toolkit designed to be lightweight and have a highly Pythonic API. -- Gregory Ewing greg.ewing at canterbury.ac.nz http://www.cosc.canterbury.ac.nz/greg.ewing/ This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. From smcclure at racemi.com Mon Oct 18 21:32:16 2010 From: smcclure at racemi.com (Steve McClure) Date: Mon, 18 Oct 2010 15:32:16 -0400 Subject: [Pygui] Dynamically changing Column or Row contents. Message-ID: <8B9E656A-B24D-403F-BB45-D2CA5D0B0326@racemi.com> Does this work? I tried this where self.servers is a Column of Buttons: # get rid the old servers for server in self.servers.contents: #print 'deleting server:',server self.servers.remove(server) for server in servers: #print 'adding server:',server b = Button(title=server, action=(self.show_details,'server',server)) self.servers.add(b) But the windows doesn't get updated. I've done quite a bit of Motif and PyGTK programing but this is my first cut at PyGUI. I'm on OS X Snow Leopard if that makes any difference. Thanks for any pointers, Steve -- Steve McClure smcclure at racemi.com From smcclure at racemi.com Mon Oct 18 22:27:14 2010 From: smcclure at racemi.com (Steve McClure) Date: Mon, 18 Oct 2010 16:27:14 -0400 Subject: [Pygui] Dynamically changing Column or Row contents. In-Reply-To: <8B9E656A-B24D-403F-BB45-D2CA5D0B0326@racemi.com> References: <8B9E656A-B24D-403F-BB45-D2CA5D0B0326@racemi.com> Message-ID: <60461F40-2CC0-4570-A2F4-6AAE1B1D4876@racemi.com> Oops, sorry, I was wrong. I was connecting to a different web service than I thought so the data was different. On Oct 18, 2010, at 3:32 PM, Steve McClure wrote: > Does this work? I tried this where self.servers is a Column of Buttons: > > # get rid the old servers > for server in self.servers.contents: > #print 'deleting server:',server > self.servers.remove(server) > > for server in servers: > #print 'adding server:',server > b = Button(title=server, action=(self.show_details,'server',server)) > self.servers.add(b) > > But the windows doesn't get updated. > > I've done quite a bit of Motif and PyGTK programing but this is my first cut at PyGUI. I'm on OS X Snow Leopard if that makes any difference. > > Thanks for any pointers, > Steve > -- > Steve McClure > smcclure at racemi.com > > _______________________________________________ > Pygui mailing list > Pygui at python.org > http://mail.python.org/mailman/listinfo/pygui -- Steve McClure smcclure at racemi.com From smcclure at racemi.com Mon Oct 18 22:50:44 2010 From: smcclure at racemi.com (Steve McClure) Date: Mon, 18 Oct 2010 16:50:44 -0400 Subject: [Pygui] Dynamically changing Column or Row contents. In-Reply-To: <60461F40-2CC0-4570-A2F4-6AAE1B1D4876@racemi.com> References: <8B9E656A-B24D-403F-BB45-D2CA5D0B0326@racemi.com> <60461F40-2CC0-4570-A2F4-6AAE1B1D4876@racemi.com> Message-ID: On Oct 18, 2010, at 4:27 PM, Steve McClure wrote: > Oops, sorry, I was wrong. I was connecting to a different web service than I thought so the data was different. I think I get it now. I'm iterating over the contents and removing them, thus changing the contents midstream. > > On Oct 18, 2010, at 3:32 PM, Steve McClure wrote: > >> Does this work? I tried this where self.servers is a Column of Buttons: >> >> # get rid the old servers >> for server in self.servers.contents: >> #print 'deleting server:',server >> self.servers.remove(server) >> >> for server in servers: >> #print 'adding server:',server >> b = Button(title=server, action=(self.show_details,'server',server)) >> self.servers.add(b) >> >> But the windows doesn't get updated. >> >> I've done quite a bit of Motif and PyGTK programing but this is my first cut at PyGUI. I'm on OS X Snow Leopard if that makes any difference. >> >> Thanks for any pointers, >> Steve >> -- >> Steve McClure >> smcclure at racemi.com >> >> _______________________________________________ >> Pygui mailing list >> Pygui at python.org >> http://mail.python.org/mailman/listinfo/pygui > > -- > Steve McClure > smcclure at racemi.com > -- Steve McClure smcclure at racemi.com From smcclure at racemi.com Mon Oct 18 23:04:56 2010 From: smcclure at racemi.com (Steve McClure) Date: Mon, 18 Oct 2010 17:04:56 -0400 Subject: [Pygui] Dynamically changing Column or Row contents. In-Reply-To: References: <8B9E656A-B24D-403F-BB45-D2CA5D0B0326@racemi.com> <60461F40-2CC0-4570-A2F4-6AAE1B1D4876@racemi.com> Message-ID: <6AAD579C-31FE-4B5F-AC81-99681F281C5D@racemi.com> On Oct 18, 2010, at 4:50 PM, Steve McClure wrote: > > On Oct 18, 2010, at 4:27 PM, Steve McClure wrote: > >> Oops, sorry, I was wrong. I was connecting to a different web service than I thought so the data was different. > > I think I get it now. I'm iterating over the contents and removing them, thus changing the contents midstream. Not completely. I still get an empty Column if I: self.servers = Column([]) then run the code below. There must be some property or method that causes the column/window to be resized according to its contents. It looks like calling shrink_wrap() will resize that one Column but then the parent Row and its parent Window don't resize. I must be doing something wrong because I doubt that manual geometry management is a goal of PyGUI. Thanks, Steve > >> >> On Oct 18, 2010, at 3:32 PM, Steve McClure wrote: >> >>> Does this work? I tried this where self.servers is a Column of Buttons: >>> >>> # get rid the old servers >>> for server in self.servers.contents: >>> #print 'deleting server:',server >>> self.servers.remove(server) >>> >>> for server in servers: >>> #print 'adding server:',server >>> b = Button(title=server, action=(self.show_details,'server',server)) >>> self.servers.add(b) >>> >>> But the windows doesn't get updated. >>> >>> I've done quite a bit of Motif and PyGTK programing but this is my first cut at PyGUI. I'm on OS X Snow Leopard if that makes any difference. >>> >>> Thanks for any pointers, >>> Steve >>> -- >>> Steve McClure >>> smcclure at racemi.com >>> >>> _______________________________________________ >>> Pygui mailing list >>> Pygui at python.org >>> http://mail.python.org/mailman/listinfo/pygui >> >> -- >> Steve McClure >> smcclure at racemi.com >> > > -- > Steve McClure > smcclure at racemi.com > -- Steve McClure smcclure at racemi.com From greg.ewing at canterbury.ac.nz Tue Oct 19 08:03:39 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 19 Oct 2010 19:03:39 +1300 Subject: [Pygui] Dynamically changing Column or Row contents. In-Reply-To: <6AAD579C-31FE-4B5F-AC81-99681F281C5D@racemi.com> References: <8B9E656A-B24D-403F-BB45-D2CA5D0B0326@racemi.com> <60461F40-2CC0-4570-A2F4-6AAE1B1D4876@racemi.com> <6AAD579C-31FE-4B5F-AC81-99681F281C5D@racemi.com> Message-ID: <4CBD34BB.40006@canterbury.ac.nz> Steve McClure wrote: > Not completely. I still get an empty Column if I: > > self.servers = Column([]) > > then run the code below. There must be some property or method > that causes the column/window to be resized according to its contents. No, there isn't, sorry. The Row and Column classes (and most other containers) lay out their contents once when you create them. They're not designed to cope with dynamically adding and removing subcomponents. -- Greg From kxroberto at googlemail.com Tue Oct 19 20:07:14 2010 From: kxroberto at googlemail.com (Robert) Date: Tue, 19 Oct 2010 20:07:14 +0200 Subject: [Pygui] PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems Message-ID: A) What could be the cause for this exception of PyGUI with pywin32-build214 - but not with build 212 :? Traceback (most recent call last): File "blobedit.py", line 131, in BlobApp().run() File "C:\Python26\lib\site-packages\GUI\GenericGApplications.py", line 122, in run self.process_args(sys.argv[1:]) File "C:\Python26\lib\site-packages\GUI\Generic\GApplications.py", line 251, in process_args self.open_app() File "blobedit.py", line 32, in open_app self.new_cmd() File "C:\Python26\lib\site-packages\GUI\Generic\GApplications.py", line 219, in new_cmd self.make_window(doc) File "blobedit.py", line 40, in make_window cursor = self.blob_cursor) File "C:\Python26\lib\site-packages\GUI\Win32\ScrollableViews.py", line 32, in __init__ GScrollableView.__init__(self, _win = win) win32ui.error: The object has been destroyed. class ScrollableView(GScrollableView): _line_scroll_amount = default_line_scroll_amount def __init__(self, **kwds): kwds.setdefault('extent', default_extent) win = ui.CreateView(win_dummy_doc) win.CreateWindow(win_none, 0, win_style, (0, 0, 100, 100)) GScrollableView.__init__(self, _win = win) self.set(**kwds) def get_hscrolling(self): ( both from commandline and inside PythonwinIDE ) =========== Maybe it has also to do with the following serious bugs (which can be worked around - but smelling): B) a oneliner with just "import wx" crashes hard with F5 in Pythonwin IDE build 214/py2.6 - but not in build 212 (ntdll.dll) AppName: pythonwin.exe AppVer: 2.6.214.0 ModName: ntdll.dll ModVer: 5.1.2600.3520 Offset: 00044872 Code: 0xc015000f Address: 0x7c954872 (wxpython 2.8.11.0 (msw-unicode)) Only after this patch below (passing the SendMessage by a direct python call) it works again. (But with importing this oneliner file with Ctrl-I the IDE still crashes the same.) --- scintilla/bindings.py Sun Jan 04 15:01:18 2009 +++ scintilla/bindings.py Tue Oct 19 18:53:49 2010 @@ -33,7 +33,11 @@ def __init__(self, cmd): self.cmd = cmd def __call__(self, *args): - win32ui.GetMainFrame().SendMessage(win32con.WM_COMMAND, self.cmd) + # F5-run on simple "import wx" (wx2.8.11.0 (msw-unicode)) crashed in ntdll.dll: + ##win32ui.GetMainFrame().SendMessage(win32con.WM_COMMAND, self.cmd) + win32ui.GetMainFrame().OnCommand(self.cmd, 0) + #note: Ctrl-I/import still crashes because of WM_COMMAND in the line + C) all standalone win32ui GUI apps here crash hard with py2.3/pywin32-build214 at the very end/exit when they are executed from commandline "python somewin32uiapp.py". not with 212 and before. (they may crash as well as .pyw / win-apps - or even PythonWin.exe may crash at the end but nobody sees without a shell win) It seems, rude C-level leaks went into win32ui during 212 -> 214 - maybe because of the rework for py3k. Or is it all about one leak? 214 ui is hardly usable anywhere with various python versions - most practical use cases in and around win32ui become questionable. Yet there was no update for long time. I wonder that there are not many pywin32 bug reports in that direction. I only found : bug #2846720 (similar to C) ) and #2908939 perhaps. (->comments by M. Hammond, but no solution found) #3013558 Any ideas? Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: x.py Type: text/x-python Size: 10 bytes Desc: not available URL: From rupole at hotmail.com Thu Oct 21 03:02:49 2010 From: rupole at hotmail.com (Roger Upole) Date: Wed, 20 Oct 2010 21:02:49 -0400 Subject: [Pygui] PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems References: Message-ID: "Robert" wrote in message news:i9kmoi$clm$1 at dough.gmane.org... > A) > > What could be the cause for this exception of PyGUI with > pywin32-build214 - but not with build 212 :? > > Traceback (most recent call last): > File "blobedit.py", line 131, in > BlobApp().run() > File "C:\Python26\lib\site-packages\GUI\GenericGApplications.py", line > 122, in run > self.process_args(sys.argv[1:]) > File "C:\Python26\lib\site-packages\GUI\Generic\GApplications.py", line > 251, in process_args > self.open_app() > File "blobedit.py", line 32, in open_app > self.new_cmd() > File "C:\Python26\lib\site-packages\GUI\Generic\GApplications.py", line > 219, in new_cmd > self.make_window(doc) > File "blobedit.py", line 40, in make_window > cursor = self.blob_cursor) > File "C:\Python26\lib\site-packages\GUI\Win32\ScrollableViews.py", line > 32, in __init__ > GScrollableView.__init__(self, _win = win) > win32ui.error: The object has been destroyed. > > > > > class ScrollableView(GScrollableView): > > _line_scroll_amount = default_line_scroll_amount > > def __init__(self, **kwds): > kwds.setdefault('extent', default_extent) > win = ui.CreateView(win_dummy_doc) > win.CreateWindow(win_none, 0, win_style, (0, 0, 100, 100)) > GScrollableView.__init__(self, _win = win) > self.set(**kwds) > > def get_hscrolling(self): > > > > ( both from commandline and inside PythonwinIDE ) > The problem stems from these 2 lines in ScrollableViews.py: rev = ui.CreateRichEditView() win_dummy_doc = rev.GetDocument() The win32ui framework really should not allow a view to be created without a valid document. In win32view.cpp, there's a C++ class that allows some protected members of an MFC class to be set which makes this possible. Essentially this is a hack on top of a hack, and I'm not sure why it ever worked. A while back I thought I had a solution to allow it to work again, but it only caused unpredictable results and crashes further down the road. The PyGUI framework can probably create a valid MFC document to use as a dummy with a little work. Something like: dt=win32ui.CreateDocTemplate(win32ui.IDR_PYTHONTYPE) win_dummy_doc=dt.DoCreateDoc() may do the trick. Also, the win32ui framework needs to disallow the current behaviour altogether. I think it was originally allowed because it was attempting to instantiate MFC objects in the wrong order. > B) a oneliner with just "import wx" crashes hard with F5 in Pythonwin IDE > build 214/py2.6 - but not in build 212 (ntdll.dll) > > AppName: pythonwin.exe AppVer: 2.6.214.0 ModName: ntdll.dll > ModVer: 5.1.2600.3520 Offset: 00044872 > Code: 0xc015000f > Address: 0x7c954872 > (wxpython 2.8.11.0 (msw-unicode)) > > Only after this patch below (passing the SendMessage by a direct python > call) it works again. (But with importing this oneliner file with Ctrl-I > the IDE still > crashes the same.) > > --- scintilla/bindings.py Sun Jan 04 15:01:18 2009 > +++ scintilla/bindings.py Tue Oct 19 18:53:49 2010 > @@ -33,7 +33,11 @@ > def __init__(self, cmd): > self.cmd = cmd > def __call__(self, *args): > - win32ui.GetMainFrame().SendMessage(win32con.WM_COMMAND, self.cmd) > + # F5-run on simple "import wx" (wx2.8.11.0 (msw-unicode)) crashed in > ntdll.dll: > + ##win32ui.GetMainFrame().SendMessage(win32con.WM_COMMAND, self.cmd) > + win32ui.GetMainFrame().OnCommand(self.cmd, 0) > + #note: Ctrl-I/import still crashes because of WM_COMMAND in the line > + Trying to run one GUI framework inside of another is a sure recipe for disaster. Both will be trying to process messages, with race conditions and memory conflicts galore. The short answer is "don't do that". > C) all standalone win32ui GUI apps here crash hard with > py2.3/pywin32-build214 at the very end/exit when they are executed from > commandline "python > somewin32uiapp.py". not with 212 and before. (they may crash as well as > .pyw / win-apps - or even PythonWin.exe may crash at the end but nobody > sees without a > shell win) > Can you post a small script that exhibits this ? Roger From greg.ewing at canterbury.ac.nz Fri Oct 22 04:33:08 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 22 Oct 2010 15:33:08 +1300 Subject: [Pygui] [python-win32] and PyGUI notes - Re: PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems In-Reply-To: References: <4CBFA5E9.7090100@canterbury.ac.nz> Message-ID: <4CC0F7E4.20904@canterbury.ac.nz> On 22/10/10 01:47, Robert wrote: > But perhaps long time and debugging to get real world usability (Win). > One could use the (bugfixed) existing behaviour, plus __getattr__ on the > ._win Component member etc for first and hope for platform independent > behavior later (some 90%+x auto-translate code). I don't understand what you're talking about here. > py2exe and cxfreeze don't find the PyGUI autoloader stuff, one has to > collect&pull some 80+ paths by extra function. Yes, that's a bit of a problem. For apps intended to be py2exe'd, it might be better to explicitly import things from the relevant submodules, e.g. 'from GUI.Windows import Window' rather than from 'GUI import Window'. That way, py2exe will be able to find the modules that you use, together with the ones they depend on. > will try and go into it a little more. > > Further notes so far: currently no pythonic speedy late import is done > for expensive stuff throughout the library to exploit the dynamic > binding (like e.g. done in above .patch in GetDummyDoc). I'm not sure if that helps much. If you're using ScrollableViews in your application at all, you're going to need a dummy doc template at some point, so you might as well get the overhead out of the way early on. This might be a difference in philosophy -- it annoys me when an application pauses randomly during its operation to load stuff up, so I tend to design things so that everything that is almost certain to be used is imported at startup. If you have an application that only rarely uses ScrollableViews, you can deal with that by delaying your import of the ScrollableView class until you need it. > A simple app > pre-imports almost the whole mess, 80+ GUI mods plus pywin fully 1:1, I'm not sure if there's much that can be done about that. There's quite a lot of infrastructure shared by all component classes, and the intertwinedness of the generic and platform-specific code requires splitting it into quite a lot of modules. Maybe the code could be pre-processed to fold things together into larger modules for installation, although I'm not sure how much that would help -- the total amount of code loaded would be the same. > (the __init__.py autoloader thus doesn't save a lot) The purpose of the autoloader isn't so much to delay importing as to avoid importing things that won't be used at all. Currently the amount of optional stuff is a relatively small proportion of the whole, but that will change as more features are added. > No one should write a new > GUI-lib which does not use AbcDef for method names. We have another philosophical difference, then, because I believe that no-one should write a Python library that doesn't follow PEP 8 conventions, unless it's exposing a pre-existing API. > The menus seem to be a litte too automatic, Yes, I know, and I'm thinking about ways to make it easier to customise them. > The string style constants/events etc. ... may disapear without trace if > a letter is typed wrong I acknowledge that more could be done to validate these. > (difficult for auto-completers, pychecker, ...). Yeah... I just like them better than named constants, somehow. I think it's because they're automatically context-sensitive, so it avoids the need to give them unique prefixes. I don't use auto-completion, so that aspect of it didn't occur to me. Perhaps I could compromise by providing named constants for them as an alternative. > Didn't come to the new auto layout features (like wx / glade) so far .. PyGUI does have auto layout features, it's just that they don't work quite the same way as they do in wx or gtk. There's an assumption that you will be laying things out once when you create the window, and after that it's just a matter of moving and resizing things sensibly when the user changes the window size. I'm thinking about ways to make more dynamic layouts possible, but there are some tricky aspects to it, such as the possibility of infinite loops occurring if layout changes can propagate both up and down the hierarchy. -- Greg From amorris at mistermorris.com Tue Oct 26 16:00:30 2010 From: amorris at mistermorris.com (Adam Morris) Date: Tue, 26 Oct 2010 21:00:30 +0700 Subject: [Pygui] responding to applescript events? Message-ID: Hello all, I was thinking of writing a python-based program that would respond to applescripts, beyond the open and quit commands. Does anybody know what I would have to do to get that sort of support working in PyGUI? I'm only interested in developing for the Mac, obviously. -Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.holland at gmail.com Fri Oct 29 03:56:00 2010 From: alex.holland at gmail.com (Alex Holland) Date: Fri, 29 Oct 2010 14:56:00 +1300 Subject: [Pygui] Font Sizes on Windows XP + Standard Colour Suggestion Message-ID: <474B87FCA5D446D6BC91BD049AADB6C3@gmail.com> Hi,Just kicking the tyres of PyGUI with a view for using it for rapid GUI development/testing work. Greg, love the work you've done so far - a real breeze to learn, and well documented to boot.I noticed the system font on Windows XP looked too small, so had a poke around in the sources. I see it's theoretically 8pt Tahoma, but comparing it to renderings in WordPad, it seems to be 7pt.Editing GUI\Win32\StdFonts.py to change the input to _win_pts_to_pixels 10, rather than 8, seems to produce correct 8pt Tahoma. I've not experimented in depth, but this +2 point fudge-factor seemed correct for 10pt and 12pt text too. The DPI maths in there look correct, so I'm not sure what's causing this.I'm running Windows XP at 96 DPI in VMWare Fusion.?However, this might be VMWare weirdness - can anyone with a windows desktop replicate this?Could I also suggest adding Windows XP's not-quite-grey to the standard colour library? I make the RGB values (0.93, 0.91, 0.85) - this matches the background that appears around RadioButtons on Win32.Cheers,Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: