Active Topics

 



Notices


Reply
Thread Tools
Posts: 70 | Thanked: 128 times | Joined on Dec 2015 @ Spain
#331
Really impressed in how this offline map application works in sfos. Without doubt, one of the best solution in mobile offline navigation out there. Thanks!
 

The Following 5 Users Say Thank You to ferlanero For This Useful Post:
karlos devel's Avatar
Posts: 50 | Thanked: 114 times | Joined on Mar 2013 @ Guatemala
#332
A tons of Thanks to @rinigus of this.
__________________
Caballlero
Free Software supporter
 

The Following 3 Users Say Thank You to karlos devel For This Useful Post:
Posts: 209 | Thanked: 982 times | Joined on Aug 2016 @ Estonia
#333
I have released a new version with the changes by @mal: fixed typos found by him as well as updated his Finnish translation. Thank you @mal!

I wonder if there is someone around interested in linguistics or able to spell out pronunciation of some words. Namely, Valhalla supports US English (Pirate version) for its instructions. While a joke, its a nice one and, I think, very appropriate for Sailfish. Unfortunately, TTS software does not know how to pronounce "Arrr" and few other words. What TTS software can do, is to pronounce according to given phoneme description.

So, I would like to ask for help and maybe someone here can propose their versions for words listed at https://github.com/valhalla/valhalla/issues/891 .

In Sailfish, install mimic from OpenRepos ( https://openrepos.net/content/rinigus/mimic ) and use

Code:
mimic -voice awb -ssml -t 'Some <phoneme ph="k ae p n">Capn</phoneme> wheel' -o /tmp/out.wav && gst-launch-1.0 -q filesrc location=/tmp/out.wav ! wavparse ! pulsesink
to test the phonemes.
 

The Following 3 Users Say Thank You to rinigus For This Useful Post:
Posts: 72 | Thanked: 302 times | Joined on Dec 2014 @ Earth
#334
Originally Posted by rinigus View Post
After that I will continue the development according to suggestions and some ideas that I have. Right now, it has been suggested to allow using the server as a proper daemon.
The best way to be compatible with the official Jolla shop ("no daemon allowed" rule) and end-users desire (background daemon), while avoiding to have 2 completely different codepaths, would be :

- always run the server in a separate process
- (which also means : design some inter-process communication. DBUS ? simple webservice ? protocole buffers ?)
- give the ability to start only that process ("OSMScout --daemon" or something)

- for the version available on openrepos.net :
pack a systemd ".service" file that only start the daemon in background

- for the version avaiable on the shop :
don't pack that file.

When UI starts, it checks (see the IPC mentionned above) if there's a daemon process answering.
If not, it launches the daemon as a child process / as just another thread of the main UI task.

On the official version it means that the service will only be available while the UI is running (even if it uses a weird IPC instead of directly calling functions).

On the openrepos version, people have the possibility to launch the daemon in background at boot ("systemctl enable OSMscout.service") and only launch the UI to monitor daemon activity.
 

The Following 3 Users Say Thank You to DrYak For This Useful Post:
Posts: 209 | Thanked: 982 times | Joined on Aug 2016 @ Estonia
#335
Originally Posted by DrYak View Post
The best way to be compatible with the official Jolla shop ("no daemon allowed" rule) and end-users desire (background daemon), while avoiding to have 2 completely different codepaths, would be :

- always run the server in a separate process
- (which also means : design some inter-process communication. DBUS ? simple webservice ? protocole buffers ?)
- give the ability to start only that process ("OSMScout --daemon" or something)

- for the version available on openrepos.net :
pack a systemd ".service" file that only start the daemon in background

- for the version avaiable on the shop :
don't pack that file.

When UI starts, it checks (see the IPC mentionned above) if there's a daemon process answering.
If not, it launches the daemon as a child process / as just another thread of the main UI task.

On the official version it means that the service will only be available while the UI is running (even if it uses a weird IPC instead of directly calling functions).

On the openrepos version, people have the possibility to launch the daemon in background at boot ("systemctl enable OSMscout.service") and only launch the UI to monitor daemon activity.
Indeed, that would be a proper way of doing it. Would have to move all communication between GUI and the server to RPC then. Not too easy since it requires some redesign, but possible. I have added your suggestions to the corresponding github issue and let's see when I will get to that.

Alternative to RPC would be to add a command line switch and make some lock file. When user starts GUI, I can kill the daemon and run as GUI app. When GUI app is closed, a new daemon can be started as well. I would have to think how to ensure that its all working
 

The Following User Says Thank You to rinigus For This Useful Post:
Reply

Tags
offline maps, sailfish os

Thread Tools

 
Forum Jump


All times are GMT. The time now is 19:23.