Suggestions

[kjaklinovic]

I really like the idea and the concept of windowchef. I have a few suggestions on how to improve it and make it more popular and overall better. If you find those ideas good and you would like to implement some of those I would also like to contribute.

CHANGES TO WINDOWCHEF

1. When changing workspaces focus last focused window on that workspace (currently focuses the first window created in the group)
2. Make it compatible with polybar inner workspace module (posible replacement of groups with actual workspaces) - noone really wants to torture their CPU just to know what the current workspace is with no delay
3. Add new params: bar_height, bar_position and bar_monitor
4. Make window snapping relative to gaps and bar_height (especially centering)
5. New command gapless_monocle: same as full screen except it respects bar_height, bar_position and bar_monitor
6. Add extra options in initial window placement (currently window is spawn at the mouse position)
7. Option that window can always stay on top of others
8. Put_in_grid optionally takes extra two parameters that indicate how many cells will window occupy
9. New type of resizing relative to grid the window is placed in
10. If window in centered, after resizing window still remains centered
11. Being able to resize windows that are maxed verticaly and horizontaly
12. Define workspaces per minitor
13. Outer gaps (margins) per workspace

Optional: . Some windows can be borderless . When using tint2 or docky or any other taskbar, currently one is unable to focus a window using those programs

In my local build of windowchef I added parameter bar_height, but I still didn't figure out how to set it with waitron. Command returns true but there is no change in value. Also I modified full screen command so it would respect bar_height. I would add it as extra command but I'm still exploring the code. If you want to write a new wm ground up or implement any of those suggestions you can be like my mentor or smth. As I said, I really like the concept, specially placing in grid. PS. I couldn't find you mail address so I posted this here.

[tudurom]

When changing workspaces focus last focused window on that workspace (currently focuses the first window created in the group)

Good idea.

Make it compatible with polybar inner workspace module (posible replacement of groups with actual workspaces) - noone really wants to torture their CPU just to know what the current workspace is with no delay

You don't have to. Use xprop -root -spy to wait for group change events. Also, groups will never be replaced by workspaces.

Add new params: bar_height, bar_position and bar_monitor

A better idea would be per-monitor gaps.

Make window snapping relative to gaps and bar_height (especially centering)

It already is.

New command gapless_monocle: same as full screen except it respects bar_height, bar_position and bar_monitor

There is window_monocle. It should do what you're requesting with per-monitor gaps.

Add extra options in initial window placement (currently window is spawn at the mouse position)

Can you give me some examples of possible window placements?

Option that window can always stay on top of others

Very good additions, would also be very nice with EWMH hints.

Put_in_grid optionally takes extra two parameters that indicate how many cells will window occupy

It already does. I think it is also noted in the CHANGELOG.

New type of resizing relative to grid the window is placed in

There is no grid. You should be able to script that easily with window_put_in_grid.

If window in centered, after resizing window still remains centered Being able to resize windows that are maxed vertically and horizontally

Might consider that in the future.

Define workspaces per monitor

That should be scriptable? You can have a script that uses something like wmp from wmutils core that gets the coordinates of the pointer and then, using dattr from disputils you can find out where your pointer is. Then you can make your own logic for workspace switching and stuff. This is the UNIX workflow windowchef was designed for.

Outer gaps (margins) per workspace

Per monitor is better IMO. More flexible for scripting.

Some windows can be borderless

Might do someday.

When using tint2 or docky or any other taskbar, currently one is unable to focus a window using those programs

It does now, since yesterday :)

PS. I couldn't find you mail address so I posted this here.

git log

Thank you for the suggestions, it feels good to know that people are legitimately interested in my work!

[kjaklinovic]

Could you elaborate more on using xprop -root -spy with polybar ?

Idea behind gapless monocle is when using chromium for example I don't really need gaps. I just want a visible bar and a window with no borders.

Can you give me some examples of possible window placements?

Possible options for window placement: always spawn window in the center, custom (x,y) location, random location, smart placement (thought I just like the one where window in centered when spawned what is probable possible atm via script or maybe ruler).

Add new params: bar_height, bar_position and bar_monitor -> A better idea would be per-monitor gaps.

IMO it is better to define bar area per monitor. Otherwise, for example if your bar is on top one should define gaps for bottom, left, right and top+bar_height. Gapless monocle idea is not even possible then. Most of the modern wm I would say detect bars automatically. I think better customization is possible via my suggested parameters or any other way that allows your to reserve space for a bar.

Put_in_grid optionally takes extra two parameters that indicate how many cells will window occupy

That was also my issue. My list is just outdated, sorry for that.

New type of resizing relative to grid the window is placed in

If you use waitron to set window in grid, it would be cool to store that grid and make window resizable relative to its grid.

A good start would be implementing suggestion 1, 7 and 11. Suggestion (1) is something that should exist. As I said, I can add some of those features on your command and implementation idea.

[tudurom]

Could you elaborate more on using xprop -root -spy with polybar ?

Never used polybar, but I guess that it has some functionality to use a script for its contents. xprop -root -spy WINDOWCHEF_ACTIVE_GROUPS will wait for the property to change and then print to stdout its value. You get the value and update your bar with it. And it doesn't waste CPU.

Otherwise, for example if your bar is on top one should define gaps for bottom, left, right and top+bar_height. Gapless monocle idea is not even possible then.

It is possible because I've been doing this since I wrote windowchef. You don't have to define all these gaps. You only need two:

waitron wm_config gap_width all $GENERAL_GAP
waitron wm_config gap_width top $(( (GENERAL_GAP + BW) + PANEL_STATUS_HEIGHT ))

This is how it looks like:

You can see that I have gaps and I can see the bar. I only used window_monocle to achieve this.

[kjaklinovic]

Your window has borders in this example. For larger border width this won't work for me.

[kjaklinovic]

And one more thing. WINDOWCHEF_ACTIVE_GROUPS won't change if you switch to a group that has no windows.

[tudurom]

It does now, since yesterday :)

I forgot to push oops

[mtreca]

Piggybacking on this thread.

Would it be possible to add an option to make moving and resizing windows respect (ie not go beyond) the edges of the monitor they are currently in? I know it's possible to avoid this using a combination of snapping and maximizing but I have 2bwm muscle memory and I got used to this behavior.

Replying on your first comment in this thread, I think windowchef is an interesting project. I see it somewhere between 2bwm and wmutils but with simpler configuration and group support out of the box.

[tudurom]

@vxid There's a little problem here. In a multi-monitor setup, how do you move a window from a monitor to another if it's confined to a monitor?

[mtreca]

@tudurom Hmmm, that's tricky indeed.

Is there an easy way to detect if the specific edge of a monitor is connected to another by randr? If so, then one possible behavior would be to block windows on edges that are not extended by another monitor and to allow going beyond for those who are.

If the implementation is too complicated I don't think you should bother thoough, most window managers don't.