From l.dobrev at gmail.com  Mon Aug  4 11:07:22 2008
From: l.dobrev at gmail.com (Lachezar Dobrev)
Date: Mon, 4 Aug 2008 12:07:22 +0300
Subject: [PythonCE] Python CE on a Intel XScale industrial device.
In-Reply-To: <200807311630.m6VGUv9f008892@courrier.enst-bretagne.fr>
References: <200807311630.m6VGUv9f008892@courrier.enst-bretagne.fr>
Message-ID: <90266c3f0808040207n39bbe22cn694cff510e4f5f1f@mail.gmail.com>

  More updates.

  Thanks to Alexandre I was able to start Python with Tkinter, however
I was a bit disappointed by the hardness of the installation
procedure, and the unexpected dependancy on the TCL Toolkit. No
matter.

  I extracted the .CAB file with a Windows utility called MSCEInf.exe.
  I copied the files to the device using a (W)LAN.
  I then copied the celib.dll and the TCL/TK libraries (a very tedious
procedure).

  I was able to successfully create a Tkinter Frame with a label inside.
  I was also able to run the provided Tkinter._test().

  Trying to install the ppygui however was no success at all.
  A few seconds after starting install.py I got:

> Traceback (innermost last):
>   File "\Temp\ppygui-0.7\install.py", line 5, in <module>
>     import ppygui as gui
>   File "\Temp\ppygui-0.7\ppygui\__init__.py", line 1, in <module>
>     from api import *
>   File "\Temp\ppygui-0.7\ppygui\api.py", line 29, in <module>
>     from html import *
>   File "\Temp\ppygui-0.7\ppygui\html.py", line 101, in <module>
>     _InitHTMLControl()
>   File "\Temp\ppygui-0.7\ppygui\html.py", line 99, in _InitHTMLControl
>     cdll.htmlview.InitHTMLControl(GetModuleHandle(0))
>   File "C:\devl\release\PythonCE-2.5-20061219\Python-2.5-wince\Lib\ctypes\__init__.py", line 387, in __getattr__
>   File "C:\devl\release\PythonCE-2.5-20061219\Python-2.5-wince\Lib\ctypes\__init__.py", line 312, in __init__
> <type 'exceptions.WindowsError'>: [Error 87] Windows Error 0x7E

  Which baffled me completely (I am quite new to this stuff).

  However inspired by this minor success I used a set of tools for Linux:
  1. I extracted the CAB file with cabextract.
  2. I used hexer to edit the *.000 file and replace the supported
processor from 0x0A11 at position 20 with 0x0920 (which is the XScale
processors' cpu id).
  3. I used lcab to 'try' and recreate the CAB with the updated files.

  Well...
  At first the installer no longer bugged me with '... can not run on
this device...'. It actually started copying files.
  However for all the .dll and .exe files the installer said: 'File
... was not copied.' (or something similar). It also told me I need to
get the CAB file from the source location again.
  The result was not very good. I canceled the installation half-way
through (too many pop-ups). The 'Program Files\Python25' had a number
of files and directories similar to what I got when I extracted the
cab with the Windows tool. However all the .dll and .exe files had
zero length. Surprisingly a lot of .pyd files were there with a
positive length. I did not get to the registration process, so I have
not checked the .py .pyc and .pyw associations.
  The un-installation also did no go as expected, leaving most files
inside the device.

  However I believe that this shows, that the processor type IS the
issue with the installer.

  Alexandre...
  Who is 'we' who should rebuild the CABs?
  Any pointers on the ppygui installation issue?

2008/7/31 Alexandre Delattre <alexandre.delattre at enst-bretagne.fr>:
> Hi,
>
> In my opinion if you're able to run the python exe it means that is not processor related.
>
> I think the problem comes from what you've pointed out, the OS versions constraints.
>
> I think we should rebuild the .cab to allow os versions from 4.00 and 5.99 as you suggested. There's also a bug in the cab that would be worth fixing at the same time:
>
> In one of the registry key that associates  .pyw to pythonce without shell we have to replace \nopcceshell by /nopcceshell.
>
> Else this cause the error <NULL>:<NULL> to be raised when running .pyw.
>
> For tKinter, the dll are not shipped with PythonCE and you have to copy them manually, more info on the wiki.
>
> For ppygui I'll be very glad if you use my toolkit, and if you send me your traceback I'll make my possible to make it work for you.
> I think the issue you described comes from that ppygui was designed for PocketPC 2003 and Windows Mobile, while it seems from screenshot your device has the 'classic' wince interface.
>
> Regards,
> Alexandre
>
>
> ----- Message d'origine -----
> De: Lachezar Dobrev <l.dobrev at gmail.com>
> Env: jeudi 31 juillet 2008 17:05
> ?: Alexandre Delattre <alexandre.delattre at enst-bretagne.fr>
> Objet: Re: [PythonCE] Python CE on a Intel XScale industrial device.
>
>  Update follows...
>
>  People on this list were quite helpful in referencing a couple of
> tools for Pocket PC CAB file mangling.
>  1. I was able to extract the Python CE CAB file an uploaded the
> extracted files to my device. The python executable had an icon, and I
> was able to run it. It seemed to work. I was able to execute a few
> minor tests my way: a few dir()-s, a few imports, a few Base64
> encoding and decoding operations, and it seemed to work fine. Until I
> tried to import Tkinter:
>
>> >>> import sys
>> >>> import Tkinter
>> Traceback (most recent call last):
>>   File "C:\devl\release\PythonCE-2.5-20061219\Python-2.5-wince\Lib\lib-tk\Tkinter.py", line 38, in <module>
>> RuntimeError: Could not find CeLib DLL
>> >>>
>
>  Which led me to believe something is not right.
>  Has anyone seen that? Does anyone know how to fix that?
>
>  A similar error occurs when I try to install the PocketPyGui
> (ppygui-0.7) which I thought I would use for the GUI part. However the
> exception then has a bit longer stack trace (about 10 frames).
>
>  2. Reading the documentation on the pocketpc-cab and lcab utilities
> I found something that rang a bell:
>
>    Appendix A: a list of processor architectures
>    ...
>    1824 - ARM 720
>    2080 - ARM 820
>    2336 - ARM 920
>    2577 - StrongARM
>    ...
>
>    My device says in the System Properties: 'Intel, ARM920T-PXA27x'
>    Could this be the culprit of my problems? Is ARM920 compatible
> with Strong ARM? Should I give-up on trying to install the current
> version and try to compile a version for my device personally?
>
>  I also noted that the CAB files state, that the allowed OS version
> is 4.00 up to 5.00, shouldn't it be up to 5.99 or something? Not that
> my device has Windows 5.1 or anything, but I saw a the Smart Phone
> version note a MAX OS Version of 5.99...
>
>  I hope I get more feed-back on the subject.
>  I feel I am getting closer, but I am neither a Mobile-Device expert,
> nor a Python expert. I am fairly new to this stuff.
>
>
>

From alexandre.delattre at enst-bretagne.fr  Mon Aug  4 14:09:59 2008
From: alexandre.delattre at enst-bretagne.fr (Alexandre Delattre)
Date: Mon, 04 Aug 2008 14:09:59 +0200
Subject: [PythonCE] Python CE on a Intel XScale industrial device.
In-Reply-To: <90266c3f0808040207n39bbe22cn694cff510e4f5f1f@mail.gmail.com>
References: <90266c3f0808040207n39bbe22cn694cff510e4f5f1f@mail.gmail.com>
Message-ID: <4896F197.9050403@enst-bretagne.fr>

Hi,

What I meant is that if you can run python.exe without crashing, it 
seems obvious to me that this code is compatible with your processor 
(else the .exe would refuse to start, or you would have very strange 
results and won't be able to enter a single command).
To me, the processor seems not to be the real backend problem, but you 
may be right about the processor type specified in the cab preventing 
the installation.
Are you able to install other PocketPC applications from .cab ?

 > Alexandre...
 > Who is 'we' who should rebuild the CABs?

Good question ... I'd really like to do that but I don't have much time 
right now (plenty of other projects and stuff to do...) and need to have 
evc++4.0 working on my computer (f*ckin windows vista ...).
If someone is willing to take that up, I'll be glad to give directions.

 > Any pointers on the ppygui installation issue?
The traceback points to the Html control module, which is not the most 
essential, however, as the installer relies on this control you'll have 
to proceed to manual installation, i.e. copy ppygui package from the 
archive to \Program Files\Python25\Lib

Then you have to edit ppygui/api.py and comment out the line:
from html import *

Then try to run the demo.py file which does not use the html control, 
and see if it works.

Alexandre.

From l.dobrev at gmail.com  Mon Aug  4 14:57:31 2008
From: l.dobrev at gmail.com (Lachezar Dobrev)
Date: Mon, 4 Aug 2008 15:57:31 +0300
Subject: [PythonCE] Python CE on a Intel XScale industrial device.
In-Reply-To: <4896F197.9050403@enst-bretagne.fr>
References: <90266c3f0808040207n39bbe22cn694cff510e4f5f1f@mail.gmail.com>
	<4896F197.9050403@enst-bretagne.fr>
Message-ID: <90266c3f0808040557l43626e78k47a1c2bf9bc3d62a@mail.gmail.com>

  I understand what you mean, but I am more worried about the subtle
differences in processors (like the MMX vs SSE in X86). These
differences do not surface early, but when requested.
  I still remember 'those times' where a program would run correctly
for some time, until one tries floating point operations and would
crash badly.

  I thought of running the Python regression tests, but I don't think
those are available for Python CE, and I was unable to complete the
tests on a test Desktop machine (some weird unstoppable exception is
some *chat* test case).

  I am afraid I can not volunteer to build the CAB files myself.
  I am a bit scared to ask, but can't 'we' use SourceForge's farms to
set up a continuous build system? I can not volunteer for that task
either, because I am not a SourceForge (project) developer.

  You ask if I was able to install anything...
  I '''installed''' Mozilla's Minimo browser, but it has no Processor
Type specified, and on top of that it would not run afterwards: the
.exe files have no icon, and 'This is not a CE program' error shows
when I try to run any of them.
  I have not seen any available CAB files for XScale, that I could test with.

  BTW. The Minimo project seems to have been archived and dropped. I
don't like where Mozilla is going :-/ (I actively dislike Firefox
3.0).

2008/8/4, Alexandre Delattre <alexandre.delattre at enst-bretagne.fr>:
> Hi,
>
>  What I meant is that if you can run python.exe without crashing, it seems
> obvious to me that this code is compatible with your processor (else the
> .exe would refuse to start, or you would have very strange results and won't
> be able to enter a single command).
>  To me, the processor seems not to be the real backend problem, but you may
> be right about the processor type specified in the cab preventing the
> installation.
>  Are you able to install other PocketPC applications from .cab ?
>
>  > Alexandre...
>  > Who is 'we' who should rebuild the CABs?
>
>  Good question ... I'd really like to do that but I don't have much time
> right now (plenty of other projects and stuff to do...) and need to have
> evc++4.0 working on my computer (f*ckin windows vista ...).
>  If someone is willing to take that up, I'll be glad to give directions.
>
>  > Any pointers on the ppygui installation issue?
>  The traceback points to the Html control module, which is not the most
> essential, however, as the installer relies on this control you'll have to
> proceed to manual installation, i.e. copy ppygui package from the archive to
> \Program Files\Python25\Lib
>
>  Then you have to edit ppygui/api.py and comment out the line:
>  from html import *
>
>  Then try to run the demo.py file which does not use the html control, and
> see if it works.
>
>  Alexandre.
>

From l.dobrev at gmail.com  Tue Aug  5 09:25:27 2008
From: l.dobrev at gmail.com (Lachezar Dobrev)
Date: Tue, 5 Aug 2008 10:25:27 +0300
Subject: [PythonCE] Python CE on a Intel XScale industrial device.
In-Reply-To: <4896F197.9050403@enst-bretagne.fr>
References: <90266c3f0808040207n39bbe22cn694cff510e4f5f1f@mail.gmail.com>
	<4896F197.9050403@enst-bretagne.fr>
Message-ID: <90266c3f0808050025i459a3a69vbaa91f3a6333972f@mail.gmail.com>

2008/8/4, Alexandre Delattre
>  > Any pointers on the ppygui installation issue?
>  The traceback points to the Html control module, which is not the most
> essential, however, as the installer relies on this control you'll have to
> proceed to manual installation, i.e. copy ppygui package from the archive to
> \Program Files\Python25\Lib
>
>  Then you have to edit ppygui/api.py and comment out the line:
>  from html import *
>
>  Then try to run the demo.py file which does not use the html control, and
> see if it works.

  Success!
  After manually copying the ...\ppygui-0.7\ppygui\*.py to a newly
created $PYTHONHOME\Lib\site-packages\ppygui the demo application
started (pretty damn fast!) and displayed correctly (as far as I
know).
  Now... Do I need the Tkinter pack to use ppygui? I did not find any
reference to that, and I am eager to trim down the Python
distribution. I'll be having problems creating a distribution pack for
installing on the devices we'll be using.

  Hmm... I wonder if I could be converted into a Python Head.

From alexandre.delattre at enst-bretagne.fr  Tue Aug  5 12:34:36 2008
From: alexandre.delattre at enst-bretagne.fr (Alexandre Delattre)
Date: Tue, 05 Aug 2008 12:34:36 +0200
Subject: [PythonCE] Python CE on a Intel XScale industrial device.
In-Reply-To: <90266c3f0808050025i459a3a69vbaa91f3a6333972f@mail.gmail.com>
References: <90266c3f0808050025i459a3a69vbaa91f3a6333972f@mail.gmail.com>
Message-ID: <48982CBC.1060904@enst-bretagne.fr>

 > Success!
 > After manually copying the ...\ppygui-0.7\ppygui\*.py to a newly
 > created $PYTHONHOME\Lib\site-packages\ppygui the demo application
 > started (pretty damn fast!) and displayed correctly (as far as I
 > know).

Glad to here that works :)

 > Now... Do I need the Tkinter pack to use ppygui? I did not find any
 > reference to that, and I am eager to trim down the Python
 > distribution.

No, ppygui has no external dependence besides PythonCE and the system 
dlls that comes out of the box on wince devices. A byte-code only 
distribution of ppygui is around 250 kB.

 > I'll be having problems creating a distribution pack for
 > installing on the devices we'll be using.

These days I've been working on a script that helps producing easily 
.cab for pythonce applications and libraries. Hopefully I'll polish and 
publish it in the week.

 > Hmm... I wonder if I could be converted into a Python Head.

You mean a python egg ?

Also, I remember from the time I played with evc++ that PythonCE is 
targeted for armv4 processors. From what I read XScale is armv5 but is 
supposed to be backward compatible with armv4.
Maybe the .cab installer check the processor type id without taking into 
account backward-compatibility stuff ?

I think you don't have to hurry on recompilation yet if you're able to 
make work what you need for your project. Also I'm afraid only Visual 
Studio 2005 allow to compile for armv5, in case you really want to 
recompile something optimized for your architecture.


Alexandre

From l.dobrev at gmail.com  Tue Aug  5 13:33:41 2008
From: l.dobrev at gmail.com (Lachezar Dobrev)
Date: Tue, 5 Aug 2008 14:33:41 +0300
Subject: [PythonCE] Python CE on a Intel XScale industrial device.
In-Reply-To: <48982CBC.1060904@enst-bretagne.fr>
References: <90266c3f0808050025i459a3a69vbaa91f3a6333972f@mail.gmail.com>
	<48982CBC.1060904@enst-bretagne.fr>
Message-ID: <90266c3f0808050433l2825333bgdc8e3687046218e2@mail.gmail.com>

2008/8/5, Alexandre Delattre <alexandre.delattre at enst-bretagne.fr>:
> > Now... Do I need the Tkinter pack to use ppygui? I did not find any
> > reference to that, and I am eager to trim down the Python
> > distribution.
>
>  No, ppygui has no external dependence besides PythonCE and the system dlls
> that comes out of the box on wince devices. A byte-code only distribution of
> ppygui is around 250 kB.
  That is nice to know. Since these devices rarely have much available
space wasting 2 MB on TCL is not something I'm looking forward to.
With tinkering I can have up to 80 MB of available disk space, but I'd
like to keep it low-size.


> > Hmm... I wonder if I could be converted into a Python Head.
>
>  You mean a python egg ?
  No :).
  I meant Myself (from Java Head into a Python Head).
  Although this was a nice shot :)

>  Also, I remember from the time I played with evc++ that PythonCE is
> targeted for armv4 processors. From what I read XScale is armv5 but is
> supposed to be backward compatible with armv4.
  This is what I read around the network.

>  Maybe the .cab installer check the processor type id without taking into
> account backward-compatibility stuff ?
  I agree. This seems a most-likely reason.

>  I think you don't have to hurry on recompilation yet if you're able to make
> work what you need for your project. Also I'm afraid only Visual Studio 2005
> allow to compile for armv5, in case you really want to recompile something
> optimized for your architecture.
  Actually I would want the opposite: a VM that would work on many
devices rather than a VM that would work on only one type of device a
bit better. Pardon the terminology, I still look at the Python frame
through my Java experience.

  We are targeting a Client-Server architecture, where the server does
most of the job, and the client is used as a 'Screen and Keyboard
Terminal' without putting much resource pressure on it.

  I was actually wondering if there is a way to build a new CAB file
with only the Processor Type changed (no re-compilation). However I
lack the tools to do so.

>  Alexandre

  P.S. I will be off the subject for a while. I need to focus back to
the server side. My device was also put to real use, and I will have
no test bed for a week or so.

From renesd at gmail.com  Wed Aug  6 07:43:16 2008
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Wed, 6 Aug 2008 15:43:16 +1000
Subject: [PythonCE]  pygame / distutils
Message-ID: <64ddb72c0808052243s14e67d9emf4046645e1e48edf@mail.gmail.com>

Hi,

if anyone has any project files to build pygame on pythonce I'd love
to have them included with pygame.  I'm an author/maintainer of pygame
and have commit access to svn, so could add project files if someone
makes them... I could also add a pygame download for python CE to the
pygame.org download page.

Or you could add compilation instructions to the pygame wiki here:
http://pygame.org/wiki/CompilePythonCE

I have a winCE phone so would love to be able to get pygame running on it :)


cheers,

From adam.walley at gmail.com  Wed Aug  6 13:02:19 2008
From: adam.walley at gmail.com (Adam Walley)
Date: Wed, 6 Aug 2008 12:02:19 +0100
Subject: [PythonCE] pygame / distutils
In-Reply-To: <64ddb72c0808052243s14e67d9emf4046645e1e48edf@mail.gmail.com>
References: <64ddb72c0808052243s14e67d9emf4046645e1e48edf@mail.gmail.com>
Message-ID: <518d94ee0808060402s2168fe23h31f5d14fefd07de8@mail.gmail.com>

Well, I have been attempting to get something working, but have been
struggling to get the SDL compiled correctly (without SDL, there is no point
in trying to get pygame working). In my investigations, I came across the
SCUMM forum. Now the SCUMMVM appears to be a fully working product on
various platforms including WinCE. My attempts to compile some simple test
programs using the SDL source available from the official SDL site failed
(mostly because the source will not compile 'as is' and needs some tweaking
which is probably beyond my capabilities). However, the SCUMM forum pointed
me to a set of libraries from 'knakos'. I quickly set up a new project, with
my simple test program, and lo! it compiled first time and tested correctly
on my WM5 device. I assume these SCUMM libraries have already been adapted
to work on WinCE, and since the SCUMM idea is to get retro graphical games
working, I think that pygame will probably get all the functionality it
needs from them.

Now, on to getting pygame working! I will attempt to get some of the pygame
source modules compiled as PYDs to see if they will import and work under
PythonCE. I have not yet attempted to get a DLL compiled using these new
libraries so may yet hit a wall. I will report back with any news.

Rene, thanks for your comments. It's nice to know there is interest from the
pygame side.

If anyone else would like to provide comments/advice/code to get pygame
working, it will be welcomed.

Adam.

On 06/08/2008, Ren? Dudfield <renesd at gmail.com> wrote:
>
> Hi,
>
> if anyone has any project files to build pygame on pythonce I'd love
> to have them included with pygame.  I'm an author/maintainer of pygame
> and have commit access to svn, so could add project files if someone
> makes them... I could also add a pygame download for python CE to the
> pygame.org download page.
>
> Or you could add compilation instructions to the pygame wiki here:
> http://pygame.org/wiki/CompilePythonCE
>
> I have a winCE phone so would love to be able to get pygame running on it
> :)
>
>
> cheers,
> _______________________________________________
> PythonCE mailing list
> PythonCE at python.org
> http://mail.python.org/mailman/listinfo/pythonce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080806/6bf16699/attachment.htm>

From renesd at gmail.com  Thu Aug  7 01:09:22 2008
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Thu, 7 Aug 2008 09:09:22 +1000
Subject: [PythonCE] pygame / distutils
In-Reply-To: <518d94ee0808060402s2168fe23h31f5d14fefd07de8@mail.gmail.com>
References: <64ddb72c0808052243s14e67d9emf4046645e1e48edf@mail.gmail.com>
	<518d94ee0808060402s2168fe23h31f5d14fefd07de8@mail.gmail.com>
Message-ID: <64ddb72c0808061609q12f0394ar1f15a26c09c308db@mail.gmail.com>

nice work :)

It can be easier to first try and get the SDL test programs compiling.
 Then try and get a really simple, minimal python extension
compiling... and you guessed it, try and get them both compiling
together :)

There's a few wince folks hanging out on the libsdl mailing list if
you have troubles there.

cu,



On Wed, Aug 6, 2008 at 9:02 PM, Adam Walley <adam.walley at gmail.com> wrote:
> Well, I have been attempting to get something working, but have been
> struggling to get the SDL compiled correctly (without SDL, there is no point
> in trying to get pygame working). In my investigations, I came across the
> SCUMM forum. Now the SCUMMVM appears to be a fully working product on
> various platforms including WinCE. My attempts to compile some simple test
> programs using the SDL source available from the official SDL site failed
> (mostly because the source will not compile 'as is' and needs some tweaking
> which is probably beyond my capabilities). However, the SCUMM forum pointed
> me to a set of libraries from 'knakos'. I quickly set up a new project, with
> my simple test program, and lo! it compiled first time and tested correctly
> on my WM5 device. I assume these SCUMM libraries have already been adapted
> to work on WinCE, and since the SCUMM idea is to get retro graphical games
> working, I think that pygame will probably get all the functionality it
> needs from them.
>
> Now, on to getting pygame working! I will attempt to get some of the pygame
> source modules compiled as PYDs to see if they will import and work under
> PythonCE. I have not yet attempted to get a DLL compiled using these new
> libraries so may yet hit a wall. I will report back with any news.
>
> Rene, thanks for your comments. It's nice to know there is interest from the
> pygame side.
>
> If anyone else would like to provide comments/advice/code to get pygame
> working, it will be welcomed.
>
> Adam.
>
> On 06/08/2008, Ren? Dudfield <renesd at gmail.com> wrote:
>>
>> Hi,
>>
>> if anyone has any project files to build pygame on pythonce I'd love
>> to have them included with pygame.  I'm an author/maintainer of pygame
>> and have commit access to svn, so could add project files if someone
>> makes them... I could also add a pygame download for python CE to the
>> pygame.org download page.
>>
>> Or you could add compilation instructions to the pygame wiki here:
>> http://pygame.org/wiki/CompilePythonCE
>>
>> I have a winCE phone so would love to be able to get pygame running on it
>> :)
>>
>>
>> cheers,
>> _______________________________________________
>> PythonCE mailing list
>> PythonCE at python.org
>> http://mail.python.org/mailman/listinfo/pythonce
>
>

From adam.walley at gmail.com  Thu Aug  7 10:47:41 2008
From: adam.walley at gmail.com (Adam Walley)
Date: Thu, 7 Aug 2008 09:47:41 +0100
Subject: [PythonCE] pygame / distutils
In-Reply-To: <64ddb72c0808061609q12f0394ar1f15a26c09c308db@mail.gmail.com>
References: <64ddb72c0808052243s14e67d9emf4046645e1e48edf@mail.gmail.com>
	<518d94ee0808060402s2168fe23h31f5d14fefd07de8@mail.gmail.com>
	<64ddb72c0808061609q12f0394ar1f15a26c09c308db@mail.gmail.com>
Message-ID: <518d94ee0808070147x42913862y378f53038184aabd@mail.gmail.com>

My plans, exactly ;-) BTW why was pygame-ctypes abandoned? Reading some of
the past info on it, it seemed like a great idea to use the ctypes module.

2008/8/7 Ren? Dudfield <renesd at gmail.com>

> nice work :)
>
> It can be easier to first try and get the SDL test programs compiling.
>  Then try and get a really simple, minimal python extension
> compiling... and you guessed it, try and get them both compiling
> together :)
>
> There's a few wince folks hanging out on the libsdl mailing list if
> you have troubles there.
>
> cu,
>
>
>
> On Wed, Aug 6, 2008 at 9:02 PM, Adam Walley <adam.walley at gmail.com> wrote:
> > Well, I have been attempting to get something working, but have been
> > struggling to get the SDL compiled correctly (without SDL, there is no
> point
> > in trying to get pygame working). In my investigations, I came across the
> > SCUMM forum. Now the SCUMMVM appears to be a fully working product on
> > various platforms including WinCE. My attempts to compile some simple
> test
> > programs using the SDL source available from the official SDL site failed
> > (mostly because the source will not compile 'as is' and needs some
> tweaking
> > which is probably beyond my capabilities). However, the SCUMM forum
> pointed
> > me to a set of libraries from 'knakos'. I quickly set up a new project,
> with
> > my simple test program, and lo! it compiled first time and tested
> correctly
> > on my WM5 device. I assume these SCUMM libraries have already been
> adapted
> > to work on WinCE, and since the SCUMM idea is to get retro graphical
> games
> > working, I think that pygame will probably get all the functionality it
> > needs from them.
> >
> > Now, on to getting pygame working! I will attempt to get some of the
> pygame
> > source modules compiled as PYDs to see if they will import and work under
> > PythonCE. I have not yet attempted to get a DLL compiled using these new
> > libraries so may yet hit a wall. I will report back with any news.
> >
> > Rene, thanks for your comments. It's nice to know there is interest from
> the
> > pygame side.
> >
> > If anyone else would like to provide comments/advice/code to get pygame
> > working, it will be welcomed.
> >
> > Adam.
> >
> > On 06/08/2008, Ren? Dudfield <renesd at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> if anyone has any project files to build pygame on pythonce I'd love
> >> to have them included with pygame.  I'm an author/maintainer of pygame
> >> and have commit access to svn, so could add project files if someone
> >> makes them... I could also add a pygame download for python CE to the
> >> pygame.org download page.
> >>
> >> Or you could add compilation instructions to the pygame wiki here:
> >> http://pygame.org/wiki/CompilePythonCE
> >>
> >> I have a winCE phone so would love to be able to get pygame running on
> it
> >> :)
> >>
> >>
> >> cheers,
> >> _______________________________________________
> >> PythonCE mailing list
> >> PythonCE at python.org
> >> http://mail.python.org/mailman/listinfo/pythonce
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080807/84f46e3c/attachment.htm>

From jabapyth at gmail.com  Thu Aug  7 14:19:52 2008
From: jabapyth at gmail.com (Jared Forsyth)
Date: Thu, 7 Aug 2008 08:19:52 -0400
Subject: [PythonCE] pygame / distutils
In-Reply-To: <518d94ee0808070147x42913862y378f53038184aabd@mail.gmail.com>
References: <64ddb72c0808052243s14e67d9emf4046645e1e48edf@mail.gmail.com>
	<518d94ee0808060402s2168fe23h31f5d14fefd07de8@mail.gmail.com>
	<64ddb72c0808061609q12f0394ar1f15a26c09c308db@mail.gmail.com>
	<518d94ee0808070147x42913862y378f53038184aabd@mail.gmail.com>
Message-ID: <9a5375240808070519r69c5135bo5369457925a96f26@mail.gmail.com>

I, too came across the SCUMM files ;) and have gotten some test SDL c
programs to compile under cegcc.

On Thu, Aug 7, 2008 at 4:47 AM, Adam Walley <adam.walley at gmail.com> wrote:

