Re: Training for Maemo Development

[Aleksandr Koltsoff]

Merrick Fonnesbeck wrote:
> Does anybody know of any good training courses or seminars that are
> available in the United States for learning how to develop applications
> on the Maemo OS or geared toward developing for the Nokia Internet
> tablets?  I guess any training on Hildon UI, GTK, or Debian Linux
> development might be helpful as well.  We have started a project at work
> that is developing software for the Nokia N800/N810 and I need some good
> training/courses that will get me going in the right direction.  Please
> let me know if anybody knows of anything.  Thanks.

If you have a large enough team, organizing in-house training might be
feasible. There's some training material available (under CC-SA) here:
http://maemo.org/development/training/ which you can use. Covers the
basics of GTK+, Hildon, packaging and D-Bus.

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

Re: modification for the makefile

[Aleksandr Koltsoff]

Hi Vinod,

Vinod Hegde wrote:
> i have maemo 4.0 sdk and apophys scratchbox and want to know how can i
> insert a module in the scratchbox environment. i want to test insertion of
> helloworld module into my n810.  i wrote the "hello world" module and
> inserted on Linux machine. it gets inserted and prints the message. But the
> same makefile does not work in the scratchbox and i get the following error

The SDK cannot be used to test ARMEL kernel modules. You should do the
testing on the real target device instead. The SDK is not a system-level
emulator.

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

[announce] building out-of-tree modules on os2007/os2008 updated

[Aleksandr Koltsoff]

Hello

Decided to update the out-of-tree module build guide to OS2008 level,
available at http://koltsoff.com/pub/hello-n800/ . And yes I know that
there is also an official howto relating to maemo "kernel".

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

Re: Chinook install

[Aleksandr Koltsoff]

Hello

On Thursday 20 December 2007 17:51, [EMAIL PROTECTED] wrote:
> However, I found in the mameo 4 docs a little piece about making sure that
> binfmt_misc was loaded as a module. I loaded this module and ran the
> install script with the -d and -u options.
>
> It appears to be working... right now its happily downloading a bunch of
> packages.
>
> Now I have to figure out how to load this module automatically.

Add 'binfmt_misc' (without the quotes) to /etc/modules (on a line of its own). 
reboot, and lsmod to check that this worked.

ak.

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

Re: Is it possible to make a "well-behaved" pyGame app with maemo-python ?

[Aleksandr Koltsoff]

Pierre Amadio opened a bug about this issue already way back:
https://bugs.maemo.org/show_bug.cgi?id=1475

(The bug is still set at "NEW").

Fred Pacquier wrote:
> Eero Tamminen a écrit :
>> So you've now verified that Exec part works, whether it's in
>> .desktop or .service file.  What about the service name,
>> Does the service name in .desktop match the .service file?
>> I don't really know D-BUS, but when looking at the maemoblocks
>> stuff on the device:
>> /usr/share/applications/hildon/maemoblocks.desktop:
>> X-Osso-Service=br.org.indt.maemoblocks.startup
>> /usr/share/dbus-1/services/br.org.maemoblocks.startup.service:
> 
> I hope there's a typos in that filename (missing.indt) or I don't 
> understand anything anymore :-)

1) The name of the .desktop file is not important. Task navigator will
scan through the directory (/usr/share/applications/hildon/) whenever
there's a change in that directory and will read through the files (not
sure whether only the new file are all files).

For consistency, using a filename like "programname.desktop" would be
logical (IMO). One menu-entry per application.

2) The contents of .desktop file is important. X-Osso-Service is the
D-Bus well-known name that Task navigator will attempt to activate via
D-Bus daemon.

3) The name of the .service file is not important. The D-Bus bus daemon
will read all files from /usr/share/dbus-1/services whenever that dir
changes (similar to Tn above).

It seems that there are no established conventions in maemo for the
filename here. One sees names which contain the well-known-name
(com.nokia.foo.service) and names which contain the application name
(application.service). Technically the name is NOT significant. I'd
think that using the well-known name as part of the filename
(com.nokia.foo.service) would be more logical here, since a single
application can provide multiple well-known-names (each being described
in a separate service file).

4) The contents of the .service file is important. It tells the bus
daemon which program to run when:
a) Someone will attempt RPC to a well-known name that is not already
registered (program providing that name hasn't been started).
b) The service name in a service file matches the "well-known" name of
the request. In the case of applications started via Tn, this must match
exactly the name given in "X-Osso-Service".

It would be nice to get debugging output from D-Bus daemon in this case
(when it can't find any service file matching an RPC request OR fails to
find the executable listed with Exec, OR fails to start the executable).
Not sure whether dbus-monitor can be used nowadays (4.0) for this. But
some kind of debugging support would be very much useful.

5) Once the daemon will start the Exec program that _should_ provide the
name, the program will need to register that name onto the D-Bus. This
can be done with creating the OSSO context (or by other means, as long
as the correct name will appear on the bus).

So, the above rules pretty much contain everything that needs to be done
in order for the activation to work. The rules are indeed complicated by
the fact that when one uses non-qualified names (names without dots in
them), 2) and 5) will prefix the listed name with "com.nokia.".

For 3rd party applications, you should never use names without dots in
them, to avoid the prefixing. This is unfortunately not explained in any
of the HOWTO/tutorials, but can be "easily" read from LibOSSO source
code. Fixing the documentation comments in LibOSSO to explain the
behaviour wrt names in
http://maemo.org/api_refs/4.0/libosso/group__Init.html#g05d45d1e72c2cd74f665086225141431
would be nice as well. The documentation can now easily be understood to
mean that "com.nokia." is always prefixed, when it fact it's only
prefixed when the 'application' parameter doesn't contain any dots.

Here, debugging support would again be nice, so that one could see:
a) what application is started (Exec) and the commandline (Exec)
b) what name(s) the application will register on the bus
c) whether the application registers any names (this is the case where
the app would eventually be killed).

As for application icons missing from Tn, I think that's a separate issue.

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

Re: web based local application GUIs

[Aleksandr Koltsoff]

Hello,

Tomi Ollila wrote:
> On Wed 28 Nov 2007 00:21, Aleksandr Koltsoff <[EMAIL PROTECTED]> writes:
>> The lo interface is UP and running.
> 
> You're right! By a coincidence I have both 770 and 800 on my desk now,
> neither running the latest OS version and both, indeed, have localhost
> interface up like the above (/sbin/ifconfig gives same output)
> 
> So I remember incorrectly -- the real reason is (probably) that when
> socket(2) system call is started, these Internet Tablets tries to make
> internet connection up (either via wlan, or bt-connected phone)
> and if that cannot be made, socket(2) fails. 
> There is no way knowing at socket(2) time that user wants to connect(2)
> 127.0/8 addresses. There is probably good reason to wrap socket() instead
> of connect(), bind() (and some other system calls.. timeouts maybe...).
> 
> Well, I'm (quickly) writing this without checking earlier discussion 
> of the matter. The situation is probably well-explained there (?).

Ah yes, this does indeed sound slightly familiar back from the 1.0 days.
Maybe a proper testing program is in order then. I might take a look at
this later if I have spare time. If the syscall is wrapped, then yes, it
 would make things slightly difficult, but I'm wondering whether there's
a simple way to avoid that even in that case.

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

Re: web based local application GUIs

[Aleksandr Koltsoff]

For some reason can't find the mail that had the below quoted part, but
anyways:

[EMAIL PROTECTED] wrote:
>  Jesse Guardiani <[EMAIL PROTECTED]> wrote: 
>> On 11/27/07, Tomi Ollila <[EMAIL PROTECTED]> wrote:
>>> On Tue 27 Nov 2007 16:27, "Jesse Guardiani" <[EMAIL PROTECTED]> writes:
>>> localhost inet sockets do not work in offline mode.
>>>
>>> Which, btw, is pretty weird (IMHO). I have not seen this behaviour in any
>>> other unix system; results of "ifconfig lo 127.0.0.1" has preserved over
>>> changes in any other interfaces (static and dynamic).
>>>
>>> Why can not the loopback interface be up all the time ??

Tested on N810 just a moment ago:
1) put device in flight mode
2) /sbin/ifconfig
loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:38 errors:0 dropped:0 overruns:0 frame:0
  TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:14929 (14.5 KiB)  TX bytes:14929 (14.5 KiB)

The lo interface is UP and running.

If by "inet socks not working" you mean "localhost" not resolving to
127.0.0.1, then say so. The lo interface seems to be running and well.

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

Re: OS2008 N800 and root password

[Aleksandr Koltsoff]

Hello

william maddler wrote:
> Am I wrong? Or root password on OS2008 for N800 is not "rootme" anymore?
> Thank you.

It is. However if you refer to logging in over ssh, the device needs to
be in R&D mode to allow you in as root.

You're welcome.

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

Re: debugging spontaneous reboot issues with N800/N810

[Aleksandr Koltsoff]

Hello,

Thanks Kalle & Eero for the enlightening comments & info, much appreciated.

Eero Tamminen wrote:
> ext Kalle Valo wrote:
>>> 3) Asterisk marks the application that caused the last wd timeout
>>> operation? (so in this case, the spontaneous reboot was caused by dsp_dld
>>> or it at least seems so?)

Any ideas on the asterisk though? It's only ever set on one name at a time.

>> There is no way to know what cause hardware watchdog reboot. It can be
>> a problem in kernel, or some userspace application taking all the CPU
>> time.

Right. So debugging a spontaneous system reboot is pretty impossible
after the hw watchdog triggers, if I understand correctly.

Any ideas on how to proceed though? I'd like to post a bug, but without
any ideas on what is causing the reboot, the bug report isn't going to
be very useful to anyone.

> Some process just taking all CPU doesn't cause HW watchdog reboot.
> Some OOM-protected[1] process (such as Desktop) taking all memory
> (e.g. due to a leak in an applet) so that kernel spends all time
> just suffling memory pages can cause it though.
> 
> [1] OOM-protected = processes ignored by the kernel out of memory
> killer. Applications (such as Browser) are not not OOM-protected.
> If they use too much memory, kernel kills them to protect
> rest of the system.  (before this allocations are denied to
> them, but this doesn't help if other processes in the system
> need more memory too)

Only processes on the OOM-protected list will be protected, right? This
would imply that by default any other process would fall under the
OOM-killer in the kernel (which makes sense).

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

debugging spontaneous reboot issues with N800/N810

[Aleksandr Koltsoff]

Hello

I've now seen both of the subject devices rebooting spontaneously after
long times of inactivity (just sitting on the table).

I was pointed to http://maemo.org/community/wiki/reportingrebootissues/
, which seems like a good start, but doesn't explain enough. So, I have
some questions to fellow users/developers who might be able to fill in
the gaps.. (all info appreciated)

So, some stuff that I'm seeing (on a N800):

cat /proc/bootreason:
32wd_to

This means that the hw watchdog was triggered and caused the reboot.
That's cool.

ls -la /var/lib/dsme/stats/:
drwxr-xr-x 2 root root 0 Nov 21 21:33 .
drwxr-xr-x 3 root root 0 Aug 13 08:19 ..
-rw-r--r-- 1 root root 2 Nov 21 21:33 32wd_to
-rw-r--r-- 1 root root   120 Nov 13 15:26 lifeguard_restarts
-rw-r--r-- 1 root root 2 Nov 13 13:40 sw_rst

cat 32wd_to:
2
Question: Does this count the times that the hw-watchdog was triggered
so far (after last flash)?

cat sw_rst:
1
Question: Number of times "critical 'system' application crashing or
being killed by the kernel OOM-killer" happened? (quoted text from the
wiki page)

cat lifeguard_restarts:
/usr/bin/esd : 1
/usr/sbin/multimediad  : 1
/usr/sbin/dsp_dld -p --disable-restart \
  -c /lib/dsp/dsp_dld_avs.conf : 1 *
(line continuation in the last one was made by me)
Question: Now this is the interesting part:
1) Am I correct to assume that each line records the name of the program
that was running when the hw watchdog triggered?
2) And the number after each records the times that the programs were
running when the watchdog tripped?
3) Asterisk marks the application that caused the last wd timeout
operation? (so in this case, the spontanous reboot was caused by dsp_dld
or it at least seems so?)

---

For reference, same info from N810, however, I've booted the device once
normally after the spontaneous reboot:

cat /proc/bootreason:
pwr_key

cat 32wd_to:
2

cat sw_rst:
1

cat lifeguard_restarts:
/usr/bin/hildon-input-method  : 1
/usr/sbin/ke-recv : 1 *

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

Re: cannot resolve repository

[Aleksandr Koltsoff]

Actually what you could/should do, is as follows:

1) Install dnsmasq on your real host. Defaults should be ok, no need to
mess with your real host resolv.conf. Dnsmasq will read that and update
it's own internals when/if necessary automatically. Also, if using
Debian/Ubuntu, you don't need to touch dnsmasq default setup. It will
work out of the box.

2) Modify the /etc/resolv.conf in your sbox targets to read:
nameserver 127.0.0.1

This way sbox name resolution will use the dnsmasq that is running on
your real host, and you'll never have to touch your sbox resolv.conf again.

Very useful when using the machine in dhcp environments and/or traveling
around.

ak.

Bryan Kate wrote:
> Thank you. I checked most of them but I did not realize there were so many 
> copies. Also, the file is fairly dynamic on the host system, so it was not 
> being copied properly when it changed from site to site.
> 
> - Bryan
> 
> 
> Loïc Minier wrote:
>> On Mon, Nov 19, 2007, Bryan Kate wrote:
>>> I know the solution to this problem is all over the net, but I still
>>> cannot seem to fix it. I get the following error when I try to run
>>> 'apt-get update' on any target in scratchbox. 
>>  You didn't mention checking /etc/resolv.conf, so you might want to try
>>  that (in your rootstrap).
>>
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers

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

Re: Check if application is run

[Aleksandr Koltsoff]

Hi,

Eero Tamminen wrote:
> ext Aleksandr Koltsoff wrote:
>> Eero Tamminen wrote:
>>> ext Aleksandr Koltsoff wrote:
>>>> I think in your case it would be sufficient to do something like this:
>>>> .. snip ..
>>>> while(1) {
>>>>   system("./run-your-application params");
>>>>   sleep(2);
>>>> }
> .. big snip .. 
>> If the application is completely broken, and will fail to start in any
>> case, then this would amount to polling, and would shorten battery life.
> 
> This would happen also if the process daemonizes itself.

Indeed. In that case the above starting loop would eventually cause N
copies of the child to run (barring exclusive resource usage inside the
child) and would eventually result in dragons flying out of ones nose. I
guess the original context was "how to run and restart an SDL game". I
didn't assume that the game would daemonize itself :-).

Should the program (I'll ignore the SDL-game now) daemonize itself, one
is left with the original second problem though. Since the daemonized
process is no longer a child process to the starter, how does the
starter know when the now daemonized child will terminate? (since
daemonization involves moving under init directly and breaking the
original parent<->child relationship). This brings us back to the issue
that Linux doesn't have a non-polling solution to wait until some PID
exits (and even the polling ones are racy, but triggering that race
would require quick PID-space exhaustion between the polls).

This problem isn't by any means to related to ITs though.

> ext Aleksandr Koltsoff wrote:
>> My original post did suggest handling exit codes of the child properly,
>> but I guess that was lost somewhere in the process..
>>>> Linux (kernel) does not have a non-polling mechanism to track
>>>> PID-existance for non-related processes.
>> Eero Tamminen wrote:
>>> It has, you just need to be the process parent.  :-)
> ext Aleksandr Koltsoff wrote:
>> Note the "non-related" part :-). Parent <-> child = related processes.

Suggestion for Nokia, could you join IEEE 1003 and add an asynchronous
PID-waiting syscall to POSIX? /me hides & runs.

Seriously though, adding the capability to the Linux kernel isn't all
that hard, but the problem is that it would "bloat" each task structure
with at lest one pointer (list-head), in a similar way that the process
accounting support does. Hence, it is not free (resource wise) to
implement. Other possibility would be using a global structure to keep
all the pid-trackers, but that's even worse solution (wrt scalability
across multiple logical CPUs, and locks and all that evil crufty stuff).

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

Re: Check if application is run

[Aleksandr Koltsoff]

Eero Tamminen wrote:
> ext Aleksandr Koltsoff wrote:
>> I think in your case it would be sufficient to do something like this:
>> while true; do
>>   ./run-your-application params
>>   sleep 2
>> done
>>
>> Or in C:
>>
>> while(1) {
>>   system("./run-your-application params");
>>   sleep(2);
>> }
> 
> That would shorten the battery life. If one really needs/wants
> to kludge things with polling, the interval should be several
> times larger.

When the application is running, both methods wait for the process to
terminate, i.e., no polling. man 3 system. The idea originally was that
should the application terminate, it will be restarted after a while.

If the application is completely broken, and will fail to start in any
case, then this would amount to polling, and would shorten battery life.
My original post did suggest handling exit codes of the child properly,
but I guess that was lost somewhere in the process..

>> Linux (kernel) does not have a non-polling mechanism to track
>> PID-existance for non-related processes.
> It has, you just need to be the process parent.  :-)

Note the "non-related" part :-). Parent <-> child = related processes.

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

Re: Problems logging in to scratchbox after reboot

[Aleksandr Koltsoff]

Your kernel needs "compat VDSO"-support.

ak.

Stelian Iancu wrote:
> That was it, many thanks!
> 
> Now I have other errors:
> 
> [EMAIL PROTECTED] ~]$ /scratchbox/login
> Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion `(void 
> *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!
> 
> You dont have active target in scratchbox chroot.
> Please create one by running "sb-menu" before continuing
> 
> 
> Welcome to Scratchbox, the cross-compilation toolkit!
> 
> Use 'sb-menu' to change your compilation target.
> See /scratchbox/doc/ for documentation.
> 
> Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion `(void 
> *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!
> Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion `(void 
> *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!
> Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion `(void 
> *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!
> 
> But I know the cause of these, it seems that the Fedora 8 kernel doesn't 
> have VDSO compat enabled. Hmm ... I wonder if I need to rebuild the 
> kernel ...
> 
> Regards,
> Stelian
> 
> Alfredo J. Fabretti wrote:
>> Try:
>>
>> /scratchbox/sbin/sbox_ctl start
>>
>> before login
>>
>>
>> On Nov 13, 2007 5:36 PM, Stelian Iancu <[EMAIL PROTECTED] 
>> > wrote:
>>
>> Hi all,
>>
>> I have successfully installed scratchbox on Fedora 8. However, after a
>> reboot of the machine, I am getting the following:
>>
>> [EMAIL PROTECTED] ~]$ /scratchbox/login
>> ERROR: Scratchbox is not properly set up!
>>
>> Any idea what might be the problem?
>>
>> With regards,
>> Stelian Iancu
>> ___
>> maemo-developers mailing list
>> maemo-developers@maemo.org 
>> https://lists.maemo.org/mailman/listinfo/maemo-developers
>>
>>
>>
>> 
>>
>> ___
>> maemo-developers mailing list
>> maemo-developers@maemo.org
>> https://lists.maemo.org/mailman/listinfo/maemo-developers
> 
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers

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

Re: Support to non-Linux developers (was Re: General Maemo/Scratchbox/N800 help)

[Aleksandr Koltsoff]

Hello,

Darren Kenny wrote:
> I'm a regular user of non-Linux distro - OpenSolaris/Solaris - that is both 
> x86,
> has qemu, Xephyr, etc. Would be great to get this working on Solaris too -
> although I'm biased I suppose ;)

Does solaris support anything like linux binfmt? (telling the kernel to
launch a program based on the file header via a "freely" selected
program?). Note that this is not the same as #! as often used in
scripts, but much more generic (since program files rarely start with
those two bytes).

If not, then getting sbox working on solaris might be "tad difficult".

Getting sbox working on solaris should be priority 1 for you in this
case. Getting maemo working inside sbox should be attempted only after this.

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

Re: Check if application is run

[Aleksandr Koltsoff]

Hi

Michael Stepanov wrote:
> when the SDL program crashed by some reason to run it again. What is the
> most efficient way to periodically check something in the Maemo SDK?

I think in your case it would be sufficient to do something like this:
while true; do
  ./run-your-application params
  sleep 2
done

Or in C:

while(1) {
  system("./run-your-application params");
  sleep(2);
}

Linux (kernel) does not have a non-polling mechanism to track
PID-existance for non-related processes (adding this is not that hard,
one hooks into the same logic that is used for BSD style process
accounting, but this isn't present in stock kernel).

Obviously you'll want to also check the reason why your application
"crashed" and act on that (branching on the exit code) but that was
omitted from the above snippets.

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

Re: How to setup multicast over wifi, 3G, DVB-H ?

[Aleksandr Koltsoff]

Hello Darius (and others),

Darius Jack wrote:
> But what I need to establish is open multicast - broadcasting channel for 
> media (TVersity or another streaming back end servwer).
> 
> In ethernet configuration multicast packets from multicat IP range are copied 
> by a router and sent to each respective IP address assigned by DHCP server 
> running at multicast router .

Multicast in ethernet actually works slightly differently. There is a
mapping from the IP-group addresses ("class d") into specific Ethernet
MACs (which have the broadcast bit set, but not all bits are set to
ones, as in broadcast). Stations on the same segment will then filter
those packets which they deem "useful" (based on programs binding for
multicast IP addresses for reception). Routing multicast IP traffic is
an different issue, as is multicast filtering (both require a working
IGMP setup and multicast routing also requires some higher level
multicast routing protocol like PIM). DHCP is not involved (other than
when used as MADCAP server, which is not common in UNIX/Linux world).
IPv6 changes these things slightly as well.

> Multicast over wifi should be configured as an open stream channel like 
> DVB-H/G3 to provide open listen to, access to any device switched to listen 
> to mode , like fm radio , sat tv or the like.

"Wi-Fi" (802.11a/b/g) works as a transparent "ethernet" service. So in
fact, multicasting IP traffic in a wireless 802.11 environment isn't any
different from multicasting in ethernet. A problem which people often
will run with multicast in wireless is encryption (WEP/WPA/CCMP) and
bad/flakey support of access points to do use correct keys for broadcast
and multicast traffic. A lot of the cheaper APs have serious problems
with proper key usage anyway unless one uses shared key WEP. However, in
your case I think it wouldn't be a problem as you seem to want to run a
"public/open" wireless setup.

> So please let me know how to setup media streamer client's application to 
> ignore IPs in packets streamed by server and have to read selected open 
> channel wifi stream , bufor and read in media streamer application.

Not really sure what you're after here. You might start testing your
setup by running the video lan client (vlc) (for streaming and testing
multicast) first, and when your wireless setup seems to work with normal
Linux boxes over wireless, you'll want to find a media client/player for
the Internet Tablets which is capable of receiving unreliable/multicast
streams and start hacking on that (a topic where other people surely can
help).

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

Re: Debian toolkit mismatch

[Aleksandr Koltsoff]

Hi Ludovic (and others),

Ludovic Courtès wrote:
> In Scratchbox (ARMEL target), I'm observing strange inconsistencies
> between `dh_make' and `dpkg-buildpackage'.  Basically, `dh_make' creates
> `debian/{control,changelog}' files that are considered invalid by
> `dpkg-buildpackage':

You'll need to set your DEBFULLNAME envvar when running dh_make. If the
maintainer name is empty, you'll end up with broken changelog.

So something like this:

DEBFULLNAME="First Lastname" dh_make -e [EMAIL PROTECTED] -f
../path-to-dist.tar.gz

(so nothing special, just make sure that you've set DEBFULLNAME when
running the tool).

This broke somewhere between 1.0 and 3.2 (it used to work fine without
DEBFULLNAME in 1.0).

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

Re: DBus problem

[Aleksandr Koltsoff]

Michael Trunner wrote:
> did I need run-standalone.sh even on the n800?
> I try it direct on the n800, not in scratchbox.

You need run-standalone on the device if you plan to attach to the
session bus. Attaching to the system bus works without the wrapper
script, although I'd recommend you use it anyway.

You can test for this yourself by running dbus-monitor on the device
(with and without the wrapper, with --system and with --session).

ak.

> Aleksandr Koltsoff schrieb:
>> Hi Michael,
>>
>> Michael Trunner wrote:
>>   
>>> I tried to write a small program that has a dbus method that should
>>> called from an other application. The program works on my ubuntu with
>>> out problems and I can compile it in scratchbox. But when I start it and
>>> try to call the method over dbus nothing happens. The calling software
>>> is waiting for an answer, that my program didn't send. Even the function
>>> isn't called, but the rest of the program works perfect so the
>>> gtk_main_loop is running.
>>> 
>> You did run it with run-standalone.sh?
>>
>> run-standalone.sh ./yourprogram param1 param2
>>
>> (no spaces allowed in parameters)
>>
>> If it still doesn't work, you probably didn't start the application
>> framework: af-sb-init start (you need working DISPLAY for this).
>>
>> ak.
>>
>>   
> 

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

Re: DBus problem

[Aleksandr Koltsoff]

Hi Michael,

Michael Trunner wrote:
> I tried to write a small program that has a dbus method that should
> called from an other application. The program works on my ubuntu with
> out problems and I can compile it in scratchbox. But when I start it and
> try to call the method over dbus nothing happens. The calling software
> is waiting for an answer, that my program didn't send. Even the function
> isn't called, but the rest of the program works perfect so the
> gtk_main_loop is running.

You did run it with run-standalone.sh?

run-standalone.sh ./yourprogram param1 param2

(no spaces allowed in parameters)

If it still doesn't work, you probably didn't start the application
framework: af-sb-init start (you need working DISPLAY for this).

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

[announce] step-by-step guide for building kernel modules for N800

[Aleksandr Koltsoff]

Hello

Decided to write a small blurb about the subject after I proving myself
that building kernel modules isn't as straight-forward in the SDK as one
might assume.

You can find the blurb here: http://koltsoff.com/pub/hello-n800/ .

Feedback appreciated (via private email, or IRC ([EMAIL PROTECTED])).

ak.
-- 
RHCX/MCSE:Sec, http://koltsoff.com, LinkedIn(tm)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] The future of the Application installer

[Aleksandr Koltsoff]

Hello, this is a late reply but might be documented anyway.

On Monday 07 November 2005 14:16, Marius Vollmer wrote:
> as you all know, the current Application installer sucks more than
> Cygnus X-1 [1], and this needs to change.

Personally I think the AI is wonderful ;-). Seriously though, what about this 
idea (not going into implementation issues here):
- have AI retrieve a categorized software catalog over maemo (and maybe some 
other site for N-supported software if there ever will be such a thing). In 
short, multiple repo support, maybe with an XML file rooted at maemo.org for 
the first time.
- For each application, make it possible to download a textual (localized) 
description of the package and a screenshot. Esp the screenshot. Also a link 
to the homepage of the project/package if such exists.
- These things probably should be centralized in maemo.org or some repo at 
least. I'm not sure whether the downloadable packages should also be 
distributed via centralized repos, but that would surely cut down 
intermittant problems with web servers going offline and back off (other than 
maemo.org that is).
- The user could then just install the package by pressing 'Install now' and 
AI2 would download the package and install it (if no dependency problems).

More feedback on the reasons why package installations fail would also be 
appreciated. And no, I don't think that "Package already installed" would cut 
it ;-).

There are also other ideas but they're pretty silly so I thought I'd just 
write down the not-very-silly ones.

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

[maemo-developers] bi-di BT-link between two 770s

[Aleksandr Koltsoff]

Hello

Since my BT skills are non-existant, I'm asking for help for this project. I'm 
thinking of implementing a simple util library that would provide two-way 
stream-communication between games running on two 770s (same game obviously).

How should I proceed in this? The following issues come into mind, but I'm 
looking for someone who would have concrete information on how to solve these 
problems:
1) When starting the game, how does the end-user "see" the other 770-device? 
ie, is pairing necessary, and is there a GUI for this (connection damager?)
2) What do I need to do to make 770 visible to the other 770 (assuming there 
is a GUI for this on the other side). Can this be done programmatically 
without requiring user intervention?
3) Is using RFCOMM-sockets between the devices a suitable transport? (I'm 
looking for something akin to TCP). It can be assumed that only one program 
will be active on a device at one time that needs this, so I guess BT-MAC 
address is enough to connect?
4) Can all of this be done with a normal application installed via the AI on a 
stock 770? (not requiring the user to reflash from the sales sw version)

So, mostly the questions arise from my lacking experience with BT-programming 
and my lack of experience with the 770 sw.

If you know whether the problems above can be solved, I'm interested in 
hearing from you. I plan to release the utility lib under lgpl if it's 
possible to implement at all (I know that technically anything is possible, 
but question 4 might stop this from being possible).

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

Re: [maemo-developers] Re: Flasher debs

[Aleksandr Koltsoff]

On Thursday 27 October 2005 15:59, Aleksandr Koltsoff wrote:
> I agree with Timo on this one. Just came up with another package that could
> be placed in such repo. The documentation html-stuff. Would be nice to be
> able to download the docs in proper /usr/share/doc-path when going on a
> trip with a laptop (or even with GPRS). Would make updating docs and
> flasher easier as well (would be part of regular apt-get update -process).

This could be taken a step further infact. Assume that a separate repo would 
exist for debian-based development.

Make a package called 'maemo-sdk'. It would contain preinst/postinst logic to 
download and install the sdk files (user could be asked to select whether 
they want to install both x86 and arm-versions). It would also depend on the 
flasher-deb and the documentation-deb (if one would exist). Could also depend 
on devhelper, but could be difficult to do so that it devhelper would include 
the versions of datafiles suitable for exact GTK/Glib-versions used in the 
SDK. So, it would also install sbox, and configure the targets (by using 
default names "SDKx86" and "SDKarm" or similar). It would also configure 
xephyr and such.

This way getting and starting the SDK would be simplified for new users as 
well as the sbox version supported by the SDK could be limited to 0.9.8.5 (or 
whatever will be supported in later versions).

This requires real work on N's part though, but isn't impossible.

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

Re: [maemo-developers] Re: Flasher debs

[Aleksandr Koltsoff]

On Thursday 27 October 2005 15:49, Timo Savola wrote:
> On Thu, Oct 27, 2005 at 03:42:04PM +0300, [EMAIL PROTECTED] wrote:
> > On Thu, 27 Oct 2005, Aleksandr Koltsoff wrote:
> > > Other possibility is making a separate deb repo for tools that one
> > > would find useful when developing on debian, but since flasher is the
> > > only tool at the moment, that might be an overkill.
> > >
> > > ak.
> > I think that Timo wanted a debian repo that could have been put to a
> > sources.list and installed with apt-get. Single debian package that would
> > be downloaded via web page and installed to host with dpkg (after
> > click-through license agreement) is IMHO quite pointles because then it
> > would require one step more to use the flasher.
> Actually, I wanted none of those things.  I want a Debian package that
> shows up in the dpkg database (with proper version information) so that I
> don't have any unaccounted-for files installed on my system.
>
> Downloading a file using a browser and installing it with dpkg is as easy
> than adding a line to sources.list, updating and installing.  (I suspect
> that the flasher isn't going to be updated very often.)

I agree with Timo on this one. Just came up with another package that could be 
placed in such repo. The documentation html-stuff. Would be nice to be able 
to download the docs in proper /usr/share/doc-path when going on a trip with 
a laptop (or even with GPRS). Would make updating docs and flasher easier as 
well (would be part of regular apt-get update -process).

ak.

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

Re: [maemo-developers] Re: Flasher debs

[Aleksandr Koltsoff]

On Thursday 27 October 2005 10:45, Ferenc Szekely wrote:
> ext Timo Savola wrote:
> > How about providing Debian packages (i386 and powerpc) of the flasher?
> yes, it is the license that prohibits us to distribute the tool in a
> debian repo. we could place the deb packages to the same place, but it
> does not help much, i guess.

How about placing the deb packages somewhere where people download the SDK 
from? Should probably be a separate directory with a README that would note 
that the deb is not meant to be installed within SDK env. It would help 
though.

Other possibility is making a separate deb repo for tools that one would find 
useful when developing on debian, but since flasher is the only tool at the 
moment, that might be an overkill.

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

Re: [maemo-developers] Enough theory...

[Aleksandr Koltsoff]

Hello all

"Component already included" -> Package Depends is wrong. Needs only depend on 
"maemo", nothing else. Also note that no pre/post-install scripts will be run 
from the package, so if package installation depends on them, it will break, 
but at least you won't get the nice & "descriptive" error message ;-). And as 
was noted, the installation root is /var/install ("making new 
packages"-document).

Of course the error might be caused because of other things as well, but this 
is what worked for me.

ak.

On Wednesday 19 October 2005 23:26, Ralf Engels wrote:
> Hi Janne,
> that does not explain the error (which component is already included) and
> it also does not explain why I get the error when I try "helloworld" and
> "maemopad".
>
> I am waiting since several weeks that this get's fixed.
> Meanwhile I play Sokoban.
>
> BR,
> Ralf
>
> On Wed, 19 Oct 2005 19:36:22 +0300
>
> Janne Kataja <[EMAIL PROTECTED]> wrote:
> > Mattias Schlenker wrote:
> > > Today UPS dropped off a brandnew N770. I wanted to start installing
> > > applications, AbiWord from indt.org.bra but maemo refused to install
> > > libfribidi with a strange error message saying something like
> > > "component already included", the same with Maemo Word processor.
> > > Since this little bastard does not sport a console I am feeling a
> > > little helpless...
> >
> > The application installer packages need to be in a special format, see
> > http://maemo.org/platform/docs/howtos/howto_making_an_application_package
> >.html
> >
> > I am writing a script based on equivs that takes a control file and a
> > bunch of Debian packages and combies them to an application installer
> > package. More on that later this week.
> >
> >
> > Janne
> >
> > --
> > Janne Kataja, Movial Corporation
> > Porkkalankatu 13 J, FI-00180 Helsinki
> > Mobile +358 40 550 9801, Tel +358 9 8567 6400
> > Fax +358 9 8567 6401
> > www.movial.fi
> >
> > ___
> > 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
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] delay

[Aleksandr Koltsoff]

On Tuesday 30 August 2005 12:21, rh wrote:
> Hi all,
>
> Does anyone know what command to make delay time in maemo ?
> And maybe with sample program ?

Your question doesn't make sense but here goes :-).

On command line use a program called 'sleep x' where x is the time to wait in 
seconds. Inside a program code use usleep or some variant. You can also use a 
travesty called system("sleep x"), but YMMV based on your skills. In GTK+ use 
GLib timers (they work quite nicely there without blocking the GUI-loop).

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

Re: [maemo-developers] create, remove & check directory/folder

[Aleksandr Koltsoff]

On Thursday 18 August 2005 10:15, rh wrote:
> Hi all,
>
> Does anyone know how to create, remove & check directory/folder for maemo
> program ? I don't see these references in GTK+ 2 API.
> GNOME-vfs just for files ?
> Please help.

Try http://developer.gnome.org/doc/API/gnome-vfs/ (or google for gnome-vfs, 
it's the first hit).

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

Re: [maemo-developers] Maemo Terminal - 0.1

[Aleksandr Koltsoff]

> 2005/8/15, Mayank Jain <[EMAIL PROTECTED]>:
> > So, what you are saying is, menus can be used to display the status of
> > executing commands (or last executed command). If anyone wants to
> > switch between the appviews, menus should be used?

Yes. That was the main idea. Although I'm not sure how usable it would be. 
Note that I can't imagine opening multiple sessions in 770, although I do 
that all the time on regular sized desktops. So it might be enough to use the 
TN-functionality. The problem with the TN approach could be (haven't tested) 
when you have more than a small amount of sessions. How does TN handle let's 
say, 20 "appviews"/applications open at the same time? (again, just guessing 
this time since I haven't tried this myself on maemo).

If terminal emu use will be restricted to the VKB and the pointer, one could 
do more with usability by integrating some prediction on shell commands and 
file names directly in the VKB (some kind of small file/path selector) and 
some vkb-local command history mainly so that often used commands can be 
selected quickly, even between the sessions). This is probably impossible to 
do without taking VKB apart and it would require specialized code, so I'd 
think it's a no-no. Probably not worth it iff BT keyboards will work.

Just my 20 mm worth :-).

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

Re: [maemo-developers] Maemo Terminal - 0.1

[Aleksandr Koltsoff]

On Monday 15 August 2005 10:33, Kalle Vahlman wrote:
> 2005/8/15, Aleksandr Koltsoff <[EMAIL PROTECTED]>:
> > What about the following points:
> > - tabs are useful when browsing the web, I've found them less useful with
> > terminals (I disable them since they eat screen-estate, even if I have
> > plenty of that to go around).
>
> My point was mainly that appviews already implement the functionality
> of tabs, so using tabs that take up additional space is just silly.

I don't disagree with you :-).

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

Re: [maemo-developers] Maemo Terminal - 0.1

[Aleksandr Koltsoff]

On Monday 15 August 2005 10:16, Mayank Jain wrote:
> On 8/15/05, Kalle Vahlman <[EMAIL PROTECTED]> wrote:
> > 2005/8/15, Mayank Jain <[EMAIL PROTECTED]>:
> > I'm not following you. HildonAppViews can have unique titles, if
> > that's what you are worried about. Multiple appviews with multiple
> > tabs sounds like duplicating functionality *and* losing screen-estate.
>
> Or there can be a nice way of switching between multiple appviews,
> something managed by a small toolbar.
>
> > Disclaimer: I consider myself to be the president of "Developers
> > against tabs" foundation, so take my rants with some moderation ;)

What about the following points:
- tabs are useful when browsing the web, I've found them less useful with 
terminals (I disable them since they eat screen-estate, even if I have plenty 
of that to go around).
- having multiple views is certainly useful, however I dislike the idea of 
having a "small" toolbar to indicate them as well. Most of the time I'm not 
interested in seeing how many I have
- but, sometimes it's useful to see what the different tabs are doing

So, what I'm proposing is having an appview per session, and listing all open 
sessions (and what they're doing/current directory) in the appview menu 
(directly or in a submenu).

Besides, if not using bt-keyboard (iff it will work), the virtual keyboard 
will be eating a lot of screenestate as it is.

How does this sound? Certainly easier to implement than a small toolbar or 
having the tab-view.

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

Re: [maemo-developers] Maemo Planet live.

[Aleksandr Koltsoff]

On Monday 01 August 2005 12:51, [EMAIL PROTECTED] wrote:
> Hi all!
>
> Today we published the maemo.org Planet. You can find it at
> http://planet.maemo.org .

Cool. What is it? ;-)

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

Re: [maemo-developers] new software for 770

[Aleksandr Koltsoff]

On Thursday 21 July 2005 16:09, Brad Clements wrote:
> http://www.fabrica.it/flipbook/
>
> I guess flipbook is done with flash, but any drawing program that saves 1-
> bit jpgs and can flip through them will work..

Hello

Please consider using another format besides jpeg for 1-bit images (png) since 
there is no such thing as 1-bit jpegs.

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

Re: [maemo-developers] Porting applications for Maemo

[Aleksandr Koltsoff]

On Wednesday 13 July 2005 08:00, Daniel Monteiro wrote:
> 8-O
> "everything I know is wrong!"
>
> I must review my concepts =-) thanks for the help.

I found an excellent book on ARM couple of weeks backwards (excellent as in 
content _and_ style, which doesn't happen very often):

Steve Furber: ARM system-on-chip architecture, published by addison-wesley 
(2nd ed yr 2000).

Yes, it's a bit dated, doesn't cover OMAP but covers ARM very nicely (all 
architectures up to ARM11).

If you're more of the technically minded person, you'll like it. For ppl 
looking for "arm for dummies", this is definitely not the book.

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

Re: [maemo-developers] Re: some precisions

[Aleksandr Koltsoff]

On Friday 08 July 2005 10:56, Rakotomandimby Mihamina wrote:
> Aleksandr Koltsoff wrote:
> > to go trough the GTK+ tutorial first (although it is quite outdated), be
> > sure to use the version 2.x tutorial, not the 1.x. When you've done
> Do you mean this:
> http://www.gtk.org/tutorial/

Yes. It's a bit dated (it uses in places some deprecated API calls) so you'll 
need to consult the GTK+ API docs while you're playing with the code in the 
tutorial so that you don't learn to use the obsolete stuff.

Also note that the version of GTK+ in maemo SDK is 2.6.x and the newest 
version of GTK+ API docs is for 2.7.x (you can find 2.6.x API docs in the 
same place though, ask google if unsure).

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

Re: [maemo-developers] some precisions

[Aleksandr Koltsoff]

On Friday 08 July 2005 00:06, Rakotomandimby Mihamina wrote:
> (Sorry to flood ;-) )

You're welcome :-)

> We mostly master Python/OCaml/C than Java.
> At school/college/univesrity, we made some complicated programs, but
> never X11 applications, and very few multiple files project (all our
> homeworks/projects were about one large file) and only command-line
> based. Not event ncurses based.

You don't need to program "X11" with maemo SDK. I found the maemo tutorial 
rather difficult for starters (IMHO) and would recommend that you would try 
to go trough the GTK+ tutorial first (although it is quite outdated), be sure 
to use the version 2.x tutorial, not the 1.x. When you've done you're first 
menus and vboxes and things like that, you might want to look at the tutorial 
again. The tutorial assumes a great deal of things about the reader.

> I doubt and don't really know if we have installed enough...
> Do we need special flavour of GTK libs??

Follow the installation instructions. You need scratchbox and the maemo RS 
(SDK). The rootstrap contains the special flavour GTK+ libs that you'll need 
but as I said, you should really start with normal GTK+ first. It's not that 
different in maemo. The "Hildon Libs" are custom widgets for the special 
version of GTK+ that comes with the SDK.

Hope this helps

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

Re: [maemo-developers] Problems with Xnest

[Aleksandr Koltsoff]

On Thursday 16 June 2005 12:55, Aleksandr Koltsoff wrote:
> af-sb-init race-condition bug _and_ LANGUAGE-bug.
>
> please read mailing list archive and bugzilla for solutions.

My bad, only the race-condition bug.

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

Re: [maemo-developers] Problems with Xnest

[Aleksandr Koltsoff]

On Thursday 16 June 2005 12:15, Marius Vollmer wrote:
> Sorry, I botched the moderation of this message, so I am forwarding
> it.

af-sb-init race-condition bug _and_ LANGUAGE-bug.

please read mailing list archive and bugzilla for solutions.

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

Re: [maemo-developers] hildon-input-method errors when starting maemo GUI

[Aleksandr Koltsoff]

On Thursday 16 June 2005 06:06, Daniel Monteiro wrote:
> this worked almost well...but unset all the resources
> from the indt's game launcher.
> also, some other stuff appeared when clicking on the
> application installer.

Almost well working software is the best! ;-). Seriously though, since the 
maemo SDK doesn't have a pt_BR locale in it, how would you go on fixing this? 
af-sb-init.sh will cause LANGUAGE to be set to en_GB on start if LANGUAGE is 
missing, and this should fix it. Maybe indt's game launcher assumes LANGUAGE 
is pt_BR?

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

Re: [maemo-developers] Optimized software

[Aleksandr Koltsoff]

On Thursday 16 June 2005 09:42, Jose Manrique Lopez de la Fuente wrote:
> I've read a review about Nokia 770[1] saying that the device is
> something slow. Sure you have all in mind that optimized software is
> important, and I hope that release unit won't have speed issues.

I'd rather have software without difficult to debug bugs at this time thank 
you :-). Speed will come later when capable people with platform (inc GTK) 
knowledge will benchmark properly and identify the issues.

I'll present some counter-points based on my experience (nothing personal 
though):

> Some reactions to this review[2] comment about latency experience
> solutions: * Wherever possible, use multi-threading to push latency into
> the background. 

Whenever possible avoid using threads unless you know how they're implemented 
in your architecture. When you know that, you will know how to use them a) 
efficiently b) safely and know how to debug programs. Until then, don't use 
threads or ask someone else to do the threading logic for you. Threads are no 
panacea for usability problems (not even latency). GTK+ and GLib provide a 
lot of means to implement "multi-tasking" without threads.

> * Latency can often be hidden from users through 
> multi-tasking
> techniques, letting them continue with their work while transmission
> and computation take place in the background.

Yes. If your CPU has idle time. If your CPU is busy 100% of the time, this 
won't help but make it worse.

> * Reduce the user's experience of latency.

By making the device even slower? what does this mean ;-). 

> * Acknowledge all button clicks by visual or aural feedback within 50
> milliseconds.

This is good, and I noticed that in maemo the task navigator reacts to 
"button-release" instead of button-press. I don't know how much this adds to 
the latency in this particular case (I didn't mind it at least), but it does.
But don't implement the _aural_ part. 

> * Display an hourglass for any action that will take from 1/2 to 2 seconds.

Or implement some other consistant way to notify the user about operations 
that take time. It is important that this way is consistant across the 
platform, not only your program. Does maemo have anything for this?

> * Animate the hourglass so they know the system hasn't died.

I'd rather go for blinkenlichts but seeing that 770 has them missing, animated 
is ok as long as the animation itself doesn't grab too much of CPU-time. (a 
simple - / | \ - animation would be enough for me personally but knowing that 
pango is involved in displaying text, an animated clock would be probably 
faster ;-). Playing some sound with "Aie" is enough to notify the user 
that the system has died ;--) (just joking).

> * Display a message indicating the potential length of the wait for
> any action that will take longer than 2 seconds.

A 5 second limit for this target device would be much more appropriate since 
ppl tend not to notice and read within seconds.

> * Communicate the actual length through an animated progress indicator.

