#I was troubleshooting something last
1 messages · Page 1 of 1 (latest)
Initially, I was trying to solve the fact that context menus were being cut off by clipping paths on elements. No big deal - that was something specific to my module. But changing how they worked on the summary sheet to just rendering with a different position broke the equip status menu on the gear tab because its not implemented in the same way as other context menus. And I'm not sure why.
Via CSS, I was able to revert everything done to the equip status menu with inline styles and and very minor changes to the core sheet's code. I'm just about ready to submit a PR to the system for it. Unfortunately, what I can't do is fix the fact that the fantasy companion's premium module is similarly using the same limiting of targeting parent tags to get an item ID. In this case, I think the Backpack context menu option is looking specifically for li.item when it shouldn't really matter whether a sheet is using an li tag or a div tag - as long as it's using the correct class structure.
This isn't just about one 3PP module implementing genre-generic custom sheets. The implementation of targeting event listeners to specific document element types is a limiting factor for all Aces with a desire to publish setting-themed character sheets without needing to, essentially, rewrite the entire system or, at best, large chunks of the character sheet.
I'll open an issue and submit a PR for the core system, but this is something that really needs to be addressed with a code standard at MM since it's now also affecting premium modules which can't be addressed by the community.
Removing all the inline styles and applying a position: absolute and then I added this code to my own character sheet, which is what, essentially, fixes the equip status rendering.
html.find(".item .equip-status").off();
html.find(".item .equip-status").on('click', async (element) => {
ContextMenu.create(this, html, '.item .equip-status', this.themedSheetsEquipStateOptions);
});
We do test against the premium modules but we can't test against every 3PP module. If you give me access to your sheets I can try and keep collateral to a minimum, but as I've said in the gitlab ticket before, I would really advise you to write your own sheet from scratch because it makes you more independant from what the system does
You should really take full advantage of the fact that foundry let's your register your own sheet class. By relying on the system sheet you are in essence limiting yourself.
it makes you more independant from what the system does
Which is not feasible for small publishers. This isn't just me. This is Knight Errant. This is the Vermilium publisher. If you implement standards you won't cause these issues for 3PP
You are free to make said standard 3PP sheet yourself
I do and I am. But I shouldn't need to rewrite system code to do it. The system should be listening for events independent of document structure and it's not.
I am happy to give ownership of all sheet related tickets to you
let me add you to the repo real quick
Any objections?
Dude. I'm asking for a code standard to make things easier.
And I am asking you to do it yourself
Part of the problem it seems is that the premium modules, which the community can't touch, are using the element-based selectors as well rather than class-based selectors.
Which is what I'm going to submit in a PR later. The problem is, I can't PR the premium modules because they have similarly constructed standards-breaking implementations.
Okay sure do it
then I can go ahead and fix all the shit you break later and you can continue to make money off your patreon
or do you want me to do that for you as well?
Just submit the PR, the rest isn't your issue after all.
I'm going to test everything with the system to make sure the implementation works generically. But, again, I can't do anything to premium modules. If there were standards for implementing and interacting with the system, it would help not just 3PP (because you could point to a documentated standard that is followed) but also the internal premium modules.
Just do the PR please
"If you want it, you're welcome to submit a PR."
"Submit a PR, and then I'll have to support your shit code."
This song and dance is getting old, Flo.
No, you're still being an asshole
So what do you want me to do please
Not be an asshole
Create a welcoming environment so people want to contribute to the system.
Then I will quit.
I clearly can't create this environment
It has been an honor
Good night
or whatever time of day you are currently having.
Cool
How?
The problem I am having here is that you are asking me to do things I have no control over
I am not in charge of the premium content. I can forward your request but I cannot guarantee anything will be done
That's why it's coming up in a conversation, which is OK!
I can merge your suggested changes, and then somebody (probably not me) will have to adjust all the other modules, including all those small 3PP publishers that you mentioned
But you could surface the concern. This is something that will make implementing things easier for both 3PP and MM premium content.
If you want to suggest a change to how the premium modules do their selectors I am all ears. There's a bit of work involved until I can make such big sweeping changes for sure, but if it's a conflict with the premium modules and it's because we are doing bad practices I am happy to hear you out.
also @night zenith @hollow current You two should lodge complaints against me with both MM and PEG, jsut to be sure
but making that as an issue or in direct communication with me would be the way, I only accidentally stumbled over this.
It's a minor change. Basically, don't target specific element types, target based entirely on CSS classes.
I've already got an accepted PR on the core system that does it going into 3.3.
I just ran into the problem again with the Backpack equip status option from the Fantasy Companion module and I had to override the context and pull that one out because it was the only one that wouldn't work.
I don't have the context required is what I'm saying.
did you check out the changes we did to the context menu as part of 3.3?
That's not a problem, but please be aware that the community doesn't know who is responsible for what behind the scenes at MM.
when in doubt, https://support.metamorphic-digital.com is responsible for everything behind the scenes.
Support Portal for MetaMorphic Digital Studio products.
Hey @radiant quail can you post that to the main chat so it can get pinned
What would you need for context? Code? Or just the specific situation/use case?
The challenge there is that it disappears into a space in which no one from the community can easily reference the issue. I know I've received replies without any context to what the original request was and had no idea what we were even talking about anymore. 😆
That's a separate issue then with the portal config not making sure the email chain has the original ticket
Yup, I've brought that up before during one of those exchanges
Yeah, I am a wildcard resource, that means I know enough of everything to get things fixed if I know what to look for, but I don't usually know enough to fix something based on high-level language^^;
I saw them. It's got the tagless implementation but the main source of the problem I was running into was the PopupMenu class that overrides the core Foundry ContextMenu class with inline styles.
And I see that's still being used.
I don't like it either but that was the only way to get it to work how we wanted it to, i.e. not overflowing and opening pointing towards the inside of the sheet
I was being serious tho about the sheet tickets
you are free to do those, I don't want them anyway
realistically nobody wants them, save for you I guess ^^
Gotcha. So, there's an equip status in the Fantasy Companion module for "Backpack". In the callback, it looks for i.parents('li.item').data().itemId (or something to that effect - it's the li.item that's the concern). All the equip status callbacks in the core system do the same with i.parents('.item').data().itemId.
I'm guessing there is a similar function on the fantasy companion sheet where this is taking place. On the system sheet, it's in #setupEquipStatusMenu. The other possibility is it's in a menuItems Hook listener.
that's only half of it, at best. My issue is that I just end up effectively getting badgered to do something until I do it, mostly by the community
So I've grown reluctant
not that anybody really cares (least of which myself I guess lol)
...I just end up effectively getting badgered...
That's part of the problem. No one was badgering you here. It was just conversation. In most cases, it's just conversation.
That's part of it
For you it's just a conversation
For me it's not, because historically every "conversation" ends with with a ticket, request or some other work item that for the most part I get to do
Because people ask me to put myself in their shoes but I don't think anybody's ever put themsevles into my shoes
To be perfectly 100% honest? I don't want to be here
Oh well then in that case, let's just never bring up issues and let the system be as is. What were we thinking? 🙄
Except this one is only going to result in a PR that all you need to do is click to Merge. I spent several hours of my own time yesterday figuring out what was causing the problem and more time this morning surfacing the issue and a way to address it long-term. And you reacted like you normally do.
I can't imagine why there's so little community involvement in improving the system. 🤔
If you want me to leave then please just come out and say it clearly
That's all I'm asking right now
If you want me gone then say so
Well if you don't then also say so, of course
But right now I am not sure whether the community even wants to be a part of it or not anymore
or if we were all better off if I weren't involved at all anymore
I think I can't make this decision anymore
Please just give me a simple yes or no. We can talk about the rest later if you want, that's all I'm asking
two to three letters. Not more, not less, please
It's not a question of whether or not anyone wants you to leave, it's that we want you to be receptive. Your reactions and general outlook make it challenging to interact, and certainly reduce or remove any incentive to engage.
And the problem remains the same.
Let me know if this is enough context for you or if I can provide additional detail.
And so the cycle continues
Only because you let it.
No, because you refuse to answer a simple yes or no question
I'm just done engaging with you on this thread since you won't be part of the solution.
I want to be part of a solution but it's not the solution you want
I just want this very simple question answered, then we can continue.
enough for now, I saved a link in the issue and will follow up if needed.
am I correct in saying that the changes you are proposing here don't improve the sheet functionality for any user, but they make it more convenient for people building sheet customisations on top of the system? switching these sheet CSS selectors doesn't fix anything that's broken in the system as it ships today, right?
Those sheets function properly, but the way it's implemented prevents other sheets not based on that layout from functioning properly.
Correct. It's improving it for licensees that might build setting-specific sheets as well as my own genre-specific, but overall generic, sheets.
It also impacts premium module sheets which could be implemented more easily with a different approach.
That's all I'm proposing.
Or trying to propose, at least.
that's what I thought
so Peter -- given you're asking for these changes so you can continue to run a for-profit Patreon off the back of your sheet-customising efforts -- can I please ask you maybe approach the situation with a bit more humility than you're currently showing.
coz I just read the thread above, and I think you're being bloody rude. Even asking those of us who open source our contributions to make changes to suit yourself is still time and effort we could be using to improve the system for everyone else. Let alone demanding it.
So, Ace Licensees shouldn't be able to create a setting specific sheets that extend and implement the system? I know of two that have.
I'm also open-sourcing contributions and proposing these to the core system. I haven't made my PR yet, I just finished troubleshooting yesterday.
I'm contributing to the open source system to improve it. The problem is those same implementations are made in premium modules where I cannot contribute.
C’mon man, you’re doing it so you can make sheets for your Patreon. I wasn’t born yesterday.
And that’s a perfectly OK thing for any Ace to do and within the spirit of Apache-style OSS (but not, I note, GPL FOSS.) But they have to approach the situation with some bloody humility if they’re going to ask others to do free work to support their commercial work!
Maybe we should all just take a minute and take a breather
That's the driver, sure. But that's not unusual for how open-source projects tend to evolve. I utilize OSS frameworks (and provide financial support for them) through my Web dev company in the same way that I provide financial support for the free system in the form of premium module purchases.
Peter is trying to make sure that if his PR gets merged, it won't break the premium sheets.
I already guaranteed it will, haven't I?
I will broadly say that CSS is a hot topic the last 24 hours - other parts of this server have been talking about it too - and so it's not just us that are dealing with "Devs butting heads over selectors"
Asking for a standard shouldn't be met with "eff off". I might also be asking because it's impacting me, but this is also soemthing that affects other Aces who might try doing something more elaborate for their setting sheets.
Some of this is us dealing with the downstream effects of how Foundry loads styles
I mean if we don’t merge it we can be sure it won’t break anything, so if that’s the goal I have a solution
but it IS us dealing with "Floradical is an asshole" xD
not my words, but they're certainly true
And thus other devs creating custom sheets, whether for profit (including Ace licensees) or not, are to do what exactly?
swings and roundabouts. Imma merge Peter's changes and then we can continue living our lives
I work for a very large software company and if we asked Linus to make kernel changes the way you asked for them here, we’d never get anything upstreamed at all
oh god could you imagine lol
Linus isn't known for his polite responses to aggression, lol
tbh, standards are also a very vague thing. I've seen a bunch of people claim vastly different standards over a bunch of things.
I'm not saying that it is. I'm simply saying, there are CSS standards and, with good namespacing and selectors, the system is something that can be implemented to create a very immersive experience. I'm identifying things that impacted me specifically, sure. But I'd like to be able to do more for my own setting as that develops. And I'm willing to contribute to the free system. But your public face makes that extremely challenging since starting a conversation is grounds for criminal charges.
Yea. That doesn't justify someone else's bad behavior.
Standards always are. It's not a reason to not have one.
It sounds like this thread has run its course and all that's left to be done is submit a PR with proposed changes
There's more to the discussion than that, but yes, that particular part discussion seems to be concluded.
maybe it would also be beneficial to actually get the aces into the conversation as well
I wasn't finished yet. I know you two are
Ummm... Then Aces are in the conversation. Is it just not enough of them?
Kinda, yeah
The way it's worded it seems you are speaking for more than just the two of you, which is why I am proposing to get more people who are impacted involved directly so we can hear out what they also have to say
Not because I think you two aren't worth listening to but because we have a sample size of, well, two
If you really want to establish a standard everyone can work with and adhere to we should try and get more opinions so we can formulate a pattern that works, get an RFC going and all that jazz
or do you want me to link the relevant XKCD?
I mean, I proposed a standard already and was told I was being demanding. So... 🤷
The intersection of Aces who also write code is small. That's why there are so few Ace products in Foundry VTT.
Also, are we seriously debating the validity of not using an HTML element as part of a selector?
I agree my response was dogshit but does that invalidate the points I am making right now?
Or to submit a PR but if I submit a PR then you have to support that shit.
It doesn't. But a standard was proposed.
I'm not sure "don't use selectors like this" is a standard. This needs some more definition. Stuff like using data attributes to control listener execution etc
We could be doing so much more to make it even easier, is what I am saying
Gee... You should have led with that instead of getting indignant and pissed off, then.
dude, calm it
serioulsy
What I said, and what I've always said is: if we take the document element out of the selector and just use a class tree (.item.effect .effect-action for example), it makes it so it can generally be applied.
Have you submitted a PR to make the necessary changes in all the spots it's needed yet?
This literally started with a conversation about making a PR
Partially, and I am grateful for the changes
I will once I've been able to locate all the spots and test to make sure it works broadly with the core system sheet and sheets that extend the core.
Then we can come back and further define the element tree and possible attributes
I don't see a recent one in the repo is why I asked. And at this point some hard changes to talk about are the next step. A continued vague but irritated argument in here isn't productive ATM. Getting some hard changes to discuss is necessary.
Peter said he's going to make a PR with the necessary changes. We can pick up that particular part again later