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

amiga-news.de Forum > Programmierung > OOP-GUI Systeme und Content-Clipping [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 2 -3- 4 [ - Beitrag schreiben - ]

15.07.2011, 13:43 Uhr

Holger
Posts: 8116
Nutzer
@AGSzabo:
Schreib doch neue Sachen in neue Beiträge, statt einen alten mehrfach zu editieren.

Zitat:
Original von AGSzabo:
übrigens, ich habe ein "pages" widget, das kann multiple inhalte an der selben stelle, von denen im layout der größte genommen wird und von denen nur einer an der front sein kann. die anderen werden dann der funktion SetVisible(false) übergeben.

Aha, Du hast also auch Objekte, die nicht sichtbar sind und Platz wegnehmen. ;)

Zitat:
ps: was ist mit einem popup-menu? es ist nicht on screen und will trotzdem sichtbar sein und auch mausklicks erhalten und mehr.
Wieso ist ein Popup-Menü nicht on-screen?
Natürlich ist es on-screen, während es angezeigt wird.
Zitat:
pps: wenn du den rasport mit dem layout misenden willst, müsste das layout auch immer von ganz oben kommen. ein balance-widget kann es nicht selber nur an seine beiden childs senden ... oder?
Ich kann Deine Logik nicht nachvollziehen. Ein Balance-Widget bekommt seinen Kontext von oben, wie alle anderen Widgets auch, und sendet ihn an seine Kinder, egal, ob das nun zwei oder zweihundert sind. Wie alle anderen Widgets auch.
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

15.07.2011, 17:15 Uhr

AGSzabo
Posts: 1663
Nutzer
@Holger:

> reservierst Du von Anfang an so viel Platz für die Tabs, dass auch nicht sichtbare Tabs Platz hätten?

ja.


> An sich ist doch ein Objekt on-screen, wenn es (und alle seine Parents) visible und der Root ein Fenster ist, dass tatsächlich geöffnet ist. Diese Eigenschaft ändert sich doch nicht durch layouten.

hmmm, genauso ist das bei mir.


> Klar brauchst Du solche Informationen auch für andere Operationen als das Zeichnen. Trotzdem sind das alle Operationen, die somit diese Informationen als Parameter übergeben bekommen können. ... Ein Balance-Widget bekommt seinen Kontext von oben, ...

Die Frage war, wenn der rastport für die fontgröße NUR vom fenster aus mit der layout-message mitgeschickt wird, kann kein kind selber das layout seiner kindeskinder ändern .. bzw müsste dazu auch den rastportzeiger schon haben ...


> Schreib doch neue Sachen in neue Beiträge, statt einen alten mehrfach zu editieren.

Es gibt tatsächlich foren, wo das 'verboten' ist ("sonst fliegst du raus" etc)

--
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 15.07.2011 um 17:16 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

15.07.2011, 18:14 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
Die Frage war, wenn der rastport für die fontgröße NUR vom fenster aus mit der layout-message mitgeschickt wird, kann kein kind selber das layout seiner kindeskinder ändern .. bzw müsste dazu auch den rastportzeiger schon haben ...

Du verwechselst Größenänderung mit Layouten. Ein Balance-Widget oder eine Split-Pane ändert lediglich die Größen seiner Kinder.

Der Layout-Prozess läuft genauso wie das Zeichnen ab: vorhergehende Operationen, wie z.B. eben jenes Größen ändern, markieren Objekte als layouttechnisch dirty, das kann sehr viele Objekte betreffen, und hinterher wird von der Wurzel ausgehend das gesamte Layout aufgefrischt. Wobei Objekte, die nicht dirty sind, je nach Kontext übersprungen werden können.

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

[ - Antworten - Zitieren - Direktlink - ]

15.07.2011, 22:38 Uhr

AGSzabo
Posts: 1663
Nutzer
@Holger:

Kapier ich nicht was der Unterschied zwischen Layout und Größenänderung sein soll oder ist. In beiden Fällen gibts neue coordinaten oder neues width/height?

Ich hab noch ein neues Problem mit den Layers: ab der zweiten Installation eines neuen cliprects (das erste geht gut), wartet der amiga 8 sekunden bis das fenster nach einer größenänderung neugezeichnet wird. im emulator tritt dieses problem nicht auf.

ich habe schon ausprobiert, statt einer statischen regionstruktur, in die ich hineinschreibe, mal NewRegion/OrRectRegion/DisposeRegion zu verwenden, das hat aber nichts gebracht. :( (da ich immer nur 1 clipbox habe, also immer nur einen rechteckigen bereich als maske, enthält meine region auch immer nur 1 rectangle, das kann man statisch lösen)

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

[ - Antworten - Zitieren - Direktlink - ]

16.07.2011, 11:20 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Ja, bei mir wäre eine Größenänderung auch das gleiche wie ein Layout.
Schliesslich muss man, je nach Widget, ein eMenge anpassen je nach Größe.

Wegen dem RastPort beim Layout... den hole ich mir immer durch hochlaufen zum Fenster.


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

16.07.2011, 14:09 Uhr

AGSzabo
Posts: 1663
Nutzer
@Der_Wanderer:

> Wegen dem RastPort beim Layout... den hole ich mir immer durch hochlaufen zum Fenster.

Woher weiss ein Widget, welches Objekt schließlich das Fenster ist?
--
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 - ]

16.07.2011, 17:56 Uhr

AGSzabo
Posts: 1663
Nutzer
Das clippen der view und damit - wer hätte es gedacht - des gesamten OX-Systems funktioniert jetzt perfekt. Nun kommt das filtern von Mausevents dran. Es soll nur diejenig view Mausevents erhalten, über der sich die Maus gerade befindet, ausgenommen wenn die taste schon gedrückt wurde und während dann die maus bewegt wird, soll das gewählte objekt weiterhin mousemoves und buttonups erhalten. zwei schwierigkeiten sind dabei zu meistern: hat zB ein button den fokus, werden alle messages - im jetzigen system - direkt an diesen button geleitet. dadurch erhält er zwar auch mousemoves außerhalb der view, ist dann aber auch außerhalb der view - da wo er nimmer zu sehen ist, clickbar. Und zweitens, wenn eine view in einer view ist, müsste die höhere view erstmal die tiefere fragen, ob die maus über der tieferen ist? wie kann man das alles machen?
--
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 - ]

16.07.2011, 21:39 Uhr

AGSzabo
Posts: 1663
Nutzer
Und um das Ganze ab zu runden, sollen schließlich die slider mit der view und umgekehrt kommunizieren können. ich habe mal im mui handbuch nachgesehen, wie sowas von user's seite aus sieht. aber wie programmiert man das?

http://www.sasg.com/mui/autodocs/MUI_Notify.html#MUIM_Notify

Wie wird es gehandhabt, daß ein slider, der beim moven mit der maus sein eigenes attribut intern ändert, das an jmd weiterleitet? muß er selber in einer notifikationsliste nachsehen und die dort eingetragenen methoden aufrufen, oder langt es, wenn er das dem system überlässt? was mich ein bischen stört, daß ich in einem objekt für jede änderung einen code einbauen muss, der das abfängt und irgendwie weiterleitet. kann man das nicht irgendwie global handhaben?

Und wenn ein SetAttr() vom userprogramm auf ein objekt ausgeführt wird, auch dann müsste man den weiterleitungsmechanismus anleiern ... in dem fall könnte das die SetAttr() funktion selber handhaben, die in der notify-liste des objekts nachschaut und von dort an dritte weiterleitet?

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

[ - Antworten - Zitieren - Direktlink - ]

17.07.2011, 12:04 Uhr

Der_Wanderer
Posts: 1229
Nutzer
1. Jedes Objekt hat auch einen Pointer auf das Elternobjekt.
Wenn du einen RastPort brauchst, dann läufst du so lange nach oben bis eines der Objekte sage "Hey, ich wäre derjenige der den RastPort zur Verfügung stellt!".
Das muss nicht immer ein klassisches Fenster sein, z.B. bei einem Pop Up Menu wäre es das Subwindow des Menu Titles, oder beim aufgeklappten Cycle wäre es das Subwindow des Cycle Buttons.

Das macht man auch Rekursiv, z.b. mit einer Methode wie "GetRastPort(object)". Wenn das Objekt kein eigenen RastPort hat, dann rüft es einfach "GetRastPort(object->parent)", und irgendjemand in der Reihe wird dann schon was tun. Kann natürlich auch NULL zurückkommen, wenn z.b. das Fenster zu ist.

2. Das mit dem Get/SetAttr macht man mit "Überladen".

Also stell dir vor, du hast ein Integer Wert, den man bei jedem Gadget wieder findet. Dann schreibst du eine allgemeine Funktion (also für ein Object, nicht ein spezielles Widget), z.b.

code:
SetInteger(object this, int value) {
  this.value = value;
}


Jetz gibt es aber ein paar Ausnahmen, z.b. ein Object anmens "Foobar" wo z.b das Value nicht negativ sein darf und dann auf 0 geklippt werden soll, aber eben nicht bei allen.
Das heißt jetzt nicht, dass du jedem Object nun eine eigene Implementierung verpassen musst, nur dem einen speziellen.
Wenn du keine Sprache nutzt, die OOP macht, dann machst du das so mit hilfe von Funktionpointer, die jedes Object speichert. Wenn der Funktionpointer NULL ist, wird die Eltern-Implementierung genutzt.


