ve.dm.Scalable is now a computational model for image scaling and
size manipulation. This commit adjusts the nodes and the edit and
insertion dialog to handle the new scalable model, and by that
use a centralized computational engine for all scaling and size
changes.
New changes:
3ec19fb8 Refactor Scalable functionality
Change-Id: I017a017924f544cc8bc9b7d8245335759ae0e890
Objectives:
* Allow users on-wiki to create tools and dialogs for citation templates
of their choosing
* Allow editing of citation templates directly, without having to go
through the reference dialog
* Provide citation template tools within reference editing that use the
same titles and icons as the citation tools do, but don't wrap the
inserted content in a ref tag
Changes:
* Reference list was cloning the DOM element it was inserting into its
view before the generated content node could finish rendering, so it
never ended up showing the finished rendering in the reference list
* Documenting hack about use of reference list node's destroy method,
and how we are depending on destroy not canceling generated content
rendering
* Introduced reference model
* Added saving/updating method to transclusion model
* Added getPartsList method to dm transclusion node, which caches the
result and invalidates the cache on update
* Added citation dialog, which extends transclusion dialog
* Added cite group to toolbars, cite-template in reference dialog toolbar
* Factored out getting the node to edit and saving changes procedures in
transclusion dialog so they could be extended in citation dialog
* Updated uses of autoAdd as per changes in oojs-ui (Ic353f91)
* Renamed MWDialogTool file since there was only one tool in it
* Expanded TransclusionDialogTool file out since there is now more logic
to it
* Switched to using ve.dm.MWReferenceModel instead of plain objects in
reference search widget
Configuration:
If you add to MediaWiki:Visualeditor-cite-tool-definition.json the
following code you will magically be presented with a delightful array
of citation options:
[
{ "name": "web", "icon": "ref-cite-web", "template": "Cite web" },
{ "name": "book", "icon": "ref-cite-book", "template": "Cite book" },
{ "name": "news", "icon": "ref-cite-news", "template": "Cite news" },
{ "name": "journal", "icon": "ref-cite-journal", "template": "Cite journal" }
]
...or...
[
{
"name": "any-name",
"icon": "any-ooui-icon",
"template": "Any template",
"title": "Any title text"
}
]
The title text is derived either from the title property or from the name
property by pre-pending the string 'visualeditor-cite-tool-name-' to
generate a message key. Titles for 'web', 'book', 'news' and 'journal' are
provided. The icon is a normal oo-ui-icon name, and more icons can be
added, as usual, by adding a class called .oo-ui-icon-{icon name} to
MediaWiki:Common.css. 'ref-cite-web', 'ref-cite-book', 'ref-cite-news'
and 'ref-cite-journal' are provided. The template name is simply the name
of the template without its namespace prefix.
Depends on Ic353f91 in oojs-ui
Bug: 50110
Bug: 50768
Change-Id: Id401d973b8d5fe2faec481cc777c17a24fd19dd4
TOC Widget is created in the mw target view class.
Adding and removing a heading rebuilds the TOC Widget based
on the the order of the page heading nodes.
TOC Widget considers TOC page settings and displays in the default manor
unless forced or disabled.
TOC Widget still needs to be finalized by being placed in the surface.
This could be a problem until we have a CE node for it to live in or
have some DM work added. Roan and I have discussed how to go forward.
To enable the widget you must add the following to LocalSettings.php:
$wgVisualEditorEnableTocWidget = true;
Change-Id: I488cfbbdb060e50d81f51e0f757e67d0114b8936
Make sure the magnify button in the caption is properly shown or
hidden when image type changes. The magnify icon will always be
built, but will be shown and hidden using CSS rules.
Bug: 62139
Change-Id: Ib9a4569239ed70d16a153fb0823e283203fba1d4
There are several conditions to defaultSize behavior of thumbnails and
frameless images and other images when it comes to default size. In the
same principle is 'border' which is not quite a type despite the fact
it 'behaves' as such in wikitext (and has a unique identifier that comes
instead of the other types.
This commit aims to organize this behavior for the user in an
understandable manner.
* Add 'basic' image type for images that have no specified type ('none')
* Handle the difference in 'default' size behavior between basic images
and thumbnails/frameless. The thumb/frameless images have the default
wiki size. Other images' default size is their original dimensions.
* Force wiki-configured default size for thumbnails and frameless images
in the DM. This is done because at the moment Parsoid's output is of
Wikipedia's default size rather than the local wiki's. The size is
adapted if needed, directly in the DM.
* Added 'border' as a pseudo-type checkbox flag that sets css class
'mw-image-border' is for parsoid rendering on save.
* Add 'make full size' to the size widget select and treat it as a faux
default button for basic and frame images.
Bug: 62013
Bug: 62024
Bug: 61155
Bug: 61059
Bug: 61282
Change-Id: I6778705306f0dd6bb96afeb91383089a4ddab7ed
This commit makes several adjustments to make sure default size is being
handled correctly:
* Add wiki's default size configuration parameter to the
VisualEditor.hooks.php file so it can be called from VE.
* Make sure new images are inserted with default size and are
marked 'defaultSize = true' for the DM to handle.
* Force default size if 'defaultSize=true' in the DM
* Add a 'default|custom' switch to the media edit dialog for size
inputs. When 'default' is chosen, the media size widget will be
emptied, displaying its placeholders (default size)
* When the size widget's values are 0 it will automatically turn to
default size values. If the value started default and the user
typed in a size, it will automatically override default and use
custom size.
Bug: 47804
Change-Id: Ib973ea2afa96090a4ba61b2b55ee63457f1329c1
Adding a type change to the media edit dialog. Also changing SelectWidgets
to ButtonSelectWidgets for consistency.
Bug: 38129
Change-Id: I9c855e6381d970b5f08460822366f6333af24f82
wgSVGMaxSize sets the maximum size for the shortest edge of a
vector image. Pass this through to MWImageNodes.
Change-Id: I6410e7cda137cf4828d12280cb1e5cfc27805859
Implement new logic in ve.Scalable from I5b4f0f91b.
Also update VE core submodule to master (57ed8d3).
New changes:
59a0afe The great image scaling rewrite of 2014
Change-Id: I24a2976036310d3814cc7d1853a68745e0499bd5
Adding the ability to edit image size in the media edit dialog.
The size is now a separate widget.
The following changes were made:
* The dialog was changed to a booklet with 'general settings' and
'advanced settings', in preparation for other edit features.
* The original image maximum size is fetched from the API and cached.
* Maximum size is limited to the image's original maximum size.
* Aspect ratio is kept when changing height or width, using original
image size to preserve a sane ratio through the MediaSizeWidget.
* If an error is found in the size, the image will retain its previously
set dimensions.
Depends on MediaSizeWidget: I3d0f9348a52
Bug: 38129
Change-Id: I2946fb21c46ce05583b219f665ef68928188899e
For block images, show the bottom left/right anchor if the image
is right/left aligned, and both if it is centred.
For inline images, show the bottom right anchor unless the page is
RTL.
Change-Id: Icb5b74b954493257c517a5fbac5f0a0a457c544c
This fixes the issue where parsing HTML that started with
a text node would cause that first text node to be dropped.
Change-Id: I71dafd69e12cab50e6644b4817f0fd6105657216
MWBlockImage
* Remove properties which just cache model properties. We can get
fresh values from the model whenever needed and this just causes
problems keeping them in sync.
* Tidy up DOM documentation indentation
* Merge setupCaption and setCaptionVisible into updateCaption. The
caption's visibility can be calculated inside the method from
model attributes.
* No need to generate figcaption on init, updateCaption will do
this for us
* Storing full view and model in this.caption is unnecessary,
just store this.$caption (view.$element) and this.captionVisible
* Append the caption directly to the figure now there is no container
* Simplify setCaptionVisible
* Add in fix to account for border to figure width
* updateSize can get values from the model if they are not provided
* Remove unnecessary styles being set on this.$element.
MWImageCaption
* Generate as a figcaption instead of a div for direct attachment
MWImage
* Missing docs
CSS
* Cleanup reset styles, remove redundant add in required
* Fix margins for left/right floats to match .tleft/.tright
* Use more specific selector for inner border (thumbimage) to avoid
matching shields.
* Remove unnecessary frameless styles, it has no border by default.
Change-Id: I52e0e10b465bb9761c2e4be28c98bec37b0dd2ca
Also make available as a static method so it can be used by the
converter. We will need this for generated HTML for the external
clipboard.
Change-Id: Ief843ac10cd6c6e4b25e09a007625d363792adff
If you've just pasted in a reference and a list the internal list
nodes may not have been rebuilt yet.
Bug: 58242
Change-Id: Ib10b81f4023194791f789f3e7dda393f2e355ea3
Adding @noflip to align-left and align-right in the <figure> css styling
rules and removing the need to resize the Branch Node div element on center.
Change-Id: Iec6e589ba9ecdf32c1a0934b9eb05ee3fd42af66
This change is meant to transform the current block image node rendering
in ContentEditable from the nested <div> structure to a <figure> tag more
closely matching Parsoid's output, with CSS to style it the same. This is
mostly so we can work with and display attribute changes, like 'type' and
'alignment', without constantly destroying and rebuilding nested <div>
structures.
This change also includes all the attribute changes that will be called
when the media edit dialog changes image type, alignment, size, etc.
Node: The mw-classes 'thumb', 'thumbinner' and 'thumbcaption' are
preserved in the structure of the <figure> but CSS designers should note
these styles are no longer necessarily attached to <div> elements.
Bug: 53436
Change-Id: I40065acd9fd59d30f94b5336736d4986e8de15aa
Let's experiment with this via our local Gruntfile. If it works
fine we can install it in Jenkins (similar to node-csslint).
Verify through $ npm install && npm test;
Fixed all outstanding violations.
Also:
* Added syntaxhighight to ignore.
* Added imetests (which contain unformatted JSON) to ignore.
* In ve.dm.ModelRegistry#matchTypeRegExps, removed redundant
!! cast from the [+!!withFunc] statement which was hitting
a bug in node-jscs. All callers to this local private function
pass a literal boolean true/false so no need to cast it.
* Removed "/* key .. , value */" from ve.setProp, though this
wasn't caught by node-jscs, found it when searching for " , ".
* Made npm.devDependencies fixed instead of using tilde-ranges.
This too often leads to strange bugs or sudden changes. Fixed
them at the version they were currently ranging to.
Bug: 54218
Change-Id: Ib2630806f3946874c8b01e58cf171df83a28da29
MW extensions are XML not HTML, so we shouldn't build them as XML
to prevent HTML specific rules being applied, such as <source>
always being self closing.
Bug: 54577
Change-Id: I84af4a29cd1c4ae4d1db4f70a4012a8ad0f98bf6
We had CSS that applied to our rendering of autonumbered links,
but not for raw <a rel="mw:ExtLink"></a> tags appearing in
generated content like templates.
Bug: 57420
Change-Id: Ic1585ecb1a133d16b7393ce0ce38a11b76cc2239
As of 46f40dc, we've split the VisualEditor API backend and the
part containing the parsefragment method no longer needs
an edit token.
This gets rid of the warning that started appearing after 46f40dc:
{
"warnings":{"main":{"*":"Unrecognized parameter: 'token'"}},
"visualeditor":{"result":"success","content":"<p>foo\n</p>"}
}
Change-Id: I36f79fa8ae48cdbec1b3506953418561ef2ff828
Objectives:
* Rename this.$ to this.$element
* Rename this.$$ to this.$
* Get rid of the need to use this.frame.$$
* Rename OO.ui.Element.get$$ to OO.ui.Element.getJQuery
Changes: (using Sublime Text regex patterns)
* Replace "get$$" with "getJQuery"
* Replace "\.(\$)([^\$a-zA-Z])" with ".$element$2"
* Replace "\.(\$\$)" with ".$"
* Replace "'$$'" with "'$'"
* Set this.$ to null in constructor of OO.ui.Window
* Set this.$ to this.frame.$ in initialize method of OO.ui.Window
* Replace "\.(frame.\$)([^\$a-zA-Z])" with ".\$$2"
Bonus:
* Use this.$() in a bunch of places where $() was erroneously used
Change-Id: If3d870124ab8d10f8223532cda95c2b2b075db94
Objectives:
* Hamburger menu in actions area of toolbar
* Add tools that open specific pages in the meta dialog
* Fix support for using setPage in ve.ui.PagedOutlineLayout
* Allow passing setup config objects through window open calls
* Add dialog action, similar to inspector action
* Fix incorrect or missing documentation
Change-Id: I2d2c9b87554fb2a0c90ed6944a58b38a37efa712
* changes:
Get rid of dmRendering hack in ve.ce.MWInternalLinkAnnotation
Render resolved URLs for href and src attributes in CE
Give ce.Annotations a reference to their ce.ContentBranchNode
Track the original HTMLDocument in ve.dm.Document
Create CE nodes and annotations with the correct $$
Add ve.resolveUrl for URL resolution
Don't render href as src in MWBlockImageNode
Rename 'html' to 'body' in converter tests
URLs are resolved according to the <base> URL from the Parsoid DOM.
For instance, a link can have its href set to '../Foo' in the DM, and
the target will show up as '../Foo' in the link inspector, but the CE
rendering will be <a href="http://localhost/Foo"> (assuming Parsoid sent
<base href="http://localhost/wiki/Bar">).
Bug: 48915
Change-Id: I919135eb758c82361525078f276ca193dc4c4820
Instead of using @emits in both, use our custom @fires in
production (JSDuck 4), and in the future it'll just naturally
use the native one.
This way we can also index oojs without issues, which seems to
have started using @fires already.
Change-Id: I7c3b56dd112626d57fa87ab995d205fb782a0149
Since I0f0a826c in Parsoid, numbered external links are now empty
<a rel="mw:ExtLink"></a> tags. This means we have to put in a node type
for them to prevent them from being considered empty annotations and
getting converted to alienMeta.
MWNumberedExternalLinkNode is protected and focusable to avoid making
the link text (which isn't editable) clickable. It isn't inspectable
yet, we need to work on that.
Bug: 53505
Change-Id: I83f69695f3974089e51a84e799f31ab6ed879e05