> My plans, exactly ;-) BTW why was pygame-ctypes abandoned? Reading some of
> the past info on it, it seemed like a great idea to use the ctypes module.
>
> 2008/8/7 Ren? Dudfield <renesd at gmail.com>
>
> nice work :)
>>
>> It can be easier to first try and get the SDL test programs compiling.
>>  Then try and get a really simple, minimal python extension
>> compiling... and you guessed it, try and get them both compiling
>> together :)
>>
>> There's a few wince folks hanging out on the libsdl mailing list if
>> you have troubles there.
>>
>> cu,
>>
>>
>>
>> On Wed, Aug 6, 2008 at 9:02 PM, Adam Walley <adam.walley at gmail.com>
>> wrote:
>> > Well, I have been attempting to get something working, but have been
>> > struggling to get the SDL compiled correctly (without SDL, there is no
>> point
>> > in trying to get pygame working). In my investigations, I came across
>> the
>> > SCUMM forum. Now the SCUMMVM appears to be a fully working product on
>> > various platforms including WinCE. My attempts to compile some simple
>> test
>> > programs using the SDL source available from the official SDL site
>> failed
>> > (mostly because the source will not compile 'as is' and needs some
>> tweaking
>> > which is probably beyond my capabilities). However, the SCUMM forum
>> pointed
>> > me to a set of libraries from 'knakos'. I quickly set up a new project,
>> with
>> > my simple test program, and lo! it compiled first time and tested
>> correctly
>> > on my WM5 device. I assume these SCUMM libraries have already been
>> adapted
>> > to work on WinCE, and since the SCUMM idea is to get retro graphical
>> games
>> > working, I think that pygame will probably get all the functionality it
>> > needs from them.
>> >
>> > Now, on to getting pygame working! I will attempt to get some of the
>> pygame
>> > source modules compiled as PYDs to see if they will import and work
>> under
>> > PythonCE. I have not yet attempted to get a DLL compiled using these new
>> > libraries so may yet hit a wall. I will report back with any news.
>> >
>> > Rene, thanks for your comments. It's nice to know there is interest from
>> the
>> > pygame side.
>> >
>> > If anyone else would like to provide comments/advice/code to get pygame
>> > working, it will be welcomed.
>> >
>> > Adam.
>> >
>> > On 06/08/2008, Ren? Dudfield <renesd at gmail.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> if anyone has any project files to build pygame on pythonce I'd love
>> >> to have them included with pygame.  I'm an author/maintainer of pygame
>> >> and have commit access to svn, so could add project files if someone
>> >> makes them... I could also add a pygame download for python CE to the
>> >> pygame.org download page.
>> >>
>> >> Or you could add compilation instructions to the pygame wiki here:
>> >> http://pygame.org/wiki/CompilePythonCE
>> >>
>> >> I have a winCE phone so would love to be able to get pygame running on
>> it
>> >> :)
>> >>
>> >>
>> >> cheers,
>> >> _______________________________________________
>> >> PythonCE mailing list
>> >> PythonCE at python.org
>> >> http://mail.python.org/mailman/listinfo/pythonce
>> >
>> >
>>
>
>
> _______________________________________________
> PythonCE mailing list
> PythonCE at python.org
> http://mail.python.org/mailman/listinfo/pythonce
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080807/7f82d2e9/attachment.htm>

From adam.walley at gmail.com  Tue Aug 12 19:43:56 2008
From: adam.walley at gmail.com (Adam Walley)
Date: Tue, 12 Aug 2008 18:43:56 +0100
Subject: [PythonCE] DLL hourglass in ctypes
Message-ID: <518d94ee0808121043k42073c01ydb408027dc6ee683@mail.gmail.com>

Hello,

I am reporting back after some experimenting with building a DLL based on
the SDL library. I have successfully created a very simple DLL that accepts
5 int values (color, x,y,w,h) and uses the SDL_RectFill function to draw
directly to the screen. Then I use ctypes to import the DLL into pythonCE
and access its functions from there. This may seem very basic, but it allows
me to draw a rectangle of any size or colour to the screen, and I can do it
using very straightforward python script. The DLL lives in the main Windows
folder, and is automatically recognised by pythonCE when it starts.

My question is about the hourglass which appears on the screen while my
script is running (in WM5 it's actually not an hourglass, but a kind of
circular dial with windows colours). Is there any way I can prevent this
from appearing while my python script runs?

My next plan was to try to use ppygui to make some buttons for user input.

Any thoughts or comments are very welcome.

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080812/0e6c5192/attachment.htm>

From bkc at murkworks.com  Tue Aug 12 20:17:44 2008
From: bkc at murkworks.com (Brad Clements)
Date: Tue, 12 Aug 2008 14:17:44 -0400
Subject: [PythonCE] DLL hourglass in ctypes
In-Reply-To: <518d94ee0808121043k42073c01ydb408027dc6ee683@mail.gmail.com>
References: <518d94ee0808121043k42073c01ydb408027dc6ee683@mail.gmail.com>
Message-ID: <48A1D3C8.3040500@murkworks.com>

Adam Walley wrote:
>
>  
> My question is about the hourglass which appears on the screen while 
> my script is running (in WM5 it's actually not an hourglass, but a 
> kind of circular dial with windows colours). Is there any way I can 
> prevent this from appearing while my python script runs?

I do not recall exactly, but I vaguely remember something about this.  
Do you have a windows message loop running?

I think the hour glass stays there until you start processing windows 
messages.


-- 
Brad Clements,                bkc at murkworks.com    (315)268-1000
http://www.murkworks.com                          
AOL-IM: BKClements


From christopher at christec.co.nz  Tue Aug 12 23:59:50 2008
From: christopher at christec.co.nz (Christopher Fairbairn)
Date: Tue, 12 Aug 2008 17:59:50 -0400
Subject: [PythonCE] DLL hourglass in ctypes
Message-ID: <2229.1218578390@christec.co.nz>

Hi,

On Wed 13/08/08 05:43 , "Adam Walley" adam.walley at gmail.com sent:
> My question is about the hourglass which appears on the screen while
> my script is running (in WM5 it's actually not an hourglass, but a
> kind of circular dial with windows colours).

This is caused by a design decision from the original Windows CE port of Python.
The core executable displays a wait cursor and then waits for the internal shell
script (pcceshell.py) to load. One of the first things the shell script does is
turn off the wait cursor by calling back into the native C code.

If you run a script or do anything else which causes the python shell not to
load, the cursor won't be hidden. Libraries such as ppygui "resolve" this by
explictly hiding the wait cursor as part of their own initialisation process.

They use code along the lines of:

   import _pcceshell_support
  _pcceshell_support.Busy(0);

I haven't liked this, since it means each library needs to be aware of something
PythonCE specific. For cleaness I think the native C part of the Python
interpreter can (and should) take care of this.

Three options I experimented with were

1) Removing the wait cursor entirely if the PythonCE executable was being started
to run a specific script (didn't work too well, depending upon the size of your
script this meant the user was presented with no visual que that anything was
happening for a long period of time).

2) Modifying the script loading mechanism in pythonce.c so the native C code is
aware once the script has been parsed, but hasn't started execution and have it
explictly turn off the wait cursor before handing control over to the python code.

3) Always load the shell (even if PythonCE is started to run a specific script),
then launch the user script by simulating the user entering a call to the
execfile function.

If anyone is actively working on the core interpreter I would be happy to share
more detailed thoughts.

Hope it helps,
Christopher Fairbairn


From bkc at murkworks.com  Wed Aug 13 02:31:45 2008
From: bkc at murkworks.com (Brad Clements)
Date: Tue, 12 Aug 2008 20:31:45 -0400
Subject: [PythonCE] DLL hourglass in ctypes
In-Reply-To: <2229.1218578390@christec.co.nz>
References: <2229.1218578390@christec.co.nz>
Message-ID: <48A22B71.50505@murkworks.com>

Christopher Fairbairn wrote:
>
> They use code along the lines of:
>
>    import _pcceshell_support
>   _pcceshell_support.Busy(0);
>
> I haven't liked this, since it means each library needs to be aware of something
> PythonCE specific. For cleaness I think the native C part of the Python
> interpreter can (and should) take care of this.
>   
Ah, this rings a bell.

I think according to the Windows CE compatibility guide, you're supposed 
to show the hourglass until your application is "ready for user input".

I believe it's up to the application .py file, not any libraries or 
interpreter, to make the Busy(0) call.

Only the application author knows how many modules need to be loaded and 
when the application really has "started".



-- 
Brad Clements,                bkc at murkworks.com    (315)268-1000
http://www.murkworks.com                          
AOL-IM: BKClements


From pacopablo at pacopablo.com  Wed Aug 13 04:44:48 2008
From: pacopablo at pacopablo.com (John Hampton)
Date: Tue, 12 Aug 2008 19:44:48 -0700
Subject: [PythonCE] DLL hourglass in ctypes
In-Reply-To: <48A22B71.50505@murkworks.com>
References: <2229.1218578390@christec.co.nz> <48A22B71.50505@murkworks.com>
Message-ID: <48A24AA0.7050307@pacopablo.com>

Brad Clements wrote:
<snip>
> I think according to the Windows CE compatibility guide, you're supposed 
> to show the hourglass until your application is "ready for user input".
> 
> I believe it's up to the application .py file, not any libraries or 
> interpreter, to make the Busy(0) call.
> 
> Only the application author knows how many modules need to be loaded and 
> when the application really has "started".

I'll admit to being completely out of my league when it comes to how 
windows CE development should be done, however, I do like the idea of 
being able to leave the hourglas running until I'm "ready for input". 
I'm in the midst of creating a scanning application that will be loading 
quite a few modules, and it would be nice to have the visual clue that 
the user needs to wait.

Additionally, it would be nice to be able to turn on the hourglass when 
entering a method that may take a while to complete. (I'm sure there is 
probably an easy way to do this, I'm just not familiar with it yet.)

-John

From adam.walley at gmail.com  Wed Aug 13 10:49:57 2008
From: adam.walley at gmail.com (Adam Walley)
Date: Wed, 13 Aug 2008 09:49:57 +0100
Subject: [PythonCE] DLL hourglass in ctypes
In-Reply-To: <48A22B71.50505@murkworks.com>
References: <2229.1218578390@christec.co.nz> <48A22B71.50505@murkworks.com>
Message-ID: <518d94ee0808130149h3ec0247ci732fefb1a508fc10@mail.gmail.com>

Well, my initial question certainly seems to have stirred some interest.
Thanks to everyone for the input. I think what I can draw from all this is
that:

1. The hourglass/busy icon is useful to give users an indication of when the
application is busy 'grinding' away at something and user input is not
expected/possible at that time - as in the application John described in a
previous post.

2. The hourglass/busy icon is NOT helpful when the application is doing some
processing that involves some visual effects, since the hourglass/busy icon
then interferes and obscures the display. This is a nuisance, when the
application is trying to display something on screen (whether it requires
user input or not). I would say most pygame applications fall into this
category (and the idea of pygame for PythonCE is what prompted this post in
the first place).

My conclusion would be that while there is no harm in having this icon
appear by default, it cannot be left to the system to decide when the icon
should appear. Therefore, a method of 'disabling' the icon, at least for the
duration of the execution of a script, would be useful.

Jared kindly pointed out that the ppygui package already has this covered,
so at least in the first instance I will see whether I can combine what I
have built so far with ppygui to see if I can achieve a satisfactory result.

Thanks again to all.

Adam


2008/8/13 Brad Clements <bkc at murkworks.com>

> Christopher Fairbairn wrote:
>
>>
>> They use code along the lines of:
>>
>>   import _pcceshell_support
>>  _pcceshell_support.Busy(0);
>>
>> I haven't liked this, since it means each library needs to be aware of
>> something
>> PythonCE specific. For cleaness I think the native C part of the Python
>> interpreter can (and should) take care of this.
>>
>>
> Ah, this rings a bell.
>
> I think according to the Windows CE compatibility guide, you're supposed to
> show the hourglass until your application is "ready for user input".
>
> I believe it's up to the application .py file, not any libraries or
> interpreter, to make the Busy(0) call.
>
> Only the application author knows how many modules need to be loaded and
> when the application really has "started".
>
>
>
> --
> Brad Clements,                bkc at murkworks.com    (315)268-1000
> http://www.murkworks.com                          AOL-IM: BKClements
>
> _______________________________________________
> PythonCE mailing list
> PythonCE at python.org
> http://mail.python.org/mailman/listinfo/pythonce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080813/92329766/attachment.htm>

From adam.walley at gmail.com  Wed Aug 13 17:41:54 2008
From: adam.walley at gmail.com (Adam Walley)
Date: Wed, 13 Aug 2008 16:41:54 +0100
Subject: [PythonCE] DLL hourglass in ctypes
In-Reply-To: <518d94ee0808130149h3ec0247ci732fefb1a508fc10@mail.gmail.com>
References: <2229.1218578390@christec.co.nz> <48A22B71.50505@murkworks.com>
	<518d94ee0808130149h3ec0247ci732fefb1a508fc10@mail.gmail.com>
Message-ID: <518d94ee0808130841q5d3df080q7e63ca7e9903b554@mail.gmail.com>

Just one more note on this. Having tinkered a little with ppygui, I decided
that although it is a very fine package, it would not really help with what
I am aiming for - mainly because it is event based, whereas pygame apps
would tend to need 'real-time' interaction, rather than waiting for the user
to press something. If someone knows where/how I would put a main loop into
a ppygui app then let me know.

I did find that adding the lines:

   import _pcceshell_support
   _pcceshell_support.Busy(0)

worked like a dream! No more hourglass/busy indicator/color wheel or
whatever it's called (not knowing makes it harder to google). So thanks to
Christopher for that tip.

Adam.

2008/8/13 Adam Walley <adam.walley at gmail.com>

> Well, my initial question certainly seems to have stirred some interest.
> Thanks to everyone for the input. I think what I can draw from all this is
> that:
>
> 1. The hourglass/busy icon is useful to give users an indication of when
> the application is busy 'grinding' away at something and user input is not
> expected/possible at that time - as in the application John described in a
> previous post.
>
> 2. The hourglass/busy icon is NOT helpful when the application is doing
> some processing that involves some visual effects, since the hourglass/busy
> icon then interferes and obscures the display. This is a nuisance, when the
> application is trying to display something on screen (whether it requires
> user input or not). I would say most pygame applications fall into this
> category (and the idea of pygame for PythonCE is what prompted this post in
> the first place).
>
> My conclusion would be that while there is no harm in having this icon
> appear by default, it cannot be left to the system to decide when the icon
> should appear. Therefore, a method of 'disabling' the icon, at least for the
> duration of the execution of a script, would be useful.
>
> Jared kindly pointed out that the ppygui package already has this covered,
> so at least in the first instance I will see whether I can combine what I
> have built so far with ppygui to see if I can achieve a satisfactory result.
>
> Thanks again to all.
>
> Adam
>
>
> 2008/8/13 Brad Clements <bkc at murkworks.com>
>
> Christopher Fairbairn wrote:
>>
>>>
>>> They use code along the lines of:
>>>
>>>   import _pcceshell_support
>>>  _pcceshell_support.Busy(0);
>>>
>>> I haven't liked this, since it means each library needs to be aware of
>>> something
>>> PythonCE specific. For cleaness I think the native C part of the Python
>>> interpreter can (and should) take care of this.
>>>
>>>
>> Ah, this rings a bell.
>>
>> I think according to the Windows CE compatibility guide, you're supposed
>> to show the hourglass until your application is "ready for user input".
>>
>> I believe it's up to the application .py file, not any libraries or
>> interpreter, to make the Busy(0) call.
>>
>> Only the application author knows how many modules need to be loaded and
>> when the application really has "started".
>>
>>
>>
>> --
>> Brad Clements,                bkc at murkworks.com    (315)268-1000
>> http://www.murkworks.com                          AOL-IM: BKClements
>>
>> _______________________________________________
>> PythonCE mailing list
>> PythonCE at python.org
>> http://mail.python.org/mailman/listinfo/pythonce
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080813/30696c1d/attachment.htm>

From igor_kaplan at hotmail.com  Thu Aug 14 02:05:58 2008
From: igor_kaplan at hotmail.com (Igor Kaplan)
Date: Wed, 13 Aug 2008 20:05:58 -0400
Subject: [PythonCE] Programaticly moving cursor in multi-line edit control
In-Reply-To: <mailman.51.1218621613.22111.pythonce@python.org>
Message-ID: <BAY132-DAV11148C2C1176DF2781C1D09A720@phx.gbl>

Hello,

  I would like to ask a little advice. Already several days I am trying to
figure out the following problem using ppygui: How to move the cursor in the
edit field to the top of that field.
  In my code I create the frame and then Edit control:
Self.text_entry = gui.Edit(multiline=True)
    sizer = gui.VBox(border=(2,2,2,2), spacing=2)
    sizer.add(self.text_entry)
..

  Later I open the text file and copy it's context into that edit control:
    fl = open(self.filename, 'r')
    l = fl.readlines()
    self.text_entry.text = ""
    for i in l:
      self.text_entry.append(i)

  Only reason why I add the text such long way because if I just do:
Self.text_entry.text = fl.read()
I looze all line breaks and all text goes into 1 line.

  After opening that file I do:
Self.text_entry.selection = 0, 0

  And that line does nothing. For some reasons the cursor always positions
at the same spot in the Edit box after opening the file, somewhere in the
middle and does not want to go to the beginning.

  I also have another event:
Def OnBegin(self, event):
  Self.text_entry.selection = 0, 0

  That event executes on menu item. And something interesting is going on.
Sometimes cursor goes to the beginning of the edit control as it should do,
sometimes moves to some line of the edit box, again, somewhere at the
middle, sometimes just stays where it was.

  I am not sure, if I am doing something incorrectly or positioning of the
cursor does not work in ppygui?
  Would greatly appreciate any advice!

  Many thanks.

   Igor.



From alexandre.delattre at enst-bretagne.fr  Thu Aug 14 02:30:08 2008
From: alexandre.delattre at enst-bretagne.fr (Alexandre Delattre)
Date: Thu, 14 Aug 2008 02:30:08 +0200
Subject: [PythonCE] Programaticly moving cursor in multi-line edit
	control
In-Reply-To: <BAY132-DAV11148C2C1176DF2781C1D09A720@phx.gbl>
References: <BAY132-DAV11148C2C1176DF2781C1D09A720@phx.gbl>
Message-ID: <48A37C90.5020804@enst-bretagne.fr>

Igor,

 From what you say, I don't see what you could have done wrong.
can you send me the full source code  so I can give a try ?

Alexandre


From igor_kaplan at hotmail.com  Thu Aug 14 12:49:06 2008
From: igor_kaplan at hotmail.com (Igor Kaplan)
Date: Thu, 14 Aug 2008 06:49:06 -0400
Subject: [PythonCE] Programaticly moving cursor in multi-line edit control
In-Reply-To: <mailman.57.1218708013.12675.pythonce@python.org>
Message-ID: <BAY132-DAV13E5663E4048DBFFDB7F589A720@phx.gbl>

Hi Alexandre,

  Thanks a lot for your reply. I'll try to attach the source file to this
message, however not sure if this mailing list allows attachments, so I have
uploaded it also to my ftp side:
ftp://ftp.uliy.com/pub/python/te.py

  I tried to run this file on the smartphone and on PocketPc, the same
result. Was playing with OnOpen method detaching the Edit control from the
frame, adding the text and attaching it again, still the same, cursor does
not move.

  Would so much appreciate any comments.

Igor.

From: Alexandre Delattre <alexandre.delattre at enst-bretagne.fr>
Subject: Re: [PythonCE] Programaticly moving cursor in multi-line edit
	control
To: pythonce at python.org
Message-ID: <48A37C90.5020804 at enst-bretagne.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Igor,

 From what you say, I don't see what you could have done wrong.
can you send me the full source code  so I can give a try ?

Alexandre

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: te.py
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080814/12ecd4d6/attachment.txt>

From jabapyth at gmail.com  Thu Aug 14 13:40:51 2008
From: jabapyth at gmail.com (Jared Forsyth)
Date: Thu, 14 Aug 2008 07:40:51 -0400
Subject: [PythonCE] Programaticly moving cursor in multi-line edit
	control
In-Reply-To: <BAY132-DAV11148C2C1176DF2781C1D09A720@phx.gbl>
References: <mailman.51.1218621613.22111.pythonce@python.org>
	<BAY132-DAV11148C2C1176DF2781C1D09A720@phx.gbl>
Message-ID: <9a5375240808140440r5f675940lb1843e7b22330d57@mail.gmail.com>

The way to preserve linebreaks is tp replace "\n" with "\r\n"
so: self.text_entry.text = fl.read().replace("\n","\r\n")

On Wed, Aug 13, 2008 at 8:05 PM, Igor Kaplan <igor_kaplan at hotmail.com>wrote:

> Hello,
>
>  I would like to ask a little advice. Already several days I am trying to
> figure out the following problem using ppygui: How to move the cursor in
> the
> edit field to the top of that field.
>  In my code I create the frame and then Edit control:
> Self.text_entry = gui.Edit(multiline=True)
>    sizer = gui.VBox(border=(2,2,2,2), spacing=2)
>    sizer.add(self.text_entry)
> ..
>
>  Later I open the text file and copy it's context into that edit control:
>    fl = open(self.filename, 'r')
>    l = fl.readlines()
>    self.text_entry.text = ""
>    for i in l:
>      self.text_entry.append(i)
>
>  Only reason why I add the text such long way because if I just do:
> Self.text_entry.text = fl.read()
> I looze all line breaks and all text goes into 1 line.
>
>  After opening that file I do:
> Self.text_entry.selection = 0, 0
>
>  And that line does nothing. For some reasons the cursor always positions
> at the same spot in the Edit box after opening the file, somewhere in the
> middle and does not want to go to the beginning.
>
>  I also have another event:
> Def OnBegin(self, event):
>  Self.text_entry.selection = 0, 0
>
>  That event executes on menu item. And something interesting is going on.
> Sometimes cursor goes to the beginning of the edit control as it should do,
> sometimes moves to some line of the edit box, again, somewhere at the
> middle, sometimes just stays where it was.
>
>  I am not sure, if I am doing something incorrectly or positioning of the
> cursor does not work in ppygui?
>  Would greatly appreciate any advice!
>
>  Many thanks.
>
>   Igor.
>
>
> _______________________________________________
> PythonCE mailing list
> PythonCE at python.org
> http://mail.python.org/mailman/listinfo/pythonce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080814/c4f0e2bf/attachment.htm>

From alexandre.delattre at enst-bretagne.fr  Thu Aug 14 20:38:52 2008
From: alexandre.delattre at enst-bretagne.fr (Alexandre Delattre)
Date: Thu, 14 Aug 2008 20:38:52 +0200
Subject: [PythonCE] Programaticly moving cursor in multi-line edit
	control
In-Reply-To: <BAY132-DAV13E5663E4048DBFFDB7F589A720@phx.gbl>
References: <BAY132-DAV13E5663E4048DBFFDB7F589A720@phx.gbl>
Message-ID: <48A47BBC.6060009@enst-bretagne.fr>

Igor,

I've tested your app, and what happens really is that the cursor itself 
is moved at the beginning but the edit isn't scrolled to make it visible 
(if you press an hardware key or try to insert a few characters, you'll 
be then scrolled at the beginning). This seems to be the normal 
behaviour of windows ce.

There is at least 2 way to solve that:

1) Use the line proposed by Jared to make the conversion between unix 
and windows line endings, so the problem isn't even ask. I recommand you 
to use this in your case.

2) Make some "invisible" changes at the beginning of the Edit, so that 
the view is scrolled to show the change, you can use this snippet:

self.text_entry.selection = 0, 1
self.text_entry.selected_text = self.text_entry.selected_text
self.text_entry.selection = 0, 0

I think that, later, I'll surely implement scrolling methods so that 
kind of stuff could be done much more cleanly.

Hope it helps,
Alexandre

From igor_kaplan at hotmail.com  Fri Aug 15 01:56:59 2008
From: igor_kaplan at hotmail.com (Igor Kaplan)
Date: Thu, 14 Aug 2008 19:56:59 -0400
Subject: [PythonCE] Programaticly moving cursor in multi-line edit
	control
In-Reply-To: <9a5375240808140440r5f675940lb1843e7b22330d57@mail.gmail.com>
Message-ID: <BAY132-DAV9B0FA8360D407039B5F1D9A720@phx.gbl>

Hi Jared,

 

  Thanks so much for your advice, it solved the problem of loading file all
into 1 line, so loading is so much faster now!

  I am still trying to figure out the cursor movement issues.

 

  All the best.

 

  _____  

From: Jared Forsyth [mailto:jabapyth at gmail.com] 
Sent: Thursday, August 14, 2008 7:41 AM
To: Igor Kaplan
Cc: pythonce at python.org
Subject: Re: [PythonCE] Programaticly moving cursor in multi-line edit
control

 

The way to preserve linebreaks is tp replace "\n" with "\r\n"
so: self.text_entry.text = fl.read().replace("\n","\r\n")

On Wed, Aug 13, 2008 at 8:05 PM, Igor Kaplan <igor_kaplan at hotmail.com>
wrote:

Hello,

 I would like to ask a little advice. Already several days I am trying to
figure out the following problem using ppygui: How to move the cursor in the
edit field to the top of that field.
 In my code I create the frame and then Edit control:
Self.text_entry = gui.Edit(multiline=True)
   sizer = gui.VBox(border=(2,2,2,2), spacing=2)
   sizer.add(self.text_entry)
.

 Later I open the text file and copy it's context into that edit control:
   fl = open(self.filename, 'r')
   l = fl.readlines()
   self.text_entry.text = ""
   for i in l:
     self.text_entry.append(i)

 Only reason why I add the text such long way because if I just do:
Self.text_entry.text = fl.read()
I looze all line breaks and all text goes into 1 line.

 After opening that file I do:
Self.text_entry.selection = 0, 0

 And that line does nothing. For some reasons the cursor always positions
at the same spot in the Edit box after opening the file, somewhere in the
middle and does not want to go to the beginning.

 I also have another event:
Def OnBegin(self, event):
 Self.text_entry.selection = 0, 0

 That event executes on menu item. And something interesting is going on.
Sometimes cursor goes to the beginning of the edit control as it should do,
sometimes moves to some line of the edit box, again, somewhere at the
middle, sometimes just stays where it was.

 I am not sure, if I am doing something incorrectly or positioning of the
cursor does not work in ppygui?
 Would greatly appreciate any advice!

 Many thanks.

  Igor.


_______________________________________________
PythonCE mailing list
PythonCE at python.org
http://mail.python.org/mailman/listinfo/pythonce

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080814/bc593b7c/attachment-0001.htm>

From igor_kaplan at hotmail.com  Fri Aug 15 03:25:30 2008
From: igor_kaplan at hotmail.com (Igor Kaplan)
Date: Thu, 14 Aug 2008 21:25:30 -0400
Subject: [PythonCE] Programaticly moving cursor in multi-line edit
In-Reply-To: <mailman.16870.1218758221.920.pythonce@python.org>
Message-ID: <BAY132-DAV1315E10970528964E5D41E9A6D0@phx.gbl>

Hi Alexandre,

  Thanks a lot for your suggestion, it worked, so now moving to the
beginning and to the end of the edit control works perfectly fine.
  Ppygui is being such a wonderful library, just love it!

  Many thanks and all the best.

  Igor.

From: Alexandre Delattre <alexandre.delattre at enst-bretagne.fr>
Subject: Re: [PythonCE] Programaticly moving cursor in multi-line edit
	control
To: pythonce at python.org
Message-ID: <48A47BBC.6060009 at enst-bretagne.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Igor,

I've tested your app, and what happens really is that the cursor itself is
moved at the beginning but the edit isn't scrolled to make it visible (if
you press an hardware key or try to insert a few characters, you'll be then
scrolled at the beginning). This seems to be the normal behaviour of windows
ce.

There is at least 2 way to solve that:

1) Use the line proposed by Jared to make the conversion between unix and
windows line endings, so the problem isn't even ask. I recommand you to use
this in your case.

2) Make some "invisible" changes at the beginning of the Edit, so that the
view is scrolled to show the change, you can use this snippet:

self.text_entry.selection = 0, 1
self.text_entry.selected_text = self.text_entry.selected_text
self.text_entry.selection = 0, 0

I think that, later, I'll surely implement scrolling methods so that kind of
stuff could be done much more cleanly.

Hope it helps,
Alexandre




From renesd at gmail.com  Fri Aug 15 03:56:26 2008
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Fri, 15 Aug 2008 11:56:26 +1000
Subject: [PythonCE] pygame / distutils
In-Reply-To: <518d94ee0808070147x42913862y378f53038184aabd@mail.gmail.com>
References: <64ddb72c0808052243s14e67d9emf4046645e1e48edf@mail.gmail.com>
	<518d94ee0808060402s2168fe23h31f5d14fefd07de8@mail.gmail.com>
	<64ddb72c0808061609q12f0394ar1f15a26c09c308db@mail.gmail.com>
	<518d94ee0808070147x42913862y378f53038184aabd@mail.gmail.com>
Message-ID: <64ddb72c0808141856j75be7a1er191463a96e606d35@mail.gmail.com>

What is the best way to compile extensions for python CE ?

Adam: do you have a link to those SCUMVM files?

Any further progress?

Why not pygame-ctypes?  It was slow, buggy, and non-portable - and C
pygame worked fine.  The author was paid to do it, and stopped when
the money ran out and moved on to pyglet.  pygame has a bunch of C
code which just can't run fast enough in python.  Pygame is not just a
SDL wrapper, it's got a bunch of other code in it too.  ctypes has an
overhead for each call which is annoying for real time apps.
However... pygame-ctypes is still useful for some things, and if pypy
ever gets fast it will become more important (assuming they never
release a C api for pypy).

anyway...


I'd going to try the following order of things...
- get a simple C program to compile and run on the device.
- get a simple C python extension module working.
- get a simple SDL program working.
- get some pygame modules running.
- get full pygame test suite working.
- port pygame example programs so they work ok on pythonCE too.




On Thu, Aug 7, 2008 at 6:47 PM, Adam Walley <adam.walley at gmail.com> wrote:
> My plans, exactly ;-) BTW why was pygame-ctypes abandoned? Reading some of
> the past info on it, it seemed like a great idea to use the ctypes module.
>
> 2008/8/7 Ren? Dudfield <renesd at gmail.com>
>>
>> nice work :)
>>
>> It can be easier to first try and get the SDL test programs compiling.
>>  Then try and get a really simple, minimal python extension
>> compiling... and you guessed it, try and get them both compiling
>> together :)
>>
>> There's a few wince folks hanging out on the libsdl mailing list if
>> you have troubles there.
>>
>> cu,
>>
>>
>>
>> On Wed, Aug 6, 2008 at 9:02 PM, Adam Walley <adam.walley at gmail.com> wrote:
>> > Well, I have been attempting to get something working, but have been
>> > struggling to get the SDL compiled correctly (without SDL, there is no
>> > point
>> > in trying to get pygame working). In my investigations, I came across
>> > the
>> > SCUMM forum. Now the SCUMMVM appears to be a fully working product on
>> > various platforms including WinCE. My attempts to compile some simple
>> > test
>> > programs using the SDL source available from the official SDL site
>> > failed
>> > (mostly because the source will not compile 'as is' and needs some
>> > tweaking
>> > which is probably beyond my capabilities). However, the SCUMM forum
>> > pointed
>> > me to a set of libraries from 'knakos'. I quickly set up a new project,
>> > with
>> > my simple test program, and lo! it compiled first time and tested
>> > correctly
>> > on my WM5 device. I assume these SCUMM libraries have already been
>> > adapted
>> > to work on WinCE, and since the SCUMM idea is to get retro graphical
>> > games
>> > working, I think that pygame will probably get all the functionality it
>> > needs from them.
>> >
>> > Now, on to getting pygame working! I will attempt to get some of the
>> > pygame
>> > source modules compiled as PYDs to see if they will import and work
>> > under
>> > PythonCE. I have not yet attempted to get a DLL compiled using these new
>> > libraries so may yet hit a wall. I will report back with any news.
>> >
>> > Rene, thanks for your comments. It's nice to know there is interest from
>> > the
>> > pygame side.
>> >
>> > If anyone else would like to provide comments/advice/code to get pygame
>> > working, it will be welcomed.
>> >
>> > Adam.
>> >
>> > On 06/08/2008, Ren? Dudfield <renesd at gmail.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> if anyone has any project files to build pygame on pythonce I'd love
>> >> to have them included with pygame.  I'm an author/maintainer of pygame
>> >> and have commit access to svn, so could add project files if someone
>> >> makes them... I could also add a pygame download for python CE to the
>> >> pygame.org download page.
>> >>
>> >> Or you could add compilation instructions to the pygame wiki here:
>> >> http://pygame.org/wiki/CompilePythonCE
>> >>
>> >> I have a winCE phone so would love to be able to get pygame running on
>> >> it
>> >> :)
>> >>
>> >>
>> >> cheers,
>> >> _______________________________________________
>> >> PythonCE mailing list
>> >> PythonCE at python.org
>> >> http://mail.python.org/mailman/listinfo/pythonce
>> >
>> >
>
>

From jabapyth at gmail.com  Fri Aug 15 13:38:17 2008
From: jabapyth at gmail.com (Jared Forsyth)
Date: Fri, 15 Aug 2008 07:38:17 -0400
Subject: [PythonCE] Programaticly moving cursor in multi-line edit
	control
In-Reply-To: <BAY132-DAV9B0FA8360D407039B5F1D9A720@phx.gbl>
References: <9a5375240808140440r5f675940lb1843e7b22330d57@mail.gmail.com>
	<BAY132-DAV9B0FA8360D407039B5F1D9A720@phx.gbl>
Message-ID: <9a5375240808150438k14d85545n345340933511cd7f@mail.gmail.com>

Have you played around with different values for selection? like
self.text_edit.selection = 1,1.....etc.
If they all fail, you might want to try going in and firing off the actual
underlying win32 message

Good luck

On Thu, Aug 14, 2008 at 7:56 PM, Igor Kaplan <igor_kaplan at hotmail.com>wrote:

>  Hi Jared,
>
>
>
>   Thanks so much for your advice, it solved the problem of loading file all
> into 1 line, so loading is so much faster now!
>
>   I am still trying to figure out the cursor movement issues.
>
>
>
>   All the best.
>
>
>  ------------------------------
>
> *From:* Jared Forsyth [mailto:jabapyth at gmail.com]
> *Sent:* Thursday, August 14, 2008 7:41 AM
> *To:* Igor Kaplan
> *Cc:* pythonce at python.org
> *Subject:* Re: [PythonCE] Programaticly moving cursor in multi-line edit
> control
>
>
>
> The way to preserve linebreaks is tp replace "\n" with "\r\n"
> so: self.text_entry.text = fl.read().replace("\n","\r\n")
>
> On Wed, Aug 13, 2008 at 8:05 PM, Igor Kaplan <igor_kaplan at hotmail.com>
> wrote:
>
> Hello,
>
>  I would like to ask a little advice. Already several days I am trying to
> figure out the following problem using ppygui: How to move the cursor in
> the
> edit field to the top of that field.
>  In my code I create the frame and then Edit control:
> Self.text_entry = gui.Edit(multiline=True)
>    sizer = gui.VBox(border=(2,2,2,2), spacing=2)
>    sizer.add(self.text_entry)
> .
>
>  Later I open the text file and copy it's context into that edit control:
>    fl = open(self.filename, 'r')
>    l = fl.readlines()
>    self.text_entry.text = ""
>    for i in l:
>      self.text_entry.append(i)
>
>  Only reason why I add the text such long way because if I just do:
> Self.text_entry.text = fl.read()
> I looze all line breaks and all text goes into 1 line.
>
>  After opening that file I do:
> Self.text_entry.selection = 0, 0
>
>  And that line does nothing. For some reasons the cursor always positions
> at the same spot in the Edit box after opening the file, somewhere in the
> middle and does not want to go to the beginning.
>
>  I also have another event:
> Def OnBegin(self, event):
>  Self.text_entry.selection = 0, 0
>
>  That event executes on menu item. And something interesting is going on.
> Sometimes cursor goes to the beginning of the edit control as it should do,
> sometimes moves to some line of the edit box, again, somewhere at the
> middle, sometimes just stays where it was.
>
>  I am not sure, if I am doing something incorrectly or positioning of the
> cursor does not work in ppygui?
>  Would greatly appreciate any advice!
>
>  Many thanks.
>
>   Igor.
>
>
> _______________________________________________
> PythonCE mailing list
> PythonCE at python.org
> http://mail.python.org/mailman/listinfo/pythonce
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080815/d4272bc4/attachment.htm>

From adam.walley at gmail.com  Fri Aug 15 14:26:20 2008
From: adam.walley at gmail.com (Adam Walley)
Date: Fri, 15 Aug 2008 13:26:20 +0100
Subject: [PythonCE] pygame / distutils
In-Reply-To: <64ddb72c0808141856j75be7a1er191463a96e606d35@mail.gmail.com>
References: <64ddb72c0808052243s14e67d9emf4046645e1e48edf@mail.gmail.com>
	<518d94ee0808060402s2168fe23h31f5d14fefd07de8@mail.gmail.com>
	<64ddb72c0808061609q12f0394ar1f15a26c09c308db@mail.gmail.com>
	<518d94ee0808070147x42913862y378f53038184aabd@mail.gmail.com>
	<64ddb72c0808141856j75be7a1er191463a96e606d35@mail.gmail.com>
Message-ID: <518d94ee0808150526g9b97ddfx2f29f46e33b719f1@mail.gmail.com>

Hi, Rene.

Thanks for the clarification on pygame-ctypes. The link where I found the
SCUMMVM SDL libraries is here:

http://users.uoa.gr/~knakos/scummvm/libraries/release-0-10-0/wince-gcc-libs.tar.bz2

There are a number of files in there, including a .diff file which may shed
some light on some of the difficulties in compiling the SDL libraries. The
SDL version used is 1.2.6. I believe the latest one is 1.2.13, but I think
this should not be a big issue to update later.

As far as my progress goes, I have got a small pythonCE script running,
which draws some coloured squares to the screen (kind of like one of the
slide transition effects in powerpoint). The busy indicator no longer
interferes with the display :D

Now, I am working on a bit of code to allow user input. I am adapting the
code to allow key presses of the PDA's hardware function keys to be
detected. I would like this to be a small module that can be used in
PythonCE to get the scancode from any key press (from the SIP or the
hardware keys). I know that SDL provides this, but I am not sure if it will
allow the hardware keys to be detected.

>From what I understand, there is some extra work in writing a PYD module, in
contrast to writing a DLL that is called with ctypes. I have not looked into
this in great detail yet, but ultimately, I would like to get some DLLs
written in the correct form so they can be used as PYDs. I guess there are
some basic rules for Python to 'talk' with its package modules.

Anyhow, your plan sounds good, so if there's any way I can help just let me
know.

Adam


On 15/08/2008, Ren? Dudfield <renesd at gmail.com> wrote:
>
> What is the best way to compile extensions for python CE ?
>
> Adam: do you have a link to those SCUMVM files?
>
> Any further progress?
>
> Why not pygame-ctypes?  It was slow, buggy, and non-portable - and C
> pygame worked fine.  The author was paid to do it, and stopped when
> the money ran out and moved on to pyglet.  pygame has a bunch of C
> code which just can't run fast enough in python.  Pygame is not just a
> SDL wrapper, it's got a bunch of other code in it too.  ctypes has an
> overhead for each call which is annoying for real time apps.
> However... pygame-ctypes is still useful for some things, and if pypy
> ever gets fast it will become more important (assuming they never
> release a C api for pypy).
>
> anyway...
>
>
> I'd going to try the following order of things...
> - get a simple C program to compile and run on the device.
> - get a simple C python extension module working.
> - get a simple SDL program working.
> - get some pygame modules running.
> - get full pygame test suite working.
> - port pygame example programs so they work ok on pythonCE too.
>
>
>
>
> On Thu, Aug 7, 2008 at 6:47 PM, Adam Walley <adam.walley at gmail.com> wrote:
> > My plans, exactly ;-) BTW why was pygame-ctypes abandoned? Reading some
> of
> > the past info on it, it seemed like a great idea to use the ctypes
> module.
> >
> > 2008/8/7 Ren? Dudfield <renesd at gmail.com>
> >>
> >> nice work :)
> >>
> >> It can be easier to first try and get the SDL test programs compiling.
> >>  Then try and get a really simple, minimal python extension
> >> compiling... and you guessed it, try and get them both compiling
> >> together :)
> >>
> >> There's a few wince folks hanging out on the libsdl mailing list if
> >> you have troubles there.
> >>
> >> cu,
> >>
> >>
> >>
> >> On Wed, Aug 6, 2008 at 9:02 PM, Adam Walley <adam.walley at gmail.com>
> wrote:
> >> > Well, I have been attempting to get something working, but have been
> >> > struggling to get the SDL compiled correctly (without SDL, there is no
> >> > point
> >> > in trying to get pygame working). In my investigations, I came across
> >> > the
> >> > SCUMM forum. Now the SCUMMVM appears to be a fully working product on
> >> > various platforms including WinCE. My attempts to compile some simple
> >> > test
> >> > programs using the SDL source available from the official SDL site
> >> > failed
> >> > (mostly because the source will not compile 'as is' and needs some
> >> > tweaking
> >> > which is probably beyond my capabilities). However, the SCUMM forum
> >> > pointed
> >> > me to a set of libraries from 'knakos'. I quickly set up a new
> project,
> >> > with
> >> > my simple test program, and lo! it compiled first time and tested
> >> > correctly
> >> > on my WM5 device. I assume these SCUMM libraries have already been
> >> > adapted
> >> > to work on WinCE, and since the SCUMM idea is to get retro graphical
> >> > games
> >> > working, I think that pygame will probably get all the functionality
> it
> >> > needs from them.
> >> >
> >> > Now, on to getting pygame working! I will attempt to get some of the
> >> > pygame
> >> > source modules compiled as PYDs to see if they will import and work
> >> > under
> >> > PythonCE. I have not yet attempted to get a DLL compiled using these
> new
> >> > libraries so may yet hit a wall. I will report back with any news.
> >> >
> >> > Rene, thanks for your comments. It's nice to know there is interest
> from
> >> > the
> >> > pygame side.
> >> >
> >> > If anyone else would like to provide comments/advice/code to get
> pygame
> >> > working, it will be welcomed.
> >> >
> >> > Adam.
> >> >
> >> > On 06/08/2008, Ren? Dudfield <renesd at gmail.com> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> if anyone has any project files to build pygame on pythonce I'd love
> >> >> to have them included with pygame.  I'm an author/maintainer of
> pygame
> >> >> and have commit access to svn, so could add project files if someone
> >> >> makes them... I could also add a pygame download for python CE to the
> >> >> pygame.org download page.
> >> >>
> >> >> Or you could add compilation instructions to the pygame wiki here:
> >> >> http://pygame.org/wiki/CompilePythonCE
> >> >>
> >> >> I have a winCE phone so would love to be able to get pygame running
> on
> >> >> it
> >> >> :)
> >> >>
> >> >>
> >> >> cheers,
> >> >> _______________________________________________
> >> >> PythonCE mailing list
> >> >> PythonCE at python.org
> >> >> http://mail.python.org/mailman/listinfo/pythonce
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080815/e3c1790e/attachment.htm>

