amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Jetzt nochmal das Notify [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 [ - Beitrag schreiben - ]

22.07.2011, 11:29 Uhr

AGSzabo
Posts: 1663
Nutzer
Da es bisher nicht geklärt wurde, ich möchte ein Notify in mein GUI schreiben.

Dazu habe ich bisher in jedem Objekt eine Liste mit Empfängern und um die anzusprechen ruft das sendende Objekt oxDoNotify( self, methodID, message) auf. MethodID und message werden dann an jedes Objekt der Notify-Liste gesendet. Nun kommt es aber vor, dass ich keine Methode verschicken will, sondern ein geändertes Attribut. Zudem könnte dieses Attribut vom Ziel nicht verstanden werden und ich würde deswegen ein map einbauen, mit der alten und neuen AttributID.

Eine Methode braucht man senden, wenn zwei oder mehr Attribute, die voneinander abhängen, auf einmal gesendet werden müssen, zB die pot/max/body eines Propgadets, welche die Liste bei einer Änderung an ihren Slider sendet. Dem Slider langt es aber, bei einer Bewegung nur pot an die Liste zu senden.

Ich konnte mich bisher nicht entscheiden, wie ich den Unterhschied zwischen dem Senden eines Attributes und einer Methode implementieren soll. Könnte man es mit einem extra oxDoNotifyAttr() machen? Wie würdet ihr es programmieren?

ps: Binding reicht mir nicht.

pps: in MUI reagiert ein Notify direkt auf die Änderung eines Attributes. Aber was ist, wenn sich wie in meinem Fall gleich drei Attribute ändern und man alle drei gleichzeitig zur Neuberechnung der verbundenen Wert braucht?

--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 22.07.2011 um 11:39 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 15:49 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Also müssen wir erstmal klären, was ein "notify" bedeuten soll.
Bei mir bedeutet das was völlig anderes, nämlich die Information die an den App Programmierer geht. Aber vergessen wir das erstmal, denn dei dir geht es eher darum, Objekte zu manipulieren bzw. zu binden.

Also das sind erstmal zwei verschiedene Dinge, manipulieren und binden.

Bei mir (NTUI) kann man Objekte nur über SetAttr modifizieren.
So hat man alle Änderungen schön an einem Platz und kann das gut implementieren. Ich habe bisher noch keine Änderung gebraucht, die mehrere Attribute auf einmal benötigt.
Bei meinem Slider setze ich pot/max/body nacheinander, wobei das bei mir value, minvalue und maxvalue heißt.
Die Attribute werden selbstverständlich überprüft, deshalb setzt man zuerst min/max, und danach das value. Wenn man value zuerst setzt, könnte es ja geclippt werden wenn es vorher nicht in den min/max Grenzen war.
Ausser der Abhängigkeit der Reihenfolge ergibt sich aber sonst keinerlei Problem. Wo siehst du das Probleme (interessiert mich, evtl. habe ich was übersehen?)

Extra Methoden haben meine Objekte nicht, nur die Standard Methoden.
Als kleine "Hintertürchen" kann man ja "Strobe"-Attribute machen, die eine Methode ausführen, aber bisher habe ich das eigentlich nicht benötigt, und ich habe schon so ziemlich alle Basis Widgets implementiert.

Das Binding hingegen ist was völlig anderes. Beim Binding habe ich, wie ich ja schon erwähnte, Objekte in einem Ring angeordnet. Jedesmal, wenn ei Object ein Attribute ändert, das es teilen möchte (z.b. Value, String, MaxValue, MinValue, Disabled etc.), dann schickt es ein Binding Event durch den Ring. Der Unterschied zwischen dem Binding Event und dem SetAttr ist, dass es nicht wiederum eine Binding Aktion auslöst (was ja fatal wäre), und dass der Wert nicht unbedingt vom empfänger angenommen werden muss, das hängt davon ab ob das Empfänger Object dieses Attribute auch wirklich teilen will.
Z.b. teilt ein Slider sein Integer Value, aber ein Button (z.b. der Arrow Button) nicht, da hier der Integer für den gedrückt/nichtgedrückt Zustand verwendet wird. BZW, er kann ihn Teilen, aber nicht über eine HVALUE Message, sondern über eine ON/OFF Message o.ä.
Z.b. H und V Slider benutzen unterschiedliche Binding Events für jeweils ihre Integer Values, die man aber beide mit SetAttr(TUIA_VALUE,n) setzen würde.
Da hängt also nochmal eine Interpretationsebene dazwischen.



--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 16:12 Uhr

AGSzabo
Posts: 1663
Nutzer
@Der_Wanderer:

> Ausser der Abhängigkeit der Reihenfolge ergibt sich aber sonst keinerlei Problem.

Das ist mir Problem genug. Ich finde es unschön und fehleranfällig. Auch die Reihenfolge wie du bindest gefällt mir nicht. Ich löse es so, daß man beim erstellen einer Verbinung, jetzt mal egal ob Binding oder Notify, dem quellobjekt blos ein zeiger auf den zeiger auf das zielobjekt gegeben wird, wobei das system sobald es das zielobjekt erzeugt, dort den zeiger darauf reinschreibt. bis zur laufzeit ist alles korrekt initialisert. Nun ist es egal wer zuerst kommt.

Zudem werden die zeiger auf wunsch nicht von einer festen adresse gelesen und gespeichert, sondern per offste relativ zu einem buffer, der im fall der scrollview in deren objektstruktur liegt.

da die scrollview aber auf view und sliders aufbaut, wäre es gut, wenn sie die selben attribute wie die view unterstützen könnte (zb "erlaube horizontales wachstum"), das tut sie aber im moment noch nicht. Man muß der scrollview eigene attribute geben, die sie dann an die view weiterleitet. das ist unpraktisch.

"Value" find ich gut, da kann man gleich ein globales attribut draus machen, das von listen, slidern und stringgadgets im zahlenmodus verstanden wird. blos ein kleiner schönheitsfehler bei mir: slider arbeiten intern immer mit max = $ffff und daran angepassten min und value werten. diesen so gearteten value senden sie auch an die liste, welche die werte wiederum in ihr eigenes min/max/value übersetzt... machst du das anders?

Kannst du mir Strobe näher erklären?

> H und V Slider benutzen unterschiedliche Binding Events für jeweils ihre Integer Values

Wenn der vertikale slider mit einem horizontalen gauge-balken verbunden sein soll, hast du da ein problem. das meinte ich zu lösen mit "map" tags, wo aus einem attributID ein anderes wird.

--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 22.07.2011 um 16:20 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 16:24 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Die Reihenfolge beim Binding ist kein echtes Problem. Ich kann mit dem Binden ja warten, bis alle Objekte erzeugt sind, und dann die Bindings vornehmen. Unschön finde ich, Pointer auf Pointer oder sonstige Hacks zu machen, damit man mit etwas arbeiten kann was noch nicht existiert. Was du da beschreibst hört sich für mich sehr umständlich und "mit dem Auge durch die Brust ins Ohr" an.

Die Core-Funktion heißt bei mir Bind(Object a, Object b), a und b müssen logischerweise existieren.

Es ist lediglich Sache das XML Parsers (bzw. um Holger zu Frieden zu stellen, des anschließenden Interpreters der Informationen), wann er das nun aufruft. Kann er wie gesagt, aber auch am Ende machen, tut ja niemandem weh.

Du kannst ja auch kein Draw(Object) oder SetAttr(Object) machen, bevor das Object existiert, warum sollte das bei einem Bind anders sein?


--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von Der_Wanderer am 22.07.2011 um 16:25 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 16:28 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Erstmal Slider!=Scroller.


Beide arbeiten bei mir mit 32bit Integers, wobei 64bit sogar besser wäre, aber in AB3 geht das nicht so schön. Warum auf 16bit beschränken? Das finde ich bei Gadtools den größten Krampf den es gibt.

Des weiteren skaliere ich das nicht nocheinmal, warum sollte man das tun?

Der User setzt seine min/max.

Wenn ich einen View zwischen -100 und +400 scrollen lassen will, dann nehme ich genau diese Werte. Ich sehen keine Notwendigkeit, das intern umzurechnen und auf 0...0xFFFF zu skalieren. Nur Nachteile durch ab/aufrunden.
--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 16:31 Uhr

AGSzabo
Posts: 1663
Nutzer
@Der_Wanderer:

> Du kannst ja auch kein Draw(Object) oder SetAttr(Object) machen, bevor das Object existiert, warum sollte das bei einem Bind anders sein?

Weil ich es umständlich finde, daß

- man sich das binding merken muss bis nacher
- dass man den objekten eine id geben muss, bzw nach dem Erzeugen eine Funktion aufrufen muss.

Naja, geschmackssache. Dem einen erscheint das eine umständlich, dem anderen das andere. Wenn ich mir bis nacher die pointer auf die objekte irgendwie merken muss um zu binden kann ich auch nen pointer auf nen pointer merken.

--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 22.07.2011 um 16:34 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 16:32 Uhr

Der_Wanderer
Posts: 1229
Nutzer
"Strobe" heisst, dass das SetAttr gar kein Attrbiute setzt, sondern eine aktion auslöst.

Z.b.

SetAttr(Object,TUIA_DO_MY_FUNCTION,True);

Habe ich bisher aber noch nicht gebraucht.
SetAttr() wird quasi als DoMethod() missbraucht. Letztendlich ist ja aber auch alles das gleiche.


--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 16:35 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Klar, das Binding bei mir hat Grenzen.
Würde ich einen StatusBar mit einem Scroller (Achtung, nicht Slider!) verknüpfen wollen (der Sinn sei mal dahin gestellt), dann müsste ich ene CallBack machen auf den Scroller der dann "SetAttr(StatusBar,TUIA_Value,scrollerPosition)" macht.
Oder mit eine Message vom Scroller schicken lassen und dann im App Kontext den StatusBar setzen.

Hier gilt aber die Regel:
Was oft vorkommt, ist super einfach. Was selten vorkommt, braucht mehr Codezeilen aber ist machbar.

Vermutlich würdest du aber lieber einen Slider mit einem StatusBar verknüpfen wollen. Und der hat nur ein Value, ohne H/V, weil beim Scroller H/V nicht wichtig ist, nur für die Darstellung, aber ohne semantische Bedeutung wie beim Scroller.


--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 16:35 Uhr

AGSzabo
Posts: 1663
Nutzer
@Der_Wanderer:

> Letztendlich ist ja aber auch alles das gleiche.

Eben. :D

(auch slider und scroller)
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 22.07.2011 um 16:38 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 16:50 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Zitat:
Original von AGSzabo:
@Der_Wanderer:

> Du kannst ja auch kein Draw(Object) oder SetAttr(Object) machen, bevor das Object existiert, warum sollte das bei einem Bind anders sein?

Weil ich es umständlich finde, daß

- man sich das binding merken muss bis nacher

Nein, du verstehst das nicht ganz denke ich.
Bei XML ist das überhaupt nicht umständlich für den App Programmierer, ehrlich gesagt kann es eigentlich nicht einfach gehen.
code:
<object id="a" ...>
<object id="b" bind="a" ...>

oder
code:
<object id="a" bind="b"...>
<object id="b" bind="a" ...>

oder
code:
<object id="a" bind="b" ...>
<object id="b">

Ist egal, wie er das tut.

Für den GUI Toolkit Programmierer ist das auch nicht wirklich schwierig und vor allem nicht fehleranfällig.

Was machst du z.b. wenn das 2te Objekt nicht erzeugt werden kann? Dan hast du ratz fatz Nullpointer die du abfangen musst. Bei mir würde ein BindByID einfach die ID nicht finden und einen Fehler melden. Danach geht aber alles sauber weiter.

Zitat:
- dass man den objekten eine id geben muss, bzw nach dem Erzeugen eine Funktion aufrufen muss.
Der App Programmierer muss eine ID geben, wenn er XML benutzt, aber das will er ja auch.
Wenn er seine GUI Programmatisch erzeugt, dann macht e
code:
Object *a = CreateObject(...);
Object *b = CreateObject(...);
Bind(a,b);

Wie sollte es einfacher gehen?

Zitat:
Naja, geschmackssache. Dem einen erscheint das eine umständlich, dem anderen das andere. Wenn ich mir bis nacher die pointer auf die objekte irgendwie merken muss um zu binden kann ich auch nen pointer auf nen pointer merken.
Das ist nicht wirklich Geschmacksache. Dein Vorgehen ist einfach komplizierter.
Wenn ich das hier poste:
code:
Object *a = CreateObject(...);
Object *b = CreateObject(...);
Bind(a,b);

leuchtet das jedem sofort ein, selbst nicht-Programmierern (von der Bedeutung mal abgesehen, aber vom Ablauf). Deine Version habe ICH nichtmal wirklich verstanden. Und mit Pointer auf Pointer sind sowieso 99% der Menschheit überfordert.

Wenn jemand seine GUI Programmatisch erstellt, arbeitet er in der Regel sowieso mit Pointern auf die Objekte und merkst sich die.

Wenn jemand seine GUI mit XML erstellt, arbeitet er in der Regel mit den IDs und merkt sich die.

Und wir als GUI Toolkit programmierer bekommen das gerade noch hin, die Bindings auszuführen wenn beide Objects da sind, oder nicht? ;-)

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 16:54 Uhr

Der_Wanderer
Posts: 1229
Nutzer
@AGSzabo:
Nein, Slider und Scroller sind ganz verschiedene Widgets.

Ein Scroller hat eine Orientierung, Total, Visible und Top.

Ein Slider ist lediglich ein Widget zur Eingabe eines Wertes. Der Wert liegt zwischen min/max. Der "Knob" ändert auch seine Größe nicht. Die Orientierung ist unwichtig, und hat nur ergonomische Gründe.


--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 16:59 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Zu den Bindings wollte ich noch sagen, dass das eine relativ seltene Sache ist.
Bei vielen GUI Toolkits ist sowas nichtmal nach aussen gelegt, d.h. Bindings von User Seite aus müssen immer über CallBacks gehen.

Die Bindings sind hautsächlich dazu gedacht, Widgets mit mehr Features anzureichern, z.B. Scroller mit Arrows, Views mit Scrollern usw.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 17:01 Uhr

AGSzabo
Posts: 1663
Nutzer
@Der_Wanderer:

Slider / Scroller .. größe des knob, da gebe ich dir recht.


> Dan hast du ratz fatz Nullpointer die du abfangen musst.

Musst du auch beim senden deiner events, oder? Also wenn ein objekt kein binding hat, ist der next-zeiger leer.
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 22.07.2011 um 17:08 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 17:15 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Total, Visible und Top != Max, Min, Value.

Die Logik die dahintersteckt ist eine ganz andere.

Und um nochmal zur Frage zurückzukehren, woher das Bedürfnis die interne Repräsentation auf 0..0xFFFF zu normalisieren?

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 17:26 Uhr

AGSzabo
Posts: 1663
Nutzer
@Der_Wanderer:

> woher das Bedürfnis die interne Repräsentation auf 0..0xFFFF zu normalisieren?

Dummes Artefakt aus der Frühzeit der GUI-Geschichte?


edit: ah ja, das ist, damit elemente miteinander kommunizieren können, die verschiedene verhältnisse haben.

--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 22.07.2011 um 20:26 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.07.2011, 01:26 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
edit: ah ja, das ist, damit elemente miteinander kommunizieren können, die verschiedene verhältnisse haben.

Warum sollten sie das tun wollen?

Die Wertebereiche sind ja gerade deshalb unterschiedlich, weil Du einem bestimmten Gadgettypen den willkürlich gewählten Bereich von 0-0xffff aufzwingst.

Mir fällt absolut kein Praxisbeispiel ein, bei dem es sinnvoll wäre Objekte mit unterschiedlichen Wertebereichen zu koppeln.

@Der_Wanderer:

Mir ist ja schon bei Deinen Beispiel-XML aufgefallen, dass da nirgendwo schlüssig erkennbar ist, wie denn eigentlich die Anwendungslogik zum GUI kommt (oder umgekehrt). Da dachte ich noch, es läge an der Vereinfachung des Beispiels, aber jetzt bei der Binding Diskussion fällt es mir wieder auf.

Wenn ich GUIs mittels XML erzeuge, dann definiert die Anwendung mögliche Aktionen und Daten und natürlich deren IDs. Diese werden von der XML-Datei referenziert, z.B.

code:
<vgroup>
  <hgroup>
    <button action="back"/>
    <button action="forward"/>
    <button action="home"/>
  </hgroup>
  <text-pane content="main-document"/>
</vgroup>


Da jedes GUI-Element an irgendeine anwendungsspezifische Logik gekoppelt ist, entfällt die Notwendigkeit, GUI-Elemente an andere GUI-Element zu koppeln, komplett.

