Where to store the background images

[clausmuus]

Hi,

where must I store the background images, so that the vomp-client can find and load them?

Claus

[MartenR]

In the moment I do not know.
Where should I search for them?
Currently loading images is not implemented... It is on my todo list.

Anyway if you have a good suggestion for a place to store them plus a good search algorithm
for most distributions, I will keep it in mind when implementing it.

Marten

[glotzi]

I think there are more important issues than displaying a background image on the raspi client 

[clausmuus]

Hi,

yes, glotzi are right. It's not so importent. I have only ask, because I thought that I store the image at the wrong place.
I think /usr/share/vompclient/ will be a good place. If you will also store settings (were did you store them at the moment? On the server?) a second good place will be /etc/vompclient/. You can also first check, if the folder ~/.config/vomplient/ exists and contains the image or settings.
Also it will be great if it will also be possible to setup the background color(or background image?) for the menu and the color of the menu texts.
I think, a compile option to select the config/image folder or a command option will also be helpful.

Claus

[MartenR]

Hi,

yes, glotzi are right. It's not so importent. I have only ask, because I thought that I store the image at the wrong place.
I think /usr/share/vompclient/ will be a good place. If you will also store settings (were did you store them at the moment? On the server?) a second good place will be /etc/vompclient/. You can also first check, if the folder ~/.config/vomplient/ exists and contains the image or settings.
Also it will be great if it will also be possible to setup the background color(or background image?) for the menu and the color of the menu texts.
I think, a compile option to select the config/image folder or a command option will also be helpful.

Claus

I thought a bit about it. The default images and fonts will be stored inside the executable.
Setting colors is at the end of my priority list.
First an implementation of the drawing routines using openvg will be done (this will allow using gradients as color) and then I might think about skinning, but for me this is not really important, so may be someone else has to do it.
Configurations will stay on the server one config for every client. (May be a small local config for video modes might be necessary on the client)

Just for reference, my current todo list (subject to change):

1) Add ac3 passthrough mode and fix audio playback on certain channels (e.g. mono is broken).
2) Handle video mode switch e.g. setting to PAL 50 Hz video modes and handle switching of hdmi and composite, if a connectors is plugged in. Switching video and audio off.
3) Rewrite OSD and surface class to be vector based and to use OpenVG.

Everything else is almost done.

Marten

[davep]

Just for reference, my current todo list (subject to change):

1) Add ac3 passthrough mode and fix audio playback on certain channels (e.g. mono is broken).
2) Handle video mode switch e.g. setting to PAL 50 Hz video modes and handle switching of hdmi and composite, if a connectors is plugged in. Switching video and audio off.
3) Rewrite OSD and surface class to be vector based and to use OpenVG.

It would be good to have:

4) Reconfigure key mapping for CEC remotes via config file.

My TV remote doesn't have buttons for 'skip', 'pause' etc, so I would like to remap the RGYB buttons to these functions, but only in Play mode. XBMC has this ability.

[MartenR]

4) Reconfigure key mapping for CEC remotes via config file.

You should already have the possibility to change the keymapping in the options menu.
(I did not test it yet, but might already work).

but only in Play mode.

This is not working in the way remote calls are handled internally in the moment.
And it will need a major rewrite of the code, so it is very unlikely that I will do it, since it is rather unimportant for me.
(And I do not see see a clean may to switch the mappings, for me the color buttons are really important for recording playback,
navigating and switching audio channels)

One thing we could think of is vomp listening on a port for UDP remote presses, which might be feed by an android app.... (given some else writes the app)
This would be easy to implement.

I would suggest in the moment the following options:
1) Buy a usb remote, which is handled through /dev/input/event...
2) Maybe use some other keys, which are not needed for either tv or recording playback.
3) Try some options in your tvs menu mine worked only with all keys after changing some settings.

Marten

[odin4242]

It would make sense to store those Images on the Server, doesn't it? The Vompserver could deliver them to the client.

[MartenR]

It would make sense to store those Images on the Server, doesn't it? The Vompserver could deliver them to the client.

No it does not, you also want an ui, before connecting to the main server.

@davep

I made a little change to the recording playback.
Now you can also use the arrow keys for:
up=play
down=pause
right=fast forward
left= fast backward

I hope this enough for your remote to use all functions of the recording playback.

Marten

[davep]

I made a little change to the recording playback.
Now you can also use the arrow keys for:
up=play
down=pause
right=fast forward
left= fast backward

I hope this enough for your remote to use all functions of the recording playback.

Excellent! Many thanks.

[MartenR]

2. Handle video mode switch e.g. setting to PAL 50 Hz video modes and handle switching of hdmi and composite, if a connectors is plugged in. Switching video and audio off.

Will unfortunetely not happen, the api does not allow to do mode switching and to reconfigure the osd.
Until the firmware change here towards an easier implementation, the users have to set the modes themself. Sorry. (After hours of trying I give up...)

Marten

[clausmuus]

I have already add the mode selection to the Webif of the MLD. So it's also easy to select a 50Hz mode.

Claus

[clausmuus]

Hi,

is it a big thing, to delete at minimum the whole screen when entering a menu? At the moment I will see parts of the last menu around the current one, if this is smaller than the last one. That's not really nice ;(
(Skinning the theme is not important for me. If I want, it's no problem to change the colours in the source code, or later also change the background image that will be compiled in)

Claus

[MartenR]

@clausmuus
Well, it will be changed, when the opengl stuff is replaced with openvg.
It the moment, it is just not programmed completely.

Remember the git is not a release, it is just a work in progress development version, so some stuff works, some stuff will not work yet.
But it will get better and better.

Marten

[clausmuus]

Thank you for the information.
I know, it's in development. And I'm happy, that its works already so well, since it's at the moment the only working vdr frontend for the RPI!

Claus