Commit graph

8 commits

Author SHA1 Message Date
Trevor Parscal d2dfb9ac4f Split oojs-ui from ve.ui
* Move and rename generic parts of ve.ui to OO.ui
* We now have a UI test suite because ve.Element (outside ve.ui)
  is now part of oojs-ui, so it needs a test suite.
* Added to the MW test run (just like we do for unicodejs).
* Updated csslint config (also added ve-mw and syntaxhighlight
  which were missing).

oojs-ui still depends on the TriggerRegistry in VE, this is addressed
in a follow-up commit.

Change-Id: Iec147155c1ddf20b73a4d15d87b8742207032312
2013-10-28 22:40:08 -07:00
Trevor Parscal efafed3231 Remove ve.{inheritClass,mixinClass} and use OO instead
Change-Id: I8df9226a358a76b661eab6e967ff0d63d361f691
2013-10-18 18:58:08 +02:00
Ed Sanders e6f48c5c93 'Config' -> 'Configuration' in all comments
Because the former isn't a real word.

Change-Id: Ie6ed15f9e390b357bbaa768b57f3c3fd7cf21181
2013-09-25 11:23:16 +01:00
Trevor Parscal 2717ea1645 Add ve.ui.ToolGroup and use within toolbar setup
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
2013-08-07 05:08:20 +00:00
Trevor Parscal 9426dfd54b Cleanup tool styles
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
2013-08-07 05:08:08 +00:00
Trevor Parscal a226716d70 Split ve.ui.Toolbar and ve.ui.SurfaceToolbar
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
2013-08-02 14:33:25 -07:00
Timo Tijhof 14343c7bf7 ve.ui.Toolbar: Refactor floating logic for performance
== Renamed methods ==

* enableFloating  -> enableFloatable
* disableFloating -> disableFloatable
* setPosition     -> float
* resetPosition   -> unfloat

== Scroll and resize event ==

Timeline for scroll event reduced from about half a dozen
"Recalculate style" and various forced "Paint" down to 0.

New timeline for scroll is clean (for me: from ~35 to ~59 fps):
* 1 Event (scroll)
* 1 Composite Layer

The composite layer action is the browser changing the viewport
to a different portion of the document drawing. Exactly the one
thing a simple scroll should do.

Timeline for resize event is still pretty crowded and low fps,
but it has improved. Further improvement would likely be around
using requestAnimation and going outside ve.ui.Toolbar.

== Changes ==

* New: ve.ui.Toolbar#initialize.
  Similar to what surface has. Users of Toolbar should decide
  whether to call enableFloatable, append it to the DOM at some
  point and then call initialize() once.

* Don't compute offset() every time.
  Eliminated by doing it once in #initialize. These 'top' and
  'left' offsets do not change.

* Don't compute outerWidth() and $window.width() every time.
  Reduced by doing it once in #initialize to compute the 'right'
  offset. Updating it only on resize.

* Don't set 'top' every time.
  This is already in the stylesheet. It was never set to anything
  else so the abstraction for it in #float has been removed.
  This also made it obvious that code for "ve-ui-toolbar-bottom"
  was unused and left behind. Tha class was only ever being
  removed from something (never added).
  The one addClass call for it was in a condition that is always
  false ("if top > 0").

* Don't set 'left' every time.
  Eliminated by doing it once in #float.

* Don't set 'right' every time.
  Reduced by no longer doing it on scroll. Done once in #float,
  and on resize after computing the new value for it.

* Remove no-op style operations.
  Wrapped methods in if-floatable, if-floated etc. to reduce a
  fair amount of easily avoided re-paint overhead.

* Avoid double re-paint in mw.ViewPageTarget.
  Though we prevent a lot of redundant re-paints now, whenever
  we do repaint we want to do it in 1 repaint instead of 2.

  ve.ui.Toolbar emits #toolbarPosition, which tells
  mw.ViewPageTarget to update toolbarTracker which would read
  the new $bar style properties and copy them over to the
  $toolbarTracker. However, this read operation forces the browser
  to do an immediate re-paint half-way just for $bar.

  Browsers only repaint when style properties are changed and
  JS has yielded. The exception to this is JS reading style
  properties: in that case the browser is forced to do those
  deferred repaints directly and reflect the new values.

  We can avoid this double repaint by passing the updated values
  as data instead of requiring the receiver to read the DOM (and
  thus a keep the deferred repaint). Now toolbarTracker can use
  them directly whilst the browser hasn't even repainted $bar yet.

== Clean up ==

* Redundant "border-radius: 0". This would reset something, but
  it never does. None of the things it inherits from set a
  border-radius. There is one subclass where toolbar is used
  with a border-radius (".ve-ui-surfaceWidget .ve-ui-toolbar-bar"
  sets a border-radius) which overrides this on purpose, so the
  default of 0 is redundant.

* Pattern "if ( .. ) addClass() else removeClass()" changed to:
  "toggleClass( , .. )"

Bug: 52014
Change-Id: I9be855148962eee068a77fe83e98eb20bbdcfeec
2013-07-30 01:47:54 +02:00
Trevor Parscal 61ba07d409 Reference dialog commingling
Objectives:

* Merge reference insert and edit dialogs
* Change workflow to put editing/creating a new reference first
* Add secondary page in dialog for selecting an existing reference

Changes:

*.php
* Cleanup unused files/messages

ve.ui.Dialog.css
* In the footer; make primary, constructive and destructive buttons
  appear on the right; all others on the left

ve.ui.MWReferenceSearchWidget.js
* Fix documentation
* Remove create option and reuse section header items

ve.ui.MWReferenceInsertButtonTool.js,
ve.ui.MWReferenceEditButtonTool.js,
ve.ui.MWReferenceButtonTool.js
* Merge reference button tools

ve.ui.MWDialog.css
* Remove body styles, use padded option of layout instead
* Update selectors as per merging of dialogs

ve.ui.MWReferenceInsertDialog.js
ve.ui.MWReferenceEditDialog.js
ve.ui.MWReferenceDialog.js
* Merge reference dialogs
* Add buttons to switch between edit and select mode

ve.init.mw.ViewPageTarget.js
* Update reference button name as per merging of tools

ve.ui.SurfaceWidget.js
* New widget!
* Encapsulates a "sub-surface"

Bug: 51152
Bug: 50458
Change-Id: I8265febf4fd8f64d2ac40470ff033bac68b24d99
2013-07-18 14:14:14 -07:00