Talk:OOUI

Jump to navigation Jump to search

About this board

Previous discussion was archived at Talk:OOjs UI/Archive 1 on 2016-12-12.

Nirmos (talkcontribs)

I've never really understood how to properly remove dialogs. $( '.oo-ui-windowManager' ).remove(); is obviously wrong because after doing that I am unable to scoll. And myDialog.close(); is not sufficient because it can only be called from a very limited context, is per dialog and so on. So, how do I properly remove all dialogs?

Jdforrester (WMF) (talkcontribs)

Reading https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.WindowManager I think you want to use OO.ui.WindowManager#clearWindows(), which closes and removes all windows:

Remove all windows from the window manager.
Windows will be closed before they are removed. Note that the window manager, though not in use, will still listen to events. If the window manager will not be used again, you may wish to use the destroy method instead. To remove just a subset of windows, use the removeWindows method.

Hope this helps!

Nirmos (talkcontribs)

It seems like windowManager.clearWindows(); would suffer from the same problem as myDialog.close(); in that it can only be called from when and where it is defined (this is what I meant by "context" above) which excludes MyDialog.prototype.initialize, MyDialog.prototype.getReadyProcess, MyDialog.prototype.getTeardownProcess and so on. How do I undo what oojs-ui does to the scroll bar?

Jdforrester (WMF) (talkcontribs)

Then use MyDialog.getManager().clearWindows(); I suppose?

Nirmos (talkcontribs)

Sorry for late reply, but I've finally done some testing now, and it seems like the solution is really simple. myDialog needs to be declared – but not assigned to – before MyDialog.prototype.initialize, MyDialog.prototype.getReadyProcess, MyDialog.prototype.getTeardownProcess etc, like this. The documentation should probably be updated to use that format. I could do that, however, I'd first like to see some kind of acknowledgement that my reasoning here about the variable being out scope is correct, and that users will run into scope issues if they follow the documentation as it is currently written.

Matma Rex (talkcontribs)

That is one of the possible solutions, especially if you need to be able to close the dialog from "outside" the dialog.

Another is to simply use this.close(); rather than myDialog.close();, if you're in the right scope. Some extra trick might be needed to access the this from a nested function. But this will be neater most of the time, especially if your code is using more than one dialog.

I made an example version of your gadget like this, based on the previous version : w:sv:Användare:Matma Rex/test 20170308.js (comparison: ).

Nirmos (talkcontribs)

This is still a huge problem. It's possible to open more than one dialog at a time, and when closing them, it's impossible to scroll. Today, I finally figured out the answer to the question I asked a year ago (How do I undo what oojs-ui does to the scroll bar?). The answer is that I have to do this. This feels very hacky and I don't think this should be necessary.

Reply to "How to properly remove dialogs"

Getting OOUI object reference from an element?

2
137.147.133.11 (talkcontribs)

For example, I simply want to disable a button. Before I could just set the disabled property, but now I need to call the disable method on the button's OOUI object. If the button was a PHP object, I could infuse it to get the object, but for buttons created in JS (by other scripts I have no control over, for instance), infuse doesn't work.

Matma Rex (talkcontribs)

There is no way to do this. If the other script wanted you to be able to disable its button, it would allow you to get the OOUI object.

For example, the other script could do something like this:

fooWidget.$element.data( 'ooui', fooWidget );

…but if it doesn't, there's no way to get the OOUI object from the DOM element.

Reply to "Getting OOUI object reference from an element?"
Jon Harald Søby (talkcontribs)

I have a peculiar issue. I have a couple of scripts on Wikidata where I've used OOUI buttons. The issue appears with multiple scripts, so I made a script as easy as it gets that still has the problem here: d:User:Jon Harald Søby/testscript.js. The script just puts a button after the page title on user pages.

The problem is that the button only loads when the tab is active while the page is being loaded. That is, if I open a tab that should have a button in the background (with Ctrl+click), the button doesn't appear. If I reload and stay in that tab while the page loads, the button appears. If I reload the page and immediately switch to another tab, the button doesn't appear. This happens in both Chrome and Firefox (I'm on Ubuntu 17.10 if that matters).

You can test it yourself by including that script (on Wikidata) with importScript ( 'User:Jon Harald Søby/testscript.js' ); in your common.js.

Am I doing something wrong in that script?

Matma Rex (talkcontribs)

Your script does not specify a dependency on OOjs UI, which means that it might work or not depending on whether something else on the page has loaded OOjs UI first. Perhaps the browsers load scripts in inactive tabs later or in a different order for some reason.

Try wrapping the entire script in a mw.loader.using call to make it reliable, like this:

( function ( $, OO ) {
	mw.loader.using('oojs-ui').then( function () {
		var button = new OO.ui.ButtonWidget( {
			icon: 'lightbulb',
			label: 'Test button that does nothing',
			flags: [
				'primary',
				'destructive'
			]
		});
		$("body.ns-2 h1").after(button.$element);
	} );
})( jQuery, OO );
Jon Harald Søby (talkcontribs)

Yes, that seems to work! Thanks a lot! :-)

Reply to "OOUI buttons not loading in background"
MitchTarps (talkcontribs)

I'm put in charge of a private wiki for a university here. I've been told to bring back the old UI, as apparently for the dean, "The new interface is too hard and fancy!". My job's on the line here. Can anyone tell me how the hell do I go back to mw-ui? I tried commenting all the dependencies in Resources.PHP and commented out OOjs style from ResourceLoader.PHP. Yet, I could not get a few forms like in the special:movepage to prevent generating the OOjs classes. Please tell me there is a way!

Whatamidoing (WMF) (talkcontribs)

I'm sorry; I don't know how to solve the technical problem. I can't even tell you whether it's possible.

On the human side, have you talked to the dean yourself about this? In my experience, these messages are not always accurately relayed, so if you think you're getting the message second- or third-hand, then it might be worth double-checking. Also, people's initial reaction often changes after they've used something a few more times. And, of course, it's possible that the dean has discovered a bug. In that case, I'd be happy to help you file a bug report.

MitchTarps (talkcontribs)

Yeah, I did. The university got used to the regular UI. They were using an old MediaWiki 1.21. I updated it on their request, fixed all the breaking changes. Now I'm tasked with removing the OOjs library or the UI elements for the least. So far, I have successfully stopped the OOjs core styles from loading up via resource loader. But most things like movepage and search are still using the OOjs UI elements. I see they are defined in that way. Is there a way to go back to mediawiki ui?

Jdforrester (WMF) (talkcontribs)

I'm afraid there's no easy way to keep a latest version of MediaWiki but without the OOUI design; moving all of MediaWiki to it has been a key part of the (still incomplete) marathon job of modernising all the interfaces. Depending on which skin you're using, the "Apex theme" (which loads for Monobook) might be more appealing to the design sensibilities of your users, but other than that I can only recommend reverting which version of MediaWIki you're using.

MitchTarps (talkcontribs)

I also noticed that due to this incomplete transition, some parts of MediaWiki is slow as well. I have submitted a request to revert back to the older version. The problem is I have to patch all the security updates manually. I literally fainted imagining that!

Matma Rex (talkcontribs)

I guess the OOjs UI widgets will mostly work fine if you remove (or heavily trim down) the styles. This is not supported and you will probably face all kinds of problems with tools which depend on OOjs UI more heavily (e.g. UploadWizard or VisualEditor), but if you're desperate… The style files are in /resources/lib/oojs-ui (see also Do not hack MediaWiki core).

Implementing an "unstyled" OOjs UI theme could probably be kind of cool, though. Maybe we should do that at some point.

Matma Rex (talkcontribs)

Also, like James suggested, try using the Apex theme instead – it's a lot less "modern-looking" (but still different from the old lack of styling). If you want it for Vector, you'll need to hack skins/Vector/skin.json and add the following at the end before "manifest_version": 1 (please note, the same warnings about hacking core apply here, but this is likely to cause a lot less problems):

	"SkinOOUIThemes": {
		"vector": "Apex"
	},
Reply to "How do I go back to mediawiki UI?"
There are no older topics