Ottonavi HU: How to customize (a bit) the UI

Hello Sebasian, welcome here.

1) Not sure what you mean by *does not seem possible*. Not sure what you edit either.
But I'm guessing that the iPod screen became unresponsive after using the RRUIEditor.
The reason why is most probably because the skin is newer than the RRUIEditor itself; so it doesn't know how to handle the skin functions.
The RRUIEditor is an official Roadrover tool but it was made for earlier skins versions; so new skins are not always editable by this tool.
Bad design choice on Roadrover part... and not easily fixable now.
On the other hand, you can always use the RRUITool to fix things (it can fix anything UI related) but it's a bit more difficult.

2) If the Equalizer was working before, it should still work (unless you change the MCU firmware).
I would be surprised if your version of 4.x manager.exe doesn't handle it. Possible but highly improbable.
May be the 4.x skins have been modified by the RRUIEditor and lost their functions; try again with one of the original untouched 4.x skin.
If it still doesn't work, then we will have to take a look at your UI 3.0.9 and UI 4.x files to see where the difference lies.

 

Hello Sebasian,
many questions here... I will take a look into them in the next few days; be patient.
Thanks for posting your files.

 

Hello Sebasian,
I looked at your files... Here are a few comments.

1) The files in 3008v3.zip and 3008v4.zip are exactly identical; only the skin name file has changed.
You said it supposed to be a new 4.x skin so check again your files.
If it was really provided as a 4.x skin than it would mean that somehow the 4.x manager lost the EQ function (hard to believe...).
So please check again the zip files you sent.
As for EQ, again, the best way to make it work under 4.0.x is to provide an original 3.x skin that you know FOR SURE was working under 3.x manager. Then we can pick any 4.x screen , import the data functions from the working 3.x skin and test it under 4.x. Should work.

2) As for skin editing, you said there was a pic attached to show the problem; could not find it.
Maybe you meant that RRUITool displays garbled text in the UI screens; that would be normal; very primitive tool...
But the skin itself should be fine when displayed on the unit itself.

3) Copying a block of code for screens should at least work in the RRUITool. 65 should show up.
May be you should submit the original .txt file you changed (the *source code*) so we can check what went wrong.

I realize the documentation (and the tool) are not top notch (really bad in fact) but that's all we have right now.
The format is simple but you need to double check what you have changed before creating a new .rrui with the tool.

Let us know how it goes!

 

Hi Sebasian,

thanks for the new info.

1) So from what you said now it's not so sure anymore if your unit does support EQ. To find out, you will need to run one of the MCU firmware update tool (without updating the firmware of course). This tool will report the radio chip model and that would tell us if EQ is supported. If I remember, TEF6624 Audio chip only have the 3 bands equalizer. Check it out.

2) The picture you attached seems to show that manager.exe does not know how to handle the skin graphics properly. When it is the case the unit just falls back to its default internal skin. So may be the skin needs to be fixed.

3) OK; will wait.

4) iPod settings... Keys are added to the config.ini file very often so it's hard to keep track of every change RR made and which ones are supported. There is also a ipod_usb key (0,1) but I think it's related to the fact that previous unit versions had a plug in the back (which was not a standard usb). Not sure if there are any other key for ipod. Also I believe the choice of using ipod screen A versus B is based on the manager.exe version; not controlled by the skin itself. I also suspect that ID functions from both screens are actually available in manager.exe. This means that in theory, one should be able to copy-paste the functions ID from the unused screen to the used screen and make it work. But that would require further testing. That's why I said: if you can find a skin that works for you then we can probably copy-paste the functions to another skin using the RRUITool as long as it's the same manager.exe.

Hope that helps.

 

Hi MottiF,

here is a *short* explanation.

The RRUITool can read a .rrui binary file and generate an equivalent pseudo-formatted editable .txt file.
You can then edit that formatted .txt file to your taste.
Then the RRUITool can read back your txt file and generate a new .rrui file (skin).

To change the .txt file you need to know how to handle the RRUI file format.
The RRUI skin file contains a list of possible screens for the unit.
Some of those screens are not necessarily enabled depending on your unit hardware (like the equalizer screen).
Each screen is in fact a list of UI elements that represents not only the visual (associated graphics) but also its behaviour.
The behaviour describes how it reacts visually and also how it reacts inside the manager.exe.
This is basically a ID function (number) that is interpreted and executed by manager.exe.
So you can change the ID function of a UI element; manager.exe will now execute a different function.
Obviously you can not change the code of the function itself because it resides inside manager.exe.
Not so much control you say but at least in this way we can copy-paste from skin to skin some of the behaviours we like.

The long explanation is inside the Help file that comes with the tool. Click on Help in the RRUITool Menu.
You will find there a bit more explanations along with the *known* RRUI description format.
(I say *known* because there are still a few fields which we are not 100% sure...)

Remember that editing those skins with the RRUITool is a hack.
Those skin screens are in fact Windows CE windows with Windows messages (ID function).
So they were designed with a specific behaviour in mind.
So any change you made might actually break that design.

So do your testing properly!

 

1) Yes; this is equivalent to a Windows ID that will eventually receive a Windows message. So for example, when this UI element (or ID) receives a Click (touch) message, manager.exe will execute some specific code (or function) for that UI element.

2) Should be. At least in terms of visual appearance. But EP2 seems to be dependant on the element itself. So this means that the same value might produce different behaviors depending on the element which receives that message. That's what I meant by you need to experiment. Some of those fields are actually a placeholder for combinations of different values and RR probably add more values with the new skins. You can check with the old RRUIEditor to see what they are but again the new values might not be recognised by this old editor version.

3) You probably meant SP1. This is the 3D style for a window. Never used it so I don't know if it is working or not. These window control styles are all explained in the doc itself; you can either read about them at the beginning of the skin .txt file or in the Help menu in the RRUITool.

 

Nice work MottiF!

So now we know a little bit more about the iPod implementation; the list allocation and the wheel controlled feature are dependant.
They shouldn't be of course.

1) So yes may be a blunt bug. And maybe worst; instead of reusing or improving the existing code they branched away based on the tab order but in the process *forgot* to implement all the wheel controlled messages; really too bad. Not much we can do here.

2) About the settings... Normally the Windows styles are used just for controlling some visual aspects. Of course, a programmer can decide to implement his own interpretation (like the tab order) but then it becomes difficult to find out the new meaning of the field. I would be surprised anyway if the programmer encoded the list maximum value in there. No I'm afraid that what you see is what you get; the first version was limited to 30 but wheel controlled; the second has a new (may be dynamic) list but lacks the wheel-controlled feature.

3) There are a couple of Windows CE ARM disassembler and even decompiler available on the net but most of them are unreliable, incomplete and hard to use. But there is one called IDA by https://www.hex-rays.com that really shines above all the others.
Could be expensive; you have to check what they offer nowadays.

Back to your problem, to *fix* this, I would probably keep the second type skin ( tab order=1 to get the wheel control feature) and find the code spot in manager.exe where the allocation list is done and change the value to a better value; hard to find (even with IDA) but easy to change. We may find out later that this does not work or causes other problems but I would give it a try.
There is no problem in editing or modifying manager.exe; I did it for editing the RDS type and everything was fine.
Only problem with this approach (if it works) is you have to change manager.exe for each UI version you use... But that's doable.

Thanks again for sharing your find.
Hope that helps; let us know!

 

Yes, very nice. Golf for some reason has very elegant skins.