Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Christian H. Kuhn" Newsgroups: de.comp.lang.java Subject: =?UTF-8?Q?Re:_GUI-Update_=c3=bcber_Swing-EDT?= Date: Sun, 17 Jul 2016 16:02:48 +0200 Lines: 31 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net 5yO6lUoOcveMMzw2UGr8owLgYBUep6hOKZBs1eauk32M9H6Ks= Cancel-Lock: sha1:l8wRE6G6oLEQJwn6NAv57toAPO0= User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: Xref: csiph.com de.comp.lang.java:13009 Am 16.07.2016 um 23:05 schrieb Christian „Ingrid“ Kuhn: > v0.8.6 Und voll über’s Ziel hinausgeschossen. In der Swing-GUI liegen echte Clicks (und inzwischen auch doClick() aus den Tests) auf dem EDT. Die entsprechenden Methoden von QChessClock werden nie niemals nicht von woanders direkt aufgerufen und liegen ebenfalls auf dem EDT. Diese Methoden rufen notifyXY auf, was wieder updateXY der GUI aufruft. Immer noch alles auf dem EDT. Damit muss SwingUtilities.invoke...() in allen diesen Funktionen NICHT benutzt werden. (G)UI ohne Swing und Tests, die QChessClockInterface implementieren, müssen da halt aufpassen. Fehlschlagende Tests haben mir jedenfalls gut gezeigt, wo noch ein notify oder update in den Thread hineinmuss. Damit werfen diese ganzen Methoden auch nicht mehr die Exceptions von invoke...(), und das uncaughtExceptions-Gehampel um actionPerformed() entfällt. Etwas Anderes ist es mit dem notifyObservers(), das getaktet ausgelöst wird. Das läuft definitiv auf einem anderen Thread. Hier wird aber nur Zeit und Blättchenfall kontrolliert. Da gibt es dann eine Methodendoppelung. QChessClockObserver müssen dann für Zeit und Flags eine weitere Update-Methode anbieten, in der sie sich z.B. in Swing darum kümmern, dass die Zugriffe auf den GUi-Status auf den EDT gelegt wird. Jetzt sortiere ich noch ein wenig. Das wird v0.8.7 lg QNo