RE: Computerworld article
I notice that this is a US publication, so it's hardly going to be impartial regarding a non-US company, especially when they've got a home-grown, non-Microsoft-stable company (Apple) to talk about. In any case, this is probably the most difficult industry of all in which to make accurate predictions. Who really knows which piece of kit will really gain grass-roots support? Everyone hopes they've got the winning formula, but nobody knows for certain. David Hazel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tony Maro Sent: 29 September 2007 08:52 To: maemo-dev List Subject: Computerworld article Linked on Slashdot, so likely others have seen this already... http://www.computerworld.com/action/article.do?command=viewArticleBasic&ar ticleId=9039659 From the article: -- The Federal Communications Commission recently approved a new minitablet, nonphone device from Nokia that supports Bluetooth, WLAN and GPS. The approval was branded as "confidential," so only the sketchiest of details are available on the product, which will almost certainly ship this year. I'm not sure Nokia has the "right stuff" to compete in the nonphone market. For starters, the company has trouble focusing on individual products and tends to scatter its energy and resources across its massive line of devices. The future king of tiny mobile computers is going to need vision and focus. Go ahead and take Nokia off the list of contenders. -- Personally I think he's got it wrong. I've noticed with tech companies (including Microsoft) that "third time's the charm." I think Nokia has touched into the power users with the open-sourciness (hehe) of Maemo and gotten enough good feedback that the next revision will be a big hit. Adding GPS would be awesome if still economical, and if you guys listened to everyone about sync capabilities for contacts and such, there's no product that could really compete in my opinion. Although I think multitouch solid screens similar to the iPhone might be nice ;-) At least the solid part. I'm always afraid I'm going to damage my LCD. I mean let's be honest - I'd give up my RAZR in a heartbeat for a good old solid indestructible Nokia phone that doesn't misdial every time I call someone. The brand still carries a lot of weight for me. And I love my n800. -- Tony Maro http://www.maro.net/ossramblings.php ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Upcoming new maemo documentation and an introduction
I think the section on Development Environment should cover the following, in addition to the things that are listed: - Suggestions of IDEs to use (I use Geany, but maybe there are better ones) - Tools that are available for creating GUIs (I don't know any, so I've had to work out the positioning of widgets by a combination of hand calculation and trial-and-error). - Limitations of the emulator that runs under Scratchbox (e.g. it doesn't seem to include a Browser or a File Manager, so any applications that interact with those can't be fully tested except on the device itself) - The section on "Packaging, deploying and distributing" needs to be as self-contained as possible, with a proper description of how it all works and what is necessary. Examples are fine, but an up-front description of the principles will avoid the kind of runaround I'm having with trying to understand things like Automake which really aren't anything to do with Debian packages. Also, even though you say this is aimed at people with GNU/Linux experience, the section on Porting Software might benefit from some hints for people wanting to port Windows Mobile applications. Finally, I hope the sections on the architecture, system services and other system software will include information on the APIs and the C header files needed. I spent a lot of time simply working out what calls I needed and where they were declared. David Hazel > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Juha Tukkinen > Sent: 26 September 2007 10:57 > To: maemo-developers@maemo.org > Subject: Upcoming new maemo documentation and an introduction > > > Hello maemo developers! > > Information for you in advance: a completely new maemo > document intended > for new maemo developers, "Maemo 4 Quick Start Guide" will be > out in the > near future. The purpose of the guide is to be a starting point for > developing maemo applications for people with basic GNU/Linux > software > development background. No previous embedded or maemo programming > knowledge is required. > I would appreciate any feedback on its table of contents [1] > right now. > Is something crucial completely missing from your point of view? > > Also, revised and supplemented maemo Chinook documentation > (how-tos and > a tutorial) will be released in the very near future. > > I joined the OSSO team in Nokia this summer to help spread the maemo > message, hence the memorable title ;) Amongst other things, > I'm involved > with maemo documentation and the processes and tools of getting the > documentation better. A task I will need your help and ideas. > > - Juha T. / jtukkine > > P.S. Greetings to all the nice people I met at GUADEC'07! > > [1] > http://maemo4beginners.garage.maemo.org/maemo-quick-start-toc- 20070925.pdf -- __ Maemo Evangelist [EMAIL PROTECTED] Open Source Software Operations Multimedia ___ 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 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
Making my app. appear on the Navigator menu
I have my application written, and I've tested it and verified that it is working properly, so now I'm trying to build a package that will install under the Application Manager. I've read the Debian New Maintainers' Guide, and the How To titled "Making a package for the Application Manager in maemo 3.x", and downloaded the example Hello World application, and after a bit of trial and error I've managed to build a .deb package for my application. If I copy this to a memory card, and then insert this into my N800 and run it, the Application Manager recognises the package and successfully installs it. The trouble is, the application does not appear anywhere in the menu of available applications, so cannot be activated by the user. It's not listed under Web, or Contact, or Utilities, or Games, or Tools, or with things like Media Player or File Manager. Nor does it appear anywhere that File Manager can show me. 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. 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.) Also, do I need to write code to make my application integrate with the Navigator? I seem to remember reading something about some kind of calling interface, but it wasn't clear when I read it whether it was relevant to what I needed to do (and, in fact, I now can't find it among the various documentation pages). Any offers of help? Or is this going to be another of my questions that disappears into a black hole never to get answered? 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. 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. David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Creating a Debian package - clarifications required
I'm trying to follow the instructions in the "How To" section of the Maemo website, and I'm finding that there are several questions that don't seem to be addressed. I'm hoping that someone can answer these for me. 1. The application I'm packaging up is not intended to be built from source by users, but to be supplied "as-is" in binary form on a memory card (specifically for the N800). I am hoping that this means I don't need to supply a Makefile, but the instructions aren't clear on this point. Can I elect not to supply a Makefile if I don't intend to supply sources for the user to build the application? All I want the Application Manager to do, when it reads this package, is copy the binary and other files from the memory card to the right locations and do whatever else is needed to make the application appear in the navigator menu. 2. I originally started off with my source directory containing mixed upper and lower case letters, as well as the version number. However, db_make complained about this and I've now changed the directory name. Do I also need to change the names of the binary, icon file and desktop file to match? Again, this isn't clear from the instructions. 3. Does the application name used for the source directory need to correspond with the name by which the application will be known to OSSO? For example, if my source directory is abc-1.0.0, does this mean that OSSO will have to know the service as "abc.nokia.com" and that the OSSO application name will have to be "abc"? 4. Does the name of the icon file have to correspond with the name of the binary file in any way? For example, if it is a 26x26 icon, and the binary name is abc, does the icon have to be called abc_icon_26x26.png? This is kind of suggested in the documentation, but it isn't stated explicitly. 5. Will dh_make automatically uuencode the icon and place it in the control file, or do I have to manually run uuencode and copy the text in? Sorry for so many questions in one go, but my first attempt to follow the instructions didn't really clarify these points. David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Missing Hildon include files?
Thanks for the suggestion. Does the name I pass to dbus_bus_name_has_owner need to be "osso_browser", or OSSO_BROWSER_SERVICE, to determine whether the Browser is running? Is there any online documentation for the DBUS API? I was trying to pick my way through the include files the other day, for just this purpose, but the function names tell me almost nothing about what they do, and there are no comments in the header files to help me. I couldn't find any documentation for them. I wonder why the osso-manager.h function is documented among the rest of the Maemo APIs, if it is not intended for general use? There should at least be a note somewhere saying that it is for internal use. David Hazel -Original Message- From: Santtu Lakkala [mailto:[EMAIL PROTECTED] Sent: 20 September 2007 13:01 To: David Hazel Cc: maemo-developers@maemo.org Subject: Re: Missing Hildon include files? -BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Hazel wrote: > I appear to be missing some Hildon include files, and presumably the > libraries that go with them. In particular, I can't find osso-manager.h > in my development environment under Scratchbox, and I haven't been able > to find out where to get it from. Can anyone advise me where to find it? > I need to use the is_service_running function within my application, and > the include file for it isn't there. It is meant for maemo-af-desktop internal use. Use dbus_bus_name_has_owner[1] instead. [1]: http://dbus.freedesktop.org/doc/api/html/group__DBusBus.html#g9cf4ff79453e2e 11eab5b1d33395679b - -- Santtu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFG8mDlX9Rc0+po4p0RArZFAJ49mMGzWuOqyOR1w9y6CohcpOu3eQCfb7lU FUwa6DBK4GLP82upvm0UaII= =bFrt -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Second time of asking: hildon-desktop include file missing
I asked this question a couple of days ago and was completely ignored, so let's see if I have any luck this time around. I need to use the function is_service_running, but I appear not to have the include file osso-manager.h within my scratchbox/maemo development environment. Is this not a standard include file? What do I need to do to get it? I also appear to be missing whichever library contains the is_service_running binary. I tried getting around the lack of the osso-manager.h file by manually adding the declaration of the is_service_running function (taken from a copy of the header file that I found online). However, my application doesn't link because it can't find where this function is defined. The call I need is documented within Doxygen, under the API documentation for Hildon Status Bar, Home Applets and Navigator, but I can't see anything that describes any special actions I need to take to allow me to use these APIs. David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Another libosso bug?
The logic is comparable to what I'm doing. However, in my case I'm calling osso_application_top in response to a user clicking on a button on my application. When I first found it not working, it occurred to me that this might be because the fact that the button was being clicked at that point meant that my application was being forced to the front by the OS. To get around this, I placed the call to osso_application_top inside a callback function, which is activated by a 300ms timeout from the button-click routine. In other words, a 300ms timeout is triggered by the button click, and the callback routine that handles the timeout invokes osso_application_top to bring the browser to the front. However, it still doesn't work. This is why I asked whether there were conditions under which osso_application_top would not work. Presumably, if the application that calls it is in the process of doing something that makes it the top application, this would override the attempt to bring another application to the front. The problem is, I can't think of any other way to trigger such an event in response to a user action. By definition, this must be an action that does something to my application's window, which means my application has to be in front to deal with it. Any suggestions as to what might be going wrong? David Hazel -Original Message- From: Kimmo Hämäläinen [mailto:[EMAIL PROTECTED] Sent: 19 September 2007 12:39 To: ext David Hazel Cc: maemo-dev Subject: Re: Another libosso bug? On Mon, 2007-09-17 at 21:15 +0100, ext David Hazel wrote: > Within my application, I am trying to bring the browser to the front > in response to a certain user action. The call I am using is: > > osso_application_top(mvarAppCtx, "osso_browser", NULL); > > However, nothing is happening in response to this call. My application > remains visible, and the browser does not come to the front of the > display. The question is, am I using the above call correctly (in > particular, is the application name correct for the browser)? Are > there any restrictions on the circumstances where I can expect this > call to bring another application in front of mine? This works for me: - #include #include #include static GMainLoop *loop; int main(int argc, char* argv[]) { osso_context_t *context; loop = g_main_loop_new(NULL, 1); context = osso_initialize("toptest", "0.1", 0, g_main_loop_get_context(loop)); osso_application_top(context, "osso_browser", NULL); g_main_loop_run(loop); return 0; } -- BR, Kimmo > > > 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
Missing Hildon include files?
I appear to be missing some Hildon include files, and presumably the libraries that go with them. In particular, I can't find osso-manager.h in my development environment under Scratchbox, and I haven't been able to find out where to get it from. Can anyone advise me where to find it? I need to use the is_service_running function within my application, and the include file for it isn't there. David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Another libosso bug?
Within my application, I am trying to bring the browser to the front in response to a certain user action. The call I am using is: osso_application_top(mvarAppCtx, "osso_browser", NULL); However, nothing is happening in response to this call. My application remains visible, and the browser does not come to the front of the display. The question is, am I using the above call correctly (in particular, is the application name correct for the browser)? Are there any restrictions on the circumstances where I can expect this call to bring another application in front of mine? David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Possible libosso bug?
I encountered the following unexpected behaviour while testing my application, and I wanted to run it past the people on this list to see if this is a known "feature". My application opens the browser as part of its normal operation. On application exit, the browser is closed. The call used to do this is: osso_rpc_run_with_defaults(mvarAppCtx, "osso_browser", OSSO_BROWSER_EXIT, NULL, DBUS_TYPE_INVALID); Now, if the browser is open when this call runs, it closes down exactly as expected. However, if it has already been closed by the user, the above call OPENS it! Given that the call is telling the browser to exit, I would expect one of two things to happen if the browser is not open: 1) The call is ignored, because it is asking for a browser state that already exists 2) The call fires up the browser and immediately closes it (because the OSSO_BROWSER_EXIT request has to be dealt with by the browser itself). Instead, what actually happens is that the browser opens and stays open (on its default home page). Is this a known "feature" of libosso or the Browser? If not, should I report it as a bug? David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Trapping application "crashes"?
Is it possible for an application to trap abnormal termination? In other words, can a callback be registered that will be invoked when the application is about to be shut down because of an error that the application itself has caused (e.g. memory allocation errors or other problems that would cause the OS to terminate the application). David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Software on MMC cards & OSSO question
A few days ago, in a reply to a question I had posted, someone said that executable files could not be run directly from a MMC card because of those cards being mounted noexec. Can someone confirm whether this is correct? Is it possible to get the OS to mount these cards -exec? Or is the problem simply that FAT-formatted devices don't support the "executable" attribute? My second question is to do with the OSSO library. I am using the call osso_rpc_run_with_defaults to open the browser. The Doxygen documentation says that this call is "blocking", which I take to mean that control should not return to my application until the browser is closed. However, I am finding that control returns immediately, and does not block my application. Is this a bug in OSSO, or have I misunderstood what the "blocking" refers to? Ideally, I really need my application not to continue past the invocation of the browser until the latter is closed by the user. Failing that, I need to be able to embed a browser in my application. David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Finding the mmc cards
I'm interested to hear that anything outside of the SD card has a choice in the matter. There was a time when hardware write-protection of this kind was exactly that: harware-enforced write-protection. I would have expected that, if I put the switch on an SD card into the "write-protected" position, the card itself would disable or ignore write operations (by, for example, disabling whatever line/signal is used to perform the write operation). David Hazel On 8/29/07, David Hazel <[EMAIL PROTECTED]> wrote: - whether write protected (yes, you can write-protect an SD card) Yes, but the Nokia's do not support or honor that switch. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Finding the mmc cards
> You can also use the environment variables MMC_MOUNTPOINT and > INTERNAL_MMC_MOUNTPOINT, but then you have to make sure that they are > always set correctly in your environment. (I don't think using > environment variables for this kind of system information is a good > idea.) Those environment variables seem oddly inconsistent to an ex-VMS man like me. Why not EXTERNAL_MMC_MOUNTPOINT and INTERNAL_MMC_MOUNTPOINT? Otherwise it's necessary to remember which one the unqualified MMC_MOUNTPOINT refers to (e.g. by remembering that the other one starts with INTERNAL rather than EXTERNAL - which itself is counter-intuitive, as I would expect the internal one to be the more "important" and therefore the unqualified one). I also picked up on Tony's reply regarding the way in which /dev/mmcblk0 and /dev/mmcblk1 seem to be reversed in semantics with respect to the cards they relate to. With these two examples of inconsistency in card mappings, it seems all the more important to me that some kind of API is provided that can enumerate the cards with certainty (and with logical/naming consistency, please!) and can determine a range of useful information about the cards. Here are some ideas for the kind of information such an API might want to be able to retrieve: - serial number - capacity - whether FAT16 or FAT32 formatted - mountpoint - device file name - whether write protected (yes, you can write-protect an SD card) David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Finding the mmc cards
I've added bug #1930. I hope I've done it right, because even that procedure isn't particularly clear. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Eero Tamminen Sent: 29 August 2007 10:40 To: ext [EMAIL PROTECTED] Cc: maemo-developers@maemo.org Subject: Re: Finding the mmc cards Hi, Please file a documentation bug into Maemo Bugzilla. We need this documented. Handling of removable medias, especially with file systems as easily corrupted as FAT, needs special care from applications (stop using files when pre-unmount message is delivered on them so that unmounts succeed, do better error handling etc.) - Eero ext [EMAIL PROTECTED] wrote: > I agree that assuming mmc1 and mmc2 is potentially dangerous. In an answer to my > original question on this subject, someone suggested that mmc0 and mmc1 were the > correct names, whereas in my Scratchbox environment they are mmc1 and mmc2. > Consequently, when I was implementing a scan for memory cards, I opted to look > in the /media folder for files whose names begin "mmc", and to assume that any > such file I find might be a memory card. This appears to work (in the > test/development environment), but personally I hate making those kinds of > assumptions. I would far rather have a definitive statement from someone to the > effect that "if you do X, this will guarantee to find the memory cards and > nothing else". For me, this is particularly important, as my application will be > sold commercially and needs to work under all circumstances. > > > David Hazel > > > > After our thread some weeks ago regarding reading the serial number from a > MMC card, I've since implemented detection of the MMC card's presence by the > existence of those same files. I know my solution works on my device perfectly. > > I figure it's probably a bad decision, because the architecture could change > somewhat with the next hardware or software release. > > Can someone tell me, is there an approved / documented way of identifying the > location of any MMC cards currently installed? I've noticed you can't simply > look for /media/mmcX because that directory will exist even if there is no card > inserted. > > Also, what determines MMC1 vs MMC2 as the card's path for internal/external? Is > it possible these paths would change at some date? I know some Linux distro's > with SATA drives had a problem with the drives changing their /dev/sdX path > every reboot. I know that MY Nokia isn't doing anything similar, but I figure > it's possible that my /media/mmc1 might be internal, but for someone else it > could be the external slot - or maybe in the next hardware revision or something. > > I did find the alias names located in the /sys/ path that specify "internal" is > for one and "external" or removable or something for the other. Also, are the > names and paths the same for the 770's? Since I have an n800 I don't know. I'm > hesitant to read too much data from /sys/ because it all looks _so_ > Maemo-specific I wonder if I will tie my code too closely to one hardware revision. > > Just looking for the most _compatible_ way to identify if/when and where a media > card is present. > > And as usual, from Python. > > Thanks, > Tony ___ 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: General Maemo/Scratchbox/N800 help
Some people seem to have issues that completely corrupt beyond repair a MMC card and it seems to be possibly tied to using the USB cable to transfer files to/from your PC and the MMC card in the Nokia. It's possible that cards experiencing this problem are not completely corrupted "beyond repair", but that they've simply had their FAT tables damaged to the point where most software can't deal with them. FAT32 devices seem to have a particular problem, in that if certain elements of the FAT table get corrupted, they appear to be completely unusable. This kind of damage can be repaired using the Disk Manager on Windows XP or 2000. If you use this to reformat such a device, it will come back to life quite successfully (but be prepared for a bit of a wait while the Disk Manager decides that the device is not properly formatted and that it can't therefore show its current format). David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Finding the mmc cards
I agree that assuming mmc1 and mmc2 is potentially dangerous. In an answer to my original question on this subject, someone suggested that mmc0 and mmc1 were the correct names, whereas in my Scratchbox environment they are mmc1 and mmc2. Consequently, when I was implementing a scan for memory cards, I opted to look in the /media folder for files whose names begin "mmc", and to assume that any such file I find might be a memory card. This appears to work (in the test/development environment), but personally I hate making those kinds of assumptions. I would far rather have a definitive statement from someone to the effect that "if you do X, this will guarantee to find the memory cards and nothing else". For me, this is particularly important, as my application will be sold commercially and needs to work under all circumstances. David Hazel After our thread some weeks ago regarding reading the serial number from a MMC card, I've since implemented detection of the MMC card's presence by the existence of those same files. I know my solution works on my device perfectly. I figure it's probably a bad decision, because the architecture could change somewhat with the next hardware or software release.Can someone tell me, is there an approved / documented way of identifying the location of any MMC cards currently installed? I've noticed you can't simply look for /media/mmcX because that directory will exist even if there is no card inserted. Also, what determines MMC1 vs MMC2 as the card's path for internal/external? Is it possible these paths would change at some date? I know some Linux distro's with SATA drives had a problem with the drives changing their /dev/sdX path every reboot. I know that MY Nokia isn't doing anything similar, but I figure it's possible that my /media/mmc1 might be internal, but for someone else it could be the external slot - or maybe in the next hardware revision or something. I did find the alias names located in the /sys/ path that specify "internal" is for one and "external" or removable or something for the other. Also, are the names and paths the same for the 770's? Since I have an n800 I don't know. I'm hesitant to read too much data from /sys/ because it all looks _so_ Maemo-specific I wonder if I will tie my code too closely to one hardware revision. Just looking for the most _compatible_ way to identify if/when and where a media card is present.And as usual, from Python.Thanks,Tony ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Support to non-Linux developers (was Re: GeneralMaemo/Scratchbox/N800 help)
>The good news is that we are getting an increasing interest from >developers with a background strong in mobile development but not >specifically on Linux. > >On Tue, 2007-08-28 at 00:43 +0200, ext koos vriezen wrote: >> Hm, maybe we should start a Wiki page 'Getting started with Linux >> using N880/N770' ... > >Any help in this direction is welcome, starting with the own non-Linux >developers reporting and documenting the main issues they encounter. > >From my perspective, there have been two distinct areas where I've needed help: 1. Linux development in general. There is some documentation out there, especially regarding GTK+, Gnome and GLib, but it doesn't appear to be 100% documented, it isn't easy to find the documentation on some calls (e.g. GLib versions of standard things, such as g_free(), etc.), and what documentation does exist doesn't appear to start from a high-level overview of what the thing (i.e. GTK+, Gnome or GLib) actually does or how its various function groups are intended to be used. 2. Maemo in particular (or Scratchbox, or Hildon - I'm still not clear on the distinction between these, as there is no single place where they are all discussed and compared). It took me ages even to find the HTML pages that describe the Hildon API, and even then it was incomplete. I'm still under the impression that many areas of interaction with the N800 are under-supported from an OS/API point of view (for example, is it possible, with a simple set of calls, to get an enumerated list of memory cards, so that one can scan them to see which one contains which files or obtain other information about them?) Maybe this impression is wrong, but if so it's because I haven't yet found any documentation that tells me otherwise. It would also be useful to have a list of areas where the Scratchbox emulator currently does not implement all of the features on the N800. I'm finding, for example, that my Scratchbox doesn't provide the full set of applications that are present on my N800 (e.g. there is no Connection Manager, and no File Manager). (By the way, on the question of semantics, the Scratchbox thingy IS an emulator, even though it is running the same software as the N800. It doesn't have the same hardware environment as the latter, so it has no choice but to simulate this in software. This kind of environment is universally referred to as an emulator, or a simulator, in software engineering circles.) Finally, I'm finding that there is an over-reliance on 'examples' (which really seems to mean endless reams of other people's code) rather than proper descriptions of how things should be done. I've spent 24 years of my professional life reading other people's code. It's tedious, error-prone, and always open to the question "just because they've done it like that, does that mean this is how it's supposed to be done?" It's also a lot more time-consuming to read such code and work out how it relates to ones own requirements than to read a proper description (with small code examples if that helps illustrate things). I realise it's harder to WRITE the proper description than just do a brain-dump of ones own code, but it's certainly more helpful to the newcomer. >We are starting to produce official documentation targeting developers >with different backgrounds than Linux to help them land in the maemo >context. These docs will be included in the maemo 4.0 release. For ideas on what is needed, have a look at some of the published books on, say, WinAPI or Java. Alternatively, look at how Apple do it with the documentation they've produced for Mac OS X. The latter is a supreme example of well-written, carefully-crafted documentation (and, in fact, of a thoroughly well-engineered operating system and associated software technologies). Yes, there's an awful lot of it, but it's better to have that than too little. If the answer to the last point is that 'free' documentation of that quality simply can't be produced on a part-time basis, well, I'm open to suggestions. I often write in my spare time, and I have a colleague who specialises in writing text books on various computing themes (his name is Nat McBride - look him up on Amazon). I also have a window opening in my availability after 7th September. Maybe Nokia would be prepared to fund someone to write some suitable documentation? After all, it would be in their interests for the wider developer community to be up to speed on this technology (otherwise it will die a death through lack of support). If anyone from Nokia is interested in this suggestion, and wants to take it further, let me know. I'd be happy to discuss things in more detail. David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: General Maemo/Scratchbox/N800 help
Sorry, Ross, I'm being a pain, I know, but: >Open the .install file on the N800, and Application Manager will open >and install it for you. I assume this means that I need internet connectivity on my N800. I haven't yet found out how to achieve that - I haven't found a way of making it connect via the USB link through my PC (it seems to think that my NTL broadband connection is a BTHomeHub-C38B, whatever that is, and prompts me for a WEP key, whatever one of those is; it certainly doesn't try to connect transparently through the PC). My belief that I couldn't connect to the internet from the emulator was based on a reply I received to a question I posted a couple of days ago. Someone said this was something that would only work from the N800, not from the emulator. Also, my belief that memory cards could not be emulated was based on something I saw on a website (possibly the Maemo one) that suggested MMC cards were not emulated at present. If I copy the resolv.conf file from my Linux PC into the Scratchbox area, will this give me connectivity? How do I go about using my USB card reader to let Scratchbox emulate a memory card? Also: >Copy the file to the home directory and chmod +x it. How do I do chmod (and, in fact, what constitutes the home directory on this beast)? I haven't found anything resembling a command line on my N800, and the File Manager doesn't seem to provide that level of control over file attributes and locations. David Hazel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ross Burton Sent: 26 August 2007 12:31 To: maemo-developers@maemo.org Subject: RE: General Maemo/Scratchbox/N800 help On Sun, 2007-08-26 at 11:09 +0100, David Hazel wrote: > >I put the executable on the memory card, copy it to my home directory > >and run it. You'll need xterm on the 800 to do this. > > Question 1: How do I get a version of xterm that will run on the N800? > Question 2: How do I install it to the N800? > > I'll need fairly detailed instructions for each of the above, I'm afraid. I > did try to download what purported to be an Openssh client for the N800 > yesterday, but all I got was a file called openssh-client.install, and no > clues as to what I was supposed to do with it. Open the .install file on the N800, and Application Manager will open and install it for you. If you read the .install file in a text editor you'll see that it just specifies repositories and package names. The dropbear ssh client/server and a terminal are available from maemo-hackers.org. Open the install file under "bora/it2007" at http://maemo-hackers.org/wiki/OssoXterm on your N800 and the terminal will be installed. Then in Application Manager you can install the dropbear client and server. > I did once try putting my executable onto a memory card. However, I wasn't > able to run it even though I thought I had built it for the right target > (which is ARMEL, I assume?) and the version I built for X86 runs (almost) > fine on Scratchbox. I believe memory cards are mounted noexec, and are vfat anyway. Copy the file to the home directory and chmod +x it. > (I say "almost" because the emulator doesn't appear to > be all that close an emulation of the target environment. It apparently > can't simulate the presence of memory cards or give me an internet > connection, both of which are central to what my application is trying to > do.) You can get to the internet from inside a scratchbox, you probably need to fix /etc/resolv.conf. It defaults to 127.0.0.1 which is wrong unless you run a local name server or cache. Memory cards are just mounted file systems, you can simulate those exactly by using a USB card reader. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF ___ 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: General Maemo/Scratchbox/N800 help
Hi Tony, Thanks for your suggestion. I'll have a look at the instructions you pointed me at. One question, though: why do I need to fiddle about with public/private keys? I only want to be able to interact directly with my N800 via a USB link, so there's no one else likely to be peeping at the link while I'm doing it. I don't really care about encrypting files as they go across. Also, isn't there a way of "logging in" directly to my machine across the USB link and simply typing shell commands (say, via telnet)? Does my N800 have a particular host name when it is connected? I've played around with 'flasher' and found out how to put my N800 into "R&D mode" and "USB host mode", and flasher can obviously communicate with it. Having got it into host mode or R&D mode, is there no way for me to talk to it directly from a command line? (I'm fine with Unix/Linux shell commands; it's all the other faffing about that's defeating me at the moment.) David Hazel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tony Green Sent: 26 August 2007 10:52 To: maemo-developers@maemo.org Subject: General Maemo/Scratchbox/N800 help > Date: Sat, 25 Aug 2007 18:03:41 +0100 > From: David Hazel <[EMAIL PROTECTED]> > Subject: General Maemo/Scratchbox/N800 help > To: maemo-developers@maemo.org > > - transferring files etc. to the N800, for example to test software > > I put the executable on the memory card, copy it to my home directory > and run it. You'll need xterm on the 800 to do this. Perhaps I could suggest Openssh as an easier solution? (especially if like me you don't have a card reader for your desktop machine) It's available on the Maemo repository, though it's a bit fiddly to install because you have to enable "red pill" mode on your device (there are instructions on how to do this at http://www.gossamer-threads.com/lists/maemo/users/26247) Once you've set up public/private key-pairs, copying files between machines is a simple one-line command. ...and handily, having ssh on the tablet provides a way of getting root on it, since "su" doesn't play simply issue "ssh -l root localhost" Then give it the root password when it prompts you (I can't remember what it is, but Google will find it). -- Tony Green Ipswich, Suffolk, England http://www.beermad.org.uk http://no2id-ip.web-brewer.co.uk ___ 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: General Maemo/Scratchbox/N800 help
Hi Frank, Thanks for your answers. There's one that I'll need further help with, however: >I put the executable on the memory card, copy it to my home directory >and run it. You'll need xterm on the 800 to do this. Question 1: How do I get a version of xterm that will run on the N800? Question 2: How do I install it to the N800? I'll need fairly detailed instructions for each of the above, I'm afraid. I did try to download what purported to be an Openssh client for the N800 yesterday, but all I got was a file called openssh-client.install, and no clues as to what I was supposed to do with it. I did once try putting my executable onto a memory card. However, I wasn't able to run it even though I thought I had built it for the right target (which is ARMEL, I assume?) and the version I built for X86 runs (almost) fine on Scratchbox. (I say "almost" because the emulator doesn't appear to be all that close an emulation of the target environment. It apparently can't simulate the presence of memory cards or give me an internet connection, both of which are central to what my application is trying to do.) David Hazel -Original Message- From: Frank Banul [mailto:[EMAIL PROTECTED] Sent: 25 August 2007 19:40 To: David Hazel Cc: maemo-developers@maemo.org Subject: Re: General Maemo/Scratchbox/N800 help Hi David, I started working with the 770 a month or so ago so I don't have all the answers but I'll give a few below a shot. On 8/25/07, David Hazel <[EMAIL PROTECTED]> wrote: > - interacting with the N800 device itself from my Linux PC I didn't find the need to do this. Using scratchbox to develop was enough. So far, only one problem has appeared on the tablet and not in scratchbox. > - understanding 'flasher' (in particular, what the "R&D mode" and "host > mode" actually do and how to make use of them) I didn't find a need for these at all, I still don't have root on my 770. > - transferring files etc. to the N800, for example to test software I put the executable on the memory card, copy it to my home directory and run it. You'll need xterm on the 800 to do this. > - knowing what commands are available in Scratchbox to help me with the > development, deployment and testing of software Here is my cheat sheet. How to build: ./autogen.sh automake ./configure dpkg-buildpackage -rfakeroot -b How to run outside of scratchbox: /scratchbox/start-xephyr.sh & To start scratchbox: /scratchbox/login inside of scratchbox: export DISPLAY=:2 af-sb-init.sh start run-standalone.sh To change targets: sb-menu To install in emulator: fakeroot dpkg -i maemo-soundbridge_0.1_i386.deb Hope this helps. Frank ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
General Maemo/Scratchbox/N800 help
I've been trying, for 3-4 weeks now, to develop some software in my spare time for the N800 device. However, I'm fairly new to Linux development in general, and completely new to Maemo/Scratchbox. I'm having a general problem with finding out how to do basic things such as: - interacting with the N800 device itself from my Linux PC - understanding 'flasher' (in particular, what the "R&D mode" and "host mode" actually do and how to make use of them) - transferring files etc. to the N800, for example to test software - knowing what commands are available in Scratchbox to help me with the development, deployment and testing of software The problem seems to be that such documentation as exists often appears to jump into the explanations halfway through, without catering for people who aren't members of the "Linux/Maemo developers" clique. There are often disclaimers to the effect that readers are assumed already to be familiar with X, without saying what to read if one isn't familiar with X. Even when pointers exist, they are often in the form of vaguely worded descriptions that don't produce anything useful when typed into Google. Some documentation is even at the level of header comments, which are only useful as reminders if you already know how to do things. Now it may be that everything is fully documented, and that the documentation is available somewhere online. The problem I'm having is finding it (or even finding out whether it exists, in many cases). So, can anyone help me? I need to find out where I can look, either online or in published books, to find out how to proceed. Answers to the points listed above would be an excellent starter. I have lots of software development experience, on many operating system platforms, so I certainly don't lack the skills to do what I'm trying to achieve. Unfortunately, not much of my experience has been on Unix or Linux, and I'm finding these to be pretty impenetrable to someone who doesn't have a-priori Unix knowledge. Thanks in advance for any pointers that anyone is able to give me. David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Browsing and opening URLs from within a C application
I'm trying to do two things that I would expect to be very simple on a device as internet-enabled as the Nokia N800, but it's proving almost impossible to find any documentation that tells me how to go about doing either of these things. Firstly, I need to be able to open a URL and read (programmatically, in C) the HTML text that is returned by it. I'm currently trying to do this with code similar to the following (which is trying to retrieve the required text in the variable actText; url contains the URL that I want to open): gchar *actText = malloc(); GnomeVFSURI *uri = gnome_vfs_uri_new(url); GnomeVFSHandle *gfh = NULL; ... ConIcConnection *inConn = con_ic_connection_new(); g_signal_connect(G_OBJECT(inConn), "connection-event", G_CALLBACK(inConnCallback), NULL); if (con_ic_connection_connect(inConn, CON_IC_CONNECT_FLAG_NONE)) { /* wait for "connection-event" to be flagged by callback function */ if (connected) { GnomeVFSResult gres = gnome_vfs_open_uri(&gfh, uri, GNOME_VFS_OPEN_READ); if (gres == GNOME_VFS_OK) { GnomeVFSFileSize count = 0; gres = gnome_vfs_read(gfh, actText, buffSize, &count); if (gres != GNOME_VFS_OK) { /* deal with error */ } gres = gnome_vfs_close(gfh); } else { /* deal with error */ } con_ic_connection_disconnect (inConn); } } I've tested this code on the emulator on my development system (but not on the N800 itself). It is failing even to connect after the con_ic_connection_connect call (it times out without the appropriate callback handler ever receiving the "connection-event"). If I remove all of the "conic" connection logic, the gnome_vfs_open_uri call fails with a "Host not found" error. The questions are: (a) am I using the right calls above to enable me to open the URL? and (b) if not, what should I be doing? Should I be using something other than the "con_ic" and "gnome_vfs" functions? Secondly, I would like to be able to embed a browser within my application, so as to provide the user with a means of viewing local HTML content. I came across a vague reference somewhere to Mozilla which seemed to imply this could somehow be embedded within an application, but I couldn't find anything that told me how. (In fact, I even noted down "libgtkembedmoz.so" in connection with this, but couldn't find any references to the header files that might tell me the functions to use for it.) Any ideas? Is it possible to embed a browser within an application (by which I mean add a widget to my application window that can load and render HTML documents)? In hopeful anticipation, David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Obtaining flash memory serial numbers on Nokia N800
Tony, Thanks for the reply and for re-posting my question to the list. I'm replying to "all" so that this goes to the list, too. Regarding the "cat X" info that a couple of people have mentioned, the problem I was having here is that it seemed to presume that I know a-priori which device I need to incorporate into the path to get what I want. I won't know this without first being able to determine which device a particular (persistent) file is sitting on. Hence the first part of my question. I think your suggestion about df may give me what I want. I suppose I was expecting there to be something analogous to Mac OS's IOKit (which has functions that do exactly the filename-to-containing-device translation that I've described). Sorry about the capitals. I'm aware of the connotations with shouting, but I couldn't think of any other way of emphasising how I need to be able to get the information I'm after (and I only capitalised the relevant words). Some of the earlier replies read as if people thought I wanted to see the serial number from a command line, rather than programmatically. > That's Linux 101, but certainly is alien to anyone who has done Palm, PocketPC or Windows development. And to ex-VMS programmers ;-) Actually, what's most alien is the amount of hunting around that seems to be needed to find out how everything needs to be done on the N800 specifically (as opposed to Linux in general). The real "how to do it" developer information seems almost nonexistent when it comes to the specifics of Maemo/Nokia N800. No other platform that I've ever programmed for (and there are many, going back over 24 years) has been so couched in mystery. (Where, for example, is the documentation - as opposed to just header comments - for the Hildon APIs? I haven't found any yet. Even the GTK+ and GLib stuff is little more than header comments with a few extra bits of description tacked on. There's very little proper top-down documentation that I've been able to find.) Thanks for the info you've given me so far, anyway. David Hazel -----Original Message- From: Tony Maro [mailto:[EMAIL PROTECTED] Sent: 12 August 2007 20:01 To: David Hazel; maemo-developers@maemo.org Subject: Re: Obtaining flash memory serial numbers on Nokia N800 On 8/12/07, David Hazel <[EMAIL PROTECTED]> wrote: OK, so far I haven't had a reply that really answers my original questions, so let me rephrase them: I'd tend to disagree, but let's go on ;-) 1. Given a full directory path, how can I determine FROM WITHIN AN APPLICATION which storage device (memory card) this corresponds with? In other words, starting with something of the form "/dir1/dir2/dir3/file", how can I identify the storage device that this resides on? Well, that one would best be determined by reading the output of df or mount I would think. Because the Linux file system is so flexible, there may not be an actual "device" associated with a given path. Some of the paths in the file system are actually output from running applications. Others might be mounted across the network using any number of network file systems. For instance, the /proc directory doesn't really exist on a Linux hard drive so much as is output by a program running on the machine. So when you say you want to "find which storage device a path corresponds with" there may not be an answer because the question is wrong. Read on for more info... 2. Having found the above, how can I then find that storage device's serial number? (Again, FROM WITHIN AN APPLICATION) Um, actually that was the answer everyone provided. No need to yell - that's generally what gets most Linux advocates bristling and starts flame wars. Just read the text file at the specified location. Where we said "cat XX", cat was just meaning dump the contents of that file to the console, so you could just open that file like any text file and read the serial number out of it. That's Linux 101, but certainly is alien to anyone who has done Palm, PocketPC or Windows development. So in Python for instance, you might do: mypath = '/sys/devices/platform/mmci-omap.1/mmc1*/cid' srcfile = open(mypath,'r') myserial = srcfile.readline() srcfile.close() # tada! no need for any include's either. Nice and simple. You can use the same method to find the type of processor in the device, how much memory card space is in use, and untold many other tidbits of cool information. Keep in mind, Linux aka Unix was originally designed around everything communicating to each other through what is basically console I/O. It's a really neat system when you think about it. This means there's no special API that needs written or header files that must be available for
Re: Obtaining flash memory serial numbers on Nokia N800
On Fri, 2007-08-10 at 22:52 +0300, Igor Stoppa wrote: > I don't know about MMC/SD (isn't that something that is not public > available?) I would hope that the serial number of an SD card can be read on the Nokia. It can certainly be read from an SD card that is installed on a Windows Mobile device. Thanks for the pointer to the Samsung website. I'll see what I can find from there. David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Obtaining flash memory serial numbers on Nokia N800
I've been trying, without success, to find some documentation that will tell me how to go about reading, from within an application, the serial number for any of the storage memory in an N800. What I need to do is, given a directory path: - Determine which storage memory this corresponds with (whether it be the built-in memory, or an SD card in either of the memory slots that are available) - Obtain the serial number of that memory device, if it has one (or determine that it hasn't got a serial number, if this is the case). Can anyone suggest how I can do this? David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Post-installation problem with starting Maemo system
I've been through the process of installing Scratcbox and Maemo 3.1, and updating the latter to Maemo 3.2. Using section 4.2 of the INSTALL.txt notes, I also successfully installed Xephyr and was able to start the Xephyr server and execute the af-sb-init.sh start command in Scratchbox to get the Application Framework running in the Xephyr window. However, since then I have closed down my system and re-started it. I am now in the process of working through the Maemo Tutorial, and I've created and built the Hello World example in the Quick Start section. Now I'm trying to run the command "af-sh-init.sh start" in Scratchbox; except that, this time, the command does not work. Here is what I am seeing: [sbox-SDK_X86: ~] > af-sh-init.sh start bash: af-sh-init.sh: command not found So why is it that the command worked fine just after I'd installed everything, but now the system has no idea what I'm asking it to do? Is there something I'm supposed to do to ensure that the system retains a knowledge of this command? If so, what? Incidentally, I did a search, using find, to locate any files called af-sh-init.sh, and I found nothing. Regards, David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Errors while installing Maemo3.1 on Debian Linux
I'm trying to install the Maemo 3.1 SDK on Scratchbox under Debian Linux, and I am getting errors at step 3.3 in the installation guide: [sbox-SDK_X86: ~] > fakeroot apt-get install maemo-explicit (lots of stuff that seems to have worked, then:) Setting up maemo-explicit (3.0) ... W: Couldn't stat source package list http://repository.maemo.org bora/free Packages (/var/lib/apt/lists/repository.maemo.org_dists_bora_free_binary-i386_Packages) - stat (2 No such file or directory) W: Couldn't stat source package list http://repository.maemo.org bora/non-free Packages (/var/lib/apt/lists/repository.maemo.org_dists_bora_non-free_binary-i386_Packages) - stat (2 No such file or directory) W: You may want to run apt-get update to correct these problems The above happens for both SDK_X86 and SDK_ARMEL. In both cases, my sources.list contain the following: deb http://repository.maemo.org/ bora free non-free deb-src http://repository.maemo.org/ bora free deb file:/home/david/maemo-sdk-nokia-binaries_3.1 bora explicit Can anyone suggest why the error is occurring, and what I need to do to correct it? Is there perhaps something wrong with the placement of the files on the repository.maemo.org site? This certainly seems to be what the installer is complaining about. (In fact, I had a similar problem when I was trying to install Scratchbox. I had to download the files to my local system manually, adjust their relative placement in relation to the Packages.gz file, and then install from my local path.) I don't know whether it is related, but I had problems with the download of the Maemo 3.1 files from the website. I was able to download the release notes and installation instructions, but my attempt to download the SDK installer script failed on my Debian Linux system. However, I was able to download the script from my Windows XP system. I'm fairly new to Linux development, although I do have lots of experience (about 24 years!) of software development on many operating systems. Regards, David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers