Re: Intone - the future and help needed
c_c wrote: Hi, c_c wrote: can someone convert this to edbus? Also - how do I register a callback to be triggered on an incoming call? I've used it just few times, but something like this [2] should work Ah! Thanks a lot. I get the idea. You can also get more by looking at the test programs available in e_dbus ;) -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone - the future and help needed
this probably won't be for the near future, but a route to bluetooth headset (+ maybe pairing) would be interesting; but i think intone is maybe not the place to start work on that one On Sun, Apr 12, 2009 at 6:13 PM, c_c cchan...@yahoo.com wrote: Hi, If you find a way for it to work, let me know. I'd be interested in it myself as well. Try reading this http://n2.nabble.com/Call-from-command-line-%28on-FSO%29-td1516004ef1958.html#a1516004. I also have the idea of making a daemon called pocketd that would register a few simple tap rythms with the accelerometers and output them using dbus signals. That kind of thing could work well here : ) That'd be really interesting and useful. You should go ahead and make it. I think Intone should keep you busy a bit longer then you think : P. There's lot to polish. There always is ;-). I can help pinpointing the problems but I'm too damn lazy to do the coding myself : D. That'd be good too. Yes, id3lib for mp3. Vorbis comments seem to be parseable without a library or perhaps libvorbis provides calls for that. As for m4a, does anyone use that for their music? I don't think there's reason to worry about that : ). Ha ! Ok. Lets see how that goes. Yeah, I did some testing and found quite a lot of unexpected behaviour. I'll compile it all into an e-mail and send it separately. Please do. I can see things that need doing - but it's always nice to have a second opinion. -- View this message in context: http://n2.nabble.com/Intone---the-future-and-help-needed-tp2623289p2624514.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone - the future and help needed
c_c wrote: 1. dbus - I've coded in glib and I'm not yet comfortable in edbus. So here's [1] the code I used in guitartune to request resource CPU - can someone convert this to edbus? Also - how do I register a callback to be triggered on an incoming call? I've used it just few times, but something like this [2] should work (I've not tested it in the phone). [2] http://pastebin.ubuntu.com/151118/ -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone - the future and help needed
Hi, c_c wrote: can someone convert this to edbus? Also - how do I register a callback to be triggered on an incoming call? I've used it just few times, but something like this [2] should work Ah! Thanks a lot. I get the idea. -- View this message in context: http://n2.nabble.com/Intone---the-future-and-help-needed-tp2623289p2636632.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Intone - the future and help needed
Hi,
Well, Intone has turned out to be pretty stable - other than the bugs I've
induced ;-) while fixing other stuff and a few niggling problems that I should
be able to sort out with the next release (hopefully today). So, I thought,
maybe I should share what I'm looking at adding to Intone in the future. So
here goes :-
1. Prevent suspend when playing songs and pause on incomnig call (dbus stuff)
2. Album art - an optional view that shows the album cover and meta
information about the playing song. Also - the icon then changes to show the
cover for songs whose album art is available
3. Lyrics - an optional view that shows lyrics for the playing song
4. map the aux button to choose between 3 diff volume levels in rotation - or
1 click for next song and 2 for the last song - Any opinions?
5. Ability to manage, download and play podcasts from intone (or should it be
a diff app catering to podcasts only?)
6. A seperate app (mostly Intone) to manage and play videos (using
mplayer-xgalmo).
Anything other interesting and needed feature that comes up based on your
feedback (graphic eq maybe?)
And to be able to do all this (really fast!) I need some help.
1. dbus - I've coded in glib and I'm not yet comfortable in edbus. So here's
[1] the code I used in guitartune to request resource CPU - can someone convert
this to edbus? Also - how do I register a callback to be triggered on an
incoming call?
2. How do I get album art? I've tried to get a key from allcdcovers.com - but
haven't got any response. And I'm not sure about the legality of getting the
images from an online retailer. Does anyone have any ideas/opinions - including
whether this is required or not?
3. Enlightenment help - i have a genlist in a vbox. I want to add some
labels, an entry and a photo to the same vbox. Can I then hide some widgets and
show some based on a button click in a way that the hidden widgets take no
space on the screen? I'm able to hide / show widgets - but the hidden widgets
also take up some blank space on the screen.
How do I show labels in a genlist so that when the item is selected the
labels also show through clearly? Right now the text in the genlist is clear -
but the labels get hidden behind the black highlight.
4. Pointers on how to do any of this stuff are welcome too. Patches are best
:-D
Thanks
Request resource CPU code using glib.
[1] DBusGConnection *connection;
GError *error;
DBusGProxy *proxy;
DBusGProxyCall* call;
char *resource = CPU;
g_type_init ();
error = NULL;
connection = dbus_g_bus_get (DBUS_BUS_SYSTEM, error);
if (connection == NULL) {
g_printerr (Failed to open connection to bus: %s\n,
error-message);
g_error_free (error);
exit (1);
}
// Create a proxy object
proxy = dbus_g_proxy_new_for_name (connection,
org.freesmartphone.ousaged,
/org/freesmartphone/Usage,
org.freesmartphone.Usage);
call = dbus_g_proxy_begin_call (proxy, RequestResource, NULL, NULL,
NULL, G_TYPE_STRING, resource, G_TYPE_INVALID);
dbus_g_proxy_end_call (proxy, call, error, G_TYPE_INVALID);
if (error != NULL) {
printf(dbus error: %s\n, error-message);
}
g_object_unref (proxy);
return 0;
}
--
View this message in context:
http://n2.nabble.com/Intone---the-future-and-help-needed-tp2623289p2623289.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Intone - the future and help needed
Hi, My $0.02 follows: On Sun, 12 Apr 2009 00:29:50 -0700 (PDT) c_c cchan...@yahoo.com wrote: 1. Prevent suspend when playing songs and pause on incomnig call (dbus stuff) Good idea although I'm not quite sure FSO framework is quite perfect for it yet. As I understand you can set the auto-suspending to off when Intone is started and return to its former value when it's closing. If Intone crashes or is killed however, the auto-suspending option will remain off, even if that wasn't intended. It probably still how it should be implemented now, I'd just like the framework to add something like for GPS for the disable suspend option. Something like that if anyone is using the no-suspend option then it's on and once everyone is disconnected from it, the default is returned, not matter if the app exited gracefully. That's not your problem however, I'm just ranting off. I should probably discuss it in the framework mailing list. 2. Album art - an optional view that shows the album cover and meta information about the playing song. Also - the icon then changes to show the cover for songs whose album art is available Yeah, nice idea, but I'll consider it a feature creep if the player will attempt to connect to the network. I think a nice approach would be to simply look for album.jpg or something the like in the album directory and use that. There could be a second app for automatically downloading the album art. Don't build it into the player however. The player should be there to play songs, not fool around on the Internet : ). 3. Lyrics - an optional view that shows lyrics for the playing song Ditto. If local songname-lyrics.txt file exists, use that, otherwise disregard. The second app could be used for downloading the lyrics. For both of the above, the find corresponding file from the same folder would probably not work if there is no directory structure. The extra app for downloading album art and lyrics should probably save the downloaded information straight to the database and give the downloaded files unique names if they are not in separate folders. 4. map the aux button to choose between 3 diff volume levels in rotation - or 1 click for next song and 2 for the last song - Any opinions? Actually I hate when apps start fooling around with my input controls. I currently put Intone in the playing mode, then use the aux button to lock the phone so I can leave it safely in my pocket. I'd rather it didn't change that. The aux button is too small anyway, no chance of pressing it when phone's in the pocket, if it's out, no problem using the touch screen. 5. Ability to manage, download and play podcasts from intone (or should it be a diff app catering to podcasts only?) My opinion is that it should be a different app alltogether. Amarok and the like are fun beasts but this is embedded we're talking about. Let your app do one thing and do it well : ). 6. A seperate app (mostly Intone) to manage and play videos (using mplayer-xgalmo). Yeah why not. You did well on finger-friendly GUI design on Intone, we could probably use a video player like that as well. I'd suggest you concentrate on Intone for now however and leave the video player for later when perhaps someone can optimize video playing enough to make it really feasable on the Freerunner. So far I don't see it, I do see the feasability of an audio player though. Anything other interesting and needed feature that comes up based on your feedback (graphic eq maybe?) I think the first priority should be bug fixing and integrating to the framework via DBus. As for features, perhaps a full screen mode where the whole screen is just big buttons and no output. I'm not sure this is needed however, the input was probably good enough for now. What I wouldn't mind would be compiling the artists, albums and songs using corresponding tags on both mp3-s and ogg-s instead of just directory structure. I never bothered to move my music around so on the Freerunner it's all piled together into a single folder. My tags are healthy however and organizing based on that would be nice. I suggest that the only time you'd need to look for the tags would be when importing new music. Then it can all be saved in the database and save on resources. There could be a out-of-sight button for re-reading tags on selected songs in case you've changed them however. The latter of course is a low priority but the tag system itself would be good. Perhaps there should be automatic directory structure creation as well on importing songs - toggleable certainly. I find it hard to get only the songs I want on the freerunner while keeping the directory structure in place. No more ideas for now. I'll try to investigate that database bug and recreate it. I'll let you know if I manage to find out how it happens or if I have any other ideas. Thanks and regards, Yogiz ___ Openmoko community mailing list community@lists.openmoko.org
Re: Intone - the future and help needed
Hi, Thanks for the detailed reply. I kind of pretty much agree with most of what you've written. If Intone crashes or is killed however, the auto-suspending option will remain off, even if that wasn't intended. Actually, it does release the suspend bit if the app crashes. You prevent suspend and your request is valid till the app runs. On exit the request is released automatically - or at least that's what I've understood. I might be wrong though. The player should be there to play songs, not fool around on the Internet : ). I subscribe to the unix idea of 'one tool for one thing' too. But its easy to want to do everything too! So, I'll make this downloading album art from the internet a script - that should be easier to maintain too. Same for lyrics I guess. Only, while the lyrics thing is relatively easy to to (with lyrics wiki for eg) I'm kind of stuck on how to go about doing the album art thingy. Actually I hate when apps start fooling around with my input controls. Ha! But I do like the idea of having some control without taking the player out of my pocket. Maybe using the button on the headphones is a better idea? What do you think? My opinion is that it should be a different app alltogether. I agree. Though eventually this app too will play audio files. But again, it will be easier to maintain as a separate app. However, since I'm not a regular user of podcasts - I'll like to hear some more opinions on this one. .someone can optimize video playing enough to make it really feasable on the Freerunner. I haven't tried playing videos because it seems like a painful thing to do. So - a GUI will definitely help pushing for a better player / method. Since Intone is essentially a mplayer frontend - I think it shouldn't be too difficult to modify it to start playing videos. I'll do this as soon as I can sort out the few remaining bugs in Intone. I think the first priority should be bug fixing and integrating to the framework via DBus. I agree. I could do with a little help too. :-D What I wouldn't mind would be compiling the artists, albums and songs using corresponding tags on both mp3-s and ogg-s instead of just directory structure. That's been on my mind too - but I wasn't sure of all the libraries I would need to cater for reading tags from all the different types of files out there. I can commence with mp3's (using id3lib). Can anyone point out other libraries with this functionality for ogg's and m4a's which are also in the repositories? No more ideas for now. I'll try to investigate that database bug and recreate it. I'll let you know if I manage to find out how it happens or if I have any other ideas. Thanks for expressing your views. That db bug is another mysterious one and I hope it gets resolved soon. -- View this message in context: http://n2.nabble.com/Intone---the-future-and-help-needed-tp2623289p2623902.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone - the future and help needed
On Sun, 12 Apr 2009 04:57:55 -0700 (PDT) c_c cchan...@yahoo.com wrote: Hi, Thanks for the detailed reply. I kind of pretty much agree with most of what you've written. If Intone crashes or is killed however, the auto-suspending option will remain off, even if that wasn't intended. Actually, it does release the suspend bit if the app crashes. You prevent suspend and your request is valid till the app runs. On exit the request is released automatically - or at least that's what I've understood. I might be wrong though. That's how it should work but I'm not certain that kind of thing is implemented now. I got the impression that apps simply use the framework to change the auto-suspend preferences at the start and closure of an app. I might be mistaken. If you find a way for it to work, let me know. I'd be interested in it myself as well. The player should be there to play songs, not fool around on the Internet : ). I subscribe to the unix idea of 'one tool for one thing' too. But its easy to want to do everything too! So, I'll make this downloading album art from the internet a script - that should be easier to maintain too. Same for lyrics I guess. Only, while the lyrics thing is relatively easy to to (with lyrics wiki for eg) I'm kind of stuck on how to go about doing the album art thingy. Sound good. Actually I hate when apps start fooling around with my input controls. Ha! But I do like the idea of having some control without taking the player out of my pocket. Maybe using the button on the headphones is a better idea? What do you think? Yeah, the headphone button would be good. I also have the idea of making a daemon called pocketd that would register a few simple tap rythms with the accelerometers and output them using dbus signals. That kind of thing could work well here : ). ---snip--- .someone can optimize video playing enough to make it really feasable on the Freerunner. I haven't tried playing videos because it seems like a painful thing to do. So - a GUI will definitely help pushing for a better player / method. Since Intone is essentially a mplayer frontend - I think it shouldn't be too difficult to modify it to start playing videos. I'll do this as soon as I can sort out the few remaining bugs in Intone. I think Intone should keep you busy a bit longer then you think : P. There's lot to polish. I think the first priority should be bug fixing and integrating to the framework via DBus. I agree. I could do with a little help too. :-D I can help pinpointing the problems but I'm too damn lazy to do the coding myself : D. What I wouldn't mind would be compiling the artists, albums and songs using corresponding tags on both mp3-s and ogg-s instead of just directory structure. That's been on my mind too - but I wasn't sure of all the libraries I would need to cater for reading tags from all the different types of files out there. I can commence with mp3's (using id3lib). Can anyone point out other libraries with this functionality for ogg's and m4a's which are also in the repositories? Yes, id3lib for mp3. Vorbis comments seem to be parseable without a library or perhaps libvorbis provides calls for that. As for m4a, does anyone use that for their music? I don't think there's reason to worry about that : ). No more ideas for now. I'll try to investigate that database bug and recreate it. I'll let you know if I manage to find out how it happens or if I have any other ideas. Thanks for expressing your views. That db bug is another mysterious one and I hope it gets resolved soon. Yeah, I did some testing and found quite a lot of unexpected behaviour. I'll compile it all into an e-mail and send it separately. Regards, Yogiz ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone - the future and help needed
Hi, If you find a way for it to work, let me know. I'd be interested in it myself as well. Try reading this http://n2.nabble.com/Call-from-command-line-%28on-FSO%29-td1516004ef1958.html#a1516004. I also have the idea of making a daemon called pocketd that would register a few simple tap rythms with the accelerometers and output them using dbus signals. That kind of thing could work well here : ) That'd be really interesting and useful. You should go ahead and make it. I think Intone should keep you busy a bit longer then you think : P. There's lot to polish. There always is ;-). I can help pinpointing the problems but I'm too damn lazy to do the coding myself : D. That'd be good too. Yes, id3lib for mp3. Vorbis comments seem to be parseable without a library or perhaps libvorbis provides calls for that. As for m4a, does anyone use that for their music? I don't think there's reason to worry about that : ). Ha ! Ok. Lets see how that goes. Yeah, I did some testing and found quite a lot of unexpected behaviour. I'll compile it all into an e-mail and send it separately. Please do. I can see things that need doing - but it's always nice to have a second opinion. -- View this message in context: http://n2.nabble.com/Intone---the-future-and-help-needed-tp2623289p2624514.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
