Asking for onCanCut/Copy/Paste/Clear just before onCut/Copy/Paste/Clear
in the same InputChainElement we ensure that the command for that specific
element can be used (and we aren't mixing onCans result of one input chain
element with the execution of the first input chain element command).
This commit includes the new doc::PalettePicks class. It's a helper
class to identify which entries are selected in the ColorBar.
We've removed the Copy/Paste buttons from the Palette Editor window.
Now the default palette is saved in the user configuration
directory, so we can set any palette as the default (it doesn't
matter if it's related or not to a file, it will be copied into
the user directory anyway).
As now the eraser must show the boundaries of custom brushes, the fixed
maximum limit we were using (MAX_SAVED) for boundaries is not enough.
So now we use a std::vector for saved pixels.
There was an ugly combination of events:
1. When ContextBar::BrushTypeField receives an onItemChange is because the
mouse button is pressed on it (a kMouseDownMessage)
2. It shows the BrushPopup window (which is a PopupWindow
with kCloseOnClickInOtherWindow click behavior)
3. When other click is made in BrushTypeField, the BrushPopup is closed
because it is filtering messages (since it's
kCloseOnClickInOtherWindow). This generates a kCloseMessage in the
queue.
4. BrushTypeField::onItemChange() is executed again (for the same
click in point 3), and it checks that the popup is closed (recently
closed, by this click), so it shows the BrushPopup again.
5. The enqueued kCloseMessage is receved by PopupWindow, and it calls
stopFilteringMessages().
So in this case we have a visible PopupWindow that is not filtering
messages. To fix this bug we have included a startFilteringMessages()
in kOpenMessage. So when the popup is shown again, it filters messages
and the popup cannot stay visible.
After creating a new cel from a tool loop, we have to generate an
ActiveSiteChange notification (because now we have a cel in the active
position). In this way the StatusBar can update/enable the opacity slider.
On OS X we can use Cmd+[ or Cmd+] to navigate the history. And Cmd+Up/Down
to go to the enclosing folder, or enter in a folder respectively.
On Windows we can use Alt+Left/Right to navigate the history. And Alt+Up
to go to the enclosing folder. (Alt+Down is an extra shortcut to enter
in the folder).
We've to regenerate all buttons that modify a specific keyboard shortcut
because they are listening the Click signal with the specific index of
the that shortcut. The index is given as parameter to the Signal connect()
function.
We've converted all buttons to shared pointers to simplify the code.
There are some widgets (e.g. fg/bg color buttons in the ColorBar, and
ContextBar's check-boxes) that use a "mini font". We could setup the mini
font in onInitTheme(), but the whole program is not ready to do something
like that (there are too much child_spacing/borders values that are set
outside onInitTheme).
A better way is to ask to the theme itself (Theme::getWidgetFont())
about what font to use for each specific widget. And the Widget::m_font
field can act as a cache of this requested font. So now the "mini font"
is specified in a SkinProperty's flag.
Instead of calling StatusBar::updateUsingEditor(Editor*), now the StatusBar
is a ContextObserver that observe changes in the active doc::Site. The
Editor notifies a ActiveSiteChange event when the active frame/layer
is changed.
Fix#657
This fixes a problem creating interpolation between random
oldX/Width values and x/width fields. I've added some special values
in the initialization of a Tab to know if we are using uninitialized
values oldX/Width/x/width values in the animation.
Related to bug found in #656. In this way, if the UI is enabled,
the active document is != null only if there is an active view for it.
Anyway, in batch mode we can potentially have a lot of bugs. There are
several UI commands that think that active view != null (and
current_editor != null) when the active document != null.
Now the file name field is an editable ComboBox, so we don't
autocomplete/modify the text inside the entry box.
With this commit we modified the editable ComboBox behavior too:
* When the ListBox is shown, the focus remain in the Entry field (now
the ListBox cannot have the focus when the ComboBox is editable).
* When Up/down keys are received by the Entry, they are given to the
ListBox to change the selected item. But the focus returns to the
Entry anyway.
When a combobox popup is open, it creates a new non-foreground top window
(which is sibling of the window where the combobox widget is). When the
popup receives a key press, and it doesn't use it, the key is passed to
its parent (a ui::Manager), and then the latter has to process it.
Before this commit, CustomizedGuiManager::onProcessMessage() was
filtering shortcuts for foreground window, but it was working only
when the key was pressed in the foreground window itself (not when a
combination of foreground and background windows were open). Now the
filter is done in Manager::onProcessMessage() (which returns true,
i.e. key was used, for every pressed key when a foreground window
is found in its children hierarchy).
We replace brush slots until the user presses its keyboard shortcut, which
means he is interested in reusing the brush. In this way, if we want to
keep a brush, we can press Ctrl+B, select the brush area, and then Alt+1
to keep the first brush, then the next brush slot will be used/replaced
until Alt+2 is pressed, etc.
When we create a CompressedImage from a Brush image, we want to know what
pixels are != the mask color, just to generate the PointShape (we don't
care the specific color of the scaneline/each pixel, that information is
used in the "ink processing" step).
Now the ContextBar contains a set of brushes. The ChangeBrushCommand
supports a new "slot" parameter and "change" = "custom" to select a
specific custom brush from the ContextBar. Alt+1, Alt+2, etc. are mapped
to this ChangeBrushCommand (see changes in gui.xml).
Also, as the ButtonSet that represent different brushes in the ContextBar
uses icons generated from the brush, we don't need the skin parts that
represent each brush type (we can generate those icons from some standard
brushes). Those skin parts were removed.
If we press several times Ctrl+B, we could create several SelectBoxStates,
and as it backs to the previous state, it's like we will select several
brushes instead of backing to the original state.
This is the first step to create a bigger BrushPopup to select brushes
from an history of brushes. The general idea is to use Alt+1, Alt+2, etc.
to select different brushes from a stock.
Also the "discard brush" was removed. As the brush can be discarded
changing the brush type.
Compiler could not find notifyActiveDocumentChanged.
/home/aurelien/src/aseprite/src/./doc/test_context.h: In instantiation of ‘void doc::TestContextT<Base>::onRemoveDocument(doc::Document*) [with Base = app::Context]’:
/home/aurelien/src/aseprite/src/app/document_api_tests.cpp:66:1: required from here
/home/aurelien/src/aseprite/src/./doc/test_context.h:44:58: error: ‘notifyActiveDocumentChanged’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
notifyActiveDocumentChanged(m_activeDoc = nullptr);
Was getting this when linking aseprite:
check_update.cpp:113: undefined reference to
net::HttpHeaders::setHeader(std::string const&, std::string const&)
With this we can see the exact preview in real-time of the the left
click paiting (e.g. using real Indexed composition, ink, point shape, etc.)
We are able to preview blur, eraser, or flood fill preview too (anyway
these are not enabled at this moment).
Changes:
* Add render::ExtraType enum to indicate if the extra cel acts like a
patch for the current cel (e.g. cursor), or as an extra layer for
composition (e.g. selection/moving pixels)
* Add ExtraCelType property to app::Document and to render::Render
* Add ToolBox::getPointShapeById()
* As the current cursor preview depends on the current layer, when
we change the current layer we've to update the Preview editor
with the new selected layer (now we listen to
Document:.onAfterLayerChanged())
* Add create_tool_loop_preview() and PreviewToolLoopImpl
