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

[bratch9]

Hi,

I have an issue that depends on a theme extensions. My spell domain extension changes the size of the 'power_groupdetail' window due to adding extra buttons. This works fine for most theme usage, but the 'D&D - official' theme also changes this, so I need 2 values in my extension. One normal and one for when the theme is loaded. ( If this was a ruleset I could use the 'ruleset="5E"' checking xml, but extension ones dont exist as far as I know. )

So the non-theme, non-extension standard game sets this as,


<size width="430" height="290" />

My extension sets this to,


<size width="430" height="330" />

The D&D-Official theme sets it to, ( to cope with the 'dragon' logo at the top of the window. )


<size width="430" height="330" />


And with both theme and my extension, to cope with both the theme extra 'dragon' logo, and my extra buttons. My extension needs to set it to,


<size width="430" height="380" />


So does the system have a way that I can configure my extension to set the 'height' to 330 or 380 depending if a theme extension is loaded ?

What the best way to cope with this. I can set the larger value in my extension, then the window just looks way too large for people not using the D&D-official theme. ( Which looks a mess !! )

I did try 'setSize(x,y) in the onInit for the window, but this did not actually change the size of the window. ( Maybe if it was a re-sizable window it would have... but this is not a re-sizable window for the user. )

Thoughts,
Pete

[damned]

Have you tried Extension.getExtensions()?

[damned]

function onInit()
tExtensions = Extension.getExtensions();
for _,vExt in ipairs(tExtensions) do
if vExt=="ThemeName" then
...code...
end
end
end

[bratch9]

Thanks Damned, that would be fantastic if the 'setSize()' to control the window actually changed the window size. As stated in my thread. ( Yes I already know about getExtensions, I use it and different ways to spot extension across my extensions already.. )

So unless you know of a different way to change the window size that might work that I can put in the '...code...', then its back to what can be done in the xml pre-build layout.

As I said, I could probably change the window to be resizable, and then the setSize() might actually work. But then setSize() would not be needed as the person using the theme would just re-size the window with a quick drag to see the items off the bottom of the window.

Its more about how extension themes and extensions interact and how these issues could be solved...

like,
<size height="+40" />

to be able to increase the static window size by the amount required, instead of a 'fixed' value etc..

or having an xml extension="" like the ruleset one, since the extensions are known at the start just like the ruleset.

or some other way I just dont know about.

-pete

[bratch9]

Also note that the size section is in the placement section,



<windowclass name="power_groupdetail" merge="join" >
<placement>
<size width="430" height="330 or 380" />
</placement>
<script file="mycode.lua"/>



So I'm not sure if the setSize() function is changing this or the actual window size and the visible part is limited by the placement etc..

Also it could be that I need to use window.setSize(), in the onInit of mycode.lua. As I assumed I was a the windowclass level the setSize was valid otherwise it would have said 'call to function nil' in the console etc...

-pete

[bratch9]

I also have xml join for code from other extensions,



<windowclass name="charsheet_actionsft" merge="join">


In this case if the extension does not exist it gives a warning as it can not merge due to no asset.

This would require an 'extensions=""' type item like 'ruleset=""' to allow this window class merge to pickup if it was needed or not.

As the other extension could not correct for it, as they also would not know if my extension was/was not enabled to be able to merge in the items I have to add.

-pete

[damned]

I just added a numberfield to a window with the following code:


function onValueChanged()
Debug.chat(Extension.getExtensions());
window.setSize(getValue(), getValue());

tExtensions = Extension.getExtensions();
for _,vExt in ipairs(tExtensions) do
if vExt=="ExpressYourself" then
window.setSize(getValue(), getValue()*2);
end
end

end

and the window resizes as I change the value in the numberfield.
it does it correctly based on that code.

[damned]

OK just saw that the window is not resizable.
Why dont you just overwrite that in your extension?

[bratch9]

OK just saw that the window is not resizable.
Why dont you just overwrite that in your extension?

Because over the last multiple years of this extension been perfectly fine, this one theme issue report from yesterday is the only sizing issue been reported.

Hence normally its perfectly fine.

Yes I could change it to a resizable window, and I'm sure the issue theme would have the graphics for the resize. Without it falling back to a core/5e graphic which would then cause to 'look' issue to also resolve.

Since the window is static size and only needed the extra items, I followed the minimal change needed. ( In much the same way the theme also changed the static size.. )

This one theme causes issues, and while I could just set it to a larger window and have it look a little too big on the not-this-theme situation. I wanted a more elegant solution.

In my onInit for this window,



function onInit()
setSize(800,1000);
window.setSize(1000, 800);
end


the console window reports 'attempt to index global 'window' (a nil value ), and the window is not resized to 800,100 by the 'working/non error reported' setSize call.

Yes I could set it to resizable, yes I could just oversize the window for all themes.

Even maybe setSize() not changing the size of the window is a 'bug' ?

The one reported person, is happy to just adjust my extension for height 330 -> height 380 to resolve the issue. But that is not a good solution, as it would need to be fixed if/when I update the extension.

Due to more themes and them doing more integration, since themes used to be mainly set background image... Now they are extensions and allowed to 'adjust' more than just a texture swap, more of this sort of issue is probably happening.

Sure in most cases as extension coders we 'work around' with bits of hacks like your suggestion. ( which has it been a resizable window, this would never have been reported in the first place as the user would have just made the initial window bigger.. )

I like a good solution, I can do a 'work around'. But the more times we just 'work around' these things instead of properly talking about real solutions, the less of an issue these things are considered and never get a proper solution.

I'd love to know if the setSize() call should have changed the size of the non-resizable window, and hence is a bug or not.

-pete

[damned]

There is a post from MW in Discord:


Moon Wizard — 12/20/2022 4:13 PM
No, there's no mechanism for that in the system. Either the size is fixed and setSize won't change it; or the size is dynamic and setSize will change it.

[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.atlassian.net/wiki/spaces/FGCP/pages/996645644/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.atlassian.net/wiki/spaces/FGCP/pages/996645644/windowclass

Using dynamic can result in,

57971

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,

58002


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