[maemo-developers] Home applet questions

2007-01-30 Thread Christoph Würstle
Hi,

I wrote a small home applet (showing gpe todos and appointments).
It works nice, but I have two issues:

1. how can I get the right themed border (in standard theme the blue one)

2. and a very basic question: what's the simplest way to gt the ui
updating (new buttons/labes/etc) at hildon_home_applet_lib_foreground in
a background process (I'm new to c programming)

Thanks,
Chris
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] cx3110x source code is for the nokia800?

2007-01-30 Thread Koen Kooi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Komal Shah schreef:
> On 1/30/07, Koen Kooi <[EMAIL PROTECTED]> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi,
>>
>> Is the cx3110x source code is for the nokia800 available somewhere?
>>
> 
> I don't think that it is available. It is binary only module 

Geez, how bad does nokia want to get sued for GPL violations?

> because
> of chip manufacturer and many other things.

Where "chip manufacturer and many other things" read "complete and utter 
bullshit"


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFwEhrMkyGM64RGpERAjfeAJ4p75BiTx5A9oeipNsMvujx4A4nAQCeOm/a
dW4hmfCdMMbenGEVd8VvXZs=
=V0gE
-END PGP SIGNATURE-
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] to Nokia: simple method to gainagamingaudienceon 770/800

2007-01-30 Thread Tapani Pälli
ext Clemens Eisserer wrote:
> and here we are again.
>
?
> Why is the virtual keybord restricted to GTK applications? Is a simply
> interface which would require some addotion of toolkits really so hard
> to create?
> *PLEASE* create an cross-toolkit API for non-gtk apps - which works
> clean and without hacks. There is real demand for it, really.
>

It's not _restricted_, it uses X messaging so it's technically possible
to use with other toolkits. For SDL games, I would still recommend to
implement own simple solution. Ideally it would be posted to libsdl.org
then and could be used by anyone out there.

> lg Clemens
>
> 2007/1/26, Tapani Pälli <[EMAIL PROTECTED]>:
>> ext [EMAIL PROTECTED] wrote:
>> >> On 1/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> >>
>> >>>  * easy to make basic GUI for game setup (input methods do
>> >>>
>> >> not work in
>> >>
>> >>> SDL)
>> >>>
>> >> Hello
>> >>
>> >> I guess anybody how is porting a SDL game will run into the
>> >> keyboard issue problem.
>> >> It would be nice if we can port existing SDL games but that
>> >> really means that we need a cute keyboard input hack. I have
>> >> been asking around but did not find a simple pluggable virtual
>> >> keyboard for sdl.
>> >> perhaps pointer to such resources would help. but otherwise I
>> >> think some effort must be put into that.
>> >>
>> >> greetings
>> >>
>> >
>> > Hi,
>> >
>> > This has been studied briefly, and since SDL games are a very colorful
>> > bunch we felt that a solution to suit "SDL games" is a very illusive
>> > target, we would not get a solution that suits all and it would be a
>> > hack complicating things evern futher.
>> >
>> > The startup screen has been seen as a significantly more elegant
>> way of
>> > dealing with most of the cases and so far it has proven right (how
>> many
>> > games require text entry during the gameplay?).
>> >
>> >
>>
>> One solution for this would be to provide a nice and minimal keyboard
>> class which would return inputted text just as a string and not really
>> emit keyevents. The API for keyboard should be minimalistic so that
>> porting textentries needed for ip-address, highscrore etc. would be
>> easy. Now just someone has to write this ... this would portable for
>> other platforms aswell.
>>
>> > Br,
>> >
>> > --jakub
>> >
>> >
>> >
>> >
>> >
>>
>> // Tapani
>>
>> ___
>> maemo-developers mailing list
>> maemo-developers@maemo.org
>> https://maemo.org/mailman/listinfo/maemo-developers
>>

// Tapani

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] CPA: Maemo Service Handler

2007-01-30 Thread Tuomas Kulve


I made a little Control Panel applet for starting and stopping system
services in /etc/init.d/:

http://tuomas.kulve.fi/blog/2007/01/27/maemo-service-handler/

It seems to be stable, but it misses many convenient features, which may
not ever get there, since it works already..


PS. For Bora.

-- 
Tuomas




signature.asc
Description: OpenPGP digital signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] Warranty of discounted devices (was RE: anyone else troubles with the camera?)

2007-01-30 Thread quim.gil
 

>Also do developer devices come with warranty?

Definitely, they are full comercial packages with the same warranty,
terms and conditions than the devices bought in any store at a full
price.

This is one of the reasons why we can't send devices from Nokia to
[unsupported country], since all these small prints apply only to the
countries where the device is sold.

PS: please avoid crossposting between the users and developers lists -
thank you.

--
Quim Gil
Maemo team
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] cx3110x source code is for the nokia800?

2007-01-30 Thread Komal Shah

On 1/30/07, Koen Kooi <[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Is the cx3110x source code is for the nokia800 available somewhere?



I don't think that it is available. It is binary only module because
of chip manufacturer and many other things. Samuel Ortiz is better
person to answer this.

--
---Komal Shah
http://komalshah.blogspot.com
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] PyMaemo and modules left out.

2007-01-30 Thread Simo Hosio


Hi,

I am starting to develop a middleware for Maemo with Python. However, there 
are numerous python modules I'd like to utilize in my work, e.g. xmlrpc 
server side. This is only available in the SDK, I realize. What is the 
reason for having some modules only there? I mean, I understand that they 
are heavy and generate overhead, but doesn't this only make developing with 
Python harder? Since the scripts / code one develops, won't work directly 
in the device? Couldn't find answer to this..and I am quite unexperienced 
with both, python and Maemo anyway..


And furthermore, if the efficiency and efficiency of the software is not my 
greatest concern, is it a big sin just grabbing the libs / sources and just 
importing them to the device? Or will I have some other problems if I do 
that? Any opinions? (Or, knowledge even;)



Br,
Simo
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] oops... I broke app catalog at https://test.maemo.org/

2007-01-30 Thread Igor Tkach

