setPosition in SvelteApplication
The
SvelteApplication class has a function called setPosition that is there to support core behavior. And while it exists and is called when opening the app. It isn't really called when minimizing, maximizing, or changing the position of the window itself. This means that any modules that try to wrap the setPosition function to extend features fail to do so.29 Replies
Well you shouldn't wrap it per se. What type of feature are you trying to implement? The TRL / TJSPosition implementation is quite a bit richer. Quite likely there is an alternate way to accomplish most things.
I'm not the one trying to wrap the function in this case
core foundry uses
sheet.setPosition to change the position of sheets.
Module makers that change the behavior of this function to add more functionality like attach other windows to the sheet generally wrap this function either manually or using libwrapper. And because SvelteApplication doesn't call setPosition while changing the position of the sheet means it breaks compatibility with all the other modules.Indeed any module being refactored / rewritten for TRL may need to change a thing or two depending on the goals being accomplished.
In TRL
app.position is a store, so it can be subscribed to for implementations of attaching / following a target apps position. There is also a robust validation stage that can have user added validators for restricting movement / also useful for docking. So, unless it was a really strange use case there should be a cleaner way to implement the feature w/ TRLthe problem is that other modules don't use TRL 😄
Ah, so you are saying that there is a module out there that somehow affects the position of apps it doesn't own? Got an example of such a module?
ripper's paper doll is one example
honestly a lot of modules do similar things with other functions as well
setPosition should be the only function where control flow is altered w/ TRL, so other Application functions are not diverted to an alternate implementation. In the paper doll example a small change would be needed to subscribe to the position changes of the host sheet.
Not that this is a great solution.. Just a brainstorm hack I haven't tried. Because you have a system and can test against paper doll. Add this.position.subscribe((pos) => this.setPosition(pos)); to the constructor of your sheet. I'm not saying this is a good solution, but curious if that works or blows up.. ;Pyeah already tried that 😄
it's an infinite loop 😄
Yeah.. I'd have to check it out. Technically it should reject follow up position setting if the data is the same as current state, so I'll take a look at that. Not that the hack mentioned above is a good solution.
It is a bit of a rub because the TRL position system is backward compatible with Foundry core except for the use case of an external module trying to integrate in an ad hoc manner with Applications it doesn't control.
technically this can be resolved with changing the 3 instances of
this.position.set to this.setPosition.
actually no 🤔
need to double check something 😄I'll have to take a look. There is the draggable action / implementation that is the sticking point quite likely. This is in the platform neutral implementation for TJSPosition, so not at the Foundry integration layer:
https://github.com/typhonjs-svelte/runtime-base/blob/main/src/svelte/store/position/action/draggable.js#L224
prolly
core foundry calls
app.setPositionYes.. The TJSPosition implementation is platform neutral and can be applied to any element to make something positionable / draggable, etc. It's not a hard coded 1:1 relationship to a specific implementation ala
app.setPosition.
Given that all of this could be upended with the v12 App v2 API I'd want to wait just a bit more to see how much damage that may cause. If Foundry core drastically changes how position state is stored or accessed there will be other aspects to work around and consider. I've been mum on trying to contact Atro and just not draw attention to this potential situation. The likelihood is that app.position as an object storing positional data will survive the App v2 changes. It may not though.
---
All of this again is just a sticking point for "unclean" hackery of external modules which is the exception to the rule.ok I've made a workaround
Do share.. I'll be at a computer soon.
result
Nice.. Yeah. I was going to check out potential solutions that required a small override to
setPosition, but the above is a good take at it.
Now... This works in the adhoc use case of paper doll, but perhaps may fail to work when an external module tries to change the position data versus just plug into getting a hard coded callback that just some position changed of an external app.yup
It's conceivably possible to just make a "Foundry" implementation of
draggable or just add the overridden setPosition implementation you came up with to SvelteApplication, but it really makes sense to wait until there is more details / access to App v2 before implementing anything.
Essentially the current SvelteApplication implementation is going to be transferred to the legacy sub-path export #runtime/svelte/application/legacy and then a new App v2 implementation will be made as presumably there will be changes.yup
I'd deffo wait till application v2 before making any changes honestly
It is a low volume nuisance really just for system developers too. I don't think there are modules that try to do something to other modules in the same manner as paper doll does in respect to actor sheets.
a lot of modules do actually
just not with sheets usually
it's usually with other parts of the system
the list goes on
Honestly, the way modules change stuff is by wrapping the original functions of sheets, documents, etc
For sure, but from a UI / control perspective it should be rare or non-existent that a module tries to change the behavior of another module. The paper doll situation is system specific for actor sheets.
Yeah
Core foundry doesn't really have a hook for position change of a sheet
So stuff like this ends up being needed
Hopefully all these little things will be better with Appv2
Yeah.. I hope so too. I wished I had a better working relationship with Atro and the core team to be able to communicate lessons learned. You could drop in the TRL position implementation (which is JS) right in and get tremendous benefits. I want to remain positive that good things will come from App v2, but I expect it to be flawed as UI / UX is not a strong point of the core team. I remain hopefull nonetheless.
Just as a note too re: no hook for position changes. If the TRL / TJSPosition implementation was the standard these kinds of problems would go away because
app.position can be subscribed to. And if an external module wants to alter validation of position changes there is the validator API of TJSPosition: https://typhonjs-fvtt-lib.github.io/api-docs/classes/_runtime_svelte_store_position.AdapterValidators.html
I definitely should try and get a demo of the validator API into essential-svelte-esm at some point.