From: Daniel F <nan...@gm...> - 2009-07-06 23:18:41
|
Hello all! Since it appears that the project is a little dead, I have created a fork of the codebase, and hosted the git repository for it on github. Here's the link: http://github.com/nanotube/pmw_fixes/tree For now, the only thing I've done is commit a fix for the "regsub" module problem bundlepmw.py. Everyone who's interested and up for it is welcome to drop by the github repo, start his own fork on github, and commit whatever fixes you want - and i'll be sure to merge your things into the trunk. You are in particular invited to fix any issues from the bug tracker ( https://sourceforge.net/tracker/?group_id=10743&atid=110743 ), but any code improvements would probably be a welcome addition to the Pmw user community. If there's enough interest in this, I'll start sourceforge project for this. For now, you can leave your comments in this thread, or on the comments page on the github wiki for the project, here: http://wiki.github.com/nanotube/pmw_fixes/discussioncomments |
From: Friedrich R. <fri...@gm...> - 2009-07-07 18:57:30
|
Hello! It would be great to make Pmw working with modern :-) py2exe and py2app. At the moment, one needs quite many tweaks to overcome the restrictions of the bundling of the packages into library.zip (py2exe) and to get Pmw.def included (py2exe). To use Pmw with this, one has to disable the library.zip (py2exe) or has to write a recipe (py2app). Most users are not able to do this, I'm afraid. It blows up the archive a lot (py2exe) resp. a bit (py2app). I think a way to overcome the path-related stuff and to keep the auto-search function would be to either replace the whole package on installation or to replace only __init__.py on installation. For the second case, it would be possible to do something like versions = [(0,1,2),(0,1,3)] for version in versions: try: ...import code... except: pass An update would replace only the line "versions = ..." But when we are going to replace something on installation it would make more sense for me to simply replace the __init__.py by something straightforward and non-magic like from Pmw_1_2 import * This is easier to understand, easier to fix, less error prone and easier to configure even by Python newbies. The Pmw.def could be replaced by a simple Config.py defining the needed constants. What do you think about this? When I get some time, I will try to dive into Pmw to get this working. I think Pmw is quite dead because it's in functionality quite mature. It's a great concept of hull_border='sunken' etc. and I think most users simply use it and have no need to contribute any patches, except at least two people on the world who want to freeze their Python app ... Wishing you the best, Friedrich |
From: Charles س. D. <dou...@ll...> - 2009-07-07 19:05:37
|
While we're at requests, it would be great t simply get it to work with Python 2.6 C. On Jul 7, 2009, at 11:57 AM, Friedrich Romstedt wrote: > Hello! > > It would be great to make Pmw working with modern :-) py2exe and > py2app. At the moment, one needs quite many tweaks to overcome the > restrictions of the bundling of the packages into library.zip (py2exe) > and to get Pmw.def included (py2exe). To use Pmw with this, one has to > disable the library.zip (py2exe) or has to write a recipe (py2app). > Most users are not able to do this, I'm afraid. It blows up the > archive a lot (py2exe) resp. a bit (py2app). > > I think a way to overcome the path-related stuff and to keep the > auto-search function would be to either replace the whole package on > installation or to replace only __init__.py on installation. For the > second case, it would be possible to do something like > > versions = [(0,1,2),(0,1,3)] > > for version in versions: > try: > ...import code... > except: > pass > > An update would replace only the line "versions = ..." > But when we are going to replace something on installation it would > make more sense for me to simply replace the __init__.py by something > straightforward and non-magic like > > from Pmw_1_2 import * > > This is easier to understand, easier to fix, less error prone and > easier to configure even by Python newbies. > > The Pmw.def could be replaced by a simple Config.py defining the > needed constants. > > What do you think about this? > > When I get some time, I will try to dive into Pmw to get this working. > > I think Pmw is quite dead because it's in functionality quite mature. > It's a great concept of hull_border='sunken' etc. and I think most > users simply use it and have no need to contribute any patches, except > at least two people on the world who want to freeze their Python app > ... > > Wishing you the best, > Friedrich > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited > time, > vendors submitting new applications to BlackBerry App World(TM) will > have > the opportunity to enter the BlackBerry Developer Challenge. See > full prize > details at: http://*p.sf.net/sfu/blackberry > _______________________________________________ > Pmw-general mailing list > Pmw...@li... > https://*lists.sourceforge.net/lists/listinfo/pmw-general > |
From: Daniel F <nan...@gm...> - 2009-07-07 20:32:07
|
Hi guys, thanks for your interest and support! :) Friedrich: Indeed, I myself am planning on trying to freeze my app with py2exe over the summer, and will certainly look into the whole thing, if you don't do it first. I only recently started using pmw (couple of weeks), so I don't know much about it, but it seems to me that we could do away entirely with the "dynamic loader" bit. I see nothing wrong with doing "from Pmw.PmwComboBox import ComboBox", and then using 'ComboBox' in the code, or doing "from Pmw import PmwComboBox" and then using "PmwComboBox.ComboBox" in the code. That would remove an unnecessary level of complexity. According to the description of the purposes of the dynamic loader, here: http://pmw.sourceforge.net/doc/dynamicloader.html , the "three purposes" of the loader are (1), to allow the usage of classes directly from Pmw (as in, Pmw.ComboBox), which I think is not important, as per the paragraph above, (2), delay imports until they are needed - that is taken care of by explicitly importing only what you need - a practice that people should be following anyway, and which is not nearly as important now as it was when Pmw was first written, and (3) to allow easy version checking of Pmw - which i think is not at all important, given how static the code is now that it is mature. Finally, the usage of Pmw.ClassName directly can probably be achieved with some playing around with __all__ and whatnot, so that we can keep basic backwards compatibility with existing code (certainly a big priority). I invite all comments about this, it's important to discuss this in detail before jumping into it... Charles: I just fixed a bug with the optionmenu.setitems which affected the usage of combobox on python 2.6.I didn't notice anything else reported in the bug tracker or mailing lists regarding python 2.6 compatibility, and things seem to work fine with python2.6 generally speaking. What other incompatibilities are there that prevent the use of Pmw with python 2.6? Please feel free to post bug reports in the pmw bug tracker about them, and we can all work together to fix. :) Glad to have you guys with me - let's get this party started. :) Daniel 2009/7/7 Charles سمير Doutriaux <dou...@ll...>: > While we're at requests, it would be great t simply get it to work with > Python 2.6 > > C. > > On Jul 7, 2009, at 11:57 AM, Friedrich Romstedt wrote: > >> Hello! >> >> It would be great to make Pmw working with modern :-) py2exe and >> py2app. At the moment, one needs quite many tweaks to overcome the >> restrictions of the bundling of the packages into library.zip (py2exe) >> and to get Pmw.def included (py2exe). To use Pmw with this, one has to >> disable the library.zip (py2exe) or has to write a recipe (py2app). >> Most users are not able to do this, I'm afraid. It blows up the >> archive a lot (py2exe) resp. a bit (py2app). >> >> I think a way to overcome the path-related stuff and to keep the >> auto-search function would be to either replace the whole package on >> installation or to replace only __init__.py on installation. For the >> second case, it would be possible to do something like >> >> versions = [(0,1,2),(0,1,3)] >> >> for version in versions: >> try: >> ...import code... >> except: >> pass >> >> An update would replace only the line "versions = ..." >> But when we are going to replace something on installation it would >> make more sense for me to simply replace the __init__.py by something >> straightforward and non-magic like >> >> from Pmw_1_2 import * >> >> This is easier to understand, easier to fix, less error prone and >> easier to configure even by Python newbies. >> >> The Pmw.def could be replaced by a simple Config.py defining the >> needed constants. >> >> What do you think about this? >> >> When I get some time, I will try to dive into Pmw to get this working. >> >> I think Pmw is quite dead because it's in functionality quite mature. >> It's a great concept of hull_border='sunken' etc. and I think most >> users simply use it and have no need to contribute any patches, except >> at least two people on the world who want to freeze their Python app >> ... >> >> Wishing you the best, >> Friedrich >> >> >> ------------------------------------------------------------------------------ >> Enter the BlackBerry Developer Challenge >> This is your chance to win up to $100,000 in prizes! For a limited time, >> vendors submitting new applications to BlackBerry App World(TM) will have >> the opportunity to enter the BlackBerry Developer Challenge. See full >> prize >> details at: http://*p.sf.net/sfu/blackberry >> _______________________________________________ >> Pmw-general mailing list >> Pmw...@li... >> https://*lists.sourceforge.net/lists/listinfo/pmw-general >> > > |
From: Chris F. <cf...@th...> - 2009-07-07 21:16:50
|
Something I've long wished for is a toolkit agnostic core. The MegaArchetype class still depends on Tkinter, if indirectly. I think the component model Pmw uses would be useful for other toolkits, or even for class heirarchies that have nothing to do with user interfaces. But I haven't taken the time to learn Pmw internals. Maybe I will, if this sounds like a good idea to people. It seems as though it would be pretty simple to do, but I fear the unanticipated pitfall that awaits those who meddle around in code they don't understand :) Chris |
From: Peter M. <Pe...@re...> - 2009-07-07 22:18:55
|
I don't think you are correct here Chris, Pmw widgets are intimately bound with Tkinter at all levels - not just at the MegaArchetype level i.e. a brief flick through the code for Pmw.RadioSelect found references to Tkinter Frame, Button, Radiobutton, Checkbutton etc etc Not to mention all the options that are inherited/used from each of those Tkinter objects (which you can directly access via your Pmw widget i.e. the entry field width of the Tkinter Entry widget that is used in Pmw.EntryField). I think Pmw is wonderful and have been using it for some considerable time now (since at least Python 2.1) but abstracting it to cater for other toolkits would not be a practical exercise at all :-) Peter -----Original Message----- From: Chris Fuller [mailto:cf...@th...] Sent: Wednesday, 8 July 2009 7:01 AM To: pmw...@li... Subject: Re: [Pmw-general] new pmw git repository now up on github.com Something I've long wished for is a toolkit agnostic core. The MegaArchetype class still depends on Tkinter, if indirectly. I think the component model Pmw uses would be useful for other toolkits, or even for class heirarchies that have nothing to do with user interfaces. But I haven't taken the time to learn Pmw internals. Maybe I will, if this sounds like a good idea to people. It seems as though it would be pretty simple to do, but I fear the unanticipated pitfall that awaits those who meddle around in code they don't understand :) Chris ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Pmw-general mailing list Pmw...@li... https://lists.sourceforge.net/lists/listinfo/pmw-general Warning: Copyright ResMed. Where the contents of this email and/or attachment includes materials prepared by ResMed, the use of those materials is subject exclusively to the conditions of engagement between ResMed and the intended recipient. This communication is confidential and may contain legally privileged information. By the use of email over the Internet or other communication systems, ResMed is not waiving either confidentiality of, or legal privilege in,the content of the email and of any attachments. If the recipient of this message is not the intended addressee, please call ResMed immediately on +61 2 8884 1000 Sydney, Australia. |
From: Daniel F <nan...@gm...> - 2009-07-08 11:32:44
|
On 7/7/09, Chris Fuller <cf...@th...> wrote: > > Something I've long wished for is a toolkit agnostic core. The > MegaArchetype > class still depends on Tkinter, if indirectly. I think the component model > Pmw uses would be useful for other toolkits, or even for class heirarchies > that have nothing to do with user interfaces. > > But I haven't taken the time to learn Pmw internals. Maybe I will, if this > sounds like a good idea to people. It seems as though it would be pretty > simple to do, but I fear the unanticipated pitfall that awaits those who > meddle around in code they don't understand :) Nice idea, but Peter Milliken is right, pmw is tkinter through and through, it wouldn't make much sense to try to make it a multi-toolkit toolkit like wxwidgets. Nice idea, though :) |
From: David M. <da...@re...> - 2009-07-07 23:28:12
|
On Tue, 2009-07-07 at 12:05 -0700, Charles سمير Doutriaux wrote: > While we're at requests, it would be great t simply get it to work > with Python 2.6 WTF? PMW doesn't work with py2.6?!? That's just WRONG! What is it about Py2.6 that breaks PMW? Or what's broken in PMW that can't handle Python upgrades? PMW has been such a promising widget framework. Would be a damn shame if it dies. Especially since PMW-based python apps take less than half the time and memory to load up compared to wx-based python apps. Cheers David |
From: Daniel F <nan...@gm...> - 2009-07-08 05:00:42
|
On 7/7/09, David McNab <da...@re...> wrote: > On Tue, 2009-07-07 at 12:05 -0700, Charles سمير Doutriaux wrote: >> While we're at requests, it would be great t simply get it to work >> with Python 2.6 > > WTF? PMW doesn't work with py2.6?!? That's just WRONG! What is it about > Py2.6 that breaks PMW? Or what's broken in PMW that can't handle Python > upgrades? > > PMW has been such a promising widget framework. Would be a damn shame if > it dies. Especially since PMW-based python apps take less than half the > time and memory to load up compared to wx-based python apps. > Don't worry, pmw does work with python 2.6. :) I did just fix a bug in my github repo specific to python 2.6 in the combobox widget, but besides that, it seems to work just fine. I mentioned that in my previous email, but I guess after my long-winded talk about the dynamic loader, nobody got to the end where I responded to the python 2.6 compatibility question ;) |
From: Peter M. <Pe...@re...> - 2009-07-08 05:52:08
|
No need to worry, I assume the reference/request was for py2exe to work with Pmw and Python 2.6. Hope I got that right? Because I had the same initial response as David... :-) Certainly Pmw works with Python 2.6 (I have just finished writing a GUI using Pmw and 2.6), so that can't be the meaning/interpretation of the sentence :-) Peter -----Original Message----- From: David McNab [mailto:da...@re...] Sent: Wednesday, 8 July 2009 8:45 AM To: Charles سمير Doutriaux Cc: Daniel F; pmw...@li... Subject: Re: [Pmw-general] new pmw git repository now up on github.com On Tue, 2009-07-07 at 12:05 -0700, Charles سمير Doutriaux wrote: > While we're at requests, it would be great t simply get it to work > with Python 2.6 WTF? PMW doesn't work with py2.6?!? That's just WRONG! What is it about Py2.6 that breaks PMW? Or what's broken in PMW that can't handle Python upgrades? PMW has been such a promising widget framework. Would be a damn shame if it dies. Especially since PMW-based python apps take less than half the time and memory to load up compared to wx-based python apps. Cheers David ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Pmw-general mailing list Pmw...@li... https://lists.sourceforge.net/lists/listinfo/pmw-general Warning: Copyright ResMed. Where the contents of this email and/or attachment includes materials prepared by ResMed, the use of those materials is subject exclusively to the conditions of engagement between ResMed and the intended recipient. This communication is confidential and may contain legally privileged information. By the use of email over the Internet or other communication systems, ResMed is not waiving either confidentiality of, or legal privilege in,the content of the email and of any attachments. If the recipient of this message is not the intended addressee, please call ResMed immediately on +61 2 8884 1000 Sydney, Australia. |
From: Daniel F <nan...@gm...> - 2009-07-09 04:03:49
|
Hi Friedrich, Getting this back on-list, because I think it's important to keep this discussion open and encourage others to join in and provide input. :) >> but it seems to me that we could do away entirely with >> the "dynamic loader" bit. I see nothing wrong with doing "from >> Pmw.PmwComboBox import ComboBox", and then using 'ComboBox' in the >> code, or doing "from Pmw import PmwComboBox" and then using >> "PmwComboBox.ComboBox" in the code. That would remove an unnecessary >> level of complexity. > Exactly, I agree. My imagination was, to import anything statically on > startup. But maybe this would make things to slow. So I agree with you > to do it like this. It's straightforward, nevertheless it's not very > typing-saving and not very elegant. Maybe we can do it like this: > Pmw.__init__.py offers a method, which does the import task via the > following code: > > def whatsoever_import(): > import Pmw.PmwComboBox > Pmw.PmwComboBox = Pmw.PmwComboBox.ComboBox I think it would be even simpler to do, inside Pmw/__init__.py something like this: from PmwComboBox import ComboBox from PmwDialogBox import DialogBox etc... that way, after you "import Pmw", all the classes will be directly available as "Pmw.ComboBox", etc. In other words, just like now, only without all the fancy loader bit. Nowadays, you really aren't saving any appreciable amount of time or ram by not importing a few dozen classes. I mean, what are we talking about here, an extra half a megabyte of ram tops, for importing everything instead of dynamically loading? Peanuts. > It's still simple and a little more elegant, thought little hacky too, > but not that much as the Loader is at the moment. Maybe we can > incorporate this idea into an quite abstract loader class, which would > be a Pmw-independent dynload module. It just should do on __getattr__ > call try to find and import the given module. If the loaded thing is a > module, it should be wrapped again into such an dynamic loader, and > the process will continue automatically without any path search. I > find the built-in imp module very promising. Since this is built-in, > it's to assume that it works also with .zip archives in py2exe, but I > will check this. > > I think, you can enroll me for this task, since it will be also useful > for my own projects. I think it's feasible will less that 300 LOC. Interesting idea - i'm not familiar with the details of the imp module, but I'll take a look, too. :) >> According to the description of the purposes of the dynamic loader, >> here: http://pmw.sourceforge.net/doc/dynamicloader.html , the "three >> purposes" of the loader are (1), to allow the usage of classes >> directly from Pmw (as in, Pmw.ComboBox), which I think is not >> important, as per the paragraph above, (2), delay imports until they >> are needed - that is taken care of by explicitly importing only what >> you need - a practice that people should be following anyway, and >> which is not nearly as important now as it was when Pmw was first >> written, and (3) to allow easy version checking of Pmw - which i think >> is not at all important, given how static the code is now that it is >> mature. > I think the first point IS important, I also sticked long time to the > practice to force the user to say import enumber.enumber2 and then > en=enumber.enumber.ENumber() because there was also enumber.statistics > and so on. But this is really a lot of typing efford, and it's so > convenient to have then directly available. But the problem was so > far, that some quite big numeric modules have to be loaded on startup, > slowing down the whole thing. > > The second point is merely an implication of the first one because of > implmentation details. > > I agree, taht the third point is completely unnecessary, modules _have > to be_ backward compatible, otherwise it's better to start with Pmw2 > 0.1.0b. yea, saving typing is nice - but i think it's even more important /at this point/, to maintain perfect backward compatibility, so that all the existing code that uses Pmw can use the "new" Pmw which has no dynamic loader (or a different implementation thereof, as per your idea above), without any changes. >> Finally, the usage of Pmw.ClassName directly can probably be achieved >> with some playing around with __all__ and whatnot, so that we can keep >> basic backwards compatibility with existing code (certainly a big >> priority). > For the fist time, it's our major task to make Pmw py2sth compatible, > i.e. to keep it backward compatible. This btw implicates that we have > to keep the dynload since it's the only way to keep compatibilty while > not slowing it down. But let's try it out, how much time importing > anything on startup really needs. I have always my modules with numpy > etc. in mind, here it's only Tkinter, which is needed anyway. > Nevertheless, I'm courius about a new and less hacky dynload module... I'll try to quickly throw together the "import everything" __init__.py, and see how much time it takes. my guess is, nothing that you'd notice. >> Glad to have you guys with me - let's get this party started. :) > Oh yes! > > I have to say, that the creator of Pmw does not match my programming > style very precicely. But I will try to understand and not to mess up > the code. Well... we'll just try to follow PEP8 when we can, and go from there. :) > P.S.: Since we go into details now, I thought it's better to not write > to the mailing list any longer. When we have results in our > discussion, we can send them, but for the majority this will be > propably not of such big interest. See my reasoning above. I think on the contrary it is very important to keep the discussions at this initial stage public, to involve as many people and opinions as possible. I think anyone who's signed up for the pmw-general list is probably at least somewhat interested in the goings on, so it's not like we're spamming some unrelated mailing list. I'm about to try freezing my project which I just recently ported to Pmw, with py2exe. will see how that goes. :) Look forward to further comments, from you, and anyone else. :) |
From: Friedrich R. <fri...@gm...> - 2009-07-09 22:11:38
|
Hi Daniel, > I think it would be even simpler to do, inside Pmw/__init__.py > something like this: > from PmwComboBox import ComboBox > from PmwDialogBox import DialogBox > etc... Yes, I agree fully that probably noone needs a dynloader, but I'm just curious about it... > Interesting idea [imp dynload] - i'm not familiar with the details of the imp > module, but I'll take a look, too. :) Exactly, it's just a fascinating problem to be solved. It may be of use for more projects than Pmw only. > [...] i think it's even more important /at > this point/, to maintain perfect backward compatibility, so that all > the existing code that uses Pmw can use the "new" Pmw which has no > dynamic loader (or a different implementation thereof, as per your > idea above), without any changes. We agree here completely. >> I have to say, that the creator of Pmw does not match my programming >> style very precicely. But I will try to understand and not to mess up >> the code. > Well... we'll just try to follow PEP8 when we can, and go from there. :) No, what I mean is the extensive use of magic arrays, and things like that, which I try to avoid by using clear and general concepts. I got this impression from PmwBase.py alone. Nevertheless PEP8 is quite good. I didn't know about it up to now, but it matches my programming style, except for that I'm not using spaces in assignments and around operators. |
From: Daniel F <nan...@gm...> - 2009-07-09 04:09:21
|
> I do not agree, I think it's a great idea to write an abstract > framework for using the a_b=sth stuff. But I think it's a point for > Pmw2. [snip] Well, i think the thing is that Pmw allows the passthrough of tkinter config to the underlying tkinter base widgets (like label width and color e.g., for the Balloon widget). You'd essentially have to wrap all of that, and check what's allowed depending on which underlying toolkit you use, and it would be a pain to do. And besides, I think it would simply be a reimplementation of wxwidgets. That said, I'm always open to more discussion, and further, seeing as how I just recently started with Pmw, I am also open to the idea that I don't know what I'm talking about. :) P.S., taking this back on the list, for the same reasons as before. :) |
From: Daniel F <nan...@gm...> - 2009-07-09 04:48:47
|
> I'm about to try freezing my project which I just recently ported to > Pmw, with py2exe. will see how that goes. :) Well, I had total success freezing my app with Pmw using py2exe. First, I used the "bundlepmw.py" script (the latest one, with the modification to use re instead of regsub), to bundle Pmw (with "-noblt" option since I am not using blt). In my project's directory, I created a directory Pmw, and stuck the Pmw.py file created by bundlepmw into that directory, and also took PmwColor.py from Pmw/lib, and stuck it into that directory (since i'm using color). Inside that Pmw directory, I also created a file "__init__.py", which had the following content, of one line: from Pmw import * The above steps (with the directory and all), could probably be avoided and i could have just used Pmw.py and PmwColor.py directly... but it seemed neater that way, to separate the Pmw files from the rest of my project's source code files. Finally, I ran my "python setup.py py2exe" script (which was created as usual, following py2exe standard guidelines), and everything built and worked like a charm. So... what that says to me is that there's not a pressing need to do anything about the dynamic loader. Feedback and comments are welcome. |
From: Daniel F <nan...@gm...> - 2009-07-09 05:03:40
|
> In my project's directory, I created a directory Pmw, and stuck the > Pmw.py file created by bundlepmw into that directory, and also took > PmwColor.py from Pmw/lib, and stuck it into that directory (since i'm > using color). Inside that Pmw directory, I also created a file > "__init__.py", which had the following content, of one line: > from Pmw import * > > The above steps (with the directory and all), could probably be > avoided and i could have just used Pmw.py and PmwColor.py directly... > but it seemed neater that way, to separate the Pmw files from the rest > of my project's source code files. Indeed, I just tested, and placing Pmw.py and PmwColor.py directly into the project's source directory worked just fine, as well. So, if things seem to be working so well with py2exe, do we really need to do anything at all as far as the dynamic loader is concerned? Could we just let it be? |
From: Chris F. <cf...@th...> - 2009-07-09 05:05:08
|
On Wednesday 08 July 2009 23:09, Daniel F wrote: > > I do not agree, I think it's a great idea to write an abstract > > framework for using the a_b=sth stuff. But I think it's a point for > > Pmw2. [snip] > > Well, i think the thing is that Pmw allows the passthrough of tkinter > config to the underlying tkinter base widgets (like label width and > color e.g., for the Balloon widget). You'd essentially have to wrap > all of that, and check what's allowed depending on which underlying > toolkit you use, and it would be a pain to do. And besides, I think it > would simply be a reimplementation of wxwidgets. > > That said, I'm always open to more discussion, and further, seeing as > how I just recently started with Pmw, I am also open to the idea that > I don't know what I'm talking about. :) > > P.S., taking this back on the list, for the same reasons as before. :) I never said anything about wx. This could be useful for totally new class heirarchies, which could have a similar dictionary-type configuration as Tkinter from the get-go. For existing classes, a mixin class that does on the fly conversions would probably work out, as long as it doesn't intrude on an existing interface, and this one is uncommon enough. Another approach might be a "configuration filter" that you configure when creating the megawidget, which avoids the pitfalls of multiple inheritance, but would only work at initialization. Chris Fuller |
From: Friedrich R. <fri...@gm...> - 2009-07-09 22:23:58
|
Hi Daniel, (Freezing) > First, I used the "bundlepmw.py" script (the latest one, with the > modification to use re instead of regsub), to bundle Pmw (with > "-noblt" option since I am not using blt). Well, it's the first time I hear about the bundlepmw.py part of Pmw. Most Pmw users also didn't hear about it, it seems to me. Otherwise we would have had more instructive answers to the question "how to freeze my Pmw app" some time ago. Maybe we all didn't read the documentation intensive enough, though... Most users want to install Pmw, write import Pmw, and freeze their app. When there is a bundlepmw.py, this means to bypass the dynamic loader, and to do what we want to do. But I guess the task isn't that complicated, when just using the method you proposed. To introduce another point that reinforces the wish to restructure the module pathes of Pmw, is that Pmw (at least im Pmw 1.3, quite old?) is installed in a separate directory. It would be much more straightforward and better to maintain, when we would place it in site-packages/Pmw as all other site modules do. The way to use bundlepmw.py looks to me more like a dirty hack done by someone else for you. Friedrich |
From: Daniel F <nan...@gm...> - 2009-07-13 01:22:44
|
Hi Friedrich, Well, indeed, bundlepmw is a bit of a hack, but since it works so well, it certainly becomes a lot less of a priority to mess around with it. :) That said, it would be /nice/ to get things looking more straightforward - and getting rid of the Pmw_X_Y_Z subdirectory would probably be a good place to start, since Pmw versioning is just not that important these days, since it's very stable. On Thu, Jul 9, 2009 at 10:23 PM, Friedrich Romstedt<fri...@gm...> wrote: > Hi Daniel, > > (Freezing) > >> First, I used the "bundlepmw.py" script (the latest one, with the >> modification to use re instead of regsub), to bundle Pmw (with >> "-noblt" option since I am not using blt). > Well, it's the first time I hear about the bundlepmw.py part of Pmw. > Most Pmw users also didn't hear about it, it seems to me. Otherwise we > would have had more instructive answers to the question "how to freeze > my Pmw app" some time ago. Maybe we all didn't read the documentation > intensive enough, though... > > Most users want to install Pmw, write import Pmw, and freeze their app. > > When there is a bundlepmw.py, this means to bypass the dynamic loader, > and to do what we want to do. But I guess the task isn't that > complicated, when just using the method you proposed. > > To introduce another point that reinforces the wish to restructure the > module pathes of Pmw, is that Pmw (at least im Pmw 1.3, quite old?) is > installed in a separate directory. It would be much more > straightforward and better to maintain, when we would place it in > site-packages/Pmw as all other site modules do. The way to use > bundlepmw.py looks to me more like a dirty hack done by someone else > for you. > > Friedrich > |
From: Friedrich R. <fri...@gm...> - 2009-07-09 22:35:43
|
(Component configuration) >> > I do not agree, I think it's a great idea to write an abstract >> > framework for using the a_b=sth stuff. But I think it's a point for >> > Pmw2. [snip] >> Well, i think the thing is that Pmw allows the passthrough of tkinter >> config to the underlying tkinter base widgets (like label width and >> color e.g., for the Balloon widget). You'd essentially have to wrap >> all of that, and check what's allowed depending on which underlying >> toolkit you use, and it would be a pain to do. And besides, I think it >> would simply be a reimplementation of wxwidgets. >> >> That said, I'm always open to more discussion, and further, seeing as >> how I just recently started with Pmw, I am also open to the idea that >> I don't know what I'm talking about. :) > I never said anything about wx. This could be useful for totally new class > heirarchies, which could have a similar dictionary-type configuration as > Tkinter from the get-go. For existing classes, a mixin class that does on > the fly conversions would probably work out, as long as it doesn't intrude on > an existing interface, and this one is uncommon enough. Another approach > might be a "configuration filter" that you configure when creating the > megawidget, which avoids the pitfalls of multiple inheritance, but would only > work at initialization. My idea got a little more mature: The dictionary configuration scheme is adopted and no compatibilty with other systems than with Tkinter is aimed at. I thought this were clear, but now it's clearified definitely. When you write megawidget['component_background']='yellow' this will be translated by the magewidget into megawidget.get_component('component')['background']='yellow'. Obviously this is a recursive process, breaking down the a_b_c keyword into a and b_c, thus making it simple to code. When the component configured is a Tkinter.* instance, it will end up in configuring the Tkinter widget. All the megawidget has to do is to register its component in its component dictionary (or whatever structure used) on startup [or even later]. From this point on, one can use the ['a_b_c']=value syntax fully transparently from inside (self['a_b']='X') and from outside (magewidget['a_b']='X'). That's the outline of my model. It's clear that the concept is of much greater applicability for configuring anything, not only Tkinter mega widgets. That is the reason why I want to have it in a separate module, separate from Pmw. |
From: Daniel F <nan...@gm...> - 2009-07-13 01:24:43
|
> My idea got a little more mature: > > The dictionary configuration scheme is adopted and no compatibilty > with other systems than with Tkinter is aimed at. I thought this were > clear, but now it's clearified definitely. > > When you write megawidget['component_background']='yellow' this will > be translated by the magewidget into > megawidget.get_component('component')['background']='yellow'. > Obviously this is a recursive process, breaking down the a_b_c keyword > into a and b_c, thus making it simple to code. When the component > configured is a Tkinter.* instance, it will end up in configuring the > Tkinter widget. > > All the megawidget has to do is to register its component in its > component dictionary (or whatever structure used) on startup [or even > later]. From this point on, one can use the ['a_b_c']=value syntax > fully transparently from inside (self['a_b']='X') and from outside > (magewidget['a_b']='X'). > > That's the outline of my model. It's clear that the concept is of much > greater applicability for configuring anything, not only Tkinter mega > widgets. That is the reason why I want to have it in a separate > module, separate from Pmw. > Seems interesting... give it a whirl and see what you come up with, I'd be curious to see. Create a fork on github, it's very easy to do, and hack away. ;) |
From: Daniel F <nan...@gm...> - 2009-07-10 13:59:46
|
Hi Peter, All the files I have had reason to look at for reasons of bugfixing have had mixed indentation (ie, mixing tabs and spaces). So maybe they look weird in the browser? That said, I did correct the couple of lib files I changed for bugfixing purposes to consistently just use 4 spaces... but didn't do so for bundlepmw. I'll do that now and push it out to git. I'll note that bundlepmw worked just fine for me in its present form, too, so... you can not worry about that and just use it. Please do let me know if you see anything else that needs attention :) And let me know how your freeze goes. Thanks, Daniel On Fri, Jul 10, 2009 at 12:25 AM, Peter Milliken<Pe...@re...> wrote: > Hey Daniel - good work. > > I am just trying to "freeze" my latest GUI (I didn't even know Pmw had reached 1.3! :-) I am still using 1.2). > > Your entry into git has some indentation problems with the expandLinks() function. I am not using git, just looking at it with my browser and it looks like this: > > def expandLinks(path): > if not os.path.isabs(path): > path = os.path.join(os.getcwd(), path) > while 1: > if not os.path.islink(path): > break > dir = os.path.dirname(path) > path = os.path.join(dir, os.readlink(path)) > > return path > > Regards > Peter > > > > > -----Original Message----- > From: Daniel F [mailto:nan...@gm...] > Sent: Thursday, 9 July 2009 2:49 PM > To: Friedrich Romstedt > Cc: pmw...@li... > Subject: Re: [Pmw-general] new pmw git repository now up on github.com > >> I'm about to try freezing my project which I just recently ported to >> Pmw, with py2exe. will see how that goes. :) > > Well, I had total success freezing my app with Pmw using py2exe. > > First, I used the "bundlepmw.py" script (the latest one, with the > modification to use re instead of regsub), to bundle Pmw (with > "-noblt" option since I am not using blt). > > In my project's directory, I created a directory Pmw, and stuck the > Pmw.py file created by bundlepmw into that directory, and also took > PmwColor.py from Pmw/lib, and stuck it into that directory (since i'm > using color). Inside that Pmw directory, I also created a file > "__init__.py", which had the following content, of one line: > from Pmw import * > > The above steps (with the directory and all), could probably be > avoided and i could have just used Pmw.py and PmwColor.py directly... > but it seemed neater that way, to separate the Pmw files from the rest > of my project's source code files. > > Finally, I ran my "python setup.py py2exe" script (which was created > as usual, following py2exe standard guidelines), and everything built > and worked like a charm. > > So... what that says to me is that there's not a pressing need to do > anything about the dynamic loader. > > Feedback and comments are welcome. > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Pmw-general mailing list > Pmw...@li... > https://lists.sourceforge.net/lists/listinfo/pmw-general > > Warning: Copyright ResMed. Where the contents of this email and/or attachment includes materials prepared by ResMed, the use of those > materials is subject exclusively to the conditions of engagement between ResMed and the intended recipient. > > This communication is confidential and may contain legally privileged information. > By the use of email over the Internet or other communication systems, ResMed is not waiving either confidentiality of, or legal > privilege in,the content of the email and of any attachments. > If the recipient of this message is not the intended addressee, please call ResMed immediately on +61 2 8884 1000 Sydney, Australia. > > > > |
From: David M. <da...@re...> - 2009-07-10 23:28:42
|
On Fri, 2009-07-10 at 13:59 +0000, Daniel F wrote: > Hi Peter, > > All the files I have had reason to look at for reasons of bugfixing > have had mixed indentation (ie, mixing tabs and spaces) Ohh, the tortures I could dream up for those who use tabs in Python code. Why the presence of tabs outside of strings hasn't been deprecated completely escapes me. Tab should be a syntax error! Why can't people just learn to use 4 spaces? Cheers David |
From: Daniel F <nan...@gm...> - 2009-07-12 05:41:46
|
whoops, forgot to copy to list... ---------- Forwarded message ---------- From: Daniel F <nan...@gm...> Date: Sun, Jul 12, 2009 at 5:41 AM Subject: Re: [Pmw-general] new pmw git repository now up on github.com To: David McNab <da...@re...> On Fri, Jul 10, 2009 at 10:59 PM, David McNab<da...@re...> wrote: > Ohh, the tortures I could dream up for those who use tabs in Python > code. > > Why the presence of tabs outside of strings hasn't been deprecated > completely escapes me. Tab should be a syntax error! Why can't people > just learn to use 4 spaces? Heh well, the consistent use of either tabs or spaces is "ok" in my book, though I prefer the 4 space indent myself. It's when code mixes tabs and spaces in seemingly random way, and thus looks all out of wack in an editor, that's when I start having real issue with it. (as in the case of Pmw's code). But, fwiw, I have changed the indentation to be consistently 4 spaces per tab in my pmw git repository. At least in the lib and bin subdirectories. I haven't yet looked at tests, though from my running of them, they seem like they need to be updated for the modern python versions, since they expect slightly different exception text. |
From: Daniel F <nan...@gm...> - 2009-07-12 18:00:58
|
Hey, anyone else get a segmentation fault when running tests/Dialog_test.py? seems to happens during or after _createOtherToplevel, which is on line 35... |
From: Peter M. <Pe...@re...> - 2009-07-12 21:12:11
|
No, I don't get a segmentation fault, but I do get an apparent failure: wres12386#1(/c/Python26/Lib/site-packages/Pmw/Pmw_1_3/tests)$ python Dialog_test.py ==== function _bogus () ==== result was: <type 'exceptions.AttributeError'>: Dialog instance has no attribute 'bogus' <type 'str'> ---- result should have been: AttributeError: Dialog instance has no attribute 'bogus' <type 'str'> ---- FAILED Peter -----Original Message----- From: Daniel F [mailto:nan...@gm...] Sent: Monday, 13 July 2009 4:01 AM To: pmw...@li... Subject: Re: [Pmw-general] new pmw git repository now up on github.com Hey, anyone else get a segmentation fault when running tests/Dialog_test.py? seems to happens during or after _createOtherToplevel, which is on line 35... ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Pmw-general mailing list Pmw...@li... https://lists.sourceforge.net/lists/listinfo/pmw-general Warning: Copyright ResMed. Where the contents of this email and/or attachment includes materials prepared by ResMed, the use of those materials is subject exclusively to the conditions of engagement between ResMed and the intended recipient. This communication is confidential and may contain legally privileged information. By the use of email over the Internet or other communication systems, ResMed is not waiving either confidentiality of, or legal privilege in,the content of the email and of any attachments. If the recipient of this message is not the intended addressee, please call ResMed immediately on +61 2 8884 1000 Sydney, Australia. |