Well, at least SDict Viewer page... I was updating the info and
uploading screenshots, and at some point (I think I was trying to
update title of the first screenshot) it blew up with a bunch of
errors (see below). It keeps spitting out the errors from then on
(just go to, say,
http://test.maemo.org/downloads/product/sdictviewer).

( ! ) Notice: Undefined offset: 1 in
/usr/share/php/midcom/lib/midcom/helper/datamanager2/type/blobs.php on
line 130
Call Stack
#   TimeMemory  FunctionLocation
1   0.0008  64808   {main}( )   ../9-49-18-0.php:0
2   0.1630  6512968 midcom_application->codeinit( )  
../9-49-18-0.php:114
3   0.1664  6517960 midcom_application->_process( )  
../application.php:542
4   0.2207  7478272 midcom_application->_handle( )   
../application.php:1055
5   0.2209  7478496 org_openpsa_products_interface->handle(
)   ../application.php:1155
6   0.2209  7478496 org_openpsa_products_viewer->handle( )   
../interface.php:610
7   0.4244  7935288 
org_openpsa_products_handler_product_edit->_handler_edit(
)   ../request.php:715
8   0.4283  7940440 
midcom_helper_datamanager2_controller_simple->set_storage(
)   ../edit.php:91
9   0.4290  7940672 midcom_helper_datamanager2_datamanager->autoset_storage(
)   ../controller.php:151
10  0.4322  7983568 midcom_helper_datamanager2_datamanager->set_storage(
)   ../datamanager.php:237
11  0.4336  7988248 midcom_helper_datamanager2_storage_midgard->load(
)   ../datamanager.php:168
12  0.4347  7989336 
midcom_helper_datamanager2_type_images->convert_from_storage(
)   ../storage.php:206
13  0.4351  7990248 
midcom_helper_datamanager2_type_blobs::convert_from_storage(
)   ../images.php:732

( ! ) Notice: Undefined index: main in
/usr/share/php/midcom/lib/midcom/helper/datamanager2/type/images.php
on line 888
Call Stack
#   TimeMemory  FunctionLocation
1   0.0008  64808   {main}( )   ../9-49-18-0.php:0
2   0.1630  6512968 midcom_application->codeinit( )  
../9-49-18-0.php:114
3   0.1664  6517960 midcom_application->_process( )  
../application.php:542
4   0.2207  7478272 midcom_application->_handle( )   
../application.php:1055
5   0.2209  7478496 org_openpsa_products_interface->handle(
)   ../application.php:1155
6   0.2209  7478496 org_openpsa_products_viewer->handle( )   
../interface.php:610
7   0.4244  7935288 
org_openpsa_products_handler_product_edit->_handler_edit(
)   ../request.php:715
8   0.4283  7940440 
midcom_helper_datamanager2_controller_simple->set_storage(
)   ../edit.php:91
9   0.4290  7940672 midcom_helper_datamanager2_datamanager->autoset_storage(
)   ../controller.php:151
10  0.4322  7983568 midcom_helper_datamanager2_datamanager->set_storage(
)   ../datamanager.php:237
11  0.4336  7988248 midcom_helper_datamanager2_storage_midgard->load(
)   ../datamanager.php:168
12  0.4347  7989336 
midcom_helper_datamanager2_type_images->convert_from_storage(
)   ../storage.php:206
13  0.4351  7990248 
midcom_helper_datamanager2_type_blobs::convert_from_storage(
)   ../images.php:732
14  0.4530  8041536 
midcom_helper_datamanager2_type_images->_sort_attachments(
)   ../blobs.php:134
15  0.4531  8041632 uasort ( )  ../images.php:874
16  0.4531  8041632 
midcom_helper_datamanager2_type_images::_sort_images_callback(
)   ../images.php:0

( ! ) Notice: Undefined index: main in
/usr/share/php/midcom/lib/midcom/helper/datamanager2/widget/images.php
on line 257
Call Stack
#   TimeMemory  FunctionLocation
1   0.0008  64808   {main}( )   ../9-49-18-0.php:0
2   0.1630  6512968 midcom_application->codeinit( )  
../9-49-18-0.php:114
3   0.1664  6517960 midcom_application->_process( )  
../application.php:542
4   0.2207  7478272 midcom_application->_handle( )   
../application.php:1055
5   0.2209  7478496 org_openpsa_products_interface->handle(
)   ../application.php:1155
6   0.2209  7478496 org_openpsa_products_viewer->handle( )   
../interface.php:610
7   0.4244  7935288 
org_openpsa_products_handler_product_edit->_handler_edit(
)   ../request.php:715
8   0.4537  8040864 
midcom_helper_datamanager2_controller_simple->initialize(
)   ../edit.php:92
9   0.4539  8040968 midcom_helper_datamanager2_formmanager->initialize(
)   ../simple.php:45
10  0.4835  8180696 
midcom_helper_datamanager2_widget_images->add_elements_to_form(
)   ../formmanager.php:216
11  0.4835  8180696 
midcom_helper_datamanager2_widget_images->_compute_elements(
)   ../images.php:367
12  0.4845  8189552 
midcom_helper_datamanager2_widget_images->_add_image_row(
)   ../images.php:386

( ! ) Notice: Undefined index: main in
/usr/share/php/midcom/lib/midcom/helper/datamanager2/widget/images.php
on line 555
Call Stack
#   TimeMe

RE: [maemo-developers] Ogg Vorbis and the N800

2007-01-30 Thread Simon Pickering
 

> > Hi
> >
> > as far as I can tell the n800 with the OMAP2420 processor has a vfp 
> > (vector floating point unit; see [1] ) Based on this I wanted to find 
> > out if vorbis could take advantage of this unit by default.
> >
> > To make it short: Yes it works - BUT it is just painful!
> [...]
> > Conclusion:
> > It works but the cpu load is high. Vorbis decoding takes almost 80% 
> > cpu. I also tried MPlayer 1.0rc1-maemo.8 which has the integer based 
> > Tremor decoder codec [4] nicely integrated. Tremor needs around 12% 
> > cpu for the same ogg file. (That is an expected scale up from the 770 
> > experience - tremor takes around 20% cpu on the 770 - due to the 
> > faster cpu of the n800)
> >
> > It exceeds my skills to analyze this much further. However it seems 
> > that the vorbis decoder is not vfp optimized ;-) [yet?].
> 
> Did you specify any compiler flags or just compile as-is?
> 
> I'm not 100% sure but I've let myself belive (based on 
> comments on the IRC channel) that it won't compile with vfp 
> unless you specify "-mfpu=vfp -mfloat-abi=softfp" for the 
> compiler. Also based on the chatting on #maemo, 
> "-mcpu=arm1136j-s" might be worth it.

Just using the "-mfpu=vfp -mfloat-abi=softfp" flags (I couldn't remember the
exact -mcpu setting), produces a gstreamer vorbis plugin with a CPU load of
~30% playing the same file. So better, but still not too good. I wonder why
this is so slow compared with the integer version (does the integer version
produce worse sound?).

Files are here (including the ~12% load tremor gst plugin):
http://people.bath.ac.uk/enpsgp/temp/vorbis-stuff.tar.gz

Put the libgst*.so files in /usr/lib/gstreamer-0.10/ and the others in
/usr/lib/, note that you may not need all of the files in the tarball as
some already exist, namely libao* and libgstvideo4linux.so. Make sure you
symlink the files from *.so.X.x -> *.so.X and again from *.so.X -> *.so

Cheers,


Si

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] Mildly concerned about order status

2007-01-30 Thread Jae Stutzman

Go to http://LetsTalk.com and do an order/status check if the Status field
is empty, call them and ask them to "Push" your order through. Within a few
minutes your status should say "Picking". That is a good sign and should be
shipped within 24hrs from then. This was my experience.

Jae
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] Re: [maemo-users] anyone else troubles with the camera?

2007-01-30 Thread Collin R. Mulliner
I have the same problem (my unit is made in Finland).

Also do developer devices come with warranty?

Other question would be: can we fix this issue ourselfs? (I guess there
is just a smal switch in the camera-stick?)

Collin

PS: my first camera app. is almost done :-)

On Tue, 2007-01-30 at 16:06 +0200, Kemal Hadimli wrote:
> You need to replace your device, according to this url:
> http://www.internettablettalk.com/forums/showthread.php?t=4351
> 
> 
> On 1/30/07, Simon Budig <[EMAIL PROTECTED]> wrote:
> > Just a quick question - does anyone else have problems with the camera?
> > When - starting in the 03:00 position - I turn it around the image flips
> > when the camera is in the 12:00 position, but flips back in the 11:00
> > position and stays that way, even when moving the camera fully to the
> > back (which of course is unusable).
> >
> > I strongly suspect that this is a hardware problem, but I'd like to hear
> > if anyone else has experienced this problem.
> >
> > I'd hate to have to send the device back...   :-)
> 
--
Collin R. Mulliner <[EMAIL PROTECTED]>
BETAVERSiON Systems [www.betaversion.net]
info/pgp: finger [EMAIL PROTECTED]
Help Microsoft fight software piracy: Give Linux to a friend today!

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] GLIBC_2.4

2007-01-30 Thread Amy Sockanathan

Hi,
I am having a problem where it says "GLIBC_2.4" not defined and I saw
that the scratchbox compilers in maemo are 2.3.6 and I need 2.4. Is
there anyway to upgrade libc. Any help is much appreciated.

Thanks
- Amy
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] Re: Fast 16bpp alpha blending (was: Improving Cairo performance on the N800)

2007-01-30 Thread Gustavo Sverzut Barbieri

On 1/30/07, Siarhei Siamashka <[EMAIL PROTECTED]> wrote:

On Thursday 18 January 2007 13:46, Gustavo Sverzut Barbieri wrote:

> > By the way, free software is really poorly optimized for ARM right now.
> > For example, SDL is not optimized for ARM, xserver is probably not
> > optimized as well, a lot of performance critical parts of code in various
> > software are still only implemented in C for ARM while they have x86
> > assembly optimizations long ago. Considering that Internet Tablets might
> > have a tight competition  with x86 UMPC devices in the near future, ARM
> > poweded devices are at some disadvantage now. Is this something that we
> > should try to change? :-)
>
> Yes. Since at INdT we use a lot of SDL, GTK and in future Evas, we are
> interested in optimizing this.
>
> One thing that can be optimized is 16bpp operations. Moving SDL
> surfaces to be optimized, packing 16bpp RGB into one plane and 1
> byte-Alpha in another plane, we could use multiple store (stm) and
> improve things a bit.
>
> If we could achieve ~24fps blitting fullscreen 16bpp+Alpha, it would
> rock! :-) Right now we do 18fps, but we still need that function with
> separated planes + stm. I'll ask Lauro to send them as soon as we get
> it working.
>
> Anyone willing to help evas port to work with 16bpp+Alpha internally?
> Evas is a great canvas, can interoperate with Glib main loop easily
> and provides high level utilities, like text layout (pango-like),
> gradients, the concept of objects to animate and is scriptable really
> easy (with optimizations!).

Regarding 16bpp alpha blending, I did some optimization (not involving
assembly yet) for maemo build of ufo2000 [1]. The code which is currently
used, is based on and extends RLE sprites from Allegro game programming
library [2]. The sources can be found here:
http://ufo2000.svn.sourceforge.net/viewvc/ufo2000/trunk/src/fpasprite/

The goal was to get support for drawing isometric tiles with the support of
alpha channel (for fire, smoke, explosions, window glass, ...) and adjustable
brigtness (for lighting effects on night missions simulation).

The code works as allegro addon library and allows loading sprites from
PNG files. It automagically detects presence or absence of alpha channel and
converts images into optimal format which allows fast blending (for alpha
channel) and store it in a compact form (for images without alpha channel).
When blitting sprite, brightness ranging from 0 - 255 is used as an additional
argument. The code uses C++ templates to support all the possible variants
of bit depth and blending type (may be not a very good idea for the code
intended for submission into C library later :) ).

The trick used to speed up alpha blending was to store each pixel data in
a special 32-bit representation with R, G, B and alpha channel arranged in a
special way for better performance.

So imagine that we have 16-bit pixel in RGB565 format and alpha channel.
We convert it into this 32-bit preprocessed data according to the following
algorithm:

uint32_t convert_pixel(uint16_t rgb565, int alpha)
{
uint32_t n = (alpha + 1) / 8, x = rgb565;
x = (x | (x << 16)) & 0x7E0F81F;
return x | (n << 5);
}

Now if we need to do alpha blending (with some buffer in memory), we do the
following (d - destination pixel data buffer, s - buffer with preprocessed
32-bit pixel data, w - number of pixels to blend, n - brightness level (0 -
32)):

uint16_t *draw_alpha_dark_line16(uint16_t *d, uint32_t *s, int w, uint32_t n)
{
 while (--w >= 0) {
uint32_t x = *s++;
uint32_t y = (uint16_t)*d;
uint32_t result = (x >> 5) & 0x3F;
x = ((x & 0x7E0F81F) * n / 32) & 0x7E0F81F;
y = (y | (y << 16)) & 0x7E0F81F;
result = ((x - y) * result / 32 + y) & 0x7E0F81F;
*d++ = (result | (result >> 16));
}
return d;
}

This code works quite fast (at the cost of some precision loss though). It
is perfectly suitable for isometric tile based games and probably other
applications which only need lightning fast blending and do not need any
extra operations with sprites (rotation for example). Removing brightness
level support makes the code even faster.

Using this code in ufo2000 allows it to keep reasonably high framerate (more
than 10 fps) even on complicated scenes full of fire and smoke animation for
example. I hope this information may be useful for other maemo game
developers or anyone in need of fast 16bpp alpha blending code.

PS. Optimizing alpha blending using assembly can most likely improve
performance even more :)


We're doing almost this for Canola with the exception that we keep
data as 16+alpha in memory... we were considering moving to this same
32bit format you've said, since 3bytes is not aligned and make us do
the unpack it every time... at the expense of bit more memory.

We plan to release this blit function, but it's not much useful right
now... we should try make it available inside SDL_BlitSurface, but I
don

[maemo-developers] Fast 16bpp alpha blending (was: Improving Cairo performance on the N800)

2007-01-30 Thread Siarhei Siamashka
On Thursday 18 January 2007 13:46, Gustavo Sverzut Barbieri wrote:

> > By the way, free software is really poorly optimized for ARM right now.
> > For example, SDL is not optimized for ARM, xserver is probably not
> > optimized as well, a lot of performance critical parts of code in various
> > software are still only implemented in C for ARM while they have x86
> > assembly optimizations long ago. Considering that Internet Tablets might
> > have a tight competition  with x86 UMPC devices in the near future, ARM
> > poweded devices are at some disadvantage now. Is this something that we
> > should try to change? :-)
>
> Yes. Since at INdT we use a lot of SDL, GTK and in future Evas, we are
> interested in optimizing this.
>
> One thing that can be optimized is 16bpp operations. Moving SDL
> surfaces to be optimized, packing 16bpp RGB into one plane and 1
> byte-Alpha in another plane, we could use multiple store (stm) and
> improve things a bit.
>
> If we could achieve ~24fps blitting fullscreen 16bpp+Alpha, it would
> rock! :-) Right now we do 18fps, but we still need that function with
> separated planes + stm. I'll ask Lauro to send them as soon as we get
> it working.
>
> Anyone willing to help evas port to work with 16bpp+Alpha internally?
> Evas is a great canvas, can interoperate with Glib main loop easily
> and provides high level utilities, like text layout (pango-like),
> gradients, the concept of objects to animate and is scriptable really
> easy (with optimizations!).

Regarding 16bpp alpha blending, I did some optimization (not involving
assembly yet) for maemo build of ufo2000 [1]. The code which is currently 
used, is based on and extends RLE sprites from Allegro game programming
library [2]. The sources can be found here:
http://ufo2000.svn.sourceforge.net/viewvc/ufo2000/trunk/src/fpasprite/

The goal was to get support for drawing isometric tiles with the support of
alpha channel (for fire, smoke, explosions, window glass, ...) and adjustable
brigtness (for lighting effects on night missions simulation).

The code works as allegro addon library and allows loading sprites from
PNG files. It automagically detects presence or absence of alpha channel and
converts images into optimal format which allows fast blending (for alpha
channel) and store it in a compact form (for images without alpha channel).
When blitting sprite, brightness ranging from 0 - 255 is used as an additional
argument. The code uses C++ templates to support all the possible variants 
of bit depth and blending type (may be not a very good idea for the code
intended for submission into C library later :) ).

The trick used to speed up alpha blending was to store each pixel data in
a special 32-bit representation with R, G, B and alpha channel arranged in a
special way for better performance.

So imagine that we have 16-bit pixel in RGB565 format and alpha channel. 
We convert it into this 32-bit preprocessed data according to the following
algorithm:

uint32_t convert_pixel(uint16_t rgb565, int alpha)
{
uint32_t n = (alpha + 1) / 8, x = rgb565;
x = (x | (x << 16)) & 0x7E0F81F;
return x | (n << 5);
} 

Now if we need to do alpha blending (with some buffer in memory), we do the
following (d - destination pixel data buffer, s - buffer with preprocessed
32-bit pixel data, w - number of pixels to blend, n - brightness level (0 - 
32)):

uint16_t *draw_alpha_dark_line16(uint16_t *d, uint32_t *s, int w, uint32_t n)
{
 while (--w >= 0) {
uint32_t x = *s++;
uint32_t y = (uint16_t)*d;
uint32_t result = (x >> 5) & 0x3F;
x = ((x & 0x7E0F81F) * n / 32) & 0x7E0F81F;
y = (y | (y << 16)) & 0x7E0F81F;
result = ((x - y) * result / 32 + y) & 0x7E0F81F;
*d++ = (result | (result >> 16));
}
return d;
}

This code works quite fast (at the cost of some precision loss though). It 
is perfectly suitable for isometric tile based games and probably other
applications which only need lightning fast blending and do not need any 
extra operations with sprites (rotation for example). Removing brightness
level support makes the code even faster.

Using this code in ufo2000 allows it to keep reasonably high framerate (more
than 10 fps) even on complicated scenes full of fire and smoke animation for
example. I hope this information may be useful for other maemo game 
developers or anyone in need of fast 16bpp alpha blending code.

PS. Optimizing alpha blending using assembly can most likely improve 
performance even more :)

[1] http://ufo2000.sourceforge.net
[2] http://alleg.sourceforge.net
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] Ogg Vorbis and the N800

2007-01-30 Thread Kalle Vahlman

2007/1/30, Krischan Keitsch <[EMAIL PROTECTED]>:

Am Montag, 29. Januar 2007 09:08 schrieb Kalle Vahlman:
> 2007/1/29, Krischan Keitsch <[EMAIL PROTECTED]>:
> > Hi
> >
> > as far as I can tell the n800 with the OMAP2420 processor has a vfp
> > (vector floating point unit; see [1] ) Based on this I wanted to find out
> > if vorbis could take advantage of this unit by default.
> >
> > To make it short: Yes it works - BUT it is just painful!
>
> [...]
>
> > Conclusion:
> > It works but the cpu load is high. Vorbis decoding takes almost 80% cpu.
> > I also tried MPlayer 1.0rc1-maemo.8 which has the integer based Tremor
> > decoder codec [4] nicely integrated. Tremor needs around 12% cpu for the
> > same ogg file. (That is an expected scale up from the 770 experience -
> > tremor takes around 20% cpu on the 770 - due to the faster cpu of the
> > n800)
> >
> > It exceeds my skills to analyze this much further. However it seems that
> > the vorbis decoder is not vfp optimized ;-) [yet?].
>
> Did you specify any compiler flags or just compile as-is?
>
> I'm not 100% sure but I've let myself belive (based on comments on the
> IRC channel) that it won't compile with vfp unless you specify
> "-mfpu=vfp -mfloat-abi=softfp" for the compiler. Also based on the
> chatting on #maemo, "-mcpu=arm1136j-s" might be worth it.

I tried again with the flags
mfpu=vfp mfp=vfp mcpu=arm1136j-s
(mfloat-abi=... didn't work)

(I passed the flags to the configure script. Is that the correct way to do
it?)


No, they should be set to the CFLAGS environment variable (for example):

 export CFLAGS='-mfpu=vfp -mfloat-abi=softfp -mcpu=arm1136j-s'

and after that run configure and recompile (remember to 'make
clean'!). You should see them in the lines that begin with 'gcc' if
the configure script picked them up properly.


--> No success! It compiled fine but cpu was above 80% and playback got
interruppted quite often.  :-(


That sounds strange, if you pass those to the configure script it
should just silently ignore them...

--
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] Java phoneME advanced for the 770

2007-01-30 Thread Roberto Resoli

...

> Many thanks for your work, i will try ASAP, along with recent ports of
> GNU Classpath, jamvm and jikes 
>
> Bye,
> Roberto.
>
>

I tried jamvm plus classpath but got the GTK-Peer bug because a library my
app uses draws with Graphics2D. Normal swing sliders/borders and
comboboxes did work though and the application could be closed nicely.
Didn't have top menus of course. I was impressed with the startup speed on
the 770 compared to my pc: not that much slower, although of course no jit
compilation is performed.


Same impression here, may be is an effect of recent Classpath
optimizations or it relates to 770 compile optimization? Very good, in
any case :)

Bye,
Roberto
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] Mildly concerned about order status

2007-01-30 Thread Brian Waite
I thin kthe best thing to do is call Nokia direct at the phone # in my last 
mail. I ordered mine over the phone when the CCs were having trouble. Once i 
heard it cleared up I Called back to make sure I wasn't stuck in a mgr queue 
I did not need to be in. Later that night they called me back and while on 
the phone pushed the order into the shipping pipe. It was deiivered today, 
can't wait to get home! Give a call you might be on hold for a bit, but I bet 
it just takes a wakeup to get it out. While you are there you should rant 
about hom long it took  to process. Who knows maybe they'll upgrade the 
shipping!

Thanks
Brian
On Tuesday 30 January 2007 14:43, Andrew Barr wrote:
> Hi,
>
> I know that as far as Maemo vs. Nokia is concerned in the N800 developer
> program, we need to be talking to the web shop folks at Nokia USA,
> however I would like to solicit reactions from those in the US and maybe
> Canada who have placed orders for N800s under the developer device
> program.
>
> I placed my order on Friday after the credit-card processing issues were
> cleared up. It is now Tuesday and my order status page has stayed like
> this[0] since Friday. I read someone's post saying that these discounts
> needed management approval, could that be what I am waiting on? On the
> other hand, I also read that someone had their order on the web
> shop /appear/ to go through but they had to re-place the order over the
> phone. I would rather not navigate the phone maze again and have to
> explain to every last person why I think I should get a $400 computer
> for $125, so if anyone could give me an idea of what might be going on
> here, I'd appreciate it.
>
> [0]
> http://www.oakcourt.dyndns.org/~andrew/screenshots/n800_order_status.png
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] Mildly concerned about order status

2007-01-30 Thread Aaron Levinson
On Tue, 30 Jan 2007, Andrew Barr wrote:

> Hi,
> 
> I know that as far as Maemo vs. Nokia is concerned in the N800 developer
> program, we need to be talking to the web shop folks at Nokia USA,
> however I would like to solicit reactions from those in the US and maybe
> Canada who have placed orders for N800s under the developer device
> program.
> 
> I placed my order on Friday after the credit-card processing issues were
> cleared up. It is now Tuesday and my order status page has stayed like
> this[0] since Friday. I read someone's post saying that these discounts
> needed management approval, could that be what I am waiting on? On the
> other hand, I also read that someone had their order on the web
> shop /appear/ to go through but they had to re-place the order over the
> phone. I would rather not navigate the phone maze again and have to
> explain to every last person why I think I should get a $400 computer
> for $125, so if anyone could give me an idea of what might be going on
> here, I'd appreciate it.

I think you are just going to have to call.  I didn't have any problems
with any of the times I called Nokia USA, and I just used the phone number
listed on my order.  As Quim indicated, all of the on-line stores should
now be familiar with the coupon deal.  Just give them your order number to
expedite the transaction.

Aaron

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] Mildly concerned about order status

2007-01-30 Thread Hubert Figuiere
> I would like to solicit reactions from those in the US and maybe
> Canada who have placed orders for N800s under the developer device
> program.

People in Canada are not allowed to order at all.

Apparently there is a US custom problem for shipping to Canada[1]

Hub

[1] http://maemo.org/pipermail/maemo-developers/2007-January/007628.html
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] Mildly concerned about order status

2007-01-30 Thread Andrew Barr
Hi,

I know that as far as Maemo vs. Nokia is concerned in the N800 developer
program, we need to be talking to the web shop folks at Nokia USA,
however I would like to solicit reactions from those in the US and maybe
Canada who have placed orders for N800s under the developer device
program.

I placed my order on Friday after the credit-card processing issues were
cleared up. It is now Tuesday and my order status page has stayed like
this[0] since Friday. I read someone's post saying that these discounts
needed management approval, could that be what I am waiting on? On the
other hand, I also read that someone had their order on the web
shop /appear/ to go through but they had to re-place the order over the
phone. I would rather not navigate the phone maze again and have to
explain to every last person why I think I should get a $400 computer
for $125, so if anyone could give me an idea of what might be going on
here, I'd appreciate it.

[0]
http://www.oakcourt.dyndns.org/~andrew/screenshots/n800_order_status.png
-- 
Andrew Barr | http://www.pridelands.dyndns.org/

"My life is an open book, but I'm not going to read it to you."
-- David Hyde Pierce
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] calling small unix tools from filemanager; was: unzip: file manager associations - NOT fixed

2007-01-30 Thread Danny Milosavljevic
Hi,

So I wonder what I've been smoking... Writing "fixed" in the subject when the 
problem just changed to another one... Must be sleep deprivation ;)

On Tue, 30 Jan 2007 01:16:34 +, Danny Milosavljevic wrote:
[...]
>> However, the file manager will detect my test zip file as being 
>> "application/zip" (tested by long-clicking on zip file and choosing 
>> "Details").
> 
> When I click on it, it will give "Unable to open".

So the problem moved to the desktop file, which is:

[sbox-ARMEL: ~/source/zip-unzip/unzip-5.52/debian] > cat unzip.desktop 
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Name=Uncompress zip files
Icon=unzip
Exec=/usr/bin/batch-unzip -- %f 
X-Osso-Type=application/x-executable
MimeType=application/zip;

Note that there is no dbus service or osso_init in batch-unzip (batch-unzip 
actually is just a shell script).

This probably means that quite a few assumptions the file manager made are 
broken by me, I'd think. Is there a way to call such tools in a simple way or 
do I have to add another dbus service / C program / callback / ... complex 
stuff?

> btw: where does the file manager get the icon for the file?

cheers,
  Danny

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] cx3110x source code is for the nokia800?

2007-01-30 Thread Koen Kooi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Is the cx3110x source code is for the nokia800 available somewhere?

regards,

Koen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFv4NTMkyGM64RGpERAtSeAJ4katS4gbm15s9mDD7hDvXkkMKQ/QCgnPwz
SMsVmRLAojP9ogu2mp+RkXs=
=VPtb
-END PGP SIGNATURE-
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] N800 codes at UK shop

2007-01-30 Thread mike saunby

Thanks for this.  It worked for me, so I'm no longer one of the
"unfortunate". Hopefully it will work for others too.

I'm looking forward with great anticipation to trying out the N800 in 2/3
days.

Michael

On 30/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


 Some of you had trouble at the UK shop (some don't, >50% according to our
records).

Hopefully this is a solution for the unfortunate:

*http://direct.nokia.com/countries.aspx?model=N800&add=true&country=GB*


It should work. Otherwise contact phone/mail support of the UK shop. At
this point we believe all the online shops are aware of the N800 developer
program and should be able to provide support and answers. They can solve
problems with i.e. credit cards - we don't.

Thank you again for your understanding. We are taking notes not to forget.

--
Quim Gil
Maemo team

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] Java phoneME advanced for the 770

2007-01-30 Thread Henning Sprang
Hi,

Johannes Eickhold wrote:
> [1] http://i30www.ira.uka.de/p2p/ambicomp/phoneME_Nokia770
> [2]
> http://wiki.java.net/bin/view/Mobileandembedded/PhoneMEAdvancedPlatformsNokia770
> [3] http://forums.java.net/jive/forum.jspa?forumID=100

Just found your posts when searching information about the state of java
on the 770.

I am interested in building java apps for the 770. I had no time to get
into it until now, but will be able to spend some time with that when a
major project is finished in some days.

Until now, searching the wiki and mailing lists did not really give me
detailed or exact information on the state of java on 770 - only this
thread changes this a bit.

Still, I am not clear if there is some working implementation one can
start writing apps against, or if there still are some major steps to go
until one can think of writing end user apps.

This threads sounds like some steps are still needed, while some of the
links I just added on the maemo wiki's java page (wondering why not all
information on this topic get collected there but spread on multiple
personal sites) suggest there are working implementations and end user apps.

Which one is right?

Maybe it would be cool to create some table about the different java vm
options available, the things that work and don't work with each, most
important things to do to get it up and running for building end user
applications, and who is working on what. (all that also for the
different versions of maemo and IT OS, which I still need to invest some
time to understand which is what and how they are related exactly.)

It seems also an open question if the java bytecode extensions of the
CPU can be used.

If I get that information here, I'll add it to the wiki page - as well
as any further clarifications on the topic.


Henning
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] Re: to Nokia: simple method to gainagamingaudienceon 770/800

2007-01-30 Thread Clemens Eisserer

This is no API nor something really considerable as stable or whatever.
Its a pain to implement and may change without any notice from one
maemo release to another.

What I am asking is a library with a well-designed C-interface
developers can rely on.

lg Clemens

2007/1/30, Ross Burton <[EMAIL PROTECTED]>:

On Tue, 2007-01-30 at 16:11 +0100, Clemens Eisserer wrote:
> and here we are again.
>
> Why is the virtual keybord restricted to GTK applications? Is a simply
> interface which would require some addotion of toolkits really so hard
> to create?
> *PLEASE* create an cross-toolkit API for non-gtk apps - which works
> clean and without hacks. There is real demand for it, really.

http://maemo.org/maemowiki/InputMethod

Ross
--
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF




___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] Re: to Nokia: simple method to gainagamingaudienceon 770/800

2007-01-30 Thread Ross Burton
On Tue, 2007-01-30 at 16:11 +0100, Clemens Eisserer wrote:
> and here we are again.
> 
> Why is the virtual keybord restricted to GTK applications? Is a simply
> interface which would require some addotion of toolkits really so hard
> to create?
> *PLEASE* create an cross-toolkit API for non-gtk apps - which works
> clean and without hacks. There is real demand for it, really.

http://maemo.org/maemowiki/InputMethod

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] apply gconf settings using data in /etc/gconf/gconf.xml.defaults/schemas/* ?

2007-01-30 Thread william maddler
william maddler wrote:
> Hello,
> I was playing/messing around with gconftool and did a not-so-smart move,
> overwriting one of the default values (namely display blank timeout
> values). I found they are stored in
> /etc/gconf/gconf.xml.defaults/schemas/system/osso/dsm/display/%gconf.xml
> 
> Is there a way to apply them without having to reflash?

Simply use: gconftool -u 
and default values will restored



___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] to Nokia: simple method to gainagamingaudienceon 770/800

2007-01-30 Thread Clemens Eisserer

and here we are again.

Why is the virtual keybord restricted to GTK applications? Is a simply
interface which would require some addotion of toolkits really so hard
to create?
*PLEASE* create an cross-toolkit API for non-gtk apps - which works
clean and without hacks. There is real demand for it, really.

lg Clemens

2007/1/26, Tapani Pälli <[EMAIL PROTECTED]>:

ext [EMAIL PROTECTED] wrote:
>> On 1/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>
>>>  * easy to make basic GUI for game setup (input methods do
>>>
>> not work in
>>
>>> SDL)
>>>
>> Hello
>>
>> I guess anybody how is porting a SDL game will run into the
>> keyboard issue problem.
>> It would be nice if we can port existing SDL games but that
>> really means that we need a cute keyboard input hack. I have
>> been asking around but did not find a simple pluggable virtual
>> keyboard for sdl.
>> perhaps pointer to such resources would help. but otherwise I
>> think some effort must be put into that.
>>
>> greetings
>>
>
> Hi,
>
> This has been studied briefly, and since SDL games are a very colorful
> bunch we felt that a solution to suit "SDL games" is a very illusive
> target, we would not get a solution that suits all and it would be a
> hack complicating things evern futher.
>
> The startup screen has been seen as a significantly more elegant way of
> dealing with most of the cases and so far it has proven right (how many
> games require text entry during the gameplay?).
>
>

One solution for this would be to provide a nice and minimal keyboard
class which would return inputted text just as a string and not really
emit keyevents. The API for keyboard should be minimalistic so that
porting textentries needed for ip-address, highscrore etc. would be
easy. Now just someone has to write this ... this would portable for
other platforms aswell.

> Br,
>
> --jakub
>
>
>
>
>

// Tapani

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] Re: Sending mail from console

2007-01-30 Thread Michael Kleinhenz

>> If I put a mail into apps/email/Mail/Outbox/ using a reengineered
>> filename (something like "accountname^Outbox^msgid"), the mail is
>> _sometimes_ delivered when calling send_and_receive, but not always.
>> Sometimes the mail is set on hold: I can see it in the Outbox folder of
>> osso-email but I have to manually force the send using the "send" button.
> 
> You could write the file in text editor, add headers and send it,
> if I'm not wrong in this case. Also, login into your smtp server,
> write the letter and let the server do the rest.

Sure, I could use a small smtp gateway server that could deliver an
email to a remote smtp service, but I want to use the offline spool
function of osso-email - I would like the email to be spooled until
network connectivity is restored.

Installing a full-blown mta like postfix just for store-and-deliver
operation seems too bloated to me.

can anyone explain the meaning of cache.xml and cache.xml0 in the Outbox
folder or is there some documentation about it?

Thanks,
Michael

-- 
Michael Kleinhenz
www.quendor.org

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] Re: Sending mail from console

2007-01-30 Thread Zoran Kolic
> I try to send an email from a console application using the integrated
> osso-email, but it seems that ist does not have a console mode or a
> suitable dbus call.

Unix pipes have a hard time to work with graphic apps.

> If I put a mail into apps/email/Mail/Outbox/ using a reengineered
> filename (something like "accountname^Outbox^msgid"), the mail is
> _sometimes_ delivered when calling send_and_receive, but not always.
> Sometimes the mail is set on hold: I can see it in the Outbox folder of
> osso-email but I have to manually force the send using the "send" button.

You could write the file in text editor, add headers and send it,
if I'm not wrong in this case. Also, login into your smtp server,
write the letter and let the server do the rest.

> Is there a reliable way to insert an email into the internal mail spool?

All ways are reliable if the mail is there.
The plain file on desktop you may send by ssmtp or similar. It is
not available on 770, as I know.

 Zoran


___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] apply gconf settings using data in /etc/gconf/gconf.xml.defaults/schemas/* ?

2007-01-30 Thread william maddler
Hello,
I was playing/messing around with gconftool and did a not-so-smart move,
overwriting one of the default values (namely display blank timeout
values). I found they are stored in
/etc/gconf/gconf.xml.defaults/schemas/system/osso/dsm/display/%gconf.xml

Is there a way to apply them without having to reflash?

Thank you.

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] problem with maemomm

2007-01-30 Thread rogelio . canedo
hello,
i have a problem with the installation of libhildon-libsmm-dev
libhildon-fmmm-dev

I follow the tutorial:
http://maemomm.garage.maemo.org/docs/tutorial/html/ch03.html

[sbox-ARMEL: ~] > fakeroot apt-get update
Get:1 http://repository.maemo.org scirocco/free Packages [10.6kB]
Get:2 http://repository.maemo.org scirocco/free Release [114B]
Get:3 http://repository.maemo.org scirocco/non-free Packages [20B]
Get:4 http://repository.maemo.org scirocco/non-free Release [118B]
Get:5 http://repository.maemo.org scirocco/free Packages [87.1kB]
Get:6 http://repository.maemo.org scirocco/free Release [114B]
Get:7 http://repository.maemo.org scirocco/non-free Packages [6812B]
Get:8 http://repository.maemo.org scirocco/non-free Release [118B]
Fetched 105kB in 1m22s (1274B/s)
Reading Package Lists... Done
[sbox-ARMEL: ~] > fakeroot apt-get install libhildon-libsmm-dev
libhildon-fmmm-dev
Reading Package Lists... Done
Building Dependency Tree... Done
E: Couldn't find package libhildon-libsmm-dev


Can you help me please, thank you
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] to Nokia: simple method to gain a gaming audience on 770/800

2007-01-30 Thread Marcelo Oliveira

Hei all

We were doing a very simple prototype for a cross platform python game (same
code on s60, 770 and desktop) , and at least in the pygame(python + sdl) it
was so simple to make the bitmap solution (even with cap and simbols) take
less then a couple of hours to prototype (not clean coding etc)

Of course I cannot assure that we supported languages like hungarian, or
even our brasilian portuguese, but for the game input was ok and made in
just one day.

So I agree with jacub, if you  really need, go and make a simple thing for
you the fits your need. It's not a problem at all.

I had a lot more problems with the DOOM, that needed more visual controls
then a keyboard : / but at least was playable in the end and showed
something :
maybe you don't need a full keyboard =)

http://www.marceloeduardo.com/blog/wp-content/uploads/2007/01/picture-8.png


Together goes the keyboard for the demo in python (you can bring it easily
to C)

Obs : this was a fast prototype of a non-python developer =) so do not look
at with demanding eyes =)

BR

Marcelo Oliveira
INdT - Recife
www.marceloeduardo.com

-
( http://www.marceloeduardo.com/blog/wp-content/uploads/2007/01/2.png )
class KeyBoard:

   # Constructor
   def __init__(self, people):
   self.show = 0
   self.shift = 0
   self.msg = ""
   self.whisper = ""
   self.text = 0
   self.people = people
   self.lower_keys = pygame.image.load("pixmaps/keyboard-lower.png")
   self.upper_keys = pygame.image.load("pixmaps/keyboard-upper.png")
   self.keymap1 = (("q", "w", "e", "r", "t", "y", "u", "i", "o", "p",
"[", "]", "1", "2", "3"),
   ("a", "s", "d", "f", "g", "h", "j", "k", "l", ";",
"`", "'", "4", "5", "6"),
   ("z", "x", "c", "v", "b", "n", "m", ",", ".", "?",
"!", "+", "7", "8", "9"),
   (" ", " ", " ", " ", " ", " ", " ", " ", " ", " ", "
", " ", "-", "0", "="))
   self.keymap2 = (("Q", "W", "E", "R", "T", "Y", "U", "I", "O", "P",
"{", "}", "!", "@", "#"),
   ("A", "S", "D", "F", "G", "H", "J", "K", "L", ":",
"\"", "/", "$", "%", "^"),
   ("Z", "X", "C", "V", "B", "N", "M", "<", ">", "?",
"~", "\\", "&", "*", "("),
   (" ", " ", " ", " ", " ", " ", " ", " ", " ", " ", "
", " ", "_", ")", "+"))

   # Create text
   def create_text(self):
   if self.msg != "":
   self.text = font.render(self.msg, 1, (255, 255, 255))
   if self.text.get_width() > 484:
   self.text = self.text.subsurface(self.text.get_width() -
484, 0, 484, self.text.get_height())
   else:
   self.text = 0

   def set_whisper(self, name):
   self.show = 1
   self.whisper = name

   # Update keyboard state
   def update(self, event):
   if event.type == KEYDOWN and event.key == K_RETURN:
   self.whisper = ""
   self.show = not self.show
   elif self.show and event.type == MOUSEBUTTONDOWN:
   x, y = pygame.mouse.get_pos()
   if x >= 7 and x < 472 and y >= 347 and y < 471:
   x = (x - 7) / 31
   y = (y - 347) / 31
   if x == 0 and y == 3:
   self.shift = not self.shift
   else:
   if self.shift:
   self.msg += self.keymap2[y][x]
   else:
   self.msg += self.keymap1[y][x]
   self.create_text()
   elif x >= 472 and x < 505 and y >= 347 and y < 378:
   self.msg = self.msg[:-1]
   self.create_text()
   elif x >= 472 and x < 505 and y >= 378 and y < 441 and
self.msg.strip() != "":
   self.people.msg_me(self.msg, self.whisper)
   self.show = 0
   self.text = 0
   self.msg = ""
   self.whisper = ""
   elif x >= 472 and x < 505 and y >= 441 and y < 471:
   self.whisper = ""
   self.show = not self.show

   # Draw keyboard
   def draw(self):
   if self.show:
   if self.shift:
   map.blit(self.upper_keys, (0, 302))
   else:
   map.blit(self.lower_keys, (0, 302))
   if self.text:
   map.blit(self.text, (14, 315))






On Jan 26, 2007, at 6:09 PM, Kees Jongenburger wrote:

On 1/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Kees Jongenburger wrote:

I have been asking
around but did not find a simple pluggable virtual keyboard for sdl.


This is IMHO a very simple problem. Just a quick guess: You have to draw a
nice keyboard,
export it to BMP and load it with SDL_LoadBMP(). Then you display (blit) it
with
SDL_BlitSurface(). Don't forget to update the screen with SDL_UpdateRects().
Then you can
SDL_WaitEvent() to wait for SDL_MOUSEBUTTONDOWN events. You just need a
table
which contains the x and y coords of our virtual keyboard to decode coords
to the key
pressed. Of course you should handle shift, delete and someth

Re: [maemo-developers] Re: Python/Contact Data Store APIs..

2007-01-30 Thread Luciano M. Wolf

On 1/30/07, Ross Burton <[EMAIL PROTECTED]> wrote:

On Mon, 2007-01-29 at 17:48 -0900, John P. Mitchell wrote:
> I want to write an address book that intergrates with the built in
> contacts data store. Which libraries are required for accessing that data
> store and are there bindings for them in the Python 2.5 release?
>  Has anyone tried using swig[1] to build a wrapper for binding Maemo C
> libraries to Python?

To access the address book data you libebook, there is a tutorial on
maemo.org:

http://maemo.org/platform/docs/howtos/howto_using_abook_bora.html

However there are no Python wrappers.  The API is fairly standard
GObject style so you should have some success in using the existing
pygtk framework to wrap it.  The parsing tools are quite pedantic so
I'll happily modify any headers in the EDS svn repository to make it
build, as I'd love to see Python wrappers myself.

You may find http://www-128.ibm.com/developerworks/linux/library/l-wrap/
useful, it's a tutorial I wrote some time ago (but still mostly
relevant, not a lot has changed) that documents the basics in wrapping
GObjects for Python.

Ross
--
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


Hi,

You could take a look in PythonHildon[1] too. We use codegen, provided
by pygtk, to produce bindings. First of all run h2def to produce the
"def" files that will be used by gen-enum-c and gen-enum-h. Codegen
will work over code generated by these utilities. The utilities are
called by setup.py.
Most part of time swig application is used to produce C++ wrappers and
here we use C. This is the reason to adopt codegen.

Regards,
Luciano
-INdT-

[1]
https://stage.maemo.org/svn/maemo/projects/haf/trunk/python-hildon/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] xmoto development

2007-01-30 Thread Kees Jongenburger

Hello

I am happy announce that xmoto is reaching beta status on the N800

Here is a nice video showing that off
http://video.google.com/videoplay?docid=-5434097291911279996

The build system used for xmoto is the mud builder, I am very happy with it
and would like to recommend it to others

I send  this mail in the  hope to find some people willing to help me
fixing some of the maemo itegration issues (keyboard,full screen
toggle, and of course speed improvements).

Hi have setup a test repository for whoever feels like a beta
tester(also requires the maemo repository repository.maemo.org)

Catalogue name xmoto_testing
web address http://box.mmapps.net/~keesj/mud/
Distribution bora
Components testing

greetings
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] Unified/Umbrella garage project for direct ports

2007-01-30 Thread Kemal Hadimli

That's even better than the unified project idea. Great news!

On 1/30/07, Andrew Flegg <[EMAIL PROTECTED]> wrote:

On 1/29/07, Kemal Hadimli <[EMAIL PROTECTED]> wrote:
>
> There are a lot of userspace utilities or system libraries that work
> on maemo without requiring any special/custom "porting", and are just
> direct scratchbox compiles of debian packages. These libraries/utils
> are currently distributed across custom repositories. Moving these
> over to the maemo garage would result in countless project entries
> which are rarely updated.

Agreed.

> The idea is to create an "umbrella project" and add maintainers of
> various packages as developers to this project, so they can publish
> files. They will all have garage repository access and will maintain
> directly-ported packages like simple command line utils, small
> libraries, etc. The aim is to make these packages accessible in a
> single repository. (which is the maemo extras repo)

A fantastic idea. One so fantastic it proves "great minds think alike"[1]:

http://mud-builder.garage.maemo.org/

> So, comments? Do you have a few utils/libraries compiled for maemo in
> your personal homepage/repository? Would you be interested in
> maintaining some of these packages in this umbrella project? What do
> you think?

That's exactly the workflow I've got in mind for MUD:

http://mud-builder.garage.maemo.org/docs/index.php?id=workflow

Any comments or questions would be very much appreciated either here,
or on the mailing list. We're almost ready to start releasing the debs
upstream to the extras repository, but for some reason I can't upload
my GPG key to Garage (it claims it as invalid), and I've not heard
back from Ferenc (or anyone else) as to how to fix it.



--
Kemal
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] Unified/Umbrella garage project for direct ports

2007-01-30 Thread Andrew Flegg

On 1/29/07, Kemal Hadimli <[EMAIL PROTECTED]> wrote:


There are a lot of userspace utilities or system libraries that work
on maemo without requiring any special/custom "porting", and are just
direct scratchbox compiles of debian packages. These libraries/utils
are currently distributed across custom repositories. Moving these
over to the maemo garage would result in countless project entries
which are rarely updated.


Agreed.


The idea is to create an "umbrella project" and add maintainers of
various packages as developers to this project, so they can publish
files. They will all have garage repository access and will maintain
directly-ported packages like simple command line utils, small
libraries, etc. The aim is to make these packages accessible in a
single repository. (which is the maemo extras repo)


A fantastic idea. One so fantastic it proves "great minds think alike"[1]:

   http://mud-builder.garage.maemo.org/


So, comments? Do you have a few utils/libraries compiled for maemo in
your personal homepage/repository? Would you be interested in
maintaining some of these packages in this umbrella project? What do
you think?


That's exactly the workflow I've got in mind for MUD:

   http://mud-builder.garage.maemo.org/docs/index.php?id=workflow

Any comments or questions would be very much appreciated either here,
or on the mailing list. We're almost ready to start releasing the debs
upstream to the extras repository, but for some reason I can't upload
my GPG key to Garage (it claims it as invalid), and I've not heard
back from Ferenc (or anyone else) as to how to fix it.

Cheers,

Andrew

--
Andrew Flegg -- mailto:[EMAIL PROTECTED]  |  http://www.bleb.org/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


Re: [maemo-developers] GPS APIs in OS2007

2007-01-30 Thread Dave Smith

On 29/01/07, Jukka Rissanen <[EMAIL PROTECTED]> wrote:


ext Dave Smith wrote:
>
> Do you know of any plans to expose these APIs to Python?  I wrote a
> GPS app in Python for the 770, but it really relied on gpsd running on
> another machine, so I'm pleased to see gpsd on the 800 and it'd be
> nice to spawn it off simply from the code.
>
> Regards,
> Dave
>

Sorry, currently there are no plans for Python API.

Rgds, Jukka



I _think_ I've put something together using swig, but I'm away from my GPS
unit to test it.  If it works, I'll post it somewhere convenient.

Regards,
Dave
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] Have there been any serious efforts to port SUN's CDC implementation?

2007-01-30 Thread Clemens Eisserer

Hi,

Just to be curious, have there been any real efforts in porting Sun's
CDC implementation to the 770/N800?
I really think this should finally be done and it would be great to
hear what problems people experienced...

lg Clemens
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] Starting osso-xterm executing a command?

2007-01-30 Thread Michael Kleinhenz
Hi,

is there a way to start osso-xterm and executing a command in it, like
the original xterm -e command?

Thanks,
Michael

-- 
Michael Kleinhenz
www.quendor.org

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] Sending mail from console

2007-01-30 Thread Michael Kleinhenz
Hi,

I try to send an email from a console application using the integrated
osso-email, but it seems that ist does not have a console mode or a
suitable dbus call.

If I put a mail into apps/email/Mail/Outbox/ using a reengineered
filename (something like "accountname^Outbox^msgid"), the mail is
_sometimes_ delivered when calling send_and_receive, but not always.
Sometimes the mail is set on hold: I can see it in the Outbox folder of
osso-email but I have to manually force the send using the "send" button.

Is there a reliable way to insert an email into the internal mail spool?

Thanks,
Michael

-- 
Michael Kleinhenz
www.quendor.org

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] [maemo-announce] stage.maemo.org will go down at 1200 (EET); break for 20 mins

2007-01-30 Thread Ferenc Szekely
Hello,

Due to a hardware error stage.maemo.org will be down for approx. 20 minutes
today, starting at 1200 (UTC/GMT +2 hours).

We are sorry for the inconvinience it may cause.

Regards,
Ferenc
___
maemo-announce mailing list
[EMAIL PROTECTED]
https://maemo.org/mailman/listinfo/maemo-announce
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] N800 codes at UK shop

2007-01-30 Thread quim.gil
Some of you had trouble at the UK shop (some don't, >50% according to
our records). 

Hopefully this is a solution for the unfortunate:

http://direct.nokia.com/countries.aspx?model=N800&add=true&country=GB  

It should work. Otherwise contact phone/mail support of the UK shop. At
this point we believe all the online shops are aware of the N800
developer program and should be able to provide support and answers.
They can solve problems with i.e. credit cards - we don't.

Thank you again for your understanding. We are taking notes not to
forget.

--
Quim Gil
Maemo team
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


[maemo-developers] Re: Python/Contact Data Store APIs..

2007-01-30 Thread Ross Burton
On Mon, 2007-01-29 at 17:48 -0900, John P. Mitchell wrote:
> I want to write an address book that intergrates with the built in 
> contacts data store. Which libraries are required for accessing that data 
> store and are there bindings for them in the Python 2.5 release?
>  Has anyone tried using swig[1] to build a wrapper for binding Maemo C 
> libraries to Python?

To access the address book data you libebook, there is a tutorial on
maemo.org:

http://maemo.org/platform/docs/howtos/howto_using_abook_bora.html

However there are no Python wrappers.  The API is fairly standard
GObject style so you should have some success in using the existing
pygtk framework to wrap it.  The parsing tools are quite pedantic so
I'll happily modify any headers in the EDS svn repository to make it
build, as I'd love to see Python wrappers myself.

You may find http://www-128.ibm.com/developerworks/linux/library/l-wrap/
useful, it's a tutorial I wrote some time ago (but still mostly
relevant, not a lot has changed) that documents the basics in wrapping
GObjects for Python.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers