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

Proper full screen support #34

Open
jwilm opened this Issue Jan 2, 2017 · 17 comments

Comments

Projects
None yet
10 participants
@jwilm
Owner

jwilm commented Jan 2, 2017

Currently there's no full screen support in Alacritty. Doing to with glutin requires recreation of the window and thus recreation of the OpenGL context.

@jwilm jwilm added the enhancement label Jan 2, 2017

@jwilm jwilm added this to the Version 1.0 milestone Jan 2, 2017

@jwilm

This comment has been minimized.

Show comment
Hide comment
@jwilm

jwilm Jan 2, 2017

Owner

At least on macOS, there's the automagical full screen button that does the trick. It does occupy another workspace, however, and it doesn't allow stacking the full screen application on top of other apps.

Owner

jwilm commented Jan 2, 2017

At least on macOS, there's the automagical full screen button that does the trick. It does occupy another workspace, however, and it doesn't allow stacking the full screen application on top of other apps.

@davesque

This comment has been minimized.

Show comment
Hide comment
@davesque

davesque Jan 6, 2017

I can't get the fullscreen button to work on OS X 10.11.6.

Update:
Nevermind, there's an issue for this. It happens when you start alacritty from within tmux.

davesque commented Jan 6, 2017

I can't get the fullscreen button to work on OS X 10.11.6.

Update:
Nevermind, there's an issue for this. It happens when you start alacritty from within tmux.

@jimeh

This comment has been minimized.

Show comment
Hide comment
@jimeh

jimeh Jan 7, 2017

I'd would love to see a non-native full screen option for macOS. The native solution isn't great. Personally I use iTerm right now with a hotkey to toggle a full screen window's visibility, meaning it just appears on top of whatever I have open, regardless of what desktop I'm on. Via the native solution you'd be switched away to a application specific desktop which sucks.

jimeh commented Jan 7, 2017

I'd would love to see a non-native full screen option for macOS. The native solution isn't great. Personally I use iTerm right now with a hotkey to toggle a full screen window's visibility, meaning it just appears on top of whatever I have open, regardless of what desktop I'm on. Via the native solution you'd be switched away to a application specific desktop which sucks.

@jwilm

This comment has been minimized.

Show comment
Hide comment
@jwilm

jwilm Jan 8, 2017

Owner

@jimeh That's precisely what this issue is for :)

Owner

jwilm commented Jan 8, 2017

@jimeh That's precisely what this issue is for :)

@jimeh

This comment has been minimized.

Show comment
Hide comment
@jimeh

jimeh Jan 8, 2017

@jwilm Good good :)... I just wanted to point out that the native full screen implementation on OSX sucks... lol

jimeh commented Jan 8, 2017

@jwilm Good good :)... I just wanted to point out that the native full screen implementation on OSX sucks... lol

@jedahan

This comment has been minimized.

Show comment
Hide comment

jedahan commented Oct 9, 2017

@caiocutrim

This comment has been minimized.

Show comment
Hide comment
@caiocutrim

caiocutrim Dec 7, 2017

Well, it was implemented? It seems that is not working in ubuntu when I hit f11...

caiocutrim commented Dec 7, 2017

Well, it was implemented? It seems that is not working in ubuntu when I hit f11...

@jedahan

This comment has been minimized.

Show comment
Hide comment
@jedahan

jedahan Dec 8, 2017

@caiocutrim since the issue is still open I assume no one has taken a crack at it yet.

jedahan commented Dec 8, 2017

@caiocutrim since the issue is still open I assume no one has taken a crack at it yet.

@TaylorDennisLee

This comment has been minimized.

Show comment
Hide comment
@TaylorDennisLee

TaylorDennisLee Dec 19, 2017

For what it is worth, on Linux, you can install wmctrl which allows you to control windows from the terminal. In my .zshrc, I have an alias: alias wq='wmctrl -r 'Alacritty' -b toggle,fullscreen' which allows you to toggle fullscreen with the command wq. If you use tmux, you can bind this command to F11 by putting the following into your .tmux.conf:

bind -n F11 run-shell 'wmctrl -r 'Alacritty' -b toggle,fullscreen'

Notice that this works because 'Alacritty' is the title of the window. So, if your tmux config changes the title, you have to be aware of this and adjust either the new title or the key-binding/alias to match.

Also, I have found trying to invoke an alias with a tmux key-binding does not work, so just type in the entire command it references instead.

