Fix Alt-tabbing while using hand tool locks the hand tool (fix #325) by Gasparoken · Pull Request #5601 · aseprite/aseprite

Gasparoken · 2025-12-16T15:09:33Z

aseprite-bot

clang-tidy made some suggestions

aseprite-bot · 2025-12-16T15:18:16Z

         (m_proj.scaleX() <= 1.0 && m_proj.scaleY() <= 1.0)));
 }

+void Editor::cancelOperation()


warning: method 'cancelOperation' can be made static [readability-convert-member-functions-to-static]

src/app/ui/editor/editor.h:114:

- void cancelOperation(); + static void cancelOperation();

aseprite-bot · 2025-12-16T15:18:16Z


+static CancelActionsCallback cancelActionsCallback = nullptr;
+
+void Manager::setCancelActionsCallback(CancelActionsCallback callback)


warning: method 'setCancelActionsCallback' can be made static [readability-convert-member-functions-to-static]

src/ui/manager.h:146:

- void setCancelActionsCallback(CancelActionsCallback callback); + static void setCancelActionsCallback(CancelActionsCallback callback);

aseprite-bot · 2025-12-16T15:18:16Z

+  cancelActionsCallback = callback;
+}
+
+void Manager::cancelActions()


warning: method 'cancelActions' can be made static [readability-convert-member-functions-to-static]

src/ui/manager.h:147:

- void cancelActions(); + static void cancelActions();

dacap · 2025-12-17T14:37:47Z

@Gasparoken please give a proper title to the PR

Gasparoken · 2025-12-17T15:17:28Z

@Gasparoken please give a proper title to the PR

Ok, no problem, by the way: @dacap If you're available, could you check if the approach is correct? I'm still testing on Windows and trying to address the hand tool issue with the mouse middle button.

martincapello · 2025-12-20T02:28:42Z

        enqueueMessage(msg);
        break;
      }
+      case os::Event::CancelActions: {


I'm not sure about introducing this new os.Event in laf as is...because it doesn't seem to map well to an actual OS event. Should this event be fired when the program's window is not the main/focused/active window any more?

martincapello · 2025-12-20T02:32:02Z

 // when the os::Display is resized by the user.
 static bool auto_window_adjustment = true;

+static CancelActionsCallback cancelActionsCallback = nullptr;


I think we should avoid using a static callback for this.

martincapello · 2025-12-20T02:40:12Z

        break;
      }
