Re: Making my app. appear on the Navigator menu
Hi, ext Thomas Waelti wrote: > Thank you very much for your valuable feedback! > >> You need to provide D-BUS service only if: >> - You handle D-BUS messages in general (e.g. because you don't want >> the caller of your application to care about whether your program >> is already running or not) - You want to prevent user from >> (accidentally) running several instances of your program at the >> same time > > But shouldn't "most" applications provide a D-BUS service so that > they can receive system messages (low battery, shutdown, > screen blanking) and gracefully handle them? (kind of best practice??) Normal applications should be completely idle and not update screen when user is not interacting with them. If these are already true, there isn't really anything extra you need to do. And if your application is doing some activity (which is not user requested such as clock updates etc), you should stop those activities when you're not visible, not just when screen is blanked... If you have user data, you can save it periodically *if* the data has changed. On shutdown your application will be anyway killed, but saving ny non-autosaved data would be nice (assumes it's _fast_). :-) >>> And no, my Icon doesn't yet show up in the tasks - but at least I >>> can see and launch it from the Extras menu :-) > [...] >>> And with that >>> comes my other issue: the infowindow keeps being in the >>> foreground for at least 20 seconds even if the app has finished >>> loading long ago. Annoying. >>> >> Both issues are because the WM_CLASS provided by your application >> window and the one specified in its .desktop file do not match. >> Therefore Maemo Task Navigator cannot match what was started from >> the menu and the window the application opened. Therefore the >> startup banner doesn't go away and your window doesn't show up in >> the tasks. > [...] >> Gtk sets WM_CLASS automatically to the application (binary) name, >> so this is usually only a problem for non-Gtk apps, e.g. SDL games. >> See: https://bugs.maemo.org/show_bug.cgi?id=24 >> http://lists.maemo.org/pipermail//maemo-developers/2006- >> March/003513.html > > Whew - this clears it up. mClock currently is a pure Pygame thing, so that's > why the WM_CLASS was needed. Now I understand. I was confused because: > - I read somewhere about the use of WM_CLASS not being necessary anymore > - Some apps I dissected had the WM_Class in their .desktop file, but nowhere > in their app code, so it seemed unused (probably because they were GTK apps) > > So I now fixed this and the icon shows up in the TN. Cool :-) > However, the TN still doesn't know the NAME of my app! (Fortunately, I'm not > alone with this problem - UKMP has the same issue as I saw by coincidence) > -When in normal mode, pressing the Home icon brings up TN with my mClock > icon, but named as "unknown" > -When in Fullscreen mode, pressing the Home icon brings up TN with my mClock > icon, but named as "" (just like with UKMP) > What is missing now? How can I tell TN the name of my App? Hm. I'm not sure where TN currently takes the window name. If it's not from the app .desktop file, you need to set the window title in your program (preferably before you map the window). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Making my app. appear on the Navigator menu
Thank you very much for your valuable feedback! > You need to provide D-BUS service only if: > - You handle D-BUS messages in general (e.g. because you don't want > the caller of your application to care about whether your program > is already running or not) - You want to prevent user from > (accidentally) running several instances of your program at the > same time But shouldn't "most" applications provide a D-BUS service so that they can receive system messages (low battery, shutdown, screen blanking) and gracefully handle them? (kind of best practice??) >> And no, my Icon doesn't yet show up in the tasks - but at least I >> can see and launch it from the Extras menu :-) [...] >> And with that >> comes my other issue: the infowindow keeps being in the >> foreground for at least 20 seconds even if the app has finished >> loading long ago. Annoying. >> > Both issues are because the WM_CLASS provided by your application > window and the one specified in its .desktop file do not match. > Therefore Maemo Task Navigator cannot match what was started from > the menu and the window the application opened. Therefore the > startup banner doesn't go away and your window doesn't show up in > the tasks. [...] > Gtk sets WM_CLASS automatically to the application (binary) name, > so this is usually only a problem for non-Gtk apps, e.g. SDL games. > See: https://bugs.maemo.org/show_bug.cgi?id=24 > http://lists.maemo.org/pipermail//maemo-developers/2006- > March/003513.html Whew - this clears it up. mClock currently is a pure Pygame thing, so that's why the WM_CLASS was needed. Now I understand. I was confused because: - I read somewhere about the use of WM_CLASS not being necessary anymore - Some apps I dissected had the WM_Class in their .desktop file, but nowhere in their app code, so it seemed unused (probably because they were GTK apps) So I now fixed this and the icon shows up in the TN. Cool :-) However, the TN still doesn't know the NAME of my app! (Fortunately, I'm not alone with this problem - UKMP has the same issue as I saw by coincidence) -When in normal mode, pressing the Home icon brings up TN with my mClock icon, but named as "unknown" -When in Fullscreen mode, pressing the Home icon brings up TN with my mClock icon, but named as "" (just like with UKMP) What is missing now? How can I tell TN the name of my App? Thanks again! -Tom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Making my app. appear on the Navigator menu
Hi, ext Thomas D. Waelti wrote: [...] >> "D-BUS service file is installed in “/usr/share/dbus-1/services/” >> and maemo GUI needs to be restarted with “af-sb-init.sh restart” >> before D-BUS daemon recognizes it." > > But isn't this only valid for Scratchbox? IIRC, I can't do this in > xterm on my N800. My app still doesn't properly connect to the D-Bus, > even altough I did exactly like the examples tell me (PyMaemo doc) > and how I could observe in various examples that I dissected. I believe > this has something to do with services keeping running even after > an uninstall of a service file or with services Packages providing services should in general make sure that the services are stopped when the service package is removed. If it's an UI application (which user might be using), that's of course another matter. :-/ [...] > In my example, I had the code for mClock done after a few hours, thanks to > the ease of use of Python with Pygame (even if it was my first ever Python > app). > OTOH, I literally wasted more than double that time in trying to get the > D-Bus service to properly work with my app. You need to provide D-BUS service only if: - You handle D-BUS messages in general (e.g. because you don't want the caller of your application to care about whether your program is already running or not) - You want to prevent user from (accidentally) running several instances of your program at the same time Otherwise a .desktop file suffices just fine. If you request TN to start your app with D-BUS (by giving D-BUS service name in .desktop file), you need to register to D-BUS, otherwise D-BUS concludes that the process startup failed and forcibly terminates it. > And no, my Icon doesn't yet show up in the tasks - but at least I can see and > launch it from the Extras menu :-) > [Currently, my app doesn't seem to connect to it anymore, as I can't seem to > stop the screen blanking with display_blanking_pause; even altough I had it > up and running one evening... However, I DO launch the app using the D-Bus > service (at least I get the "mClock is loading..." info window when starting > it from the desktop and the app comes up. And with that comes my other issue: > the infowindow keeps being in the foreground for at least 20 seconds even if > the app has finished loading long ago. Annoying. Both issues are because the WM_CLASS provided by your application window and the one specified in its .desktop file do not match. Therefore Maemo Task Navigator cannot match what was started from the menu and the window the application opened. Therefore the startup banner doesn't go away and your window doesn't show up in the tasks. For the latter you might actually report a bug, although TN doesn't know it's your app, it could show at least some icon (e.g. "??" for unknown window)... Gtk sets WM_CLASS automatically to the application (binary) name, so this is usually only a problem for non-Gtk apps, e.g. SDL games. See: https://bugs.maemo.org/show_bug.cgi?id=24 http://lists.maemo.org/pipermail//maemo-developers/2006-March/003513.html - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Making my app. appear on the Navigator menu
It recently took me 2.5 days to install DevStudio w/all extensions for WM dev'tit was a freaking nightmare. They may have had easy installs and good docs in the past...but not so much anymore. I have like 20 bookmarks for WM apisnothing is in a single spot. Plus...like 20% of msoft links on their site for dev't are dead404 always. I remember attending a MS-Dev Conf like 15 years ago where they stated their "move" away from printed docs...but don't worry...everything you need will be in online help. Well as many of you already know...when you hit F1you 99% of time don't get actual help but "placeholder text". mike David Hazel wrote: > In the context of this thread, I would like to highlight one point of > Thomas' in particular: > > >> One thing Microsoft excels at is in documentation, example >> code and support (you get what you are paying for ;-) >> > > I guess the reaction of some people to that will be "Oh, well, Microsoft > have cash coming out their ears", so let me add this: > > Apple's documentation and development tools on Mac OS X leave Microsoft and > everyone else in the shade. Not only is the documentation very extensive, > complete, well-cross-referenced and online, it is FREE!!! On top of this, > their development tools are also free and every bit as good as anything that > Micro$oft produces. They have obviously realised that there's a commercial > advantage to ensuring their platform is well-supported by software > developers and have made it as easy as they can for that to happen. I spent > 6 months last year developing on Mac OS X (never having used it before), and > it was an absolute joy to work with something so well-engineered. It was > like being back in the VMS world, but with better development tools (and I > guess only another VMS programmer would know what a compliment that is). > > Why is this relevant here? Well, if Apple can do it, so can others. I'm not > asking for development tools other than the ones already available; just for > good documentation that doesn't assume everyone who reads it already knows > where to find the bits that the author has skipped over. A bare minimum > would be a web page that lists links to existing documentation in some kind > of logical order (e.g. where you get to read the pre-requisite information > before you're halfway through a complicated example which assumes you > already know it). > > > David Hazel > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Making my app. appear on the Navigator menu
In the context of this thread, I would like to highlight one point of Thomas' in particular: > One thing Microsoft excels at is in documentation, example > code and support (you get what you are paying for ;-) I guess the reaction of some people to that will be "Oh, well, Microsoft have cash coming out their ears", so let me add this: Apple's documentation and development tools on Mac OS X leave Microsoft and everyone else in the shade. Not only is the documentation very extensive, complete, well-cross-referenced and online, it is FREE!!! On top of this, their development tools are also free and every bit as good as anything that Micro$oft produces. They have obviously realised that there's a commercial advantage to ensuring their platform is well-supported by software developers and have made it as easy as they can for that to happen. I spent 6 months last year developing on Mac OS X (never having used it before), and it was an absolute joy to work with something so well-engineered. It was like being back in the VMS world, but with better development tools (and I guess only another VMS programmer would know what a compliment that is). Why is this relevant here? Well, if Apple can do it, so can others. I'm not asking for development tools other than the ones already available; just for good documentation that doesn't assume everyone who reads it already knows where to find the bits that the author has skipped over. A bare minimum would be a web page that lists links to existing documentation in some kind of logical order (e.g. where you get to read the pre-requisite information before you're halfway through a complicated example which assumes you already know it). David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Making my app. appear on the Navigator menu
Thanks for those pointers, Eero. That was the how-to that I began with when I first started trying to package up my application. I will go through it again once I've restructured my application to use the same directory structure as MaemoPad. The various explanations I've seen about how .desktop and .service files are to be used might make more sense once I've done that. David Hazel PS I like Make files, too. I'd write my own for this, except that the ones in the examples have been auto-generated and, as you say, are impossible to follow. Without proper explanations of what is supposed to be done (as opposed to just example code), I've no idea what I would need to put in one. -Original Message- From: Eero Tamminen [mailto:[EMAIL PROTECTED] Sent: 25 September 2007 18:04 To: ext David Hazel Cc: maemo-developers@maemo.org Subject: Re: Making my app. appear on the Navigator menu Hi, ext David Hazel wrote: > Hi Eero, > > Thanks for that suggestion. I'll give it a try and see what it tells me. What to do with the .desktop file seems to be mentioned here: http://maemo.org/development/documentation/how-tos/3-x/creating_a_debian_pac kage.html But I think the howto here (which links above howto): http://maemo.org/development/documentation/how-tos/3-x/howto_new_application _bora.html should have an example of how to get .desktop file into package with Autotools. - Eero PS. I'm not a fan of GNU Autotools, I like & use Makefiles as pkg-config and GNU Make can do 90% of what you actually get from Autotools (besides autogenerated 100KB configure script that is larger than rest of your code and much harder to debug). Debian packaging has also a lot of things one needs to know but at least they mostly make sense unlike libtools (part of Autotools)... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Making my app. appear on the Navigator menu
>> So you'd prefer me not to explain my problem as clearly and fully as >> possible? That'll help a lot, won't it? >> > > break your question into pieces, it will definitely encourage people > reading and answering :) I've tried that. It doesn't work. At best, I get an answer to the first question in the set. >> And by the occasional Nokia person, with presumably a commercial interest in >> making sure that people out in the wide world know how to write software for >> their kit. > > by stating you're working on behalf on a customer, you are the one with > commercial interest in this discussion. I'm not the one trying to sell hardware with a poorly-documented operating system. >> I've had answers to less than 50% of the questions I've asked. The rest of >> the answers I've had to dig out myself by trial and error. > > > people can't do everything for you ;) also it might be a direct > consequence of too much questions in a row. I hadn't realised we were on a ration here. >> Sometimes you have to be direct to get a response. And since when is >> pointing out the shortcomings of documentation and community support >> "whining"? I assume Nokia would like to know when there are shortcomings in >> both of these areas. It's quite likely, too, that there are others out there >> with similar problems to mine who simply don't dare shout because of exactly >> this kind of slap-down. >> > > my opinion is that information is there. > maybe its access could be improved. The first MAY be true (although some of it is mutually inconsistent, if you can find it). The second definitely is. > however it's really there and you're silently ignoring the pointers in > my answer: the "Getting Application to Task Navigator Menu" section of > the Maemo 3.x tutorial explains about .desktop and .service files, so > does the "Adding Application To Menu" section of the How to write a new > application to maemo 3.x document. I said in my original question that I had read the second of the above. Contrary to what you say, it does not "explain about" .desktop and .service files. It gives examples, which I have followed, but that alone does not get my application displaying correctly. There's obviously more to it than the explanation given there, and that's what I was asking about. >> And keeping silent about poor documentation and support won't help Nokia to >> sell non-Windows PDAs. Technology alone never sells itself, despite what >> many techies believe - you need good grass-roots support as well. That >> comes, in part, from there being widespread knowledge about how the >> technology works, and by hiding the complexities of the technology as much >> as possible. >> > > The documentation for what maemo is relying on exists out there: "How to > write a new application to maemo 3.x document" points to: >. http://www.gnu.org/software/autoconf >. http://www.gnu.org/software/automake >. http://www.gnu.org/software/gettext >. http://www.debian.org/doc/maint-guide/ > > Maybe it could be more centralized which i guess is trying to be > achieved by the new howtos on maemo.org: >. "creating a debian package" >. "howto make a debian DBG package" I read the first of those and had to ask questions on this mailing list about even that. The answer I got was to go away and read the "Debian New Maintainers' Guide", which I did. After reading this and then both of the items you mention, I finally managed to get my .deb package built and installing (as I said in my original email). It still didn't put the application on the menu, though. > it seems that someone realized that creating an installation package > wasn't that straightforward for someone who doesn't know about debian > packages. It probably is straightforward when you do know. It's that business of getting to know that seems to be the stumbling block. If the documentation was ALL listed in one central place (e.g. one of the Documentation pages on the Maemo site), and if it took the trouble to explain how things are supposed to work before launching into specific examples, we might all be able to do it without having to ask questions on this list. David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Making my app. appear on the Navigator menu
Hi Thomas, I really appreciate you taking the time and trouble to offer your words of support here. I haven't had time to read your email in full yet (I've just got back from walking the dog!), but I will. It's felt very lonely here, on occasions, while I've been banging my head against brick wall after brick wall, trying to find documentation that apparently exists but isn't very well referenced by the stuff I've been able to find. I've posted numerous questions along the way, and most of the replies have been either answers to one of several questions, or else fairly basic advice about things I haven't even asked about. I've had several slap-downs for daring to be a non-Unix person - something which people seem to assume means I'm a Windows person instead. In fact, I've 24 years of development experience on things as diverse as VMS, iRMX, Mac OS X, and, yes, Windows. Of all of them, only VMS and Mac OS really seem to have their act fully in gear (and VMS is of course dead now, pretty much). Thanks again for your support. Maybe the powers-that-be at Nokia might take notice if two of us are telling them the documentation is crap (sorry, incomplete in some key areas). David Hazel -Original Message- From: Thomas Waelti [mailto:[EMAIL PROTECTED] Sent: 25 September 2007 19:02 To: Gregory 'guardian' Pakosz; David Hazel Cc: maemo-developers@maemo.org Subject: Re: Making my app. appear on the Navigator menu I can really feel with David, as I encountered exactly the same issues when developing mClock during the last few weeks. While the N800 motivated me enough to plunge into Linux development, some issues around the Hildon Dekstop and D-Bus were indeed extremely frustrating. >> The problem I'm having now is understanding what I'm supposed to >> do to fix this. Having looked at all of the documentation I've >> listed above, I began reading [...] >> >> > i suggest you convert the energy you put in writing those long > emails into reading carefully > > http://maemo.org/development/documentation/tutorials/Maemo_tutorial_bo > ra.html http://maemo.org/development/documentation/how-tos/3- > x/howto_new_application_bora.html > >> My biggest problem is that all of the instructions I've read so >> far insist on giving me examples, and I can't pick out which >> things are relevant to me and which are not. >> [...] > studying maemopad is a good exercise to understand what's going on > (apt-get source maemopad), it worked for me. Isn't this a very non-efficient way to achieve something, especially if someone's needs differ a bit? Normally, there should be enough basic documentation covering a theme, and the example would then show the real-world application of it. The docs you quote are a good start - but not sufficient, as they only show how, but don't tell why - which is crucial to understand the area and be able to resolve problems. > "D-BUS service file is installed in “/usr/share/dbus-1/services/” > and maemo GUI needs to be restarted with “af-sb-init.sh restart” > before D-BUS daemon recognizes it." But isn't this only valid for Scratchbox? IIRC, I can't do this in xterm on my N800. My app still doesn't properly connect to the D-Bus, even altough I did exactly like the examples tell me (PyMaemo doc) and how I could observe in various examples that I dissected. I believe this has something to do with services keeping running even after an uninstall of a service file or with services not getting up and running even properly. (I did a lot of installs/uninstalls of my app) >> Any offers of help? Or is this going to be another of my >> questions that disappears into a black hole never to get answered? Using PyPackager (www.khertan.net ), I build my simple .debs directly on the device. Makes it much easier to get started in a simple way. -The yourappname.desktop file must go to usr\share\applications\hildon -The yourappname.service file must go to usr\share\dbus-1\services -Put a yourapp.png (26x26 pix) under usr\share\pixmaps Install OpenSSH, then connect as root to the device. Now SFTP through the directories, download what interests you and look at it. This way, you can also control if your files ended up where you wanted them... >> The N800 is an interesting piece of >> kit, but without MUCH better documentation and properly >> integrated development tools, it is too expensive to write for >> and more trouble than it's worth. >> > welcome to the embedded world, no you're no more under windows > sitting comfortably behind visual studio's brilliant debugger :) Even if this is the embedded world, stuff must become much better documented if Nokia wants to gain more support from developers. One thing Microsof
Re: Making my app. appear on the Navigator menu
I can really feel with David, as I encountered exactly the same issues when developing mClock during the last few weeks. While the N800 motivated me enough to plunge into Linux development, some issues around the Hildon Dekstop and D-Bus were indeed extremely frustrating. >> The problem I'm having now is understanding what I'm supposed to >> do to fix this. Having looked at all of the documentation I've >> listed above, I began reading [...] >> >> > i suggest you convert the energy you put in writing those long > emails into reading carefully > > http://maemo.org/development/documentation/tutorials/Maemo_tutorial_bo > ra.html http://maemo.org/development/documentation/how-tos/3- > x/howto_new_application_bora.html > >> My biggest problem is that all of the instructions I've read so >> far insist on giving me examples, and I can't pick out which >> things are relevant to me and which are not. >> [...] > studying maemopad is a good exercise to understand what's going on > (apt-get source maemopad), it worked for me. Isn't this a very non-efficient way to achieve something, especially if someone's needs differ a bit? Normally, there should be enough basic documentation covering a theme, and the example would then show the real-world application of it. The docs you quote are a good start - but not sufficient, as they only show how, but don't tell why - which is crucial to understand the area and be able to resolve problems. > "D-BUS service file is installed in “/usr/share/dbus-1/services/” > and maemo GUI needs to be restarted with “af-sb-init.sh restart” > before D-BUS daemon recognizes it." But isn't this only valid for Scratchbox? IIRC, I can't do this in xterm on my N800. My app still doesn't properly connect to the D-Bus, even altough I did exactly like the examples tell me (PyMaemo doc) and how I could observe in various examples that I dissected. I believe this has something to do with services keeping running even after an uninstall of a service file or with services not getting up and running even properly. (I did a lot of installs/uninstalls of my app) >> Any offers of help? Or is this going to be another of my >> questions that disappears into a black hole never to get answered? Using PyPackager (www.khertan.net ), I build my simple .debs directly on the device. Makes it much easier to get started in a simple way. -The yourappname.desktop file must go to usr\share\applications\hildon -The yourappname.service file must go to usr\share\dbus-1\services -Put a yourapp.png (26x26 pix) under usr\share\pixmaps Install OpenSSH, then connect as root to the device. Now SFTP through the directories, download what interests you and look at it. This way, you can also control if your files ended up where you wanted them... >> The N800 is an interesting piece of >> kit, but without MUCH better documentation and properly >> integrated development tools, it is too expensive to write for >> and more trouble than it's worth. >> > welcome to the embedded world, no you're no more under windows > sitting comfortably behind visual studio's brilliant debugger :) Even if this is the embedded world, stuff must become much better documented if Nokia wants to gain more support from developers. One thing Microsoft excels at is in documentation, example code and support (you get what you are paying for ;-) In the end, it is the maturity, ease-of-use and extent of the available software that makes a platform successful. Right now, its is still too hard for the less-than-hardcore devs to get up and running on Maemo. Which is a shame, because the concept and the device are fantastic IMHO. But then, this is a "young" platform that is still ripening... In my example, I had the code for mClock done after a few hours, thanks to the ease of use of Python with Pygame (even if it was my first ever Python app). OTOH, I literally wasted more than double that time in trying to get the D-Bus service to properly work with my app. And no, my Icon doesn't yet show up in the tasks - but at least I can see and launch it from the Extras menu :-) [Currently, my app doesn't seem to connect to it anymore, as I can't seem to stop the screen blanking with display_blanking_pause; even altough I had it up and running one evening... However, I DO launch the app using the D-Bus service (at least I get the "mClock is loading..." info window when starting it from the desktop and the app comes up. And with that comes my other issue: the infowindow keeps being in the foreground for at least 20 seconds even if the app has finished loading long ago. Annoying. (Another long mail, but at least this shows the energy and enthusiasm available :-) Best regards -Tom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Making my app. appear on the Navigator menu
> So you'd prefer me not to explain my problem as clearly and fully as > possible? That'll help a lot, won't it? > break your question into pieces, it will definitely encourage people reading and answering :) > And by the occasional Nokia person, with presumably a commercial interest in > making sure that people out in the wide world know how to write software for > their kit. by stating you're working on behalf on a customer, you are the one with commercial interest in this discussion. > I've had answers to less than 50% of the questions I've asked. The rest of > the answers I've had to dig out myself by trial and error. > people can't do everything for you ;) also it might be a direct consequence of too much questions in a row. > Sometimes you have to be direct to get a response. And since when is > pointing out the shortcomings of documentation and community support > "whining"? I assume Nokia would like to know when there are shortcomings in > both of these areas. It's quite likely, too, that there are others out there > with similar problems to mine who simply don't dare shout because of exactly > this kind of slap-down. > my opinion is that information is there. maybe its access could be improved. however it's really there and you're silently ignoring the pointers in my answer: the "Getting Application to Task Navigator Menu" section of the Maemo 3.x tutorial explains about .desktop and .service files, so does the "Adding Application To Menu" section of the How to write a new application to maemo 3.x document. > And keeping silent about poor documentation and support won't help Nokia to > sell non-Windows PDAs. Technology alone never sells itself, despite what > many techies believe - you need good grass-roots support as well. That > comes, in part, from there being widespread knowledge about how the > technology works, and by hiding the complexities of the technology as much > as possible. > The documentation for what maemo is relying on exists out there: "How to write a new application to maemo 3.x document" points to: . http://www.gnu.org/software/autoconf . http://www.gnu.org/software/automake . http://www.gnu.org/software/gettext . http://www.debian.org/doc/maint-guide/ Maybe it could be more centralized which i guess is trying to be achieved by the new howtos on maemo.org: . "creating a debian package" . "howto make a debian DBG package" it seems that someone realized that creating an installation package wasn't that straightforward for someone who doesn't know about debian packages. > I'm not some rookie fresh out of university. When someone with 24 years of > development experience, including in embedded software, says a platform is > difficult to develop on because of poor (or, more likely, poorly organised) > documentation, it's worth paying attention and not dismissing them out of > hand. my guess is that it's exactly what upsets you :( ok you have experience in development, still once the maemo sdk is installed, it's all uphill from there if you don't have knowledge about linux development, autotools and debian packages. >> good luck > > Looks like we'll all need it. > as well as pointers to the good references: the autotools tutorial by Alexandre Duret Lutz is one of them, you should get your files deployed correctly in no time. http://www-src.lip6.fr/homepages/Alexandre.Duret-Lutz/autotools.html hope you'll manage to get your application install smoothly. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Making my app. appear on the Navigator menu
Hi, ext David Hazel wrote: > Hi Eero, > > Thanks for that suggestion. I'll give it a try and see what it tells me. What to do with the .desktop file seems to be mentioned here: http://maemo.org/development/documentation/how-tos/3-x/creating_a_debian_package.html But I think the howto here (which links above howto): http://maemo.org/development/documentation/how-tos/3-x/howto_new_application_bora.html should have an example of how to get .desktop file into package with Autotools. - Eero PS. I'm not a fan of GNU Autotools, I like & use Makefiles as pkg-config and GNU Make can do 90% of what you actually get from Autotools (besides autogenerated 100KB configure script that is larger than rest of your code and much harder to debug). Debian packaging has also a lot of things one needs to know but at least they mostly make sense unlike libtools (part of Autotools)... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Making my app. appear on the Navigator menu
> i suggest you convert the energy you put in writing those long emails > into reading carefully So you'd prefer me not to explain my problem as clearly and fully as possible? That'll help a lot, won't it? > if you are unsure about the directory structure and you have no real > reason to change it, then stick with the one suggested: this really > eases reading the docs and tutorials. The problem there is that there is more than one directory structure "suggested": the one in the hello-world example is different from the one in MaemoPad. The hello-world example is closer to mine than MaemoPad's, but the fact that they differ is what makes me ask the question. > remember that help on the irc channel or the dev mailing list is > provided by volunteers. And by the occasional Nokia person, with presumably a commercial interest in making sure that people out in the wide world know how to write software for their kit. > from what i can > recall, a lot of people on the mailing list helped you already. I've had answers to less than 50% of the questions I've asked. The rest of the answers I've had to dig out myself by trial and error. > did you > ever consider you were not asking the right way ? > in any case, whining never helped. Sometimes you have to be direct to get a response. And since when is pointing out the shortcomings of documentation and community support "whining"? I assume Nokia would like to know when there are shortcomings in both of these areas. It's quite likely, too, that there are others out there with similar problems to mine who simply don't dare shout because of exactly this kind of slap-down. > how does it help solving your problem with .desktop and .service files ? Not with those, specifically, but I'm hoping the remark will serve to prompt someone at Nokia to take this issue seriously. Platforms don't gain widespread support when they're only suitable for technically-minded people. > unfortunately, blaming the platform, the people behind it, and the > community won't bring you more attention nor more help offers. And keeping silent about poor documentation and support won't help Nokia to sell non-Windows PDAs. Technology alone never sells itself, despite what many techies believe - you need good grass-roots support as well. That comes, in part, from there being widespread knowledge about how the technology works, and by hiding the complexities of the technology as much as possible. > welcome to the embedded world, no you're no more under windows sitting > comfortably behind visual studio's brilliant debugger :) Nor am I under Mac OS X with its even better (GNU-based) debugger, well thought-out documentation and integrated development/deployment tools ;) I'm not some rookie fresh out of university. When someone with 24 years of development experience, including in embedded software, says a platform is difficult to develop on because of poor (or, more likely, poorly organised) documentation, it's worth paying attention and not dismissing them out of hand. Again, Nokia need to be aware that there are issues like this with their platform. Keeping quiet about it would not help them. > good luck Looks like we'll all need it. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Making my app. appear on the Navigator menu
Hi Eero, Thanks for that suggestion. I'll give it a try and see what it tells me. David Hazel -Original Message- From: Eero Tamminen [mailto:[EMAIL PROTECTED] Sent: 25 September 2007 17:00 To: ext David Hazel Cc: maemo-developers@maemo.org Subject: Re: Making my app. appear on the Navigator menu Hi, ext David Hazel wrote: > write a new application to maemo 3.x" instructions. Also, I'm unsure > whether I'm supposed to set up a Makefile.am script to ensure that > "something" gets done with the .desktop and .service files. Do these get > automatically recognised and dealt with, or do I have to tell the > installer what to do with them? You can list what your package installed with: dpkg -L If it doesn't list your application .desktop file under /usr/share/applications/hildon directory, there's nothing telling the Desktop that such an UI application exists (and what is its name, icon etc). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Making my app. appear on the Navigator menu
Hi, ext David Hazel wrote: > write a new application to maemo 3.x" instructions. Also, I'm unsure > whether I'm supposed to set up a Makefile.am script to ensure that > "something" gets done with the .desktop and .service files. Do these get > automatically recognised and dealt with, or do I have to tell the > installer what to do with them? You can list what your package installed with: dpkg -L If it doesn't list your application .desktop file under /usr/share/applications/hildon directory, there's nothing telling the Desktop that such an UI application exists (and what is its name, icon etc). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Making my app. appear on the Navigator menu
> The problem I'm having now is understanding what I'm supposed to do to > fix this. Having looked at all of the documentation I've listed above, I > began reading the How To titled "How to write a new application to maemo > 3.x". This appears to show a completely different folder hierarchy to > the one that is in the Hello World example. I've tried following its > instructions for creating a .desktop and .service file for my > application, and I've rebuilt my .deb package with these in place. All > I've managed to achieve so far, though, is make the right icon appear > next to the application in the Application Manager. I still don't get > the application's icon appearing anywhere in the Navigator, so I can't > fire it up to see if anything else works. > i suggest you convert the energy you put in writing those long emails into reading carefully http://maemo.org/development/documentation/tutorials/Maemo_tutorial_bora.html http://maemo.org/development/documentation/how-tos/3-x/howto_new_application_bora.html > My biggest problem is that all of the instructions I've read so far > insist on giving me examples, and I can't pick out which things are > relevant to me and which are not. The various Makefiles and so on list > all kinds of things that are clearly irrelevant to me, and I've no idea > how closely I have to stick to the folder hierarchy shown in the "How to > write a new application to maemo 3.x" instructions. Also, I'm unsure > whether I'm supposed to set up a Makefile.am script to ensure that > "something" gets done with the .desktop and .service files. Do these get > automatically recognised and dealt with, or do I have to tell the > installer what to do with them? (In which case, it would be nice to read > a proper explanation of what has to happen to them. Examples are fine if > they are directly applicable to what you are trying to do. If they > aren't 100% applicable, they are useless because they don't provide any > proper context for deciding what I need to do in my particular case.) > studying maemopad is a good exercise to understand what's going on (apt-get source maemopad), it worked for me. if you are unsure about the directory structure and you have no real reason to change it, then stick with the one suggested: this really eases reading the docs and tutorials. also, in the "Getting Application to Task Navigator Menu" section of the Maemo 3.x tutorial, it is explained that: "To make application visible in maemo Task Navigator it needs a Desktop file for the application. This file contains all the essential information needed to show the application entry in the menu, like name, binary and D-BUS service name. Name of the file should be [application].desktop and location in filesystem “/usr/share/applications/hildon/” "D-BUS service file is installed in “/usr/share/dbus-1/services/” and maemo GUI needs to be restarted with “af-sb-init.sh restart” before D-BUS daemon recognizes it." so, yes something has to be done with .desktop and .service files. This is the purpose of data/Makefile.am (see maemopad source distribution) if you are not familiar with Makefile.am files, please read about autotools and automake: http://www-src.lip6.fr/homepages/Alexandre.Duret-Lutz/autotools.html http://www.gnu.org/software/automake/manual/automake.html > Any offers of help? Or is this going to be another of my questions that > disappears into a black hole never to get answered? remember that help on the irc channel or the dev mailing list is provided by volunteers. "disappear into a black hole" ? from what i can recall, a lot of people on the mailing list helped you already. did you ever consider you were not asking the right way ? http://www.catb.org/~esr/faqs/smart-questions.html in any case, whining never helped. > I should add that I'm writing this application on behalf of a customer, > and from the outset neither of us were sure that the N800 was a good > platform to target. After all the difficulties I've had in finding > accurate and complete information, and the lack of response I've been > getting to the questions I've been posing on this mailing list, I'm > inclined to suggest to them that we were right, and that we should stick > to more mature technology in future. how does it help solving your problem with .desktop and .service files ? unfortunately, blaming the platform, the people behind it, and the community won't bring you more attention nor more help offers. > The N800 is an interesting piece of > kit, but without MUCH better documentation and properly integrated > development tools, it is too expensive to write for and more trouble > than it's worth. > welcome to the embedded world, no you're no more under windows sitting comfortably behind visual studio's brilliant debugger :) good luck ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-develope