wmctrl is pretty legit. Type in wmctrl -l to get a listing of all your windows to see what to target with it. You may be able to hit Alacritty in other ways besides with the window title. I don't know what the OS X equivalent it, but if we are preserving the 'purity' of Alacritty by farming out scrollback to tmux, we might consider trying to use wmctrl for as much functionality as we can.

What are your thoughts on binding shell commands to the keys in the Alacritty config? Can you do that with other terminal emulators?

I really witsh we could change the font size without restarting Alacritty. Maybe we could think of giving the alacritty command some functionality the way the tmux command can be used within tmux to detach sessions, split panes etc. I like the 'the best UI is no UI' approach. We should remain very opposed to cluttering the UI.

TaylorDennisLee commented Dec 19, 2017

For what it is worth, on Linux, you can install wmctrl which allows you to control windows from the terminal. In my .zshrc, I have an alias: alias wq='wmctrl -r 'Alacritty' -b toggle,fullscreen' which allows you to toggle fullscreen with the command wq. If you use tmux, you can bind this command to F11 by putting the following into your .tmux.conf:

bind -n F11 run-shell 'wmctrl -r 'Alacritty' -b toggle,fullscreen'

Notice that this works because 'Alacritty' is the title of the window. So, if your tmux config changes the title, you have to be aware of this and adjust either the new title or the key-binding/alias to match.

Also, I have found trying to invoke an alias with a tmux key-binding does not work, so just type in the entire command it references instead.

wmctrl is pretty legit. Type in wmctrl -l to get a listing of all your windows to see what to target with it. You may be able to hit Alacritty in other ways besides with the window title. I don't know what the OS X equivalent it, but if we are preserving the 'purity' of Alacritty by farming out scrollback to tmux, we might consider trying to use wmctrl for as much functionality as we can.

What are your thoughts on binding shell commands to the keys in the Alacritty config? Can you do that with other terminal emulators?

I really witsh we could change the font size without restarting Alacritty. Maybe we could think of giving the alacritty command some functionality the way the tmux command can be used within tmux to detach sessions, split panes etc. I like the 'the best UI is no UI' approach. We should remain very opposed to cluttering the UI.

@jwilm

This comment has been minimized.

Show comment
Hide comment
@jwilm

jwilm Dec 22, 2017

Owner

@TaylorDennisLee font resizing is available on latest master. You should actually be able to run arbitrary commands through Alacritty key bindings as well. The default alacritty.yml should have an example.

Owner

jwilm commented Dec 22, 2017

@TaylorDennisLee font resizing is available on latest master. You should actually be able to run arbitrary commands through Alacritty key bindings as well. The default alacritty.yml should have an example.

@botverse

This comment has been minimized.

Show comment
Hide comment
@botverse

botverse Feb 19, 2018

@TaylorDennisLee thanks for that, you can still do it not knowing the window name using the id instead, with xdotool:

.tmux.conf

bind -n F11 run-shell 'wmctrl -ir `xdotool getwindowfocus` -b toggle,fullscreen'

@jwilm I didn't manage to do that in the alacritty.yml file, I guess because of the nested command

# this does not work
key_bindings:
  - { key: F11, command: { program: "wmctrl", args: ["-ir", "`xdotool getwindowfocus`", "-b", "toggle,fullscreen" ] } }

Edit:

What I did is just put this in ~/.local/bin/fullscreen

wmctrl -ir `xdotool getwindowfocus` -b toggle,fullscreen

And this in alacritty.yml:

  - { key: F11, command: { program: "fullscreen" } }

botverse commented Feb 19, 2018

@TaylorDennisLee thanks for that, you can still do it not knowing the window name using the id instead, with xdotool:

.tmux.conf

bind -n F11 run-shell 'wmctrl -ir `xdotool getwindowfocus` -b toggle,fullscreen'

@jwilm I didn't manage to do that in the alacritty.yml file, I guess because of the nested command

# this does not work
key_bindings:
  - { key: F11, command: { program: "wmctrl", args: ["-ir", "`xdotool getwindowfocus`", "-b", "toggle,fullscreen" ] } }

Edit:

What I did is just put this in ~/.local/bin/fullscreen

wmctrl -ir `xdotool getwindowfocus` -b toggle,fullscreen

And this in alacritty.yml:

  - { key: F11, command: { program: "fullscreen" } }
@yech1990

This comment has been minimized.

Show comment
Hide comment
@yech1990

