There are various actions and values that access displayables
in the current screen. Some of these might be run (for example,
BarValue.get_adjustment()) in a hiding or old(-state-of-transition)
screen.
Almost certainly, those values and actions want the displayables
that are present in the original screen, not the copy, and so
the value is redirected.
Fixes#3998.
This simplifies many cases where a page has a ref identifier distinct
from its filename, which makes linking harder to understand when writing
the doc.
Also, it solves a small scrolling problem in such cases.
Some links in changelog and changelog6 were left alone, and some .. _
identifiers too, to ensure compatibility.
* Remove python creation of screens from the doc
* doc: Undocument various ui functions and renpy.define_screen
* doc: Move and rephrase renpy.predicting's documentation
* Clarify renpy.variant
and remove reference to screen creation and style setup
* doc: Remove unnecessary interstitial addition
* Changelog the removal of python screen creation
At most one InputValue can be focused at a time. This is enforced
by Ren'Py, and can be used along with buttons to handle switching
between multiple Inputs.
This is similar to a bar value, except it's taken by an input,
rather than a bar. An input value has:
* A method that returns a default value for the input.
* A method that is called when the input text changes.
* A method that is called when the user presses enter.
* A method that's called to determine if the input should be
considered editable.
InputValue objects also have methods that return actions that
enable, disable, and toggle editing.
This function was previously exposed as renpy.run_action. It's now
properly documented and exposed as renpy.run, with the old name
left around as an alias.