Alle GUI-Elemente, die an dasselbe logische Feature gebunden sind, sind implizit zusammengebunden. Und Regeln, die zwischen unterschiedlichen logischen Elementen bestehen, sind Teil der Anwendung, nicht des GUIs. So kann z.B. die Aktion "back" aus dem Beispiel dazu führen, dass der Status der Aktion "forward" zu <enabled> wechselt. Aber das tut er dann in jedem Fall, egal, wie das GUI aussieht, egal, ob die Aktion an einen Menüpunkt, einen Button oder ein Tastatur-Shortcut oder alles zusammen gebunden ist.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

23.07.2011, 06:01 Uhr

AGSzabo
Posts: 1663
Nutzer
@Holger:

> Die Wertebereiche sind ja gerade deshalb unterschiedlich, weil Du einem bestimmten Gadgettypen den willkürlich gewählten Bereich von 0-0xffff aufzwingst. Mir fällt absolut kein Praxisbeispiel ein, bei dem es sinnvoll wäre Objekte mit unterschiedlichen Wertebereichen zu koppeln.

Sicher? Ein Slider bzw Scroller mag ja schon vom Haus aus vielleicht eine andere Pixelgröße als die Listview selber haben. Da muß man sowieso was umrechnen? Aber wahrscheinlich hast du recht.

ps: ich habe jetzt sowohl das Notify als auch das Bind eingebaut. :) ...so wie es sich mir im moment erschließt. Sind blos noch wenig Events (= Methoden) definiert. Ein Notify könnte auch einen callback-hook aufrufen..., nur um das mal zu standardisieren anstelle von dem daß jedes widget die option eines hooks selber herstellen muss und um zu vermeiden dass ein widget bei werteänderungen mehrere funktionen aufrufen muss, also zB das Notify UND den hook. Der Hook im Notify würde einfach mitgehen bei dem einen Notify-Aufruf und parallel dazu können andere elemente direkt informiert werden.

--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 23.07.2011 um 06:10 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.07.2011, 11:21 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von AGSzabo:
edit: ah ja, das ist, damit elemente miteinander kommunizieren können, die verschiedene verhältnisse haben.

Warum sollten sie das tun wollen?
Ja, das ist wirklich keine gute Idee.

Zitat:
Mir fällt absolut kein Praxisbeispiel ein, bei dem es sinnvoll wäre Objekte mit unterschiedlichen Wertebereichen zu koppeln.
Mir auch nicht. Und denke dran, die häufigen Anwendungsfälle sollte einfach und elegant gehen. Wer was ganz spezielles braucht, dem darf man dann mehr-Arbeit zumuten. Z.b. über die App Logik kann man natürlich beliebige Gadgets mit beliebiger dahinterstehende Logik/Umrechnung verknüpfen.
Das "Binding" ist nur eine Art Shortcut, damit man nicht für jede Kleinigkeit die App bemühen muss.

Zitat:
@Der_Wanderer:

Mir ist ja schon bei Deinen Beispiel-XML aufgefallen, dass da nirgendwo schlüssig erkennbar ist, wie denn eigentlich die Anwendungslogik zum GUI kommt (oder umgekehrt). Da dachte ich noch, es läge an der Vereinfachung des Beispiels, aber jetzt bei der Binding Diskussion fällt es mir wieder auf.

Das ist ganz einfach, wie z.B. bei Android, was ich derzeit als eines der modernsten GUI Systeme halte. (ist auch das neueste, From-Scratch designte GUI Toolkit)

Zum einen bekommst du Events geschickt, die aber schon logisch verarbeitet sind. Um die terminologisch von Low-Level Events (wie Mausklick, Tastendruck etc.) zu trennen, nenne ich das "Nofify", nicht zu verwechseln mit dem Notify was AGSzabo meint. Er bezeichnet damit sowas wie Binding (wobei mir der Unterschied zwischen seinen Bindings und Notifies noch nicht klar ist).
Also eine Benachrichtigung der GUI an die App. Events im klassischen Sinne bekommt die App gar nicht, und soll sie auch nicht bekommen.

Definiert werden die im XML als String:

code:
<button onclick="ping!">


Die App wurde in dem Fall, wenn der Button erfolgreich gedrückt wird, das Notify "ping!" erhalten. In deinem Beispiel hast du es "action" genannt. Es gibt aber noch mehr Gelegenheiten, bei denen man sich ein Notify schicken kann. Z.B. wenn man auf den Button Down reagieren will:

code:
<button ontouch="ping!" onrelease="pong!">


Zum Anderen kann die App auf GUI Elemente über die ID zugreifen, wenn sie die GUI Elemente manipulieren will.

code:
<slider id="mySlider" min="0" max="100" value="5">


code:
int value = GetAttrByID("mySlider",ATTR_VALUE);
SetAttrByID("mySlider",ATTR_VALUE,value+1);
SetAttrByID("mySlider",ATTR_VISIBILITY,VISIBILITY_INVISIBLE);


Wobei die Engine natürlich mit Pointern arbeitet. Man kann also auch folgendes tun:
code:
Slider *myslider = GetObjectByID("mySlider");
int value = GetAttr(myslider,ATTR_VALUE);
SetAttr(myslider,ATTR_VALUE,value+1);
SetAttr(myslider,ATTR_VISIBILITY,VISIBILITY_INVISIBLE);


Die "ByID" Varianten sind sog. Convinient Stubbs und nicht Teil der Core-Funktionen des GUI Toolkits.

Zitat:
Wenn ich GUIs mittels XML erzeuge, dann definiert die Anwendung mögliche Aktionen und Daten und natürlich deren IDs. Diese werden von der XML-Datei referenziert, z.B.

code:
<vgroup>
  <hgroup>
    <button action="back"/>
    <button action="forward"/>
    <button action="home"/>
  </hgroup>
  <text-pane content="main-document"/>
</vgroup>


Richtig. Genau so ist es in NTUI.

