Hilfe, ich will ein Fenster zentrieren!

Wieder eines dieser schrecklichen Probleme, an die man sich zeitraubend Schrittchen für Schrittchen herantasten muss Warum nur?!

Ich möchte doch NUR ein kleines Alert-Fenster aufpoppen lassen, und zwar exakt (!!!) in der Mitte des Bildschirms.

Theoretisch habe ich die Lösung gefunden:

local screen = api.gui.util.getById("mainView")
--local parent = screen:getParent()  -- @ eis_os: Auch das habe ich probiert, und die komplette tpfui._getRoot-Funktion, alles vergeblich :-(
--while(parent) do
--	screen = parent
--	parent = screen:getParent()
--end
local screenSize = screen:getContentRect()
state.window = api.gui.comp.Window.new(_("alertboxTitle"),api.gui.comp.TextView.new(_("alertboxText")))
state.window:addHideOnCloseHandler()
state.window:setIcon(icon or "ui/icons/windows/attention.tga")
state.window:setId(winId)
local newSize = api.gui.util.Size.new(500,150)
state.window:setSize(newSize)
print ("screen size", screenSize.w, screenSize.h)
local x = math.floor((screenSize.w - 500) * .5 +.5)
local y = math.floor((screenSize.h - 150) * .5 +.5)
state.window:setPosition(x, y)
game.gui.playSoundEffect("attention")

Aber nur theoretisch ...

Das Fenster klappt auch. Aber nur in der Auflösung 1920 x 1080 liegt es in der Mitte. Wähle ich z.B. meine Standardgröße 2560 x 1440, liegt es zu weit rechts. Wenn man die Gegenprobe macht und das Fenster einmal am rechten Rand ausrichtet (also screenSize.w - 500), liegt es nicht am rechten Rand, sondern überschreitet ihn. Daraus ist zu folgern, dass die GUI-Grundfläche kleiner sein muss als die Bildschirmauflösung, aber gleichzeitig über sie hinausläuft. Aber eben nicht in allen Auflösungen. Was ist da los - und wie bekomme ich den richtigen Wert? Oder ist das einfach nur ein böser Bug? Wobei es in den hauseigenen UG-Routinen ja zu funktionieren scheint, denn die Ingame-Fenster (z.B. die Warnmeldung oben im Spielfenster) werden exakt zentriert.

Und nein, es hat nichts mit Vulcan und OpenGL zu tun, hab ich auch schon getestet.

Ääääh ... hab ich doch gemacht, hab nur statt mainView screen als Variable benutzt. Dürfte eigentlich nichts ausmachen. Hmm, dann weiß ich auch nicht mehr weiter., vielleicht haben die da ja tatsächlich was geändert. Oder mein Monitor tickt falsch. Du (oder war es jemand anders?) hattest auch mal was mit Faktor 0.9 drin. Ich hatte schon den Verdacht, das wär's, aber das würde dann ja wieder mit den Fällen kollidieren, wo es exakt stimmt.

Die Bildschirmauflösung wird bei mir auch immer korrekt ermittelt. Aber was ist denn der mysteriöse UI Skalierungsfaktor?

Ja, danke, das ist doch schon mal was. Da muss einer aber wirklich erst drauf kommen! Wozu soll das gut sein? Wenn man auf mehreren Monitoren spielt? Ahja, jetzt ist's klar - wegen der Schriftgröße. Die sich allerdings weniger ändert als die Größe der Fenster, wenn man diese mit calcMinimumSize() automatisch an den Text anzupassen versucht. Auch so eine Merkwürdigkeit.

Daraus ergibt sich allerdings eine weitere Frage: Kann man den Skalierungswert irgendwo abgreifen?

Ich glaube inzwischen eine Lösung gefunden zu haben. Sieht zumindest so aus, dass es auch ohne Kenntnis des Skalierungsfaktors funktioniert:

local function guiUpdate()
    if state.openWindow then -- trigger message
        local winId = "wkjsAlertbox"
        if not api.gui.util.getById(winId) then -- checks if window already exists to inhibit a new window every call :-)
            state.window = api.gui.comp.Window.new(_("alertboxTitle"),api.gui.comp.TextView.new(_("alertboxText")))
            state.window:addHideOnCloseHandler()
            state.window:setIcon("ui/icons/windows/attention.tga")
            state.window:setId(winId)
            local parent = state.window:getParent() -- not the screen size but the usable part of the game window
            uiSize = parent:getContentRect()
            local newSize = api.gui.util.Size.new(500, 150) -- regular size without UI scaling
            state.window:setSize(newSize)
            state.window:setVisible(false, false) -- can we really notice the window opening at the wrong place?
            state.window:setPosition(0, 0) -- opens the window, which must be opened extemporary to get the (scaled) size :-(
            local winSize = state.window:getContentRect() -- now we can get the scaled size
            local x = math.floor((uiSize.w - winSize.w) * .5 +.5)
            local y = math.floor((uiSize.h - winSize.h) * .5 +.5)
            state.window:setPosition(x, y) -- and now we can set the final position :-)
            state.window:setVisible(true, false)
            game.gui.playSoundEffect("attention") -- for warnings
            state.openWindow = false
        end
    end
end

An dieser Stelle gleich die Warnung, dass das alles noch experimentell und ohne Gewähr ist - für alle, die den Code übernehmen möchten.

Erstaunlich, welcher Aufwand getrieben werden muss, um ein simples Fenster zu öffnen. Erstaunlich auch, dass man wohl erst die tatsächlichen Maße des Fensters zurückgegeben bekommt, nachdem das Fenster bereits geöffnet wird. Aber immerhin hätten wir ein Workaround - womöglich schon den Königsweg. Vielleicht doch mal UG fragen ...

Eine weitere Überlegung wäre noch, das Fenster schon in guiInit anzulegen und später an entsprechender Stelle aufzupoppen. Dort wird es witzigerweise unabhängig von den in setPosition angegebenen Werten in den unsichtbaren negativen Koordinatenbereich geschoben, allerdings so, dass ein Teil noch in den sichtbaren GUI-Bereich hineinragt.

Ob setVisible überhaupt notwendig ist, ist mir nicht ganz klar. Für genau einen Frame müsste das Fenster an der falschen Stelle sichtbar sein. Alternativ könnte man es auch außerhalb des Bildschirms platzieren, in der Hoffnung, dass es dort nie jemand zu sehen bekommt. Und da scheint mir setVisible die sicherere Lösung zu sein.

Ganz sicher bin ich mir noch nicht, ob bei der obigen Anordnung irgendwelche Aktionen beim Framewechsel "verschluckt" werden könnten.

Ein interessanter Effekt dabei ist, dass state.openWindow schon wieder gelöscht ist, bevor das Fenster aufgebaut ist, allerdings gleichzeitig noch als Zombie-Variable irgendwo zwischen load und save herumschwirrt. Multithreading ist echt schwer zu verstehen. Auf jeden Fall sollte man mit state.openWindow keine Strings aus anderen Threads an das Fenster übergeben.

Zitat

macht eig keinen Sinn, da ja state bei load wieder neugeladen wird.

Aber wie soll ich sonst das Fenster starten? Von der Engine zum GUI gibt es doch keinen anderen Weg als über state-Variablen? Oder irre ich mich da?

Zitat

Wenn du von dort aus den state ändern willst, musst du ein ScriptEvent schicken und die Änderung im Script Thread machen.

Bingo! Ist zwar etwas kompliziert, aber andererseits auch einleuchtend.

Zitat

Aber prüfen ob das Fenster schon geöffnet wurde, kann man auch mit ner lokalen Variable machen

Im Grunde finden ja mehrere Dinge statt. Zunächst schicke ich einen Befehl von der Engine an GUI, um das Fenster zu öffnen. Da dieser Befehl mehrmals reinkommt (mal testen, wie es mit obiger Lösung funktioniert), muss ich prüfen, ob das Fenster schon offen ist. Das mache ich über die Id (Grüße an Enzojz ). Ich hatte da auch schon mit einer Variable außerhalb state gearbeitet, wollte aber dann doch irgendwelche mutmaßlichen Hacks vermeiden. Der dritte Vorgang ist die Übergabe von Strings an das Alert-Fenster, die in meinem hier veröffentlichen Code noch nicht implementiert ist. Ich hatte hierfür einen String in windowOpen reingepackt, aber - wie gesagt - er wurde schon wieder gelöscht, bevor er überhaupt an das Fenster übergeben wurde. Deshalb übergebe ich jetzt einen separaten String, natürlich auch in state, der hinterher nicht gelöscht wird und vermutlich bis in alle Ewigkeit im gameScript wie ein Pingpong-Ball hin- und herspringt. Aber vielleicht krieg ich das ja jetzt mit der von dir vorgeschlagenen Methode optimiert und kann womöglich noch eine der drei Variablen sparen.