gui-task - amiga-news.de Forum

amiga-news.de Forum > Programmierung > gui-task

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

-1-

[ - Beitrag schreiben - ]

01.11.2009, 07:17 Uhr

AGSzabo
Posts: 1663
Nutzer

hellau. ich habe es geschafft dass der file scanner in einen eigenen task läuft so dass das gui clickbar bleibt. aber wie programmiert man generell das gui so dass es nie stecken bleibt wie zb intuition. ist eine frage des prinzips, die mir vielleicht de wanderer beantworten kann. mfg
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

01.11.2009, 11:57 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von AGSzabo:
aber wie programmiert man generell das gui so dass es nie stecken bleibt wie zb intuition.

Was meinst Du mit "generell"? Bzw. "zb intuition"? Willst Du wissen, wie man ein Betriebssystem programmiert, oder wie man eine Anwendung programmiert?
intuition verschickt bekanntermaßen Messages und wartet nicht auf deren Antwort und bleibt somit auch nicht stecken.

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

[ - Antworten - Zitieren - Direktlink - ]

01.11.2009, 12:10 Uhr

AGSzabo
Posts: 1663
Nutzer

@Holger:

ich denke mal "gui-toolkit" geht in die richtung betriebssystem. der wanderer hat sein NTUI asynchron gemacht, das heisst die knöpfe bleiben immer clickbar auch wenn die applikation die das toolkit benutzt beschäftigt oder gar abgestürzt ist. meine frage ist, wie hat er das gemacht! mfg
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

01.11.2009, 12:29 Uhr

Holger
Posts: 8116
Nutzer

@AGSzabo:
Ja, Toolkit geht in die Richtung Betriebssystem.
Es gibt dabei nur zwei Möglichkeiten, ereignisgesteuerte Handler oder einen eigenen Task benutzen. Ok, drei, denn man kann auch beides kombinieren.

In beiden Fällen kommuniziert das Toolkit mit den Anwendungen über Nachrichten, die eben im Eingang liegen bleiben, wenn die Anwendung beschäftigt ist.

Dass ein Button anklickbar bleibt, auch wenn die Anwendung beschäftigt ist, liegt schlicht darin, dass nicht die Anwendung den Button zeichnet, sondern das Toolkit. So machte es intuition schon zu AOS1.x Zeiten, so machen es auch BOOPSI und ReAction und vermutlich auch NTUI. Die Anwendung erhält lediglich eine Nachricht darüber, dass der Button ausgelöst wurde, zeichnen muss sie nichts mehr.

Allerdings hat das auch seine Nachteile. So kann man nämlich u.U. auch Buttons auswählen, die im aktuellen Kontext gar nicht wählbar sein sollen, weil die beschäftigte Anwendung es noch nicht geschafft hat, diese abzuschalten.

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

[ - Antworten - Zitieren - Direktlink - ]

01.11.2009, 12:36 Uhr

AGSzabo
Posts: 1663
Nutzer

@Holger:

> Allerdings hat das auch seine Nachteile. So kann man nämlich u.U. auch Buttons auswählen, die im aktuellen Kontext gar nicht wählbar sein sollen, weil die beschäftigte Anwendung es noch nicht geschafft hat, diese abzuschalten.

ja, das habe ich mir auch schon gedacht. evtl helfen signale?

also im moment mache ich es so dass alle programmfunktionen über hooks aufgerufen werden. wenn zb bei einem button eine datei geladen werden soll, muss das der button-click-hook-machen. ich weis nicht ob diese variante zu dem message-system kompatibel ist oder ob man dazu eine große select case konstruktion braucht die alle IDs durchgeht! mfg
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

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

[ - Antworten - Zitieren - Direktlink - ]

01.11.2009, 13:20 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von AGSzabo:
ja, das habe ich mir auch schon gedacht. evtl helfen signale?

Nein. Asynchron bleibt asynchron.
Wenn man nicht innerhalb der Anwendung zeichnet, wie z.B. bei MUI, besteht immer die Möglichkeit, dass das Toolkit ein optisches Feedback gibt, während die Anwendung noch nicht dazu gekommen ist, genau das zu verbieten.

Zitat:
also im moment mache ich es so dass alle programmfunktionen über hooks aufgerufen werden. wenn zb bei einem button eine datei geladen werden soll, muss das der button-click-hook-machen.

Die Frage ist, wer den Hook aufruft. Die Gadgets-Hooks, die von intuition direkt aufgerufen werden, können direkt andere Gadgets sperren, noch bevor weitere Eingaben produziert werden. Dafür dürfen sie aber nichts anderes tun, vor allem nichts, was länger dauert, und auf keinen Fall Dateizugriffe.

Natürlich kann man auch eigene Hooks implementieren, die im Kontext der eigenen Anwendung aufgerufen werden. Das kann so funktionieren:

Anwendung erhält Message von Intuition, das Button gedrückt wird

Anwendung ermittelt Button, Anwendung liest eigenen Hook (z.B. in UserData) aus

Anwendung ruft Hook auf

Dieser Hook kann dann auch Dateizugriffe durchführen. Währenddessen reagiert die Anwendung aber logischerweise nicht auf andere Aktionen. Deshalb sollte man auch vorher das GUI in einen entsprechenden Status setzen (Busy-Pointer, Buttons sperren).

Wenn man dagegen sehr lange Operationen hat, wie z.B. Festplatte durchsuchen, und einen Stop-Button anbieten will, muss man entweder seinen Operation so schreiben, dass sie regelmäßig auf neue Nachrichten prüft, oder zwei Tasks benutzen.

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

[ - Antworten - Zitieren - Direktlink - ]

01.11.2009, 13:54 Uhr

AGSzabo
Posts: 1663
Nutzer

@Holger:

ich seh schon. asynchrones gui lohnt sich nicht wirklich. aber zum scannen der dateien benutze ich eh einen eiegenen task und so auch zu anderen operationen die dauern.
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

01.11.2009, 16:16 Uhr

cgutjahr
Posts: 2783
[Administrator]

Zitat:
ich seh schon. asynchrones gui lohnt sich nicht wirklich

Das ist m.E. keine Frage von "lohnen", sondern eine von Konsistenz. Natürlich sollte sich deine GUI so verhalten wie die anderen GUIs auf dem Amiga auch. Auf OS4 (asynchron), MorphOS oder AROS (jeweils MUI) ist die Antwort auf diese Frage klar, unter OS3 musst du halt abschätzen ob es mehr MUI oder mehr Reaction/Gadtools/GT-Erweiterung/BGUI/Triton/Custom-GUIs gibt.
--
Delirium BBS

[ - Antworten - Zitieren - Direktlink - ]

01.11.2009, 16:23 Uhr

AGSzabo
Posts: 1663
Nutzer

@cgutjahr:

hm, ich verstehe nicht was du mir damit sagen willst. konsistenz ja, aber dann in satz zwei mit dem abschätzen? openxui soll in keiner weise unbedingt so sein wie ein anderes gui. es bedient blos eine kleine assemblerniesche und besticht da durch seine einfachheit.

--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

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

[ - Antworten - Zitieren - Direktlink - ]

01.11.2009, 16:46 Uhr

cgutjahr
Posts: 2783
[Administrator]

Zitat:
Original von AGSzabo:
hm, ich verstehe nicht was du mir damit sagen willst. konsistenz ja, aber dann in satz zwei mit dem abschätzen?

Wenn du ein GUI-Toolkit schreibst, das du irgendwann mal auf Anwender loslassen willst, sollte sich dieses Toolkit genauso bedienen und "anfühlen" wie die bereits existierenden Toolkits.

Bei der Frage "mache ich eine asynchrone GUI" musst du dir also ansehen ob die bereits existierenden GUI-Toolkits asynchron arbeiten oder nicht. Unter OS3 gibt es leider einen wilden Mix verschiedener Toolkits, weswegen diese Frage dort nicht so einfach zu beantworten ist (deswegen "abschätzen").

Aber das ist die Frage die du dir stellen musst, nicht ob es "sich lohnt".

--
Delirium BBS

[ - Antworten - Zitieren - Direktlink - ]

01.11.2009, 17:26 Uhr

thomas
Posts: 7718
Nutzer

Alle oben genannten GUI-Toolkits basieren irgendwie auf Intuition, deshalb stellt sich die Frage eigentlich gar nicht. Intuition sorgt automatisch dafür, daß GUI-Elemente bedient werden können, auch wenn die Anwendung nicht reagiert.

Nur xui ist komplett mit der Hand am Arm programmiert. Da muß man sich halt selbst etwas ausdenken.

Die einfachste Möglichkeit, es jetzt noch nachträglich irgendwie in Intuition einzubinden, wäre wohl, die komplette GUI in ein großes BOOPSI-Gadget zu verpacken. Dann liefen alle visuellen Änderungen und Eingaben unter der Task des input.device und somit asynchron vom Hauptprogramm.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

01.11.2009, 17:44 Uhr

AGSzabo
Posts: 1663
Nutzer

@thomas:

> mit der Hand am Arm programmiert

der handknochen hängt am armknochen?

>ie komplette GUI in ein großes BOOPSI-Gadget zu verpacken

ehhh, diese idee ist .... naja ... geht das wirklich?

--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

01.11.2009, 22:50 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von thomas:
Alle oben genannten GUI-Toolkits basieren irgendwie auf Intuition, deshalb stellt sich die Frage eigentlich gar nicht. Intuition sorgt automatisch dafür, daß GUI-Elemente bedient werden können, auch wenn die Anwendung nicht reagiert.

Das stimmt nur halb. MUI ist z.B. nicht bedienbar, wenn die Anwendung nicht reagiert. Gadtools ist halb und halb, es funktioniert asynchron bei Features, die es schon bei 1.3 gab (z.B. Buttons), aber nicht bei komplexen Gadgets wie ListView, die zumindest unter AOS2.0 nicht mit BOOPSI implementiert sind.

Zitat:
Die einfachste Möglichkeit, es jetzt noch nachträglich irgendwie in Intuition einzubinden, wäre wohl, die komplette GUI in ein großes BOOPSI-Gadget zu verpacken. Dann liefen alle visuellen Änderungen und Eingaben unter der Task des input.device und somit asynchron vom Hauptprogramm.

Oder man installiert einen Handler im input.device, bzw. commodities.library. (So macht es Intuition ja auch)

--

[ Dieser Beitrag wurde von Holger am 01.11.2009 um 22:54 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

02.11.2009, 08:46 Uhr

AGSzabo
Posts: 1663
Nutzer

vielleicht könnte man auch jeden hook code generell als eigenen task ausführen...?
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

02.11.2009, 10:29 Uhr

thomas
Posts: 7718
Nutzer

Zitat:
geht das wirklich?

Natürlich, sonst hätte ich es nicht vorgeschlagen.

Zitat:
Oder man installiert einen Handler im input.device, bzw. commodities.library. (So macht es Intuition ja auch)

Das Problem bei dem Ansatz ist, daß man *jedes* Eingabeereignis mitbekommt und man selbst entscheiden muß, ob das für das eigene Fenster oder für ein andere Programm gedacht ist. Gerade wenn das eigene Fenster von mehreren anderen überdeckt ist, ist es relativ schwierig, herauszufinden, ob der Mauszeiger über dem sichtbaren Ausschnitt ist oder nicht.

Der Ansatz mit dem BOOPSI-Gadget stellt sicher, daß man Input nur dann bekommt, wenn das eigene Fenster (und das Gadget) aktiv ist.

Zitat:
vielleicht könnte man auch jeden hook code generell als eigenen task ausführen...?

Das ist dir überlassen.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

02.11.2009, 12:58 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von thomas:
Das Problem bei dem Ansatz ist, daß man *jedes* Eingabeereignis mitbekommt und man selbst entscheiden muß, ob das für das eigene Fenster oder für ein andere Programm gedacht ist.

Sollte es dafür nicht reichen, seinem Handler eine Priorität kleiner als -60 zu geben? Dann müsste, da intuition die Ereignisse schon ausgewertet hat, das aktive Fenster in der intuition.library korrekt sein.

Natürlich kann der Ansatz eines fensterfüllenden Gadgets einfacher zu programmieren sein, je nach dem, was man sonst noch machen will, wobei ich den BOOPSI-Overhead nicht mitnehmen würde, wenn man BOOPSI ansonsten nicht benutzen will. Dafür reicht ja ein Gadget-Hook.

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

[ - Antworten - Zitieren - Direktlink - ]

02.11.2009, 16:16 Uhr

thomas
Posts: 7718
Nutzer

Zitat:
Original von Holger:
Sollte es dafür nicht reichen, seinem Handler eine Priorität kleiner als -60 zu geben? Dann müsste, da intuition die Ereignisse schon ausgewertet hat, das aktive Fenster in der intuition.library korrekt sein.

Intuition filtert alles raus, was es gebrauchen kann, d.h. wenn dein Handler nach dem von Intuition kommt, ist kaum noch etwas übrig, vor allem keine Benutzereingaben mehr.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > gui-task

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