Talk:OOUI/Archive 2

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

For example, switching a button from enabled to disabled.

You'll want to call the setDisabled() method, see the docs.

For instance, in the code to insert it:

// Create button
const buttonWidget = new OO.ui.ButtonWidget( {
	icon: 'next',
	label: 'Press me!'
} );

// Append to DOM
$('body').append( buttonWidget );

// Make it disabled
buttonWidget.setDisabled( true );

On the other hand, if the button was injected by PHP, you'd need to infuse it first, using an ID you set on it (in this case, 'thisIsMyButton':

// Get the button's DOM node
const buttonNode = document.getElementById( 'thisIsMyButton' );

// Turn it into an OOUI widget
const buttonWidget = OO.ui.infuse( buttonNode );

// Make it disabled
buttonWidget.setDisabled( true );

Thanks a lot!

But in this case(js): the button has been inserted to DOM by function1, but when I want to disable it in function2 after some process, I can't find a way to reclaim the button object defined in function1. So, is there any way to achieve that? The infuse method seems to fit this requirement but does it just work with PHP injected element?

Looking forward to your reply!

You should ideally have function1 and function2 communicate properly rather than through the DOM, but yes, you can re-infuse to get a handle on a widget.

OK, thanks. I haven't learn coding systematically, so my dumb way is to re-infuse from DOM.

OOUI offers nothing that specific, but it is perfectly feasible and the kind of custom approach I'm settling on - using separate inputs for values and labels - is parallelled in other UI frameworks.

For the original report and some context, see https://phabricator.wikimedia.org/T335240

If it is not a bug, the question would be how to best work around the default behaviour of comboboxes which lets you select an option and submit a value, but confusingly, without displaying the relevant label to users. (By 'label' I don't mean the html element that may be associated with an input).

The common approach for option elements is to have the value/data assigned to the attribute 'value' and the label to the content of the element, but in OOUI, the accepted values go to an input in which you can type new things. Of course, inputs don't support that sort of separation of values and labels. Frameworks tend to solve this by introducing some kind of interaction with additional hidden elements, but I haven't been able to find out if OOUI has ever addressed this situation.

Maybe there are best practices I'm not aware of, or someone else has already cracked it!

A search for potentially related solutions on Github and Phabricator wasn't very fruitful, so I went ahead and started work on an approach involving a combobox widget and a hidden input widget that's just there to contain / accept the selected value. That seems to work well enough though I need to spend more time on it in order to keep the inputs in sync.

Hello, I tried to create a OO.ui.FieldsetLayout with the "help" config, but I noticed that the help icon didn't appear in the upper-right corner as described by the documentation. Instead, it appeared in the middle (about 7:3 to the left and right margin). Is this a bug by any chance? Thanks!

Hi,

although I am doing everything according to the documentation, OOJS-UI throws errors at me. To reproduce:

• Install nvm, nodejs 16.19.0 (lts/gallium) and grunt-cli
• git clone repo https://github.com/wikimedia/oojs-ui to html root/resources/lib
• go to oojs-ui
• npm install
• grunt build
• npm run-script demos

Everything works up until here, but when I clone a template with:

• grunt add-theme --name=pf2e --template=wikimediaui
• npm run-script demos

And I go to the /resources/lib/oojs-ui/demos/index.html, when clicking the name of my template, the screen stays white. When clicking on php and then on my template, it throws the following error: "Fatal error: Uncaught Error: Class 'OOUI\pf2eTheme' not found in /var/www/html/resources/lib/oojs-ui/demos/demos.php:23 Stack trace: #0 {main} thrown in /var/www/html/resources/lib/oojs-ui/demos/demos.php on line 23"

I do not know what to do since I am keeping 100% to the docs. Can anyone help me?

Thank you very much in advance

It seems that the theme names are case-sensitive – everything works for me if I use:

grunt add-theme --name=pf2e --template=WikimediaUI
grunt build

…with WikimediaUI, not wikimediaui.

(I updated the docs: https://www.mediawiki.org/w/index.php?title=OOUI/Themes&diff=5681289&oldid=4824850)

You cannot imagine how grateful I am :-) Thank you very very much, that solved everything!

Hi again,

after @Matma Rex clarified the building and testing process for me, I tried to load the theme in my chameleon skin. Unfortunately, it does not work and WikimediaUI is used e.g. when editing a page or in the extension advanced search.

I did the steps according to OOUI/Themes (Using themes in MediaWiki) and copied everything accordingly. I then edited the skin.json of chameleon and inserted the code according to the example on Gerrit.

"SkinOOUIThemes": {
  "pf2eui": "Pf2eUI"
},
"OOUIThemePaths": {
  "Pf2eUI": {
    "scripts": "skins/chameleon/ooui/oojs-ui-pf2eui.js",
    "styles": "skins/chameleon/ooui/oojs-ui-{module}-pf2eui.css",
    "images": "skins/chameleon/ooui/images/{module}.json"
  }
},
"AutoloadClasses": {
  "OOUI\\Pf2eUITheme": "skins/chameleon/ooui/Pf2eUITheme.php"
},

I have tested 3 things:

1. all files are at the locations stated in skin.json
2. the css files in the folder seem to have the correct color palette
3. when purposefully inserting mistakes in skin.json, some extensions (e.g. Advanced Search) won't load

So it seems that my OOUI stated in skin.json is found but it does not overwrite the default in the extension.json.

Do I have to edit every single extension.json, or am I making a mistake?

Mediawiki 1.37.6
Chameleon 4.1.0

Thank you in advance for your help!

I think the paths should be relative to the skin's root directory, not MediaWiki's root directory – try removing skins/chameleon/ from them all.

If that doesn't help, can you put up the code somewhere I could download and test it?

Thank you for your effort again and please check your mail

Here is the link to my compressed skin folder: https://drive.google.com/file/d/1gsZYKIjZ5QcBX0o1GrpeksH6bVuZ3QMn/view?usp=share_link

I can't access that link, I get:

Access denied

Error code 1020

You do not have access to cloud.mysv.me.

The site owner may have set restrictions that prevent you from accessing the site.

Sorry, I moved it to Google Drive. Please find the link above

I had a look and I mostly got it working. There are three problems:

• In SkinOOUIThemes, the key is supposed to be the skin name and the value is the theme name, so the correct syntax for your case is:

  "SkinOOUIThemes": {
  	"chameleon": "Pathfinder2UI"
  },
  

  I had missed it at first that you're adding this to the chameleon skin, rather than to your own skin with the same name as the theme.
• In OOUIThemePaths, you actually need to add back the skins/chameleon/ prefix, my bad. The paths are relative to the value specified in ResourceFileModulePaths, and chameleon doesn't specify it at all. Every other skin I've seen in the past configured the prefix using that option. (AutoloadClasses, however, should not have the prefix.)

  "OOUIThemePaths": {
  	"Pathfinder2UI": {
  		"scripts": "skins/chameleon/ooui/oojs-ui-pathfinder2ui.js",
  		"styles": "skins/chameleon/ooui/oojs-ui-{module}-pathfinder2ui.css",
  		"images": "skins/chameleon/ooui/images/{module}.json"
  	}
  },
  "AutoloadClasses": {
  	"OOUI\\Pathfinder2UITheme": "ooui/Pathfinder2UITheme.php"
  },
  

• Several of the .css and .js files are missing in your archive, possibly you copied the wrong files from the OOUI build? I am getting error messages such as:

  RuntimeException: style file not found or not a file: "/var/www/html/w/skins/chameleon/ooui/oojs-ui-widgets-pathfinder2ui.css"
  

  When I place files at these locations, they are loaded as expected.

Unbelievable, thank you very much again, that solved everything! I corrected the entries and added the files. I must have been blind to not copy every file with my UI name.

Up until now, everything looks like I have built it! Thank you!!

Over the last couple of days, I've been trying to implement navigation tabs using OOUI\TabPanelLayout, OOUI\PanelLayout and OOUI\IndexLayout in PHP. My setup is a custom extension and the tabs are intended to be rendered on pages of a custom MW namespace. However, both panels are shown, stacked vertically, and clicking any of the headers has no effect on the appearance of the panels, whether framed or frameless. The browser’s inspector shows what looks like some unprocessed json data still being attached to the data-ooui attribute. Also, there’s a couple of seconds delay in page load before OOUI finally kicks in and the plain HTML gets transformed.

I could go into a lot more detail here, but the issue here is that what is required to make things work, namely infusion, is not being triggered. Wikimedia’s own OOUI demo shows that the same broken behaviour applies unless you hit the ‘Infuse’ button at the top. I had already made each widget infusable and also added the setInfusable function at the end, to be on the safe side, but it would be helpful to know what other steps need to be taken.

The documentation on this website and on the Wikimedia site does not suggest solutions, AFAICS. Should something like https://github.com/wikimedia/oojs-ui/blob/master/demos/infusion.js be included as a dependency? What do you recommend we should do? Is it advisable to use OOUI at all?

I wanted to create a clean jsfiddle environment with OOUI.js but failed. https://jsfiddle.net/wnju1orq/
Cannot find a clean list of its dependencies on OOUI and associated pages : they assume we code on the wiki.
Added OOUI JS library v0.42 from cdnjs but doesn't work. https://cdnjs.com/libraries/oojs-ui
Is there something I'am not aware of ?

I created a OOUI starter on jsfiddle :

• https://jsfiddle.net/bkdp478f/ - OOJS/OOUI kick starter, ready to code and demo

I added a link at the bottom of the main page. It think it fits into that list but please review.

OOUI is "Object-Oriented User Interface", see OOUI/About the library

What OOUI stands for? Obviously the UI stands for User Interface, but the OO?

"Object-Oriented User Interface", see OOUI/About the library

Hi - for the OOUI DateInputWidget (currently used in UploadWizard and maybe elsewhere), is there a way to change the first day of the week shown in the calendar input from Sunday to other days (since in many countries it's Monday or even Saturday)?

The start of week shown in the calendar depends on user language, e.g. it's Monday in Polish and Sunday in English. https://phabricator.wikimedia.org/source/mediawiki/browse/master/resources/src/mediawiki.widgets/mw.widgets.CalendarWidget.js$186

The logic for this comes from the Moment.js library. It allows you to customize this: https://momentjs.com/docs/#/customization/dow-doy/ but I'm not sure what's a good way to do that without hacking up MediaWiki's files.

Also, if it's an acceptable option for you, apparently the en-gb locale is also using Monday as the first day of the week.

@Matma Rex - okay, thank you, that's good to know - both in general and about the en-gb "hack".

Wdgets implemented with OOUI, such as the new recent changes widget and its filters, are painful to style for wiki admins who maintain a custom theme but only have interface admin access. As far as I understand, the "correct" method for styling OOUI is described in OOUI/Themes and would require access to the server. I haven't studied this method of styling OOUI since it is of no use to me, but I assume it would be better than using MediaWiki interface message pages to override the default style.

By "painful" I mean several things, compared to modifying the core mediawiki CSS:

• OOUI has far greater number of CSS rules than the entire core MediaWiki + skin!
• Styling comparable wiki interface elements (in mw-ui, I believe) before OOUI was doable with a few simple CSS rules
  • Now the same level of interface skinning takes hundreds of high-specificity CSS rules
• Redoing all the images takes a lot of work
  • Also requires questionable hosting choices or embedding into CSS as data-URIs. (Again, for wiki content admins with no access to the server)
• The selectors are long with high specificity
  • Resulting in barely human-readable CSS
  • No easy way to style larger groups of elements at once (simplifying the style and selectors)
• OOUI, especially when partially reskinned through MediaWiki interface pages, has measurable impact on page loading speed on slower end-user hardware.
  • The reskinned OOUI is loaded on every page load, and the full original OOUI CSS is also loaded when needed.

I don't know how common my position is (MediaWiki content admin also maintaining custom skin w/o direct server access) and I don't know the backend well enough to suggest a solution. Perhaps OOUI stylesheets could be moved to MediaWiki interface messages to at least allow ResourceLoader could handle it better in cases like this? In any case, the seperation of interface widget style from the rest of the skin seems counterproductive.

In my opinion OOUI styles are also too complex for what they do and could be greatly simplified with minimal loss of features, but I understand there may be use cases that require such a heavy interface library. OOUI definitely is on a different level than the rest of MediaWiki styling, for good or for bad.