Installed themes are not available

Locus

New Post

Themes are not available. The Theme (openandromaps) was copyed under the _themes folder, but i can't see it.

Thilo Müller

4 Posts
1 Reply Like

Posted 2 years ago

2 years ago

tommi, Champion

467 Posts
38 Reply Likes

Same tip here, I suggest to check for a 2nd locus folder.

Comment

2 years ago

Thilo Müller

4 Posts
1 Reply Like

Sorry. I double check this with my mac. No second locus folder. Not on the internal or on the external SD card.

Comment

2 years ago

Menion, Official Rep

2961 Posts
210 Reply Likes

if there is any duplicate folder or not, may be seen now directly in menu > information > first tab! So check it there please

Hmm anyway I see no reason why it is not visible. Locus only checks directory and availability of one XML file. Weird ... I should create some test version that will display some debug messages, no better solution for now ...

Comment

2 years ago

Thilo Müller

4 Posts
1 Reply Like

The problem was solved. I removed all Themes.
Copied the Themes as .zip to my Droid.
Then unzip with ASTRO.
Move the files to the right folder...
..now it works fine.

Downloading the zip with MacOSX, unzip with osx and copy to Droid does not work.

Thanks for your help

cheers

Thilo

Comment

1 person likes this

2 years ago

tommi, Champion

467 Posts
38 Reply Likes

Reason: unzip with MacOS creates a new line with CR (0x0d) only while Android/Linux expects a LF (0x0a)
@Thilo: Could you confirm by checking with a hex editor?

Comment

2 years ago

Thilo Müller

4 Posts
1 Reply Like

I am sorry. No Hex Editor available. But I provide the mac_xml file for further checks here:

http://dl.dropbox.com/u/50118932/andr...

Comment

2013-03-15T05:49:25+00:00

tommi, Champion

467 Posts
38 Reply Likes

Oh, I see, Mac users don't need such stuff, they prefer video editors ;-).
The file contains the Windows like sequence of 0D 0A for end of line which is to what I remember not understood by the mapsforge library which reads the theme files. Actually I don't know if Mac OS still uses 0D (what they really did in the past!) or if it was changed due to the Unix platform it is based on since MacOSX.
Whatever, I'm pretty sure that the reason for the incompatibility of the .xml is the contained 0D 0A sequences instead of 0A only for every line end.
So, problem fixed.