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
uilayer uses only onui::Managerwith one display). - Then we refactored everything to a new layer (
laf) instead of using Allegro directly. - Then we switch the back-end of
lafto our own implementation using events to handle user input, and using Skia to draw graphics in-memory. - Now the
laflibrary supports multiple windows, but theuimodule of Aseprite doesn’t. So now we have to change theui::Managerimpl to handle multipleos::Display, and eachui:Windowcould be related to a specificos::Display.
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).