Multi screen support

Features
2

Hi @Forrest_Lowe, actually the “do it” thing doesn’t work for developers. Even more, it works in the reverse direction: the more “do it” I hear, the less I want to work on it.

10 Likes
3

Well that would be valid if I wasn’t also a developer. I am a strong believer in listening to my audience, if you don’t believe in that then why charge for your product? Because you’re gonna make allot more sales going FTU if you don’t give a shit what people think.

4

Just in case, this feature was thought long time ago: Make all elements on screen dockable/movable/resizable · Issue #518 · aseprite/aseprite · GitHub

The feature can be implemented after doing the full switch to our back-end + Skia (removing Allegro library completely, which is still active on Aseprite v1.2.9 on Linux). You can see the ongoing efforts along all these years to implement this feature here: https://github.com/aseprite/aseprite/issues/139 It’s not related to “I don’t give a shit about the users”, it’s that it required years of work to be able to implement the feature and just in this year we’ll be able to start working on this.

What I find a little harsh from your side, is the imperative tone to ask for features, sounds like developers are slaves or something like that.

8 Likes
5

It’s more of a suggestion, I am happy to see that it is indeed being worked on. I do not mean to tell you how to do your job, I only mean to express how I feel the product should continue. I want a feature, and to know that it will be implemented in a couple of years (as it sounds from the way you put it) just makes me joyous.
Side note: I don’t mind being harsh if it means you’re listening. I like to be playful and ask for something in a joking manor “Do it” being the punchline(poor though it may be.) But I don’t care to be talked down to for not being on the project. If you were to start your responses with “That feature is actually already in the works” like you have done now, I would have responded very differently.

6

Don’t worry, eveything is fine :+1:

4 Likes
8

Developers everywhere hate attitudes like yours, Forrest. You being one of them isn’t a free pass, it makes us ashamed to share an occupation/hobby with you.

Edit: Just a note, there was an even nastier comment from our friend Forrest that was removed that prompted my response, but my remark still stands.

6 Likes
9

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

  1. 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.)
  2. 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).
  3. Then we refactored everything to a new layer (laf) instead of using Allegro directly.
  4. 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.
  5. 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 os::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).

9 Likes
10

Wow, I was googling for this and it turns out it’s been discussed just a few days ago. Well, if someday it’s implemented it will be really welcomed!. These kind of core refactors may be really, really painful. I prefer a single-windowed-bug-free software than a rushed multiwindow disaster. Take your time!

5 Likes
11

Just my two cents, I would rather have someone like this, than those who doesn’t participate in community. and yes, I also came here because I have multi monitor and would like to see the progress of this feature. Thank you.

12

@dacap Is there an ETA for this feature? (I’m also a multi monitor user, but I don’t really mind if it’s a pair of years or more, I’m more than happy with the development of Aseprite, it’s just my curiosity asking ^_^)

I totally agree! :slight_smile:

I’m not too sure of that, man. Maybe Forrest_Lowe meant no harm with his original post, but sometimes users can create really toxic threads (even unknowingly) by asking for things and answering posts in that way (without caring about good manners and/or upsetting other users). Also, welcome to the community! @macroblitz :smiley:

13

1+ to this feature, I’m pretty new to animation and art, pixel or otherwise, but at least to me it seems very important to be able to have the same animation open on multiple stages of the animation and on multiple levels of zoom just to easily get an overview of the different states and how they relate to the part you are drawing. Understand it hasn’t been prioritised given the complexity though.

But instead of just complaining I’ll also come with a possible solution. It’s a bit of a hack but works better than nothing if you really want the second monitor (let me know if anyone has a better hack pls).

With OBS (streaming software) you can easily show different regions of a screen on another screen, so if you just duplicate tiny windows of what you would want on the other monitor, and then just blow up that region on your second screen, you can get more references of what you are currently drawing on your second monitor without taking up that much real estate in the main window.

Second monitor on the left:

To easily crop the windows in OBS hold down ALT while resizing them.

4 Likes
14

created account just to support this comment. when i read forrrest lowe’s words i dry heaved a little in my mouth…

2 Likes
15

@dacap Thank you for this, it’s really informative and surprisingly showed me I’m an old time user of ASE from ages ago.

Allegro really wasn’t designed for this scenario, I look forward to your future development.

1 Like
16

Here is what I do by the way to get around this limitation when using Aseprite until it can be supported.

Honeyview will auto refresh when the open file is changed. It also supports nearest neighbor scaling (“No filter” in the menu). So if you keep exporting the image and have it open in Honeyview, you can get whatever size of preview you want. It can also preview animated images in addition to static images.

17

What did they say? I’m curious as to how horrible it is. Was it a “you make product so you have to improve the product even if it is at the expense of your own health because I paid for quality and I will get quality” dumbfucks or was it worse? I can’t count the amount of people messaging me weekly about an app I stopped developing years ago.

18

Would be a great feature! I hope it’s possible @dacap !

19

Hi,
Curious to know what’s the status of this feature. I understand it’s very complicated but I’d like to know if there’s an update.

Thanks!

20

This is implemented in the v1.3/beta branch, you can enable from Edit > Preferences > General, but it’s disabled by default since v1.3-rc1 because there are a lot of issues to fix yet (#3556)

Some of the work done to make this work can be found in the following changes (but it’s not a complete list):

  • Window resizing in real-time #139 #2536 patch
  • Support for multiple windows #139 patch
  • Custom native frame for windows #139 patch
  • Support for multiple windows in the UI layer patch
  • Added multiple windows on UI layer patch
  • Several fixes for multiple windows on UI layer patch

Issues:

21

ahahah, true :smiley:

22

Well it does work in 1.3.2, but the behavior is kind of buggy in Gnome Linux. I have a Wacom Cintiq 16, everytime I open a dialog, it opens on the other screen. I’d say, maybe I’d like the application to open it over the main window, or at least, remember the dimensions and position of the windows the next time it opens… and beware of managing the position the next time if the multiscreen config changed (I’ve seen applications where the dialog opens into the void, completely off-screen).

When the Open and Save dialog opens, I don’t know how to describe that, it opens full-double-screen, in other words, the open dialog box is covering both screens 100%. I have to resize it everytime, thats pretty anoying :stuck_out_tongue: