Re: Lua API for GUI
Posted: 20 May 2021, 20:33
That's what position_real is for, to get 30% width and 100% height you'd do this.
Code: Select all
position_real="0 0 0.3 1"
That's what position_real is for, to get 30% width and 100% height you'd do this.
Code: Select all
position_real="0 0 0.3 1"
I see, it's just yes another MyGUI feature which has a nonsensical name and isn't documentedwazabear wrote: ↑20 May 2021, 20:33That's what position_real is for, to get 30% width and 100% height you'd do this.
Code: Select all
position_real="0 0 0.3 1"
Forgot to write an update on this. I've tried real position, and it's not great. The main issue is that it gets converted into pixels immediately. So if the parent size changes later, the children sizes stay the same as they were.wazabear wrote: ↑20 May 2021, 20:33That's what position_real is for, to get 30% width and 100% height you'd do this.
Code: Select all
position_real="0 0 0.3 1"
It would be nice to have him explain what the plan currently is.AnyOldName3 wrote: ↑02 Jul 2021, 00:10 I brought that up when we were discussing the Lua threading model, and ptmikheev responded in some way or other, so he might have a plan already.
It is fine to call some UI callbacks from the main thread if it is really needed.urm wrote: ↑01 Jul 2021, 12:36 So we either need some approach for running some Lua code in the main thread, simultaneously with MyGUI, or restrict creating widgets to C++. I'm leaning towards the latter, I think we can provide all the necessary widgets ourselves. However that is assuming this is the only issue caused by multiple one-frame delays, and assuming we are fine with a one-frame delay for all of the Lua UI actions.
Yeah, I'm leaning to that approach in any caseptmikheev wrote: ↑02 Jul 2021, 20:49It is fine to call some UI callbacks from the main thread if it is really needed.urm wrote: ↑01 Jul 2021, 12:36 So we either need some approach for running some Lua code in the main thread, simultaneously with MyGUI, or restrict creating widgets to C++. I'm leaning towards the latter, I think we can provide all the necessary widgets ourselves. However that is assuming this is the only issue caused by multiple one-frame delays, and assuming we are fine with a one-frame delay for all of the Lua UI actions.
However I think we shouldn't add too lot of functionality in one merge request.
Would it be reasonable to start from C++-only widgets and keep it mind how to add custom widgets if/when it becomes essential?
urm wrote: ↑02 Jul 2021, 08:26Forgot to write an update on this. I've tried real position, and it's not great. The main issue is that it gets converted into pixels immediately. So if the parent size changes later, the children sizes stay the same as they were.wazabear wrote: ↑20 May 2021, 20:33That's what position_real is for, to get 30% width and 100% height you'd do this.
Code: Select all
position_real="0 0 0.3 1"
I've implemented a different relative positioning system https://gitlab.com/uramer/openmw/-/comm ... c00e45704e