Please disable 2-factor authentication on this account - 2016-08-15 - thanks
- User Since
- Oct 7 2014, 2:49 PM (133 w, 1 d)
- IRC Nick
- LDAP User
- MediaWiki User
Tue, Apr 25
Should review and improve patch fairly soon.
This can probably be worked on pretty soon.
This is worthwhile, but it's something that will require a lot of looking into the necessity of various dependencies, and bits of code. Hopefully we can schedule this for sometime soon, but unclear exactly when.
This is not a media viewer ticket, reassigning to a more useful project...still something we should look at, though.
This should probably happen after we implement licenses in structured data.
Thu, Apr 20
I also cannot reproduce. Given that there is not sufficient information to reproduce or investigate further, I will close this bug - if someone comes back and reopens it, please include more information about your browser and other configuration details so we can actually look into this.
I think this doesn't rise to the level of "normal", as it's a totally optional feature request that would only affect a pretty small subset of files and users...something to think about in the future, but not something we need to rush towards.
I fear the initial triage and investigation may have missed the point of this bug - @Steakyfask1 are you saying that, after exiting the Media Viewer, the scrollbar for the article is disabled? If so, can you please tell us what browser you're using? I could not reproduce this on English Wikipedia with Google Chrome on Linux.
Coming back to MMV bugs after some significant amount of time, I have to agree with @Tgr that, while this may make it harder to test the extension alongside other extensions, it is absolutely true that the tests' assumptions are mistaken. As this is only within the MediaWiki-extensions-MultimediaViewer project, I'm going to lower the priority on this once again and move it to a holding pen on our workboard. If the maintainers of the Cite extension want to take over this task and alter how their tests work, I would be happy to see an increase in priority.
Wed, Apr 19
@Ineuw do you want a totally new interface that detects redlinked categories after upload, and offers an option to create a page for them? It's not totally clear the scope of this request, but if you can clarify, I'd be happy to talk with someone about what it would entail.
Tue, Apr 18
Updated patch, @Jdlrobson if you want to take another look that would be nice
@Prtksxna would it be sufficient to add role=button et al. to make these accessible in the usual way? It's not clear what specific issue you're looking to solve.
Thu, Apr 13
Yeah, that project is long gone.
Mar 28 2017
Mar 26 2017
Mar 10 2017
Mar 7 2017
T159884 maybe a use case for this at some point (mentioning for bookkeeping)
I sent an e-mail to the ops list to ask for some help coming to a resolution on that. I'll post here with a description, along with other tasks if necessary.
Mar 6 2017
Blocked on T157077, will go forward once that's closed.
Mar 5 2017
Mar 1 2017
Feb 28 2017
Feb 27 2017
Fixing thumbnail process, the wgMaxShellMemory was too restrictive
D580 should fix these concerns, but I skipped a couple as noted in the commit message.
Feb 19 2017
Feb 14 2017
Feb 10 2017
I suspect this is mostly a problem with the server timing out or being overloaded with the 40mb file that James tested with - we will test aggressively with big files on the beta cluster and see if this remains an issue.
Cool. I'll delay this for now, then.
Correct, but as above, if the thumbnail has a different aspect ratio from the viewer, there will be a significant visual jump...though I suppose I could try and see if it affects anything. I expect there may also be a problem with the rotation not being perfectly aligned with one axis or another (so the thumbnail will also potentially cut out bits of the object) but it may be unfounded. Ugh, I will try investigating. I'd almost rather not have the viewer and thumbnail codes diverge so much (as the dimension/view code is basically identical right now), but if this is a big deal then I can.
I was just mucking around with this, and a friend made an accurate observation that, if we have the thumbnail for e.g. a 1x100 aspect object, be a 1x100 thumbnail (or maybe with some padding, 3x102 or whatever), then when a user rotates in the viewer, they will only see 3/100 of the object. We could fix this by using the entire bounding box, and setting it to a square-ish thumbnail with the greatest dimension setting the value, but square aspect rations tend to squash the object a bit (compared to e.g. Thingiverse's rendering). However, if we only did it to the viewer (i.e. not to the thumbnail), we would see a significant visual jump as the viewer loads in Media Viewer.
Feb 8 2017
@Miriya52 I have the same answer as above.
Feb 7 2017
Feb 6 2017
@Legoktm yeah, I think @Gilles probably figured we'd be in Diffusion by the time it got deployed. We can move it into Gerrit whenever that's needed, and if there's any information set up for that, that would help me.
Turns out this is already the case, but the grab/grabbing cursor values aren't supported in webkit or mozilla yet. Adding compat rules (and "move" fallback) in a new patch...
Feb 2 2017
Jan 31 2017
OK, I'll leave this up to @Jdforrester-WMF to decide when he returns to keyboard.
Jan 30 2017
As far as I understand, the 3D extension currently has these capabilities, at least in part. See rTDTP for the thumbnailer, and https://www.mediawiki.org/wiki/Extension:3d for the extension (with thumbnailing and Media Viewer support).
Given that we've decided to only support STL, which is a binary format with no mechanisms for interacting with the outside world, is this task obviated? Do we want to re-title it to deal only with AMF (which we aren't using anyway)?
Jan 27 2017
Upstream bug is fixed - are we at an updated enough version that this can be resolved now?