Selfmade GUI Programmierung Tips?

amiga-news.de Forum > Programmierung > Selfmade GUI Programmierung Tips?

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2

[ - Beitrag schreiben - ]

10.01.2014, 10:23 Uhr

AGSzabo
Posts: 1663
Nutzer

Hi,

Für mein 'OX' GUI habe ich ein Paar Fragen wie man etwas machen kann. Vorweg die Sache mit der zentralen Verwaltung von Screens, datatype Images und Farben.

Soweit ich gekommen bin, braucht man für diese Images eines Screenzeiger, schon zum Remappen. Den habe ich aber erst, wenn die Fensterklasse ein Fenster auf macht. Ich möchte aber zB. die Buttonklasse schon im Vorraus ihr Skin-Image bereitstellen lassen, anstelle es erst zu laden, wenn das Fenster auf geht, also wenn eine Button-Instanz erzeugt wird, und von der Fensteröffnung erfährt.

Ähnlich soll es sich mit den Pens verhalten. Ich möchte zwar die Pens zentral von der Lib verwalten lassen (shinepen, darkpen, etc), aber wieder bekomme ich sie erst allokiert, wenn ein Fenster auf geht. Also die Pens in der Fensterklasse holen zu lassen ist nicht zentral. Außerdem geht das ja auch wieder nur auf Screen-Basis. Und ich möchte meine Fenster auch nicht nur auf den WBScreen ausbreiten.

Wie könnte ich vor gehen?

Andreas

--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

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

[ - Antworten - Zitieren - Direktlink - ]

10.01.2014, 13:10 Uhr

inq
Posts: 445
Nutzer

Zitat:
Original von AGSzabo:
Hi,

Für mein 'OX' GUI habe ich ein Paar Fragen wie man etwas machen kann. Vorweg die Sache mit der zentralen Verwaltung von Screens, datatype Images und Farben.

Soweit ich gekommen bin, braucht man für diese Images eines Screenzeiger, schon zum Remappen. Den habe ich aber erst, wenn die Fensterklasse ein Fenster auf macht. Ich möchte aber zB. die Buttonklasse schon im Vorraus ihr Skin-Image bereitstellen lassen, anstelle es erst zu laden, wenn das Fenster auf geht, also wenn eine Button-Instanz erzeugt wird, und von der Fensteröffnung erfährt.

Ähnlich soll es sich mit den Pens verhalten. Ich möchte zwar die Pens zentral von der Lib verwalten lassen (shinepen, darkpen, etc), aber wieder bekomme ich sie erst allokiert, wenn ein Fenster auf geht. Also die Pens in der Fensterklasse holen zu lassen ist nicht zentral. Außerdem geht das ja auch wieder nur auf Screen-Basis. Und ich möchte meine Fenster auch nicht nur auf den WBScreen ausbreiten.

Du bekommst die meisten Daten von GetScreenDrawInfo() mit dem Argument des Screens, den du benutzen willst (LockPubscreen()); außerdem hast du ja im Screen auch einen Rastport, bzw. in der screenstruct auch zumindest die Daten für Detailpen/blockpen.
--
Config:
A1200/30/50/FPU/SCSI/64MB, WinUAE/40/xx/xxMB, EUAE/40/25/xxMB, CDTV, CD32/SX32MK2/HD - AOS3.5

[ - Antworten - Zitieren - Direktlink - ]

10.01.2014, 13:24 Uhr

AGSzabo
Posts: 1663
Nutzer

@inq:

Danke. Es ist nicht rübergekommen was ich will. Ich habe eine eigene GUI-Engine (OOP) und die hat ihren eigenen Voreinsteller (Prefs). Darin kann man Images für den Skin auswählen und Farben einstellen. Das soll zentral gehen und für alle Apps die mein GUI benutzen global gültig sein und das tut es im Moment auch. Aber herbringen kann ich die Images und Pens für meine Farben erst, wenn eine Instanz des Fenster-Objektes erzeugt wird. Dieses kann dann zwar die Images und Pens holen, aber das ist nicht zentral. Oder wenn eine Klasse geöffnet wird, zB Button, kann die noch nicht ihr Skin-Image laden, weil dazu bei Datatypes ein Screen nötig ist. Das kann sie wiederum erst dann, wenn es auch schon ein Window gibt und dieses sich gerade öffnet. Der Button erfährt das im Moment über eine Spezielle 'window opening' message und lädt daraufhin sein Image. Das ist aber doof, da ich dann bei jedem Button schauen muss, ob schon ein Image geladen wurde ... hat jemand eine bessere Idee?