From jabapyth at gmail.com  Fri Aug 15 16:55:01 2008
From: jabapyth at gmail.com (Jared Forsyth)
Date: Fri, 15 Aug 2008 10:55:01 -0400
Subject: [PythonCE] pygame / distutils
In-Reply-To: <518d94ee0808150526g9b97ddfx2f29f46e33b719f1@mail.gmail.com>
References: <64ddb72c0808052243s14e67d9emf4046645e1e48edf@mail.gmail.com>
	<518d94ee0808060402s2168fe23h31f5d14fefd07de8@mail.gmail.com>
	<64ddb72c0808061609q12f0394ar1f15a26c09c308db@mail.gmail.com>
	<518d94ee0808070147x42913862y378f53038184aabd@mail.gmail.com>
	<64ddb72c0808141856j75be7a1er191463a96e606d35@mail.gmail.com>
	<518d94ee0808150526g9b97ddfx2f29f46e33b719f1@mail.gmail.com>
Message-ID: <9a5375240808150755q66dbae6cqf804fdc2bdfc9dae@mail.gmail.com>

I have successfully compiled SDL, and compiled several SDL programs in
cegcc.
To compile SDL:
Grab SDL 1.2.6 <http://www.libsdl.org/release/SDL-1.2.6.tar.gz>
Grab this patch <
http://users.uoa.gr/~knakos/scummvm/libraries/libsdl_20070610_diff>
Unzip SDL: tar -zxf SDL-1.2.6.tar.gz
apply the patch (in the base SDL directory): patch -p0 < libsdl*diff
go into the makefile (created by the patch) and replace all (about 3)
occurrences of arm-wince-pe with arm-wince-mingw32ce
run make (it should run without a hitch): ./make
grab the resulting libSDL.lib from the build directory, drop it in your
/opt/mingw32ce...../lib/ directory
dont forget the header files in include/
And then your good to go!

Heres a command line script you can run:

wget http://www.libsdl.org/release/SDL-1.2.6.tar.gz
tar -zxf SDL-1.2.6.tar.gz
cd SDL-1.2.6
wget http://users.uoa.gr/~knakos/scummvm/libraries/libsdl_20070610_diff
patch -p0 < libsdl_20070610_diff
cat Makefile | sed -e 's/arm-wince-pe/arm-wince-mingw32ce/' > Makefile2
mv Makefile2 Makefile
make
sudo cp libSDL.lib /opt/mingw32ce/arm-wince-mingw32ce/lib/
cd ..
rm SDL-1.2.6.tar.gz
rm -r SDL-1.2.6
wget
http://users.uoa.gr/~knakos/scummvm/libraries/release-0-10-0/wince-gcc-libs.tar.bz2
sudo -jxf wince-gcc-libs.ta.bz2
cd libs/include
sudo cp sdl /opt/mingw32ce/arm-wince-mingw32ce/include/
cd ../..
rm -r libs
rm wince-gcc-libs.tar.bz2

and your done!! compile SDL programs with the command:
arm-wince-mingw32ce-gcc testsdl.c -o test.exe -llibSDL

Cheers! Ill probs put this up on the wiki soon...

On Fri, Aug 15, 2008 at 8:26 AM, Adam Walley <adam.walley at gmail.com> wrote:

> Hi, Rene.
>
> Thanks for the clarification on pygame-ctypes. The link where I found the
> SCUMMVM SDL libraries is here:
>
>
> http://users.uoa.gr/~knakos/scummvm/libraries/release-0-10-0/wince-gcc-libs.tar.bz2<http://users.uoa.gr/%7Eknakos/scummvm/libraries/release-0-10-0/wince-gcc-libs.tar.bz2>
>
> There are a number of files in there, including a .diff file which may shed
> some light on some of the difficulties in compiling the SDL libraries. The
> SDL version used is 1.2.6. I believe the latest one is 1.2.13, but I think
> this should not be a big issue to update later.
>
> As far as my progress goes, I have got a small pythonCE script running,
> which draws some coloured squares to the screen (kind of like one of the
> slide transition effects in powerpoint). The busy indicator no longer
> interferes with the display :D
>
> Now, I am working on a bit of code to allow user input. I am adapting the
> code to allow key presses of the PDA's hardware function keys to be
> detected. I would like this to be a small module that can be used in
> PythonCE to get the scancode from any key press (from the SIP or the
> hardware keys). I know that SDL provides this, but I am not sure if it will
> allow the hardware keys to be detected.
>
> From what I understand, there is some extra work in writing a PYD module,
> in contrast to writing a DLL that is called with ctypes. I have not looked
> into this in great detail yet, but ultimately, I would like to get some DLLs
> written in the correct form so they can be used as PYDs. I guess there are
> some basic rules for Python to 'talk' with its package modules.
>
> Anyhow, your plan sounds good, so if there's any way I can help just let me
> know.
>
> Adam
>
>
> On 15/08/2008, Ren? Dudfield <renesd at gmail.com> wrote:
>>
>> What is the best way to compile extensions for python CE ?
>>
>> Adam: do you have a link to those SCUMVM files?
>>
>> Any further progress?
>>
>> Why not pygame-ctypes?  It was slow, buggy, and non-portable - and C
>> pygame worked fine.  The author was paid to do it, and stopped when
>> the money ran out and moved on to pyglet.  pygame has a bunch of C
>> code which just can't run fast enough in python.  Pygame is not just a
>> SDL wrapper, it's got a bunch of other code in it too.  ctypes has an
>> overhead for each call which is annoying for real time apps.
>> However... pygame-ctypes is still useful for some things, and if pypy
>> ever gets fast it will become more important (assuming they never
>> release a C api for pypy).
>>
>> anyway...
>>
>>
>> I'd going to try the following order of things...
>> - get a simple C program to compile and run on the device.
>> - get a simple C python extension module working.
>> - get a simple SDL program working.
>> - get some pygame modules running.
>> - get full pygame test suite working.
>> - port pygame example programs so they work ok on pythonCE too.
>>
>>
>>
>>
>> On Thu, Aug 7, 2008 at 6:47 PM, Adam Walley <adam.walley at gmail.com>
>> wrote:
>> > My plans, exactly ;-) BTW why was pygame-ctypes abandoned? Reading some
>> of
>> > the past info on it, it seemed like a great idea to use the ctypes
>> module.
>> >
>> > 2008/8/7 Ren? Dudfield <renesd at gmail.com>
>> >>
>> >> nice work :)
>> >>
>> >> It can be easier to first try and get the SDL test programs compiling.
>> >>  Then try and get a really simple, minimal python extension
>> >> compiling... and you guessed it, try and get them both compiling
>> >> together :)
>> >>
>> >> There's a few wince folks hanging out on the libsdl mailing list if
>> >> you have troubles there.
>> >>
>> >> cu,
>> >>
>> >>
>> >>
>> >> On Wed, Aug 6, 2008 at 9:02 PM, Adam Walley <adam.walley at gmail.com>
>> wrote:
>> >> > Well, I have been attempting to get something working, but have been
>> >> > struggling to get the SDL compiled correctly (without SDL, there is
>> no
>> >> > point
>> >> > in trying to get pygame working). In my investigations, I came across
>> >> > the
>> >> > SCUMM forum. Now the SCUMMVM appears to be a fully working product on
>> >> > various platforms including WinCE. My attempts to compile some simple
>> >> > test
>> >> > programs using the SDL source available from the official SDL site
>> >> > failed
>> >> > (mostly because the source will not compile 'as is' and needs some
>> >> > tweaking
>> >> > which is probably beyond my capabilities). However, the SCUMM forum
>> >> > pointed
>> >> > me to a set of libraries from 'knakos'. I quickly set up a new
>> project,
>> >> > with
>> >> > my simple test program, and lo! it compiled first time and tested
>> >> > correctly
>> >> > on my WM5 device. I assume these SCUMM libraries have already been
>> >> > adapted
>> >> > to work on WinCE, and since the SCUMM idea is to get retro graphical
>> >> > games
>> >> > working, I think that pygame will probably get all the functionality
>> it
>> >> > needs from them.
>> >> >
>> >> > Now, on to getting pygame working! I will attempt to get some of the
>> >> > pygame
>> >> > source modules compiled as PYDs to see if they will import and work
>> >> > under
>> >> > PythonCE. I have not yet attempted to get a DLL compiled using these
>> new
>> >> > libraries so may yet hit a wall. I will report back with any news.
>> >> >
>> >> > Rene, thanks for your comments. It's nice to know there is interest
>> from
>> >> > the
>> >> > pygame side.
>> >> >
>> >> > If anyone else would like to provide comments/advice/code to get
>> pygame
>> >> > working, it will be welcomed.
>> >> >
>> >> > Adam.
>> >> >
>> >> > On 06/08/2008, Ren? Dudfield <renesd at gmail.com> wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> if anyone has any project files to build pygame on pythonce I'd love
>> >> >> to have them included with pygame.  I'm an author/maintainer of
>> pygame
>> >> >> and have commit access to svn, so could add project files if someone
>> >> >> makes them... I could also add a pygame download for python CE to
>> the
>> >> >> pygame.org download page.
>> >> >>
>> >> >> Or you could add compilation instructions to the pygame wiki here:
>> >> >> http://pygame.org/wiki/CompilePythonCE
>> >> >>
>> >> >> I have a winCE phone so would love to be able to get pygame running
>> on
>> >> >> it
>> >> >> :)
>> >> >>
>> >> >>
>> >> >> cheers,
>> >> >> _______________________________________________
>> >> >> PythonCE mailing list
>> >> >> PythonCE at python.org
>> >> >> http://mail.python.org/mailman/listinfo/pythonce
>> >> >
>> >> >
>> >
>> >
>>
>
>
> _______________________________________________
> PythonCE mailing list
> PythonCE at python.org
> http://mail.python.org/mailman/listinfo/pythonce
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080815/4d580b4f/attachment-0001.htm>

From alexandre.delattre at enst-bretagne.fr  Fri Aug 15 18:14:49 2008
From: alexandre.delattre at enst-bretagne.fr (Alexandre Delattre)
Date: Fri, 15 Aug 2008 18:14:49 +0200
Subject: [PythonCE] pygame / distutils
Message-ID: <200808151615.m7FGF7I8005131@courrier.enst-bretagne.fr>

Jared & Adam,
Glad to hear you were able to cross compile sdl with cegcc, this opens the possibility to compile pygame with cegcc, which may yield better results than Microsoft tools :)

Some times ago, I've sent Jared a PythonCE 2.5 import library and an scons script to easily compile Python modules with cegcc. I think they'll be useful for compiling pygame.

(Btw, I have a working PIL port built this way that I'll be happy to put online soon)

Jared, did you manage to compile SDL_Image on top of SDL ?
I think it's the only extra dll that is needed by pygame to work. 
I remember that when compiling with embedded vc++ this dll was compiled almost out of the box since the low level calls were handled by SDL so no porting was required.
Would be cool to have SDL_Mixer too.

Best regards,
Alexandre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080815/43dda045/attachment.htm>

From jabapyth at gmail.com  Fri Aug 15 18:45:26 2008
From: jabapyth at gmail.com (Jared Forsyth)
Date: Fri, 15 Aug 2008 12:45:26 -0400
Subject: [PythonCE] pygame / distutils
In-Reply-To: <200808151615.m7FGF7I8005131@courrier.enst-bretagne.fr>
References: <200808151615.m7FGF7I8005131@courrier.enst-bretagne.fr>
Message-ID: <9a5375240808150945x2ac289f3i72a473947c157a23@mail.gmail.com>

i tried, but not very hard. configure worked fine, but during make it
complained about iconv.h some other include....and looking in legacy
versions of cegcc, iconv.h *was* included in the mingw32ce dist....but i
dunno. Ill probs work on it some more this week, to try to get it working

Jared

On Fri, Aug 15, 2008 at 12:14 PM, Alexandre Delattre <
alexandre.delattre at enst-bretagne.fr> wrote:

> Jared & Adam,
> Glad to hear you were able to cross compile sdl with cegcc, this opens the
> possibility to compile pygame with cegcc, which may yield better results
> than Microsoft tools :)
>
> Some times ago, I've sent Jared a PythonCE 2.5 import library and an scons
> script to easily compile Python modules with cegcc. I think they'll be
> useful for compiling pygame.
>
> (Btw, I have a working PIL port built this way that I'll be happy to put
> online soon)
>
> Jared, did you manage to compile SDL_Image on top of SDL ?
> I think it's the only extra dll that is needed by pygame to work.
> I remember that when compiling with embedded vc++ this dll was compiled
> almost out of the box since the low level calls were handled by SDL so no
> porting was required.
> Would be cool to have SDL_Mixer too.
>
> Best regards,
> Alexandre
>
> _______________________________________________
> PythonCE mailing list
> PythonCE at python.org
> http://mail.python.org/mailman/listinfo/pythonce
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080815/870294d1/attachment.htm>

From theller at ctypes.org  Fri Aug 15 21:50:03 2008
From: theller at ctypes.org (Thomas Heller)
Date: Fri, 15 Aug 2008 21:50:03 +0200
Subject: [PythonCE] Installation of Python packages on Windows CE
Message-ID: <g84mld$tue$1@ger.gmane.org>

How should Python packages be installed on Windows CE?

The context is that I am preparing a new release of comtypes.

I have learned so far on this list that a CAB file is a convenient way
to install software, but my question is what should this cab file create:

- as usual on Windows, a directory tree containing .py files in \Program Files\Python\Python25

or

- a zipfile in \Program Files\Python\Python25 which would be put on sys.path
  by a .pth file in the same directory and imported by the zipimport mechanism?

  For the zip-file, there are again several possibilities:

  - should the zipfile be compressed to save space or not?  I'm not
    sure if decompressing slows down importing or not...

  - Should the zipfile contain only .pyc files to save space, but
    then source code is not available for tracebacks, for example

  - Should the zipfile contain only .py files to save space, but
    importing would probably be slower because the modules have to
    be recompiled every time Python uses them

  - Should the zipfile contain .py files plus .pyc files?

