First commit :
Removed Local storage feature
Added 'download project' 'open project' options
First attempt at simplifying right panel.
To be continued ...
New option in application settings : onion skin.
You can choose the overlay to display now :
- no overlay
- onion skin (default)
- layer preview (previous default)
Available in Application Settings panel.
Only one overlay can be used at the same time.
The onion skin overlay is driven by a new OnionSkinRenderer maanged by the
drawing.
The drawing controller is responsible for instanciating and 'choosing' the
overlay renderer.
When switching to a new overlay, other overlays are cleared and flushed
(they cache their rendering frame, flush empties the cache).
NB : flush is only available on LayersRenderer and OnionSkinRenderer for
now.
In the GIF export panel, user can now choose between :
- export online (previous 'upload' feature)
- download GIF
Labels have been updated in the PNG export panel to follow the same
convention.
CanvasToBlob library was modified and moved to dedicated utils to handle
not only canvas, but also any base64 dateURI.
When holding shift and using the move tool,pixels normally exiting the
frame will now be redrawn on the other end of the frame.
Makes it easy to perform sliding animations.
Added new tool to lighten/darken. By default is in lightening mode. If the
user holds ctrl/cmd while using the tool, switches to darkening mode.
If the user holds shift while using the tool, then each pixel can only be
modified once per tool usage (ie user keeps hovering the same pixel, it
won't get lighter/darker after the first time). Can be useful if you want
to keep control of the amount of colors in the sprite.
TODO :
- Ability to select explicitly lighten/darken (context menu for
tools).
- Ability to set the 'step' (ie the strength of the lighten/darken)
If there are less than 256 colors in the piskel, do not perform anycolor
quantization, just reuse the colors from the piskel.
Added preserveColorsParameter to gif.js library.
If nb colors>256, fallback to the previous behavior. This could be
improved by checking the number of colors for each frame. The palette is
defined independantly for each frame, so as long as a frame is <256
colors, we could reuse the original colors.
I also believe that images with more colors would get a better quality if
we could use a single color sample for all frames. This would avoid color
'gaps' as we can experience today. In any case, for piskel, < 256 is a
reasonable assumption
When user changes canvas background, css class now applied on document
body.
Created new controller listening to Events.USER_SETTINGS_CHANGED to handle
this.
Created dynamic palette displaying currently used colors.
This palette is now selected by default.
New service UsedColorsService created. Listens to PISKEL_RESET and
TOOL_RELEASED and keeps track of the list of current colors.
Still need to :
- improve sorting of colors
- allow to clone the current color palette as a custom palette
- add proper getter in UsedColorService to get the list of current colors
Also I hardcoded a max-height for the palettes-list as I found no better
way of handling the case of palettes containing many colors.
Maybe should add a limit to the number of colors handled by this automatic
palette.
- new checkbox in resize panel
- content is resized using nearest neighbor
- deactivated by default
2 bug fixes :
- remove focus after closing drawer
- fire resize event after undo/redo if size changed
- can use BACKSPACE key to delete selection content
when no selection, backspace retains the default behavior
- cursor for rectangle selection has been changed to crosshair
- fixed a bug where selection seemed to be cropped when released out of
the visible canvas
- new controller CursorCoordinatesController
- added div in right column (bottom:0)
- 3 new events : CURSOR_MOVED, DRAG_START, DRAG_END
- modified tools to fire events when necessary
The cursor coordinates are displayed when the mouse is hovering the
drawing area. When the mouse leaves the area, the indication disappears.
If the user is using a tool that involves dragging (selection, rectangle,
circle), the indicator displays the original coordinates (captured during
drag start) and the current coordinates.
- added rename icon in layers list
- mutualized CSS for edit icon between palette manager and layers list
- new CSS file icons.css for actions/links/buttons using icons
- layers are no longer retrieved by name, but by index
- mutualized shape tools common code in a ShapeTool class
- when holding shift and drawing a frame, the ratio is preserved
- selection and shape tools now support the mouse to leave the drawing
area
- shape tools can go 'outside' the drawing canvas
- Frame set/getPixel now check the pixel is in range instead of crashing
Issue was coming from the cached frame renderer.
During the window resize, we update the displaySize of the frame renderer,
regardless of the fact that the dimensions changed or not.
The setDisplaySize triggers a destruction of the canvas. But the
CachedFrameRenderer will render the frame only if it detects a change. In
this case, setDisplaySize has been overrided in CachedFrameRenderer to
skip any processing if the dimensions didn't change.
This behavior could be actually done in the FrameRenderer itself, but
since this is crucial to the CachedFrameRenderer behavior, I prefer to
keep it in this class.
Alternatively, could implement a way to discard caches of
CachedFrameRenderers from the outside.
The palette manager UI is redrawn almost everytime the model changes.
This way, UI is always in sync with the model.
However, spectrum instances are spawning everytime a redraw is performed.
They cannot be cleaned before the redraw is performed, because if a
spectrum picker is opened, it should remain like this. This allows the
cuser to keep modifying a color without having to reopen the picker each
time he/she stops on a color.
As a workaround, I keep a reference on all the spectrum containers and
destroy them all when the manager is disposed.
Ideally I'd prefer to have a single spectrum instance that I could move
around depending on which color the user wants to edit. I.e. I want to
mutualize all the picker instances ... But this will require a bit more
work.
Also added a notification when the user saves a palette.
Updated z-index of user-message container so that it is always above the
rest of the application.
Mousemove events do not have the correct button information
Need to keep the state of which button is clicked at which moment
This was actually the initial implementation ...
But I removed it because I couldn't remember why we did this in the
beginning.
Added lots of 'warnings' in comments, but won't be safe until we get good
integration tests.
References :
- FF : https://bugzilla.mozilla.org/show_bug.cgi?id=297919
"What if multiple buttons are pressed during mouse move? And how does the
integer field (button) indicate that no button is pressed? I think this
should be wontfix -- if people need button information during mouse move events
we need a new way of getting it (buttonSet), not the same way it works for click,
etc."
- IE : couldn't find any reference ...
- Fixed : manager UI is redrawn after save
- the Selected palette is saved as a user preference
- default background is now the dark one
- the selected palette is not reset after closing palette manager
- can create palettes
- palettes are persisted to local storage
- can add colors to palettes using spectrum color picker
- can remove created palettes
- can revert changes on unsaved palettes
Merge branch 'master' into feature-color-palette
Conflicts:
src/css/spectrum/spectrum-overrides.css
* Users can now use DEL to delete the current selection
* Cheatsheet has been updated accordingly
* Cheatsheet has been refactored to mutualize markup creation code
* removed SHOW_GRID boolean, replaced with GRID_WIDTH
* gridEnabled on a frame is now infered from the grid width setting
* updated template to use a select to pick the grid size
