fix: add shortcut for GTK inspector#428
Merged
RobertMueller2 merged 1 commit intoSatty-org:mainfrom Mar 16, 2026
Merged
Conversation
Closes: Satty-org#427 Before this fix, we mask GTK's own shortcuts (Ctrl+Shift+D and Ctrl+Shift+I). There is no easy way to prevent this with how we handle shortcuts. Instead, handle those shortcuts explicitly and actively enable GTK inspector. Since there is no good way to check whether it's currently enabled, toggle would require an additional bool in sketchboard, which could get out of sync if the user closes the inspector window. Instead, just enable without toggle, the user then has to close the inspector window if they want to get rid of it.
RobertMueller2
force-pushed
the
fix_inspector
branch
from
e4fbe3f to
18f8064
Compare
RobertMueller2
added a commit
to RobertMueller2/Satty
that referenced
this pull request
Mar 2, 2026
This adds a highlight (using adwaita @accent_color) for the button for a tool that is actively editing. This works for text and crop. The idea is that it's transparent to a user when esc/enter, which normally trigger actions, are masked by a tool. Based on PRs Satty-org#428 and Satty-org#398, so this remains a draft until they are merged. There are also a few leftover items. [ ] explore if this can be extended to the other tools while they are being dragged, it would make sense. In that context, it would be good if they had uniform handling of esc/enter, double check this [ ] removing the class within toolbars.rs update may not be ideal, perhaps there's a better way [ ] triggering ToolsToolbarInput::SwitchSelectedTool from toolbars.rs init may be redundant, double check that it isn't
RobertMueller2
added a commit
to RobertMueller2/Satty
that referenced
this pull request
Mar 5, 2026
This adds a highlight (using adwaita @accent_color) for the button for a tool that is actively editing. This works for text and crop. The idea is that it's transparent to a user when esc/enter, which normally trigger actions, are masked by a tool. Based on PRs Satty-org#428 and Satty-org#398, so this remains a draft until they are merged. There are also a few leftover items. [ ] explore if this can be extended to the other tools while they are being dragged, it would make sense. In that context, it would be good if they had uniform handling of esc/enter, double check this [ ] removing the class within toolbars.rs update may not be ideal, perhaps there's a better way [ ] triggering ToolsToolbarInput::SwitchSelectedTool from toolbars.rs init may be redundant, double check that it isn't
RobertMueller2
added a commit
to RobertMueller2/Satty
that referenced
this pull request
Mar 5, 2026
This adds a highlight (using adwaita @accent_color) for the button for a tool that is actively editing. This works for text and crop. The idea is that it's transparent to a user when esc/enter, which normally trigger actions, are masked by a tool. Based on PRs Satty-org#428 and Satty-org#398, so this remains a draft until they are merged. There are also a few leftover items. [ ] explore if this can be extended to the other tools while they are being dragged, it would make sense. In that context, it would be good if they had uniform handling of esc/enter, double check this [ ] removing the class within toolbars.rs update may not be ideal, perhaps there's a better way [ ] triggering ToolsToolbarInput::SwitchSelectedTool from toolbars.rs init may be redundant, double check that it isn't
gabm
approved these changes
Mar 16, 2026
RobertMueller2
added a commit
to RobertMueller2/Satty
that referenced
this pull request
Mar 19, 2026
This adds a highlight (using adwaita @accent_color) for the button for a tool that is actively editing. This works for text and crop. The idea is that it's transparent to a user when esc/enter, which normally trigger actions, are masked by a tool. Based on PRs Satty-org#428 and Satty-org#398, so this remains a draft until they are merged. There are also a few leftover items. [ ] explore if this can be extended to the other tools while they are being dragged, it would make sense. In that context, it would be good if they had uniform handling of esc/enter, double check this [ ] removing the class within toolbars.rs update may not be ideal, perhaps there's a better way [ ] triggering ToolsToolbarInput::SwitchSelectedTool from toolbars.rs init may be redundant, double check that it isn't
RobertMueller2
added a commit
to RobertMueller2/Satty
that referenced
this pull request
Mar 27, 2026
This adds a highlight (using adwaita @accent_color) for the button for a tool that is actively editing. This works for text and crop. The idea is that it's transparent to a user when esc/enter, which normally trigger actions, are masked by a tool. Based on PRs Satty-org#428 and Satty-org#398, so this remains a draft until they are merged. There are also a few leftover items. [ ] explore if this can be extended to the other tools while they are being dragged, it would make sense. In that context, it would be good if they had uniform handling of esc/enter, double check this [ ] removing the class within toolbars.rs update may not be ideal, perhaps there's a better way [ ] triggering ToolsToolbarInput::SwitchSelectedTool from toolbars.rs init may be redundant, double check that it isn't
RobertMueller2
added a commit
to RobertMueller2/Satty
that referenced
this pull request
Mar 28, 2026
This adds a highlight (using adwaita @accent_color) for the button for a tool that is actively editing. This works for text and crop. The idea is that it's transparent to a user when esc/enter, which normally trigger actions, are masked by a tool. Based on PRs Satty-org#428 and Satty-org#398, so this remains a draft until they are merged. There are also a few leftover items. [ ] explore if this can be extended to the other tools while they are being dragged, it would make sense. In that context, it would be good if they had uniform handling of esc/enter, double check this [ ] removing the class within toolbars.rs update may not be ideal, perhaps there's a better way [ ] triggering ToolsToolbarInput::SwitchSelectedTool from toolbars.rs init may be redundant, double check that it isn't
RobertMueller2
added a commit
to RobertMueller2/Satty
that referenced
this pull request
Mar 28, 2026
This adds a highlight (using adwaita @accent_color) for the button for a tool that is actively editing. This works for text and crop. The idea is that it's transparent to a user when esc/enter, which normally trigger actions, are masked by a tool. Based on PRs Satty-org#428 and Satty-org#398, so this remains a draft until they are merged. There are also a few leftover items. [x] explore if this can be extended to the other tools while they are being dragged, it would make sense. In that context, it would be good if they had uniform handling of esc/enter, double check this ~ removing the class within toolbars.rs update may not be ideal, perhaps there's a better way ~ [x] triggering ToolsToolbarInput::SwitchSelectedTool from toolbars.rs init may be redundant, double check that it isn't
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes: #427
Before this fix, we mask GTK's own shortcuts (Ctrl+Shift+D and Ctrl+Shift+I).
There is no easy way to prevent this with how we handle shortcuts.
Instead, handle those shortcuts explicitly and actively enable GTK inspector.
Since there is no good way to check whether it's currently enabled, toggle would require an additional bool in sketchboard, which could become inconsistent if the user closes the inspector window. Instead, just enable without toggle, the user then has to close the inspector window if they want to get rid of it.