Or are there even other possibilities?

-- 
Thanks,
Thomas


From pacopablo at pacopablo.com  Fri Aug 15 23:52:19 2008
From: pacopablo at pacopablo.com (John Hampton)
Date: Fri, 15 Aug 2008 14:52:19 -0700
Subject: [PythonCE] Installation of Python packages on Windows CE
In-Reply-To: <g84mld$tue$1@ger.gmane.org>
References: <g84mld$tue$1@ger.gmane.org>
Message-ID: <48A5FA93.6030607@pacopablo.com>

Thomas Heller wrote:
> I have learned so far on this list that a CAB file is a convenient way
> to install software, but my question is what should this cab file create:
> 
> - as usual on Windows, a directory tree containing .py files in \Program Files\Python\Python25

This is the method that I would prefer.  A zipimport is neat, and could 
save space, but all the other issues I think out weigh the space savings 
that would come from zipimport.

I know that Alexandre has some code in ppygui to pull the location of 
the site-packages dir.

-John

From jabapyth at gmail.com  Sat Aug 16 03:03:04 2008
From: jabapyth at gmail.com (Jared Forsyth)
Date: Fri, 15 Aug 2008 21:03:04 -0400
Subject: [PythonCE] Installation of Python packages on Windows CE
In-Reply-To: <48A5FA93.6030607@pacopablo.com>
References: <g84mld$tue$1@ger.gmane.org> <48A5FA93.6030607@pacopablo.com>
Message-ID: <9a5375240808151803i6cfb3266u5c38fd0a5fe55746@mail.gmail.com>

the default install location for python is \Program Files\Python25 -- not
\Program Files\Python\Python25

On Fri, Aug 15, 2008 at 5:52 PM, John Hampton <pacopablo at pacopablo.com>wrote:

> Thomas Heller wrote:
>
>> I have learned so far on this list that a CAB file is a convenient way
>> to install software, but my question is what should this cab file create:
>>
>> - as usual on Windows, a directory tree containing .py files in \Program
>> Files\Python\Python25
>>
>
> This is the method that I would prefer.  A zipimport is neat, and could
> save space, but all the other issues I think out weigh the space savings
> that would come from zipimport.
>
> I know that Alexandre has some code in ppygui to pull the location of the
> site-packages dir.
>
> -John
>
> _______________________________________________
> PythonCE mailing list
> PythonCE at python.org
> http://mail.python.org/mailman/listinfo/pythonce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080815/2c72499b/attachment.htm>

From renesd at gmail.com  Sat Aug 16 03:31:13 2008
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Sat, 16 Aug 2008 11:31:13 +1000
Subject: [PythonCE] pygame / distutils
In-Reply-To: <9a5375240808150755q66dbae6cqf804fdc2bdfc9dae@mail.gmail.com>
References: <64ddb72c0808052243s14e67d9emf4046645e1e48edf@mail.gmail.com>
	<518d94ee0808060402s2168fe23h31f5d14fefd07de8@mail.gmail.com>
	<64ddb72c0808061609q12f0394ar1f15a26c09c308db@mail.gmail.com>
	<518d94ee0808070147x42913862y378f53038184aabd@mail.gmail.com>
	<64ddb72c0808141856j75be7a1er191463a96e606d35@mail.gmail.com>
	<518d94ee0808150526g9b97ddfx2f29f46e33b719f1@mail.gmail.com>
	<9a5375240808150755q66dbae6cqf804fdc2bdfc9dae@mail.gmail.com>
Message-ID: <64ddb72c0808151831j3678f8b1kb88b739d5facf6f@mail.gmail.com>

cool.  Thanks for the notes.

I've downloaded the cegcc from here: http://cegcc.sourceforge.net/

I got this file, since I'm using cygwin: cygwin-cegcc-mingw32ce-0.51.0-1.tar.gz
Is that the one you're using?

It seems pythonce itself is compiled with the embedded visual C++ 4.0 :
http://pythonce.sourceforge.net/Wikka/SConsBuild

... now for more reading and tinkering...

cu,


On Sat, Aug 16, 2008 at 12:55 AM, Jared Forsyth <jabapyth at gmail.com> wrote:
> I have successfully compiled SDL, and compiled several SDL programs in
> cegcc.
> To compile SDL:
> Grab SDL 1.2.6 <http://www.libsdl.org/release/SDL-1.2.6.tar.gz>
> Grab this patch
> <http://users.uoa.gr/~knakos/scummvm/libraries/libsdl_20070610_diff>
> Unzip SDL: tar -zxf SDL-1.2.6.tar.gz
> apply the patch (in the base SDL directory): patch -p0 < libsdl*diff
> go into the makefile (created by the patch) and replace all (about 3)
> occurrences of arm-wince-pe with arm-wince-mingw32ce
> run make (it should run without a hitch): ./make
> grab the resulting libSDL.lib from the build directory, drop it in your
> /opt/mingw32ce...../lib/ directory
> dont forget the header files in include/
> And then your good to go!
>
> Heres a command line script you can run:
>
> wget http://www.libsdl.org/release/SDL-1.2.6.tar.gz
> tar -zxf SDL-1.2.6.tar.gz
> cd SDL-1.2.6
> wget http://users.uoa.gr/~knakos/scummvm/libraries/libsdl_20070610_diff
> patch -p0 < libsdl_20070610_diff
> cat Makefile | sed -e 's/arm-wince-pe/arm-wince-mingw32ce/' > Makefile2
> mv Makefile2 Makefile
> make
> sudo cp libSDL.lib /opt/mingw32ce/arm-wince-mingw32ce/lib/
> cd ..
> rm SDL-1.2.6.tar.gz
> rm -r SDL-1.2.6
> wget
> http://users.uoa.gr/~knakos/scummvm/libraries/release-0-10-0/wince-gcc-libs.tar.bz2
> sudo -jxf wince-gcc-libs.ta.bz2
> cd libs/include
> sudo cp sdl /opt/mingw32ce/arm-wince-mingw32ce/include/
> cd ../..
> rm -r libs
> rm wince-gcc-libs.tar.bz2
>
> and your done!! compile SDL programs with the command:
> arm-wince-mingw32ce-gcc testsdl.c -o test.exe -llibSDL
>
> Cheers! Ill probs put this up on the wiki soon...
>
> On Fri, Aug 15, 2008 at 8:26 AM, Adam Walley <adam.walley at gmail.com> wrote:
>>
>> Hi, Rene.
>>
>> Thanks for the clarification on pygame-ctypes. The link where I found the
>> SCUMMVM SDL libraries is here:
>>
>>
>> http://users.uoa.gr/~knakos/scummvm/libraries/release-0-10-0/wince-gcc-libs.tar.bz2
>>
>> There are a number of files in there, including a .diff file which may
>> shed some light on some of the difficulties in compiling the SDL libraries.
>> The SDL version used is 1.2.6. I believe the latest one is 1.2.13, but I
>> think this should not be a big issue to update later.
>>
>> As far as my progress goes, I have got a small pythonCE script running,
>> which draws some coloured squares to the screen (kind of like one of the
>> slide transition effects in powerpoint). The busy indicator no longer
>> interferes with the display :D
>>
>> Now, I am working on a bit of code to allow user input. I am adapting the
>> code to allow key presses of the PDA's hardware function keys to be
>> detected. I would like this to be a small module that can be used in
>> PythonCE to get the scancode from any key press (from the SIP or the
>> hardware keys). I know that SDL provides this, but I am not sure if it will
>> allow the hardware keys to be detected.
>>
>> From what I understand, there is some extra work in writing a PYD module,
>> in contrast to writing a DLL that is called with ctypes. I have not looked
>> into this in great detail yet, but ultimately, I would like to get some DLLs
>> written in the correct form so they can be used as PYDs. I guess there are
>> some basic rules for Python to 'talk' with its package modules.
>>
>> Anyhow, your plan sounds good, so if there's any way I can help just let
>> me know.
>>
>> Adam
>>
>> On 15/08/2008, Ren? Dudfield <renesd at gmail.com> wrote:
>>>
>>> What is the best way to compile extensions for python CE ?
>>>
>>> Adam: do you have a link to those SCUMVM files?
>>>
>>> Any further progress?
>>>
>>> Why not pygame-ctypes?  It was slow, buggy, and non-portable - and C
>>> pygame worked fine.  The author was paid to do it, and stopped when
>>> the money ran out and moved on to pyglet.  pygame has a bunch of C
>>> code which just can't run fast enough in python.  Pygame is not just a
>>> SDL wrapper, it's got a bunch of other code in it too.  ctypes has an
>>> overhead for each call which is annoying for real time apps.
>>> However... pygame-ctypes is still useful for some things, and if pypy
>>> ever gets fast it will become more important (assuming they never
>>> release a C api for pypy).
>>>
>>> anyway...
>>>
>>>
>>> I'd going to try the following order of things...
>>> - get a simple C program to compile and run on the device.
>>> - get a simple C python extension module working.
>>> - get a simple SDL program working.
>>> - get some pygame modules running.
>>> - get full pygame test suite working.
>>> - port pygame example programs so they work ok on pythonCE too.
>>>
>>>
>>>
>>>
>>> On Thu, Aug 7, 2008 at 6:47 PM, Adam Walley <adam.walley at gmail.com>
>>> wrote:
>>> > My plans, exactly ;-) BTW why was pygame-ctypes abandoned? Reading some
>>> > of
>>> > the past info on it, it seemed like a great idea to use the ctypes
>>> > module.
>>> >
>>> > 2008/8/7 Ren? Dudfield <renesd at gmail.com>
>>> >>
>>> >> nice work :)
>>> >>
>>> >> It can be easier to first try and get the SDL test programs compiling.
>>> >>  Then try and get a really simple, minimal python extension
>>> >> compiling... and you guessed it, try and get them both compiling
>>> >> together :)
>>> >>
>>> >> There's a few wince folks hanging out on the libsdl mailing list if
>>> >> you have troubles there.
>>> >>
>>> >> cu,
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Aug 6, 2008 at 9:02 PM, Adam Walley <adam.walley at gmail.com>
>>> >> wrote:
>>> >> > Well, I have been attempting to get something working, but have been
>>> >> > struggling to get the SDL compiled correctly (without SDL, there is
>>> >> > no
>>> >> > point
>>> >> > in trying to get pygame working). In my investigations, I came
>>> >> > across
>>> >> > the
>>> >> > SCUMM forum. Now the SCUMMVM appears to be a fully working product
>>> >> > on
>>> >> > various platforms including WinCE. My attempts to compile some
>>> >> > simple
>>> >> > test
>>> >> > programs using the SDL source available from the official SDL site
>>> >> > failed
>>> >> > (mostly because the source will not compile 'as is' and needs some
>>> >> > tweaking
>>> >> > which is probably beyond my capabilities). However, the SCUMM forum
>>> >> > pointed
>>> >> > me to a set of libraries from 'knakos'. I quickly set up a new
>>> >> > project,
>>> >> > with
>>> >> > my simple test program, and lo! it compiled first time and tested
>>> >> > correctly
>>> >> > on my WM5 device. I assume these SCUMM libraries have already been
>>> >> > adapted
>>> >> > to work on WinCE, and since the SCUMM idea is to get retro graphical
>>> >> > games
>>> >> > working, I think that pygame will probably get all the functionality
>>> >> > it
>>> >> > needs from them.
>>> >> >
>>> >> > Now, on to getting pygame working! I will attempt to get some of the
>>> >> > pygame
>>> >> > source modules compiled as PYDs to see if they will import and work
>>> >> > under
>>> >> > PythonCE. I have not yet attempted to get a DLL compiled using these
>>> >> > new
>>> >> > libraries so may yet hit a wall. I will report back with any news.
>>> >> >
>>> >> > Rene, thanks for your comments. It's nice to know there is interest
>>> >> > from
>>> >> > the
>>> >> > pygame side.
>>> >> >
>>> >> > If anyone else would like to provide comments/advice/code to get
>>> >> > pygame
>>> >> > working, it will be welcomed.
>>> >> >
>>> >> > Adam.
>>> >> >
>>> >> > On 06/08/2008, Ren? Dudfield <renesd at gmail.com> wrote:
>>> >> >>
>>> >> >> Hi,
>>> >> >>
>>> >> >> if anyone has any project files to build pygame on pythonce I'd
>>> >> >> love
>>> >> >> to have them included with pygame.  I'm an author/maintainer of
>>> >> >> pygame
>>> >> >> and have commit access to svn, so could add project files if
>>> >> >> someone
>>> >> >> makes them... I could also add a pygame download for python CE to
>>> >> >> the
>>> >> >> pygame.org download page.
>>> >> >>
>>> >> >> Or you could add compilation instructions to the pygame wiki here:
>>> >> >> http://pygame.org/wiki/CompilePythonCE
>>> >> >>
>>> >> >> I have a winCE phone so would love to be able to get pygame running
>>> >> >> on
>>> >> >> it
>>> >> >> :)
>>> >> >>
>>> >> >>
>>> >> >> cheers,
>>> >> >> _______________________________________________
>>> >> >> PythonCE mailing list
>>> >> >> PythonCE at python.org
>>> >> >> http://mail.python.org/mailman/listinfo/pythonce
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>
>> _______________________________________________
>> PythonCE mailing list
>> PythonCE at python.org
>> http://mail.python.org/mailman/listinfo/pythonce
>>
>
>

From renesd at gmail.com  Sat Aug 16 03:35:04 2008
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Sat, 16 Aug 2008 11:35:04 +1000
Subject: [PythonCE] pygame / distutils
In-Reply-To: <200808151615.m7FGF7I8005131@courrier.enst-bretagne.fr>
References: <200808151615.m7FGF7I8005131@courrier.enst-bretagne.fr>
Message-ID: <64ddb72c0808151835u7104cacdu550fdc96c2f13efb@mail.gmail.com>

hi,

On Sat, Aug 16, 2008 at 2:14 AM, Alexandre Delattre
<alexandre.delattre at enst-bretagne.fr> wrote:
> Jared & Adam,
> Glad to hear you were able to cross compile sdl with cegcc, this opens the
> possibility to compile pygame with cegcc, which may yield better results
> than Microsoft tools :)
>
> Some times ago, I've sent Jared a PythonCE 2.5 import library and an scons
> script to easily compile Python modules with cegcc. I think they'll be
> useful for compiling pygame.
>


Do you have a link to that stuff?  Or could you email it to me?


