Objectives:
* Got rid of mw prefixing in tools, inspectors and dialogs
* Simplify tool classes so they can be generically used as items in bars, lists and menus
* Add support for a catch-all toolbar group
* Simplify tool registration, leaning on tool classes' static name property
* Move default commands to command registry
* Move default triggers to trigger registry
* Get language tool working in standalone
Change-Id: Ic97a636f9a193374728629931b6702bee1b3416a
And actually use this functionality on MWBlockImage to
highlight centred images correctly.
FocusableNode
* Actually use $focusable to render the highlight correctly
ProtectedNode
* Allow a $phantomable element to define which element to
highlight on mouseenter
* As phatoms are built off shields, make sure a shield is
given to $phantomable
RelocatableNode
* Allow a $relocatable element to define which element the
relocatable marker is measured against
ui.Context
* Use $focusable (when available) for positioning the popup
Plus some documentation fixes
Change-Id: I370337239af4fc935cd86757b3ce03011bae5ba8
When a link was inserted, the cursor position was backwards (at the
beginning of the word rather than its end) - this commit fixes that
problem.
Also, thanks for the help Ed!
Bug: 53560
Change-Id: I04fe1ca4c9126898e7bf85cdf519794d66b4f38b
The inspector popup should appear relative to the position of the related
calling method - either relative to the cursor (like in links and language)
or relative to the focusableNode (like in templates/transclusion).
Bug: 50905
Change-Id: I07f58d0c6561adecbec560fc24bcb6e590f2cd9f
This commit fixes two issues with insertion of annotations in blank space:
* LanguageInspector issue with inserting an language annotation inside any
whitespace (selection of space between words or collapsed selection in
blank line)
* AnnotationInspector issue with collapsed selection inside slugs. If
the marker was in a slug collapsed selection, activating
AnnotationInspector would expand the range to the closest word (on the
next paragraph). This commit makes sure the expansion for the next word
only happens if the selection is outside a slug.
Change-Id: I144eccefba16131a3d2ec6a3181adf47a15d6cc0
This listens to change events on the surface and checks to see if
there is more than just an empty paragraph node.
Bug: 53345
Change-Id: Ic8fa84d7cdcbffd154178939d0ec8c2c4f86c415
Objectives:
* Make it possible to add items to toolbars without having to have all
toolbars know about the items in advance
* Make it possible to specialize an existing tool and have it be used
instead of the base implementation
Approach:
* Tools are named using a path-style category/id/ext system, making them
selectable, the latter component being used to differentiate extended
tools from their base classes, but is ignored during selection
* Toolbars have ToolGroups, which include or exclude tools by category or
category/id, and order them by promoting and demoting selections of
tools by category or category/id
Future:
* Add a way to place available but not yet placed tools in an "overflow"
group
* Add a mode to ToolGroup to make the tools a multi-column drop-down style
list with labels so tools with less obvious icons are easier to identify
- and probably use this as the overflow group
Change-Id: I7625f861435a99ce3d7a2b1ece9731aaab1776f8
Return an array of languages instead of a single language. Languages
containing hyphens return themselves along with the root code e.g.
'en-GB' => ['en-GB', 'en']
Change-Id: I840b689d0021d865f93d16d075473a2ed0a9f0d8
Problem: When the toolbar is created twice with the same config object,
the second time around the tools are still bound to the old surface
Reason: The tool config is overwritten such that symbolic names of tools
are replaced with instances of tools, bound to a specific surface. The
second time around, the creation fails (silently in a try-catch) and then
the already translated list of tools is used to create a new toolbar
filled with old tools still bound to the wrong surface.
Solution: Leave the config object alone, and instead build a new list of
tool instances while iterating through tool names.
Bonus: Don't fail silently. Using a try-catch to detect whether a
requested tool is supported masks other errors, and is evil. Instead,
just do a lookup and skip tools in which the lookup's result is falsey.
Change-Id: Ic43ec29173e556592bb3db9399ff83787e0a6857
This commit prepares the LanguageInputWidget to handle both annotation
and node, so it can be used as the GUI for both the LanguageInspector
and the LanguageBlockInspector that's coming up.
Cleaned up the way annotations are read into LanguageInspector and
AnnotationInspector. The attributes are kept in the Widget (without regard
to what datamodel they will serve) and are then read from the inspector.
The LinkInspector had to be adjusted slightly to accomodate a small change
in the AnnotationInspector too.
Change-Id: I17954707c00ffc4c32fbb44a6807a61760ad573c
Previously we assumed that embedded icons mean we weren't
dealing with an inspector, but that is not always the case
(e.g. MWExtensionInspector).
Bug: 52845
Change-Id: Ifc5b054568661cb9badf6d7991f512b81e649b36
Roan and I think this is way too light. The only way
I can tell it's a group is by mousing over all of
the icons back and forth really quickly :)
Increasing to 10% alpha.
Change-Id: Iab55bf64921de5247d10d611318e545efe74fe4a
Objectives:
* Use a class for toolbar groups to add more functionality later
* Rename addTools method to setup
Changes:
*.php
* Add link to new file
* Move ui element classes up for more general use
ve.init.mw.ViewPageTarget.js, ve.init.sa.Target.js, ve.ui.Context.js,
ve.ui.SurfaceWidget.js
* Update use of addTools method
ve.ui.Tool.css, ve.ui.Toolbar.css
* Move styles between sheets
ve.ui.Toolbar.js
* Rename addTools to setup
* Use ve.ui.ToolGroup objects when building tools
ve.ui.ToolGroup.js
* New class, encapsulates tools
Change-Id: Ic3a643634a80a8ac7d6f6f47f031d001c7efaee7
Objectives:
* Make drop down tools look more like buttons and less like inputs, since they aren't text input and are buttons
* Make context toolbars inside surface widgets render correctly
* Show outlines of groups on hover to hint tool relationships
* Make neighboring active tools look cleaner
Changes:
ve.ui.Tool.css
* Merge ButtonTool and DropdownTool styles as much as possible
* Add styles for DropdownTool active states
* Only round the corners of the first and last tool in a group
* Soften the borders between consecutive active tools
ve.ui.Toolbar.css
* Add border to groups on hover
ve.ui.Widget.css
* Isolate surface widget toolbar styles by using stricter selector
ve.ui.Tool.js
* Fix incorrect capitalization of class name
ve.ui.SurfaceWidget.js
* Add classes to toolbar and surface for better style targeting
Change-Id: Ib5ae8f705ef1e9c481e5bdf8c8dcef9c1eb22c4d
Objective:
* Remove ve.ui.DropdownTool's dependency on ve.ui.SurfaceToolbar so it
can be used with any ve.ui.Toolbar
Changes:
ve.ui.DropdownTool.js
* Bind onBlur to document mousedown in capture mode instead of trying to
add more and more things we are listening to which is a losing battle
* Refactor activate/deactivate mode changes
* Get rid of isEnabled check - surface should disable toolbar, the tools
shouldn't be checking if the surface is enabled after the fact (also,
this is harmless and doesn't change any actual interactions)
Change-Id: I738209d17649358c2f9812f9abac576960af867b
Objective:
* Make it possible to make a toolbar without a surface
Changes:
*.php
* Links to new file
ve.ui.Toolbar.js, ve.ui.SurfaceToolbar.js
* Split toolbar into generic and surface specific classes
*.js
* Update symbol names
Change-Id: Ice063a2fb67b5ce5155cdc96a0d47af49eee48cb
Code speaks for itself, see also bug 52441.
Though not introduced by 14343c7bf7, that made the bug worse.
Bug: 52441
Change-Id: Ie2b80b22df03eb563de8812a47fb25152527e786
For configured wikis, show a dialog that welcomes the user to the
amazing and fantabulous world of VisualEditing, which is not only full of
wonderment and joy but also may lead to increased popularity and love.
The dialog only shows up once (uses a cookie).
Change-Id: I8e7c4dc2c63b36594378a543b9d66291395eebcf
By testing against a regex of legal title characters we can determine
if the entered text is a valid internal link. If it isn't we should
prevent the link inpsector from creating/changing the annotation.
Bug: 33094
Change-Id: Ia1df602601e4e82fc351279e432c28c425f5157a
Not having a description yet is fine, but they should at least
be indexed as blocks so that they are searchable and listed
in the jsduck generated pages. jsduck defaults to @method + name
of prototype property. And it even guesses parameters sometimes.
Search: \n\n([a-zA-Z\.]+\.prototype\.[a-zA-Z]+)
Where: modules/ve,modules/ve-mw
Where-Not: modules/ve/test
Replace: \n\n/** */\n$1
Added @return in a few places where it was easy to add.
Change-Id: I830c94cc7dbc261bd7a077391f930cbfff165f9d
