Hyprland issues since .lua configuration

Bugs / FRs / Support
, ,
1

Hi,

I have just moved over from my .conf to a .lua file as 0.57 approaches. There are a couple of things I have noticed which seem to be different/ not working.

Auto started apps grab focus and switch workspace:

When starting Hyprland I would like to start certain apps in the background automatically i.e. Steam. In the .conf I have applied a window_rule to control this behavior as following:

windowrule {
    name = move-steam
    match:initial_class = steam

    workspace = 3
    no_initial_focus = on
}

This puts steam on workspace 3 but keeps my initial workspace on 1 which is opened by default (see next issue for a problem with that, too). With going to .lua I have translated this into the following:

hl.window_rule({
    name  = "move-steam",
    match = {
      initial_class = "steam"
    },

    workspace = 3,
    no_initial_focus = on
})

Using this I have noticed that the workspace automatically jumps to workspace 3 once Steam loads. I have tried replacing no_initial_focus = on with no_focus = on but the behavior is the same.

Initial workspace after starting Hyprland:

With the above rules in place Hyprland would ideally open up workspace 1 after startup. Even though it’s empty. However, it does not dreate an empy workspace 1 on my primary (left) monitor. With the above rules in place it just jumps to the workspaces stated in the rules from above.

Binds (with multiple modifiers) acting weird:

Binds seem to be acting wonky, although I believe there is a change to be implemented in 0.57. However, running hl.bind(mainMod .. " CONTROL + SHIFT + C", hl.dsp.window.close()) with local mainMod = "SUPER" does not close the focused window.
Using a hl.bind(mainMod .. " ALT + C", hl.dsp.window.close()) does work though.
So either two modifier keys in a keybind is the problem or it is something else acting strangely.

Clicking on workspaces in waybar does not switch

When clicking on a workspace number in waybar, Hyprland does not switch to that workspace. Worked flawlessly before using .lua format.

Thank you for anybody looking into this.

2

For the workspace positioning part, you will get answers from Autostarting apps switches to that workspace - #3 by majamin

As for waybar, it has been addressed by the devs in the git version.
So go ahead and install the git. It works as expected.

Use wev to check the code of a modifier you want to use.

3

Thank you for getting back to me.

Using keycodes for uncommon syms does not work:
hl.bind(mainMod .. " + code:50 + C", hl.dsp.window.close()) -- SHIFT_L does not close the window as expected.

4

This works perfectly on my setup.

hl.bind(mainMod .. " + SHIFT + C", hl.dsp.window.close())

5

@hyprm3
Sure it does. It does for me, too.

But isn’t the whole point of your link to ‘Uncommon syms / binding with a keycode’ to, well, address uncommon or specific keys with a keycode?
As in SHIFT ≠ SHIFT_L.

Using SHIFT the bind will be activated by both Shift keys SHIFT_L and SHIFT_R. Using keycodes, I can differentiate between SHIFT_L = key:50 and SHIFT_R = key:62.

But, in this case it does not matter which key you use. As the bind does not work at all using a code:50 reference.

6

yes lua can’t do left / right mods, will be impl’d in keybinds: refactor, clean up code, move to new style by vaxerski · Pull Request #15568 · hyprwm/Hyprland · GitHub

7

@shamam

I see what you mean.
Given @vaxry 's clarification, if you can’t wait for a fix, keyd is your best friend.

Install it, configure in /etc/keyd/default.conf to read

[ids]
*
[main]
rightshift = f24

Enable keyd.
You may reload the config with sudo keyd reload

I used f24 as an example (it’s usually a dead key)

You then apply the bind like so:
hl.bind(mainMod .. " + F24 + C", hl.dsp.window.close())
or any combo to your liking.

keyd is a great tool for remapping.

8

@hyprm3 @vaxry thank you guys for your feedback. :folded_hands:

As the implementation is already on the horizon, I’ll gladly wait for the release.