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).
