An alle TAP Entwickler: Gemeinsame Benutzung der Fernbedienung

[Indy]

Ich bin noch nicht lange dabei darum weiß ich nicht ob ihr schon eine Lösung habt wie TAPs die Fernbedienung teilen können. Ich hatte schon das Problem dass ich keine Taste finde könnte die noch nicht benutzt ist. Leider ist da kein SHIFT oder STRG Taste aber das könnte man implementieren.

Soweit ich weiß wird die Option (Weiße) Taste nicht in Normal Mode durch der SRP Firmware benutzt. Die Taste können wir dann als STRG Taste benutzen. Wenn diese Taste gedrückt wird leitet ein TAP die einfach weiter reagiert nicht und wartet auf den nächsten Tastendruck. Wird als nächste Taste „seine“ Taste gedrückt dann wird das TAP aktiv. Ist die nächste Taste nicht „seine“ Taste dann wird die einfach weitergeleitet und geht das TAP wieder in „Standby“.

Code: Alles auswählen

// Possible implementation but NOT Tested
dword TAP_EventHandler( word event, dword param1, dword param2 ){
  UNUSED(param2);
  dword dwState, dwSubstate;
  bool bNormalState;
  static bool bShiftPressed = false;
    
  if( event == EVT_KEY ){
    // Get Status
    TAP_GetState(&dwState, &dwSubstate);
    bNormalState = (dwState == STATE_Normal && dwSubstate == SUBSTATE_Normal);
    
    switch(param1){
      case RKEY_WHITE:
        if (bNormalState){
          bShiftPressed=true;
          return param1;
        } else {
          // Do your stuff when you TAP is active
          return 0;
        }
        break;
      case RKEY_F2:
        if (bNormalState){
          if (bShiftPressed){
            // Do Your stuff
            // Reset shift key
            bShiftPressed=false;
            return 0;
          } else {
            // Pass on key
            return param1;
          }
        } else {
          // Do your stuff when you TAP is active
          return 0;
        }
        break;
      default:
        // Reset shift Key
        bShiftPressed=false;
        return param1;
    }
  }
}

Vorteil:

• mehrere TAPs können die Tasten Teilen.

Nachteil:

• Man muss immer 2 Tasten benutzen um ein TAP zu aktivieren
• Funktioniert nur wenn all TAPs das machen

Was meint ihr?

[Alter Sack]

Funktioniert nur wenn all TAPs das machen

Ich kenne da ein TAP, das verhindert das Aufrufen der Senderliste bei eingeblendetem PIP,
weil es sich die weisse Taste krallt, nennt sich CallMonitor

Ansonsten eine gute Idee, sofern sich alle daran halten .

[Indy]

Ich kenne da ein TAP, das verhindert das Aufrufen der Senderliste bei eingeblendetem PIP,
weil es sich die weisse Taste krallt, nennt sich CallMonitor

Na das meine ich, wer hat die gemacht?

OT: aber doch nicht wirklich oder kannst du das dann bitte in der Callmonitor thread posten. Sollte eigentlich nicht passieren, oder ist PIP Normal Mode?

[BluField62]

Na das meine ich, wer hat die gemacht?

OT: aber doch nicht wirklich oder kannst du das dann bitte in der Callmonitor thread posten. Sollte eigentlich nicht passieren, oder ist PIP Normal Mode?

Deshalb können wir doch auf eine andere Taste dafür wechseln (slow/okiwankenoki)

Ja PIP Senderliste ist eine normale TMS Aktion

[Alter Sack]

OT: aber doch nicht wirklich oder

Doch, ich scherze doch fast nie

[Happy]

Oder man bräuchte wieder so etwas wie den TAP bzw TSR Commander.

[bloodhound]

kann man nicht als option verschiedene tasten, z. b. in der ini eintragen?, so wie beim reset cam tap, dann kann sich jeder die entsprechende taste raussuchen, sleep wäre bei mir schon vergeben, pip brauch ich auch nicht

[Erdnussnase]

Ich glaube ich verstehe da etwas nicht.

Wenn zwei Taps die Taste blau erwarten, passiert bei der weissen erst mal nichts. Bei der zweiten (blau) gewinnt dann das erste Tap. So wie jetzt auch schon.

Derzeit ist bei mir die erste Taste bevorzugt für die Taps, bei dieser Methode wäre es die zweite.
Das Problem mit den "Ich will jetzt ausnahmsweise mal das der TMS/Topf die Taste bekommt" löse ich durch eine führende 0.
Für alle die, die man immer vom TMS erledigt haben will, kann man die Direktaufruftasten umstellen.
Da see ich nur den Unterschied das diese Methode den TMS bevorzugt, die "führende 0" Methode die Taps.

Wo liegt mein Denkfehler ?

[Indy]

[quote="Erdnussnase"]Ich glaube ich verstehe da etwas nicht.

