There are cases where we need to modify the list of observers of certain
entity when we are in a notification loop (i.e. iterating its observers).
E.g. A general update notification about the current document to all its
observers could create the mini editor, which is a DocumentObserver, so
a new observer is added to the list in the same notification loop.
Anyway, as we cannot modify the observer list (std::vector) when we are
notifying them (any modification in the std::vector invalidates
its iterators), the fix is quite easy (but not optimal): we can create
a copy of the observers list so we can iterate the list.
Note: If we have performance issues about this, we could try a std::list,
but at the moment this fix is quite enough.
On WinXP classic theme we receive a WM_NCHITTEST messages for the
scrollbars, and as they overlap the resize borders (see WM_NCCALCSIZE
handler) we have to return a proper value as if they really were the
borders of the window.
Note: Scrollbars are still visible in classic theme, that is just ugly,
but at least the user can resize the window from bottom and right edges.
This is an huge refactor to avoid handling Allegro FONT directly. Some
changes:
* Add she::System::defaultDisplay/Font, createRgbaSurface, loadSurface,
and loadRgbaSurface.
* Rename she::CreateSystem/Instance to she::create_system/instance.
* Remove ui/font.cpp and move ui/fontbmp.cpp to she library.
* ui::IButtonIcon uses she::Surface instead of BITMAP.
* Rename she::LockedSurface::drawAlphaSurface -> drawRgbaSurface
* Rename ui::SetDisplay -> set_display
* Rename _ji_font_text_len -> ui::Graphics::measureUIStringLength
If the transparent/mask color has alpha = 0, we cannot filter by
RGB/Grayscale values, we have to blend all colors anyway. Only when
the mask has alpha > 0 we can check if the RGB values are different to
the mask RGB values. In other words, comparing the source color with the
mask, makes sense only when the mask has alpha > 0.
The new default location is %AppData%/Aseprite folder. This will be useful
for a future setup program. So if aseprite.ini is located in aseprite.exe
directory, it acts like a portable program, in other case it acts like
an installed program.
When we create a new image for the sprite, we've to adjust the image mask
color to the sprite mask color (as the image isn't in the Stock yet).
This problem appears in v1.0.1 (9dfec919e4b35502fdeb88ca5c10b41af3faa9a5)
because now we don't change the mask color of sprite images in the
rendering process. This kind of bug can be detected running on debug
mode with an assert in the render procedure.
