Widget talk:Wikipopup extended

Popups with skill facts

Looking at why Meteor Shower failed (403 Forbidden), you might need to stick the text to be parsed into a header, and post with that header (rather than trying to post it in the url). -Chieftain Alex 23:19, 4 February 2023 (UTC)

the "fileOperation" function in Widget:Editing robot is similar to how I'd do it. -Chieftain Alex 23:20, 4 February 2023 (UTC)

Thanks, I will look into it tomorrow. For now I removed lots of redundant code with regex, e.g. "gamemode wvw|pvp" lines, however, there's still too much code for monstrosities like Consume Plasma.

Other problems are:

• Resize the tooltip box such that all skill facts are shown.
• Remove the fade-off at the bottom.
• Somehow add fractions, e.g. 0.5 activation time should be displayed as ½.
• Reduce the loading time for the skill fact parsing if possible.

This is just a first try to show that theoretically it is possible to modify the wiki popup and turn it somehow into the in-game tooltip. For example I'm not sure if the mutation stuff works in Common.js (the last time I tried it didn't), hence I guess we can use it only on a limited amount of pages, e.g. game updates. Also, I'm not sure how much traffic (the normal extract query, one api smw query and one api parse per hover) this would create. So overall, still a lot to do. --Tolkyria (talk) 23:39, 4 February 2023 (UTC)

• For resizing, I think overriding the CSS rule .mwe-popups.mwe-popups-is-not-tall .mwe-popups-extract { max-height: 136px; } should do it (e.g. 500px)
• For the fade, .mwe-popups .mwe-popups-extract[dir="ltr"]::after { } has the gradient, suggest add display: none.
• Fractions sounds like the easy bit vs what you've done. Helper function with a switch case statment.
• 0.14s for each of the three requests will be harder to reduce.

Three requests seems quite a lot, but as you said it's a (really good) prototype, and there's no obvious way to deal with parsing returned skill facts properties otherwise. -Chieftain Alex 00:16, 5 February 2023 (UTC)

Thanks for your additional suggestions, I implemented them (I wasn't considering the classes mwe-popups-is-not-tall and mwe-popups-is-tall for the width/heigh, see also the examples picture on top/right). However, I had no time today to figure out our initial suggestion about the parse function yet.

Furthermore, I guess at this point we can pretty much consider it as public widget, so feel free to edit and improve it directly if you got any ideas. --Tolkyria (talk) 18:28, 5 February 2023 (UTC)

Live version

I absolutely love this widget, and I know its function has been a very requested feature for quite some time, especially because of balance patches. However, it's been some time since any additional work was done, and of course I cannot force anyone to do it (obviously I would certainly help if with the widget if I could), but considering the talk thread above, maybe we could implement it already? ~Sime 17:48, 21 June 2023 (UTC)

If you wouldn't mind some improvements first (See Widget:Test) could i have a few days to do some finishing touches? Nightsky (talk) 00:45, 22 June 2023 (UTC)

Test away, test away! I just wanted to bump it and I am glad it is not being forgotten. ~Sime 00:49, 22 June 2023 (UTC)

The question is why. This has always been a nice but expensive widget with

• either very limited usage (e.g. only game update pages) and thus introducing inconsistencies on how the wiki popups look like
• or has to be used everywhere without any chance to add it to all pages properly and hence requiring lots of manual widget/template calls on pages without a generic infobox (again inconsistencies).

Sure, feel free to improve it, it's definitely a nifty and gimmicky widget to play with and get everything right, but in the end I think it's not applicable on the wiki. --Tolkyria (talk) 14:14, 23 June 2023 (UTC)

I think it's too resource heavy (sheer number of requests) to implement everywhere personally. That being said, a fairly easy optimisation to reduce requests when repeatedly hovering over the same link would be to (1) create a global variable to store previous api request results, (2) check if result already stored prior to querying the API, (3) send the output to the same formatting function. ... or just straight up cache the final tooltip. -Chieftain Alex 15:51, 23 June 2023 (UTC)

Ah I did not know it was that resource heavy. I do agree that it does not have to be implemented anywhere, from what I have seen it is mainly requested for the patch notes (and I do not think inconsistencies for normal popups vs skill popups are an issue?), but if the heaviness could be reduced to be able to deploy it for more places that would great -- but again, you here are the wizards lol, I can only put out requests. ~Sime 15:57, 23 June 2023 (UTC)

For what it's worth, the Widget:Test code seems to work just fine now. Given the talk here i'm unsure whether i should even move it over though, so i'll leave it over there. Feel free to copy it over, use it for whatever on the wiki, not at all, or replace it with something else entirely, though. Nightsky (talk) 00:40, 24 June 2023 (UTC)

Implement the code here, don't let your effort be buried and overwritten on the test widget! This general meta discussion on how to use the widget doesn't really affect the ground idea of the widget and what we already have done. I assume you had fun creating, the same as I had while putting together the rudimentary initial code, don't let this feeling go away just because we don't know how to use this widget right now.

Though, I have one point to criticize, I'm a button enjoyer, please fix these terrible no-margin grey buttons, please be fancy, maybe use something like the Template:Game mode version ones (probably no icons). --Tolkyria (talk) 08:32, 24 June 2023 (UTC)

Tested with and without icons, icons end up being too big and needs quite a few rules to "fix" the footer (naturally not high enough). -Chieftain Alex 10:45, 24 June 2023 (UTC)

I've implemented it over here, including a few changes which include making the templates response smaller.

I had no idea regarding how to make the buttons look any better and didn't think of copying the look of the game mode version widget there as well. That i'm not exactly fond of doing UI probably didn't help there either. I like how Alex made the buttons look now, though i'll miss the lack of margin in between the buttons making it impossible to acidentally navigate to the page by clicking in between them.

I wasn't sure under which name to put the template. Feel free to move it to a different/more fitting name. Nightsky (talk) 00:03, 26 June 2023 (UTC)

(Reset indent) Is there still testing that needs to be done? It looks great and I'd really love to see it go live soon. --Dak393 (talk) 13:25, 1 November 2023 (UTC)

Since it was straightforward to do, I've added some very temporary storage so that if you're on the same page it doesn't request the same SMW data (the popups extension query still fires off).

There was a bunch of code in there related to setting a preferred game mode which didn't seem to work/or do anything for me - no radio buttons etc appeared. I've removed that bit of code on the assumption that it wasn't working for anyone else. -Chieftain Alex 17:40, 1 November 2023 (UTC)

Implementation

Things to do (if we want to implement it):

• Consider moving the query template (called by the code + would then require an update) to a new location if no longer calling the widget wrapper template
• Update docs on Guild Wars 2 Wiki:Popups, and change the code to point to it
• Add to MediaWiki:Common.js
• Add to MediaWiki:Common.css

-Chieftain Alex 17:50, 1 November 2023 (UTC)

Prepared for the change. Barring any objections I will add this later in the week. -Chieftain Alex 21:51, 1 November 2023 (UTC)

JavaScript parse error (scripts need to be valid ECMAScript 5): Parse error: Missing ; before statement in file 'MediaWiki:Common.js' on line 386

Ok that failed a the first let. ES6 (ECMAScript 6) isn't supported by Common.js (ref), only up to ES5 (ECMAScript 5). I think someone will need to convert anything ES6 specific to something common.js friendly before we try this again. -Chieftain Alex 18:23, 2 November 2023 (UTC)

Looks like spread operators, arrow functions, and let/const are all no goes. -Chieftain Alex 18:26, 2 November 2023 (UTC)

The default game mode selection does do something, except only for logged out users at the moment due to clicking the gear while logged in directing to the preferences instead of showing the popup window with the settings as it does when not logged in. (For what it's worth i noted the later being the case before once, while reporting this. (At least on wikipedia there's a popup window appearing there while logged in also, so i'm assuming it not doing so here is a bug, but for all i know they could maybe be specifically opening it somehow; similar with the reference preview popups which apear just fine while logged in there too i suppose. (Though i think they were combined there before, while they seem to be two different windows now and not doing that anymore, instead going to the preferences instead there too.)))

Speaking of (or, well, referencing/having linked to) reference previews, could you possibly remove the .mwe-popups-extract { white-space: pre-line; }-bit from Common.css please? It seems as that that clashes with said previews; making them appear weirdly tall. Might have to be left out, or made specific to only popups with skill/trait data added. (Perhaps remove all of the CSS that was added to Common.css for the purpose of moving the script to Common.js while it's still here alongside of it?)

I can't quite tell (I'm not aware of any simple way to determine whether something from ES6 is remaining still at least.) but you seem to have removed all of ES6 already now? We may want to consider rewriting it to show e.g. the in game menu bar setting gear on the left (or somewhere else in the same row as where the default popup gear is on the right at the moment (Maybe where the beta text is at this time?)) to open a custom setting window (that which would probably end up not very pretty looking if i were to try and make one) to allow for selection of the default game mode there, also while logged in, instead of piggybacking onto the exsisting gear popup that only shows while not logged in, before it being moved into Common.js too? Medyro (talk) 16:41, 6 November 2023 (UTC)

I forgot about the bug report.

I removed most of the ES6, then it broke in a way I can't seem to figure out the solution for. (equivalent to the skill fact icons). -Chieftain Alex 19:07, 6 November 2023 (UTC)

That bit should be fixed (and, provided i didn't miss something (I assumed replaceWith to not be ES5 compatable at least, so replaced it too.), ES5 compatible) now. I think something's not quite right with the CSS as well though. Or at least not all of the facts seem to show up anymore. And the buttons to change between the game modes appear to not work anymore too. Medyro (talk) 00:03, 9 November 2023 (UTC)

So i rewrote some of the code. As far as i'm concerned at least the only things that the widget could probably do with before being widely imlemented would be better styling of (and probably also wording/phrasing in) the settings pane. Well, that and the updating of the code in {{wikipopup extended queries}} with the code over here (sans the category) and the replacement of the line of code in the widget referencing the latter with the former template.

There's also a space problem concearning the game mode selection buttons (causing them to stack) when the popup is tall and opens above and to the left of the link (i.e. as it does when a link's close to the right hand side of a page), however this will not be a problem anymore once the beta link is removed as then enough space will be available for the buttons to appear in a single line once more as intended.

As for why the space is a problem in this case is due to the popup being deliberatelly differently styled when it is tall and opens up to the left of a link (note the :not(.flipped-x):not(.flipped-x-y) in one of the CSS selectors), as otherwise the additional width can cause the little spike of the popup to point to the right of instead of onto the link that was moused over in order to bring the popup up in the first place.

In any case i'd like to pettition for the code to be placed on either a separate page (e.g. MediaWiki:Wikipopup extended.js) or a subpage (of Common.js, i guess? (e.g. MediaWiki:Common.js/Wikipopup extended.js)) and then be loaded from where necessary via mw.loader.load(...); or similar, which should circumvent the ES5 requirements and shouldn't be much of a problem in therms of additional traffic either, especially so if varnish is made to understand to cache it instead of declaring it uncacheable, as it seems to like to do with e.g. the action=parse mediawiki API requests the widget uses to query the template for the extended information (even if the requests only contain cookies that don't alter the response, either due to being explicitly said to not be altered or interpreted by server side code in any way (en_wikidb_gw2mwuser-sessionId) or from being caused by the cookie consent banner (cookieNotification, cookieConsent)) for example. Medyro (talk) 18:56, 14 November 2024 (UTC)