This is not always possible and sometimes counter-productive. Inproperly 
implemented progressbars are evil (especially ones that say that estimated 
time is 2 hours, then after a minute it's 1.5 hours, then again 3 hours). You 
know what I mean. And yes, implementing proper progressbars is hard. That's 
why one should think about what you want the user to see. Relative progress 
with respect time (this is what most people think it is when they see one), 
or phased progress with respect operations in programs (this is what 
programmers use when implementing progress bars). If you're implementing the 
latter, then do now use "Time" or "Percentage".

> * Offer engaging text messages to users informed and entertained while
> they are waiting for long processes, such as server saves, to be
> completed.

Or assume that the user is intelligent enough to be able to switch to another 
application meanwhile (xbill ;-).

> * Make the client system beep and give a large visual indication upon
> return from lengthy (>10 seconds) processes, so that users know when
> to return to using the system.

Do not make the client system beep. Never, ever. Overloading the users sensory 
system is bad enough as it is with modern "IT"-systems. Concentrate on clear 
and intuitive UI (intuitive for existing user base _and_ new users, again, 
this is actually quite difficult). You can ask some psychologist to tell you 
later whether to add sonic indication and where to add it.

> * Trap multiple clicks of the same button or object. Because the
> Internet is slow, people tend to press the same button repeatedly,
> causing things to be even slower.

Better yet, disable the button after you start processing or write your 
software so that it doesn't break in this case. This is a simple example 
where using threads without knowledge will lead to program crashes btw.

Just my 2 kopeikas worth.

ak.

Re: [maemo-developers] All the good projects are done! was: plucker viewer for 770

[Aleksandr Koltsoff]

On Tuesday 14 June 2005 19:04, Koen Kooi wrote:
> Brad Clements wrote:
> > Hey, does the 770 support OpenGL?
> not in hardware, the omap1710 only has 2d accel. I don't know how well
> mesa works with kdrive to do software rendering.

2d accel is fairly primitive and is not used according to the info I've read.

Also mesa-sw uses floating points, although there was an effort to implement 
mesa using fixed points around 2001. Scarce info available, maybe someone 
knows better but I'd bet implementing a opengl sw renderer would be major 
PITA. Also, considering the real processing power of 770, it's usability 
would be quite limited. A more balanced 3D-rasterizer could probably be done 
without too much effort, but not opengl.

a "hoping the next target device has opengl es and open vg" k.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] trying to eliminate error from hildon-input-method

[Aleksandr Koltsoff]

On Tuesday 14 June 2005 18:37, Tamás Bondár wrote:
> Can I put it this way? The hildon-input-method code is related to
> handwriting recognition which is proprietary, that's why its source code
> is missing from the repository. Am I misunderstanding it?

That is correct to my best knowledge. There are also other packages "missing" 
due to the same reason (be sure to read the mailing list archives).

> > On Tuesday 14 June 2005 17:12, Tamás Bondár wrote:
> > > I'm still having the error message below when doing 'af-sb-init.sh
> > > start':
> > >
> > > (hildon-input-method:21837): Gtk-CRITICAL **: gtk_box_pack_start:
> > > assertion `GTK_IS_WIDGET (child)' failed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] GCC port for the TI TMS320C5{4,5}x

[Aleksandr Koltsoff]

On Monday 13 June 2005 20:29, Jonathan Bastien-Filiatrault wrote:
> Hello,
> We are currently looking for experienced GCC hackers to help
> implement and complete a GCC port for the Texas Instruments TMS320C54x.
> This chip is used in the Neuros music player, as well as in the Nokia
> 770 internet tablet. 

Try the gcc-dev lists as well. However, I'd like to point out that the DSP 
core in 770 is 55x, not 54x. 55x supports 54x code in emulation mode but I 
don't know the innards of dspgateway nor 770 to be able to say whether 
switching the emulation mode on and off between DSP code is 
possible/feasible. Also, I don't know whether the 55x runs in 54x emulation 
mode by default (and only in emu). I'm sure someone can clarify this (if 
possible).

personally I'd like to see free development tools for the 55x core as it's 
used in 770, but have no time at the moment to participate in gcc-hacking.

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

Re: [maemo-developers] how we can enhance the maemo.org

[Aleksandr Koltsoff]

On Tuesday 14 June 2005 18:17, Karoliina T. Salminen wrote:
> In my opinion, forums are just great for shot-lived discussions.
> That is their purpose. E-mail lists really are not chat places however.
> Intention was not to replace e-mail list but add an additional feature,
> in other words, like the topic says "enchance maemo.org".

IRC (silc later?) is quite workable for short-lived discussions. What is the 
point of having "short-lived" discussions that go on for a long time? 
However, I'm not going to argue whether forums are good or bad in this 
respect, I have a more practical suggestion below.

> It really does not matter if it is the browser field when posting to
> a forum. I don't think the art of text editing is the reason for
> posting to a forum, if it is the matter of capabilities of the
> text editor, then the forum is really not the right choice for posting.

Usability is an issue when trying to lower the participation to a project. 
Using web broadens the scope of people who can participate (not necessarily 
accessability as evidenced by all the different-theme forums) but lowers 
useability (IMHO).

> Any more votes?
>
> a) An additional web based forum would ruin the site
> b) Indifferent, ok to add or ok to be without.
> c) It has some benefits to add a web based forum
> d) Would love to have an additional forum

e) Postpone adding a forum to avoid splintering the public "development". When 
770 goes live properly I'm sure there will be a need for non-developers to 
chat in a short-lived way. I mostly worry about splitting my time between 
clicking my mouse around in some forum and reading email and everything else.

Just my 2 kopeikas worth.

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

Re: [maemo-developers] trying to eliminate error from hildon-input-method

[Aleksandr Koltsoff]

On Tuesday 14 June 2005 18:01, Pixelnate wrote:
> So how does one set the language? I have the same problem.

> With choas comes destruction. But, with a powerful, controlling,

The pun is intended in the word choas? :-)

> >>> [... some 'Language string is NULL' warnings are here...]
> >> set your LANGUAGE=en_GB
> >> (or fi_FI if you prefer that one)
> >> not critical.

before starting AF in sbox:
export LANGUAGE=en_GB

and check bugzilla for a proper fix wrt setting the local setting so that you 
don't have to do it everytime you login into sbox.

As I mentioned before, this is not critical, neither should it be considered 
as an "error" (rather a "warning" in some cases, not yours)

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

Re: [maemo-developers] trying to eliminate error from hildon-input-method

[Aleksandr Koltsoff]

On Tuesday 14 June 2005 17:42, Aleksandr Koltsoff wrote:
> > [... some 'Language string is NULL' warnings are here...]
>
> set your LANGUAGE=en_GB
> (or fi_FI if you prefer that one)
> not critical.

"Not critical in your case" was I wanted to write since you had LANGUAGE unset 
when you ran the code. If LANGUAGE is set, and is _not_ one of en_GB or 
fi_FI, graphics will break. I think I've put this into the bugzilla (under af 
maybe, can't remember).

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

Re: [maemo-developers] trying to eliminate error from hildon-input-method

[Aleksandr Koltsoff]

On Tuesday 14 June 2005 17:12, Tamás Bondár wrote:
> I'm still having the error message below when doing 'af-sb-init.sh
> start':
>
> (hildon-input-method:21837): Gtk-CRITICAL **: gtk_box_pack_start:
> assertion `GTK_IS_WIDGET (child)' failed

Relates to the missing input-code which (I think) is linked to the handwriting 
recognition and thus is not part of maemo (it's proprietary, non (L)GPL).
not critical.

> [... some 'Language string is NULL' warnings are here...]

set your LANGUAGE=en_GB
(or fi_FI if you prefer that one)
not critical.

> ** (hildon-input-method:21837): CRITICAL **:
> hildon_im_plugin_fullscreen: assertion `HILDON_IM_IS_PLUGIN(plugin)'
> failed
I think this is related to the first one (im = input method)

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

Re: [maemo-developers] Maemo & Scratchbox 0.9.8.5

[Aleksandr Koltsoff]

On Monday 13 June 2005 08:27, [EMAIL PROTECTED] wrote:
> Just a quick question. Has the newly released sb 0.9.8.5 been tested
> with Maemo?  Or should I still stick with 0.9.8.4?

It works ok (no snags encountered yet).

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

Re: [maemo-developers] hildon-input-method errors when starting maemo GUI

[Aleksandr Koltsoff]

On Thursday 09 June 2005 18:01, Tamás Bondár wrote:
> I'm a novice here and tried to read through all the archives to fix my
> problems before posting but I'm afraid I just can't eliminate all the
> errors when starting the maemo GUI. I'm most worried about the CRITICAL
> messages below. Any idea how serious they are and how to get rid of
> them?

Try this (inside sbox):

unset LANGUAGE
export LANGUAGE
af-sb-init.sh

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

Re: 答复: [maemo-developers] maemo development on RH

[Aleksandr Koltsoff]

On Monday 06 June 2005 06:06, Avdpro Pang wrote:
> Hi
> Thanks for your advices! I found and installed
> XFree86-Xnest-4.2.0-72.i386.rpm for my RH8. Now my Xnest can start. But the
> scratchbox can't export display to it. Blow is what I do and what the
> console displays. Does anybody have some suggestions on this? BTW:
> Xlib: connection to "127.0.0.1:2.0" refused by server
> Xlib: No protocol specified

Hello Avdpro,

Your x server does not accept connections from your sbox clients. Normally 
this means that you haven't started it according to the tutorial 
instructions, namely, you need to give Xnest the "-ac" parameter.

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

Re: [maemo-developers] TI 55x free software compilers?

[Aleksandr Koltsoff]

On Monday 30 May 2005 15:41, Tuomas Inkiläinen wrote:
> These make a good pair with DSP Gateway's examples and makefiles:
> https://www-a.ti.com/downloads/sds_support/targetcontent/LinuxDspTools/inde
>x.html

Thanks :-)

Wasn't exactly the "free" kind I was looking for, but the codegen tools can be 
used with the 55x in omap1710 as well? (the package is geared towards omap5k)

I'll check this out once I'm back from my trip.

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

[maemo-developers] running af at 24-bit depth

[Aleksandr Koltsoff]

Hello

Most of you might know that running af-sb-init.sh will lead to funny screens 
when your X server is at 24bpp.

The component that provides images to applications (sapwood-server), has a 
hardcoded value in it that is set to 16. Since the process runs without a 
Gdk-context, it's not easy to detect the depth directly (I'm guessing here 
though).

I've modified the server so that the depth can be controlled via an 
environmental variable called SAPWOOD_DEPTH and if it's set to 24, then 
sapwood will use that.

After this, af runs ok on 24bpp.

I put a compiled (sbox/i386) debs, sources and a README (renamed to usage.txt 
because of ISP) with instructions here: 
http://koltsoff.fi/770/sapwood-16_24_bit/

And yes I know it's a hack, and yes I know better ways of doing this, but 
again, it's just a hack. I do not propose including that into the SDK, but 
wouldn't oppose it either.

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

[maemo-developers] TI 55x free software compilers?

[Aleksandr Koltsoff]

Does anyone know of such beasts? The compiler from TI comes with the 
Windows-IDE and cheapest version for OMAP costs about 5400$ (plus it requires 
windows, which is a no go for me).

I know that bintools support some parts of 54x, but don't know whether the 55x 
will be run in a the backwards compatible mode in 1710 (also, dspgateway docs 
aren't too verbose on any issue, so maybe someone on this list would know 
where to point).

a "offline for a week now" k.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

[maemo-developers] Various bugs & fixes for af-sb-init.sh

[Aleksandr Koltsoff]

If you see screens like this:
http://koltsoff.fi/770/snapshot1.png
http://koltsoff.fi/770/snapshot2.png

Please see Bug 58 in the bugzilla for corrections.

Have a nice day.

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

Re: [maemo-developers] Fail to bind socket for d-bus

[Aleksandr Koltsoff]

Hello Timo,

On Monday 30 May 2005 06:43, Timo Savola wrote:
> This will be fixed shortly in Scratchbox 0.9.8.5 (and in Scratchbox
> 1.0.2 some time in the future).

Is there are release date for 0.9.8.5? (tentative is ok too).

ak.
___
maemo-developers mailing list
[EMAIL PROTECTED]
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Hello world!

[Aleksandr Koltsoff]

Hello Avdpro

On Monday 30 May 2005 07:28, Avdpro Pang wrote:
> 1> Can I use Redhat Linux?
> 2> I know the API is fully C based, but I should can use C++ develop my
> games, isn't it?

The current sbox installation will go smoother if you're running debian or 
(k)ubuntu. There were some problems with gentoo at least, but I think I saw 
someone testing with FC3. Installing on debian is easier though.

As for the API, C++ includes the option of doing "legacy" function calls, so 
yes, you can do that if you wish. Note that at least in the x86-toolchain 
there is libstdc++, which is the C++ runtime. The toolchain also includes a 
version of gcc that does C++, so basically you should be set. If you decide 
to go this way, be careful about mixing C++ object allocation with the 
GLib-model of object creation/destruction/ref counting.

There are also C++ wrappers for GTK+ (gtkmm), but they're not included in the 
SDK and I doubt that they would be present on the 770 (other ppl might know 
better). You can of course build gtkmm inside sbox and use it as you will.

Maybe there are people on the mailinglist that have used gtkmm on maemo 
already and they can help? I've not seen or heard them yet :-).

ak. 
___
maemo-developers mailing list
[EMAIL PROTECTED]
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] 800x480

[Aleksandr Koltsoff]

On Saturday 28 May 2005 22:46, Asko Kauppi wrote:
> Ability to swap horizontal/vertical (at least in full screen mode)
> would be an almost must-have for this device.  I know SDL could do
> it, at some level, but there are issues s.a. blitting images on the
> screen that might be more elaborate.
>
> Has there been discussion/plans upon this?  Best of all: ability to
> sensor current physical orientation, and adopt instantaniously.

Hello ak :-),

At least I know that the AF get's a bit flaky if its screen resolution is 
anything else than 800x480 (like 480x800). So I think (note I haven't seen 
770 myself) that providing Xrandr would be limited (currently) to fullscreen 
applications that could use it, but the application should switch back to the 
"natural" orientation on exit. I don't know whether the AF will be fixed to 
handle that situation. Although screen space will be quite limited for 
usability in the other orientation as it is. Also the on-screen keyboard 
might get somewhat confused, as well as the hand-writing recognition.

As for SDL, it's pretty simple since it can fake the screen orientation. The 
problem will be with a rotational transform when "blitting" (the 770 doesn't 
have a graphics processor). So this would make sw based blitting quite slow 
as for each copied rect area, the access pattern would be left->right 
(top->bottom) instead of the normal top->bottom (left->right) and I would 
imagine that the memory bus is not optimized to handle wide strides like 
this. This might be how X does Xrandr as well, but it has the advantage of 
having Xrender (on some platforms) which can do the rotation in hardware so 
in those cases it's not an issue.

Please correct me if I'm wrong, I haven't read Kdrive/Xrandr-sources.

ak.
___
maemo-developers mailing list
[EMAIL PROTECTED]
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Re: Tutorial: Maemo_Dev_Platform_RS_v1.0.tgz and sapwood-server

[Aleksandr Koltsoff]

On Sunday 29 May 2005 19:09, Olivier Bornet wrote:
> It will be great to be able to use maemo with a depth of 24, even if it
> runs at 16. Can we do this ?
>

Hello Olivier,

inside sbox:
fakeroot apt-get install xserver-xephyr
(there seems to be some part inside the package that requires "root")

then start it with Xephyr -screen 800x480x16 -ac :2

This _should_ work, but at least for me it didn't :-). X ephyr is a Kdrive 
based X server that supports the modern X extensions and acts as a client to 
existing X server (similar to Xnest in this respect). It can provide a 16bpp 
screen to it's clients while it will use 24bpp itself (in your case).

Anyhow, also check the bugzilla, I remember seeing smt about this there.

As for your question, maemo cannot currently run at 16bpp as there seem to be 
some hard fixed assumptions. OTOH, the target device (770) is 16-bit, so 
there might not be much sense other than testing your application reliability 
against env changes.

ak.
___
maemo-developers mailing list
[EMAIL PROTECTED]
https://maemo.org/mailman/listinfo/maemo-developers