Active Topics
-
Porting apps to Leste (32)
to Maemo 7 / Leste by Arno_11 - 2 days, 2 hrs ago -
[ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900 (2,264)
to Maemo 5 / Fremantle by panjgoori - 3 days, 20 hrs ago -
Full linux distros on Sailfish OS (254)
to SailfishOS by qoh - 4 days, 18 hrs ago - more...
|
2012-06-02
, 23:04
|
|
Posts: 98 |
Thanked: 44 times |
Joined on Mar 2010
@ Netherlands
|
#1052
|
Sailor here,
Altitude is not a real (measurable) issue on the water. I'd suggest the idea to add content that portrays the angle to the next waypoint (either a visual or a measurement in degrees). This could open the way for efficient tacking (going upwind). BTW, I could imagine this would be too major an alteration. On the other hand, such a feature could come in handy for land driving as well btw. (i.e. for visualizing the general direction).
Anyway, absolute distance to next waypoint, too, could be informative as well and/or alternatively (i.e. to mark the 90 degr. position to a buoy, although 90 degrees normally is 'late' for a tack).
Cheers, modRana already is very cool. As said, maybe what I said is reasonably undoable, but I just wanted to describe from sailor's point of view.
Altitude is not a real (measurable) issue on the water. I'd suggest the idea to add content that portrays the angle to the next waypoint (either a visual or a measurement in degrees). This could open the way for efficient tacking (going upwind). BTW, I could imagine this would be too major an alteration. On the other hand, such a feature could come in handy for land driving as well btw. (i.e. for visualizing the general direction).
Anyway, absolute distance to next waypoint, too, could be informative as well and/or alternatively (i.e. to mark the 90 degr. position to a buoy, although 90 degrees normally is 'late' for a tack).
Cheers, modRana already is very cool. As said, maybe what I said is reasonably undoable, but I just wanted to describe from sailor's point of view.
|
|
2012-06-10
, 00:38
|
|
Posts: 1,994 |
Thanked: 3,342 times |
Joined on Jun 2010
@ N900: Battery low. N950: torx 4 re-used once and fine; SIM port torn apart
|
#1053
|
Quick message...
First, I have made it so that labels for POIs are not displayed if zoom level is smaller than 13: POIs are too close to each other, the labels become a useless mess, and besides, when the map is zoomed out enough, locations (continents, countries, et cetera) can be recognized without any labels at all. Though, '13' should be replaced with an option to be set through user interface.
I am also creating an amusing kind of POI. If description of a POI matches 'airport', then, instead of the green translucent circle, an over-simplified image of airplane is drawn. And, an 'airport' doesn't have any label at all, no matter what zoom level: the number of airports is small enough than an airport doesn't need it.
And, the bright blue dot is replaced with a changing-colour one: bright green if GPS isn't available, yellow if GPS gives large speed and large distance till the point, red if the speed is large and distance is small, green if the speed is small and distance is large, black if both speed and distance are small. Speed is compared to pedestrian's 5km/h, and distance is compared to one hour of travel at current speed.
By the way, is it true that POIs are drawn even when they are outside the screen? It can make drawing work for cairo context about ten-twenty-forty times larger.
I'm still wavering: to install CSSU or not... Thank you for ModRana.
Last edited by Wikiwide; 2012-06-11 at 22:12. Reason: Attachment
First, I have made it so that labels for POIs are not displayed if zoom level is smaller than 13: POIs are too close to each other, the labels become a useless mess, and besides, when the map is zoomed out enough, locations (continents, countries, et cetera) can be recognized without any labels at all. Though, '13' should be replaced with an option to be set through user interface.
I am also creating an amusing kind of POI. If description of a POI matches 'airport', then, instead of the green translucent circle, an over-simplified image of airplane is drawn. And, an 'airport' doesn't have any label at all, no matter what zoom level: the number of airports is small enough than an airport doesn't need it.
And, the bright blue dot is replaced with a changing-colour one: bright green if GPS isn't available, yellow if GPS gives large speed and large distance till the point, red if the speed is large and distance is small, green if the speed is small and distance is large, black if both speed and distance are small. Speed is compared to pedestrian's 5km/h, and distance is compared to one hour of travel at current speed.
By the way, is it true that POIs are drawn even when they are outside the screen? It can make drawing work for cairo context about ten-twenty-forty times larger.
I'm still wavering: to install CSSU or not... Thank you for ModRana.
__________________
Broken SIM card port?
ModRana
OviMaps voice guide(α)
MBarcode
Virtual keyboards:
CellWriter
ChineseQML
Auto-rotating,QWERTY&T9
Virtransim: choice
Face detection
Speech recognition
Saera:Pocketsphinx+eSpeak+PyGTK
Gem:QStarDict
Hildon banner
Frontcam as rgb sensor?
Cam or touch for heartrate?
Fennec17XUL Maemo
bnf
M:ic
Red
Neo900
Broken SIM card port?
ModRana
OviMaps voice guide(α)
MBarcode
Virtual keyboards:
CellWriter
ChineseQML
Auto-rotating,QWERTY&T9
Virtransim: choice
Face detection
Speech recognition
Saera:Pocketsphinx+eSpeak+PyGTK
Gem:QStarDict
Hildon banner
Frontcam as rgb sensor?
Cam or touch for heartrate?
Fennec17XUL Maemo
bnf
M:ic
Red
Neo900
Last edited by Wikiwide; 2012-06-11 at 22:12. Reason: Attachment
|
|
2012-06-12
, 11:09
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#1054
|
Originally Posted by skykooler
I think I'll just do it with elevation on the third place, to make the design cleaner and more future proof:
Really looking forward to location alarms! (Also, pilot here, would appreciate altitude alarms)
Code:
lat;lon;elevation;distance;enabled;name;alert
Originally Posted by 7thd
So basically a mode, which takes into account the order of the alarm points and shows the angle to the next one ? BTW, I think I'm a bit confused about the context of the angle - could perhaps provide a simple sketch illustrating how it would work ?
Sailor here,
Altitude is not a real (measurable) issue on the water. I'd suggest the idea to add content that portrays the angle to the next waypoint (either a visual or a measurement in degrees). This could open the way for efficient tacking (going upwind). BTW, I could imagine this would be too major an alteration. On the other hand, such a feature could come in handy for land driving as well btw. (i.e. for visualizing the general direction).
Anyway, absolute distance to next waypoint, too, could be informative as well and/or alternatively (i.e. to mark the 90 degr. position to a buoy, although 90 degrees normally is 'late' for a tack).
Anyway, I thinks that such "sailing mode" mode might not be that difficult to add, once the general alarms are implemented.
Originally Posted by Wikiwide
Good idea ! You are right that the labels are not really usable at low zoomlevels and this handles the issue quite nicely.
Quick message...
First, I have made it so that labels for POIs are not displayed if zoom level is smaller than 13: POIs are too close to each other, the labels become a useless mess, and besides, when the map is zoomed out enough, locations (continents, countries, et cetera) can be recognized without any labels at all. Though, '13' should be replaced with an option to be set through user interface.
Another possible, but more complicated future solution, would be to group nearby markers and just show a single marker with the label displaying the number of markers in the group. Clicking the label would show a list of the grouped marker or something similar.
Originally Posted by Wikiwide
Well, why not.
I am also creating an amusing kind of POI. If description of a POI matches 'airport', then, instead of the green translucent circle, an over-simplified image of airplane is drawn. And, an 'airport' doesn't have any label at all, no matter what zoom level: the number of airports is small enough than an airport doesn't need it.
It would be good to add and "icon" column to the database so that POIs can have both an icon and a full description, but this should work in the meantime.
Originally Posted by Wikiwide
Oh, I've finally got it ! Like this, you know how accessible the points are from your position, with you current speed ? Nice idea !
And, the bright blue dot is replaced with a changing-colour one: bright green if GPS isn't available, yellow if GPS gives large speed and large distance till the point, red if the speed is large and distance is small, green if the speed is small and distance is large, black if both speed and distance are small. Speed is compared to pedestrian's 5km/h, and distance is compared to one hour of travel at current speed.
Originally Posted by Wikiwide
Unfortunately yes, modRana just draws all points that were designated as visible, even if they are outside of the viewport. Also, I think the most costly is actually not the drawing but the calculations needed to compute the screen coordinates from the geographic ones and the distance, which currently happen every time the screen is redrawn.
By the way, is it true that POIs are drawn even when they are outside the screen?
Therefore, just looking what points should be visible doesn't help as you still have to iterate over all the points and check if they are visible, would not help due to all the unnecessary comparisons and coordinate conversions.
Of course, there is place for optimizations (the basic idea is to somehow reduce the number of points you have to work with at a time), the first one from the top of my head :
- calculate the bounding box of the current viewport in screen coordinates (I think a bounding box represented by geographic coordinates might not actually be a rectangle)
- then calculate a "border" bounding box, say 2x times larger
- check what markers are in the "border" bounding box
- as long as the viewport bounding box is inside the "border" bounding box, you can ignore markers that are outside
- once you detect that the viewport bounding box is outside of the "border" bounding box, you recalculate a new "border" bounding box and check what markers are contained within
I'm sure there are also other ways how to optimize this.
Originally Posted by Wikiwide
I don't understand what you mean, can can you clarify ?
It can make drawing work for cairo context about ten-twenty-forty times larger.
Originally Posted by Wikiwide
I'm using it for quite some time already, without issues. Still, I remember the Saera developer mentioning some issues with the camera UI in CSSU.
I'm still wavering: to install CSSU or not... Thank you for ModRana.
Anyway, thanks for the changes !
I'll check them out & integrate them to the upstream source code in the coming days.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
|
|
2012-06-12
, 23:39
|
|
Posts: 1,994 |
Thanked: 3,342 times |
Joined on Jun 2010
@ N900: Battery low. N950: torx 4 re-used once and fine; SIM port torn apart
|
#1055
|
Originally Posted by MartinK
Good idea.
I think I'll just do it with elevation on the third place, to make the design cleaner and more future proof:
If elevation is empty, modRana would count the distance in 2D, if it is filled in, it would count the distance in 3D.Code:lat;lon;elevation;distance;enabled;name;alert
Originally Posted by MartinK
Thank you. What about adding to each POI (or to each category of POI) additional options, such as zoom levels, or speed levels, or distance from POI, at which they will be displayed? Then some POIs, like bus stop, or bench, or shop, will disappear if you zoom out and look at the country, not at the city.
Good idea ! You are right that the labels are not really usable at low zoomlevels and this handles the issue quite nicely.
Another possible, but more complicated future solution, would be to group nearby markers and just show a single marker with the label displaying the number of markers in the group. Clicking the label would show a list of the grouped marker or something similar.
Originally Posted by MartinK
I was just a bit bored that all the different POI have the same appearance.
Well, why not.
It would be good to add and "icon" column to the database so that POIs can have both an icon and a full description, but this should work in the meantime.
Originally Posted by MartinK
It's probably nice, but it's a bit confusing, and requires adding some options into the interface.
Oh, I've finally got it ! Like this, you know how accessible the points are from your position, with you current speed ? Nice idea !
Originally Posted by MartinK
Well, if the viewport is remembered somewhere in geographic coordinates, it's possible to compare POI with viewport without converting geocoordinates of POI into screen coordinates. But I see the point: it's better not to have POI visible until it's needed, because the computations will be happening either way.
Unfortunately yes, modRana just draws all points that were designated as visible, even if they are outside of the viewport. Also, I think the most costly is actually not the drawing but the calculations needed to compute the screen coordinates from the geographic ones and the distance, which currently happen every time the screen is redrawn.
Therefore, just looking what points should be visible doesn't help as you still have to iterate over all the points and check if they are visible, would not help due to all the unnecessary comparisons and coordinate conversions.
Originally Posted by MartinK
Interesting idea. Is it possible to somehow make it so that POIs are redrawn only when the map is dragged, not every second?
Of course, there is place for optimizations (the basic idea is to somehow reduce the number of points you have to work with at a time), the first one from the top of my head :
- calculate the bounding box of the current viewport in screen coordinates (I think a bounding box represented by geographic coordinates might not actually be a rectangle)
- then calculate a "border" bounding box, say 2x times larger
- check what markers are in the "border" bounding box
- as long as the viewport bounding box is inside the "border" bounding box, you can ignore markers that are outside
- once you detect that the viewport bounding box is outside of the "border" bounding box, you recalculate a new "border" bounding box and check what markers are contained within
I'm sure there are also other ways how to optimize this.
Originally Posted by MartinK
Well... I meant that there might be only one-two-four POIs in the viewport, and about forty-fifty POIs altogether (visible, but outside the viewport), and redrawing all the POIs, even outside the viewport, sounds excessive.
I don't understand what you mean, can can you clarify ?
Originally Posted by MartinK
Thank you for replying. But don't integrate everything, or the program might bloat... It's not an actually useful or necessary feature, except for hiding the POIs labels.
I'm using it for quite some time already, without issues. Still, I remember the Saera developer mentioning some issues with the camera UI in CSSU.
Anyway, thanks for the changes !
If the conversion of geo coordinates into screen coordinates depends only on zoom, and not on current position/viewport, then screen coordinates could be permanently stored within POI, changed only when POI's geo coordinates are changed, and retrieved from here when POI is drawn, instead of being recalculated each time.
__________________
Broken SIM card port?
ModRana
OviMaps voice guide(α)
MBarcode
Virtual keyboards:
CellWriter
ChineseQML
Auto-rotating,QWERTY&T9
Virtransim: choice
Face detection
Speech recognition
Saera:Pocketsphinx+eSpeak+PyGTK
Gem:QStarDict
Hildon banner
Frontcam as rgb sensor?
Cam or touch for heartrate?
Fennec17XUL Maemo
bnf
M:ic
Red
Neo900
Broken SIM card port?
ModRana
OviMaps voice guide(α)
MBarcode
Virtual keyboards:
CellWriter
ChineseQML
Auto-rotating,QWERTY&T9
Virtransim: choice
Face detection
Speech recognition
Saera:Pocketsphinx+eSpeak+PyGTK
Gem:QStarDict
Hildon banner
Frontcam as rgb sensor?
Cam or touch for heartrate?
Fennec17XUL Maemo
bnf
M:ic
Red
Neo900
|
|
2012-06-14
, 07:33
|
|
Posts: 1,994 |
Thanked: 3,342 times |
Joined on Jun 2010
@ N900: Battery low. N950: torx 4 re-used once and fine; SIM port torn apart
|
#1056
|
Quick message...
Generally, I don't have Internet while on the move (or consider it expensive, or it is too slow). And, I generally don't want to depend on online services to help me with something which I could have done myself. Therefore, I have made a prototype offline routing: user gives one start, one end, and many middle points, and they are turned into a "route". Though, it could be developed by requiring text input for each middle point, so that the user would write the speeches for espeak - like, "turn left", "turn right", "bus stop", "train", and so on.
I would be grateful if you could integrate this into one of the next versions. Thank you.
Edit: obligatory text input for each middle point added. Though, I still haven't tested the system anywhere.
Edit: Small edit ensures that turn-by-turn navigation interface does indeed work with handmade route. But I'm not sure whether the values of distance-meters are correct here.
Edit: mod_route.turn.zip is the latest file. Two others couldn't support turn-by-turn navigation.
Best wishes to all of you.
Last edited by Wikiwide; 2012-06-15 at 23:11. Reason: Clarify
Generally, I don't have Internet while on the move (or consider it expensive, or it is too slow). And, I generally don't want to depend on online services to help me with something which I could have done myself. Therefore, I have made a prototype offline routing: user gives one start, one end, and many middle points, and they are turned into a "route". Though, it could be developed by requiring text input for each middle point, so that the user would write the speeches for espeak - like, "turn left", "turn right", "bus stop", "train", and so on.
I would be grateful if you could integrate this into one of the next versions. Thank you.
Edit: obligatory text input for each middle point added. Though, I still haven't tested the system anywhere.
Edit: Small edit ensures that turn-by-turn navigation interface does indeed work with handmade route. But I'm not sure whether the values of distance-meters are correct here.
Edit: mod_route.turn.zip is the latest file. Two others couldn't support turn-by-turn navigation.
Best wishes to all of you.
Last edited by Wikiwide; 2012-06-15 at 23:11. Reason: Clarify
|
|
2012-06-15
, 13:51
|
|
Posts: 67 |
Thanked: 36 times |
Joined on May 2010
@ Claremont (LA), California
|
#1057
|
Originally Posted by Wikiwide
This is useful for more than just offline routing. I've been wanting a similar feature so I could route things like a long bike ride that does a loop and returns home.
Therefore, I have made a prototype offline routing: user gives one start, one end, and many middle points, and they are turned into a "route".
So this is a vote for integration!
|
|
2012-06-15
, 23:34
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#1058
|
Originally Posted by Wikiwide
WOW, that sounds interesting & useful !
Quick message...
Generally, I don't have Internet while on the move (or consider it expensive, or it is too slow). And, I generally don't want to depend on online services to help me with something which I could have done myself. Therefore, I have made a prototype offline routing: user gives one start, one end, and many middle points, and they are turned into a "route". Though, it could be developed by requiring text input for each middle point, so that the user would write the speeches for espeak - like, "turn left", "turn right", "bus stop", "train", and so on.
I would be grateful if you could integrate this into one of the next versions. Thank you.
Edit: obligatory text input for each middle point added. Though, I still haven't tested the system anywhere.
Edit: Small edit ensures that turn-by-turn navigation interface does indeed work with handmade route. But I'm not sure whether the values of distance-meters are correct here.
Edit: mod_route.turn.zip is the latest file. Two others couldn't support turn-by-turn navigation.
Best wishes to all of you.
I've been working on CLI options for use by external program like (Saera) till now, so I'll check your changes next.
Anyway, thanks in advance !
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
Last edited by MartinK; 2012-06-16 at 09:21.
|
|
2012-06-15
, 23:36
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#1059
|
ModRana V0.32 has been release, with CLI interface imeprovements. Repost from the Saera thread:
ModRana now has quite a few new CLI options for use by Saera (and any other program or script):
Search
The search options work in two modes:
If --return-static-map-url is used, modRana loads only the most essential modules, handles the query and exits after printing the Url pointing to a static-map with the result to stdout.
If --return-static-map-url is not used, modRana starts normally and shows the search results.
Exit codes
If everything went fine, modRana returns 0, as expected.
If something went wrong, modRana exits with one of the codes below:
Local search takes some time
When modRana does local search and no --local-search-location is specified, it starts the GPS and waits for up to 30 seconds for it to supply valid location coordinates.
If the current location is not determined within the 30 second time limit, modRana uses the last known position (if available).
Results
If more results are returned for --return-static-map-url, modRana just returns Url for the first one (this is also usually the result with the best accuracy).
It also shouldn't be difficult to add support for returning multiple results or to return coordinates or other information to stdout (maybe URL + result title ?).
Other supported options
It is also possible to set the zoom level, make modRana focus on a set of coordinates or center on current position.
Routing
There are not yet CLI options for routing, but will be added in near future.
How to use
Example - show address search result in GTK UI on zoom level 10:
Example - return local search result at static map URL on default zoom level (15):
Feedback
Don't hesitate to let me know if you hit any issues or if you have any ideas for improvements.
Last edited by MartinK; 2012-06-16 at 09:26.
ModRana now has quite a few new CLI options for use by Saera (and any other program or script):
Code:
usage: modrana.py [-h] [-d device ID] [-u GUI ID]
[--local-search search query]
[--local-search-location an address or geographic coordinates]
[--address-search an address]
[--wikipedia-search search query] [--return-static-map-url]
[--center-on-position] [--set-zl zoom level number]
[--center-on-position-on-zl zoom level number]
[--focus-on-coordinates geographic coordinates with the geo: prefix]
A flexible GPS navigation system.
optional arguments:
-h, --help show this help message and exit
-d device ID specify device type
-u GUI ID specify user interface type (GTK or QML)
--local-search search query
specify a local search query EXAMPLE: "pizza"
--local-search-location an address or geographic coordinates
specify a geographic location for a local search query
(current location is used by default), both addresses
and geographic coordinates with the geo: prefix are
supported; use "LAST_KNOWN_POSITION" to use last known
position EXAMPLE: "London" or
"geo:50.083333,14.416667" or LAST_KNOWN_POSITION"
--address-search an address
specify an address search query EXAMPLE: "Baker Street
221b, London"
--wikipedia-search search query
specify a local search query EXAMPLE: "Prague castle"
--return-static-map-url
return static map URL for a CLI query (works for local
search, address and Wikipedia search)
--center-on-position focus on the current position & enable centering
--set-zl zoom level number
set a zoom level EXAMPLE: 15
--center-on-position-on-zl zoom level number
focus on current position on a given zoom level
EXAMPLE: 15
--focus-on-coordinates geographic coordinates with the geo: prefix
focus on given coordinates, NOTE you can use --set-zl
to set zoom level, EXAMPLE: "geo:50.083333,14.416667"
The search options work in two modes:
If --return-static-map-url is used, modRana loads only the most essential modules, handles the query and exits after printing the Url pointing to a static-map with the result to stdout.
If --return-static-map-url is not used, modRana starts normally and shows the search results.
Exit codes
If everything went fine, modRana returns 0, as expected.
If something went wrong, modRana exits with one of the codes below:
Code:
SYNTAX_ERROR = 2 SEARCH_NO_RESULTS_FOUND = 3 SEARCH_PROVIDER_TIMEOUT_ERROR = 4 SEARCH_PROVIDER_ERROR = 5 LOCAL_SEARCH_CURRENT_POSITION_UNKNOWN_ERROR = 6
When modRana does local search and no --local-search-location is specified, it starts the GPS and waits for up to 30 seconds for it to supply valid location coordinates.
If the current location is not determined within the 30 second time limit, modRana uses the last known position (if available).
Results
If more results are returned for --return-static-map-url, modRana just returns Url for the first one (this is also usually the result with the best accuracy).
It also shouldn't be difficult to add support for returning multiple results or to return coordinates or other information to stdout (maybe URL + result title ?).
Other supported options
It is also possible to set the zoom level, make modRana focus on a set of coordinates or center on current position.
Routing
There are not yet CLI options for routing, but will be added in near future.
How to use
Example - show address search result in GTK UI on zoom level 10:
Code:
python /opt/modrana/modrana.py -d n900 -u GTK --address-search "Prague" --set-zl 10
Code:
python /opt/modrana/modrana.py --local-search "pizza" --return-static-map-url
Don't hesitate to let me know if you hit any issues or if you have any ideas for improvements.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
Last edited by MartinK; 2012-06-16 at 09:26.
| The Following 6 Users Say Thank You to MartinK For This Useful Post: | ||
|
|
2012-06-16
, 09:38
|
|
Posts: 1,994 |
Thanked: 3,342 times |
Joined on Jun 2010
@ N900: Battery low. N950: torx 4 re-used once and fine; SIM port torn apart
|
#1060
|
Originally Posted by MartinK
Unfortunately, I am going on a long, likely offline trip, so I will not update Modrana now - offline routing is more important for me now than CLI.
WOW, that sounds interesting & useful !
I've been working on CLI options for use by external program like (Saera) till now, so I'll check your changes next.
Anyway, thanks in advance !
Thank you for looking into my supposed changes.
__________________
Broken SIM card port?
ModRana
OviMaps voice guide(α)
MBarcode
Virtual keyboards:
CellWriter
ChineseQML
Auto-rotating,QWERTY&T9
Virtransim: choice
Face detection
Speech recognition
Saera:Pocketsphinx+eSpeak+PyGTK
Gem:QStarDict
Hildon banner
Frontcam as rgb sensor?
Cam or touch for heartrate?
Fennec17XUL Maemo
bnf
M:ic
Red
Neo900
Broken SIM card port?
ModRana
OviMaps voice guide(α)
MBarcode
Virtual keyboards:
CellWriter
ChineseQML
Auto-rotating,QWERTY&T9
Virtransim: choice
Face detection
Speech recognition
Saera:Pocketsphinx+eSpeak+PyGTK
Gem:QStarDict
Hildon banner
Frontcam as rgb sensor?
Cam or touch for heartrate?
Fennec17XUL Maemo
bnf
M:ic
Red
Neo900
| The Following User Says Thank You to Wikiwide For This Useful Post: | ||
 |
| Tags |
| bada rox, martin_rocks, modrana, navigation, openstreetmap, the best, wehasgps |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 13:10.