jbuchermn / newm

Wayland compositor
MIT License
960 stars 30 forks source link

Native bar config #87

Closed ghost closed 2 years ago

ghost commented 2 years ago

I am trying to get bemenu to show correctly. It does not. It only shows if I execute bemenu-run -c (-c for center) If I execute it like that. It show at bottom (which it should not be :) ). If I execute it normal. It shows at top, but until I press L- to show overview. But it doesn't take any input. How would you control this on newm? and how would you get the app_id for applications? I feel like if I set a should_float function. I'll get it to show correctly?

jbuchermn commented 2 years ago

This appears to be a bug, I can reproduce. I'll take a look.

should_float or the new version rules could possibly be used for that (you can see the app_id from newm-cmd debug for now). But in the end, this probably won't work satisfyingly.

ghost commented 2 years ago

This appears to be a bug, I can reproduce. I'll take a look.

should_float or the new version rules could possibly be used for that (you can see the app_id from newm-cmd debug for now). But in the end, this probably won't work satisfyingly.

Thank you for taking the time to look into this. I will see the rules configuration. I am really loving this WM so far. Well done job on this project.

jbuchermn commented 2 years ago

Thanks a lot!

I just pushed a commit that should fix placement issues. The problem was that any layer view placed on the top or bottom was assumed to be top or bottom bars, which are by default only visible after pressing "L-". That way you can simply start waybar and it works. This heuristic is disabled now which requires (if you're using waybar or sth similar) to start it using

panels = {
    'bar': {
        'cmd': 'waybar'
    },
}
CRAG666 commented 2 years ago

@jbuchermn I just tried this, and noticed a particular behavior, I have to have the following configuration so that the native bar does not overlap you on the waybar, so, I propose if the configuration options can be unified in one place

bar = {
    "enabled": False
}
panels = {
    "lock": {
        "cmd": f"{term} newm-panel-basic lock",
        "w": 0.7,
        "h": 0.7,
        "corner_radius": 50,
    },
    "bar": {"cmd": "waybar"},
}

I propose something like this:

panels = {
    "lock": {
        "cmd": f"{term} newm-panel-basic lock",
        "w": 0.7,
        "h": 0.7,
        "corner_radius": 50,
    },
    "bar": {"enabled_newm_bar": False, "cmd": "waybar"},
}
ghost commented 2 years ago

@jbuchermn I just tried this, and noticed a particular behavior, I have to have the following configuration so that the native bar does not overlap you on the waybar, so, I propose if the configuration options can be unified in one place

bar = {
    "enabled": False
}
panels = {
    "lock": {
        "cmd": f"{term} newm-panel-basic lock",
        "w": 0.7,
        "h": 0.7,
        "corner_radius": 50,
    },
    "bar": {"cmd": "waybar"},
}

I propose something like this:

panels = {
    "lock": {
        "cmd": f"{term} newm-panel-basic lock",
        "w": 0.7,
        "h": 0.7,
        "corner_radius": 50,
    },
    "bar": {"enabled": False, "cmd": "waybar"},
}

I find this kind of confusing. Bar options are for the default bar. I feel like in this way of configuration you are stating that a bar is disabled. Which bar? Waybar or default bar? But I am just a user and feel like some of the configuration options need more clarification on the wiki. For example. What does energy = {} do. focus = {} Both of these are not mentioned in the config.md. I had to read the code to find out what they do

CRAG666 commented 2 years ago

I'll document that once v3 is done, if I understand where the confusion is going, maybe instead of "enabled" it should be something like "native_bar _enabled"

jbuchermn commented 2 years ago

I agree that we should change the config (probably that is true in many places, where the current keys are not very expressive).

Thanks, @CRAG666, for documenting v0.3 config once we're there!

As for the bar, I think we should

Does that make sense?

CRAG666 commented 2 years ago

I agree that we should change the config (probably that is true in many places, where the current keys are not very expressive).

Thanks, @CRAG666, for documenting v0.3 config once we're there!

As for the bar, I think we should

* default to not showing the native bar, so you don't have to set `"enabled": False` anywhere

* Move all native bar config options from `bar` to e.g. `panels.bar.native` (or `panels.top_bar.native` & `panels.bottom_bar.native`)

Does that make sense?

It makes a lot of sense, if as proposed it seems cleaner

jbuchermn commented 2 years ago

It's implemented like that now.