VDR 2.1.2 RecEdit und Skins

Zitat von louis

Hi alle und insbesondere Klaus,

ich habe mir mal den VDR 2.1.2 installiert und die neuen Aufnahme-Editier Funktionen mit nOpacity getestet. Dabei sind mir zwei Sachen aufgefallen:

zum einen wird beim Aufruf des Aufnahme Editier Menüs die Menükategorie "mcRecording" gesetzt. Das sollte aus meiner Sicht eine eigene Kategorie "mcRecordingEdit" (analog zu "mcChannelEdit") sein. Ansonsten behandelt ein Skin, der die Menükategorien zur Darstellung auswertet, dieses Menü falsch.

OK.

Zitat

Zum zweiten ein generelles Problem, das im Aufnahme Editier Menü zum tragen kommt: ich scrolle in nOpacity Felder, die zu lang sind, auch in "normal" dargestellten Menüs. Wenn nun ein Feld, dessen Text mit den VDR Mitteln editiert werden soll, länger ist als der zur Verfügung stehende Platz, dann kollidiert das Scrollen mit dem Editieren. Ich frage mich nun, wie ich das am besten abfange. Woher kann ich wissen, dass ein Eintrag gerade editiert wird und ich deswegen das scrollen unterdrücken muss? Ggf. könnte ich in bei den entsprechenden *mc*Edit" Menükategorien (falls Klaus übereinstimmt und mcRecordingEdit einbaut) ganz auf scrollen verzichten...das würde dieses Problem punktuell für das Aufnahmemenü fixen. Das wäre aber keine generelle Lösung, beispielsweise könnte bei einem Plugin ja auch genau dieser Fall auftreten. Eventuell würde es Sinn machen, die Funktion

Code

cDisplayMenu::SetItem(const char *Text, int Index, bool Current, bool Selectable)

zu

Code

cDisplayMenu::SetItem(const char *Text, int Index, bool Current, bool Selectable, bool isEdited)

zu erweitern? Das wäre natürlich nicht abwärtskompatibel...

Alles anzeigen

Um es abwärtskompatibel zu machen würde es sich vielleicht anbieten, es so zu machen

cDisplayMenu::SetItem(const char *Text, int Index, int Flags)

mit den eItemFlags ifCurrent, ifSelectable, ifEditing. Diese Funktion würde dann in der Default-Implementierung die ursprüngliche so aufrufen:

void cDisplayMenu::SetItem(const char *Text, int Index, int Flags)
{
  cDisplayMenu::SetItem(Text, Index, Flags & ifCurrent, Flags & ifSelectable);
}

und wenn eine Skin das ifEditing auswerten will, dann überschreibt es diese Funktion einfach.
VDR selber wird nur noch die neue Funktion aufrufen, und die alte wird "deprecated" und verschwindet irgendwann mal ganz.
Die Flags hätten den Vorteil, daß sie eventuelle künftige Erweiterungen ohne Interface-Änderung erlauben.

Klaus

Zitat von louis

Hi Klaus,

clever Wäre cool, wenn du das in die nächste Entwicklerversion so einbauen könntest.

Mach ich.

Zitat

Was ich mich generell frage: habe ich eigentlich eine Chance, wenn ich mit nOpacity Features aus der Entwicklerversion umsetzen will, aber trotzdem noch Kompatibel zur 2.0 sein will, ohne Präprozessor Macros auszukommen?

Ohne #if's dürfte das schwierig werden. Aber genau dafür gibt es doch das APIVERSNUM-Macro...

Zitat

Ausser einen eigenen Fork für VDR 2.1.x anzulegen, das würde mir auch nicht so passen.

Das mache ich bei VDR aber auch nicht anders. Wobei da halt die Developer-Version die Haupt-Entwicklungslinie ist und momentan für die 2.0.x ein Seitenzweig gepflegt wird, in dem nur noch Bugs gefixt und kleinere (voll kompatible) Verbesserungen eingepflegt werden.

Klaus

Ich habe jetzt mal versucht, die Änderung für das Erkennen des "editiert werdens" einzubauen, aber das zieht ziemlich Kreise und die Information, daß ein Item gerade editiert wird, ist an den entscheidenden Stellen nicht ohne weiteres verfügbar.
Ich werde das daher doch nicht machen, sorry.

Als Workaround könntest du ja vielleicht die eckigen Klammern als Indikator verwenden.

Klaus

Strings können beim Editieren doch eigentlich nie zu lang werden, da VDR in cMenuEditStrItem:: Set anhand der EditableWidth() die max. Anzahl Zeichen bestimmt und bei längeren Strings am Anfang und Ende ein '<' bzw '>' anzeigt. Damit wird ja automatisch nicht mehr gescrollt solange editiert wird, so ist das bei skinElchi auch "gelöst".