> (Btw, I have a working PIL port built this way that I'll be happy to put
> online soon)
>

Awesome :)  Is there a central place for pythonCE ports?


> Jared, did you manage to compile SDL_Image on top of SDL ?
> I think it's the only extra dll that is needed by pygame to work.
> I remember that when compiling with embedded vc++ this dll was compiled
> almost out of the box since the low level calls were handled by SDL so no
> porting was required.
> Would be cool to have SDL_Mixer too.
>
> Best regards,
> Alexandre

From akrpic77 at gmail.com  Mon Aug 18 12:38:33 2008
From: akrpic77 at gmail.com (Andrej Krpic)
Date: Mon, 18 Aug 2008 12:38:33 +0200
Subject: [PythonCE] Komodo remote debugging
Message-ID: <336094d30808180338n764ab807t3565dbeda7e286ae@mail.gmail.com>

Hello,
I'm exploring options for pythonCE remote debugging.
One of them appears to be Active State's Komodo.
Files required to remotely debug in Active State's Komodo are in zip
reachable at:
www.2muchbeauty.com/Komodo-PythonRemoteDebugging-4.4.1-20896-wince-arm.zip

installing:
extract dbgp in \program files\python25\lib, put pydgbp.py from bin anywere
you want (be it root for example).

using:
use rapi tools (http://www.xs4all.nl/~itsme/projects/xda/tools.html,
excellent!) to remotely run python,
to run pydbgp to debug your-script.py

> prun.exe "\program files\python25\python.exe" \pydgbp.py -d HOST:PORT
your-script.py
be sure to have Komodo listening for debugging connections (check Listener
Status for port)

issues:
your-script.py must be in root

Andrej
(note: I'm not affiliated with ActiveState in anyway)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080818/0f4c2c0f/attachment.htm>

From adam.walley at gmail.com  Tue Aug 19 18:25:39 2008
From: adam.walley at gmail.com (Adam Walley)
Date: Tue, 19 Aug 2008 17:25:39 +0100
Subject: [PythonCE] pass Python string to C char *
Message-ID: <518d94ee0808190925w37f72a9ev34a1c602efd70b5b@mail.gmail.com>

Hi, All.

This question has probably been resolved many times over on various forums,
but I was wondering what the best way is to pass a Python string (in my case
a file path) to a DLL written in C that expects a char* input?

Any suggestions?

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080819/239a24bf/attachment.htm>

From adam.walley at gmail.com  Wed Aug 20 01:01:34 2008
From: adam.walley at gmail.com (Adam Walley)
Date: Wed, 20 Aug 2008 00:01:34 +0100
Subject: [PythonCE] pass Python string to C char *
In-Reply-To: <9a5375240808191411y1abcc022ya4b57736670a0dd9@mail.gmail.com>
References: <518d94ee0808190925w37f72a9ev34a1c602efd70b5b@mail.gmail.com>
	<9a5375240808191411y1abcc022ya4b57736670a0dd9@mail.gmail.com>
Message-ID: <518d94ee0808191601l3aa084bo975ea3cf9c87cb57@mail.gmail.com>

Hi, Jared.

Thanks for the tip. I came across c_char_p("mystring"), but have not been
able to get it working. I also attempted a create_string_buffer("mystring"),
but also without success. I have not checked this fully yet, so may still
get it working...

Adam.


On 19/08/2008, Jared Forsyth <jabapyth at gmail.com> wrote:
>
> i believe its ctypes.c_str("mystring"). or maybe its c_char
>
>  On Tue, Aug 19, 2008 at 12:25 PM, Adam Walley <adam.walley at gmail.com>wrote:
>
>>  Hi, All.
>>
>> This question has probably been resolved many times over on various
>> forums, but I was wondering what the best way is to pass a Python string (in
>> my case a file path) to a DLL written in C that expects a char* input?
>>
>> Any suggestions?
>>
>> Adam
>>
>>
>>
>>
>> _______________________________________________
>> PythonCE mailing list
>> PythonCE at python.org
>> http://mail.python.org/mailman/listinfo/pythonce
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080820/63f9a2b9/attachment.htm>

From adam.walley at gmail.com  Wed Aug 20 13:48:03 2008
From: adam.walley at gmail.com (Adam Walley)
Date: Wed, 20 Aug 2008 12:48:03 +0100
Subject: [PythonCE] pass Python string to C char *
In-Reply-To: <518d94ee0808191601l3aa084bo975ea3cf9c87cb57@mail.gmail.com>
References: <518d94ee0808190925w37f72a9ev34a1c602efd70b5b@mail.gmail.com>
	<9a5375240808191411y1abcc022ya4b57736670a0dd9@mail.gmail.com>
	<518d94ee0808191601l3aa084bo975ea3cf9c87cb57@mail.gmail.com>
Message-ID: <518d94ee0808200448q457fd549s8cc0b9c2febe3a2c@mail.gmail.com>

Well, it works! I realised I had not updated the DLL on my device (that's
what comes of working late). Just for the record, I have tested two methods,
and both work fine to pass a string to a C dll requiring a char * input:

1. use mystr1=c_char_p("mystring")
2. use mystr2=create_string_buffer("mystring")

Both methods require the ctypes module and work equally well with the DLL,
but there are some differences (all of which I am not aware at the moment).
Method 1 creates a ctypes Array object, whereas method 2 appears to create
something which behaves more like a standard Python string.

Adam

2008/8/20 Adam Walley <adam.walley at gmail.com>

> Hi, Jared.
>
> Thanks for the tip. I came across c_char_p("mystring"), but have not been
> able to get it working. I also attempted a create_string_buffer("mystring"),
> but also without success. I have not checked this fully yet, so may still
> get it working...
>
> Adam.
>
>
> On 19/08/2008, Jared Forsyth <jabapyth at gmail.com> wrote:
>>
>> i believe its ctypes.c_str("mystring"). or maybe its c_char
>>
>>  On Tue, Aug 19, 2008 at 12:25 PM, Adam Walley <adam.walley at gmail.com>wrote:
>>
>>>  Hi, All.
>>>
>>> This question has probably been resolved many times over on various
>>> forums, but I was wondering what the best way is to pass a Python string (in
>>> my case a file path) to a DLL written in C that expects a char* input?
>>>
>>> Any suggestions?
>>>
>>> Adam
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> PythonCE mailing list
>>> PythonCE at python.org
>>> http://mail.python.org/mailman/listinfo/pythonce
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080820/1c9cd586/attachment.htm>

From alexandre.delattre at enst-bretagne.fr  Fri Aug 22 15:42:17 2008
From: alexandre.delattre at enst-bretagne.fr (Alexandre Delattre)
Date: Fri, 22 Aug 2008 15:42:17 +0200
Subject: [PythonCE] pass Python string to C char *
In-Reply-To: <518d94ee0808200448q457fd549s8cc0b9c2febe3a2c@mail.gmail.com>
References: <518d94ee0808200448q457fd549s8cc0b9c2febe3a2c@mail.gmail.com>
Message-ID: <48AEC239.5070304@enst-bretagne.fr>

 > Well, it works! I realised I had not updated the DLL on my device (that's
 > what comes of working late). Just for the record, I have tested two 
methods,
 > and both work fine to pass a string to a C dll requiring a char * input:

1. use mystr1=c_char_p("mystring")
2. use mystr2=create_string_buffer("mystring")

 > Both methods require the ctypes module and work equally well with the 
DLL,
 > but there are some differences (all of which I am not aware at the 
moment).
 > Method 1 creates a ctypes Array object, whereas method 2 appears to 
create
 > something which behaves more like a standard Python string.

 From my experience, it sounds to me that c_char_p creates a wrapper 
over an existing python string that is suitable for being passed as 
argument in a ctypes dll function.

create_string_buffer will duplicate the content of the string in an 
internal buffer and the resulting object will provide a fixed-length 
array interface to modify this buffer from python.

This one should be used when the c function will modify the char* 
argument in place (i.e. write directly in this buffer). Since python 
strings are supposed to be immutable (with the benefit of being hashable 
and so insertable as keys in a dict) first method should not be used here.

cheers,
Alexandre


From adam.walley at gmail.com  Fri Aug 29 18:43:37 2008
From: adam.walley at gmail.com (Adam Walley)
Date: Fri, 29 Aug 2008 17:43:37 +0100
Subject: [PythonCE] pygame / ctypes / SDL
Message-ID: <518d94ee0808290943m110f4079jf3d0ac44582d280e@mail.gmail.com>

Well, I have now got a small demo app working, which makes use of SDL
LoadBMP, Surface, blit, audio (wav), keysym, and draw functions. I have
compiled a small DLL, that allows access to these functions through ctypes,
and it works very well. The core of the application is a python script,
which then calls the other functions as required.

I will try to post a link shortly, for any one who would like to take a
look. I am wondering whether this whole exercise is kind of re-inventing the
wheel, since pygame-ctypes was already attempted. However, so far everything
seems to be working smoothly, and I am quite encouraged by the results.

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080829/f1cc844f/attachment.htm>

From theller at ctypes.org  Fri Aug 29 19:58:17 2008
From: theller at ctypes.org (Thomas Heller)
Date: Fri, 29 Aug 2008 19:58:17 +0200
Subject: [PythonCE] pygame / ctypes / SDL
In-Reply-To: <518d94ee0808290943m110f4079jf3d0ac44582d280e@mail.gmail.com>
References: <518d94ee0808290943m110f4079jf3d0ac44582d280e@mail.gmail.com>
Message-ID: <g99dbp$q20$2@ger.gmane.org>

Adam Walley schrieb:
> Well, I have now got a small demo app working, which makes use of SDL
> LoadBMP, Surface, blit, audio (wav), keysym, and draw functions. I have
> compiled a small DLL, that allows access to these functions through ctypes,
> and it works very well. The core of the application is a python script,
> which then calls the other functions as required.
> 
> I will try to post a link shortly, for any one who would like to take a
> look. I am wondering whether this whole exercise is kind of re-inventing the
> wheel, since pygame-ctypes was already attempted. However, so far everything
> seems to be working smoothly, and I am quite encouraged by the results.

Cool.  But, I'm curious: what about pyglet?  Has someone tried to port that to WinCE?

-- 
Thanks,
Thomas


From jabapyth at gmail.com  Sat Aug 30 01:44:57 2008
From: jabapyth at gmail.com (Jared Forsyth)
Date: Fri, 29 Aug 2008 19:44:57 -0400
Subject: [PythonCE] pygame / ctypes / SDL
In-Reply-To: <g99dbp$q20$2@ger.gmane.org>
References: <518d94ee0808290943m110f4079jf3d0ac44582d280e@mail.gmail.com>
	<g99dbp$q20$2@ger.gmane.org>
Message-ID: <9a5375240808291644h4cf13eedh1f876e3b85137523@mail.gmail.com>

now thats cool idea

On Fri, Aug 29, 2008 at 1:58 PM, Thomas Heller <theller at ctypes.org> wrote:

> Adam Walley schrieb:
> > Well, I have now got a small demo app working, which makes use of SDL
> > LoadBMP, Surface, blit, audio (wav), keysym, and draw functions. I have
> > compiled a small DLL, that allows access to these functions through
> ctypes,
> > and it works very well. The core of the application is a python script,
> > which then calls the other functions as required.
> >
> > I will try to post a link shortly, for any one who would like to take a
> > look. I am wondering whether this whole exercise is kind of re-inventing
> the
> > wheel, since pygame-ctypes was already attempted. However, so far
> everything
> > seems to be working smoothly, and I am quite encouraged by the results.
>
> Cool.  But, I'm curious: what about pyglet?  Has someone tried to port that
> to WinCE?
>
> --
> Thanks,
> Thomas
>
> _______________________________________________
> PythonCE mailing list
> PythonCE at python.org
> http://mail.python.org/mailman/listinfo/pythonce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080829/f7872ca9/attachment.htm>

From louis at braillesoft.net  Sat Aug 30 23:56:53 2008
From: louis at braillesoft.net (louis at braillesoft.net)
Date: Sat, 30 Aug 2008 14:56:53 -0700
Subject: [PythonCE] Import Error?
Message-ID: <023a01c90aeb$51296730$22046647@BrailleSoft>

Hi. My name is Louis Bryant. I am new to Python, especially PythonCE and have and am already facing an issue. I followed the instructions given at Pocket PC Python website. When I run Python from my Start Menu though, I get an error saying that traceback can't be imported because there is no file named OS. Though, no files are missing. OS is inside the \Program Files\Python\Lib folder, along with traceback and a bunch of Python modules. How can I fix this? It won't even let me run a Python program from the command-line, the error is the same. Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080830/1984fe4b/attachment.htm>

From louis at braillesoft.net  Sun Aug 31 00:35:11 2008
From: louis at braillesoft.net (louis at braillesoft.net)
Date: Sat, 30 Aug 2008 15:35:11 -0700
Subject: [PythonCE] Creating Windows CE Exe from Python?
Message-ID: <025101c90af0$aa55fa80$22046647@BrailleSoft>

Hi. Is it possible to generate an executable from your Python program that run on Windows CE? Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonce/attachments/20080830/9f1e1acc/attachment.htm>

From pacopablo at pacopablo.com  Sun Aug 31 08:24:45 2008
From: pacopablo at pacopablo.com (John Hampton)
Date: Sat, 30 Aug 2008 23:24:45 -0700
Subject: [PythonCE] Import Error?
In-Reply-To: <023a01c90aeb$51296730$22046647@BrailleSoft>
References: <023a01c90aeb$51296730$22046647@BrailleSoft>
Message-ID: <48BA392D.4060906@pacopablo.com>

louis at braillesoft.net wrote:
> Hi. My name is Louis Bryant. I am new to Python, especially PythonCE and 
> have and am already facing an issue. I followed the instructions given 
> at Pocket PC Python website. When I run Python from my Start Menu 
> though, I get an error saying that traceback can't be imported because 
> there is no file named OS. Though, no files are missing. OS is inside 
> the \Program Files\Python\Lib folder, along with traceback and a bunch 
> of Python modules. How can I fix this? It won't even let me run a Python 
> program from the command-line, the error is the same. Thanks.

Louis,

As you're new to both Python and PythonCE, it would be helpful for those 
trying to help, to know exactly what, and where you're having an error.

What version of Python are you using?  When referring to the Start menu, 
  I'm assuming you're referring to the Windows Mobile device?  Can you 
specify the exact error shown when you're trying to run python?

Also, what device and windows version are you using?


-John