Zitat:
Da jedes GUI-Element an irgendeine anwendungsspezifische Logik gekoppelt ist, entfällt die Notwendigkeit, GUI-Elemente an andere GUI-Element zu koppeln, komplett.
Jain. Man kann alles über die App Logik machen.
ABER: in vielen Fällen will man das nicht.
Z.b. ein ListView mit einem Scroller. Das ist eine klassiche Kombination. Da willst du dich als App Entwickler nicht wirklich drum kümmern.
Also legt der ListView gleich noch selbst einen Scroller als Kind mit an, und macht ein "Binding", dass die App Logik gar nicht mitbekommt.
Gleiches gilt für Arrows eines Scrollers, Multiline TextBox, TreeView, ScrollView, +/- Knöpfe eines Numerischen Buttens etc. etc.

Wie ich schon geschrieben habe, ist das Binding eher für solche "internen" Zwecke gedacht, aus einzelnen "Primitiven" ein komplexeres Widget aufzubauen, das ohne Zutun des App Programmierers funktioniert. Es gibt aber auch durchaus Situationen, wo der GUI XML Schreiber das gerne hätte, um sich das Leben einfacher zu machen. Z.b. wenn ich die Auswahl eines TabViews an einen Cycle Button knüpfen will, oder einen Scroller für einen View nicht direkt daneben, sondern woanders haben will. Oder den Text einer Option eines Cycles in einen StringGadget kopieren will etc.

Zitat:
Alle GUI-Elemente, die an dasselbe logische Feature gebunden sind, sind implizit zusammengebunden. Und Regeln, die zwischen unterschiedlichen logischen Elementen bestehen, sind Teil der Anwendung, nicht des GUIs.
Eben nur ein Jain von mir. So simple Verknüfpungen wie die Arrows mit dem Scroller willst du bereits im GUI Code abfrühstücken, ohne den App Programmierer damit zu belästigen.

Zitat:
So kann z.B. die Aktion "back" aus dem Beispiel dazu führen, dass der Status der Aktion "forward" zu <enabled> wechselt. Aber das tut er dann in jedem Fall, egal, wie das GUI aussieht, egal, ob die Aktion an einen Menüpunkt, einen Button oder ein Tastatur-Shortcut oder alles zusammen gebunden ist.
Richtig. Das schlägt sich im Konzept meiner "Notify"s wieder.
Z.b.
code:
<button onclick="back">
<menuitem onclick="back">
<key vanilla="b" onkeyup="back">
<arexx message="back" onreceive="back">

Die App Logik kennt nur das Notify "back", muss sich also nur EINMAL darum kümmern an EINER Stelle. => robusterer Code.

Die GUI alleine entscheidet nun, wer eigenlich so ein "back" verursachen darf, und man kann mit einem mal gleich buttons, menus, shortcuts und sogar arexx und sonstigen Kram damit erschlagen.

Oder man kann im Nachhinein sagen, ohne die Executable verändern zu müssen, man möchte die Aktion "back" eigentlich auch gerne im Menu oder auf einem Key haben, und kann das im XML tun. => weniger fehleranfällig.



--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de




[ Dieser Beitrag wurde von Der_Wanderer am 23.07.2011 um 11:38 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.07.2011, 11:26 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Zitat:
Sicher? Ein Slider bzw Scroller mag ja schon vom Haus aus vielleicht eine andere Pixelgröße als die Listview selber haben. Da muß man sowieso was umrechnen? Aber wahrscheinlich hast du recht.
Die Pixelgröße ist ja nur Darstellungsache, und völlig uninteressant für die logische Verwendung des Scrollers/Sliders. Wichtig ist der logische Wertebereich.
Z.b. in einem TextEditor, setze ich den Scroller auf

total = # der Zeilen des geladenen Texts
visible = # der Zeilen auf dem Bildschirm
top = oberste Zeile.

Wie gross der Scroller nun in Pixel dargestellt wird, ist mir als Verwender des Scrollers doch völlig wurscht. Damit will ich mich doch nicht beschäftigen.

Zitat:
ps: ich habe jetzt sowohl das Notify als auch das Bind eingebaut. :)
Was ist denn für dich der Unterschied?

Zitat:
...so wie es sich mir im moment erschließt. Sind blos noch wenig Events (= Methoden) definiert. Ein Notify könnte auch einen callback-
Events = Methoden?
Jetzt hast du mich vollkommen verwirrt.

Wir sollten erstmal die Begrifflichkeiten festlegen, mit wir uns gegenseitig verstehen können.


--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

23.07.2011, 11:43 Uhr

AGSzabo
Posts: 1663
Nutzer
@Der_Wanderer:
.i code:
; object interconnection for use with oxNotify() / oxNotifyAttr()
; ---------------------------------------------------------------
;
; the difference between OX_BIND and OX_NOTIFY is, that one object may
; have multiple notifys but only one binding and that oxNotifyAttr()
; yet only works with notifys.
;
; OX_BIND makes a chain, where every object in the chain will get the
; message sent with oxNotify(). you must make a ring with OX_BIND in
; order to get a message read by all objects in the chain regardless
; of where you start it.
;
; OX_NOTIFY makes multiple destinations, but the message or attr is not
; sent further.
;
; you can use both the OX_BIND and the OX_NOTIFY(s) on one object, but
; OX_BIND works only once.

	XITEM	OX_NOTIFY		; generate notify from one object to annother, tag_data should
					; point to a taglist as shown below

	XITEM	OX_BIND			; bind one object to annother and back, the OX_BIND tag must be
					; followed by a pointer to a pointer where the address of the
					; destination object is stored with OX_PUTPTR or OX_RELPTR.

OX_REL		EQU	$00000001	; odd pointers in tag_data are offsets to current userbase  that
					; is active at the moment of creation (odd bit masked out)

; attributes for OX_NOTIFY:

	ENUM	$1000

	EITEM	oxNA_Target		; pointer to a pointer to destination object

	EITEM	oxNA_MatchAttr		; attribute to catch
	EITEM	oxNA_NewAttr		; attribute to send in place of the catched one
					; if this is not given, match attr is sent as is

	EITEM	oxNA_Hook		; attach a callback-hook to a widget to receive
					; everything that is sent through Notify() / NotifyAttr()
					; hook gets: a0/a3 object, a1 message, a4 base, a6 oxbase
					; the message is allways a method. if it comes from
					; NotifyAttr(), the message is OXM_SET and (a1) is attr, value


Methoden und Messages:

aufruf oxDoMethod(methodID, message)


es wird einfach eine id mit einem pointer auf daten an den dispatcher einer oder mehrerer objekte eingegeben. im falle von einer intuition message (event) ist die methodenID "OXM_INTUI". Mehrere objekte heisst in meinem fall "Broadcast". Zb kommen intuimssages als broadcast. Das ist ein DoMethod auf alle kinder und kindeskinder ... eines objekts, oben angefangen. und wenn jeman die message konsumiert, kann je nach art des events schluss sein.

Das was du "event" nennst wäre bei mir eine methode, die auf alle objekte der notify liste ausgeführt wird, oder auf alle objekte der binding kette.

Wo liegt bei dir der unterschied zwischen methode und event?
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ - Antworten - Zitieren - Direktlink - ]

23.07.2011, 11:59 Uhr

AGSzabo
Posts: 1663
Nutzer
OX Objekt-Struktur
------------------
.i code:
STRUCTURE	oxObject,0
	STRUCT	oxO_node,MLN_SIZE
	STRUCT	oxO_list,MLH_SIZE
	APTR	oxO_parent
	APTR	oxO_binding
	STRUCT	oxO_notifys,MLH_SIZE
	APTR	oxO_class
	UBYTE	oxO_flags
	UBYTE	oxO_hotkey
	APTR	oxO_prev		; for connection when pressing tabulator to focus next or prev object
	APTR	oxO_next		; ..
	APTR	oxO_drawinfo
	APTR	oxO_userbase		; the create() function takes a parameter in a1 that is a pointer to
					; a custom space where f.e. the app has its globals and it is needed
					; to have a pointer to them in the hook functions of the objects ...
					; but the main purpose of this field is that XUI stores pointers here
					; via the OX_PUTPTR and OX_RELPTR tag-commands

	APTR	oxO_userdata		; custom pointer or value set to what ever by the app
	ULONG	oxO_id			; custom field intended for search

	UWORD	oxO_left
	UWORD	oxO_top
	UWORD	oxO_width
	UWORD	oxO_height

	LABEL	oxO_SIZEOF

	BITDEF	oxO,INITIALIZED,0
	BITDEF	oxO,VISIBLE,1
	BITDEF	oxO,GHOSTED,2		; clickable?
	BITDEF	oxO,SLEEPING,3		; get no intuimessages like in ghost mode but stay fully visible,
					; sleeping widgets are skipped in the tabulator chain
	BITDEF	oxO,ACTIVE,4
	BITDEF	oxO,REFRESH,5		; refresh this gadget in next refresh run ..all childs of this gadget
					; are also refreshed


Events / Methods
----------------
code:
ENUM	OX_METHODS

	EITEM	OXM_SET	; a1 oxm_set
	EITEM	OXM_GET	; a1 oxm_get

	EITEM	OXM_ADD	; a0 dest, a1 member		allow custom add-function for class
			;				example: window adds members to inner frame

	; ox objects are created and freed from central,
	; dispatchers do private work on them

	EITEM	OXM_SETDEF	; do this before tags are read to set default values

	EITEM	OXM_INIT
	EITEM	OXM_DEINIT
	EITEM	OXM_ACTIVATE
	EITEM	OXM_INACTIVE

	EITEM	OXM_INTUIMESSAGE

	EITEM	OXM_GETLAYOUT	; a1 oxLayoutInfo
	EITEM	OXM_SETLAYOUT	; ..  ..
	EITEM	OXM_setprop
	EITEM	OXM_DRAW	; draw (no sizes calculations)
	EITEM	OXM_DROPGFXBUFFERS
	EITEM	OXM_WINDOWOPEN
	EITEM	OXM_WINDOWCLOSING

   	EITEM	OXM_TABCHAIN	; link all interactive elements in a ring for
				; prev/next selection via tab
	EITEM	OXM_INVISIBLE
	EITEM	OXM_VISIBLE

	EITEM	OXM_APPWINMESSAGE
	EITEM	OXM_REFRESH

	EITEM	OXM_NEWPENS
	EITEM	OXM_INHERIT

	EITEM	OXM_ATTRSDONE	; this message (method) is sent after all
				; inital attribute tags have been set
				; this is usefull for example for creating co-objects,
				; like for example the grid, image and text in a button 

	EITEM	OXM_NEXT	; step to next/prev object in tabulator-chain
	EITEM	OXM_PREV	; this is required if a gadget hast multiple active areas,
				; like the multiple handles of a tabs gadget
	EITEM	OXM_ISCHILD

	EITEM	OXM_GETCLIP

	EITEM	OXM_HOTKEY	; if the class attribute oxCA_autohotkey is set to FALSE,
				; this method is sent to objects when their hoteky is pressed
				; (see class attributes)

--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 23.07.2011 um 12:01 Uhr geändert. ]

[ Dieser Beitrag wurde von AGSzabo am 23.07.2011 um 15:17 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.07.2011, 13:25 Uhr

Thore
Posts: 2266
Nutzer
> Wo liegt bei dir der unterschied zwischen methode und event?
Eine Methode ist eine Funktion die aufgerufen werden kann (oder wird). Ein Event ist ein Ereignis das eintreten kann (oder wird).

Ein Event wird z.B. ausgelöst, wenn ein Button gedrückt wird, oder ein Slider bewegt. Dieses Event kann dann Auslöser sein, eine verbundene (connected) Methode auszuführen.

Durch das connect wird dem Event (z.B. MousePressed) eine Methode zugewiesen (oder daß eine Variable gelesen oder geschrieben wird).

Das ist der Unterschied zwischen Event und Methode.

[ - Antworten - Zitieren - Direktlink - ]

23.07.2011, 15:11 Uhr

AGSzabo
Posts: 1663
Nutzer
> Dieses Event kann dann Auslöser sein, eine verbundene (connected) Methode auszuführen.

Dann kann man sagen dass in OX das window aus allen events generell diverse methoden macht. Und ein Button zB macht erst garkein event sondern sendet gleich eine methode los. Wann ist das ungünstig?
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 23.07.2011 um 15:12 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.07.2011, 21:18 Uhr

AGSzabo
Posts: 1663
Nutzer
Zitat:
Total, Visible und Top != Max, Min, Value.

Die Logik die dahintersteckt ist eine ganz andere.

Und um nochmal zur Frage zurückzukehren, woher das Bedürfnis die interne Repräsentation auf 0..0xFFFF zu normalisieren?


Ich hab jetzt geändert so dass der scroller direkt mit den pixelwerten der view arbeitet. Nachteil, wenn der slider mehr pixel hat als die view, dann hoppelt er.
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ - Antworten - Zitieren - Direktlink - ]

23.07.2011, 23:40 Uhr

Thore
Posts: 2266
Nutzer
> Und ein Button zB macht erst garkein event sondern sendet gleich eine methode los. Wann ist das ungünstig?

Z.B. Wenn dein Button keine Methode aufrufen soll, sondern du nur den Status (gedrückt, nicht gedrückt, Button-Text,...) wissen willst. Das lässt sich zwar auch mit einer Methode machen, aber eine "richtige" Eventsteuerung könnte hier von der Performance besser sein.
Wie machst Du das mit deinen Methoden? Werden die praktisch beim Drücken auf den Button ausgeführt? Was ist wenn diese Methode blockiert? Ist dann die GUI noch steuerbar?
Über einen Eventhandler könntest Du einen "Master" über die ausgelösten Events laufen lassen, der diese abfragt und entsprechend dem connect reagiert.
Ich kenn mich jetzt mit deinem Code nicht sonderlich gut aus, daher kann ich nicht sagen, ob es bei Dir eine Rolle spielt, die Methoden direkt zu verknüpfen.

[ - Antworten - Zitieren - Direktlink - ]

24.07.2011, 00:26 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Der_Wanderer:
Definiert werden die im XML als String:

code:
<button onclick="ping!">


Die App wurde in dem Fall, wenn der Button erfolgreich gedrückt wird, das Notify "ping!" erhalten. In deinem Beispiel hast du es "action" genannt.

Zwischen action und onclick besteht ein semantischer Unterschied. Gemeinsam ist, dass der Bezeichner "ping!" von der Anwendung definiert sein muss und der erzeugte Button diese Aktion auslöst.

Aber das Verhaltens eines Buttons wird vom System bestimmt. Ich will gar nicht, dass der Schreiber eines Skins die Möglichkeit bekommt, Buttons zu definieren, die sich völlig anders verhalten, auch wenn das auf anderen Systemen hipp ist.

Das Binden einer Aktion führt dazu, das ein Auslösen des Button, egal ob das ein Klick oder ein bestimmter Tastendruck ist, die Aktion auslöst.

Wenn also beispielsweise das System definiert, dass Buttons ausgelöst werden können, wenn er den Fokus hat und die Leertaste gedrückt wird, dann soll der GUI-Designer nicht bei jedem Button onClick="foo" onKeyPress="foo" schreiben müssen.

Außerdem liefert eine Aktion den Standardtext, den die Anwendung über dem systemspezifischen Locale-Mechanismus ermittelt als Beschriftung und, wie bereits gesagt, auch den logischen Zustand bezügliche der Frage, ob die Aktion überhaupt ausgelöst wird.

Bei einem Button mit einem Dutzend unterschiedlichen EventHandler weiß man nicht, wann der nun disabled sein soll und wann nicht. Und das den GUI-Designer innerhalb der XML-Datei schreiben zu lassen, halt ich für den falschen Weg.
Zitat:
Zum Anderen kann die App auf GUI Elemente über die ID zugreifen, wenn sie die GUI Elemente manipulieren will.
code:
<slider id="mySlider" min="0" max="100" value="5">


Was natürlich eine Vortäuschung falscher Zuständigkeit ist. Es sieht so aus, als ob die XML-Datei die ID definiert. Aber da die Anwendung nur auf IDs zugreifen kann, die sie kennt, definiert in Wahrheit die Anwendung die Liste gültiger IDs und durch das, was sie mit diesen Elementen machen will, auch ihre Bedeutung.

Dass der GUI-Designer auch noch bestimmt, welchen Range der Slider haben kann, setzt dem Ganzen die Krone auf.

Zitat:
Jain. Man kann alles über die App Logik machen.
ABER: in vielen Fällen will man das nicht.
Z.b. ein ListView mit einem Scroller. Das ist eine klassiche Kombination. Da willst du dich als App Entwickler nicht wirklich drum kümmern.
Also legt der ListView gleich noch selbst einen Scroller als Kind mit an, und macht ein "Binding", dass die App Logik gar nicht mitbekommt.

Yep.
Das tut der ListView und der ist Teil des Toolkits und somit der Anwendung, nicht der XML-Datei.

So etwas will man auch nicht jedes Mal kompliziert mit XML-Code beschreiben.

