Awesome: RFC: don't apply rules on awesome.startup

[actionless]

What about creating an option for such behavior?

I was thinking it could be useful since the rules won't be overriding changes manually made by user.

ie if in rule it's set to run Firefox on tag 2, but user moved it manually from tag 2 to tag 3, it could be irritating what after restarting awesome it moved back based on rule.

What do you think, if such approach makes any sense?

[Veratil]

Would a property in the rule itself work? Something like ignore_on_restart?

[actionless]

yup, if it will be in the default rule -- it will give the same effect as i am proposing

[warptozero]

I think it would be nice to have that option available. I'm actually applying some rules manually so that they don't get reapplied on restart (ie. placement), so would definitely use it.

[blueyed]

I think it might make sense to have this as a default behavior even, i.e. only rules with apply_on_restart=true would be applied during restart.
The handling of floating clients gets restored via xproperties already I think for example.

[Sorky]

I like this for a restart (not sure it would be good for a cold start)

One step further would be the ability to have a way to save and restore the current client tab locations

[actionless]

current client tab locations

what's that?

[Veratil]

current client tab locations

what's that?

He means keep clients on the tab they're on between restarts. There are some instances where they don't like to stay where they're at (I've hit it before, only with multi-monitor I think).

[actionless]

you mean with elv's new tabbed layouts or?

[Veratil]

I haven't tested a lot of multi-monitor lately with git-master, but I finally attached a second monitor again. I'll have to play around again and see if it will happen to me. I'm not sure what Sorky is seeing though.

[Sorky]

current client tab locations

what's that?

I meant tag - Basically what you said - Firefox on tag 2, but user moved it manually from tag 2 to tag 3 - some way to save tag-client positions and then restore them

[actionless]

i think if rules won't be re-applied tags should be preserved

[Aire-One]

I don't like this... IMO a "restart" is synonym to "refresh" in the sense you kill the process to create a new fresh one.

In my workflow, I dynamically create tags to organize my workspace. Restart awesome means it will delete all the tags and replace clients where they should be. It's a "restore as default" action plus memory re-initialization and re-creation of widgets/wiboxes/wibars. This is the current default behavior of awesome and I think it should stay unchanged.

However, I'm genuinely interested by the fact awesome.startup applies rules. Why should the startup applies rules?

BTW, "don't apply rules on awesome.startup" seems technically impossible. At startup, all already existing clients will trigger the manage signal and rules will automatically be applied because of this:
https://github.com/awesomeWM/awesome/blob/8fe06f95d08ddecc133cc2ad1deaa86928031518/lib/awful/rules.lua#L740

[actionless]

dynamically create tags to organize my workspace

that option is proposed to be optional so it shouldn't affect anyone unless the option is enabled

[blueyed]

BTW, "don't apply rules on awesome.startup" seems technically impossible.

This is what this issue is discussion. An option to enable skipping of rules on startup.

I agree with the argument that a restart should reset things, and therefore it is likely not a good idea to enable this (skipping) by default.

Technically you can have this already via a callback where you check awesome.startup yourself.

[warptozero]

@Aire-One I think this would get it done

client.disconnect_signal("manage", awful.rules.apply)
client.connect_signal("manage", function(c)
    if not awesome.startup then
        awful.rules.apply(c)
    end
end)

However this way it's not easy to exempt specific rules that do need to be applied on restart.

It would be great to be able to set the default apply_on_restart for every rule and then override individual rules. This can be usefull for both defaults. Then whatever awesome ships with is fine, and keeping the current behavoir does sound sensible.

[warptozero]

Actually, the following seems to implement the apply_on_restart property without any problems

client.disconnect_signal("manage", awful.rules.apply)
client.connect_signal("manage", function(c)
    if awesome.startup then
        local rules = awful.rules.matching_rules(c, awful.rules.rules)
        for _,rule in ipairs(rules) do
            if rule.apply_on_restart then
                awful.rules.execute(c, rule.properties, { rule.callback })
            end
        end
    else
        awful.rules.apply(c)
    end
end)

[actionless]

@warptozero it looks fine though when i was trying it in the wild i faced a weird issue:

client buttons are not applied and also tiled client is a bit mis-aligned

i am not sure what is causing the second problem, but first seems to happen because default rule is not assigning the client keys

[actionless]

fixed:

  client.disconnect_signal("manage", awful.rules.apply)
  client.connect_signal("manage", function(c)
      if awesome.startup then
          local rules = awful.rules.matching_rules(c, awful.rules.rules)
          for _,rule in ipairs(rules) do
              if rule.apply_on_restart then
                  awful.rules.execute(c, rule.properties, { rule.callback })
              else
                  local mini_properties = {
                    buttons = rule.properties.buttons,
                    keys = rule.properties.keys,
                    size_hints_honor = rule.properties.size_hints_honor,
                    raise = rule.properties.raise, -- not sure about this one
                  }
                  awful.rules.execute(c, mini_properties, { })
              end
          end
      else
          awful.rules.apply(c)
      end
  end)

[warptozero]

Hmm that's strange, I'm not experiencing both problems. Have you added apply_on_restart to the match all clients rule?
```lua
awful.rules.rules = {
-- All clients will match this rule
{ rule = {},
apply_on_restart = true,
properties = {
...

[actionless]

of course not -- that would break floating clients' positioning

[warptozero]

Oh well then that's the problem. What I did was break it up into two parts:

    { rule = {},
      apply_on_restart = true,
      properties = {
        border_width = beautiful.border_width,
        border_color = beautiful.border_normal,
        focus = awful.client.focus.filter,
        keys = clientkeys,
        buttons = clientbuttons,
        raise = false,
        switchtotag = false,
        screen = awful.screen.preferred,
        size_hints_honor = false,
      },
    },
    { rule = {},
      properties = {
        fullscreen = false,
        maximized = false,
        placement = awful.placement.centered,
      },
    },

[actionless]

yeah, that makes sense

[Aire-One]

Oh right, @warptozero! I don't know why but I forgot we could disconnect the signal :man_shrugging:
It's a nice move and it can be implemented by the user on the rc.lua, so it shouldn't be a problem at all, for users who want to keep the old behavior, I guess.

However, if I can do a little review of this code, I don't feel good regarding the big if awesome.startup condition. This will be evaluated every time a client is managed by awesome but it's relevant only at startup. So it add more complexity at run time for a "one time" problem.
Can we use the startup or property::startup signals to connect/disconnect properly callbacks?

---

@actionless, I currently don't use floating clients and I can't check what happen to them when restarting awesome. Can you briefly describe me what's going on with them before and after this "patch"? I'm not sure I do understand the positioning thing...

[psychon]

@Aire-One I'd suggest to just ignore this "it evaluates awesome.startup every time" worry. If you do indeed want to worry about, I suggest Googling for "premature optimisation" and thinking about where this would be in https://xkcd.com/1205/ (although this XKCD does not really apply, I still think it kind-of-illustrates that this is not worth worrying above).