Andreas

--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

[ Dieser Beitrag wurde von AGSzabo am 10.01.2014 um 13:48 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

10.01.2014, 13:50 Uhr

thomas
Posts: 7718
Nutzer

@AGSzabo:

Zitat:
Aber herbringen kann ich die Images und Pens für meine Farben erst, wenn eine Instanz des Fenster-Objektes erzeugt wird. Dieses kann dann zwar die Images und Pens holen, aber das ist nicht zentral.

Zentraler als das geht es aber nicht. Z.B. wenn mehrere Programme mit deiner GUI-Engine laufen, dann sind die ja u.U. auf verschiedenen Screens. Dann kannst du sowieso nicht dieselben Pens und Images benutzen, sondern musst sie für jeden Screen separat vorhalten.

Außerdem musst du sowieso alle Screen-bezogenen Resourcen freigeben, wenn ein Programm ikonifiziert werden soll, denn dann soll sich der Screen ja schließen lassen. Und wenn er später wieder geöffnet wird, ist alles weg und du musst es neu allokieren.

Du müsstest so eine Art "GUI-Context"-Klasse machen, ähnlich wie die Application bei MUI, von der alle anderen Klassen abhängig sind. Pro Programm gibt es einen GUI-Context. Diesem Context ordnest du alle Screen-bezogenen Informationen zu. Wenn das erste Fenster geöffnet wird, allokiert das Context-Object die Pens und Images etc. Und wenn das letzte Fenster geschlossen wurde, gibst du alles wieder frei. Oder du behältst es bei bis das Programm sagt, dass es beendet oder ikonifiziert wird.

Über diesen Weg könntest du auch zentral (pro Programm) ikonifizieren, indem das Context-Object alle Fenster auf einmal schließt bzw. wiederherstellt.

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ Dieser Beitrag wurde von thomas am 10.01.2014 um 13:54 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

10.01.2014, 13:53 Uhr

AGSzabo
Posts: 1663
Nutzer

@thomas:

Danke, eine App-Klasse habe ich schon. Ich brings aber nicht raus wie genau ich das machen soll dass diese aktiv wird wenn das erste Fenster geöffnet wird (und was genau sie dann tun müsste). Und kann dann eine App nur 1 Screen benutzen?
--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

[ Dieser Beitrag wurde von AGSzabo am 10.01.2014 um 14:07 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

10.01.2014, 14:01 Uhr

AGSzabo
Posts: 1663
Nutzer

@thomas:

Und hmmm, wenn eine Klasse geladen wird, müsste die sich irgendwie bei der Kontext/App Klasse melden, um ihre individuellen screenabhängigen Ressourcen her zu bringen?

Mir schwebt gerade die Idee vor, dass bei jedem Öffnen einer Klasse eine Funktion der Klassse aufgerufen werden kann, die den Kontext als Parameter bekommt oder sich irgendwie holt ... weiter weiß ich aber noch nicht.

--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

[ Dieser Beitrag wurde von AGSzabo am 10.01.2014 um 14:14 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

10.01.2014, 14:14 Uhr

Holger
Posts: 8116
Nutzer

Da Du ja dabei bist, das Rad neu zu erfinden, musst Du doch nur gucken, wie die existierenden Räder so funktionieren. Datatypes Objekte kannst Du z.B. durchaus in einer Anwendung rumreichen, ohne einen Screen zu haben. Remapping findet erst statt, wenn das Objekt auch gezeichnet werden soll. Nicht der Button muss wissen, wann das Fenster geöffnet wird, sein Skin-Image muss wissen, wann es tatsächlich gezeichnet werden soll. Und das weiß es ja auch…

Genau dasselbe lässt sich auch für ein Pen-Objekt implementieren, das seine Screen-unabhängige Form kennt (z.B. RGB) und sich erst bei Bedarf die Screen-Pen-Nummer besorgt.

Du solltest allerdings jetzt die Entscheidung treffen, ob dieses UI mit shared data mehrere Screens zur selben Zeit unterstützen soll oder ob Du das von vornherein ausschließt.

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

[ - Antworten - Zitieren - Direktlink - ]

10.01.2014, 14:16 Uhr

Holger
Posts: 8116
Nutzer

Ach, da war ich wohl zu langsam, ist schon fast alles gesagt worden…

[ - Antworten - Zitieren - Direktlink - ]

10.01.2014, 14:17 Uhr

AGSzabo
Posts: 1663
Nutzer

@Holger:

Ja, dass man das Remappen auch erst beim Zeichnen tun kann, so wie auch das Holen des Pens (letzteres mache ich auch schon zu einem kleinen Teil), ist mir schon eingefallen. Aber würde soetwas das Ganze nicht unnötig verlangsamen?
--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

[ Dieser Beitrag wurde von AGSzabo am 10.01.2014 um 14:25 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

10.01.2014, 14:26 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von AGSzabo:
@Holger:
Ja, dass man das Remappen auch erst beim Zeichnen tun kann, so wie auch das Holen des Pens, ist mir schon eingefallen. Aber würde soetwas das Ganze nicht unnötig verlangsamen?

Beim ersten Zeichnen. Dein Problem ist somit ein reines Caching-Problem: Du willst das Ergebnis des Remappings/Pen-Allocation für weitere Verwendung speichern. Für die Funktionsweise einer solchen Speicherung ist es essentiell, ob diese gemeinsam genutzten Objekte im Kontext unterschiedlicher Screens verwendet werden sollen oder immer nur für denselben. Davon hängt die notwendige Struktur (deren Komplexität) ab.

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

[ - Antworten - Zitieren - Direktlink - ]

10.01.2014, 14:32 Uhr

AGSzabo
Posts: 1663
Nutzer

@Holger:

Gut, und wie erfährt das Image-Objekt dass sein Cache nimmer gültig ist?
--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

[ - Antworten - Zitieren - Direktlink - ]

10.01.2014, 14:37 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von AGSzabo:
@Holger:
Gut, und wie erfährt das Image-Objekt dass sein Cache nimmer gültig ist?

Kommt drauf an, welche Form des ungültig werdens Du meinst. Das AmigaOS unterstützt keine grundlegenden Änderungen von Screens, d.h., solange der Screen existiert, sind Remapping und Pens gültig. Falls Du auf Dateiänderungen abzielst, die sind afaik bei Datatypes auch nicht möglich, weil die Datei gelockt bleibt. Aber natürlich wäre es prinzipiell möglich, die Datei freizugeben und auf Änderungen zu überwachen.

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

[ - Antworten - Zitieren - Direktlink - ]

10.01.2014, 14:43 Uhr

AGSzabo
Posts: 1663
Nutzer

@Holger:

Also wenn der Screen mal geschlossen wird und das Programm aber nicht, zB durch eine "Switch to own screen" Funktion. Oder wenn der Benutzer in den Prefs ein anderes Image für den Skin des Buttons ein stellt. Im Moment geht das sogar live. Aber das Wie, das gefällt mir nicht, weil es nur das Fenster kann.
--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

[ - Antworten - Zitieren - Direktlink - ]

13.01.2014, 06:04 Uhr

Der_Wanderer
Posts: 1229
Nutzer

Ich habe das jetzt nicht alles durchgelesen, aber hier is mein Beitrag wie das in NTUI funktioniert.

Das was du "App" Objekt nennst heist in NTUI "engine". Eine Engine kann nur auf einem Screen gleichzeitig sein. Sie kann aber von Screen zu Screen "hüfpen".

Dafür gibt es die Funktionen "ntui_PopUp" und "ntui_Iconify", wobei PopUp sich auf einem Screen "anmeldet" (kann Workbench, Pubscreen oder eigener Screen sein). Dann können Fenster geöffnet werden.
Wenn man sich von dem Screen zurückziehen will ruft man "ntui_Iconfiy" auf. Das gibt alle Screen spezifischen Resourcen frei wie z.B. Pens.
(achja, also Pens werden pro Engine gespeichert, nicht global).

Ob man sich auf einem Screen befindet oder nicht ist 100% transparent für das Funktionieren der GUI. D.h. die App muss nicht wissen oder ständig abfragen ob die Fenster nun offen sind oder nicht.

Wenn die App auf mehreren Screens GLEICHZEITIG sein soll, dann macht man einfach mehrere Engines auf. Macht auch Sinn, denn die "Engines" sind voneinander völlig unabhängig, können also auch auf ganz verschiedenen Auflösungen und Farbtiefen laufen.

Pens werden bei ntui_PopUp "obtained", bzw. viele auch erst "on demand". Innerhalb ntui wird nicht mit AmigaOS Pens gearbeitet (da screen spezifisch und nach einem Screen wechsel nicht mehr gültig), sondern mit NTUI-Pens. Vor jedem Zeichenvorgang wird dann erst der AmigaOS Pen ermittelt mit Hilfe eines Table Lookups.

Bilder werden als True Color geladen. Dabei muss kein Screen offen sein, da True Color keine Paletten Informationen braucht.
AmigaOS Bitmaps lege ich gar nicht erst an. Bilder werden mit "WritePixelArray" auf den Screen gebracht. Das ist natürlich für True Color Screens am besten geeignet.
Auf Color Mapped Screens wird on-the-fly geremapped, d.h. es wird ein 8bit LUT PixelArray erstellt und mit WritePixelArray8 auf den Bildschirm gebracht. Da wir ja meistens kleine Bilder zeichnen und nicht ständig, ist das kein Performance Problem auf einigermassen modernen Systemen.

Letzter Tip: Verlasse dich so wenig wie möglich auf AmigaOS. AmigaOS API ist wie eine Pralinenschachtel, man weis nie was man kriegt... ;-)

Hoffe das hilft irgendwie weiter.
--
--
Author of
NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

[ - Antworten - Zitieren - Direktlink - ]

13.01.2014, 13:57 Uhr

AGSzabo
Posts: 1663
Nutzer

@Der_Wanderer:

Danke. Ja, das hilft. Lockst Du den Screen wenn die Engine erzeugt wird, oder wenn Du das erste Fenster darauf öffnest? Ich brauche screenspezifische Daten noch bevor ich das Fenster öffne, zB Font/Größe und Fenster-Rahmenmaße/Sizegadgetmaße.

Und wann soll ich die Pens für den Screen obtainen und die Images für den Screen laden? Beim ersten Fenster öffnen oder wenn mein Screen geöffnet wird? Letzteres ist schwieriger, wenn es der WB Screen sein soll. Woher kann mein System wissen ob jemand die Workbench oder einen Publicscreen schließen oder neu öffnen will wegen Prefschanges zB?

--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

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

[ Dieser Beitrag wurde von AGSzabo am 13.01.2014 um 14:13 Uhr geändert. ]

[ Dieser Beitrag wurde von AGSzabo am 13.01.2014 um 14:13 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.01.2014, 16:40 Uhr

Der_Wanderer
Posts: 1229
Nutzer

Zitat:
Original von AGSzabo:
@Der_Wanderer:

Danke. Ja, das hilft. Lockst Du den Screen wenn die Engine erzeugt wird, oder wenn Du das erste Fenster darauf öffnest? Ich brauche screenspezifische Daten noch bevor ich das Fenster öffne, zB Font/Größe und Fenster-Rahmenmaße/Sizegadgetmaße.

Und wann soll ich die Pens für den Screen obtainen und die Images für den Screen laden? Beim ersten Fenster öffnen oder wenn mein Screen geöffnet wird? Letzteres ist schwieriger, wenn es der WB Screen sein soll. Woher kann mein System wissen ob jemand die Workbench oder einen Publicscreen schließen oder neu öffnen will wegen Prefschanges zB?

Der Screen wird mit LockPubScreen() über den PubScreen Namen geholt. Falls der nicht exitiert, wird ein eigene Screen als WB Clone aufgemacht.
D.h der Screen ist immer gelocked.
Danach kannst du Pens obtainen, die Farbtiefe untersuchen, Fonts laden, Fensterramen untersuchen etc., bevor du irgendein Fenster öffnest.

Images laden ist davon unabhängig. Die werden entweder beim erstellen eines Objektes geladen, oder zu einem späteren Zeitpunkt verschoben, idealerweise erst beim Layouten oder Zeichnen. Z.B. wenn du ein ListView mit 1000 Einträgen hast, macht es keinen Sinn für alle Einträge ein Icon/Bildchen zu laden, wenn man nur 20-30 davon sieht. Laden sollte aber nicht vom Screen abhängen, wenn das Bild zwischen Apps geshared werden soll.

Alle Screenanpassungen passieren bei mir on-the-fly beim zeichnen. Könnte man auch cachen, müsste dann aber in der Engine, und nicht global gecached werden.

Wann ein Screen geschlossen werden soll kannst du (nur) über die screennotify.libray herausbekommen. So kann dein Programm auch auf Screenmode Prefs Änderungen reagieren.

--
--
Author of
NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

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

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

[ - Antworten - Zitieren - Direktlink - ]

13.01.2014, 17:00 Uhr

AGSzabo
Posts: 1663
Nutzer

@Der_Wanderer:

AH, immer gelockt ist offenbar auch für Dich von Vorteil. Icons würde ich dann zentral chachen, die sind ja unabhängig von screens. Außerdem kann eine Listenklasse ihre Icons für die Rows auch einmalig laden. Ich würde mich ferner auch nicht wundern, wenn ein gute Iconlibrary alle Icons basierend auf dem Dateipfad/name cachet.
--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

[ - Antworten - Zitieren - Direktlink - ]

13.01.2014, 17:24 Uhr

Der_Wanderer
Posts: 1229
Nutzer

Also ich halte den Screen nicht immer gelocked. nur zwischen ntui_PopUp und ntui_Iconfiy.
--
--
Author of
NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

[ - Antworten - Zitieren - Direktlink - ]

13.01.2014, 17:37 Uhr

AGSzabo
Posts: 1663
Nutzer

@Der_Wanderer:

Und wann besorgst Du Dir die Infos aus dem Screen? Erst wenn Dein Fenster auf geht? Und warum lockst Du dann überhaupt den Screen, wo doch offener Fenster die gleiche Aufgabe erfüllen?
--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

[ - Antworten - Zitieren - Direktlink - ]

13.01.2014, 22:00 Uhr

Der_Wanderer
Posts: 1229
Nutzer

Wie gesagt, der Screen muss ja gelocked werden zumindest bis du das erste Fenster offen hast. Des weiteren ist es kein Muss, in NTUI ein Fenster auch "physisch" offen zu haben. Im Gegensatz zu AmigaOS muss in NTUI ein Fenster nicht sichtbar sein, um zu existieren. Für den App Programmierer ist das völlig egal. Lediglich GUI updates sind eben nicht sichtbar.
--
--
Author of
NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

[ - Antworten - Zitieren - Direktlink - ]

13.01.2014, 22:08 Uhr

AGSzabo
Posts: 1663
Nutzer

@Der_Wanderer:

Ok, ganz konkret gefragt, zu welchem Zeitpunkt lockst Du den Screen: Bei der Erzeugung der Engine oder nur bevor ein Fenster geöffnet werden soll?

Bei OX ist es übrigens auch so, dass der App egal sein kann ob das Fenster offen ist. Es existiert trotzdem. Eine Klasse aber muss bei mir manchmal davon erfahren, ob das Fenster auf geht, um eben zB Pens zu holen. Und das will ich ja weg haben bzw besser.

--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

[ - Antworten - Zitieren - Direktlink - ]

13.01.2014, 23:30 Uhr

Der_Wanderer
Posts: 1229
Nutzer

Du kannst eine Engine (App) anlegen. Da wird noch nichts gelocked.

Du kannst auch Fenster anlegen und alles weitere.

Jetzt ruft du

ntui_PopUp{engine,"Workbench"}

auf, und das aller aller erste was passiert ist, der Screen wird gelocked. Sonst kann man ihn dir ja wieder wegnehmen. Das passiert mit "LockPupScreen()", eine AmigaOS funktion. Wenn die fehlschlägt, dann wird ein eigener Screen mit diesem Pubnamen geöffnet.

Also z.B.

ntui_PopUp{engine,"MyProggy"}

Würde einen neuen Screen aufmachen, falls es noch nicht läuft. Der Leere Sting wird als Workbench interpretiert.

Wie auch immer, jetzt (nach PopUp) sind wir auf dem Screen, egal ob nun Fenster offen sind oder nicht. Bisher sind noch keine offen.
Jetzt kann man Fenster öffnen und schliessen wie man lustig ist. Kann man auch vorher schon, nur werden die Fenster dann nicht sichbar, da wir ja nicht auf einem Screen "gepopped" sind.
ntui_PopUp kann auch sofort Fenster sichtbar machen, die eigentlich offen sind.

Wenn wir uns von dem Screen zurückziehen wollen, rufe ich "ntui_Iconfiy{engine}" auf, dann werden alle AmigaOS Fenster zugemacht und der PubScreen unlocked. Falls noch NTUI Fenster offen sind, bleiben die offen für NTUI, aber sind nicht sichtbar.
So kann ich mit einer App komplet transaprent arbeiten, egal ob sie nun auf einem Screen ist oder nicht.
So kann man auch von einem Screen auf den anderen "umziehen", ohne die Session zu ändern, d.h. ein PopUp stellt ja alle offenen Fenster wieder sichtbar her.

Nach Iconfiy werden keinerlei Resourcen mehr auf dem Screen festgehalten, damit er geschlossen werden kann.
Die Basis Pens, Fonts werden beim PopUp geholt, un bei Iconfiy freigegeben. Eingie Resourcen werden erst geholt, wenn sie tatsächlich gebraucht werden, z.B. Bilder in einem ListView, Pens in einem farbigen Widget die nicht Standard Pens sind etc.
So muss man nicht wirklich alles komplett im PopUp tun, was evtl. langsam werden könnte. Generell ist "lzay" besser, z.B. du hast ein grosses "teures" Bild auf einem Reiter. Solange man aber den Reiter nicht sichtbar klickt, brauchst du ja auch das Bild nicht. Also schiebst du das laden so spät wie möglich, und mit etwas Glück musst du es gar nicht laden weil der User den Reiter nicht klickt, oder z.B. den ListView nicht ganz durchscrollt etc.

Pens allociere ich übrigends in einem Array mit 512 Eintägen (8x8x8), sortiert nach RGB, jeweils 3 bit. So kannst du super schnell remappen. 3bit pro Farbe reicht für die allermeisten Sachen auf Colormapped screens dicke aus. Mehr bit sieht nicht wirklich besser aus (höchstens bei Graustufen Gradienten), verbraucht aber wiederum massiv Pens des Screens. Wichtiger ist mir persönlich dass True Color gut unterstützt wird.
--
--
Author of
NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

[ - Antworten - Zitieren - Direktlink - ]

14.01.2014, 19:15 Uhr

AGSzabo
Posts: 1663
Nutzer

@Der_Wanderer:

Ah yeah, jetzt hab ich eine Logik rausgefunden, die in/auf mein System passt. Bei mir heißt das nun: WAKE und SLEEP, weil ich unter Iconify einen Zustand verstehe, wo ein Icon übrig bleibt. Das soll nicht fest sein. Jedes Objekt erfährt von dem WAKE, das vom App-Objekt gesendet wird. Kommt das WAKE am Screen vorbei, lockt sich der und holt die Ressourcen und schreibt eine Kontext-Struktur. Kommt das WAKE dann am Window vorbei, wertet das Fenster den Kontext aus und ergänzt ihn, reicht das WAKE an alle untergordneten Objekte weiter, die sich dadurch an den Kontext anpassen. Dann erst geht das Fenster auf, wenn das Userprogramm es gewünscht hat. Während alles im WAKE Zustand ist, kann das Userprogramm Fenster beliebig auf und zu machen.

Danke, hast mir sehr geholfen. Jetzt brauche ich nur noch eine Logik wie ich den Screen wechsle ... bzw wie, wo, woher und wann ich ein SLEEP sende und an wen. Und was genau dann passieren soll. Hast Du da noch eine Idee?

a
--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

[ - Antworten - Zitieren - Direktlink - ]

14.01.2014, 23:57 Uhr

Der_Wanderer
Posts: 1229
Nutzer

Man könnte es auch WAKE und SLEEP nennen, aber die App schläft nicht notwenidgerweise, ist also auch nicht ganz korrekt.

Es ist sowas sie "Tauche auf" und "Tauche unter", oder eben "Gehe auf Sceen" oder "Verlasse Screen". "PopUp" finde ich ganz intuitiv von der Terminologie her. "Iconfiy" ist etwas irreführend, gebe ich zu, weil es nicht autoamtisch heisst, dass die App ein Icon auf der WB platziert, nur wenn man will.
Allerdings heist das unter Windows auch "Iconify", obwohl es nicht wirklich ein Icon gibt. Es bedeutet für mich nur "GUI zu", aber ansonsten weiterlaufen.

--
--
Author of
NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

[ Dieser Beitrag wurde von Der_Wanderer am 15.01.2014 um 04:54 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

15.01.2014, 09:26 Uhr

Holger
Posts: 8116
Nutzer

Auf dem Amiga sind Commodities die ältesten Programme, bei denen es eine solche Funktionalität gibt. Bei denen heißt es einfach „Show“ und „Hide“.

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

[ - Antworten - Zitieren - Direktlink - ]

16.01.2014, 23:05 Uhr

Der_Wanderer
Posts: 1229
Nutzer

Ja, aber show und hide trifft es nicht ganz.

Hier der App Lebenszyklus unter NTUI:

1. Create App (including all Windows and Widgets)

2. "PopUp" to a screen (screen is now locked)

3. Show Window (Opens AmigaOS Window) *)

...

4. Hide Window (Closes AmigaOS Window) *)

5. "Iconify" or leave Screen (screen is now unlocked)

6. Goto 2. or destroy App

Diese Liste gibt nur die Idee, aber ist nicht ganz korrekt *).

Man kann durchaus auch "Show Window" auf rufen ohne dass man auf einem Screen "GePopupped" ist. Passiert halt nur nichts. Bis man dann auf einen Screen geht, dann werden die Fenster automatisch geöffnet. (da sie ja aus NTUI sich offen sind).
Genauso muss man bei "Iconify" auch keine Fenster schliessen. Also wenn man z.B. lediglich von einem Screen auf einen anderen will, dann macht man "Iconfiy" und sofort "Popup" auf dem neuen Screen. Die Fenster werden dann dort geöffnet wie sie vorher waren.
Die Fenster waren aus NTUI sicht also nie geschlossen.

--
--
Author of
NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

[ - Antworten - Zitieren - Direktlink - ]

17.01.2014, 14:19 Uhr

AGSzabo
Posts: 1663
Nutzer

@Der_Wanderer:

Ich habe noch ein "DREAM" eingefügt, das heißt, es gibt neue Farb- und Skin- Einstellungen während die Fenster offen sind.

Neue Frage: Wie fängst Du Versuche ab, dass das GUI etwas tut was es im Moment nicht kann, zB das Layout, die Breite eines Textes zu berechnen mit TextLenght() wenn gerade garkein Rastport da ist?

Ich mache es so, dass ich für geschlossene Fenster den Rastport des gelockten Screens einsetze. Der hat den selben Font, weil ich mir den Font sowieso von da abschaue. Für Zustände außerhalb des Wachseins / Popups des GUI beabsichtige aber, mir einen Leer-Rasport anzulegen. Ist das gut? Woher soll ich da den richtigen Font nehmen, wenn nicht sowieso einen eigenen?

Wie vermeidest Du unnötige Abfragen ob wir gerade wach / popup sind bei den Layout-Berechnungen?
--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

[ - Antworten - Zitieren - Direktlink - ]

18.01.2014, 04:56 Uhr

Der_Wanderer
Posts: 1229
Nutzer

Das ist eigentlich recht einfach. Du musst die möglichen Einstiegspunkte zum Zeichnen reduzieren, idealerweise gibt es nur eine einzige Funktion, bei ntui ist das ntui_Redraw(*obj,*cliprect). Die Funktion testet ob das Objekt überhaupt innerhalb des Rechtecks sichtbar ist und kehrt sofort zurück wenn nicht, andernfalls wird gezeichnet.
Alle darunterliegenden Funktionen müssen nichts mehr testen, weil sie nur von ntui_Redraw() aufgerufen werden dürfen. D.h. pro Zeichenvorgang muss nur einmal getestet werden.

Darunter liegt die Funktion ntui_Draw(*obj,*cliprect,*rastport), die von ntui_Redraw() aufgerufen wird. Wie man sieht musst dafür bereits der RastPort bestimmt worden sein, und ist völlig unabhängig von Fenstern etc. Du kannst also auch ntui Objekte in deinen privaten RastPort zeichnen.

Der App Programmierer (und NTUI selbst) verwendet aber normalerweise keine der o.g. Funktionen direkt, sondern ruft "ntui_Damage(*obj,*rect)" auf. Damit teilt man der NTUI Engine mit, dass das Objekt in dem angegebenen Rechteck neu gezeichnet werden muss. Normalerweise passiert das Neuzeichnen dann erst, wenn der Focus an NTUI zurück gegeben wird, indem NTUI dann ntui_Redraw() aufruft. So wird nur einmal gezeichnet, auch wenn der App Programmierer an mehreren Stellen ntui_Damage() aufrufen muss.

Klassisches Beispiel ist der ListView, der nach jedem Eintrag der hinzugefügt wird ntui_Damage() aufruft. Ist nicht weiters schlimm, weil ntui_Damage() nichts zeichnet, sondern nur ein Flag setzt dass anzeigt dass das Objekt ein Neuzeichnen braucht. Ist also super leichtgewichtig. Wenn der ListView dann befüllt worden ist, und der Focus an NTUI zurückgeht, wird der ListView genau einmal neu gezeichnet und das Flag wieder gelöscht.

Oder z.B. bei SimpleRefresh Fenstern, wenn man Solid Window Moving hat, dann kann es sein dass sehr viele IDCMP_REFRESH Messages kommen, schneller als man den Inhalt neuzeichnen kann. Würde ich brute Force neuzeichnen, dann würden sich die Messages aufstauen und alles träge werden, bzw. das Fenster eine weile lang sich ständig neu zeichnen. Es gibt viele Apps bei AmigaOS wo man das Verhalten beobachten kann.
Bei NTUI allerdings wird beim Eingang der IDCMP_REFRESH message erstmal nichts gezeichnet, sondern nur das Flag gesetzt. Wenn keine Messages mehr anliegen, wird EINMAL neu gezeichnet. Wenn das neu zeichnen lange dauert, werden danach wieder ALLE anstehenden Messages augesammelt, und wieder nur EINMAL neugezeichnet.

--
--
Author of
NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

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

[ - Antworten - Zitieren - Direktlink - ]

18.01.2014, 05:11 Uhr

AGSzabo
Posts: 1663
Nutzer

@Der_Wanderer:

Aha. So in etwa habe ich das auch. Rekursiv und ein Einstiegspunkt und so. Bei mir muss der App-Programmierer nichtmal einen Refresh für ein Objekt anfordern. Da macht entweder die Klasse oder ein Bit im Attribut-Tag zeigt OX an dass nach dem Ändern dieses Attributes das Objekt gezeichnet werden soll. Wenn ja, dann geht OX wieder durch den ganzen Baum, beachtet die Cliprects und so, und ruft nur die DRAW Methode eines Objekts auf, wenn es Refresh wollte oder unterhalb eines refreshenden Objekts liegt.

Meine Frage war vielmehr, wie berechne ich das Layout eines Objekts, ganz konkret die Pixelbreite eines Textes, wenn ich weder den Window-, noch den Screenrastport (Screenfont) habe?
--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

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

[ - Antworten - Zitieren - Direktlink - ]

18.01.2014, 06:26 Uhr

Der_Wanderer
Posts: 1229
Nutzer

Wenn du weder ein Window noch einen Screen hast, warum möchtest du das Layout berechnen?

Es macht nur Sinn das Layout zu berechnen wenn du vor hast das Fenster zu öffnen, und in dem Moment hast du einen Screen. Remember, bevor du ein Fenster öffnen darfst musst du auf einen Screen "uppoppen". Und dann kannst du dir Fonts, Pens etc, holen.

--
--
Author of
NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

[ Dieser Beitrag wurde von Der_Wanderer am 18.01.2014 um 06:34 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

-1- 2

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Selfmade GUI Programmierung Tips?

[ - Suche - Neue Beiträge - Registrieren - Login - ]