I’m constantly having to flip between my file explorer and opening aseprite or having to navigate through the open file window.
It would be nice to have a project pane like vscode or sublime text where I can drill down and work with files more efficiently than I am currently.
you could just bind a shortcut to open file explorer
The biggest issue is that I am running bspwm in linux and every time I open a file with aseprite, it opens a new application instead of opening in the one that is already open.
As for the open file command, I already mash ctrl + o in order to open files.
the nthats a ug that need to be solved in linux version right?
It very well could be, but again I am running a different setup than what would be run for say Ubuntu, Linux Mint, Fedora, etc…
I don’t really want to bother the devs with fixing a problem that is experienced by a few people out of the entire ecosystem.
What I am merely stating is that a project explorer would be a nice addition and for now I’ll just make do with ctrl+o and navigating around that way.
i think that you woiuld be disrupting the ecosystem more with a new feature that probaly few would use, than a bugfix whihc is easier to do, especially because aseprite ui is very tricky
An unfounded claim, but sure.
what do you mean, dancap keeps always saying that aseprite ui is very bad for creating and modifing itself thats why there is a planned ui rewrite for 1.4
also while fixing a bug can be tricky creating a whole new feature not only thakes am amout of works but then you need to debug that new feature, what you mean my claim is unfounded?
Okay.
Yea I know this. I also program.
If a rewrite is planned, then a project pane could be considered. Let’s ignore the rewrite as an option because that in of itself is fraught with problems. If you’ve ever been involved with a large rewrite, things do not go smoothly at all.
Even if this bug was fixed, I’d still like to see a quicker way to navigate around a project with out having to constantly leave aseprite to look at the file explorer and go back. Context switching sucks.
That is a defeatist attitude. Debugging a feature, would mean that it was implemented with defects.
Hi there 
Some time ago I tried to create (at least) a tab with a “file selector” view, and it was not too bad. I think a tree-like view might be useful (mainly with a search box field).
I think the main missing internal code is a “file system watcher” (but there are cross-platform solutions). We need to integrate this to watch configuration changes, which might be useful for this tree-like view of the project folder.
This is a good feature and might be implemented sometime in the future.
Not sure if I said that 
We always welcome new ideas, please don’t discourage new ideas.
You’d be suprised. All features MUST be tested and debugged before release. There are most certainly always some defects left in any code.
Anyway such pane/panel with actively processing any changes “file system watcher” should really be closed/shrunk by default (and thus not tracing anything, all hooks off). Because it may lead to crashes or/and slowdowns. Especially on massive file system swapping when any access to file I/O API would lead to application hangs.
If anyone else comes here wondering why Aseprite opens in a new instance after opening the a file from a file explorer through xdg-open, it is not currently supported in linux. From discord:
Not a huge deal for me.
ok i could swear it a ui rewrite was on the roadmap but i was wrong, but i am 90% that i seen you Dacap talk about aseprite ui code being tricky to modify
You might be referring to this post, which was a very big specific problem on Aseprite because it was not originally designed to support multiple windows. But that has changed in v1.3 with several refactors (I’ll write about this when we publish the v1.3 source code).