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

Enhancement proposal for issue #3162 #3320

Closed
wants to merge 3 commits into from
Closed

Enhancement proposal for issue #3162 #3320

wants to merge 3 commits into from

Conversation

leoagomes
Copy link

Added a variant of the scratchpad show command, scratchpad show [--hide-if-visible] [on] output <name> as a possible solution for #3162 .

From my comment on the issue:

I agree that it doesn't make much sense to assign the scratchpad (workspace) to an input, so I propose a variant of scratchpad show is added: scratchpad show [--hide-if-visible] [on] output <name>. This would behave similarly to how scratchpad show behaves: (i) running it while focusing a scratchpad window on the target output ("") hides the window; running it without focusing a scratchpad window brings up (on the target output) either (ii) an unfocused scratchpad window on the target output's active workspace or (in case there aren't any) (iii) an unfocused scratchpad window on any of the workspaces in the target output or (iv) an unfocused scratchpad window on any (non-internal) workspace or (v) brings up the highest window on the scratchpad workspace focus stack. This would make it so running scratchpad show on output current results (I believe) in the same behavior as running scratchpad show, but a user could bind a key to show their scratchpad on a specific monitor.

and

The idea behind --hide-if-visible is that it will hide not only hide the scratchpad window if it is focused (behavior i) but also hide the scratchpad window in the active workspace of the target output.

For more of the context, please check the issue.

I tried my best to mirror the styles I saw in source files, but please let me know if anything should be done differently.

Added 'scratchpad show [on] output <name>' command.
@orestisfl orestisfl changed the title Enhancement proposal for issue #3162. Enhancement proposal for issue #3162 Aug 21, 2018
@orestisfl
Copy link
Member

@Airblader what do you think of this PR on a higher level? If it sounds good to you I might do a first review pass.

@Airblader
Copy link
Member

Yes, on a high level I think this sounds fine.

@orestisfl orestisfl assigned orestisfl and unassigned orestisfl Aug 27, 2018
@orestisfl orestisfl self-assigned this Oct 2, 2018
if (strncmp(name, "__", strlen("__")) == 0) {
LOG("You cannot show the scratchpad on an i3-internal output (\"%s\").\n",
name);
ysuccess(false);
Copy link
Member

Choose a reason for hiding this comment

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

Use yerror("You cannot show the scratchpad on an i3-internal output (\"%s\").\n", name); instead of LOG + ysuccess

Copy link
Author

Choose a reason for hiding this comment

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

Later in the code I use ELOG + ysuccess. Considering there is a difference in the printed message, should I yerror them as well?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah; if the command failed due to an error, we should use yerror to return this to the client that started the IPC request.

* focused (or hide_if_visible is true and it is visible on the target output)
* it will hide the window again.
*/
bool scratchpad_show_on_output(Con *con, Output *current_output, Output *output,
Copy link
Member

Choose a reason for hiding this comment

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

current_output is not being used

@@ -210,6 +210,157 @@ bool scratchpad_show(Con *con) {
return true;
}

/**
Copy link
Member

Choose a reason for hiding this comment

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

/*

return;
}

// TODO: remove duplicate code
Copy link
Member

Choose a reason for hiding this comment

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

Use HANDLE_EMPTY_MATCH;

}
}

/* ? is there a reliable way of starting from the most recently focused
Copy link
Member

Choose a reason for hiding this comment

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

Why do you need the more recently focused workspace?

Copy link
Author

Choose a reason for hiding this comment

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

It is not that I necessarily need the more recently focused workspace, I mostly need the current workspace that is on display at the target output. I'd like to check for scratchpad windows on that workspace first, since it'd be the one the user would intuitively like to focus on.

* focused (or hide_if_visible is true and it is visible on the target output)
* it will hide the window again.
*/
bool scratchpad_show_on_output(Con *con, Output *current_output, Output *output,
Copy link
Member

Choose a reason for hiding this comment

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

I feel that we should merge this function with scratchpad_show to reduce duplicate code.

@Airblader Airblader added the waiting Waiting for feedback/changes from the author of the issue/PR. Make sure to notify us with a comment. label Nov 6, 2018
@Airblader
Copy link
Member

@leoagomes Are you going to continue your work on this?

@leoagomes
Copy link
Author

I can continue to work on this, just not at the moment, as the end of the semester is near and I have to finish multiple projects. When December comes, I'll have time to address the proposed changes.

@Airblader
Copy link
Member

Airblader commented Nov 10, 2018

That's fine, thanks for the reply. Good luck with your studies!

@orestisfl
Copy link
Member

Feel free to reopen & finish this whenever you have the time.

Best of luck with your studies!

@orestisfl orestisfl closed this Mar 30, 2019
@orestisfl orestisfl added stale Issue or PR has become stale and will be closed soon and removed waiting Waiting for feedback/changes from the author of the issue/PR. Make sure to notify us with a comment. labels Mar 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Issue or PR has become stale and will be closed soon
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants