use of Glade for N810
Hi, I'm a new to development in Maemo. I have some queries from the developers. I'm writing an application for N810 device that uses widgets like: 1. Gtk Combo Box 2. Gtk Tree View 3. Pop Up windows for dialogues 4. Buttons and Labels 5. Gtk CList My application will have just 1 toplevel window. Can I use Glade to design my GUI so that it works in the hildon program. I want my application to work by simple tapping by stylus. I have my application written in GTK+, how do I make it work in N810? If my application works in scratchbox, does it ensure it will work in N810? Regards Arvind =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Portrait Maemo app
David Greaves wrote: > Hi > I'm writing an app that would be best presented in portrait mode - can this > be done? > > I don't mind jumping through a few hoops but I'd like to share it at some > point > so it needs to be done inside my app. Also it would need to scroll down (well, > sideways) a fair few pages. > > I have it mocked up in gtk+ at the moment and it's begging to be turned > through > 90deg. > It's a touch based app so there are no typing issues. > > What if I use the new Qt4 port? (The Zaurus Qtopia port introduced rotation > but > I think that was at the fb level) Qt's rotation is not done on the hardware level, it is done in Qt's software. It can be done, if the transformed driver is being used. -- Lorn 'ljp' Potter Software Engineer, Systems Group, MES, Trolltech ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Portrait Maemo app
David, There are a number of options available to you, but each will depend upon your requirements. On the nokia device its not lack of options, but graphical bandwidth: the display cannot update fast enough to render full screen RGB graphics at fullspeed without some sort of tearing. Even before rotating, you may want to examine ways to reduce bandwidth (lowering resolution is primary). However if you are willing to try, you could look at the following options and you may find something which suits you. The simplest if you are producing an application which just needs to be on its side is to rotate your assets: Load in the images at 90degrees and translate coordinates around, but basically keep the system working as standard on stock hardware. Depending upon the performance level you hope to achieve this method may not produce desirable results, but will at least be round the corner. You should be able to prove pretty quickly if this approach will work for you with just a quick hunt through your program. The second is to actually bite the bullet and install a kernel patch to rotate the display. This has been seen working by lots of people and whilst requires deeper system changes makes your coding much simpler (your assets are still laid out logically) http://sse2.net/rotate/ A deeper more outlandish method would be to work around the graphics bandwidth problem by coding yourself a graphics library which is based on YUV (full resolution greyscale, lower resolution color) and see where it gets you.. Much like I've started to do: http://www.youtube.com/watch?v=PUPp_mE7rwI Obviously there are other options available, but that pretty much covers what I have heard about people doing recently. Have fun Gary (lcuk on #maemo) On Sun, Jun 8, 2008 at 7:19 PM, David Greaves <[EMAIL PROTECTED]> wrote: > Hi > I'm writing an app that would be best presented in portrait mode - can this > be done? > > I don't mind jumping through a few hoops but I'd like to share it at some > point > so it needs to be done inside my app. Also it would need to scroll down > (well, > sideways) a fair few pages. > > I have it mocked up in gtk+ at the moment and it's begging to be turned > through > 90deg. > It's a touch based app so there are no typing issues. > > What if I use the new Qt4 port? (The Zaurus Qtopia port introduced rotation > but > I think that was at the fb level) > > David > ___ > 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
Portrait Maemo app
Hi I'm writing an app that would be best presented in portrait mode - can this be done? I don't mind jumping through a few hoops but I'd like to share it at some point so it needs to be done inside my app. Also it would need to scroll down (well, sideways) a fair few pages. I have it mocked up in gtk+ at the moment and it's begging to be turned through 90deg. It's a touch based app so there are no typing issues. What if I use the new Qt4 port? (The Zaurus Qtopia port introduced rotation but I think that was at the fb level) David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Replacing the standard maemo bluetooth pairing dialog.
Fheem > This program works on the principle of default security pins and the program > comes with a script to do just this. one application registers itself as the passkey agent using d-bus. A second agent trying to register will fail. maybe there's a way to intercept at a different layer. -- Brad ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Replacing the standard maemo bluetooth pairing dialog.
On Sun, Jun 08, 2008 at 06:57:05AM +0100, Faheem Pervez wrote: > I've made a compile of carwhisperer for the maemo platform ( > http://www.internettablettalk.com/forums/showthread.php?t=20780). The app > itself seems to work (from what I can tell anyway) but there is one problem > with this. > > This program works on the principle of default security pins and the program > comes with a script to do just this. I've added in the pin_helper > configuration option in the hcid.conf and on a standard Linux system running > BlueZ, this works. However, on the OSSO versions of BlueZ, this doesn't > work. I think modern versions of hcid always use dbus to show the PIN dialog. On my laptop the 'pin_helper' option is not even mentioned in hcid.conf's manual page any more. 'strings `which hcid`|grep pin_helper' returns no hits either. Marius Gedminas -- Did you hear that the author of _Nitpicking for Dummies_ has just received it back from the publisher with the 182nd set of editorial markups? -- Bill Snyder signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP SBC encoder task
On Sun, Jun 08, 2008 at 01:01:57AM +0100, Simon Pickering wrote: > Other than that, I'm hopeful it should just drop in to replace the > contents of the sbc directory in Bluez-utils and compile and work. I > just tried to cross-compile Bluez-utils, and other than the lack of > Flex (which is a dep) Scratchbox is complaining about not being able > to run binaries it has produced. Any suggestions? Too late in the > evening here to do any more today, but I'll get it working tomorrow. If you've upgraded your OS/kernel lately, you need a couple of sysctl tweaks to run binaries in scratchbox: echo 0 | sudo tee /proc/sys/vm/vdso_enabled echo 4096 | sudo tee /proc/sys/vm/mmap_min_addr Marius Gedminas -- The moral of the story is that with a contrived example, you can prove anything. Oops. No, that's not what I meant to say. -- Joel Spolski signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: maemo packaging policy -draft
> * Interactive prompts from maintainer scripts (such as asking where > do you want to stick this new thing in your menus) are annoying for > the user. I'd be inclined to add a sentence or two saying that these > SHOULD be avoided where possible. Speaking as a user, the *lack* of asking which menu this belongs under is annoying. Stuffing all add-ons into Extras sucks. I want my tools organized according to uses, not according to which person developed them. -- Allen Brown abrown at peak.org http://brown.armoredpenguin.com/~abrown/ I have noticed that the people who are late are often so much jollier than the people who have to wait for them. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: About release dates (was RE: maemo Bug Jar #7)
Am Samstag, 7. Juni 2008 schrieben Sie: > ... > > Quality first! Releasing shouldn't _only_ be a management > > decision. When the quality is as expected then the (scrum ?) > > team should hand over the responsibility to the management. > > They can then powerpoint the great event ;-) > > And this is what the maemo development team does. > > To understand better what Josh is saying you need to know that there is > a gap of time between the moment the development team says 'this release > is ready' and the moment the image goes actually out. The public release > date is decided from a business and marketing perspective based on many > factors that go beyond the quality of the software. > > > Personally I > > consider fix release dates as contra productive. Quality it > > the key to success. > > There are lots of books about waterfall and agile development, and about > feature or timebox based development. In fact all combinations exist > i.e. agile + timebox. > Quim, this is getting really interesting. Maybe you could give us (the comunity) a brief insight about your combinations of different development strategies. How about the modest team? They release often with high quality - scrum? (I know that you can't tell us much due to hundreds of constrains - but, hey who knows. Could be a pr relevant article or so. :) ) It would allow us to understand software development in such a special and interesting part of the market. Cheers Krischan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP SBC encoder task
> I've re-written the original thread-based (async) code today and it's > now synchronous - a call is made to sbc_encode() on the ARM and it's > passed through to the DSP and the work is done and the data passed back. > > This should all fit in without any changes to the code which calls the > sbc_* functions. They still call just sbc_init(), sbc_encode() and > sbc_close() and all the DSP stuff is handled in the background. If > there are parts which need access to lower level data (the example > sbcenc code doesn't), then I'll have to write a link in to the DSP to > retrieve that data. Not a big issue, but I'll have to take a look at > the Bluez code and GStreamer bits to see if this is needed (or someone > let me know). A couple of questions still remain about the maximum > size of a single PCM or SBC data transfer (so I can make the DSP > buffers as small as possible) - any thoughts? > > Other than that, I'm hopeful it should just drop in to replace the > contents of the sbc directory in Bluez-utils and compile and work. I > just tried to cross-compile Bluez-utils, and other than the lack of > Flex (which is a dep) Scratchbox is complaining about not being able > to run binaries it has produced. Any suggestions? Too late in the > evening here to do any more today, but I'll get it working tomorrow. > >> In theory it should be fairly easy to create a new GStreamer element >> that overrides the software one. > > With regard to overriding, I tried a bit of code to look at an env var > and choose SW/DSP from that, but it doesn't seem to work. Strange, as > I've also written the DSP code so that if the DSP fails for any reason > it will fall back to using the sw encoding method (and that works). > Probably a silly error I've missed, but it's late so I'll take a look > at it tomorrow. > > The latest code is available in the Garage project under the "mk2" > directory if anyone wants to have a play with it while I'm asleep :) > Right, I've created some binary DSP modules, which are available for the 770 and os2008 (chinook) devices for download from the Garage page. The SBC code seems to drop straight into the bluez-utils-3.32 code (certainly it compiles), however there is an error when I move the updated bluez-* files over to my N800 test machine and try running mplayer over a2dp. I think this basically means I'll need to recompile something else. If anyone knows what, or fancies having a go please speak up :) The error (returned by mplayer) is: Nokia-N800-50-2:/home/user/MyDocs/.sounds# mplayer Moby-In_My_Heart.mp3 MPlayer 1.0rc1-maemo.27.n8x0 (C) 2000-2006 MPlayer Team CPU: ARM Internet Tablet OS version: RX-34+RX-44_2008SE_2.2007.50-2_PR_MR0 [MENU] Can't open menu config file: /root/.mplayer/menu.conf Menu inited: /etc/mplayer/menu.conf Playing Moby-In_My_Heart.mp3. Cache fill: 0.00% (0 bytes) Audio file file format detected. == Trying to force audio codec driver family dspmp3... Opening audio decoder: [dspmp3] MP3 audio pass-through for Nokia 770/N800 (fake decoder) ADecoder preinit failed :( ADecoder init failed :( Trying to force audio codec driver family libmad... Opening audio decoder: [libmad] libmad mpeg audio decoder AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400) Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3) == alsa-lib: pcm_bluetooth.c:1505:(audioservice_recv) Error receiving data from audio service: Success(0) alsa-lib: pcm_bluetooth.c:1521:(audioservice_expect) Bogus message BT_GETCAPABILITIES_REQ received while BT_GETCAPABILITIES_RSP was expected alsa-init: playback open error: Invalid argument Could not open/initialize audio device -> no sound. Audio: no sound Video: no video Exiting... (End of file) Which looks like some sort of API change. I'm not sure if libasound.so needs to be recompiled (though I seem to get a plugin for it when compiling bluez-utils, so I'm doubtful), or if mplayer needs to be recompiled (which I'll try in a minute to see). Anyway, as I said, the DSP binary (and source) code (which tends to be the limiting factor with people playing with these things) is available for download, so all you then need to do is use the sbc source from the Garage repo and compile away and test things. Let me know if it works :) Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: About release dates (was RE: maemo Bug Jar #7)
On Sun, Jun 8, 2008 at 3:58 PM, Luca Olivetti <[EMAIL PROTECTED]> wrote: > En/na Frederic Crozat ha escrit: > >> >> Translation : images are ready (and have probably been ready for some >> time) and are held back for "media coverage" purpose. > > I wouldn't be so sure: packages in > http://catalogue.tableteer.nokia.com/updates/diablo/ are being updated > (or so it seems looking at the dates) at least weekly. As I wrote earlier, I was playing devil advocate ;) OTOH, since Diablo is featuring SSU, nothing would prevent Nokia from shipping already generated images and have updates available at the same time (but it would probably been seen as a bad handling from Nokia by most people). We have this kind of issues for Mandriva distribution, since between the time we generate ISO, we validate them and release them, new security updates (or bug fixes) might be already pushed through the update channel. -- Frederic Crozat ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: About release dates (was RE: maemo Bug Jar #7)
En/na Frederic Crozat ha escrit: > > Translation : images are ready (and have probably been ready for some > time) and are held back for "media coverage" purpose. I wouldn't be so sure: packages in http://catalogue.tableteer.nokia.com/updates/diablo/ are being updated (or so it seems looking at the dates) at least weekly. Bye -- Luca ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: About release dates (was RE: maemo Bug Jar #7)
On Sat, Jun 7, 2008 at 11:16 PM, <[EMAIL PROTECTED]> wrote: > Hi, Hi, I'm going to play the devil advocate *on purpose*, even if I know perfectly what constraints exist to release free software, both as a member of GNOME release team and a Mandriva employee working on Mandriva Linux distribution for about 8 years. >> Am Donnerstag, 5. Juni 2008 schrieb [EMAIL PROTECTED]: >>> Frederic Crozat wrote: >>> > Remember that most people are not used to Nokia policy to embargo >>> > any date (even estimate) regarding software (or hardware) release. > > True. These people need to understand that Nokia is a company watched by > competitors, the media, shareholders... Device launches and software > releases have an impact in this context far beyond the software update > itself. This is why Nokia generally doesn't disclose release dates. (I'm only commenting regarding Diablo release, not hardware release) Well, if you don't couple strongly (or if you don't advertise it) software and hardware (like you seem to imply for Diablo which could be released at the same time as n810 WiMax is released), I don't see any problem. Nokia Internet Tablet have created their own niche market and don't have any competitor yet (since they are not designed, on purpose, as PDA nor smartphone), so this argument is bogus. I really don't think shareholders have any interest in software release date. Their interest is good financial result from Nokia, that is it. For media, unless things have changed recently, Nokia is not Apple and IT are (again) a niche market, so media interest is quite low on it. >>> For simplicity's sake, I don't know when Diablo will be released. >> >> Quality first! Releasing shouldn't _only_ be a management >> decision. When the quality is as expected then the (scrum ?) >> team should hand over the responsibility to the management. >> They can then powerpoint the great event ;-) > > And this is what the maemo development team does. > > To understand better what Josh is saying you need to know that there is > a gap of time between the moment the development team says 'this release > is ready' and the moment the image goes actually out. The public release > date is decided from a business and marketing perspective based on many > factors that go beyond the quality of the software. Translation : images are ready (and have probably been ready for some time) and are held back for "media coverage" purpose. I don't by the "business" perspective for a "software" release, since the earlier you release a software update, the more chance to continue selling hardware (or to prevent hardware sales to decline) you get. > Also, who said our release dates are so fixed? Remember how upset some > people were last year when I dared to give rough time estimations for > the Hacker Edition and the OS2008 releases, and at the end they came > later? Guess what was the role of quality in that. Well, you just said in your linuxtag talk that "releases were always delivered on time", so it means they are fixed (or if they were decided like "ok, we are releasing tomorrow", then you really need to change the way you deliver a message in a talk :p ) -- Frederic Crozat ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Replacing the standard maemo bluetooth pairing dialog.
Hmm, so icd handles the bluetooth pin dialog. Many thanks, it helps me finally see where this message is coming from. (Shame I can't do anything about it as icd is closed source) On Sun, Jun 8, 2008 at 11:07 AM, Tuukka Tolvanen <[EMAIL PROTECTED]> wrote: > Faheem Pervez wrote: > > I've made a compile of carwhisperer for the maemo platform >> (http://www.internettablettalk.com/forums/showthread.php?t=20780). The >> app itself seems to work (from what I can tell anyway) but there is one >> problem with this. >> >> This program works on the principle of default security pins and the >> program comes with a script to do just this. I've added in the >> pin_helper configuration option in the hcid.conf and on a standard Linux >> system running BlueZ, this works. However, on the OSSO versions of >> BlueZ, this doesn't work. >> >> I've tried rebooting, disabling the bluetooth statusbar applet, I've >> tried moving btcond, btsdp, btsearch to another place, I've even tried >> moving the relevant files in /etc/dbus-1 to no avail. I can see with top >> that the dbus-daemon is using a little bit more power when asking for >> the paircode. I've even recompiled a hcid from the BlueZ website (i.e >> devoid of any OSSO modifications) and replaced my binary in /usr/sbin >> but I still get the maemo pair dialog. >> >> So, how would I replace maemo bluetooth pairing dialog with another >> program I want to run externally. Or make the maemo bluetooth pairing >> dialog not interfere so hcid will run the program specified in the >> pin_helper option. >> > > http://lists.maemo.org/pipermail/maemo-developers/2006-October/023815.htmlseems > to contain some possibly relevant keywords, whether they're of any > practical use is of course another thing entirely ;) > > 't. > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Replacing the standard maemo bluetooth pairing dialog.
Faheem Pervez wrote: > I've made a compile of carwhisperer for the maemo platform > (http://www.internettablettalk.com/forums/showthread.php?t=20780). The > app itself seems to work (from what I can tell anyway) but there is one > problem with this. > > This program works on the principle of default security pins and the > program comes with a script to do just this. I've added in the > pin_helper configuration option in the hcid.conf and on a standard Linux > system running BlueZ, this works. However, on the OSSO versions of > BlueZ, this doesn't work. > > I've tried rebooting, disabling the bluetooth statusbar applet, I've > tried moving btcond, btsdp, btsearch to another place, I've even tried > moving the relevant files in /etc/dbus-1 to no avail. I can see with top > that the dbus-daemon is using a little bit more power when asking for > the paircode. I've even recompiled a hcid from the BlueZ website (i.e > devoid of any OSSO modifications) and replaced my binary in /usr/sbin > but I still get the maemo pair dialog. > > So, how would I replace maemo bluetooth pairing dialog with another > program I want to run externally. Or make the maemo bluetooth pairing > dialog not interfere so hcid will run the program specified in the > pin_helper option. http://lists.maemo.org/pipermail/maemo-developers/2006-October/023815.html seems to contain some possibly relevant keywords, whether they're of any practical use is of course another thing entirely ;) 't. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
