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

amiga-news.de Forum > Suche [ - Suche - Neue Beiträge - Registrieren - Login - ]

Erste 1 2 3 4 5 -6- 7 8 9 10 11 >> Letzte Ergebnisse der Suche: 1229 Treffer (30 pro Seite)
Der_Wanderer   Nutzer

24.07.2011, 21:00 Uhr

[ - Direktlink - ]
Thema: Jetzt nochmal das Notify
Brett: Programmierung

@Thread
Also ich denke, bevor wir weiterdiskutieren müssen wir die Begrifflichkeiten erstmal klären, denn wir reden in vielen Punkten gründlich aneinander vorbei. Ich denke jeder hat gute Gründe für seine Ideen/Argumente, aber es wird jeweils vom anderen nicht ganz verstanden.

Ich versuche das mal, bitte korrigiert mich wenn ihr anderer Meinung seid. Und in weiteren Posts dann bitte darauf achten, diese Begriffe konsistent zu verwenden.

OOP
Object orientiertes Programmieren. Es ist ein Programmier Paradigma und nicht an eine bestimmte Sprache geknüpft. Man kann OOP auch in 68K Assembler programmieren, in Amiblitz, C oder C++ und Java.
Wenn die Sprache das unterstützt hat man allerdings eine "Fahrbahnmarkierung" und ist besser geschützt gegen "Querfeldeinfahren"

Funktion
Das ist eine Subroutine, die ihre lokalen Variablen auf dem Stack anlegt und daher prinzipiell Multithreading fähig ist, was eine "normale" Subroutine nicht automatisch ist. Besonders in Assembler ist das etwas schwer, weil man geneigt ist Variablen global anzulegen mit "DC.l ...", was bei OOP, wo man oft Rekursion benutzt, schrecklich schief geht. (oder bei einer Callback Hook)

Methode
OOP Jargon für eine Funktion, die direkt an ein Objekt oder Klasse geknüpft ist. D.h. bei OOP Sprachen wird sie über ein Object (Objektmethode) oder Klasse (Klassenmethode) referenziert, bei nicht-OOP Sprache wäre das eine Funktion, die als ersten Parameter das Objekt hat, "auf" dem es arbeitet (Objektmethoden). Bei nicht OOP Sprachen sollte man den Funktionen den Klassennamen als Prefix geben, damit es keine Konflikte bei gleichnamigen Methoden verschiedener Klassen gibt.

Event
Jetzt wird's schwamming.
Ich würde ein Event als eine kurze "Message" bezeichnen, die von A nach B geschickt wird. In der Regel von A=Betriebssystem und B=unser GUI Toolkit Dispatcher. Darunter fallen die IDCMP Events auf dem Amiga.

Message
Überbegriff wenn man Daten von A nach B schickt. In der Regel durch Übergabe eines Pointers. Bei ganz kurzen Messages wird manchmal auch kopiert.

Binding
Zwei oder mehr Objekte werden miteinander "verbunden", kennen sich also und tauschen selbständig Informationen aus, ohne dass der App Programmierer eingreifen muss.

GUI Toolkit
Das ist im o.B.d.A eine Funkitonsbibliothek, mit deren Hilfe ein App Programmierer eine GUI realisieren kann. Wir sind und denke ich alle einige, dass ein OOP Ansatz am vielversprechendsten ist, da ein GUI Toolkit eigentlich ein Paradebeispiel für OOP ist.

App/Applikation
Das ist die eigentlich Anwendung, die der USer/App Programmierer erstellen will. Das GUI Toolkit dient dazu, der Anwendung ein Graphisches Unter Interface zu verpassen, und das möglicht einfach, mächtig und ohne Einschränkungen.

GUI Toolkit Programmierer
Z.B. ASGzabo und der Wanderer ;-)

GUI Programmierer/Designer
Derjenige, der für eine App die GUI bastelt, sei es programmatisch, per XML oder mit einem GUI Builder.

App Programmierer
Derjendige, der die eigentlich App Logik schreibt, und die GUI anspricht. Bei kleineren Projekten meistens der gleiche wie der GUI Programmierer.

Skin Designer
Ein Grafikkünstler, der schöne Bildchen erstellt, die als Elemente in einem GUI Toolkit funktionieren, ohne eine spezielle App im Hinterkopf zu haben. Das ist NICHT der GUI Programmierer/Designer, der die GUI und evtl. weitere Bildchen für eine konkrete App macht.

Attribut
Eine Eigenschaft eines Objekts, dass man lesen und/oder schreiben kann, meistens mittels sog. Getters und Setters, also GetAttr() und SetAttr(). Durch Getters und Setters vermeidet man eine Inflation von Funktionen, und kann die API einfach erweitern.
Typsiches Attribut wäre der aktuelle Integer/String Wert eines Widgets, aber auch Pixelkoordination, Enabled/Disabled Zustand etc.

Object
Im Prinzip eine Datenstruktur, mit einer Anhäufung von dazugehörigen Funktionen. Bei uns meinen wir damit meistens ein Widgets (fast gleichbedeutend mit Gadget, aber etwas allgemeiner, z.B. gehören auch Gruppen oder ein Space dazu), evtl. auch einfach GUI Element.

Notify
Dafür gibts keine wirkliche Standard Interpetation. Das heist eigentlich nur, dass ein Objekt beim Eintreten eines bestimmten Zustandes ein anderes Objekt benachrichtigt.
AGSzabo (und MUI glaube ich) nennt bei sich die Message bei einem Binding so (?), der Wanderer nennt die Messages vom Toolkit an die Applikation so.

CallBack Hook/Function
Das ist ein Codefragment, was vom App Programmierer kommt und im GUI Toolkit Kontext an bestimmten Stellen ausgeführt wird, z.b. beim drücken eines Buttons.

Aktion
Wenn die Applikation etwas bestimmtes tun soll. Das wäre ein mögliches Ergebnis des Dispatchers, der die Events verarbeitet. Also nicht mehr Maus wird an Koordiate 134/23 gedrückt (=Event), sondern, nachdem wir wissen dass es der Button "Foo" ist und er aktiv ist etc., umgewandelt in die Aktion "Save As..." o.Ä.
Dabei können mehrere Objekte gleiche Aktionen auslösen, z.B. Button, Hotkey und Menu.

Dispatcher
Das ist eine Funktion, die Betriebssystem Events bekommt und dann damit was tut (oder auch nicht). Meistens hat jedes Objekt einen eigenen Dispatcher.
Der "Master" Dispatcher der GUI Engine schaut sich normalerweise zuerst ein Event an, indem er nach einer bestimmten Strategie die einzelnen Dispatcher Funktionen ausgewählter Unterobjekte mit diesem Event aufruft. Diese können wiederum weiter-delegieren.
Wenn der Dispatcher eines Objektes mit einem Event was anfangen kann, dann konsumiert er in der Regel das Event und es ist weg, andere Objekte sollten dann nicht mehr drauf reagieren. Oft wird das mit dem Rückgabeparameter der Dispatcher Funktion geregelt, wobei "True = konsumiert", "False = nicht interessant für mich" bedeutet.

Z.b. sollte eine TextBox, die ein "a" annimmt, das Event konsumieren damit es nicht weiter an einen möglichen Hotkey geht, der auf "a" hört.

Fokus
Die meisten GUI Toolkits haben das Konzept eines Fokus, das heißt ein Objekt ist "activ", meistens das zuletzt betätigte. Eingaben, die nicht eindeutig auf ein bestimmtes Objekt abzielen, gehen normalerweise erstmal an das Object das den Fokus hat, z.B. ein Tastendruck oder ein Mouse-Wheel Event. Der Fokus wird in der Regel durch "TAB" weitergegeben, damit man eine GUI auch per Tastatur steuern kann. Return ersetzt dann in der Regel den Mausklick auf das Fokus Objekt.


--
--
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 24.07.2011 um 21:18 Uhr geändert. ]
 
Der_Wanderer   Nutzer

23.07.2011, 11:26 Uhr

[ - Direktlink - ]
Thema: Jetzt nochmal das Notify
Brett: Programmierung

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

 
Der_Wanderer   Nutzer

23.07.2011, 11:21 Uhr

[ - Direktlink - ]
Thema: Jetzt nochmal das Notify
Brett: Programmierung

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. ]
 
Der_Wanderer   Nutzer

22.07.2011, 17:15 Uhr

[ - Direktlink - ]
Thema: Jetzt nochmal das Notify
Brett: Programmierung

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

 
Der_Wanderer   Nutzer

22.07.2011, 16:59 Uhr

[ - Direktlink - ]
Thema: Jetzt nochmal das Notify
Brett: Programmierung

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

 
Der_Wanderer   Nutzer

22.07.2011, 16:54 Uhr

[ - Direktlink - ]
Thema: Jetzt nochmal das Notify
Brett: Programmierung

@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

 
Der_Wanderer   Nutzer

22.07.2011, 16:50 Uhr

[ - Direktlink - ]
Thema: Jetzt nochmal das Notify
Brett: Programmierung

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

 
Der_Wanderer   Nutzer

22.07.2011, 16:35 Uhr

[ - Direktlink - ]
Thema: Jetzt nochmal das Notify
Brett: Programmierung

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

 
Der_Wanderer   Nutzer

22.07.2011, 16:32 Uhr

[ - Direktlink - ]
Thema: Jetzt nochmal das Notify
Brett: Programmierung

"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

 
Der_Wanderer   Nutzer

22.07.2011, 16:28 Uhr

[ - Direktlink - ]
Thema: Jetzt nochmal das Notify
Brett: Programmierung

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

 
Der_Wanderer   Nutzer

22.07.2011, 16:24 Uhr

[ - Direktlink - ]
Thema: Jetzt nochmal das Notify
Brett: Programmierung

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. ]
 
Der_Wanderer   Nutzer

22.07.2011, 15:49 Uhr

[ - Direktlink - ]
Thema: Jetzt nochmal das Notify
Brett: Programmierung

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

 
Der_Wanderer   Nutzer

20.07.2011, 14:11 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

@Holger

Also wenn das hier korrekt geparsed wird, wäre das ok?

code:
<window id="xuiwin" title="NTUI Lib Info & Config PREVIEW" bgpen="halfshadow">
  <vgroup>
    <tabview activetab="1" bgpen="background">
      <vgroup title="Information" image="TBImages:help"/>
      <vgroup title="Configuration" image="TBImages:prefs">
        <hgroup>
          <vgroup title="NTUI Env Variables" bordertype="title">
            <listview title="\pTBImages:question\~|\lVariables|\lValue" id="xuilist"/>
          </vgroup>
          <vgroup title="Item Options" bordertype="title" fixwidth="true">
            <hgroup><checkbox/><label text="active (use pen if not)" align="left" fixwidth="false"/></hgroup>
            <hgroup wrap="2">
              <label text="Web/Hex" align="right"/><string text="AEBF34"/>
              <label text="Red" align="right"/><string text="231"/>
              <label text="Green" align="right"/><string text="81"/>
              <label text="Blue" align="right"/><string text="132"/>
            </hgroup>
            <hgroup bordertype="recessed"><label text="Preview" bgpen="marker"/></hgroup>
            <image src="Desktop:/Pictures/ColorWheel2.png"/>
          </vgroup>
        </hgroup>
        <hgroup bordertype="recessed" samewidth="true">
          <button text="Cancel"/>
          <button text="Revert"/>
          <button text="Default"/>
          <button text="Test"/>
          <button text="Save"/>
          <button text="Use"/>
        </hgroup>
      </vgroup>
    </tabview>
  </vgroup>
</window>


Noch eine Frage:

Bei Tags, die eigentlich nichts umklammern können, z.b. eine CheckBox, benötigt man das /> als Ende?
Das finde ich ziemlich lästig, da ich HTML gewöhnt bin.

Ich habe auch später nicht wirklich vor, komplexere GUIs per Hand zu schreiben, dafür würde ich eine GUI Builder machen, wo man zwischen Tree Ansicht und XML Code hin und her schalten kann. (und natürlich die GUI noch als Preview sofort sehen kann.


--
--
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

 
Der_Wanderer   Nutzer

20.07.2011, 11:29 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von Holger:
Zitat:
Original von Der_Wanderer:
Stimmt. Das liegt daran, dass
<vgroup ...> das gleiche ist wie <group orientation=vertical ...> und
<hgroup ...> das gleiche ist wie <group orientation=horizontal ...>.
Sind also einfach nur Abkürzungen, weil man das oft braucht.

Makro-XML? Das ist schon echt hart.
Es sind ja keine Makros. Eine V und H Group unterscheidet sich aber nur durch den Orientation Parameter, es ist die gleiche Klasse.
Und da man Gruppen sehr häufig braucht, kann man das direkt erzeugen ohne explizite Angabe des Parameters. Die Gruppen zu schliessen ist aber das gleiche, weil es ja die gleiche Klasse ist. Der Parser kennt aber auch </hgroup> und </vgroup>, wenn man es so will.

Zitat:
Zitat:
Zitat:
> <vgroup title='Item Options' bordertype=7/>

sollte nicht mit /> beendet werden.

Stimmt. Mein Parser ist da etwas großzügig.
In dem er offensichtlich falsches erlaubt? Mir scheint, Du hast einen der wesentlichen Vorteile von XML nicht verstanden.
Stimmt, in dem Fall oben ist das tatsächlich falsch. Man könnte ja auch eine leere Gruppe erstellen wollen. Das sollte ich berücksichtigen.

Zitat:
Zitat:
Wenn kein Space enthalten ist, können die ".." wegfallen. Und man darf auch '..' verwenden. Das habe ich von HTML übernommen. Ich mache das, weil ich im Sourcecode das als String definiere und nicht immer die " escapen möchte.
Die Begründung überzeugt mich nicht. Du kannst ja einfache Anführungszeichen verwenden, das ist in XML erlaubt und die müssen normalerweise nicht escaped werden. Warum Du sie jetzt auch noch unbedingt weglassen musst, um zwei Zeichen einzusparen, erschließt sich mir nicht. Das hat ja mit escapen nichts zu tun.

align=right

tippt sich einfach schneller als

align='right'

Und wenn kein Leerzeichen vorkommt, ist das Ende des Strings ja definiert. So wie bei CLI Parametern, oder HTML.
Das führt ja nicht zu Problemen wenn man es korrekt macht, vermeidet aber tonnenweise Fehlermeldungen bei faulen Programmierern.

Zitat:
Was mich aber noch mehr interessiert, was macht eigentlich </group fixwidth>? Attribute innerhalb eines schließenden Tags? Dein Parser ist wirklich verdammt tolerant, um nicht zu sagen, was auch immer er parst, es ist kein XML.
Ja, er ist verdammt tolerant ;-)
Das hat eine einfache Bewandtnis:
Ob eine Gruppe fix oder sizable ist, hängt davon ab ob seine Kinder sizable oder fix sind. Das wird rekursiv hoch-propagiert bis zum Fenster. So hat z.b. ein Fenster, das nur fixe Elemente enthält, per default kein Size Gadget. Sobald eines der Kinder sizable ist, bekommt es ein Size Gadget.
Manchmal will man das verhalten aber überschreiben, weil man eine Gruppe explizit fix machen will.
Mache ich das beim Erstellen der Gruppe, existieren noch keine Kinder.
Das Default verhalten wird erst nach schließen der Gruppe bestimmt.
Da der Parser momentan noch nicht vorausschaut, muss ich also das fix beim Schließen der Gruppe erzwingen.



Zitat:
Zitat:
Wirklich? Gibts keine "Switches" die durch ihre blosse Anwesenheit etwas anschalten?
Es gibt in XML keine Attribute ohne Wertzuweisung, d.h. es müsste mindestens foo="" da stehen. Wobei die meisten Funktionen des DOM-API oder XPath, etc. bei einer Abfrage eines Attributwertes nicht zwischen einem nicht vorhandenem Attribut und einem Leerstring unterscheiden.
"Meinem" Parser ist es egal, ob foo oder foo=x oder foo="true" da seht. Er parst den Parameter Namen und Wert. Wenn kein "=" da ist, dann ist der Wert der Leere String.

Zitat:
Man kann zwischen ihnen unterscheiden, entfernt sich aber von dem, was Standardwerkzeuge als typisch (und damit leicht zu benutzen) erachten.

Bedenke bitte, XML wurde dazu design't, maschinenlesbar zu sein, nicht zwangsläufig komfortabel für den Menschen.

XML wurde eigentlich desgined, um die Krätsche zwischen Human and Maschin Readable hinzubekommen.

Zitat:
Deine Optimierungen sind alle eher marginal, es stört kaum, wenn man immer formal korrekt <hgroup></hgroup> <vgroup></vgroup> und Anführungszeichen schreiben würde, aber wenn irgendwann mal jemand neue Features (wie wäre es mit einem GUI-Editor?) entwickelt, schaust Du blöd aus der Wäsche, wenn der scheinbar korrekte Code plötzlich nicht eingelesen werden kann, weil diese neue Software mit Deiner Interpretation von XML nicht klarkommt.
Das war nur mein XML Text. Der Parser kann natürlich auch korrektes XML parsen, nur ich kanns nicht schreiben, deshalb verzeiht der Parser mir den ein oder anderen Ausrutscher ;-)


--
--
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

 
Der_Wanderer   Nutzer

20.07.2011, 10:50 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von AGSzabo:
@Der_Wanderer:

Dann gehst du doch über IDs beim binden. Angenommen, du möchtest eine Klasse aus zwei anderen Klassen bauen, deren objekte dann miteinander gebunden werden sollen. Das geht vermutlich garnicht über XML oder? Ich vermute, für diesen Fall hast du eine Funktion Bind(a,b)?
--
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


Nein, über XML kann man keine neuen Widget Klassen bauen. Das sind Amiga Shared Libraries von 3rd Party Entwicklern, so wie bei MUI, oder direkt im NTUI Sourcecode.
Über XML kann man nur Widgets binden, z.B. einen Scroller mit Arrows etc.
Wobei man das eigentlich relativ selten braucht, da die meisten Widgets schon sinnvolle Subwidgets erstellen können.
Z.b. braucht ein ListView keinen extra Scroller, da es bereits einen eigenen anlegt und sich damit bindet, ohne dass man was auf XML ebene dazu tun muss.
Auch bei Arrows von Scrollern. Da sagt man einfach:

<scroller orientation=vertical arrows=true/>

Der Scroller legt dann beim Inisitlaisieren selbständig schon Arrow Buttons an und bindet sich damit. Aber nehmen wir mal an, ich will einen Arrow ganz wo anders haben (wo anders im Fenster oder sogar in einem anderen Fenster), dann kann ich:

<scroller id=xxx orientation=vertical/>
<arrowup bind=xxx>
<arrowdown bind=xxx>

Ja, arrowup/down sind Widget Klassen, ein Subclass von Button.


--
--
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

 
Der_Wanderer   Nutzer

19.07.2011, 22:42 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von AGSzabo:
@Der_Wanderer:

Dann kann man aber nur binden, was schon erzeugt wurde, es ist nicht möglich ein objekt zur bindung mit einem anderen schon zur erzeugungszeit vorzubestimmen. In Beispiel, du kannst dem scroller nicht sagen, hänge dich an diese view wenn sie fertig ist, sondern erst wenn die view fertig ist, geht das. man kann ja nicht wissen in welcher reihenfolge die gui elemente erzeugt 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 19.07.2011 um 22:34 Uhr geändert. ]


Es reicht ja den Bind einmal anzugeben:

code:
<view id=myView>
<hscroller bind=myView>
<vscroller bind=myView>


Wo ist da das Problem?
Zugegeben, es ist ein wenig unschön, und deshalb sollte sich der Parser die Bindings merken und am Ende ausführen, damit auch das geht:


code:
<hscroller bind=myView>
<vscroller bind=myView>
<view id=myView>


Momentan geht das noch nicht, weil ich es nicht implementiert habe, stellt aber ja kein prinzipielles Problem dar.

--
--
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

 
Der_Wanderer   Nutzer

19.07.2011, 22:25 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Die Binding Events sind definiert, genauso wie alle anderen Events.
Möchte man "selbsterfundene" Messages schicken, gibt es einen User Wertebereich oder kann per XML Attribut kommunizieren.
Das wäre aber nur dann interessant, wenn man zwei eigene, externe Widgets implementiert hat und die so miteinander kommunizieren müssen, dass es mit den "Bordmitteln" nicht geht, wo ich mir aber kein Fallbeispiel konstruieren kann.

Im aller aller schlimmsten Fall ist NTUI ja OpenSource ;-)

Zu den IDs:
IDs werden nur vom User vergeben und haben keinerlei Bedeutung, ausser dass sie als String im Object Struct ihr Dasein fristen und man sie abfragen kann.

Wie ich schon oben sagte, arbeiten alle "echten" Funktionen grundsätzlich mit Pointern, und die sind hoffentlich eindeutig ;-)

Man kann aber IDs in die dazugehörigen Pointer verwandeln,

mit

object* myobj = GetObjectByID("blabla");

Kann natürlich auch fehlschlagen, wenn es die ID nicht gibt.

Um häufig wiederkehrende GetObjectByID Orgien zu vermeiden, gibt es sog. Convinient Stubbs, also Funktionen, die nicht wirklich nötig wären aber einem das Leben leichter machen.

So gibt es zu häufig benutzten Funktionen auch ID Varianten, z.B.
code:
BindByID()
SetAttrByID()
ShowWindowByID()
CloseWindowByID()
FreeByID()
...


Die sind aber alle in einer seperaten Datei definiert und müssten streng genommen auch gar nicht in die ntui.library hinein, um Bloat zu vermeiden. Alls diese Funktionen kann man ja auch selbst definieren, z.b.
code:
void ShowWindowByID(String winId) {
  window *win = (window*)GetObjectByID(winId);
  SetAttr(win,TUIA_VISIBILITY,True);
}




--
--
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 19.07.2011 um 22:29 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 19.07.2011 um 22:36 Uhr geändert. ]
 
Der_Wanderer   Nutzer

19.07.2011, 22:11 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von AGSzabo:
Binding
-------

Kann bei dir ein objekt mit mehr als zwei anderen (next/prev) gebunden sein?

Ich hatte doch erwähnt, dass es sich um einen gerichteten Ring handelt. Ich brauche also nicht next/prev, sonder nur next. Somit kann ich beliebig viele Widgets miteinander Binden.
Ein Widget kann aber nur einem Ring angehören. Alles andere wäre auch nicht definierbar. Stell dir vor, ein Widget würde zwei Ringen angehören. Jetzt ändert sich in einem Ring was, und das Widget zieht mit. Was passiert dann mit dem anderen Ring? Passiert nichts, habe ich einen illegalen Zustand, da die Widgets nicht synchron gehalten wurden.
Schicke ich den Wert auch in den zweiten Ring, dann verhält sich das ganze wie ein einziger Ring.

Ring:

A->B->C->...->Z->A

Ändert sich z.B. C, dann schickt er an alle Nachfolger ein Event, bis er wieder bei sich selbst angekommen ist.

Zitat:
Eine view müsste ja einmel ne verbindung zu einem h-slider und einen zweiten ring mit einem vslider haben. oder habe ich was übersehen?
Der hSlider mit seinen Arrows, der vSlider mit seinen Arrows und der View sind alle im gleichen Ring.
Der hSlider sendet HVALUE Events, der andere VVALUE, die Arrows schicken HDELTA und VDELTA, der View schickt und empfängt alles.

Es gibt auch HMAX und HMIN Events, wenn z.b. der View seine Inhaltsgröße ändert, müssen die Slider das ja mitbekommen und sich auch anpassen.



--
--
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

 
Der_Wanderer   Nutzer

19.07.2011, 22:02 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von AGSzabo:
@Der_Wanderer:

Das sowohl hgroup als auch vgroup mit /group beendet werden, finde ich etwas ungünstig.

Stimmt. Das liegt daran, dass
<vgroup ...> das gleiche ist wie <group orientation=vertical ...> und
<hgroup ...> das gleiche ist wie <group orientation=horizontal ...>.
Sind also einfach nur Abkürzungen, weil man das oft braucht.
Beenden kann man alle gruppen mit </group> weil es völlig egal ist.
Aber man kann auch </vgroup> schreiben, sieht zugegebenermassen schöner aus.

Zitat:
> <vgroup title='Item Options' bordertype=7/>

sollte nicht mit /> beendet werden.

Stimmt. Mein Parser ist da etwas großzügig.

Zitat:
XML-konform müssten alle parameter in ".." stehen, aber das weist du sicherlich.
Stimmt. Mein Parser ist da etwas großzügig.

Wenn kein Space enthalten ist, können die ".." wegfallen. Und man darf auch '..' verwenden. Das habe ich von HTML übernommen. Ich mache das, weil ich im Sourcecode das als String definiere und nicht immer die " escapen möchte.

Zitat:
(und samewidth müsste samewidth="true" sein oder änliches)
Wirklich? Gibts keine "Switches" die durch ihre blosse Anwesenheit etwas anschalten?

--
--
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 19.07.2011 um 22:03 Uhr geändert. ]
 
Der_Wanderer   Nutzer

19.07.2011, 17:04 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Ich habe noch kein Skin, was alle Widgets "skinned", deshalb würde das seltsam aussehen und ich lasse es erstmal, davon Screenshots zu posten.
Der Default Look, vor allem der dünne, werden aber super schnell gezeichnet und sollte auch gut auf schwachen Maschinen laufen. Es ist dem Amiga-Look nachempfunden, zumindest was ich mir so vorstelle. Es kommt ganz ohne Gradienten aus und sieht trotzdem nicht altbacken aus. Das kommt vor allem wegen den weichen Kontrasten.

Das ist übrigends der Source für die GUI. Den kann man sich nun im Sourcecode als Konstante definieren oder von einer Datei laden, schmeißt ihn in die ntui_CreateFromXML() Funktion und das wars.

code:
<window id='xuiwin' title='NTUI Libs & Info' bgpen=6>
  <group>
    <tabview activetab=1 bgpen=0>
      <vgroup title='Information' image=TBImages:help>
        <label string='Just a button:'/>
      </group>
      <vgroup title='Configuration' image=TBImages:prefs>
        <hgroup>
          <vgroup title='NTUI Env Variables' bordertype=7>
            <ListView title='\pTBImages:question\~|\lVariables|\lValue' id=xuilist>
          </group>
          <vgroup title='Item Options' bordertype=7/>
            <hgroup><Checkbox/><label text=active align=left freewidth/></group>
            <hgroup wrap=2>
              <label text='Web/Hex' align=right><string text=#AEBF34/>
              <label text=Red align=right><string text=231/>
              <label text=Green align=right><string text=81/>
              <label text=Blue align=right><string text=132/>
            </group>
            <hgroup bordertype=7><label text=Preview bgpen=8/></group>
            <image src='Desktop:/Pictures/ColorWheel2.png'/>
          </group fixwidth>
        </group>
        <hgroup bordertype=2 samewidth>
          <button text=Cancel>
          <button text=Revert>
          <button text=Default>
          <button text=Test>
          <button text=Save>
          <button text=Use>
        </group>
      </group>
    </tabview>
  </group>
</window>

--
--
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 19.07.2011 um 17:06 Uhr geändert. ]
 
Der_Wanderer   Nutzer

19.07.2011, 16:35 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Hier mal ein Vergleich, wie die GUI auf die Schnelle im default Look (also ohne Gradienten oder Schnickschnack, einmal dick und dünn) von NTUI ausehen würde.
Hoffentlich merkst du dabei, wie "kratzbürstig" und 90er dein Skin rüberkommt, obwohl der Aufbau (über den man sich natürlich auch streiten kann, aber das ist App Programmierer Sache) fast gleich ist.

Bild: http://www.hd-rec.de/pics/xuiex1.png Bild: http://www.hd-rec.de/pics/xuiex4.png
Bild: http://www.hd-rec.de/pics/xuiex3.png
--
--
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

 
Der_Wanderer   Nutzer

19.07.2011, 13:31 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

@AGSzabo:

Das ist so was mir auf den ersten Blick ins Auge gestochen ist:
Zumal man heute eigentlich eher wenig Kontrast gibt, und nur die Schrift hart macht. Das erlaubt heute die gute Qualität der Monitore, und erhöht den Blick aufs Wesentliche bei gleichzeitiger Reduktion von Eye-Strain.

Bild: http://www.hd-rec.de/pics/xuibig2.jpg


--
--
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

 
Der_Wanderer   Nutzer

19.07.2011, 11:28 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

> ich bin von meinem skin sehr angetan, falls du noch nicht gesehen hast > (?), hier ein altes beispiel: http://otaku.onlinehome.de/xuibig.jpg
Sorry, aber das finde ich gräßlich und verletzt so ziemlich alle Regeln der GUI Kunst...

> wie könnte ich dich unterstützen? nur mal so rein ohne versprechen gefragt...
Dich in den Code einlesen und programmieren, Bugs jagen, Verbesserungen und Ideen einbringen etc.
Alleine der Austausch mit anderen Entwicklern bringt ja schon viel, wie du vielleicht selbst hier gemerkt hast.


--
--
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

 
Der_Wanderer   Nutzer

19.07.2011, 10:11 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

> ich denke state of art guis gibt es schon zu genüge
Welches denn (auf dem Amiga)?

- MUI3.8 (ist mittlerweile 20 Jahre alt, hat einige Design Flaws und unterstüzt keine 32Bit Grafiken, und ist tot)

- MUI4.0 (basiert auf MUI3 mit den gleichen Design Flaws, gibts nur für MOS, kein OS3, OS4 oder AROS)

- Reaction (darüber weis ich nicht viel, aber gibts nicht(?) für AROS/MOS und ist auf OS3 tot)

- Gadtools (ist von State-of-the-Art so weit entfernt, dass ich es nichtmal GUI Toolkit nennen würde)

- Feeling (guter Ansatz, leider nie fertig geworden und tot)

- StormWizard (eigentlich ganz gut, aber doch etwas altbacken)

- TUI war mein erster ernsthafter Ansatz für ein GUI Toolkit, ist verwendbar, aber zu kompliziert und hat einige Design Flaws. Immerhin habe ich damit Programme wie HD-Rec, TuiTED, PosTed etc. realisiert.

Hab ich was vergessen?

Schon alleine deshalb wäre es eine gute Tat, da mal was auf die Beine zu stellen. NTUI ist schon recht weit, braucht aber noch den Feinschliff.
Aufwendige Dinge wie z.B. TextEditor etc. sind aber schon implementiert.
Momentan ist es noch in Amiblitz, also 68k, der Plan ist aber es nach C zu portieren. Das ist relativ einfach, da ich C-Style programmiere und keinerlei Amiblitz spezifische Featrues/Funktionen benutze. Ich nutze Amiblitz, weil es besser zu debuggen ist. Wenn es C wäre, dann würde ich es unter Windows/Visual Studio entwickeln.

Den Nutzen von NTUI sehe ich darin, dass es viel einfacher ist hochwertige GUIs zu bauen, da man für die GUI nichts großartiges programmieren muss. Mit Hilfe eines GUI Builder nicht mal mehr XML Code.
Zudem wäre es OpenSource, auf allen Amiga Systemen in der gleichen Version verfügbar.

--
--
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 19.07.2011 um 11:21 Uhr geändert. ]
 
Der_Wanderer   Nutzer

18.07.2011, 22:08 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

@Holger
Zitat:
Da Du während der Entwicklung Deines Toolkits nicht weißt, wie komplex das Layout einer konkreten Anwendung (falls es je eine gibt) wird, musst Du eine entsprechende Strategie entwickeln, um Layout-Operationen nicht an Operationen zu koppeln, die eigentlich LowLevel sein sollten.

Das Layouten geht in der Regel sehr schnell, nur das neu zeichnen nicht.
Deshalb muss der Mauspointer wohl kaum einfrieren...

Das neuzeichnen bewirkt ledglich ein setzen des Dirty flags, und erst wenn keine Events mehr anliegen, wir neu gezeichnet.

--
--
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 18.07.2011 um 22:09 Uhr geändert. ]
 
Der_Wanderer   Nutzer

18.07.2011, 22:02 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

@Holger

> Nein, das ist "überschreiben".
> "überladen" ist es, wenn man mehrere Versionen mit unterschiedlichen
> Parameter(typen) hat.
Nein, aus OOP Sicht ist das Überladen. Du hast mehrer Funktionen die alle Layout heissen nur mit verschiedenen typen:

Layout(Slider *this, Rect bounds)

Layout(Button *this, Rect bounds)

Layout(Group *this, Rect bounds)

...

In Assembler oder plain C gibt es kein Überladen, daher muss man das mit Funktionpointern machen.

Wenn ein User seine eigene Hook reinsetzt ist das auch Überladen, da, aus OOP Sicht, eine Subklasse gebildet wird.

Aus Assembler oder Plain C Sicht kann es auch "überschreiben" oder "ersetzen" des Funktion Pointers nennen. Ändert nichts dran, dass es letzendlich das gleiche Konstrukt ist, nur anders formuliert.

--
--
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

 
Der_Wanderer   Nutzer

18.07.2011, 21:32 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von AGSzabo:
@Der_Wanderer:

Tja, bei mir wird nichts programmatisch erstellt, sondern alles aus verschachtelten taglisten, die im prinzip die xml struktur wiederspiegeln. Und IDs kommen für mich wohl nicht in frage, weil ein macro-objekt wie eine scrollview, die aus einer view und zwei scrollern besteht, nicht einfach irgendwelche IDs vergeben darf, die der benutzer wohlmöglich auch gernde vergeben würde. es wäre gut, wenn man irgendwie die suche nach IDs des benutzers um die interna des scrollviews herum blocken könnte, dann kann die scrollview aus voller freiheit schöpfen?


Ich denke dein Ansatz hat ein paar prinzipielle Design Probleme, wenn du ein wirklich State-Of-The-Art GUI Toolkit anstrebst.

Ich hatte dich glaube ich schonmal gefragt, anstatt hier NTUI im Detail zu erklären, warum nicht die Kräfte bündeln und NTUI fertig stellen und nach C portieren. Dann hätten alle was davon. Aber du wirst vermutlich nicht von deinem Baby abrücken wollen. Kann ich auch verstehen.



--
--
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

 
Der_Wanderer   Nutzer

18.07.2011, 21:28 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Objekte, die du als Kinder von eigentlichen Objekten erstellst, brauchen ja keine ID. Der Pointer als Referenz sollte doch ausreichend sein oder?

Bei NTUI geht alles mit Pointern. Die IDs sind nur "Convinient Stubbs".

Also es gibt nur eine Funktion für Binding, nämlich
code:
Bind(Object *A, Object *B)


Der Convinient Stubb über IDs macht einfach nur:

code:
BindById(String IdA, String IdB) {
  Object *A = GetObjectById(IdA);
  Object *B = GetObjectById(IdB);
  Bind(A,B);
}


--
--
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

 
Der_Wanderer   Nutzer

18.07.2011, 21:15 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

> man möchte ja nicht blos eine verbidnung von a nach b haben, sondern auch von b nach a und zu d und c!
Richtig, deshalb sprach ich von einem gerichteten Ring.

Die Bindings werden bei mir erst nach dem Erstellen aller betroffenen Objekte gemacht.

Das ist ja auch kein Problem.

Wenn du die GUI programmatisch erstellst:

code:
Slider("firstSlider",...);
Slider("secondSlider",...);

BindByID("firstSlider","secondSlider");


Wenn du sie per XML definierst:

code:
<Slider id="firstSlider" ...>
<Slider id="secondSlider" ... bind="firstSlider">


Wobei man auch den Bind beim ersten Slider eintragen könnte, oder bei beiden. Der XML Parser merkt sich die Bindings und führt sie am Ende aus.

Oder z.b. innerhalb einer Init Funkition eines Slider, der Buttons haben will:

code:
slider* InitSlider() {

  slider *this = malloc();

   ... initialisiere alles für den Slider

  this.incButton = InitButton();
  this.decButton = InitButton();

  Bind(this,this.incButton);
  Bind(this,this.decButton);  

  return this;
}



Das Binding geht so, dass jedes Objekt GENAU einen Pointer hat auf das nächste Objekt im Ring.
Wenn ich ein Binding mache zwischen A und B, dann zeigen sie jeweils aufeinander. Binde ich C mit B, dann wird es dazwischen gehängt.

also habe ich

A B C

Dann sieht es so aus
1. Bind(A,B);

...->A->B->A->...

2. Bind(B,C);

...->A->B->C->A->...

usw.

Wenn jetzt irgendein Objekt einen Wert ändert, von dem es meint "bindungswürdig" zu sein, dann schickt es ein Bind Event über den ganz normalen Event Dispatcher an alle Nachfolger im Ring.
Wenn die wollen können die dann was damit machen oder auch nicht. Hängt eben ganz vom Objekt Typ ab.






--
--
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 18.07.2011 um 21:22 Uhr geändert. ]
 
Der_Wanderer   Nutzer

18.07.2011, 18:15 Uhr

[ - Direktlink - ]
Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Ich glaube du denkst irgendwie zu kompliziert. Wenn man sich lange genug Gedankten darüber macht, kann man alles sehr einfach haben, ohne Liste für das, Liste für jenes.

Also erstmal: Ein Notify ist eine Message, die der Benutzer des GUI Toolkits bekommt, also der Programmierer der Applikation.
Wenn der Programmierer nichts unternimmt, dann läuft die GUI zwar, aber funktionslos. Erst wenn er dann z.B. einen Button ein "OnClick" Notify verpasst, dann meldet sich der Button wenn er betätigt wird mit diesem Notify.
Die App bekommt also eine Message, in der steht dann der Wert, denn der App Programmierer dem Button verpasst hat, zusammen noch mit einigen anderen Informationen, die aber erstmal zweitrangig sind. (z.B. ein Pointer auf das Objekt, dass den Notify geworfen hat, und eine Kopie des Events wodurch das verursacht wurde).

Den gleichen Notify Wert kann ich natürlich auch auf ein Menu Item, eine AREXX Message oder sonst was legen.
Dadurch gewinnt die App an Unabhängigkeit von der GUI. Kann ja dem App Programmierer auch völlig egal sein, ob ein "Bitte-Beende-Mich" Notify nun vom Menu, Key-Shortcut, WindowClose, AREXX, CTRL-C oder einem gewöhnlichen Button der mit "Exit" beschriftet ist, kommt.

Die App bekommt also niemals irgendwelche uninterpretierten Events.

Jedes Widget muss ein paar Felder haben, wo man Notifes setzen kann.
Wieviele Felder das sind und wie sie heissen, hängt vom Widget ab.

Bei einem Button wäre z.B. OnClick (der Normalfall, also bei erfolgreicher Betätigung), OnTouch (wenn er heruntergedrückt wird) und OnRelease (wenn er losgelassen wird, egal ob erfolgreich oder nicht).

Man könnte sich noch OnMouseOver, OnFocus vorstellen ums komplett zu machen.

Aber z.B. eine ListView könnte ein OnDoubleClickItem haben.

usw.

Das ist nun aber alles was völlig anderes als ein Binding.

Ein Binding ist dazu da, gewisse widgets miteinander zu kombinieren, ohne dass die App reagieren muss.
Klar könnte man z.b. einen Slider machen, und zwei Buttons, und in der App abfragen wenn die Buttons gedrückt werden und dann sen Slider bewegen. Das ist aber super hässlich, unzuverlässig und umständlich für den App Programmierer.
Und solche Dinge tauchen immer wieder auf. Und einen Extra Button für die Slider will man ja auch nicht programmieren, wenn man schon schöne "normale" Buttons hat.
Also verknüpfe ich sie indem ich einen Ring erstelle.
Dafür gibts spezielle Binding Events, die dann durch den Ring geschickt werden. Z.b. "IncreaseValue" oder "DecreateValue" oder "SetValue".
Bekommt ein Slider ein IncreaseValue, dann schiebt er sich einen Schritt weiter. Bekommt er ein SetValue, dann spring er dorthin.

Ein Button würde sich von einem IncreaseValue nicht beeindrucken lassen und tut nichts.
In NTUI gibts etwa 10 solcher Bind Events, wobei in vielen widgets die meisten einfach ignoriert werden.
Z.b ein TextBox schickt ein SetString. Ein Image Widget würde damit aber nichts anfangen, eine weitere Textbox oder ein FloatText würden das natürlich übernehmen.
Z.b. kann man eine TextBox mit einem Dateiauswahl Button "binden", dann wird der Dateiname als String immer hin und her übermittelt, wenn sich was ändert und so synchron gehalten.

Oder Scroller werden mit der Ansicht eines Multi-Line Textbox syncrhon gehalten.







--
--
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

 
 
Erste 1 2 3 4 5 -6- 7 8 9 10 11 >> Letzte Ergebnisse der Suche: 1229 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter      Benutzername
Suchoptionen
Nur in diesen Foren suchen
   nur ganze Wörter
Nur Titel anzeigen
alle Treffer anzeigen

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