109 replies to this topic

[littlesat]

But the basic question is, should we consider to made this configurable (with default as it is now)? I'm waiting on reactions during the rest of this day.... It depends on pro- and contra- arguments until somewhere this evening...

 

The 10 years argument was only there not to stop improvements... But to open the discussion: "is this really needed"...

 

Sorry for not simply implement everyone's whishes right away...

Edited by littlesat, 9 October 2013 - 09:21.

[Doume]

I agree with Pr2 : It'd be interesting to be configurable.

In my case, I'm sure I would configure it to position on current channel viewed, instead implicitly scroll it

 

 

[Erik Slagter]

It is logic as it is now as it is more user frendly when it selects one channel up and down...

I don't share that vision.

[WanWizard]

I've been a strong advocate for a complete revision of the GUI for many years now. Its current behaviour is not logical, complex, and has a very low WAF.

 

And it gets worse by the minute, recently we seem to have gotten a green button that does two different things depending on the current channel (what a horror!).

 

Problem is that if you ask 1000 people what it should be, you get 1000 different answers. Especially here, where it's being discussed amongst "geeks" (hwo seem to like as many buttons as possible, combinations of long- and short keypress, simply to avoid having to go into a menu), who are not typical endusers, and certainly not usability specialists.

 

If you compare that to the UI's of the "competition", you'll see that they usually have thought this through. I for example like the UK SKY box for this reason: 6 buttons (4 arrows, OK and BACK), and anyone can use it. This also means that more effort has to be put in to design the logic behind the GUI, removing the need to have all these buttons to directly access underlying features. You can always offer MQB like functionality build into the image, to map keys the way you like so you can customize your installation.

[littlesat]

At least this is for now a go to make it configurable and to revert the green button patch....

[WanWizard]

I don't think that is the correct approach.

 

Currently behaviour of the GUI and underlying functions is all over the place. You need to be a menu-structure-expert to know which feature or what behavior is enabled/disabled where.

 

E2 should, like you see with a lot of desktop applications, export the list of functions that can be assigned to buttons. And provide a default mapping for (a subset of) the keys and functions, and an configuration option which will show you a list of all available functions, and give you the option to assign a key to it.

 

It means redesigning part of Enigma, and it means dumping support for 6 year old plugins that were written for DMM's original Enigma. I say "so what!". If we stick to the "we want to be compatible with the old junk", we will never get anywhere.

 

With the number of OpenPLi compatible boxes in the market, and the number sold, I think we have passed the stage where it was a "geeks" and "linux hobbyist" box only...

[Arcados]

Hello all,

 

I agree with Pr2 : It'd be interesting to be configurable.

In my case, I'm sure I would configure it to position on current channel viewed, instead implicitly scroll it

 

En français

=========

 

Je suis entièrement à 100 % d'accord avec Pr2, étant francophone, si j'ai fait des fautes dans mon message en Anglais, je vous prie de m'excuser.

 

Merci a vous ..

 

Regards,

 

Yvan / Arcados

[Rob van der Does]

Worked fine does not mean that it is structured and not patching around...

That is very true; it's indeed not the best coded plugin. But using it for years (as I didn't see any alternative for configuring button-assignment) I never ever had any issue with it.

As far I understand Pauli does only manupulate the keymap.xml...

OK, I'll have a better look at Pauli then. It's quite some time ago I did that.

But IMHO the best option would be to embed button-assignment functionality in the image.

[Rob van der Does]

As far I understand Pauli does only manupulate the keymap.xml...

OK, I'll have a better look at Pauli then. It's quite some time ago I did that.

OK, done that: Pauli still only allows for a very limited number of changes. So nothing has changed since the last time I looked at it and this isn't a real solution.

[Mikelima69]

Hello,
I just read this thread with interest, because I think the remark Pr2 is justified and logical.

On the greater part of the demodulators,

the return on the channel list is done with the cursor positioned on the channel current.
Thank Pr2 for this approach.
Sincerely.

[Taapat]

It seems to me, that make configurable key mapping is not the right way.

If the most feel that it is better to change the Up arrow behavior, it should be changed in kemap.xml.

I do not know, maybe similar already works, but maybe it would be better add an option when in a folder /etc/enigma2 place your keymap.xml in which insert only those events and keys that need to be changed. Then they remain when updated keymap.

If you feel that it is better to configure the buttons with the RC, then the it may be better to use MQB.

Edited by Taapat, 9 October 2013 - 16:42.

[Pr2]

Hi,

 

Changing the keymap.xml manually then at after online update if the file is touched you will need to see what as changed in it and adapt it again, reboot you E2, etc... rapidly boring.

MQB in the feed it claims to be 2.7 I install it is 2.4 and you cannot customised the up/down arrow in 2.4. In 2.4 EPG is not customisable to Graph Multi EPG only long press is configurable... I uninstalle MQB 2.4 as fast as I install it. Or Openpli should to really upgrade it to 2.7 so I can give another try.

 

@WanWizard,

 

I second you on the fact that OpenPli should think of  a total new GUI approach, more modern style. Openpli have now its own life, with good STB manufacturers so it's probably time to say goodbye to this "DMM compatibility" mode.

 

Pr2

[Rob van der Does]

MQB on the feeds is indeed very outdated.

[betacentauri]

P+ should from my point of view switch to next channel and not show the channellist or switch bouquet or what else is the "normal" e2 behaviour. I think 99,9% of the normal users think so. I have never seen a TV with P+/P- keys on the remote which don't switch channel with P+/P- keys.

 

On the up and down arrow keys I have currently the channellist. I know that's not very common, but I had no other free key for it...

 

I would like to see a functionality to assign ALL functionalities to any key. MQB can do some things. But with my version I was e.g. not able to say that I want to open the EPG while a playback of a recording was running.

 

Changing the keymap manually is possible, but that's only for geeks. And the fact that updates overwrite the customized keymap, makes it more worse.

[Taapat]

 And the fact that updates overwrite the customized keymap, makes it more worse.

Therefore, I'm talking about a separate file in the folder /etc/enigma2 which put only the buttons which you want to change.

But looking in the git I understand that now will be an additional test before each switching and this topic can be closed.

[daniel2005]

I fully support PR2's request.

Edited by daniel2005, 9 October 2013 - 19:03.

[Dimitrij]

Changing the keymap manually is possible, but that's only for geeks. And the fact that updates overwrite the customized keymap, makes it more worse.

mytest.py...

keymapparser.readKeymap(config.usage.keymap.value)

config.usage.keymap = ConfigText(default = eEnv.resolve("${datadir}/enigma2/keymap.xml"))

[WanWizard]

But with my version I was e.g. not able to say that I want to open the EPG while a playback of a recording was running.

 

That would require rewriting the way Engima works, afaik windows aren't separate processes that multitask around a central event thread, like you have with for example an OS window manager (Explorer, Gnome, etc). A keypress lauches a function that overlays the screen, and as long as that has focus, nothing else works.

[cylindric]

I agree with PR2.I'm interrested by the configuration of PR2

[betacentauri]

But with my version I was e.g. not able to say that I want to open the EPG while a playback of a recording was running.

 

That would require rewriting the way Engima works, afaik windows aren't separate processes that multitask around a central event thread, like you have with for example an OS window manager (Explorer, Gnome, etc). A keypress lauches a function that overlays the screen, and as long as that has focus, nothing else works.

 

I always wanted to test, whether it's possible or not. But perhaps you understood me wrong. I don't want to see more than 1 plugin/window at a time. So no multitask.

My usecase is the following: I watch a recording. It's 20:10 o'clock and I want to know what programs start at 20:15. So I need to stop the playback. Then I need to stop the mediaplayer (normal no plugin) and then I can start the EPG. Afterwards I need to start the mediaplayer again and choose the file and start it. Very annoying.

Isn't it possible to start EPG plugin while watching a recording? As said before it's not a special mediaplayer plugin.