RE: [maemo-developers] Maemo Alarm/Notifier Interface
On Wed, 2006-01-11 at 11:35 -0800, ext Jason Mills wrote: A few items: 0) The RTC subsystem is served off a chip known as Retu. Most of the ASICs on the Nokia 770 board seem to have nice nordic names to them. :-) 1) The RTC subsystem only supports one future alarm event, and that event may not be more than 24h59m from now. Maximum alarm granularity is +/-1 minute or so. 23h59m if memory serves me well Only Retu can wake up the device from poweroff state at a preset time; unfortunately this is the time resolution that it canprovide. In order to extend alarms and events scheduling one could have the daemon scheduling periodic wakeups (every 24h) till the real alarm is closer than 24h. The granularity problem could be overcome using either a sw timer or an internal HW timer, with better resolution than 1m. It would be programmed by the daemon, after the last wakeup and before reaching the scheduled time for the event. 2) The actual definition of now is a bit arbitrary, because of how the RTC synchronization works. 3) There is a functional, albeit spartan CLI utility already available to talk to the RTC subsystem, -and- to set/check the alarm. /mnt/initfs/usr/bin/retutime 4) The osso_alarm and osso_notifier daemons are missing at least from the 2005.51 Nokia build. No bug is currently filed against this, and I haven't had a chance to file one yet. I think, though am not 100% sure, that these two daemons are required in order to fetch the actual alarm signal from the RTC subsystem. -JMills ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On Wed, 2006-01-11 at 20:20, ext Simon Budig wrote: Kimmo Hämäläinen ([EMAIL PROTECTED]) wrote: We have also other places where multiple simultaneous programs would screw things. Usually this can be avoided by the fact that the user can only use one application at a time. Oh right. Our System is broken anyway, so lets add more broken stuff. Sorry, this is *not* good software engineering. In general, no; but sometimes it's good to think before overengineering stuff... On Wed, 2006-01-11 at 18:50, ext Simon Budig wrote: The crontab(1) command cannot add an entry to the crontab, all it can do is pop up $EDITOR for the user to edit the crontab. Not what you want. My man page (old debian/testing) says that it can: The first form of this command is used to install a new crontab from some named file or standard input... Right, I missed that. It doesn't really help, since it installs - as far as I understand the manpage - a *new* crontab, discarding old entries. We can avoid this with some nice wrapper. Note that we can use separate, named crontabs for each alarm. Glib also is not always a good idea: It can handle timeouts but does not make any guarantees about them. Plus - as florian already mentioned - it would require your program to run all the time and waste memory. I think the user does not except atom clock precision anyway. Cron would allow the application to be launched closer to the set alarm, so the running time of the application could be minimised. Well, OTOH I don't think that differences = 1s are acceptable. If we launch an application to just play the sound we very well are in this range of prescision. We will try to re-use existing (preferably standard) software, so unless cron is not enough, it will be preferred over some new daemon implemented from scratch. I'd love to have an API call that enqueues an alarm at a specific time (maybe even with a specific sound, but I doubt that it should provide any dialog facilities, that would make it quite complex) that calls back into the application via dbus. That would make it possible to disable alarms globally (similiar to the flight mode - a cinema mode :) and would enable a list of scheduled alarms, regardless of the application that scheduled it. You can use DBus from a crontab if you want (e.g. with dbus-send). Also, stopping and restarting cron is possible. The question IMHO is not what I *can* but what I *want*. Of course I can implement applications write()ing the X-protocol to a socket of the system, that hopefully results in a window presented by the X-Server, but that does not mean that it is clever or feasible. Libraries exist for a reason. You'd have to hack a lot around crontab to enable all this and I doubt that would be significantly less error prone than implementing that stuff e.g. in the Desktop application or a new demon specific to that task. What was so difficult with cron? Ok, let me try some pseudo code to add an crontab entry for an alarm from within an application written in C. minutestring = g_strdup_printf (%d, minute); hourstring = g_strdup_printf (%d, hour); addcommand = g_strdup_printf ((crontab -l ; echo \%s %s %s %s %s %s\) | crontab -, minutestring, hourstring, *, *, *, commandstring); system (addcommand); g_free (addcommand); g_free (minutestring); g_free (hourstring); We can avoid this with some wrapper, I think. Removing an entry from the crontab would require more advanced trickery with sed to remove the entry from the crontab -l listing. Beware to not remove an entry by another application! And make sure to get the quoting for your shell commands exactly right. How do you quote spaces in an argument to dbus-send when invoking the above command? Of course some of this complexity could be hidden by custom shell scripts. You'll always have the quoting issues though. Getting a list of the currently scheduled alarms needs another mechanism, according to your approach it would probably mean implementing a parser to get the information from the output of a shell script. Now. Someone not too familiar with shell programming wants to use this and it does not work. What do you tell him? Now compare this to this: osso_time_schedule_alarm (context, alarm_time, OSSO_ANNOYING_SOUND, my_custom_callback_function); (or whatever, I did not think very deeply about the arguments). It would be typesafe, incredibly easy to use and if it doesn't work the blame is on Maemo. Great for application developers :) I think we'll just have a wrapper for crontabs. The function above looks
Re: [maemo-developers] Maemo Alarm/Notifier Interface
Great this is feedback I was looking for. Now just to bring on same page again First the end user use cases 1. An application e.g Calender or task wanting to alart and notify the user of scheduled events. This notification should have a certain accepted granularity and delivery promise - Resolution of most end user use case can live with 1 minutes granularity [IMHO] - Events must be delivered regardless of the device state e.g sleep, deep sleep or poweroff state [but with battery plugged in] - User should be able to schedule Events/Notification in any future time e.g my mothers birthday which is 8 months away. Every other use case is more secondary use case 2. User is able to work on all scheduled events from one common point UI (e.g as simon pointed, in a cinema, want to silent all alarms, cancel or enable alarms). - You can argue that switching off the device speaker would result the same, though you might have the nuisance of screen turn ons. - The ability to cancel/enable alarm might make things complicated for application developers, as then events not delivered to the registered apps, somebody need to tell them that the alarm was either cancelled or rescheduled, so they can reach a sync state. From a Developer Perspective 1. There should be a easy to use API enabling/disabling and notification of scheduled events. 2. Alarm/Notifier sub system should have the capability to delivery events to applications, even in case the application is not running [e.g starting the app with a specific startup reason code, so that the whole app window need not be started e.g in case of calendar, only a dialog pops up saying event due ... with option like open event (causing all app window to come), reschedule/snooze, cancel 3. It would also be useful that the implemented solution is also available/complaint/builds upon other solutioins like that mentioned about hh.org and iPAQs 4. IN case of reshedule, or cancel, only the app which scheduled it, is able to do that [some kind of inbuild security] What I have learnt on this discussion thread First the hardware - On n770 RTC is the provided by retu, which has a granularity of 1 minutes and can only handle 1 event at a time and that too for only between now and 23:59 - I am assuming that it is capable of waking up the hardware, even if it is powered off [but with a alive and kicking battery] About the implementation (As a application developer I would not care about the real implementation, till I can get a simple to use API interface enabling basic use cases :) but from Maemo perspective, it is benificial that the Maemo development Platform get a sane design. - some kind of D-BUS to auto activate and deliver events - some kind of library to abstract the inner working of the implementation [good also from point of view of application portability], could be extension to lib_osso or another brand new lib_alarm or whatever. This should also enable simultaneous concurrent use. - some kind of UI , maybe a control panel applet to work with all alarms/events scheduled. Now that depends if it is free for all to know about all events scheduled by other apps [not so nice from security point of view, so if security of this time is important then to drop this completely] - some sort of a daemon to provide software intelligence to make up for hardware constrains. - existing open source components should not be changed e.g reduces maintainence overhead (proposals being crond, atd) I think it would be good idea to have a wiki page? My objective is quite achieved that there is community participation, and people inside nokia need to look into what the community had wanted and what was delivered :) even when I know product schedules and requirements are highest priority [read as , you wont get always what you wanted ;)]. cheers Devesh ext Igor Stoppa wrote: On Wed, 2006-01-11 at 11:35 -0800, ext Jason Mills wrote: A few items: 0) The RTC subsystem is served off a chip known as Retu. Most of the ASICs on the Nokia 770 board seem to have nice nordic names to them. :-) 1) The RTC subsystem only supports one future alarm event, and that event may not be more than 24h59m from now. Maximum alarm granularity is +/-1 minute or so. 23h59m if memory serves me well Only Retu can wake up the device from poweroff state at a preset time; unfortunately this is the time resolution that it canprovide. In order to extend alarms and events scheduling one could have the daemon scheduling periodic wakeups (every 24h) till the real alarm is closer than 24h. The granularity problem could be overcome using either a sw timer or an internal HW timer, with better resolution than 1m. It would be programmed by the daemon, after the last wakeup and before reaching the scheduled time for the event. 2) The actual definition of now is a bit arbitrary, because of how the RTC synchronization works. 3) There is a functional, albeit spartan CLI utility already
Re: [maemo-developers] GPE PIM applications for Maemo progress
2006/1/11, Florian Boor [EMAIL PROTECTED]: Hi all, we just updated binary packages and sources for the Maemo port of the GPE PIM applications. Binary packages and sources are available from http://oss.kernelconcepts.de. All sources can be found in GPE CVS at handhelds.org too. If you are interested what is going on check out http://handhelds.org:8080/gpe/timeline. The next steps will be support for alarms and syncing... Greetings Florian First of all, many thanks for your efforts in porting these fundamental applications in 770! I'm trying your 4 updated packages, and all is well; nice improvement! I have noted only a freeze trying to set an alarm for a new event in the calendar app. The freeze happens clicking on the save button after enabilng the alarm, the only way to exit is kill the app from xterm (killall gpe-calendar). Probably exiting in such a way disrupts the /home/user/.gpe/calendar file, because deleting this file was the only way to make me able to start the application another time. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On Thu, 2006-01-12 at 10:55 +0200, Devesh Kothari wrote: Great this is feedback I was looking for. Now just to bring on same page again First the end user use cases 1. An application e.g Calender or task wanting to alart and notify the user of scheduled events. This notification should have a certain accepted granularity and delivery promise - Resolution of most end user use case can live with 1 minutes granularity [IMHO] - Events must be delivered regardless of the device state e.g sleep, deep sleep or poweroff state [but with battery plugged in] - User should be able to schedule Events/Notification in any future time e.g my mothers birthday which is 8 months away. Base assumptions: -since the Retu rtc has a minimum resolution of 1s, that's our minimum error: +/- 1s -only whole days are subtracted from the Retu days counter, so that no skew is introduced in the timeline by silent resets of the seconds counter Then the time daemon would schedule the wakeup from poweroff early enough (i.e. 1 minute earlier) and then deliver the alarm to the user, with an almost arbitrary high time resolution, because it would use a fine-grained timer synchronised with Retu rtc. There is a problem, though: I'm omitting time skews, but in order to program the alarm in i.e. 8 months and 6s a calibration of the Retu rtc is required and it would need support from the DSP for measuring the deviation over time. However this seems unlikely to be needed. Every other use case is more secondary use case 2. User is able to work on all scheduled events from one common point UI (e.g as simon pointed, in a cinema, want to silent all alarms, cancel or enable alarms). - You can argue that switching off the device speaker would result the same, though you might have the nuisance of screen turn ons. - The ability to cancel/enable alarm might make things complicated for application developers, as then events not delivered to the registered apps, somebody need to tell them that the alarm was either cancelled or rescheduled, so they can reach a sync state. The device can run out of power and the alarm not being delivered, so applications have to be able to cope with missing an alarm notification. And any form of polling or busy looping is not an option. From a Developer Perspective 1. There should be a easy to use API enabling/disabling and notification of scheduled events. 2. Alarm/Notifier sub system should have the capability to delivery events to applications, even in case the application is not running [e.g starting the app with a specific startup reason code, so that the whole app window need not be started e.g in case of calendar, only a dialog pops up saying event due ... with option like open event (causing all app window to come), reschedule/snooze, cancel This should also take into account the loading time for the application and whatever it might need. 3. It would also be useful that the implemented solution is also available/complaint/builds upon other solutioins like that mentioned about hh.org and iPAQs That's using a HW timer and we already do the same. On the 770 the Omap RTC is not capable of waking up the device from power off, so it is out of scope for a 770 specific discussion. 4. IN case of reshedule, or cancel, only the app which scheduled it, is able to do that [some kind of inbuild security] If a common UI is presented to the user that shouuld also provide a single entry point for events-management. What I have learnt on this discussion thread First the hardware - On n770 RTC is the provided by retu, which has a granularity of 1 minutes and can only handle 1 event at a time and that too for only between now and 23:59 - I am assuming that it is capable of waking up the hardware, even if it is powered off [but with a alive and kicking battery] About the implementation (As a application developer I would not care about the real implementation, till I can get a simple to use API interface enabling basic use cases :) but from Maemo perspective, it is benificial that the Maemo development Platform get a sane design. - some kind of D-BUS to auto activate and deliver events - some kind of library to abstract the inner working of the implementation [good also from point of view of application portability], could be extension to lib_osso or another brand new lib_alarm or whatever. This should also enable simultaneous concurrent use. - some kind of UI , maybe a control panel applet to work with all alarms/events scheduled. Now that depends if it is free for all to know about all events scheduled by other apps [not so nice from security point of view, so if security of this time is important then to drop this completely] - some sort of a daemon to provide software intelligence to make up for hardware constrains. - existing open source components should not be changed e.g reduces maintainence overhead (proposals being crond, atd)
Re: [maemo-developers] Perl on the Nokia 770
check the repository.maemo.org http://repository.maemo.org/pool/maemo1.1rc7/free/p/perl/ you should be able to get it using apt-get on developer rootfs atleast. Best Regard Devesh Package: perl Priority: standard Section: perl Installed-Size: 10560 Maintainer: Brendan O'Dea [EMAIL PROTECTED] Architecture: arm Version: 5.8.3-3osso1 Replaces: perl-5.005 ( 6), perl-5.6 ( 6), perl-doc ( 5.8.0-1), perl-modules ( 5.8.1-1), libdigest-md5-perl, libmime-base64-perl, libtime-hires-perl, libstorable-perl Provides: perl5, libdigest-md5-perl, libmime-base64-perl, libtime-hires-perl, libstorable-perl Depends: perl-base (= 5.8.3-3osso1), perl-modules (= 5.8.3-3osso1), libc6 (= 2.3.2.ds1-4), libdb4.0, libgcc1 (= 1:3.3.3-1), libgdbm3 Suggests: perl-doc, libterm-readline-perl-perl Conflicts: perl-5.004 ( 6), perl-5.005 ( 6), perl-5.6 ( 6), perl-doc ( 5.8.3-1), libdigest-md5-perl ( 2.33-1), libmime-base64-perl ( 2.21-1), libtime-hires-perl ( 1.52-1), libstorable-perl ( 2.08-1) Filename: pool//maemo1.1rc7/free/p/perl/perl_5.8.3-3osso1_arm.deb Size: 3133154 MD5sum: fe2ea3adebf5504026eaa719458c466c Description: Larry Wall's Practical Extraction and Report Language. An interpreted scripting language, known among some as Unix's Swiss Army Chainsaw. . Perl is optimised for scanning arbitrary text files and system administration. It has built-in extended regular expression matching and replacement, a data-flow mechanism to improve security with setuid scripts and is extensible via modules that can interface to C libraries. ext Xavier Calbet wrote: I was willing to run perl on the Nokia 770, in fact my objective is to run PDL (pdl.perl.org) on it, if the hardware permits. The reason for this is that it would turn the Nokia770 into a powerful caculator, numerical computation machine. I was going to compile perl on the maemo platform when I just noticed that it is already installed in scratchbox. I am new to maemo and I am still a bit confused on how to use it. Would it be possible to transfer in some way the perl executables in scratchbox to the Nokia770, preferably, of course, inside a deb package? Any suggestions welcome. Xavier Calbet __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com ___ 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] GPE PIM applications for Maemo progress
Cool update!! Perhaps some developers could join bedoi effort to have a maemo-desktop-plugin to show the appointments and todo summary, or just port gpe-summary as a maemo-desktop-plugin, instead of the clock that shows maemo. I will update Spanish localization soon. Thanks and best regards, 2006/1/11, Florian Boor [EMAIL PROTECTED]: Hi all, we just updated binary packages and sources for the Maemo port of the GPE PIM applications. Binary packages and sources are available from http://oss.kernelconcepts.de. All sources can be found in GPE CVS at handhelds.org too. If you are interested what is going on check out http://handhelds.org:8080/gpe/timeline. The next steps will be support for alarms and syncing... Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- J. Manrique López de la Fuente http://www.jsmanrique.net msn: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problem with building application (tutorial document).
ext Erik Bågfors wrote: 2006/1/4, Edlinoor Syahril Ramlan [EMAIL PROTECTED]: Hi, I really do not understand some of the steps written in chapter 4 section 4.2 in the tutorial document. In item 2 of the section it is mentioned that I need to copy the maemopad_1.4.tar.gz to my home directory inside Scratchbox, and uncompress it. The thing that I do not understand is: 1) Where is the user directory in Scratchbox. Is it in: /scratchbox/users/edlinoor/targets/SDK_PC/home/user? by the way edlinoor is the username that is used for scratchbox. I tried to copy the maemopad_1.4.tar.gz into that directory but when I do: [sbox-SDK_PC: ~] ls I get MyDocs but no maemopad_1.4.tar.gz. /scratchbox/users/$USER/home/$USER /Erik ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers or what i typically do is to copy to /tmp [it is shared between SB and the host system], loging into SB and just pick from /tmp like tar -zxvf /tmp/xxx.tgz Devesh ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Missing control panel
Hi, I tried the rc7 upgrade, but it did not help,.. the control panel is still missing. also the 1200_Control_Panel.desktop does exist /etc/others-menu/ - Matti At 11:08 11.1.2006, you wrote: Hi, please upgrade to 1.1rc7, as the localization issue(s) were an unfortunate problem in 1.1rc5. Instructions how to do this can be found here: http://maemo.org/maemowiki/HowTo_DistUpgrade Regards, - Pete - -Original Message- From: [EMAIL PROTECTED] on behalf of Matti Reijonen Sent: Tue 1/10/2006 3:09 PM To: maemo-developers@maemo.org Subject: [maemo-developers] Missing control panel Hello, I installed Maemo 1.1RC5 a while ago, then I noticed the odd application names control panel and application installer names were copa_ap_cp_name and ai_ap_applicatio... found the sollution into that from these mailing lists and run unset LC_ALL Now the names are fine, except that the whole control panel is missing and with that the application installer too.. I can only see the X-Terminal in applications list. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Using osso-browser-interface
ext maukka maukkanen wrote:
Hi
Anyone having experience in using osso-browser interface? I've spent
some time trying to launch browser in embedded mode from hildonapp but
all I'm able to launch is Web loading notification and then nothing.
See the code snipplet below:
osso_return_t ret;
hildon_app_set_appview ( data-app, data-browser_view );
hildon_app_notify_view_changed( data-app, data-browser_view );
ret =osso_rpc_run_with_defaults(data-osso,
osso_browser,plug_new_window, NULL,
DBUS_TYPE_UINT32,
hildon_app_find_view_id(data-app,data-browser_view),
DBUS_TYPE_STRING, file://localhost/media/mmc1/test_page.html,
DBUS_TYPE_STRING, NULL,
DBUS_TYPE_BOOLEAN, TRUE,
DBUS_TYPE_BOOLEAN, FALSE,
DBUS_TYPE_STRING,
com.nokia.osso_browser,
DBUS_TYPE_INVALID);
if (ret != OSSO_OK) {
gtk_infoprint(GTK_WINDOW(data-app), Browser launch failed);
}
--
Something is going therribly wrong but I have no idea whatsoever about
the error:( I'd also be interested in knowing if videoplayer has
similar interface available.
Thanx,
-mp
_
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
I am not so sure about the URL I always get confused by the number of
slashes etc maybe that is something you can try playing with ;)
Devesh
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] GPE PIM applications for Maemo progress
Hi, I did not install the new versions yet, but I will. I just like to say, that the N770 would be mostly useless for me without decent PIM applications. Nokia should consider integrating the GPE PIM things, so that people could use the GPE PIM contacts in the Nokia mail application etc. Thanks for GPE PIM, it's really nice and I like it definetely better than the PIM stuff on my Zaurus 5500. Cheers, WB ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Using osso-browser-interface
From: Devesh Kothari [EMAIL PROTECTED]
To: ext maukka maukkanen [EMAIL PROTECTED]
CC: maemo-developers@maemo.org
Subject: Re: [maemo-developers] Using osso-browser-interface
Date: Thu, 12 Jan 2006 12:29:30 +0200
ext maukka maukkanen wrote:
Hi
Anyone having experience in using osso-browser interface? I've spent
some time trying to launch browser in embedded mode from hildonapp but
all I'm able to launch is Web loading notification and then nothing.
See the code snipplet below:
osso_return_t ret;
hildon_app_set_appview ( data-app, data-browser_view );
hildon_app_notify_view_changed( data-app, data-browser_view );
ret =osso_rpc_run_with_defaults(data-osso,
osso_browser,plug_new_window, NULL,
DBUS_TYPE_UINT32,
hildon_app_find_view_id(data-app,data-browser_view),
DBUS_TYPE_STRING,
file://localhost/media/mmc1/test_page.html,
DBUS_TYPE_STRING, NULL,
DBUS_TYPE_BOOLEAN, TRUE,
DBUS_TYPE_BOOLEAN, FALSE,
DBUS_TYPE_STRING,
com.nokia.osso_browser,
DBUS_TYPE_INVALID);
if (ret != OSSO_OK) {
gtk_infoprint(GTK_WINDOW(data-app), Browser launch failed);
}
--
Something is going therribly wrong but I have no idea whatsoever about
the error:( I'd also be interested in knowing if videoplayer has
similar interface available.
Thanx,
-mp
_
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
I am not so sure about the URL I always get confused by the number of
slashes etc maybe that is something you can try playing with ;)
Devesh
Thanks for the answer! Yep, the url can be wrong but I've tried with
the url /media/mmc1/test_page.html too which works fine when
launching normal browser window through interface. I'm starting to
wonder if that embedded part is working at all... Well maybe it works
but I just don't know how to use it:(
I recently read that somebody was asking almost the same thing on
this list. Practically the only parameter that can go wrong is window_id.
I currently pass the HildonAppView id as window_id but should i pass
the HildonApp's GtkWindow id instead? And if so how to do this in
practise?
Br,
mp
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Building Maemo from scratch
ext Florian Boor wrote: Helo, Russell Geldmacher wrote: So, as I'd assume, there are package-specific patches for Maemo? These apply to the pristine tarballs I'm guessing? Where can one get these patches? (Is that a dumb question showing I know nothing about OE?) well... you have two sorts of patches: The maemo source packages are Debian-style sources which sometimes contain patches to be applied before building the source. In addition you sometimes need patches to apply additional fixes to build the sources with OE. These patches are managed in OE, but so far OE doesn't have a mechanism to handle the patches included in the source package. Of course you can extract these patches and add them to OE manually, but it makes maintainance of it much more complicated. Greetings Florian Wouldnt it be just easier to do it the debian way inside SB. 1. get the list of packages right so the dependencies are met. 2. If you need to modify or add some components then have them available in a different local repo [building, packaging and resolving their dependencies is a step that should be done seperately, possibly in another SB maemo rootstrap] 3. for nokia 770 add the magic packages from nokia binary distribution and you have your new rootfs for nokia 770. For other devices, to use maemo, you would have to provide device specific stuff. Or even better to get the reverse dependencies on what packages depend on packages provided by nokia, and approximate what in functionality they would mean for the different device, and have packages (dummy or providing similar functionality but for your device like device state management, battery management, input methods and VKB etc) Then comes the desktop part etc, which is hildon, remove all af-desktop related components from your build as hildon is quite n770 800x480 resolution tied. See what could be used from e.g GPE etc package them as debian [that could be quite a work] Also lot of device startup procedure would have to be streamlined would be quite lot of work but IMHO doable :) Just IN MY PERSONAL OPINION, it would great to see option of 2 toolkits (GPE , Hildon), a core base maemo platform + adaptation layers , and device specific layer, and common set of development tools and environment [SB etc, with different toolkits etc] Devesh ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Gazpacho/hildon - added extra properties
ext Florian Boor wrote: Hi, Luc Pionchon wrote: I committed a few more properties for hildon widgets. This should complete Gazpacho support, and help for bindings. this sounds promising. It might be very useful to include Gazpacho in the SDK. If this is easy to achieve maybe in the next release? :-) Greetings Florian yes Gazpacho would soon be there. It has to wait because (as far as i understand), the widget changes done to support gazpacho would make into the product only in next IT 2006 SW edition release. So hopefully in Maemo 1.3 release [no dates planned yet :)] Devesh ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Audio enabled dev-platform?
ext Christian Fredrik Kalager Schaller wrote: Hi would it be possible for Nokia to release a version of Maemo_Dev_Platform_rootfs_v1.1rc5.jffs2 or newer which contains the audio stuff? Not having any way to output audio with the current dev image makes it useless for me, and having to install the normal image and get root, xterm and ssh working on it is a tad painfull for something which I do relativly frequent. Christian ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers improving multimedia support is one of priority area. I hope we are able to push that out. Just to let you know we are working on it :) AFAIK it is mostly issues related to redistribution of the DSP side stuff (even in binary) which would enable the layer below DSPGateway. Devesh ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
DSP vs CPU for multimedia, Re: [maemo-developers] Audio enabled dev-platform?
BTW, did you think about using main CPU for decoding multimedia too? I was a bit shocked when playing the Ice Age trailer and saw in load plugin that main CPU is completely idle and both video and audio is decoded by DSP. I have no benchmarks or practical experience so far but from the documentation about C55x and ARM926TEJ it looks like the main cpu with edsp instructions could do similar work in similar speed as DSP does. If multimedia jobs could be distributed across both cpus (like dsp doing audio and color conversion into framebuffer, mpu decoding video) we could see higher resolution or frame rates. Is the gstreamer framework able to support more implementations for same codec (DSP vs CPU) and chose one based on priority? Will the stuff you are talking about releasing in future be enough for hacking in this area? Frantisek Devesh Kothari wrote: improving multimedia support is one of priority area. I hope we are able to push that out. Just to let you know we are working on it :) AFAIK it is mostly issues related to redistribution of the DSP side stuff (even in binary) which would enable the layer below DSPGateway. Devesh ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: DSP vs CPU for multimedia,Re: [maemo-developers] Audio enabled dev-platform?
ext Frantisek Dufka wrote: BTW, did you think about using main CPU for decoding multimedia too? I was a bit shocked when playing the Ice Age trailer and saw in load plugin that main CPU is completely idle and both video and audio is decoded by DSP. I have no benchmarks or practical experience so far but from the documentation about C55x and ARM926TEJ it looks like the main cpu with edsp instructions could do similar work in similar speed as DSP does. If multimedia jobs could be distributed across both cpus (like dsp doing audio and color conversion into framebuffer, mpu decoding video) we could see higher resolution or frame rates. I am not an expert in this area, but if I understand correctly the way it is architected is that n770 has gstreamer dsp sinks for different formats like mp3 etc which work using DSP gateway with their counterpart on the DSP. DSP controls all the audio rendering hardware. But I think it should still be possible to construct a gstreamer pipeline which would for example do ogg decoding on arm side and feed to the DSP PCM sink or something. But I am just reasonably guessing :) Is the gstreamer framework able to support more implementations for same codec (DSP vs CPU) and chose one based on priority? Will the stuff you are talking about releasing in future be enough for hacking in this area? You can hack I guess even today, but you would have to try it on the real product. You cant try it on the developer rootfs, which gives you a lot many other tools too, which ease development and hacking. check http://repository.maemo.org/pool/maemo1.1rc7/free/source/g/gstreamer0.8-osso/ Devesh Frantisek Devesh Kothari wrote: improving multimedia support is one of priority area. I hope we are able to push that out. Just to let you know we are working on it :) AFAIK it is mostly issues related to redistribution of the DSP side stuff (even in binary) which would enable the layer below DSPGateway. Devesh ___ 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] Maemo Alarm/Notifier Interface
Hello, Igor Stoppa wrote: Only Retu can wake up the device from poweroff state at a preset time; unfortunately this is the time resolution that it canprovide. In order to extend alarms and events scheduling one could have the daemon scheduling periodic wakeups (every 24h) till the real alarm is closer than 24h. i'm not that familiar with the power states of the 770. Does it actually reach poweroff during normal use without turning it off with the power switch? The granularity problem could be overcome using either a sw timer or an internal HW timer, with better resolution than 1m. It would be programmed by the daemon, after the last wakeup and before reaching the scheduled time for the event. As long as there is such a timer which can be used that would be fine. Sounds a little bit similar to what we do on the iPAQ. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Using osso-browser-interface
On 1/12/06, mp s [EMAIL PROTECTED] wrote: osso_return_t ret; hildon_app_set_appview ( data-app, data-browser_view ); hildon_app_notify_view_changed( data-app, data-browser_view ); ret =osso_rpc_run_with_defaults(data-osso, osso_browser,plug_new_window, NULL, DBUS_TYPE_UINT32, hildon_app_find_view_id(data-app,data-browser_view), DBUS_TYPE_STRING, file://localhost/media/mmc1/test_page.html, Usually there is a third slash in file ulrs, file:///foo/bar, although seems like most stuff tolerate less on my desktop... -- 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: DSP vs CPU for multimedia, Re: [maemo-developers] Audio enabled dev-platform?
On Thu, Jan 12, 2006 at 04:42:38PM +0200, Devesh Kothari wrote: But I think it should still be possible to construct a gstreamer pipeline which would for example do ogg decoding on arm side and feed to the DSP PCM sink or something. But I am just reasonably guessing :) This is my understanding as well. If the DSP is configured to control the audio hardware, it's easier to have it handle at least pcm playback, but one can make a sink plugin that takes data at just about any stage of decompression and handles the rest on the dsp. I imagine it's also possible to write plugins that only offload some of their processing to the dsp and do the rest on the arm. You can hack I guess even today, but you would have to try it on the real product. You cant try it on the developer rootfs, which gives you a lot many other tools too, which ease development and hacking. FWIW, I tried this a few weeks ago, trying to build a vorbis plugin against both upstream gstreamer-0.8 and the version in the maemo repository, but I couldn't get gstreamer to recognize the new plugin. If anyone gets this working, please let me know! -r ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: DSP vs CPU for multimedia, Re: [maemo-developers] Audio enabled dev-platform?
Ralph Giles wrote: FWIW, I tried this a few weeks ago, trying to build a vorbis plugin against both upstream gstreamer-0.8 and the version in the maemo repository, but I couldn't get gstreamer to recognize the new plugin. If anyone gets this working, please let me know! -r Same for me. I tried the gstreamer-alsa plugin from debian sarge, but gst-register hasn't shown anything useful and gst-inspect says alsasink/alsasrc is unknown. There must be some special don't use plugins from the rest of the world mechanism in libgstreamer-osso, because after I have overwritten libgstreamer-osso with libgstreamer from debian sarge, as also described here [1], the plugins will be recognized. [1] http://maemo.org/maemowiki/EnablingGstreamerSupport Cheers, Timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Using osso-browser-interface
mp s kirjoitti 12.1.2006 kello 13.39: I recently read that somebody was asking almost the same thing on this list. Practically the only parameter that can go wrong is window_id. I currently pass the HildonAppView id as window_id but should i pass the HildonApp's GtkWindow id instead? And if so how to do this in practise? Hi, I think you need to create a GtkSocket[1] and pass its id (gtk_socket_get_id ()) to browser. You can then pack the socket into the AppView as any other widget. BR, Lassi [1] http://developer.gnome.org/doc/API/2.0/gtk/GtkSocket.html ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] GPE PIM applications for Maemo progress
Hello, First of all, many thanks for your efforts in porting these fundamental applications in 770! yw :-) I have noted only a freeze trying to set an alarm for a new event in the calendar app. Thats a bad bug, indeed... i was able to reproduce this. It might be related to the missing support for alerts on this platform. The freeze happens clicking on the save button after enabilng the alarm, the only way to exit is kill the app from xterm (killall gpe-calendar). Probably exiting in such a way disrupts the /home/user/.gpe/calendar file, because deleting this file was the only way to make me able to start the application another time. Damaging the database is really complicated. I suppose reading this event or checking its scheduling status causes it to freeze right on start. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
Hello, That's using a HW timer and we already do the same. On the 770 the Omap RTC is not capable of waking up the device from power off, so it is out of scope for a 770 specific discussion. waking up the device from power off would take some time anyway. So it might be necessary to deal with power off in two steps: One raw timer waking up the device early enough to ensure some other instance (like the RTC) is able to care about the event while the device is running. Not that nice, but maybe the only way to deal with this. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] GPE PIM applications for Maemo progress
Hi, W. Borgert wrote: I just like to say, that the N770 would be mostly useless for me without decent PIM applications. Nokia should consider integrating the GPE PIM things, so that people could use the GPE PIM contacts in the Nokia mail application etc. this would be pretty easy. The contacts databse code is split from the application to a separate library. It is really simple but should be more than enought to fit the needs of the mail application. In fact it looks like the whole gpe-contacts is smaller than the code in osso-mail to store contacts ;-) Thanks for GPE PIM, it's really nice and I like it definetely better than the PIM stuff on my Zaurus 5500. yw :-) Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Audio enabled dev-platform?
Not having any way to output audio with the current dev image makes it useless for me, and having to install the normal image and get root, xterm and ssh working on it is a tad painfull for something which I do relativly frequent. ... improving multimedia support is one of priority area. I hope we are able to push that out. Just to let you know we are working on it :) AFAIK it is mostly issues related to redistribution of the DSP side stuff (even in binary) which would enable the layer below DSPGateway. In the meantime, the pain of getting getting the production image up and running can be reduced (not eliminated) by scripting your application install list. The Syncing Apple has a post demonstrating (see the comments for how to sudo the app-installer-tool properly): http://www.dillernet.com/apple/2006/01/01/recovering-from-a-firmware-flash/ You'll still need to install xterm and flash to RD mode manually, but the script can do quite a bit after that. Mike ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Fwd: [maemo-developers] Maemo Alarm/Notifier Interface
On 1/12/06, Florian Boor [EMAIL PROTECTED] wrote: Hi, Devesh Kothari wrote: - Events must be delivered regardless of the device state e.g sleep, deep sleep or poweroff state [but with battery plugged in] I'm not sure if poweroff is really necessary... it would be cool if it is possible but i suppose we could live without this if it is complicated to implement. Am I missing something here or just misunderstanding the meaning of the phrase Events must be delivered; if it means Events must be delivered, but possibly late (e.g. if event fired while in poweroff state) then that sounds like no problem. However, isn't the definition of hard poweroff that there is no state machine operating which can wake the system? - User should be able to schedule Events/Notification in any future time e.g my mothers birthday which is 8 months away. Definitely... snip - The ability to cancel/enable alarm might make things complicated for application developers, as then events not delivered to the registered apps, somebody need to tell them that the alarm was either cancelled or rescheduled, so they can reach a sync state. Well... usually applications will use both an alarm signal and some notification on screen. If the alarm signal is disabled by a system state and no user input received the device should just go to sleep again. Some system message indicating a missed alarm if the evice state is changed might be another possible way to deal with this. I see all three of these points as related and pointing to a solution which is something like what, IIRC, gpe-calendar does WRT layering functionality: 1) Some app or lib is responsible for recording/managing events. This app knows what events were supposed to go off, is notified by (2) when an event occurs, and is responsible for notifying apps that a) event has just occurred; b) event expired while device was powered off; c) event was otherwise cancelled by user, etc. 2) A kernel-level state machine which actually registers the timers for events and notifies (1) when they occur. Dbus seems like an appropriate channel for propagating events between (1) and (2). Any system w/ Dbus and libalarm or whatever would be able to offer apps the same API. Dave ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Doubts about flash memories and frequent writing
Hi everybody, sorry if my question seems too evident. As far as I know, the Nokia 770 contains a flash memory (128 MB), a RAM memory (64 MB) and the MMC card. All the filesystem is stored in the flash memory, and the MMC is mounted in /media/mmc1. Even, you can make swapping with a file in the MMC, as appeared some days ago in Planet Maemo. I am wondering if swapping and every day writing in the internal flash could damage these memories. Some people told me that flash memories should not be used for frequent disks writing (like swapping or every day usage of a computer). Is this relevant? I mean, could I damage the flash memory if I use the device very often and I make swap on the MMC or internal flash? Regards, Israel Herraiz signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Doubts about flash memories and frequent writing
On 1/12/06, Israel Herraiz [EMAIL PROTECTED] wrote: Hi everybody, sorry if my question seems too evident. As far as I know, the Nokia 770 contains a flash memory (128 MB), a RAM memory (64 MB) and the MMC card. All the filesystem is stored in the flash memory, and the MMC is mounted in /media/mmc1. Even, you can make swapping with a file in the MMC, as appeared some days ago in Planet Maemo. I am wondering if swapping and every day writing in the internal flash could damage these memories. Some people told me that flash memories should not be used for frequent disks writing (like swapping or every day usage of a computer). Is this relevant? I mean, could I damage the flash memory if I use the device very often and I make swap on the MMC or internal flash? Well, AFAICT, the internal flash where the root fs is stored is a JFFS2 partition which does wear leveling automatically, so for regular file access patterns I've heard it said that you're unlikely to reach the 100,000 erase cycles on enough blocks to cause a problem within a timeframe less than the normal obsolesence of the device, and then some. However, I've wondered the same thing about swap; even if one uses something like JFFS2 and swap to a file (rather than a raw swap partition), isn't it possible that the writes would be frequent enough to wear out the eraseblocks too quickly? I don't know even the beginnings of how swap + I/O interact to get my head around that. I just bought a 1 GiB mmcMobile card and though I'd love to set up a swap partition on it, I'd hate to quickly chew up usable space on the card. Dave ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] library packaging issues for maemo
Good afternoon, in my recent quest for a proper way of packaging libraries (libsigc++ for that matter) for maemo, I ran into a number of issues. The symptoms: I hunted down libsigc++-2.0_2.0.16-2.tar.gz source and applicable debian diff file, unpacked, applied the diff file and built arm.deb package. Installing it in scratchbox would give me 'Operation not permitted' error: [sbox-SDK_ARM:] app-installer-tool install libsigc++-2.0_arm.deb ... dpkg (subprocess): failed to chroot to `/var/lib/install': Operation not permitted dpkg: error processing libsigc++-2.0 (--purge): subprocess post-removal script returned error exit status 2 ... Installing the same package on 770 would fail somewhat differently: dpkg(subprocess): unable to execute old post-removal script: No such file or directory -- However, I remembered that GPE libraries would install flawlessly both on SDK_ARM and 770. Following recent announcement about new version of GPE by Florian Boor (thanks for the package!), I downloaded one of the libraries, libgpewidget, built and installed it just fine - no errors given. Both installation and removal was flawless. I unpacked libsigc++-2.0_arm.deb and libgpewidget_arm.deb archives side-by-side and began comparing the differences. What I found out after tiresome trial and error was that libgpewidget doesn't have either 'postinst' or 'postrm' shell scripts included in .deb package! So, by removing these two files from the archive and repackaging it again I was able to install libsigc++-2.0_arm.deb (if you burn with desire to learn the *art* of debian packaging by hand, check out this link http://db.glug-bom.org/wiki/index.php/Build_a_Debian_Package ) Another wrinkle - it is very easy to corrupt debian packaging archive - once you've attempted to install bad package with app-installer-tool, there is no way to get rid of it cleanly - you have to do it by hand: 1. Go to /var/lib/install/var/lib/dpkg 2. Open 'status' file and change the 'Status' line of your ill-fated package from 'purge reinstreq half-installed' to 'purge ok not-installed' 3. examine ./info directory. If there are any of package.postinst/.postrm files in there for you package, get rid of them. Now, being totally ignorant of debian packaging system, here are my questions: 1. What do I need to put in my package/debian/rules file to prohibit dpkg-deb from installing or adding any postinst/postrm file to the archive on its own. Even if I don't have any post-* scripts, dh_installdeb tends to stick a pair in with 'ldconfig' clause for 'remove' command (quite undestandable - it is a library after all). 2. Does 770 require to have ldconfig executed after library installation? 3. My guess the installation fails in the first place due to the permissions issue of some sort: I am logged in as a root, but install to /var/lib/install as 'installer' user. Could this be the root of all problems? 4. Is there a cleaner way of restoring the sanity of 'status' file except for editing it by hand? Here is the 'libsigc++-2.0/debian/rules' file in question -- #!/usr/bin/make -f # -*- makefile -*- # Use debhelper V. 3 export DH_COMPAT=4 # The current SONAME (FIXME: can we autodetect this?) SONAME=0c2a # Files whose name varies with the soname. For each entry x of this # variable, the file debian/libsigc++-2.0-$(SONAME).$(x) will be # created from debian/libsigc++-2.0.soname.$(x) file. SONAME_SPECIFIC_EXTS=install b := $(shell pwd)/debian/tmp binary: binary-arch binary-indep binary-arch: binary-arch-stamp binary-arch-stamp: install dh_testdir -a dh_testroot -a dh_compress -a dh_fixperms -a dh_makeshlibs -a -V'libsigc++-2.0-$(SONAME) (= 2.0.2)' dh_installdeb -a dh_shlibdeps -a dh_strip -a dh_gencontrol -a -- -VSoname=$(SONAME) dh_md5sums -a dh_builddeb -a touch binary-arch-stamp binary-indep: binary-indep-stamp binary-indep-stamp: install dh_compress -i -Xdoxygen_tags dh_fixperms -i dh_installdeb -i dh_strip -i dh_gencontrol -i -- -VSoname=$(SONAME) dh_md5sums -i dh_builddeb -i touch binary-indep-stamp build: build-stamp build-stamp: config dh_testdir -a #cd builddir perl -i -pe 's/^(hardcode_libdir_flag_spec\s*= \s*).+$$/$$1 -D__LIBTOOL_IS_A_FOOL__ /' libtool cd builddir $(MAKE) touch build-stamp clean: clean-arrange dh_testdir dh_testroot if [ -d builddir ]; then rm -rf builddir; fi #-for x in debian/*.patch; do patch --dry-run -fRp1 $$x /dev/null\ patch -fRp1 $$x ; done dh_clean build-stamp config-stamp install-stamp debian/shlibs.local config: config-stamp config-stamp: dh_testdir #for x in debian/*.patch; do patch --dry-run -fp1 $$x /dev/null \
Re: [maemo-developers] Doubts about flash memories and frequent writing
Israel Herraiz wrote: Hi everybody, sorry if my question seems too evident. As far as I know, the Nokia 770 contains a flash memory (128 MB), a RAM memory (64 MB) and the MMC card. All the filesystem is stored in the flash memory, and the MMC is mounted in /media/mmc1. Even, you can make swapping with a file in the MMC, as appeared some days ago in Planet Maemo. I am wondering if swapping and every day writing in the internal flash could damage these memories. Some people told me that flash memories should not be used for frequent disks writing (like swapping or every day usage of a computer). Is this relevant? I mean, could I damage the flash memory if I use the device very often and I make swap on the MMC or internal flash? Regards, Israel Herraiz Older NOR flash has a 100,000 write limitation (complete write), NAND flash has about one million write cycles. All flash memory these days is NAND. I wouldn't recommend swap on flash, but you (if you must) probably want swap on a removable card. -- Lorn 'ljp' Potter Trolltech Qtopia Community Manager Opie Core Developer http://qtopia.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Is it possible that migrate J2me to Nokia 770?
Or of course you can go the certification path but that will cost you some $. So, feasable, yes. It has even been done, yes. A good way to go? No. Why isn't it a good way? It seems Nokia bought a Opera license for the Nokia 770, why they shouldn't buy a J2ME Personal Profile license for the webpad? Sharp also offered J2ME Personal Profile on the Zaurus? There is no reason Nokia couldn't do this also for the Nokia 770. And as far as I know, Java is on the Maemo roadmap for future versions. I also like to see J2ME Personal Profile on the Nokia 770. There are some programs which can be easily ported or directly used on the Nokia 770 than. Probably look into Mono instead? Sorry, but I think if someone ask about J2ME migration, Mono isn't the answer. And second, there is not really a finished end user ready mono version for the Nokia 770 available yet. Regards Bernd ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Is it possible that migrate J2me to Nokia 770?
well, regardless these SUN bureaucratic/formal issues, you could also ask yourself about how would be the look of j2me apps running on such a device. I mean, would them fit in properly on this pretty large screen. In general, j2me aims cel phones (PDAs have a bigger screen/resolution support, I know), but its available-free-sdk widgets are not the at rich. A J2ME Personal Profile (successor of Personal Java) exists and is aimed for PDAs. The Personal Profile includes AWT. And, it shouldn't be a great problem to port eSWT from Eclipse to the Nokia 770, if J2ME Personal Profile is available on it, especially because a GTK based SWT allready exists. So, I'd suggest you , at least, porting an proprietary j2me, with customized widgets for the 77'device/maEmo, but in this case, Nokia'd have to 'step in' on the process ... Sure J2ME must be ported to the device including AWT. Btw, talking about game development on j2me, ok. there are some good ones. Java is running on the Sharp Zaurus well. And there are also some small nice games which also runs well on the Sharp Zaurus, for example Super Foul eggs. But Java is not only for games. IT would be nice on the Nokia 770 for other programs also. And a J2ME Personal Profile engine on the Nokia 770 also would make it possible to port eRCP http://www.eclipse.org/ercp/ from eclipse on it, which would be nice for future development of programs which could be run not only on the Nokia 770. Btw. eRCP is also available for Nokia series 80 phones. Just don't forget about performance issues, since it's an interpreted language. Java normally uses some sort of JIT Compilers. This is also true for Jeode on the Zaurus. Btw. the ARM CPU in the Nokia 770 offers with Jazelle a Java accelerator. Regards Bernd ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Fixing osso-email, building a custom treeview model. The technique in demo format
Hi there, In this repository I demo the beginnings of how I would implement the GtkTreeView crap for a client like osso-email https://svn.cronos.be/svn/custom-treemodel-demo/trunk/ I also created a wiki pages that explains the major problems with the current osso-email code, and how it could be fixed. http://maemo.org/maemowiki/ImprovementIdeasForOssoEmail Also check out my own wiki for more information http://www.pvanhoof.be/wiki/index.php/Different_ways_of_using_GtkTreeView -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] GPE PIM applications for Maemo progress
Hello, I have noted only a freeze trying to set an alarm for a new event in the calendar app. i uploaded new packages for libschedule and gpe-calendar which should fix this issue to http://www.kernelconcepts.de/~fuchs/nokia770/experimental. I didn't try so far... that needs to wait till tomorrow, i really need to get some sleep. Sources for both changes are available from CVS... Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] gtk dialog can not auto adjust
I add two buttons into dialog-vbox ,then click one to
remove the other,but after remove
the other,the dialog size not change to size which
just is suit for a button.
I even use
gtk_widget_set_size_request(dialog,width,height),it
seem that only when
width and height greater than orginal dialog
size,dialog change bigger,but when set height and
width smaller than orginal dialog size,it do
nothing,there is still blank area in the dialog which
used for the other button before. code below
#include gtk/gtk.h
#define A argc,argv
#defineGW GtkWidget*
#define GB gtk_button_new_with_label(xxx)
#define BP gtk_box_pack_start
GW dialog;
GW b;
GW b1;
void yes(GtkWidget* gtkwidget,gpointer data)
{
gtk_container_remove(GTK_CONTAINER(GTK_DIALOG(dialog)-vbox),b1);
gtk_widget_show_all(dialog);
}
int
main (int argc, char *argv[])
{gtk_init(A);
dialog=gtk_dialog_new();
b= GB ;
b1= GB ;
BP (GTK_BOX(GTK_BP
(GTK_BOX(GTK_DIALOG(dialog)-vbox),b,FALSE,FALSE,0);
BP (GTK_BOX(GTK_BP
(GTK_BOX(GTK_DIALOG(dialog)-vbox),b1,FALSE,FALSE,0);
gtk_widget_show_all(dialog);
g_signal_connect(G_OBJECT(b),clicked,G_CALLBACK(yes),b1);
gtk_main();
return ;
}
help me!
___
雅虎1G免费邮箱百分百防垃圾信
http://cn.mail.yahoo.com/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