Zitat:
Es gibt aber auch durchaus Situationen, wo der GUI XML Schreiber das gerne hätte, um sich das Leben einfacher zu machen. Z.b. wenn ich die Auswahl eines TabViews an einen Cycle Button knüpfen will, oder einen Scroller für einen View nicht direkt daneben, sondern woanders haben will. Oder den Text einer Option eines Cycles in einen StringGadget kopieren will etc.
Das sind, mit Ausnahme des TabViews, alles Gegenbeispiele. Alle diese Beispiele funktionieren, wenn man, wie von mir beschrieben die GUI-Elemente an ein anwendungsspezifisches Model bindet, womit die Bindung der GUI-Elemente untereinander unnötig wird.

Nur im Falle der Tabs, von denen die Anwendung meistens in der Tat nichts wissen muss, würde man reine GUI-Elemente aneinander binden. Aber dieses Beispiel hinkt doch stark.
Zitat:
Eben nur ein Jain von mir. So simple Verknüfpungen wie die Arrows mit dem Scroller willst du bereits im GUI Code abfrühstücken, ohne den App Programmierer damit zu belästigen.
Iwo. So etwas will man im GUI-Code gar nicht machen. Allenfalls, in dem der Scroller ein Attribut arrows="true" bekommt.

Aber wenn man es manuell machen will, gut, dann bindet man die Arrows an exakt dasselbe Datenmodell wie den Scroller, der ja nicht zum Selbstzweck existiert, sondern an irgendein anwendungsspezifisches Feature gebunden ist.

Zitat:
Richtig. Das schlägt sich im Konzept meiner "Notify"s wieder.
Z.b.
code:
<button onclick="back">
<menuitem onclick="back">
<key vanilla="b" onkeyup="back">
<arexx message="back" onreceive="back">

Die App Logik kennt nur das Notify "back", muss sich also nur EINMAL darum kümmern an EINER Stelle. => robusterer Code.
Mal abgesehen von Arexx, von dem ich nun wirklich nicht glaube, dass das in die Hände eines GUI-Designers gehört, sieht das ja alles fast so aus, wie ich es meine. Nur, dass diese Buttons und Menüpunkte keine Beschriftung haben, keinen Hilfetext und ihr korrektes Disablen bei nicht-Verfügbarkeit durch obigen XML-Code nicht gegeben ist. Es sei denn, es würde auch die etwas "magische" Definition existieren, dass der onClick-Handler auch den Zustand des Buttons bestimmt.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.07.2011, 00:30 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
Ich hab jetzt geändert so dass der scroller direkt mit den pixelwerten der view arbeitet. Nachteil, wenn der slider mehr pixel hat als die view, dann hoppelt er.

Ich hoffe, er hoppelt nicht, wenn er mit der Maus gezogen wird, denn dann machst Du etwas grundsätzlich falsch.

Wenn dagegen ein Slider von einer anderen Quelle aus gesetzt wird und größer als sein Wertebereich ist, ist das vollkommen normal, dass er nicht jede Pixelposition annehmen kann. Das wäre selbst dann so, wenn er intern alles auf 0-0xffff Bereich umrechnen würde.

ListViews, deren Scroller gleich hoch sind, die aber nur zeilenweise scrollen, wären ein typisches Beispiel.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.07.2011, 09:48 Uhr

AGSzabo
Posts: 1663
Nutzer
@Holger:

> Ich hoffe, er hoppelt nicht, wenn er mit der Maus gezogen wird ...

Ich mache tatsächlich etwas grundsätzlich falsch. Meine Vorgehensweise ist, bei bewegungen mit der maus direkt die gespeicherten pixelwerte der liste zu verändern (und zu senden) und daraus auch beim refresh wieder die pixelposition des scrollers zu berechnen. ich verstehe dass das falsch ist aber weis keine lösung.
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ - Antworten - Zitieren - Direktlink - ]

24.07.2011, 09:56 Uhr

AGSzabo
Posts: 1663
Nutzer
@Thore:

> Wie machst Du das mit deinen Methoden? Werden die praktisch beim Drücken auf den Button ausgeführt? Was ist wenn diese Methode blockiert? Ist dann die GUI noch steuerbar?

Wenn der Hook zu lange braucht, dann steht das GUI. Meinst du das? Für längere Aufgaben muß die App einen neuen Task starten.

> Über einen Eventhandler könntest Du einen "Master" über die ausgelösten Events laufen lassen, der diese abfragt und entsprechend dem connect reagiert.

Versteh ich nicht.
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ - Antworten - Zitieren - Direktlink - ]

24.07.2011, 11:19 Uhr

Thore
Posts: 2266
Nutzer
> Wenn der Hook zu lange braucht, dann steht das GUI. Meinst du das? Für längere Aufgaben muß die App einen neuen Task starten.

Genau das.

> Versteh ich nicht.

Wird ein Event ausgelöst, wird dieses gepuffert und der Master wandert alle gepufferten Events ab. Das sind im Grunde nur Flags (Verkettete Liste) und an jedem dieser hängt das connect (eine Methode oder sonstwas das ausgelöst wird). Der Master führt dann die Methode aus und crawlt weiter. Das Hauptprogramm selbst setzt nur die Events in die Liste wenn sie eintreffen und somit ist die GUI auch bei großen Methoden gut bedienbar. Der Master läuft in einem anderen Thread oder Task.

Ob das für Dich relevant ist, weiß ich nicht. Wenn deine Methoden sowieso in eigenen Threads oder Tasks ablaufen, kann das performancetechnisch den gleichen Vorteil bieten. Die Technik dahinter ist dann nur eben anders.

[ - Antworten - Zitieren - Direktlink - ]


-1- 2 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Jetzt nochmal das Notify [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.