+      case os::Event::CancelActions: {
+        cancelActions();


I think we should follow the same principles as for the other events: translating the os Event into a Message. Then you will be able to handle that Message in the Editor's onProcessMessage method and call your Editor::cancelOperation() method.

aseprite-bot

clang-tidy made some suggestions

aseprite-bot · 2025-12-22T20:58:54Z


+      case os::Event::AppLostFocus: {
+        if (mouse_widget) {
+          auto msg = new AppLostFocusMessage();


warning: 'auto msg' can be declared as 'auto *msg' [readability-qualified-auto]

Suggested change

auto msg = new AppLostFocusMessage();

auto *msg = new AppLostFocusMessage();

…te#325) AppLostFocusMessage was added to tell the Editor to disable the 'quick hand tool' when the application loses focus via Alt+tab.

dacap · 2026-03-05T17:27:21Z

I'm testing this one with https://github.com/gasparoken/laf/tree/fix-alt-tab (which is different from https://github.com/aseprite/laf/tree/fix-alt-tab).

Probably I'll cherry-pick https://github.com/gasparoken/laf/tree/fix-alt-tab and rename the events to AppEnter/AppLeave. I always wanted a couple of WindowEnter/WindowLeave events, but probably those would be different e.g. in a multiple-windows scenario a window could lose focus, but another window of the same app be focused (so there is a WindowLeave for the old window, WindowEnter for the new one, but no AppEnter/Leave events).

I'll try to make these events work on laf, and then go back to this PR.

dacap · 2026-03-05T20:10:03Z

Merged the laf patch in aseprite/laf@c0a8427 but then implemented AppEnter/AppLeave/WindowEnter/WindowLeave in all platforms: aseprite/laf@592136b

I'll continue with this PR tomorrow.

dacap

Leaving some comments about the code and how I'm going to rebase this PR with these patches. There is no need for action from your side.

dacap · 2026-03-06T11:18:33Z

+        ui::MouseMessage* msg = new ui::MouseMessage(ui::MessageType::kMouseUpMessage,
+                                                     os::PointerType::Mouse,
+                                                     ui::MouseButton::kButtonLeft,
+                                                     os::KeyModifiers::kKeyNoneModifier,
+                                                     manager->getMouse()->mousePosInDisplay());
+        m_state->onMouseUp(this, msg);
+        ui::MouseMessage* msg2 = new ui::MouseMessage(ui::MessageType::kMouseUpMessage,
+                                                      os::PointerType::Mouse,
+                                                      ui::MouseButton::kButtonMiddle,
+                                                      os::KeyModifiers::kKeyNoneModifier,
+                                                      manager->getMouse()->mousePosInDisplay());
+        m_state->onMouseUp(this, msg2);


Both new ui::MouseMessage(...) generate memory leaks as they are not queued in the manager, I'm going to replace both of them with:

Suggested change

ui::MouseMessage* msg = new ui::MouseMessage(ui::MessageType::kMouseUpMessage,

os::PointerType::Mouse,

ui::MouseButton::kButtonLeft,

os::KeyModifiers::kKeyNoneModifier,

manager->getMouse()->mousePosInDisplay());

m_state->onMouseUp(this, msg);

ui::MouseMessage* msg2 = new ui::MouseMessage(ui::MessageType::kMouseUpMessage,

os::PointerType::Mouse,

ui::MouseButton::kButtonMiddle,

os::KeyModifiers::kKeyNoneModifier,

manager->getMouse()->mousePosInDisplay());

m_state->onMouseUp(this, msg2);

ui::MouseMessage msg(ui::MessageType::kMouseUpMessage,

os::PointerType::Mouse,

ui::MouseButton::kButtonLeft,

os::KeyModifiers::kKeyNoneModifier,

manager->getMouse()->mousePosInDisplay());

m_state->onMouseUp(this, &msg);

ui::MouseMessage msg2(ui::MessageType::kMouseUpMessage,

os::PointerType::Mouse,

ui::MouseButton::kButtonMiddle,

os::KeyModifiers::kKeyNoneModifier,

manager->getMouse()->mousePosInDisplay());

m_state->onMouseUp(this, &msg2);

Another important thing, after merging this I'll try to refactor the ui-lib in some way automatically or to handle this in a more generic way (e.g. the Timeline has the same problem)

dacap · 2026-03-06T11:21:50Z

        break;
      }

+      case os::Event::AppLostFocus: {


I'll try to use the WindowLeave event instead of the app one (both messages should be received, but I have to test on all platforms yet):

Suggested change

case os::Event::AppLostFocus: {

case os::Event::WindowLeave: {

dacap · 2026-03-06T11:21:53Z


+      case os::Event::AppLostFocus: {
+        if (mouse_widget) {
+          auto msg = new AppLostFocusMessage();


There is no need for a new Message sub-class if the message doesn't contain any extra information, I'm going to replace this with:

Suggested change

auto msg = new AppLostFocusMessage();

auto* msg = new Message(kWinLeaveMessage);

The kWinLeaveMessage name is temptative, but probably we could add something like kMouseLostMessage or see if we can just send a kMouseLeaveMessage.

dacap · 2026-03-06T13:54:35Z

+      case os::Event::AppLostFocus: {
+        if (mouse_widget) {
+          auto msg = new AppLostFocusMessage();
+          msg->setRecipient(mouse_widget);


After furthering testing, this AppLostFocus (or another one like WindowLeave message) cannot be received by the mouse_widget only (we should setPropagateToParent(true)), but the message should be sent to the display window.

For this specific fix, I'll try another approach, probably a MouseLeave message when os::Event::WindowLeave is received (instead of creating a new AppLostFocusMessage), something to solve every case of all widgets that have the mouse captured.

, aseprite#5601)

, aseprite#5601) Switching to another app will generate a kMouseUpMessage without button (kButtonNone) for the capture_widget so it can release the mouse and go back to its idle state.

On XWayland, FocusOut events can be sent spuriously by the compositor (e.g. when focus moves between Aseprite's own windows in multi-display mode). Using WindowLeave to release capture caused popup windows like the color picker to close prematurely. Change to AppLeave which only fires when focus leaves the application entirely (e.g. Alt+Tab to another app), preserving the original fix for aseprite#325 and aseprite#5601.

Gasparoken self-assigned this Dec 16, 2025

Gasparoken force-pushed the fix-alt-tab branch from 07d276a to 84679d6 Compare December 16, 2025 15:14

aseprite-bot reviewed Dec 16, 2025

View reviewed changes

Gasparoken force-pushed the fix-alt-tab branch from 84679d6 to ede7521 Compare December 17, 2025 13:53

Gasparoken force-pushed the fix-alt-tab branch from ede7521 to 62ac22f Compare December 17, 2025 14:45

Gasparoken changed the title ~~Draft~~ Fix Alt-tabbing while using hand tool locks the hand tool (fix #325) Dec 17, 2025

Gasparoken force-pushed the fix-alt-tab branch from 62ac22f to 35f8f99 Compare December 17, 2025 19:51

Gasparoken assigned martincapello and unassigned Gasparoken Dec 17, 2025

Gasparoken force-pushed the fix-alt-tab branch from 35f8f99 to b5e44aa Compare December 18, 2025 18:30

Gasparoken marked this pull request as ready for review December 18, 2025 19:09

Gasparoken requested a review from dacap as a code owner December 18, 2025 19:09

martincapello reviewed Dec 20, 2025

View reviewed changes

martincapello assigned Gasparoken and unassigned martincapello Dec 20, 2025

Gasparoken force-pushed the fix-alt-tab branch 2 times, most recently from 1b55755 to b9223cc Compare December 22, 2025 20:55

Gasparoken assigned martincapello and unassigned Gasparoken Dec 22, 2025

aseprite-bot reviewed Dec 22, 2025

View reviewed changes

Fix Alt-tabbing while using hand tool locks the hand tool (fix asepri…

9eff071

…te#325) AppLostFocusMessage was added to tell the Editor to disable the 'quick hand tool' when the application loses focus via Alt+tab.

Gasparoken force-pushed the fix-alt-tab branch from b9223cc to 9eff071 Compare December 23, 2025 02:02

dacap assigned dacap and unassigned martincapello Feb 12, 2026

dacap reviewed Mar 6, 2026

View reviewed changes

dacap closed this Mar 6, 2026

dacap added the needs different approach label Mar 6, 2026

dacap added a commit to dacap/aseprite that referenced this pull request Mar 6, 2026

Release capture after switching to other app w/Alt+tab (fix aseprite#325

e110161

, aseprite#5601)

dacap mentioned this pull request Mar 6, 2026

Release capture after switching to other app w/Alt+tab (fix #325, #5601) #5691

Merged


		static CancelActionsCallback cancelActionsCallback = nullptr;

		void Manager::setCancelActionsCallback(CancelActionsCallback callback)

	auto msg = new AppLostFocusMessage();
	auto *msg = new AppLostFocusMessage();

	case os::Event::AppLostFocus: {
	case os::Event::WindowLeave: {

	auto msg = new AppLostFocusMessage();
	auto* msg = new Message(kWinLeaveMessage);

Uh oh!

Uh oh!

Conversation

Gasparoken commented Dec 16, 2025 • edited by martincapello Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aseprite-bot left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dacap commented Dec 17, 2025

Uh oh!

Gasparoken commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aseprite-bot left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dacap commented Mar 5, 2026

Uh oh!

dacap commented Mar 5, 2026

Uh oh!

dacap left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Gasparoken commented Dec 16, 2025 •

edited by martincapello

Loading

Gasparoken commented Dec 17, 2025 •

edited

Loading