Just in case for future reference I’ll leave here some comments about this feature and why it’s hard to implement in the current design of Aseprite (but it’s not impossible, but it will take some time):
- The original version of Aseprite (ASE, Allegro Sprite Editor) was developed with the Allegro (4) library, which was a library to program games on a MSDOS-style (one thread, sequential logic, without events). Remember that I started developing ASE in 2000~2001. (We still have the modified Allegro version that we used for Aseprite in a separated repository for historical reasons.)
- Allegro 4 library never supported multiple windows, so the program UI was never thought to be used in multiple windows of the operating system (that’s is why the
ui layer uses only on
ui::Manager with one display).
- Then we refactored everything to a new layer (
laf) instead of using Allegro directly.
- Then we switch the back-end of
laf to our own implementation using events to handle user input, and using Skia to draw graphics in-memory.
- Now the
laf library supports multiple windows, but the
ui module of Aseprite doesn’t. So now we have to change the
ui::Manager impl to handle multiple
os::Display, and each
ui:Window could be related to a specific
Basically this is a refactoring-problem vs. avoid-introducing new bugs, we choose to have a more stable Aseprite version in the short-term instead of adding something that will break everything. The actual bottleneck is the tilemap editor feature, once that is implemented on v1.3-beta, we’ll be able to start adding/refactoring more stuff on the beta version (the stable v1.2 is almost feature freeze and only bug fixes will be released from now on).