yech1990 Mar 25, 2018

@botverse

It seems that alacritty only support full path program.

The following configuration work for me.

  - { key: F11, command: { program: "/home/xxx/.local/bin/fullscreen/fullscreen" } }

yech1990 commented Mar 25, 2018

@botverse

It seems that alacritty only support full path program.

The following configuration work for me.

  - { key: F11, command: { program: "/home/xxx/.local/bin/fullscreen/fullscreen" } }
@botverse

This comment has been minimized.

Show comment
Hide comment
@botverse

botverse Mar 25, 2018

@yech1990 I have ~/.local/bin in my $PATH and seems to work

botverse commented Mar 25, 2018

@yech1990 I have ~/.local/bin in my $PATH and seems to work

@yech1990

This comment has been minimized.

Show comment
Hide comment
@yech1990

yech1990 Mar 26, 2018

@botverse
It is weird. I add ~/.local/bin in to my path too.

yech1990 commented Mar 26, 2018

@botverse
It is weird. I add ~/.local/bin in to my path too.

@TaylorDennisLee

This comment has been minimized.

Show comment
Hide comment
@TaylorDennisLee

TaylorDennisLee Apr 1, 2018

Good call @botverse your approach is much cleaner. It would be kind of cool if we could write inline scripts right in the alacritty.yml file, maybe with a keyword argument for what interpreter we want to run on it, kind of like with hashbangs at the beginning of scripts.

- {key: F11, command: {interpreter:"/usr/bin/env python3", script:"import os; print(os.uname()[1]+'\n')"}

And the stdout would go right into that Alacritty window's output. Maybe it makes less sense to use python in such an instance, but there are a lot of things you can do with Bash one-liners, and it would be cool if you could avoid having to write a script to do them, as @botverse tried to do above. The default stdin for one of these commands could be everything currently displayed in the Alacritty window.

I say make Alacritty as versatile and powerful as possible, just don't give it a drop-down menu or any kind of gui anything.

TaylorDennisLee commented Apr 1, 2018

Good call @botverse your approach is much cleaner. It would be kind of cool if we could write inline scripts right in the alacritty.yml file, maybe with a keyword argument for what interpreter we want to run on it, kind of like with hashbangs at the beginning of scripts.

- {key: F11, command: {interpreter:"/usr/bin/env python3", script:"import os; print(os.uname()[1]+'\n')"}

And the stdout would go right into that Alacritty window's output. Maybe it makes less sense to use python in such an instance, but there are a lot of things you can do with Bash one-liners, and it would be cool if you could avoid having to write a script to do them, as @botverse tried to do above. The default stdin for one of these commands could be everything currently displayed in the Alacritty window.

I say make Alacritty as versatile and powerful as possible, just don't give it a drop-down menu or any kind of gui anything.

@chrisduerr

This comment has been minimized.

Show comment
Hide comment
@chrisduerr

chrisduerr Apr 1, 2018

Collaborator

@TaylorDennisLee You should already be able to do this, you could for example use sh as command and then execute any command you want to execute.

Collaborator

chrisduerr commented Apr 1, 2018

@TaylorDennisLee You should already be able to do this, you could for example use sh as command and then execute any command you want to execute.

@Sas-18

This comment has been minimized.

Show comment
Hide comment
@Sas-18

Sas-18 Apr 29, 2018

program: "wmctrl", args: ["-r", ":ACTIVE:", "-b", "toggle,fullscreen" ]

For what it's worth, this code above also works directly from alacritty.yml, no external script nor xdotool required; it's the :ACTIVE: option for wmctrl which allows to avoid using xdotool to get our window ID. If nothing else, this should be a bit quicker, with fewer 3rd parties involved. :)

Also, unsure if it's still an issue (or ever was) but an absolute path to wmctrl isn't required here, since wmctrl is (should be) in my/your $PATH.

Sas-18 commented Apr 29, 2018

program: "wmctrl", args: ["-r", ":ACTIVE:", "-b", "toggle,fullscreen" ]

For what it's worth, this code above also works directly from alacritty.yml, no external script nor xdotool required; it's the :ACTIVE: option for wmctrl which allows to avoid using xdotool to get our window ID. If nothing else, this should be a bit quicker, with fewer 3rd parties involved. :)

Also, unsure if it's still an issue (or ever was) but an absolute path to wmctrl isn't required here, since wmctrl is (should be) in my/your $PATH.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment