[Patch] Menüelemente mit der Rechts-Taste auswählen

[dbt]

Hier eine Version, die für die dbox verträglich sein dürfte, also ohne dass die Buttons immer gemalt werden. Sollte aber im Code selbst ein Parameter mit Button angegeben sein, wird der natürlich gemalt.
Edit: Patch entfernt, ist im CVS
Wie wäre denn der Geschwindigkeitsunterschied, wenn man nun keine Icons lädt, sondern die graue Box
vorm Rendern der Ziffern, mit einer neuen Funktion im FB, malt?[/quote]
Wenn der Schrifthintergrund passen würde, dann sähe das auch nach was aus, aber da müsste mal jemand am fontrenderer schrauben, damit man jeden beliebigen Schrifthintergrund nehmen kann. Hier was Unfertiges, wenn sich jemand das zurechtbauen will:
Edit: Patch entfernt

PS: Die Buttons sind cool, Vorsichtig anfrag: kannst du die anderen auch dazu passend machen.

[GetAway]

Joa.
Warum werden die Farbbuttons mit 16x16 korrekt dargestellt und die
NumNavi-Buttons farbverfälscht, wenn ich die auf 16x16 zurechtstutze?

Beispiel: 1. mit 16x16, 2. mit 24x24

[dbt]

Vermutlich irgendwie die Transparentfarbe nicht richtig zugewiesen?

[rhabarber1848]

Hier eine Version, die für die dbox verträglich sein dürfte, also ohne dass die Buttons immer gemalt werden. Sollte aber im Code selbst ein Parameter mit Button angegeben sein, wird der natürlich gemalt.
menue_buttons_reworked_2010-05-06-22-25.patch

Sieht das Hauptmenü nur bei mir so aus?

[dbt]

Falscher Patch? Das ist der Unfertige!
Edit: Link ist korrigiert
Edit: Patch entfernt, ist im CVS

[mb405]

ich finde die icons von getaway sehr schick. der pfeil nach rechts wird hier bei mir nicht überall angezeigt. ka woran das liegt. vielleicht in den aufruf.
CMenuForwarder is ja ok aber
in CMenuOptionChooser muss das dann auch noch rein. ka wo es noch fehlt.

[GetAway]

Vermutlich irgendwie die Transparentfarbe nicht richtig zugewiesen?

Stimmt.

Hier mal ein neues Archiv mit den möglichen Button in 16x16. Menü- und Exit-Button werden zwar nicht benutzt,
habe sie aber trotzdem angepasst. In einigen Menüs rutschen die Button etwas zu hoch, liegt vermutlich an dem
starren Code in einigen Quellen und der zusätzlichen Minimierung auf 16x16.
(Filmarchiv+Moviefilebrowser, Zurück-Button, etc.)

Die beigepackten small_button würden dann eigentlich überflüssig. Muss halt der Code angepasst werden.

new_icons.rar

[dbt]

In einigen Menüs rutschen die Button etwas zu hoch, liegt vermutlich an dem
starren Code in einigen Quellen und der zusätzlichen Minimierung auf 16x16.
(Filmarchiv+Moviefilebrowser, Zurück-Button, etc.)

Das ist erst mal nicht das Problem, das hatte ich im Lauf der Zeit schon an einigen Stellen überarbeitet, aber wenn man mal eine Liste hat wo das noch repariert werden muss, wäre das hilfreich. So kommt man wenigstens drauf, dass hier noch Relikte drin sind

[dbt]

...
in CMenuOptionChooser muss das dann auch noch rein. ka wo es noch fehlt.

Da nicht, da steht OK. Soll es zumindest.

[mb405]

mhh eine durchgängige logische bedienung ist aber besser
ich hab mal in der funktion

int CMenuOptionChooser::paint( bool selected )

Code: Alles auswählen

/*if (!(iconName.empty()))
	{
		int icon_x = (x+(stringstartposName-x)/2) - (frameBuffer->getIconWidth(iconName.c_str())/2);
		int icon_y = (height/2- frameBuffer->getIconHeight(iconName.c_str())/2);
		frameBuffer->paintIcon(iconName, icon_x, y + icon_y);
	}*/
	std::string icon_name = iconName;
	if (selected)
	{
		if ((CRCInput::isNumeric(directKey)) || (directKey >= CRCInput::RC_red && directKey <= CRCInput::RC_blue) || directKey == CRCInput::RC_help || directKey == CRCInput::RC_setup || icon_name.empty())
			icon_name = NEUTRINO_ICON_BUTTON_RIGHT;
	}
	int icon_w = frameBuffer->getIconWidth(icon_name.c_str());
	int icon_h = frameBuffer->getIconHeight(icon_name.c_str());

	if (!icon_name.empty() && active  && icon_w>0 && icon_h>0)
	{
		int icon_x = (x+(stringstartposName-x)/2) - (icon_w/2);
		frameBuffer->paintIcon(icon_name, icon_x, y+ ((height/2- icon_h/2)) );
	}

dann ist alles ok.
man kann ja optionen auch mit -> schalten und mit ok. also ist das passend

[dbt]

So fällt aber nicht auf, dass man nur eine Option schaltet. Der Pfeil soll vermitteln, dass es hier weiter geht, also ein Untermenü oder eine App zum Vorschein kommt.

[rhabarber1848]

Falscher Patch? Das ist der unfertige!
Edit: Link ist korrigiert
menue_buttons_reworked_2010-05-06-22-25.patch

jetzt ist wieder alles ok, danke!

[dbt]

Das war der 2. von hier http://www.tuxbox-cvs.sourceforge.net/f ... 72#p376772. Der war ja nur voll unfertig, den hatte ich wohl verdreht

[mb405]

So fällt aber nicht auf, dass man nur eine Option schaltet. Der Pfeil soll vermitteln, dass es hier weiter geht, also ein Untermenü oder eine App zum Vorschein kommt.

is mir schon klar. nur dann dürfte da die nach rechts taste nicht funktionieren. das tut sie aber bei dem menüs.

[mb405]

ich hatte wohl den falschen patch drin
jetz gehts so wies soll auch ok ist da. klasse.
einchecken, damit nix verloren geht.

@GetAway
irgendwie schmiert bei mir neutrino ab, wenn ich deine icons reinbastel.
das dbox.raw icon bringt channellist zum abkacken. alle anderen gehen und sehen geil aus

[dbt]

Ja, das sind vlt. diverse Imagehacks oder noch Relikte...die übrigens im Neutrino-HD auch noch für einiges an Arbeit und Ärger sorgen dürften, weil hier noch sehr viel wegen des antiken Basis Softwarestandes hardcoded ist. Hier wird es sicher den einen oder Anderen etwas Kopfschmerzen bereiten, da es dort scheinbar wo's mal auffällt oft nur geflickt wird und der mangelhafte Hardwarezugang tut sein Übriges, nicht sehr lustig das ganze.
Edit: ist im CVS, fehlen noch die neuen icons

[Gaucho316]

Ich habe jetzt noch einige andere Stellen entdeckt, an denen Fehler folgender Art auftreten. Der Einfachheit halber habe ich jetzt mal rhabarber1848s Foto recycelt:


Das kommt immer dann zustande, wenn ein Menü ganz ohne Icons aufgebaut wird. Kann man den Code nicht so ändern, dass in solchen Menüs auch die Markierungs-Icons (Rechtspfeil, OK) nicht gezeichnet werden?

[GetAway]

Bei mir sieht das eigentlich so aus, welche Menü's sind das denn?


Andere Frage: Bei dem Menüpunkten bei denen nicht der Pfeil sondern "OK" eingeblendet wird
sind beide Tasten möglich, also rechter Pfeil oder OK. Ist das Absicht oder sollte bei diesen
Punkten das Ausführen der rechten Taste unterbunden sein?

[dwilx]

Bei mir sieht das eigentlich so aus, welche Menü's sind das denn?

Ja genau, das wurde doch schon gefixt, auch in der Aufnahmeverzeichnisauswahl ist das jetzt in Ordnung.

[Gaucho316]

Das Bild war nur ein Beispiel, wie es dort aussieht, wenn die Icons über das Fenster hinausragen. Ich hatte keine Lust, einen neuen Screenshot zu erstellen. Nach dem Schließen des Menüs bleiben übrigens Reste der Icons auf dem Bildschirm übrig. Aufgefallen ist es mir u.a. in der Kanalauswahlliste der Timer und auch im Bookmark-Menü (blaue Taste) des Movieplayer1, wenn man den Movieplayer in Kombination mit dem Moviebrowser nutzt. Es gibt aber ganz bestimmt noch viel mehr Stellen.


Edit:
Könnte es sein, dass folgende einfache Änderung in der Zeile 106 der menue.cpp hilft? Ich kann's leider erst heute Abend ausprobieren.

Alt:

Code: Alles auswählen

if (selected)

Neu:

Code: Alles auswählen

if (selected && offx > 0)

[dbt]

Andere Frage: Bei dem Menüpunkten bei denen nicht der Pfeil sondern "OK" eingeblendet wird
sind beide Tasten möglich, also rechter Pfeil oder OK. Ist das Absicht oder sollte bei diesen
Punkten das Ausführen der rechten Taste unterbunden sein?

Ist im Moment erstmal so mehr oder weniger naturbelassen, weil, wie schon mal gesagt wurde, das OK rein optisch vermitteln soll, dass es sich um kein Untermenü oder App handelt, sondern um einen Optionsschalter. Der umgekehrte Weg geht ja auch, also da wo -> oder <- steht, geht ja auch die OK-Taste. Dann müsste man das ja auch aus dem Verkehr ziehen, desahlb würde ich da vorerst nichts ändern und es dem Benutzer überlassen, wie er navigiert. Alternativ kann man auch ein Icon nehmen, dass abegwandelt beide Symbole enthält ->OK.

Ich habe jetzt noch einige andere Stellen entdeckt, an denen Fehler folgender Art auftreten. Der Einfachheit halber habe ...
Das kommt immer dann zustande, wenn ein Menü ganz ohne Icons aufgebaut wird. Kann man den Code nicht so ändern, dass in solchen Menüs auch die Markierungs-Icons (Rechtspfeil, OK) nicht gezeichnet werden?

Klar Hide macht ja nur den eigentlichen Bereich des Menüs wieder sauber. Einige solche Stellen hatte ich ja schon gefixt, und den fehlenden Back-Button dahin gestellt, da gehört er auch meiner Meinung nach hin. Das sollte sich dann schon wegen der Konvention durch die komplette GUI ziehen. Es ist halt für den Benutzer besser, dass er ohne großes Nachdenken sieht, dass er sich in einem Menüfenster befindet, sowas ist halt einprägsam, wenn man das optisch vermittelt bekommt.
Für das Zapitmenü fällt das sogar extrem aus, weil hier 2 Untermenüs nacheinander ohne Navi drin sind. Das ist in dem Fall aber bereits an der Stelle zwangsläufig gefixt:
http://www.tuxbox-cvs.sourceforge.net/f ... 12#p376812
Das müsste nur noch mal getestet werden, dann wäre das auch erledigt.

...
Edit:
Könnte es sein, dass folgende einfache Änderung in der Zeile 106 der menue.cpp hilft? Ich kann's leider erst heute Abend ausprobieren.

Alt:

Code: Alles auswählen

if (selected)

Neu:

Code: Alles auswählen

if (selected && offx > 0)

Das funktioniert .

[dbt]

Nochwas: Audio-Auswahl_Menü entsprechend angepasst:
audio_select.cpp-diff-2010-06-09-21-50-58.patch
Die Funktion sollte sich dadurch nicht ändern, das wäre zu testen.

[GetAway]

@dbt

Hier hat sich ein Bug eingeschlichen.
Beim Wechsel des Scan Mode in Scan Modi und verlassen des Menü's sieht es so aus.

[dbt]

Das ist schon länger, da bin ich auch am suchen. Hat aber hiermit eigentlich nichts zu tun.

[mb405]

hehe jo das ganze scan menü ist schon seit anfang an irgendwie kaputt.
ich hab ja auch schon meine fehler an anderer stelle gepostet.