This is not great, but it's a start (and unblocks other pull-throughs).
New changes:
c401efc98 build: Replace jsduck with jsdoc for documentation
16ba162a0 JSDoc: @mixins -> @mixes
9e0a1f53b JSDoc: Fix complex return types
449b6cc0f Prefer arrow function callbacks
1539af2c8 Remove 'this' bindings in arrow functions
b760f3b14 Use arrow functions in OO.ui.Process steps
57c24109e Use arrow functions in jQuery callbacks
9622ccef9 Convert some remaining functions callbacks to arrow functions
f6c885021 Remove useless local variable
1cd800020 Clear branch node cache when rebuilding tree
Bug: T250843
Bug: T363329
Change-Id: I0f4878ca84b95e3f388b358b943f105637e455f9
I'm pretty sure this extra call is just pointless. This "choose"
event is triggered every time a new parameter is added to the list of
parameters. But there is another code path that is triggered in the
exact same situations: the onReplacePart event handler.
As far as I remember this "choose" handler was added very early when
the other events haven't been implemented yet.
This should be fairly easy to test. The only situation where this
could make a difference is:
1. When you have a template with 3 parameters and you add a 4th
parameter.
2. When you edit an existing multi-part transclusion that contains a
lot of parameters, but the parameters are initially hidden. The
widgets are only created when you click "show all" or start
searching.
Change-Id: I59e3873a4fe6fa5a01d681fce89fbe00756ae815
In Iebfe2e2 we already tweaked this by 1px. Turns out this was not
enough in all relevant situations. I still get random scroll events
just because I move the mouse around. Setting: Firefox, 120% zoom,
multi-part transclusion.
Bug: T312926
Change-Id: I475c1ef029e9721cc663881e40547730389cd26d
* Rename method because it turns out it is not only about the sticky
header, but also relevant when there is no header.
* Move some code to more appropriate places.
* Use 0 as documented in OOUI, not null.
* Set the padding back to 0 when the sticky header is not visible.
As of now this is an unreachable state because the filters never go
away after they have been made visible. Still this code was always
written with this possibility in mind to make it future-proof.
* Performance optimization for the boolean "show filters?" check.
Bug: T312926
Change-Id: Iaba08ccd8bf00360fd26f9268d5be43df4f4fbd8
This is a partial revert of Ide45141. Now the scrolling always
happens (again), but properly considers the presence of the sticky
header. It was also not correctly initialized on construction time.
This is a candidate for a backport. The patch is intentionally as
small as possible because of this. Code cleanup will be done in a
later patch.
Bug: T312926
Change-Id: I06425b42566bfb2087846636055ee75e98a05029
The message was also shown when a documented template appears as
part of a multi-part transclusion but with zero parameters being
used. You see the filters in this case and can click "show all".
The message is just wrong in this situation.
Bug: T312926
Change-Id: I8d26ceec483e05fd1f69013e506fa1eb4e4c29ed
The main motivation is to get rid of the vague method name
"setParameter" that was previously used for three different methods
in three different classes. Now the three methods have three
different names.
Change-Id: I938de30b368daf6ce3385b2ed2bca98f316593e1
This also means we have to move the declaration/documentation of the
event up one level into the generic "part" widget.
Change-Id: I1b803201f8955b58136ee7f37c04c01edcd47395
The code that receives this event does not need to know that the
source is a "parameter". It's just some "item" in the sidebar. The
idea is to reuse the event for both top-level parts as well as
parameters. This will be done in the next patch.
Change-Id: I858040f5adf8e156b6013caaa527b3237b7bac0f
Fix setParameter() and let it (un)highlight parameters independent
from a selection (called "set" here).
Bug: T312925
Change-Id: Ie4e9ba94659f4f70160193ca6bec804f8a4473e4
This is not only fired when a parameter is added. It's also fired
when pressing spacebar on a parameter that already exists.
Change-Id: I245aa9f5938eb38c3a3f224a4d642d57068cf23b
This is not only fired when a parameter is checked or unchecked.
It's also not only fired when another parameter in the parameter
SelectWidget is selected. It's always fired just because the
spacebar is pressed. This is so we can scroll that parameter into
view.
Change-Id: Id621405b7ca3116cd4a06f474e49776d0830dccc
Triggers scroll in all situations where highlighting changes.
Including keyboard navigation.
Bug: T312542
Change-Id: I849f64c5cefe0cac3fde6e848b23b7b0cfc489ce
Introducing a set method to have a different state for a set
parameter and a highlighted one in the selection.
Allows us to remove a lot of workarounds for missusing the
highlight state and fixes several issues with these workarounds.
Main implications:
- Keyboard navigation and mouse hover now sets the grey highlight
- If a parameter is set (blue highlight) keyboard navigation returns
when focusing the SelectWidget
- If nothing is set keyboard navigation starts at the top after focus
- Unchecking a parameter using space will not influence the keyboard
focus in the list
- Highlighting a parameter with the mouse lets keyboard navigation
continue from there.
Bug: T312647
Bug: T311204
Bug: T312213
Depends-On: I385dca1d95033961d3844e888521750443e49c95
Change-Id: Iaf089f4b271fd853b17c1aa7f5938510ea8f5431
This prevents an invisible and unactionable focus target when the
parameter search field doesn't match anything.
Bug: T312547
Change-Id: Ib29913a547cd68649d29e28d921c4c1358bad7b8
New sidebar events take a `soft` parameter allowing reuse between
"hard" and "soft" selection and parameter add. The "hard" variant
causes a content-pane focus.
Bug: T311987
Change-Id: Ic49718840ae56eb4cfab01ce964a2fbc2d8db63b
Value changes are triggerd and tracked from the parameter page and
change events will be forwared to the outline, if they are relevant.
Initial value is read from the model.
Bug: T308730
Change-Id: I0a3b0faf40aee44889404dcce31d850714360580
Removing a class name that's going to be deleted from places where
it's not strictly needed, e.g. comments.
Bug: T307188
Change-Id: Ifb14695d05510d2c0e25623afa99c4e84af3aaf9
Will be removed when parameters are added. Needs different margins
depending on beeing shown in the single transclusion mode without
header or on multiple transclusions.
Bug: T300710
Change-Id: Ieb95d7276aa4d4b0fcbb74f87ab734e4a393dc21
We ended mixing two concepts in a single method:
* We need a method that allows us to create the parameter list widget
when it's needed, even if it's empty. This is relevant when a template
is entirely empty, and the first parameter is added. This wasn't
working. Instead the parameter list was created with all parameters.
* On initialization we either want all parameters to be shown, or only
used ones. But this code is only needed once, on initialization. I
ended inlining this code in this patch.
Bug: T300640
Bug: T304046
Change-Id: I6620a870e4420dcb8fecf522b3274458eeec891d
Due to the stickyness we need to scroll the header and the first
visible item from the parameter list to have the best result in all
cases.
We also only want to scroll when the user triggered hiding the
fields. Not when the template outline view is initialized.
Bug: T302965
Change-Id: I84d293888a7dbf13ec655c293c0fc3a79edca698
In a test case with 200 templates where all but a few parameters are
unused the loading time is cut in half.
Bug: T300974
Change-Id: Ice850cb9e5e95b9e3a19ff511b3a4f32117c7199
These are only needed when we need to access a specific `this` from
within another `function () {}` context. This is not the case in the
situations here.
This is split from Ibf25d7e to make it smaller and easier to argue
about.
Change-Id: Ide1476de91fc343aa992ad92a1321d3a38b06dd0
I bit more logic was needed to make sure, the state of the widget
resets when all unused fields are added during search.
Bug: T299811
Change-Id: I3006c233fda5490e323bc3a3e631bf0c1199bda3
Covers the base functionality to hide the parameters. Performance
optimizations could be done in a follow up.
Bug: T300640
Change-Id: Ia99b5da392273f1445e475a0720a656460612dcf
The search field is of not much use when there is not really anything
to search. It wastes more space than the actual list of parameters.
Approved by UX, see T298259#7626538.
Bug: T298259
Change-Id: I01784a1c463d8b0b504897b20179719f91597d19
From the user's perspective nothing changes. A template without
parameters doesn't show anything. (Technically there was an empty
<div>, but it doesn't do anything.) The moment the first parameter
is added the required sub-widget is created and available from there
on.
This saves loading time and memory, especially when a multi-part
template contains many templates without parameters.
Bug: T298259
Change-Id: Ib1bd2cd0be4fece4acc92e6e5f63133a7986cf81
From the user's perspective this is the same as before: When a
template doesn't have any parameters, there is no search field. The
moment the first (undocumented) parameter is added the search field
appears.
This is just delayed now. The widgets are only created the moment
they are actually needed.
This saves loading time and memory, especially in a multi-part
transclusion with many zero-parameter templates.
This also makes it a lot easier to change the minimal number of
parameters from 1 to e.g. 4.
Includes reverting the flexible header composition done in
Ib050e30a50ef965c1524e977d3a600c3ff836774
Bug: T298259
Change-Id: Ied7541d8d5c0b478a439dd31ce072e634287f181
The search field will stay at the top of the window while scrolling a
single template. In multi-part transclusions, the header will also
be sticky.
Hides the template header in single-part transclusions.
Bug: T298618
Change-Id: Ib050e30a50ef965c1524e977d3a600c3ff836774
