Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added mode indicator #1194

Merged
merged 25 commits into from
Jun 24, 2023
Merged

Added mode indicator #1194

merged 25 commits into from
Jun 24, 2023

Conversation

AndreasArvidsson
Copy link
Collaborator

@AndreasArvidsson AndreasArvidsson commented May 13, 2023

Will show different colors for sleep, dictation, mixed, command/other modes
Screenshot 2023-05-13T18-04-21

Copy link
Collaborator

@rntz rntz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks sensible, but I need to test it and I'm away from computer atm. Probably want a default=False for the activation setting so that if the .talon file gets deleted (a thing users are supposed to be able to do) the Python file doesn't start erroring.

plugin/mode_indicator/mode_indicator.py Outdated Show resolved Hide resolved
Copy link
Collaborator

@pokey pokey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't tested but looks good to me. Gradient would be nice but prob don't need it to be that fancy

plugin/mode_indicator/mode_indicator.py Show resolved Hide resolved
plugin/mode_indicator/mode_indicator.py Show resolved Hide resolved
@pokey
Copy link
Collaborator

pokey commented May 14, 2023

Probably want a default=False for the activation setting so that if the .talon file gets deleted (a thing users are supposed to be able to do) the Python file doesn't start erroring.

Yeah good point. I think the standard thing here would be to use defaults for everything and then have the settings commented out in the settings file, but I think just doing that for activation setting is reasonable. Then can have a line that's commented out in the settings file that will activate it when uncommented

@AndreasArvidsson
Copy link
Collaborator Author

AndreasArvidsson commented May 14, 2023

Probably want a default=False for the activation setting so that if the .talon file gets deleted (a thing users are supposed to be able to do) the Python file doesn't start erroring.

Yeah good point. I think the standard thing here would be to use defaults for everything and then have the settings commented out in the settings file, but I think just doing that for activation setting is reasonable. Then can have a line that's commented out in the settings file that will activate it when uncommented

Initially I had all the defaults in the python file but after a lengthy discussion with @phillco we decided that the Talon file and the python file is part of the plugin and if you don't want it you can just delete the entire folder.
There is something really nice about having all the default values in a Talon file and not having things be commented out. We could of course have all defaults in two places but we decided that if it's just going to be in one place then the Talon file is probably the best.

@phillco
Copy link
Collaborator

phillco commented May 14, 2023

Yeah, I think having commented-out settings that duplicate the defaults in the Python file is messy, and might encourage the user to change the defaults in the Python file instead, since those are not commented out. It's also an invitation for the two sources of truth to drift over time.

I think the deletion behavior we want is to encourage plugin folders to be isolated, so that the user can delete the entire plugin without causing problems (ie there aren't references to it from outside of the plugin, as is the case with, for example, the mouse grid). That's generally the behavior we see novice users do: they see an entire folder of functionality that they don't want, and delete it, and we should try to make that possible.

(If a dependency is necessary, it should go the other way -- ie, core defines actions as extension points that are implemented by the plugin. Although I guess we would still have warnings if they were empty, hmm.)

Defaulting mode_indicator_show=False seems like a good move though.

@AndreasArvidsson
Copy link
Collaborator Author

@pokey Gradient added as per your request :D

Boolean is not supported in public
settings():
# Don't show mode indicator by default
user.mode_indicator_show = 0
# 30pixels diameter
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're multiplying it by the scale factor, then these aren't necessarily pixels. For example, on my screen, this becomes a diameter of 120px.

Suggested change
# 30pixels diameter
# Diameter (in resolution independent points).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still not sure that point is more clear to people.

@AndreasArvidsson
Copy link
Collaborator Author

@lunixbochs Looks like screen scaling is applied automatically on mac, but not on windows. Is that a bug or something that we should work with?

@nriley
Copy link
Collaborator

nriley commented May 27, 2023

Another Mac versus Windows difference that results in inconsistent behavior in the mode indicator appears to be the corner of the window that stays fixed when resizing a canvas:

Mac:

>>> from talon.canvas import Canvas; canvas = Canvas.from_rect(Rect(0,0,0,0)); canvas.resize(20,20); canvas.rect
Rect(0.0, -20.0, 20.0, 20.0)

Windows:

>>> from talon.canvas import Canvas; canvas = Canvas.from_rect(Rect(0,0,0,0)); canvas.resize(20,20); canvas.rect
Rect(0.0, 0.0, 20.0, 20.0)

@lunixbochs — should this behavior be consistent cross-platform in core Talon or should we be accommodating it in our Python code?

@AndreasArvidsson — in the meantime you can resize then move to ensure that the indicator does not appear off the top of the screen using the default settings on Mac.

@AndreasArvidsson
Copy link
Collaborator Author

@nriley I have now updated it so it resizes before move. Please try it out again.

@phillco
Copy link
Collaborator

phillco commented Jun 24, 2023

I've been running with this for a week and no longer notice any oddities with the indicator relocating after resuming/logging in from sleep, which I saw in the previous version (previously I would see it would shift up several hundred pixels out of the dock area, fixed by a Talon restart)

Copy link
Collaborator

@phillco phillco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Colors look good to me.

plugin/mode_indicator/README.md Outdated Show resolved Hide resolved
plugin/mode_indicator/README.md Outdated Show resolved Hide resolved
@phillco phillco merged commit 7cf33e2 into main Jun 24, 2023
1 check passed
@phillco phillco deleted the mode_indicator branch June 24, 2023 16:20
MartinRykfors pushed a commit to MartinRykfors/knausj_talon that referenced this pull request Jul 4, 2023
Will show different colors for sleep, dictation, mixed, command/other
modes
<img width="30" alt="Screenshot 2023-05-13T18-04-21"
src="https://github.com/knausj85/knausj_talon/assets/3511326/5b6007b6-18fd-4bc5-a91d-7c2747a0c16b">

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Michael Arntzenius <[email protected]>
Co-authored-by: Phil Cohen <[email protected]>
blyons333 pushed a commit to blyons333/knausj_talon that referenced this pull request Aug 11, 2023
Will show different colors for sleep, dictation, mixed, command/other
modes
<img width="30" alt="Screenshot 2023-05-13T18-04-21"
src="https://github.com/knausj85/knausj_talon/assets/3511326/5b6007b6-18fd-4bc5-a91d-7c2747a0c16b">

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Michael Arntzenius <[email protected]>
Co-authored-by: Phil Cohen <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants