windowclass placement size merge in an extension and dependant on a theme extensions.

[Trenloe]

So, override the size to be dynamic and then you should be able to set the window size via code?

See <dynamic /> within sizelimits: https://fantasygroundsunity.atlassia...44/windowclass

[bratch9]

There is a post from MW in Discord:

And we are still back to the point at the start of the thread, I know setSize is not and never was a solution. Only you are still going on about it. Its possible SW 'could' make the setSize change a fixed size window, but the reality is they will not. It might also have a 'cache' issue in the layout system, they could put non-resize window layouts in a different pool of memory etc..

The issue is no options are available to clean resolve this issue, and other ruleset/extension to extension conflicts. Its not just about the setSize.

As covered,

1. I could make it re-sizable, then I dont need setSize anyway as the user would just resize the window. BUT this could cause a graphic issue if the theme does not have the resize graphic selected. It could end up showing nothing/default theme graphics. In which case I just end up with a message for 'in this theme the resize graphic is wrong can you fix it' and we are back to my extension needing an 'exception' something based on another extension been loaded. And like the static size window, its not possible for me to <icon /> to make that for a 'specific extension'. So 'fixing' the theme again would then break all the other themes/default etc.. Its not a workable solution.

2. I could make the window massive by default, but this just looks like a 'poor' solution and an mess. Because I can not set the height depending on a specific extension to tidy it out.

All the solutions end up with a mess because FG has no control for extension->extension interactions issues.

This one is a basic situation of the ruleset height been adjusted by an extension (theme), and then also by my extension so now we need 2 different height values in my extension based on which extensions are loaded due to this been a static size window. ( and no lua solution, only xml tags to solve it with. )

As also stated, I have extensions that have to merge with other extensions that have custom windows. If this other extension is not loaded, then my extension causes merge warning as it has nothing to 'merge="join"' with. Because its something in my extension that depends on a different extension. Again this been an xml tag issue, and no lua solution.

If we could <script extension="extension name" /> then extensions could add specific extension->extension related code in a clean way, instead of having to search the loaded extension list during onInit etc..

If we could <size extension="theme name" height="380" /> then I could have a default size and then an extension specific size override. Creating a clean solution.

Or if we could do <size height="+40" /> this could resolve this specific issue, but then not the interaction on my extension with a different extension as a custom window to merge with etc..

All reasonable solution for a clean solution require SW to adjust the base system in some way.

Or I'm missing something, which it does not seem like I am, as the only solution is the non workable lua setSize. Which I already know about.

-pete

[bratch9]

So, override the size to be dynamic and then you should be able to set the window size via code?

See <dynamic /> within sizelimits: https://fantasygroundsunity.atlassia...44/windowclass

Using dynamic can result in,

dynamic.JPG

Because to result this, I'd need to have 2 different 'minimum' sizes depending on which loaded extensions.

And guess what, no LUA code to allow me to dynamically set the minimum size...

So again, its solves one issue, and creates other issues.

We need a 'clean' solution for extension->extension interaction cases that are trapped in the XML tag world. ( Since loads of LUA api interfaces for these things are also missing. )

-pete

[bratch9]

Just doing an update, the latest changes in FG have now made this window and some others resize by default. Which is good, in that if a 'theme' is missing the resize graphics it now becomes a theme issue due to the resize been part of the base ruleset and not 'added' with my extension.

But it still has issues, the minsize is only set in the ruleset, so with the theme loaded you can now show a poor clipped window,

theme.JPG


I'm sure the theme will soon be updated with a 'new minsize' part of the merge. Which will be fine for the official theme, but still have the same issues talked about... My extension would need to pick between an extended ruleset or an extended theme size to make a reasonable window that does not clip.


Another issue I noticed, which might be more general. When you grab the 'resize' corner and shrink it to minimum and continue to hold and resize below the minimum, while the window does not change size the title bar jumps around on the window. So I assume it gets placed before the minsize is applied to the window and hence ends up been 'repositioned' when it realises the window can not go any smaller.

-pete