code:
/* Spezielle Funktion für Foobar */
void Foobar::SetInteger(object this, int value) {
  Foobar fb = (Foobar)this; /* der Cast ist hier unnötig, aber i.A. notwendig */ 
  if (value<0) value=0;
  fb.value = value;
}

/* Allgemeine Funktion auf "Object" Ebene */
void Object::SetInteger(object this, int value) {
  if (this.SetInteger!=NULL) { /* wir haben eine spezielle Funktion */
    this.SetInteger(this,value);
  } else { /* wir nutzen die allgeimeine Funktion */
    this.value = value;
  }
}


Die Funktionpointer werden bei der Initialisierung gesetzt.
Theoretisch könnte jetzt auch der App Programmierer hergehen, und eine dieser Funktionen austauschen, für maximale Flexibilität.

Das ganze nennt man "eine Funktion überladen".
Das kann man auch durch mehrere Hierarchie Ebenen hindurchziehen.
Auch ist es möglich, z.b. bei einer Draw Funktion, die "alte" weiterhin zu benutzen und nur ein kleine Ändrungen hineinzutun,
z.B. Markierungen in einem Slider.

--
--
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 17.07.2011 um 12:10 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 17.07.2011 um 12:10 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 17.07.2011 um 12:13 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

17.07.2011, 12:35 Uhr

AGSzabo
Posts: 1663
Nutzer
@Der_Wanderer:

Danke, das mit dem RastPort habe ich teilweise, das mit dem Überladen garnicht verstanden. Ich möchte ja ein Notify haben. Und weisst du auch, wie man die mauskoordinaten filtert, damit sie immer an dasjenige view gehen, über dem man gerade ist?

Ich habe gerade ein wenig nachgedacht, wegen der maus: system schaut nach, ob die maus im obersten view ist, wenn nicht, überlasse die maus dem höheren element. wenn schon, schaut es nach, ob die maus im nächstunteren view ist. wenn nicht, überlasse die maus dem höheren view. ist das gut? ich weis nicht, ob das auch funktioniert, wenn ein objekt den focus hat und dann (bei mir) messages direkt vom fenster empfängt, ohne dass sie durch den baum gehen, und aber in den baum durch lässt, wenne s sie nicht konsumiert.

--
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 17.07.2011 um 12:49 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

17.07.2011, 21:30 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Normalerweise ist das so:

Du hast eine Routine, die die Events beim Betriebssystem abholt.
Die heisst bei mir CollectAmigaEvents().
Da sind dann IDCMP, App, AREXX, ScreenNotify usw. drin, alles was ein Programm so empfangen kann/möchte.

Die Funktion erstellt dann Events im Format des GUI Toolkits. Das ist wichtig, wenn man es portabel halten will, da man dann lediglich CollectAmigaEvents() gegen CollectSDLEvents(), CollectWin32Events() etc. austauschen muss, und alles danach bleibt gleich.

Aber auch wenn man nicht vor hat es zu portieren, ist das eine gute Idee die Events in eine sog. kanonische Form zu bringen, damit sich die Widgets nicht mit Implementationsdetails von AmigaOS herumschlagen müssen, was mitunter etwas kompliziert werden kann. So hat man den ganzen "Dreck" in eine Funktion zusammengeschnürt, und fasst das dann besser nie wieder an...

Also nachdem man nun ein "MyGUIToolkit"-Event hat, also ein Struct was so aussieht wie du es verarbeiten willst, dann muss man sich fragen, wohin damit. Da muss man sich nun eine clevere Rangfolge überlegen, um später möglichst flexibel zu sein.

Was jetzt kommt nennt man "dispatchen". Es ist immer gut, sich die gebräuchliche Terminologie anzueignen, dann versteht jeder "sachkundige" gleich was du vor hast.

Beim Erstellen eines Events in dem Format deines GUI Toolkits wurde in die Struct das Urheber Object eingetragen, z.B. das Window, wo ein Mausklick entstanden ist, oder der AREXX Port der eine Message empfangen hat. (wie gesagt, das Object, nicht ein Pointer auf Window oder AREXX Port, das wäre ja wieder OS spezifisch und ist js auch bereits abgefrühstückt in CollectAmigaEvents).

Der Urheber, ein GUI Toolkit Object, bekommt nun dieses Event in seiner "dispatch" Funktion aufgerufen.
Der kann dann frei entscheiden, was er damit tut.
Der häufigste Fall dürfte ein Window sein. Deine Windows haben dann, wie alle Objekte, eine Dispatch Funktion. Die kann sich dann, in Abhängigkeit was für ein Event es ist, überlegen was passiert.

Z.B. ist es ein "Close" Event, dann kann sich das Window schließen.

Ist es ein Mausklick, dann fängt die Dispatch Funktion des Windows an zu prüfen, wer damit was anfangen kann.
Als erstes sollte das Object gefragt werden, das den Focus hat, indem das Event mit der Dispatch Funktion des Focus-Pbjects aufgerufen wird. Das Object könnte dann theoretisch wiederum weiterdelegieren oder etwas mit dem Event machen. Macht es nichts mit dem Event, gibt die Dispatch Funktion FALSE zurück, wenn sie was damit gemacht hat, dann TRUE.

So weis die Übergeordnete Dispatch Funktion, ob das Event "konsumiert" wurde oder noch nicht.
Will also nun z.B. das Objekt mit dem Focus das Event nicht, gibt dessen Dispatch Funktion FALSE zurück. (z.B. bei einem Mausklick außerhalb der Boundaries).
Dann ist wieder die Dispatch Funktion des Fensters an der Reihe. Es delegiert nun das Event weiter an das Object, worüber der Mauspfeil steht. Meistens konsumiert dann dieses Objekt das Event. Wenn nicht, könnten wir noch andere Sachen anstellen, aber bei NTUI ist dann bereits Schluß und das Fenster selbst gibt FALSE zurück.

Dann sind wir wieder auf Engine Dispatch Ebene, was mit einem Mausklick nix anfangen kann, und das Event wird endgültig entsorgt ohne Effekt.

Die Dispatch Strategie kann natürlich verschieden aussehen. So wie ich es bei NTUI mache denke ich aber ist es gut und flexibel. So kann z.b. ein Objekt den Mauspfeil ändern beim drüber fahren, z.B. ein Listview um die Colums zu verschieben, aber trotzdem könnte das Objekt mit dem Focus auch auf Mausbewegungen reagieren und ein Ändern des Mauspfeils unterbinden, falls es das Event konsumiert.

Beispiel:

Du hast eine TextBox, die normalerweise den üblichen Text-Edit Mauspfeil setzt wenn man darüberfährt (das macht die TextBox in ihrer Dispatch Funktion, sobald ein MouseMove kommt der innerhalb der Boundaries liegt).
Jetzt hat aber z.B. ein Cycle Button den Focus. Die TextBox soll aber natürlich trotzdem reagieren können.
Das funktioniert so, dass der Cycle Button bei MouseMove Events "FALSE" zurückgibt, es interessiert ihn also nicht, somit bekommt danach das Mouse-Over Objekt das Event angeboten, hier die TextBox.

ABER: wenn ich jetzt den CycleButton aufklappe und gedrückt halte, und die Maus aus der Auswahlbox rausbewege, möchte ich NICHT, dass die TextBox reagiert. (oder die Auswahlbox könnte ja über die TextBox ragen). Während der Cycle Button also gedrückt ist, kann er die MouseMove Events konsumieren, gibt im Dispatch also TRUE zurück. Somit kommt das Event nicht mehr bei der TextBox an, und sie kann nicht den Text-Edit Mauspfeil setzen.

Pew! Macht das Sinn für dich soweit?


--
--
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 17.07.2011 um 21:43 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

17.07.2011, 21:50 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Zum Überladen von Funktionen, (oder im OOP Sprachgebraucht Vererbung und Subclassen von Methoden):

Jedes Object hat Function-Pointer auf seine Version z.b. von Layout, Dispatch oder Draw.

Es kann z.B. eine allgemeine Function geben für Layout, wo einfach nur die Boundaries gesetzt werden, was mehr oder weniger für jedes Object zutrifft.

Wenn jetzt aber ein Object "FooBar" was Spezielleres benötigt, kann man die Funktion "überladen". Bzw, im OOP Sprachgebrauch würde das bedeuten, das speziellere Object "FooBar" ist nun eine Subklasse vom allgemeinen Object "Widget" und kann diverse Funktion "überladen", also ersetzen. Konkret wird der Function-Pointer von z.B. "WidgetLayout(bounds)" auf "FooBarLayout(bounds)" umgesetzt. FooBarLayout() sollte natürlich auch die Boundaries setzen (z.b. durch Aufruf von WidgetLayout()), könnte aber noch andere organisatorischen Dinge tun wie z.B. Offsets von Text etc. berechnen, damit das später beim Draw() schneller geht und vor allem Kinder-Objekte platzieren und deren Layout Funktion aufrufen.

--
--
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 17.07.2011 um 21:54 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

17.07.2011, 22:02 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Zum RastPort:

Die Aussage war, du solltest von dem RastPort Pointer keine Kopie erstellen. Du solltest grundsätzlich vermeiden, Kopien von Pointern zu erstellen, denn ein Pointer kann an anderer Stelle ungültig gemacht werden, und somit hast du einen Seiten Effekt.
Seiten Effekt == böse böse böse und führt zu anfälligem und schwer wartbarem Code.

Statt dessen gehst du in deinem Baum nach "oben", solange bis ein Objekt kommt was einen RastPort besitzt, in den du malen sollst. z.B. ein Fenster oder auch ein aufgeklapptes Pop Up Menu. Kann natürlich auch NULL sein, wenn das Fenster zu ist. Dann machst du in deinem Draw einfach nichts und springst zurück.

Der Mehraufwand, den Pointer zu holen ist überschaubar.

Der Mehraufwand, Kopien von Pointern zu synchronisieren, scheint am Anfang geringer, wächst aber bei zunehmender Komplexität ins Uferlose und so schaufelst du deinem GUI Toolkit sein Grab...

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

[ Dieser Beitrag wurde von Der_Wanderer am 17.07.2011 um 22:05 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

18.07.2011, 08:19 Uhr

AGSzabo
Posts: 1663
Nutzer
@Der_Wanderer:

> Pew! Macht das Sinn für dich soweit?

JA, danke, fast genauso löppt es schon bei mir mit den (maus)events. Ich habe blos die intuimessage struktur beibehalten und um ein langwort für meine Zwecke erweitert. Und es geht immer alles an das window, es seiden, das applikatinsobjekt, daß den "collectevents" mechanismmus enthält, kann oder will es selber verwalten, was aber imo bei mir noch nicht passiert. Und ein Popup menu kann noch nicht objekte enthalten, sondern ist eine eiheit. Mein Interesse gilt da noch der Strategie bei Mausklicks in views in views. man muß da ja nicht nur fragen, ob die maus über einer view ist, sondern auch eine zweite, die sich mit der ersten überschneidet, muss die mögliche fläche mit eingrenzen. naja, das schaffe ich schon noch.

Aber wie ist es nun mit dem Notify? Das interessiert mich am meisten.

Und zum "überladen" von Funktionen: meine subclass könnte auch die message immer zuerst bekommen und wenn sie will dann noch hinterher oder vorher den dispatcher der elternklasse aufrufen. so spart man sich die evtl vielen funktionspointer. so kann man Zb auch einen Slider um pfeilebuttons erweitern, oder? naja, ist nicht ganz das selbe wie das was du da hast... bei dir kann man ja sogar pro objekt andere funktionen 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 18.07.2011 um 09:22 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

18.07.2011, 11:19 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Zitat:
Und ein Popup menu kann noch nicht objekte enthalten, sondern ist eine eiheit.
Wenn du es richtig machst, dann kann ein PopUp Object wiederum alles enthalten. Das ist dann sehr mächtig.
Ich überlege z.B. gerade, ob ich den Tab eines Tabview nicht auch als Gruppe organisiere, sodass man dort reintun kann was man will, z.B. mehrere Grafiken oder einen Close Button etc.

Zitat:
Mein Interesse gilt da noch der Strategie bei Mausklicks in views in views. man muß da ja nicht nur fragen, ob die maus über einer view ist, sondern auch eine zweite, die sich mit der ersten überschneidet, muss die mögliche fläche mit eingrenzen. naja, das schaffe ich schon noch.
Der Test, über welchem Objekt ich mich befinde geht auch hierarchisch. So kann z.b. ein ScrollView den Mausklick Offset verschieben oder die Weiterleitung stoppen, falls nötig.

Zitat:
Aber wie ist es nun mit dem Notify? Das interessiert mich am meisten.
Das ist einfach. Ein Objekt kann verschiedene Notify Values haben.
z.B. "OnClick". Ein Button kann dann, falls ein Notify Wert gesetzt ist, eine Notify Message generieren wenn er merkt dass er geclickt wird.
Je nach Objekt kann es durchaus eine ganze Reihe von solchen Gelegenheiten geben, wo man ein Notify los werden will.
Z.b. OnClick, OnTouch, OnRelease, OnChange, OnFocus, OnMouseOver, OnTick etc...
Wenb der User allerdings keine Notify Werte setzt, dann bekommt er auch keine. So muss sich der User nicht um jeden Dreck kümmern, sondern nur darum was ihn interessiert. Z.b. setzt er bei einem Button
OnClick = "QuitApplication".
Er kann aber z.B. auch bei einem Menu Item den gleichen Notify Wert setzen, und auf den CloseButton eines Fenster auch.
Dann muss er nur einmal auf "QuitApplication" lauschen, und sich nicht mit Details rumschlagen wer nun der Auslöser war. Kann auch eine AREXX Message gewesen sein oder ein CTRL+C.
Wichtig ist halt, dass man nur einmal das Programm Ende empfängt und implementiert. Später kann man diese Notify Value überall dort eintragen, wo man beim GUI Desgin der Meinung ist dass diese Notify Ausgelöst werden soll. Das ist der grundlegende Unterschied zwischen Notify und Event.

Zitat:
Und zum "überladen" von Funktionen: meine subclass könnte auch die message immer zuerst bekommen und wenn sie will dann noch hinterher oder vorher den dispatcher der elternklasse aufrufen. so spart man
sich die evtl vielen funktionspointer. so kann man Zb auch einen Slider um pfeilebuttons erweitern, oder? naja, ist nicht ganz das selbe wie das was du da hast... bei dir kann man ja sogar pro objekt andere funktionen haben..

Weis nicht genau wie du das meinst, aber die paar Pointer pro Object kann man verkraften, oder nicht? Der Vorteil ist, dass jedes Objekt individuell einen Satz von Funktionen haben kann, der auch der App Programmierer austauschen kann, wenn er was ganz spezielles benötigt was das GUI Toolkit nicht vorgesehen hat.

Pfeil Buttons bei Slidern mache ich ganz anders.
Das sind einfach Kinder des Sliders und stink normale Buttons.
Beim Initialisieren des Sliders werden sie allerdings mit dem Slider verknüpft, mit einem sog. "Binding". Das ist ein gerichteter Ring von Objekten. Wenn sich eines ändert, ändern sich die anderen dann mit.
Dazu brauchst du ein zusätzliches Feld in deinem Objekt was einen Pointer auf das nächste Objekt in der Bind Group hat.

Dazu aber vielleicht später mehr...


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

18.07.2011, 17:33 Uhr

AGSzabo
Posts: 1663
Nutzer
@Der_Wanderer:

> Ein Button kann dann, falls ein Notify Wert gesetzt ist, eine Notify Message generieren wenn er merkt dass er geclickt wird.

Aha. Ich frage mich, wie das programmiert wird. Aber offenbar brauche ich das für die scrollview garnicht, weil es mit Binding funktioniert oder funtionieren könnte, wenn ich will. Trotzdem würde ich gerne wissen, wie das Notify intern ausschaut. Ich habe mir überlegt, das objekt welches Notify unterstützt, hätte einen Liste mit den zu notifizierenden Attributen und Werten oder so und ruft, wenn es ein attribut ändert eine masterlibraryfunktion auf, mit dem attribut und dem wert und einem zeiger auf sich objekt selbst, diese funktion geht dann die liste durch und informiert das zielobjekt wie gewünscht. der nachteil ist, oder scheint mir zu sein, dass das sendende objekt für jeden wert, den es notifizierbar machen möchte, an allen möglichen stellen wo der wert geändert werden kann, diese funktion aufrufen muss. außerdem weis ich nicht, ob man so einen ring vermeiden kann. vielleicht indem man empfangene wertändeurngen generell nicht weiterleitet, nur sendet. das ist aber schlecht für das userprogramm weil es dann alle betroffenen objekte selbst ändern müsste.

ein binding habe ich übrigens bereits: für das next/pref objekt beim drücken von der Tabulator-Taste.

> Ich überlege z.B. gerade, ob ich den Tab eines Tabview nicht auch als Gruppe organisiere,

Das ist durchaus überlegenswert. Die Frage die sich mir dabei stellt, ist, das wenn sich diese gruppen in der standard childsliste befinden, woher weiss dann die tabsklasse welches welches ist und wo. bei mir habe ich tabs so programmiert, das nur das innere content child des _aktive_ tab in der standardliste hängt und beim clicken eines anderen tab ausgetauscht wird. zudem gibt es eine liste mit allen tabs, da stehen im moment auch die zeiger auf die titeltexte drin. Ich glaube, da könnte man auch die zeiger auf dies gruppen die du meinst, eintragen. es gibt aber auch gründe dafür, dass diese gruppen zusätzlich in der standardliste sein müssen, damit nicht die tabsklasse bestimmte messages usmtändlich an diese gruppen weiterleiten müsste.

--
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 18.07.2011 um 17:52 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

18.07.2011, 18:15 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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


[ - Antworten - Zitieren - Direktlink - ]

18.07.2011, 18:27 Uhr

AGSzabo
Posts: 1663
Nutzer
@Der_Wanderer:

In MUI ist ein Notify auch das, was ich will mir der Liste und dem Slider. An sonstens bräuchte ich nach deiner Erklärung erst recht kein Notify, weil bei mir alles über Callback Hooks funktioniert. Die App bekommt blos das, wo sie ihre Hooks eingetragen hat. Zb wird für einen Button beim erstellen des gui ein attribut BA_hook gesetzt...
--
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 - ]

18.07.2011, 18:45 Uhr

AGSzabo
Posts: 1663
Nutzer
Wie bindet man die Objekte?

In den Radiobuttons habe ich es so gelöst, daß man jedem Radiobutton beim erzeugen eine RING-ID mitgeben kann. Die radiobutton klasse sucht sich die buttons mit der selben ring-id aus dem ganzen gui heraus und hällt es so, dass davon immer nur einer gedrückt sein kann.

das ist aber imo nicht gut, der app programmierer muss eine übersicht über alle IDs halten.

Im Falle von der View und dem Slidern wäre es das beste, wenn man den objekten schon zur erzeugungszeit einen pointer auf das gebundene objekt mitgeben kann. das geht aber nicht, weil man schließlich nicht riechen kann, welches objekt zuerst erzeugt wird, da kann höchstens eine neue klasse wissen, welche die scrollview aus den unterobjekten scroller und view erstellt. daher habe ich mir einen mechanismus wie folgt ausgedacht: ein spezielles tag "OX_RELPTR" bewirkt beim erzeugen, dass der pointer auf das gerade erzeugte objekt an die adresse "base"+tag_data geschrieben werden soll. "base" ist ein zeiger auf einen beliebigen buffer, den man beim erzeugen der objekte mitgeben kann. Zb die globalen eines programms, oder die datenfelder der scrollview, die dort die zeiger von scroller und view sammelt. es gibt nun ein gegenstück zum OX_RELPTR tag, das bewirkt, daß ein zeiger von einem offset gelesen wird. wohin, das entscheidet die klasse zu der das lesende attribut gehört. der eine setzt also den zeiger, der andere setzt sich selber einen zeiger auf diesen zeiger und ließt daraus wenn alles fertig ist...

wie würdest du es machen oder hast es gemacht? dein binding scheint sehr anders und noch einfacher zu funtkionieren... man möchte ja nicht blos eine verbidnung von a nach b haben, sondern auch von b nach a und zu d und c!
--
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 18.07.2011 um 18:50 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

18.07.2011, 21:15 Uhr

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

[ - Antworten - Zitieren - Direktlink - ]

18.07.2011, 21:22 Uhr

AGSzabo
Posts: 1663
Nutzer
@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?

ps: daneben ist es aber auch bei mir möglich, die gui oder teile davon programmatisch zu erstellen. zb nutzt dies das fenster um sich das menu und eine toolbar zu generieren. davon merkt die app nichts, auch wenn sie ihre gui die dann ins fenster kommt aus taglisten erstellt.

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

[ - Antworten - Zitieren - Direktlink - ]

18.07.2011, 21:28 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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


[ - Antworten - Zitieren - Direktlink - ]

18.07.2011, 21:32 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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


[ - Antworten - Zitieren - Direktlink - ]

18.07.2011, 21:47 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
Kapier ich nicht was der Unterschied zwischen Layout und Größenänderung sein soll oder ist. In beiden Fällen gibts neue coordinaten oder neues width/height?

Wenn Du die Größe einer Komponente setzt, muss gegebenfalls, das Layout sämtlicher enthaltener Komponenten berechnet werden.

Natürlich kann man grundsätzlich das komplette Layout neuberechnen, sobald eine Komponenten ihre Größe ändert, aber...

Wenn Du bei einer SplitPane den Divider mit der Maus ziehst, willst Du mit Sicherheit nicht das Layout dieser Komponente und sämtlicher enthaltenen Komponenten neu berechnen, während der Benutzer einen eingefrorenen Mauszeiger sieht.

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.
Zitat:
Original von Der_Wanderer:
Das ganze nennt man "eine Funktion überladen".

Nein, das ist "überschreiben".
"überladen" ist es, wenn man mehrere Versionen mit unterschiedlichen Parameter(typen) hat.

Zitat:
Ich überlege z.B. gerade, ob ich den Tab eines Tabview nicht auch als Gruppe organisiere, sodass man dort reintun kann was man will, z.B. mehrere Grafiken oder einen Close Button etc.
Sehr empfehlenswert.

Zitat:
Original von Der_Wanderer:
Also erstmal: Ein Notify ist eine Message, die der Benutzer des GUI Toolkits bekommt, also der Programmierer der Applikation.
...
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.

Das ist bei BOOPSI ein und dasselbe...

Notify ist nur ein spezielles Target für das, was Du beim Binding machst. Die Funktionsweise hängt nur davon ab, wie man die Objekte miteinander verknüpft. Und es heißt einheitlich "notify".

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

[ - Antworten - Zitieren - Direktlink - ]

18.07.2011, 22:02 Uhr

Der_Wanderer
Posts: 1229
Nutzer
@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


[ - Antworten - Zitieren - Direktlink - ]

18.07.2011, 22:08 Uhr

Der_Wanderer
Posts: 1229
Nutzer
@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. ]

[ - Antworten - Zitieren - Direktlink - ]

18.07.2011, 22:11 Uhr

AGSzabo
Posts: 1663
Nutzer
@Der_Wanderer:

GUI hat mich immer fasziniert, seit ich mein erstes in Amigabasic geschrieben hatte. Da war das noch ein Programm, mit dem man etwas anfangen konnte, jetzt ist es blos noch die gui selber, die im fordergrund steht. ich denke state of art guis gibt es schon zu genüge und bezweifele ob man das noch besser machen kann. es hat für mich blos einen faszinations- und lern effekt. ich kann kein c und möchte, sofern ich die dinge nicht verstehe, auch nicht von meinem design - das ich naturgemäß gut finde - abweichen. wenn ich es verstanden habe, und ich glaube, daß es im grunde sehr einfach ist, mache ich es auch anders. über deine einladung lässt sich nachdenken, ich glaube aber, dass mir die vorraussetzungen fehlen. ich kann halt assembler. mit dem xml parser den ich neulich schrieb, bin ich wohl am nähesten zu dem gekommen wo die welt jetzt steht. bevor ich noch weiter in diese richtung gehe und wohlmöglich noch ein create-script oder sowas schreibe, kann ich aber auch gleich richtig c lernen. neee, halt mal, ich hab schon in java und javascript programmiert, das war möglich. Aber mit c .. ? ich hoffe wenigstens, daß meine ideen und amateurhaften fragen dir in irgendeiner hinsicht weiterhelfen.

> während der Benutzer einen eingefrorenen Mauszeiger sieht.

Es geht tatsächlich mehr als ich dachte. Bisher war ich versucht akribisch jede kleinste "zu viel" berechnung oder darstellung zu vermeiden, aber wanderer hat mich ermutigt, das gelassen und so einfach anzugehen. jetzt gibts bei mir zwei level: REFRESH und REDRAW. Letzteres zeichnet alles neun, zb wenn sich die koordinaten verändert haben, beim refresh KANN das gadget wisse, was zu tun ist, muss aber nicht. naja, beim layout ist es vielleicht ähnlich. zB pixelbreit eines textes nur berechnen, wenn der font sich geändert hat. aber die rechner heute sind sowas von schnell, da gibt es nie und nimmer eingefrorene mauszeiger. zumindest geht sicher mehr als du denkst.

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

Oder wie auf altlibrarianisch: patchen. :)

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

[ - Antworten - Zitieren - Direktlink - ]

19.07.2011, 10:11 Uhr

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

[ - Antworten - Zitieren - Direktlink - ]

19.07.2011, 10:32 Uhr

AGSzabo
Posts: 1663
Nutzer
@Der_Wanderer:

Ich dachte garnicht so sehr an Amiga sondern an qt oder gtk oder was auch immer ubuntu jetzt benutzt. in einem interview haben die friedens verkündet, daß ihr reaction nimmer auf dem stand der dinge sei und dass sie vorwärtsschauen auf sachen wie qt zb. von mir aus können die auch ntui benutzen. dieses hdrec scheint wirklich supermächtig zu sein!

was mir schon immer gefallen hat, so wie er es mir vor etwa 20 jahren erklärt hat, war armin sanders mini-toolkit, daß er extra für sein programm Rap-Top-Cop geschrieben hatte. damals war mui auch gerade in den startlöchern, ich konnte mich aber nie damit anfreunden. es war langsam und schwerfällig und das configprogramm war überladen mit einstellungen die wohl kaum ein ernsthafter mensch wirklich braucht. die skins waren auch einfach nicht schön.

irgendeine windows lösung zu verwenden liegt mir garnicht. ich benutzte zum entwickeln fast nur den EUAE unter ubuntu, weil das so viel es will abstürzen kann und ich meinen favorite texteditor gedit nicht nach jedem absturz neu booten muss. gelegentlich teste ich es unter os4, das im bezug auf codefehler sehr 'streng' ist, aber auch einen guten debugger-output produziert. mensch das müsste ich endlich mal wieder machen. :)

ich bin von meinem skin sehr angetan, falls du noch nicht gesehen hast (?), hier ein altes beispiel: http://otaku.onlinehome.de/xuibig.jpg

wie könnte ich dich unterstützen? nur mal so rein ohne versprechen gefragt...

ps: ich habe gerade das mal in den news gefunden: http://www.amiga-news.de/de/news/AN-2011-01-00048-DE.html
--
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 10:47 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

19.07.2011, 11:28 Uhr

Der_Wanderer
Posts: 1229
Nutzer
> 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


[ - Antworten - Zitieren - Direktlink - ]


1 2 -3- 4 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > OOP-GUI Systeme und Content-Clipping [ - Suche - Neue Beiträge - Registrieren - Login - ]


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