Wenn zwei Taps die Taste blau erwarten, passiert bei der weissen erst mal nichts. Bei der zweiten (blau) gewinnt dann das erste Tap. So wie jetzt auch schon.
[/quote]
Eigentlich sollen nicht zwei Taps die gleiche Taste benutzen. Damit wird man immer Problemen haben.

[quote="Erdnussnase"]Derzeit ist bei mir die erste Taste bevorzugt für die Taps, bei dieser Methode wäre es die zweite.
Das Problem mit den "Ich will jetzt ausnahmsweise mal das der TMS/Topf die Taste bekommt" löse ich durch eine führende 0.
Für alle die, die man immer vom TMS erledigt haben will, kann man die Direktaufruftasten umstellen.
Da see ich nur den Unterschied das diese Methode den TMS bevorzugt, die "führende 0" Methode die Taps.

Wo liegt mein Denkfehler ?[/quote]
Kein Denkfehler, das was du sagst stimmt. Ich bin nur nicht bekannt mit deiner Methode. Wird das schon durch andere auch benutzt?

Ist es aber nicht so das für die meiste Tasten immer den TMS als bevorzugt genommen werden kann? Natürlich wenn das Tap nicht aktiv ist, wenn das Tap aktiv ist dann ist das Tap bevorzugt.

Beispiel:
Option+Rot = Aktivier Tap 1
Option+Grün = Aktivier Tap 2
Option+Gelb = Aktivier Tap 3
Wenn kein Tap aktiv ist (Normal Mode) gehen alle Tasten direkt zum TMS. Wird die Option Taste gedrückt warten alle Taps auf die nächste Taste. Wird z.B. Rot gedrückt dann wir Tap 1 aktiv und geht in Vordergrund. Alle Tasten gehen direkt zum Tap 1. Die andere Taps ignorieren die Tasten da die nicht in Vordergrund/aktiv sind.

[FireBird]

How do we solve the situation when people do not have TMSCommander running? Are we running our own code when we startup and disable that when we receive a TMSCMDR_Capabilities event.

The FBLib contains the function HDD_TAP_isRunning(dword TAPID), which can be used to detect if TMSCommander is installed and running. But there is still a problem. If I?ve understood John correctly, TMSCommander just shows a list of user defined TAPs and not all running TAPs. If this is the case, we need a mechanism so that a TAP can find out if it is TMSCommander?s target (registering?).

What I also miss is a way to see what TAP is activ. This is something that is not integrated in TAP_GetState. It would be great if we could register SUBSTATES for our own TAPs. But I don't see it very likely Topfield is going to add that to the API. Or even own Events

Why should CallMonitor want to know that e.g. QuickPlay currently displays some OSDs? You could do this with the Linux? shared memory where every TAP can have access to the same structure. But as long as not every TAP is doing so, you can?t rely on that method.

[Indy]

[quote="FireBird"]Why should CallMonitor want to know that e.g. QuickPlay currently displays some OSDs? You could do this with the Linux? shared memory where every TAP can have access to the same structure. But as long as not every TAP is doing so, you can?t rely on that method.[/quote]

I have 2 windows: one for the addressbook and one for the showing the incoming calls. At the moment I'm very "rude" with my incoming call window. I display this no matter what is one the screen at the moment. This might not be wanted for certain TAPs. For instance if I would know that your screensaver is active I could imagine nobody is watching so there would be no need to display the incoming call.

[FireBird]

I display this no matter what is one the screen at the moment.

The normal way is to check normal mode. This makes sure that the Toppy is not in any menu and all TAPs should leave the normal mode before showing their own menu. TAPs which display a little info window may stay in normal mode but then they have to be very careful regarding key events so that they hide themselves before they ?damage? the OSD of an other TAP. In this case the start order gets important.

I could imagine nobody is watching so there would be no need to display the incoming call.

Attach a little network camera.

[Indy]

Attach a little network camera.

Are the webcam functions in FBLib ready yet?

[FireBird]

CheckCamIfUserIsSleeping() needs some tweeking...

[Indy]

CheckCamIfUserIsSleeping() needs some tweeking...

Ah, playLoadSound() is still missing

[FireBird]

I've moved the TMSCommander posts to a separate thread.

[Indy]

I've moved the TMSCommander posts to a separate thread.

As TMSCommander seems to be the only accepted solution to the problem addressed in this thread it might be wise to close this one to prevent 2 separate discussions.

[FireBird]

[quote="Indy"]it might be wise to close this one to prevent 2 separate discussions.[/quote]
Even if there's a TAP which might be the solution for most problems, this thread still has its eligibility an therefore I won't close it.

[Indy]

Even if there's a TAP which might be the solution for most problems, this thread still has its eligibility an therefore I won't close it.

Only very little responces before TMScommander was started I think it will starve pretty soon...