From dpwhittaker at gmail.com Thu Mar 1 05:46:20 2007 From: dpwhittaker at gmail.com (Progor) Date: Wed, 28 Feb 2007 20:46:20 -0800 (PST) Subject: [PythonCE] weird Tkinter In-Reply-To: <9239471.post@talk.nabble.com> References: <9173378.post@talk.nabble.com> <9178558.post@talk.nabble.com> <9185914.post@talk.nabble.com> <9197668.post@talk.nabble.com> <9204694.post@talk.nabble.com> <9239471.post@talk.nabble.com> Message-ID: <9243936.post@talk.nabble.com> Well, adding the paths didn't help, but I just went ahead and put import _tkinter in my libs.pth file and now my Tkinter programs work like everybody else's at least. Thanks for the pointer on .pth files. Bandung wrote: > > Here is a link explaining what *.pth files do. they are just text files > with path statements. Python reads them when it first loads and > effectively adds any path statements that it sees, into the PYTHONPATH > environment. Really cool for permitting you to type in just the file's > name rather than the whole path sttement when you wantto import a script > somewhere on your system. > > You can use them to import modules as well I think. for the most part, I > simply put path statements in them. > > > http://bob.pythonmac.org/archives/2005/02/06/using-pth-files-for-python-development/ > *.pth files > > If you want your gui to load faster. give your script a *.pyw extension. > But other than that, well, yes, its a bit slow to load. (hows that for an > understatement) > > > > > Progor wrote: >> >> Hmmm, the only thing I'm not sure about is your (d) created a file which >> I call "pathextender.pth" file where I added all of the directories where >> my scripts are. In addition to adding all of my script directories (they >> are on storage cards), I then added the path to my python25\lib directory >> where my Tkinter.py and Tkinter.pyc resides. >> >> What is this pathextender.pth file, what format is it in, and how does >> python know what to do with it? >> >> Either way, I guess it's not that big of a deal. Adding import _tkinter >> doesn't seem to have any adverse effects, and it makes at least one >> machine more stable :) >> >> I'm almost finished making my Tkinter-based "almost native looking" App >> class. It's complete with no visible border or title bar, a menu at the >> bottom that leaves room for the SIP button, and a main frame that >> automatically resizes itself when the SIP appears. I just have to do a >> little bit more work to make it recognize hi-res devices and landscape >> orientation, and resize it's main frame and menus as needed. I may be >> reinventing a wheel, but I didn't find anything on this list like that. >> I'll post my files when I'm done. >> >> By the way, it's taking several seconds (5ish) to load my App (i.e. from >> the time the python interpreter appears to the time the GUI is >> displayed)... is that Tkinter taking so long, or should I look at some of >> my other imports and/or code? >> >> >> Bandung wrote: >>> >>> I've been through all of those permutations and combinations myself. >>> What I settled on was this; >>> >>> a) left the original python.zip file intact. that is to say, didn'tt >>> remove anything, didn't replace anything >>> b) added the latest Tkinter.py that I could find for python25 and placed >>> it in my Python2.5\lib directory. >>> c) clicked on the Tkinter.py file in my Lib directory to get it to >>> create a Tkinter.pyc If yours is anything like mine, it will not be the >>> same size as the one within python25.zip. This is good. Why? I don't >>> know. >>> d) created a file which I call "pathextender.pth" file where I added all >>> of the directories where my scripts are. In addition to adding all of >>> my script directories (they are on storage cards), I then added the path >>> to my python25\lib directory where my Tkinter.py and Tkinter.pyc >>> resides. >>> e) soft reset. >>> >>> Occasionally, I get that dll not found message. Particularly if the >>> unit goes into it's "hybernation" mode. Soft reset always brings it >>> back. Well on rare occasions, I have had to do numerous soft resets. >>> (even removed the battery one time and then did the "1 stylus salute" >>> thingy) >>> >>> Assuming that your files are all in the correct place, soft reset should >>> work. My python is on the storage card. Don't know if that makes a >>> difference but someone else was struggling to get their install working >>> within main memory and it worked so... >>> >>> >>> >>> Progor wrote: >>>> >>>> I wish it were that easy. This process included 20-something soft >>>> resets, none of which were able to solve this problem. I am pretty new >>>> to python, so if you can help me understand why: >>>> >>>> import _tkinter >>>> import Tkinter >>>> >>>> works, but: >>>> >>>> import Tkinter >>>> >>>> alone doesn't work, then maybe we can find a solution to the whole >>>> problem. >>>> >>>> I assume import _tkinter is asking it to import the dll itself, and >>>> somehow the Tkinter package isn't making it that far. >>>> >>>> Ok. I made it a bit further. I found a Tkinter.py and Tkinter.pyc >>>> file in one of the threads on this topic a bit back and added them to >>>> my Lib directory. That did nothing, but then I renamed Tkinter.pyc in >>>> python25.zip/lib-tk to Tkinterold.pyc (Resco File Explorer ftw) so >>>> python would be sure to use the one in Lib, and finally, it works. >>>> Oddly enough, clicking on the .py version gives a could not find TCL >>>> DLL message (on the import _tkinter line), but clicking on the .pyc >>>> gives the little demo window. Even weirder, moving that .pyc file into >>>> the zip under lib-tk takes me back to the original problem (not finding >>>> TK DLL). Yes, I soft reset between every file move operation and test. >>>> >>>> Well, dangit, I must have gotten lucky on a soft reset here or there or >>>> still had the DLL loaded into memory from something else or... who >>>> knows... I'm still getting the "could not find TK DLL" message, with >>>> either version or location of Tkinter.pyc... most of the time. >>>> >>>> >>>> Bandung wrote: >>>>> >>>>> A soft reset is your friend. Do it and your python install/tkinter >>>>> will return to normal. I don't know why at times "stuff" happens but >>>>> it does. >>>>> >>>>> >>>>> Progor wrote: >>>>>> >>>>>> So, I think I might have my install kinda borked. I finally got it >>>>>> working, but I had to jump through some hoops to make it work. >>>>>> >>>>>> First, I installed PythonCE with CABINSTL directly into /Python (I >>>>>> switch SD cards all the time, wanted it in main memory (for speed >>>>>> too), but with as few spaces as possible for command line stuff). >>>>>> >>>>>> Then, I tried just doing an import Tkinter from the console, but it >>>>>> gave me the notorious missing TK DLL message. >>>>>> >>>>>> So, I found the dlls (celib, tk84, tcl84) and put them in /Windows, >>>>>> but it still gave me the error. >>>>>> >>>>>> So, I played around with it a bit. I found out if I import _tkinter >>>>>> first, then it doesn't give me the message... but that's an extra >>>>>> line in all my programs and may be weird if I ever want to give out >>>>>> my programs. >>>>>> >>>>>> I kept looking around on this mailing list and finally figured out I >>>>>> needed to install tcl as well, did that, but I still have to import >>>>>> _tkinter before I can import Tkinter without getting the "Could not >>>>>> find TK DLL" error. >>>>>> >>>>>> It sounds like some people have gotten it to work on their systems >>>>>> without the weird "import _tkinter" extra line. Have I done >>>>>> something wrong? Or is Tkinter just that persnickity? >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/weird-Tkinter-tf3297520.html#a9243936 Sent from the Python - pythonce mailing list archive at Nabble.com. From davidf at sjsoft.com Mon Mar 5 17:11:21 2007 From: davidf at sjsoft.com (David Fraser) Date: Mon, 05 Mar 2007 18:11:21 +0200 Subject: [PythonCE] VensterCE release In-Reply-To: <20070130203626.696g4b1fwg4goog0@webmail.enst-bretagne.fr> References: <20070130165510.n9dxmi1vs4kcc8sw@webmail.enst-bretagne.fr> <7A93FCDF-D431-4A8D-B673-DED85592A5B5@ablelinktech.com> <20070130203626.696g4b1fwg4goog0@webmail.enst-bretagne.fr> Message-ID: <45EC4129.7060305@sjsoft.com> alexandre.delattre at enst-bretagne.fr wrote: > Brian Brown a ?crit : > > >> On Jan 30, 2007, at 8:55 AM, alexandre.delattre at enst-bretagne.fr wrote: >> >> >>>> I'm curious. >>>> >>>> The original Venster was published under the MIT license. >>>> >>>> Why have you published Venster-CE under the GPL license? >>>> >>>> Alan. >>>> >>> Well, I thought that the most important was to use an OSI compliant >>> license and I personnaly prefer GNU/GPL. I'am no license-expert, so if >>> you see any problem with this, tell me, and I could change the >>> licensing. >>> >>> Alex. >>> >>> >> Hello Alex, >> >> >> I was under the impression that MIT is quite OSI compliant. I prefer >> MIT/BSD licensing and have published a great deal of code under that >> license (http://techgame.net/projects/Framework). >> >> I personally believe there is a great synergy between commercial and >> open source entities; for example, all the code we have created as >> expressly open source were completely funded by commercial entities. We >> make it as free as we can (MIT/BSD) for commercial or non-commercial >> use. The GPL typically bars commercial use because you can't keep any >> part of your system proprietary. >> >> Basically, If a toolkit is GPL, I typically won't use it when doing >> development of my own stuff, although there are lots of other licenses, >> such as MPL, APL and others that are less restrictive that the GPL. >> >> That's my 2 cents :) >> >> - Brian >> >> >> >> >>> _______________________________________________ >>> PythonCE mailing list >>> PythonCE at python.org >>> http://mail.python.org/mailman/listinfo/pythonce >>> > > Hello Brian, > > Well, since I'm a student, I didn't really take into account > commercial use. I ideally thought that GPL gives a lot of freedom for > free or commercial development. > If it encouranges python ce users to choose venster as their gui > toolkit, in free or commercial products, I will release the upcoming > version under a MIT license. > > Anyway, have you tried venster-ce ? > I'll be glad to have comments or (constructive :-) criticism ! > I'd be keen to try it but would only be able to use LGPL / Python / MIT license Cheers David From brian at ablelinktech.com Mon Mar 5 19:47:48 2007 From: brian at ablelinktech.com (Brian Brown) Date: Mon, 5 Mar 2007 11:47:48 -0700 Subject: [PythonCE] VensterCE release In-Reply-To: <45EC4129.7060305@sjsoft.com> References: <20070130165510.n9dxmi1vs4kcc8sw@webmail.enst-bretagne.fr> <7A93FCDF-D431-4A8D-B673-DED85592A5B5@ablelinktech.com> <20070130203626.696g4b1fwg4goog0@webmail.enst-bretagne.fr> <45EC4129.7060305@sjsoft.com> Message-ID: <0FA264DE-2206-4031-8C64-41C105D44E4F@ablelinktech.com> On Mar 5, 2007, at 9:11 AM, David Fraser wrote: >> >> Hello Brian, >> >> Well, since I'm a student, I didn't really take into account >> commercial use. I ideally thought that GPL gives a lot of freedom for >> free or commercial development. >> If it encouranges python ce users to choose venster as their gui >> toolkit, in free or commercial products, I will release the upcoming >> version under a MIT license. >> >> Anyway, have you tried venster-ce ? >> I'll be glad to have comments or (constructive :-) criticism ! >> > I'd be keen to try it but would only be able to use LGPL / Python / > MIT > license > I think he may have already released it under MIT... Brian > Cheers > David > _______________________________________________ > PythonCE mailing list > PythonCE at python.org > http://mail.python.org/mailman/listinfo/pythonce From christopher at christec.co.nz Mon Mar 5 21:27:38 2007 From: christopher at christec.co.nz (Christopher Fairbairn) Date: Mon, 05 Mar 2007 15:27:38 -0500 Subject: [PythonCE] Building under Visual Studio 2005 for Devices Message-ID: <20070305204324.690CA1E400C@bag.python.org> Hi, I am keen to start contributing to the Windows CE/Windows Mobile port of Python. I have a lot of commerical development experience in this environment. I would like to understand the build process for Python in a lot more detail than I currently do. I thought an ideal way to do this would be to have a goal of making PythonCE compilable under Visual Studio 2005. Is anyone able to give me any starting tips on how I might approch this? Should I look at modifying the SCONS scripts to be able to detect and make use of Visual Studio 2005 instead of EVC, or should I go the route used by the PCBuild and PCBuild8 directories (i.e. desktop versions) where (I assume) someone has manually created a bunch of suitable project and solution files? Thanks. Christopher Fairbairn From fuzzyman at voidspace.org.uk Mon Mar 5 21:57:31 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 05 Mar 2007 20:57:31 +0000 Subject: [PythonCE] Building under Visual Studio 2005 for Devices In-Reply-To: <20070305204324.690CA1E400C@bag.python.org> References: <20070305204324.690CA1E400C@bag.python.org> Message-ID: <45EC843B.7050602@voidspace.org.uk> Christopher Fairbairn wrote: > Hi, > > I am keen to start contributing to the Windows CE/Windows Mobile port of Python. I > have a lot of commerical development experience in this environment. > > I would like to understand the build process for Python in a lot more detail than I > currently do. I thought an ideal way to do this would be to have a goal of making > PythonCE compilable under Visual Studio 2005. > > Is anyone able to give me any starting tips on how I might approch this? Should I > look at modifying the SCONS scripts to be able to detect and make use of Visual > Studio 2005 instead of EVC, or should I go the route used by the PCBuild and > PCBuild8 directories (i.e. desktop versions) where (I assume) someone has manually > created a bunch of suitable project and solution files? > > PythonCE is a port of the standard CPython project. As it happens there is thread going on *right now* on the Python-dev mailing list on what it takes to make CPython compilable with VS 2005. The same techniques would have to be applied to the PythonCE project which is essentially just a patched version of vanilla CPython. Worth browsing the Python-dev mailing archives for this month... Fuzzyman http://www.voidspace.org.uk/python/index.shtml > Thanks. > Christopher Fairbairn > > > _______________________________________________ > PythonCE mailing list > PythonCE at python.org > http://mail.python.org/mailman/listinfo/pythonce > > From coder_infidel at hotmail.com Tue Mar 6 15:24:10 2007 From: coder_infidel at hotmail.com (Luke Dunstan) Date: Tue, 6 Mar 2007 23:24:10 +0900 Subject: [PythonCE] Building under Visual Studio 2005 for Devices References: <20070305204324.690CA1E400C@bag.python.org> <45EC843B.7050602@voidspace.org.uk> Message-ID: ----- Original Message ----- From: "Michael Foord" To: Cc: Sent: Tuesday, March 06, 2007 5:57 AM Subject: Re: [PythonCE] Building under Visual Studio 2005 for Devices > Christopher Fairbairn wrote: >> Hi, >> >> I am keen to start contributing to the Windows CE/Windows Mobile port of >> Python. I >> have a lot of commerical development experience in this environment. >> >> I would like to understand the build process for Python in a lot more >> detail than I >> currently do. I thought an ideal way to do this would be to have a goal >> of making >> PythonCE compilable under Visual Studio 2005. >> >> Is anyone able to give me any starting tips on how I might approch this? >> Should I >> look at modifying the SCONS scripts to be able to detect and make use of >> Visual >> Studio 2005 instead of EVC, or should I go the route used by the PCBuild >> and >> PCBuild8 directories (i.e. desktop versions) where (I assume) someone has >> manually >> created a bunch of suitable project and solution files? >> >> > PythonCE is a port of the standard CPython project. > > As it happens there is thread going on *right now* on the Python-dev > mailing list on what it takes to make CPython compilable with VS 2005. > > The same techniques would have to be applied to the PythonCE project > which is essentially just a patched version of vanilla CPython. > > Worth browsing the Python-dev mailing archives for this month... > > Fuzzyman > http://www.voidspace.org.uk/python/index.shtml If it is possible to modify the PCBuild8 project files so that Python can be built for both desktop Windows and Windows CE then yes, this may well be the simplest option. However, if Windows CE would require separate project files then I think it would be better to adapt the SCons scripts. For your information, PythonCE 2.4 had two build systems: primarily a set of nmake makefiles and a secondary set of EVC 4 project files as an alternative. I replaced these with SCons because it is more powerful, more automated and easier to maintain (less redundancy) than makefiles, and far more powerful and flexible than project files. Luke From christopher at christec.co.nz Fri Mar 9 04:42:10 2007 From: christopher at christec.co.nz (Christopher Fairbairn) Date: Thu, 08 Mar 2007 22:42:10 -0500 Subject: [PythonCE] Building under Visual Studio 2005 for Devices Message-ID: <20070309034216.2476E1E4002@bag.python.org> Hi, >If it is possible to modify the PCBuild8 project files so that Python can be >built for both desktop Windows and Windows CE then yes, this may well be the >simplest option. However, if Windows CE would require separate project files >then I think it would be better to adapt the SCons scripts. I have had a quick play around with getting a build working using the Visual Studio 2005 compilers and have managed to get a version compiled on my machine via the SCons scripts. It appears to be running fine on my PDA. A brief summary of what I needed to do. 1) Modified msevc.py to change some of the tool names (cl.exe vs clarm.exe) and command line arguments as required for the VS2005 compilers. At present I also hardcoded some of the file paths required rather than writing the code to reliably find them in the registry etc. 2) Tweaked a few conditional compile statements throughout the source code (about two or three from memory) due to the conditional expressions being incorrect due to the use of the VS2005 compiler during WinCE builds. For instance, the following condition found within pythonrun.c is now slightly incorrect. /* Special signal handling for the secure CRT in Visual Studio 2005 */ #if defined(_MSC_VER) && _MSC_VER >= 1400 This condition includes code which is specific to the desktop runtime environment (but now evaluates to true due to me using the same version of the compiler), so ideally it needs a further condition added to avoid it including the code when targeting the WinCE platform with this compiler version. If I took the time to clean up and complete these patches would there be interest in including support for building PythonCE with Visual Studio 2005? Thanks, Christoher Fairbairn PS: When I ran SCons it built the Python25.dll, Python25.exe and Python25.zip files. However it didn't build the cab file. I notice there is code within the 'SConstruct' file which appears to be designed to automate the cab building process (I manually ran cabwiz.exe on the inf file), how do I run this script? From coder_infidel at hotmail.com Fri Mar 9 16:12:06 2007 From: coder_infidel at hotmail.com (Luke Dunstan) Date: Sat, 10 Mar 2007 00:12:06 +0900 Subject: [PythonCE] Building under Visual Studio 2005 for Devices References: Message-ID: Hi, Yes, there is no reason why the VS2005 patches build scripts could not be part of the PythonCE release. Target filenames or aliases can be passed on the command line to scons.bat just like make. To build the setup .exe use "scons setup". This is mentioned in README-WinCE.txt Luke ----- Original Message ----- From: "Christopher Fairbairn" To: "'Michael Foord'" ; ; "'Luke Dunstan'" Cc: Sent: Friday, March 09, 2007 12:42 PM Subject: Re: [PythonCE] Building under Visual Studio 2005 for Devices Hi, >If it is possible to modify the PCBuild8 project files so that Python can >be >built for both desktop Windows and Windows CE then yes, this may well be >the >simplest option. However, if Windows CE would require separate project >files >then I think it would be better to adapt the SCons scripts. I have had a quick play around with getting a build working using the Visual Studio 2005 compilers and have managed to get a version compiled on my machine via the SCons scripts. It appears to be running fine on my PDA. A brief summary of what I needed to do. 1) Modified msevc.py to change some of the tool names (cl.exe vs clarm.exe) and command line arguments as required for the VS2005 compilers. At present I also hardcoded some of the file paths required rather than writing the code to reliably find them in the registry etc. 2) Tweaked a few conditional compile statements throughout the source code (about two or three from memory) due to the conditional expressions being incorrect due to the use of the VS2005 compiler during WinCE builds. For instance, the following condition found within pythonrun.c is now slightly incorrect. /* Special signal handling for the secure CRT in Visual Studio 2005 */ #if defined(_MSC_VER) && _MSC_VER >= 1400 This condition includes code which is specific to the desktop runtime environment (but now evaluates to true due to me using the same version of the compiler), so ideally it needs a further condition added to avoid it including the code when targeting the WinCE platform with this compiler version. If I took the time to clean up and complete these patches would there be interest in including support for building PythonCE with Visual Studio 2005? Thanks, Christoher Fairbairn PS: When I ran SCons it built the Python25.dll, Python25.exe and Python25.zip files. However it didn't build the cab file. I notice there is code within the 'SConstruct' file which appears to be designed to automate the cab building process (I manually ran cabwiz.exe on the inf file), how do I run this script? From xrubenx.es at gmail.com Tue Mar 13 16:14:33 2007 From: xrubenx.es at gmail.com (Ruben Miguelez Garcia) Date: Tue, 13 Mar 2007 16:14:33 +0100 Subject: [PythonCE] serial port access In-Reply-To: References: Message-ID: <200703131614.33533.xrubenx.es@gmail.com> > I tried this link > "http://mail.python.org/pipermail/pythonce/attachments/20060922/5af92a01/at >tachment-0003.py ", but when I import ceserial, pythonce gave me a > "SyntasError: > invalid synax" Just rename the file as something like ceserial.py Importing files with '-' on the name cause "SyntaxError" From christopher at christec.co.nz Wed Mar 28 04:30:51 2007 From: christopher at christec.co.nz (Christopher Fairbairn) Date: Tue, 27 Mar 2007 22:30:51 -0400 Subject: [PythonCE] Submitting patches / support for WinCE Message-ID: <20070328023054.DF6CC1E4002@bag.python.org> Hi, Over the last few days I have submitted a few patches via PythonCE's sourceforge site. Hopefully there will be more to come in the future :-P The question I have is in what format are patches ideally submitted etc. Each project tends to have it's own processes in place for submitting patches etc and I would like to know how I can make it easier for my patches to be accepted and merged. The main patch I submitted a couple of days ago provides initial support for running on devices running the Smartphone variant of Windows Mobile. I would like to tidy up and submit another patch which will allow a single binary build to run on raw Windows CE, Pocket PC and Smartphone platforms without requiring dummy agyshell.dll's (and getting better Windows CE intergration in the process). Is this something which is likely to be accepted? Thanks, Christopher Fairbairn From coder_infidel at hotmail.com Wed Mar 28 23:29:40 2007 From: coder_infidel at hotmail.com (Luke Dunstan) Date: Thu, 29 Mar 2007 05:29:40 +0800 Subject: [PythonCE] Submitting patches / support for WinCE In-Reply-To: <20070328023054.DF6CC1E4002@bag.python.org> Message-ID: >From: Christopher Fairbairn >Reply-To: christopher at christec.co.nz >To: pythonce at python.org >Subject: [PythonCE] Submitting patches / support for WinCE >Date: Tue, 27 Mar 2007 22:30:51 -0400 > >Hi, > >Over the last few days I have submitted a few patches via PythonCE's >sourceforge >site. Hopefully there will be more to come in the future :-P > >The question I have is in what format are patches ideally submitted etc. >Each >project tends to have it's own processes in place for submitting patches >etc and I >would like to know how I can make it easier for my patches to be accepted >and >merged. > >The main patch I submitted a couple of days ago provides initial support >for >running on devices running the Smartphone variant of Windows Mobile. I >would like >to tidy up and submit another patch which will allow a single binary build >to run >on raw Windows CE, Pocket PC and Smartphone platforms without requiring >dummy >agyshell.dll's (and getting better Windows CE intergration in the process). >Is this >something which is likely to be accepted? > >Thanks, >Christopher Fairbairn Hi, I created the last few releases of PythonCE but I haven't done any work on PythonCE for a while, and anyway I am away from home for this week at least. In any case though, having the patches available on SourceForge is quite useful for anyone else who might want to run Python on these Windows CE platforms. Patches are preferred in unified diff format, and would ideally be patches for one of the PythonCE source tarballs, but could also be patches for an official Python release. Luke