Active Topics
-
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 1 day, 4 hrs ago -
TLS 1.2 for N9 is ready (28)
to MeeGo / Harmattan by smartblu9 - 1 day, 5 hrs ago -
Maemo repository (3)
to Community by torsen - 1 day, 21 hrs ago -
Error after installing Leste on sdcard (11)
to Maemo 7 / Leste by Maemish - 2 days, 19 hrs ago -
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 4 days, 1 hr ago - more...
|
2009-12-15
, 05:57
|
|
Posts: 25 |
Thanked: 30 times |
Joined on Dec 2007
@ Helsinki, Finland
|
#22
|
Originally Posted by VinceC
I could not agree more. I just cannot understand why Nokia is not able to do same than other with these api's. Somehow I thought that Maemo could be even more open and visible platform than others, but again it seems that Google is able to deliver more visibility inside of Android.
Quite a few of us are much more interested in low level documentation then high level documentation. Publish driver code, publish gsm modem commands, fully document gstreamer, dbus, etc.
I also courage Nokia to think beyond 'game and demo scene', where applications can do real life tasks and deliver a direct benefit to wider range of users. For example, if someone now asks from us what would be neat device to explore wifi frequency band in installation planning phase, my initial thoughts turns to Android and nice wifi scanning and visualisation programs available for it.
Nothing wrong with omweather at maemo front page, but hey guys - we can deliver so much more.
Last edited by ppafin; 2009-12-15 at 06:00. Reason: Added last sentence
 |
|
2009-12-15
, 06:08
|
|
Posts: 101 |
Thanked: 129 times |
Joined on Oct 2009
@ Los Angeles, CA
|
#23
|
Originally Posted by VinceC
Part of the problem is that currently Maemo used so many 3rd party libraries, such as Gstreamer, PulseAudio, etc. Those programming document are already out there but difficult to centralize. Nokia can not just copy those documents over the site since there is copy-right issue.
Quite a few of us are much more interested in low level documentation then high level documentation. Publish driver code, publish gsm modem commands, fully document gstreamer, dbus, etc.
We'll use the high level apis if we can, and the low level ones if we need to...
Same problem exists in Linux distribution, same issue plagues the Maemo.
However, if you look at 'Android' like document, I encourage you look at Qt. While not all system functions are fully supported in via Qt, such as BlueZ, audio, telephony, etc, but it's getting closer.
For people like me already writing Linux code for almost a decade, we have already memorized most package / libraries name. But Nokia should never forget those new-blood programmers are the ones who are able to drive the world.
|
|
2009-12-15
, 06:08
|
|
Posts: 25 |
Thanked: 30 times |
Joined on Dec 2007
@ Helsinki, Finland
|
#24
|
Originally Posted by bbns
I think Nokia needs to hire some reality check engineers. What I've found out in our business is that if there is no feedback to developers from segment you're providing solutions - there is no future for you. This forums is of course good solution to hear what people think about all this and it is a good way to collect information back. But nothing replaces a front deployed engineer in this business.
Both Android and Apple have 'Document Engineer' positions just do 'API' document. Nokia have software engineers do both the same job.
It doesn't mean Nokia should hire more 'Document Engineers'. Nokia already have lots of good coders but lack of management. If you have done reverse engineer, you could see the code are all not bad. And most of them are well written.
|
|
2009-12-15
, 06:14
|
|
Posts: 101 |
Thanked: 129 times |
Joined on Oct 2009
@ Los Angeles, CA
|
#25
|
Originally Posted by ppafin
For some reason Maemo is not a very big team (or Nokia is yet to ready to provide software service). I can count how many people from Nokia active within this forum.
I think Nokia needs to hire some reality check engineers. What I've found out in our business is that if there is no feedback to developers from segment you're providing solutions - there is no future for you. This forums is of course good solution to hear what people think about all this and it is a good way to collect information back. But nothing replaces a front deployed engineer in this business.
But I believe Nokia is getting changed but the organization is just too big. If you look at Nokia SW department (or Qt), they responds very fast and they have pretty good front end to reach different segment of developers.
|
|
2009-12-15
, 09:30
|
|
Posts: 432 |
Thanked: 645 times |
Joined on Mar 2009
|
#26
|
Originally Posted by ppafin
Of course feedback is highly appreciated. we are working on improving the documentation and figuring out how we can do it. In Barcelona we had an event with a documentation track including lots of discussions with the developers. So this kind of critical feedback is always welcome.
First, I am impressed that this topic gained at least some attention and it's great to see so many responses and even from parties who probably can guide this platform forward with mandate.
Originally Posted by ppafin
Therefore you could use the telepathy framework. A collection of links you can find in my previous post + telepathy glib API docs. Anyway it is not really easy to do that, but we are working on a detailed example, which will be available in the not too far future. Stay tuned to that.
I could not find any information how to build GSM network awareness, short message communication
Originally Posted by ppafin
There is a high-level API called gdigicam, with an example on how to use that. Further here you find some background information about the camera usage with gstreamer.
how to access camera
Originally Posted by ppafin
Here is the location API, and there is the description.
gps,
Originally Posted by ppafin
The accelerometer you can use on two different ways: DBus and sysfs. There is an overview in the wiki.
accelerometer
Originally Posted by ppafin
bluetooth is part in of the connectivity components, documented in the developer guide.
or bluetooth.
In general I don't know if you have seen the developer guide and the API refs, but I think there you should find a lot of answers to your questions. In your comparison you are basically linking to the anroid API docs. As in the Maemo case many different projects are used, it is not as simple to provide a compact API with references back and force. And the bada project. If you prefer pdfs over the wiki, ok, that's one opinion. In general we know that the documentation needs improvement and we are happy about developer feedback. So check the links out I've posted and ask more detailed questions if they are coming up and we will try to help you with that.
Cheers Daniel
|
|
2009-12-15
, 10:04
|
|
Posts: 187 |
Thanked: 345 times |
Joined on Nov 2009
|
#27
|
I don't know about Android or iPhone docs, but I must say I find the Qt API to be absolutely brilliant. Everything is there, it's detailed, it contains loads of how-tos, the introductions are very comprehensible.
The maemo APIs, concerncing stuff like connectivity are a bit scattered, and one needs to search for a bit, but in general I don't see much of an issue. Could be worse. Really, the scattering is a problem, but I don't really see a lack.
The maemo APIs, concerncing stuff like connectivity are a bit scattered, and one needs to search for a bit, but in general I don't see much of an issue. Could be worse. Really, the scattering is a problem, but I don't really see a lack.
| The Following 2 Users Say Thank You to shapeshifter For This Useful Post: | ||
 |
|
2009-12-15
, 10:44
|
|
Posts: 47 |
Thanked: 28 times |
Joined on Dec 2009
@ London, UK
|
#28
|
Originally Posted by danielwilms
Wiki is great to collaboratively build up the documentation, fix issues, keep it up to date, etc. Great tool for authoring the documentation.
If you prefer pdfs over the wiki, ok, that's one opinion.Cheers Daniel
But it's also very important to then be able to turn the authored documentation into offline documents - either to be printed (not my use-case) or for offline reading when no network connection is available, as is the case on the London Tube...
- Micha.
|
|
2009-12-15
, 10:58
|
|
Posts: 432 |
Thanked: 645 times |
Joined on Mar 2009
|
#29
|
Originally Posted by mwerle
A baseline of the guide will be as well available as pdf. We were looking once at the pdf export for mediawiki as it is used in Wikipedia. Maybe that could be a solution at some point.
But it's also very important to then be able to turn the authored documentation into offline documents - either to be printed (not my use-case) or for offline reading when no network connection is available, as is the case on the London Tube...
Cheers Daniel
|
|
2009-12-15
, 13:26
|
|
Posts: 47 |
Thanked: 28 times |
Joined on Dec 2009
@ London, UK
|
#30
|
Originally Posted by danielwilms
Good to hear, although my vote would go to a static HTML export.
A baseline of the guide will be as well available as pdf. We were looking once at the pdf export for mediawiki as it is used in Wikipedia. Maybe that could be a solution at some point.
Cheers Daniel
In my experience, PDF documents tends to be very awkward to read on a small display.
It doesn't mean Nokia should hire more 'Document Engineers'. Nokia already have lots of good coders but lack of management. If you have done reverse engineer, you could see the code are all not bad. And most of them are well written.