-
Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.
Blocking API: Neues Userinterface
- Ersteller Charlenni
- Erstellt am
Ach deswegen die Frage neulich wegen den Callbacks, is von dir das Interface oder ? Wie ichs versteh ist das "nur" für Programmierer die von Hand stricken, insofern kein besonders großes Publikum. Sowas müsste sinnigerweise in Urwigo rein, nur inwieweit sich am Endergebnis was ändert, ist mir nicht so klar, vermutlich nix. Dialog, Message und Messagebutton bleiben "nach außen" Dialog, Message und Messagebutton, egal was unter der Haube passiert.
Öhm, soweit ich das jetzt auf den 1.Blick checke.
Öhm, soweit ich das jetzt auf den 1.Blick checke.
Ja, deswegen die Frage und nein, der Code stammt nicht von mir, sondern von Jan. Wir haben uns nur darüber unterhalten. Und da die deutschsprachige Wherigo-Gemeinde recht aktiv ist (war?), hat es sich angeboten, hier mal nachzufragen.
Es stimmt, dass diese Dinge im Augenblick nicht direkt in Urwigo eingebaut sind. Die Idee dahinter ist, dass das bisherige System für Anfänger schwer zu verstehen ist. Das neue System wäre demgegenüber sehr viel einfacher. Man könnte nicht nur einen Dialog oder einen MessageBox in einer Funktion unterbringen und den Rest in Callbacks auslagern, sondern alle relevanten Dinge auf einmal abhaken. Z.B. könnte man beim Betreten einer Zone (OnEnter) eine Nachricht anzeigen (UI.Message), dann eine Abfrage machen (UI.Input), diese Auswertung und die Lösung anzeigen. Keine weitere Callback-Funktion, kein OnGetInput.
An der Oberfläche bei Garmins kann ja nichts geänder werden, aber an der Programmierung schon. Z.B. ist es ja auch interessant, wenn man nicht immer schauen muss, ob der Input-Dialog beantwortet wurde oder wie ihn der Spieler wieder starten kann. Mit UI.Input ist sicher gestellt, dass er nur dann vom Schirm verschwindet, wenn ihn der Spieler beantwortet (ob richtig oder mit abbrechen) oder ich als Programmierer das so einstelle. Läuft der Spieler in eine andere Zone und dort wird wieder etwas angezeigt, dann wird der Input nicht überschrieben.
Das System hat also schon seine Vorteile.
Es wäre nett, wenn Ihr es Euch nochmals etwas genauer anschauen würdet. Sicher kann man das eine oder andere noch verbessern. Deshalb hat Jan ja gefragt. Und wenn das mit dem Englisch zu unverständlich ist, dann kann ich es auch gerne auf Wunsch in Kurzform auf Deutsch erklären.
Es stimmt, dass diese Dinge im Augenblick nicht direkt in Urwigo eingebaut sind. Die Idee dahinter ist, dass das bisherige System für Anfänger schwer zu verstehen ist. Das neue System wäre demgegenüber sehr viel einfacher. Man könnte nicht nur einen Dialog oder einen MessageBox in einer Funktion unterbringen und den Rest in Callbacks auslagern, sondern alle relevanten Dinge auf einmal abhaken. Z.B. könnte man beim Betreten einer Zone (OnEnter) eine Nachricht anzeigen (UI.Message), dann eine Abfrage machen (UI.Input), diese Auswertung und die Lösung anzeigen. Keine weitere Callback-Funktion, kein OnGetInput.
An der Oberfläche bei Garmins kann ja nichts geänder werden, aber an der Programmierung schon. Z.B. ist es ja auch interessant, wenn man nicht immer schauen muss, ob der Input-Dialog beantwortet wurde oder wie ihn der Spieler wieder starten kann. Mit UI.Input ist sicher gestellt, dass er nur dann vom Schirm verschwindet, wenn ihn der Spieler beantwortet (ob richtig oder mit abbrechen) oder ich als Programmierer das so einstelle. Läuft der Spieler in eine andere Zone und dort wird wieder etwas angezeigt, dann wird der Input nicht überschrieben.
Das System hat also schon seine Vorteile.
Es wäre nett, wenn Ihr es Euch nochmals etwas genauer anschauen würdet. Sicher kann man das eine oder andere noch verbessern. Deshalb hat Jan ja gefragt. Und wenn das mit dem Englisch zu unverständlich ist, dann kann ich es auch gerne auf Wunsch in Kurzform auf Deutsch erklären.
Krolock
Geocacher
Prinzipiell sieht die Idee ganz gut aus, wesentlich einfacher als das bisherige MessageBox-System.
Mir macht aber der Einwand
Sorgen. Vorallem was die Unterstützung der Player insbesondere Garmin betrifft. Wenn die noch nicht mal in ihrer neuen Oregonserie den WIG-Player anbieten, dann werden die auf keinen Fall den Player für ein 5 Jahre altes Gerät aktualisieren. Das Oregon wird zwar immer mehr von Smartphones abgelöst aber meine Beobachtungen gehen davon aus, das jeder zweite WIG noch mit dem Garmin-Gerät gelaufen wird.
Mir macht aber der Einwand
Code:
we would have a compatibility nightmare on our hands.Da kann ich Dich beruhigen: wird auch so mit den Garmin Geräten funktionieren. Das Einzige, was nicht klappen wird, ist, dass man eine Nachricht nicht abbrechen kann. Da wird dann auf Garmingeräten eine Meldung kommen, dass der Dialog abgebrochen wurde. Die muss dann mit Ok bestätigt werden. Liegt daran, dass Garmin Geräte keine Funktion dafür haben, den Dialog vom Schirm zu nehemen.
Es freut mich, dass wenigsten 2 Leute sich noch näher mit Wherigo beschäftigen. Das lässt hoffen.
Es freut mich, dass wenigsten 2 Leute sich noch näher mit Wherigo beschäftigen. Das lässt hoffen.
Krolock
Geocacher
D.h die neue Api wird als Hi-Level-Kapselung auf den bestehenden Befehlsatz aufgesetzt und muss von Buildern wie Urwigo umgesetzt werden oder ist die UI Bibliothek mit den Message, Input und Choice Bausteinen bereits in den bishierigen lua-Interpreten enthalten.
Ich hatte das als Teil von Wherigo 2.0 vestanden.
Dazu hab ich übrigens nen interessanten Link gefunden:
http://www.gocacher.de/?p=2535
Ich hatte das als Teil von Wherigo 2.0 vestanden.
Dazu hab ich übrigens nen interessanten Link gefunden:
http://www.gocacher.de/?p=2535
Alles in allem sind es ca. 200 Zeilen Code, die man einfach in den Author Script Bereich kopiert. Fertig. Schon kann man die Funktionen nutzen.
Der Alptraum bezieht sich darauf, wenn Du alte und neue Funktionen mischt. Das sollte man tunlichs unterlassen. Sonst kommen die neuen Funktionen durcheinander, da sie ja im Hintergrund die Seiten, die angezeigt werden sollen, speichert. Wenn nun eine andere zwischendurch angezeigt wird, dann gibt es Probleme.
Der Alptraum bezieht sich darauf, wenn Du alte und neue Funktionen mischt. Das sollte man tunlichs unterlassen. Sonst kommen die neuen Funktionen durcheinander, da sie ja im Hintergrund die Seiten, die angezeigt werden sollen, speichert. Wenn nun eine andere zwischendurch angezeigt wird, dann gibt es Probleme.
Geheim halten ist ein großes Wort. Wenn Du ihm eine kurze Nachricht schickst, dann lässt er Dir den Code zukommen. Er soll einfach nur nicht für alle Zeiten auf irgendeiner Internet-Seite stehen, da es doch noch einige Änderungen geben kann. Und wenn es dann wieder 20 verschiedene Lösungen mit ungefähr doppelt so vielen Fehler gibt, dann ärgern wir uns wieder.
bodenseepingu
Geomaster
Hört sich interessant an, was Jan da vorschlägt. Im Moment arbeite ich bei Inputs eigtl. zu 100% mit den Urwigo-Inputs - also ZInput - bei Auswahl-Menüs mache ich öfter mal Cartridges bei denen ich die Auswahlen dynamisch dazuhänge (ZInput.Choices table) - da wird das eher einfacher mit dem neuen Api.
Mir ist nur noch nicht klar, wie schnell und wie gut sich dann das neue API mit Urwigo in der jetzigen Form einsetzen lässt bzw. was man dann auf keinen Fall mehr benutzen darf.
Ach ja - in letzter Zeit habe ich einige internationale Cartridges - und da gehe ich dann über alle Wherigo Objekte drüber und ersetze - bei ZInput ersetze ich die Fragetexte - manchmal auch die Choices - da sehe ich jetzt keine Probleme, das anzupassen...Bei Messageboxen hole ich mir die Texte so oder so über eine LUA-Funktion aus einer Table - Dialoge verwende ich bei internationalisierten Cartridges im Moment nicht.
Mir ist nur noch nicht klar, wie schnell und wie gut sich dann das neue API mit Urwigo in der jetzigen Form einsetzen lässt bzw. was man dann auf keinen Fall mehr benutzen darf.
Ach ja - in letzter Zeit habe ich einige internationale Cartridges - und da gehe ich dann über alle Wherigo Objekte drüber und ersetze - bei ZInput ersetze ich die Fragetexte - manchmal auch die Choices - da sehe ich jetzt keine Probleme, das anzupassen...Bei Messageboxen hole ich mir die Texte so oder so über eine LUA-Funktion aus einer Table - Dialoge verwende ich bei internationalisierten Cartridges im Moment nicht.
Leider geht die Einbindung in Urwigo noch nicht nahtlos. Es geht im ersten Schritt auch erstmal darum abzuklären, ob das überhaupt funktioniert und ob eventuell eine Funktion fehlt, die noch dazu muss.
Sinn und Zweck des Ganzen ist ja, die Schwelle für Cartridge Designer herab zu setzten. Oft stolpern Anfänger ja über MessageBoxen und Dialoge. Vielen machen zwei und mehr MessageBoxen in eine Funktion und wundern sich dann, warum nur die letzte Angezeigt wird. Oder eine Eingabe wird von einer MessageBox überschrieben und es wird eine Möglichkeit vergessen, diese nochmals aufzurufen und zu beantworten. Oder man hat Dutzende von Callbacks von MessageBoxen, um eine logische Kette aufzubauen. All dies könnte mit dem neuen System verhindert werden.
Die Cartridge wäre am Ende wesentlich übersichtlicher. Alles könnte in einer Funktion, z.B. in OnEnter einer Zone gemacht werden. Erklärung, Frage und Auswertung der Antwort würden direkt untereinander stehen. Kein langes Suchen mehr, was denn wo steht.
@Bodenseepingu: Wie machst Du das mit dem Ersetzen? Aus einer Tabelle raussuchen? Wenn ja, machst Du auch eine Obfuscation der Texte oder einfach nur Klartext?
Sinn und Zweck des Ganzen ist ja, die Schwelle für Cartridge Designer herab zu setzten. Oft stolpern Anfänger ja über MessageBoxen und Dialoge. Vielen machen zwei und mehr MessageBoxen in eine Funktion und wundern sich dann, warum nur die letzte Angezeigt wird. Oder eine Eingabe wird von einer MessageBox überschrieben und es wird eine Möglichkeit vergessen, diese nochmals aufzurufen und zu beantworten. Oder man hat Dutzende von Callbacks von MessageBoxen, um eine logische Kette aufzubauen. All dies könnte mit dem neuen System verhindert werden.
Die Cartridge wäre am Ende wesentlich übersichtlicher. Alles könnte in einer Funktion, z.B. in OnEnter einer Zone gemacht werden. Erklärung, Frage und Auswertung der Antwort würden direkt untereinander stehen. Kein langes Suchen mehr, was denn wo steht.
@Bodenseepingu: Wie machst Du das mit dem Ersetzen? Aus einer Tabelle raussuchen? Wenn ja, machst Du auch eine Obfuscation der Texte oder einfach nur Klartext?
Ich habe Jan auf diesen Thread hier aufmerksam gemacht. Er meinte, wenn es jemand leichter fällt, wenn er die Anfrage auf deutsch stellt, dann könnte ich das übernehmen.
Also, wenn jemand am Quellcode Interesse hat, dann einfach bei mir melden. Dann lässt es sich gleich besser diskutieren.
Also, wenn jemand am Quellcode Interesse hat, dann einfach bei mir melden. Dann lässt es sich gleich besser diskutieren.