Add 'max_window_width' feature #482

hertg · 2021-09-16T12:47:15Z

This PR addresses my feature request #475.

It allows setting a max_window_width in the configuration file.
As suggested by @VuiMuich in #475 (comment), the max width can be set globally or on a per-workspace level. A per workspace configuration takes presedence over the global configuration.

Setting this configuration is optional, if it isn't configured, layouts will behave as they did before, by filling the complete workspace width.

The max width will be applied to every layout, as I've updated the code of workspace.width() to account for this configuration. Because of that, the method now requires a parameter of window_count: usize so it can calculate the correct width.

Example
In this example, a global configuration of max_window_width = 2100 has been configured. The monitor has a resolution of 5120x1440.

I would appreciate some feedback on the code, and am happy to change anything if it goes against the projects architecture or best-practices. As I have only worked in smaller scale Rust projects, it was a bit hard to navigate the code at first. Is there some form of documentation about the project architecture available anywhere? I wasn't able to find a summary anywhere in the markdown files or the Github Wiki. Such a document would be pretty helpful for first-time contributors.

I tested the feature with a single and with multiple workspaces and it works as intended. I also ran all the tests, fmt, and clippy successfully. However there are some things I was unsure if I did them correctly:

I added a max_window_width variable to the screen struct, because I can't access the workspace configuration in the screen_create_handler.rs where the workspace gets created, so I have to get the workspace's max_window_width value directly from the screen.
I kept the original workspace.x() and workspace.width() as workspace.x_without_window() and workspace.width_without_window() respectively (I can rename those if you have a better alternative). The only place where I still call those is from the snap feature in window_move_handler.rs, because I (think) I don't have access to the workspace's window-count there.
This has the side effect that the window snap feature still snaps to the edge of the original workspace, and not to the edge of the outer windows. But maybe that's something you'd expect? I'm unsure because I never use the snap feature... I think it is a bit hard to use, because the window always jumps around if I don't hit the exact pixels where it snaps.

I will provide documentation for the feature in the Github Wiki after the PR is merged. Please let me know if this needs documentation anywhere else :)

…eds the max_window_width * window_count, update all layouts to use the new method on workspace

VuiMuich · 2021-09-16T17:49:35Z

This is great! And also the commit message is awesome 😎, thanks!

I indeed think that the _without_window feels a bit unclear, but I have not yet a better idea. Maybe _blank_workspace? Or add a comment how it's meant? Idk.

Besides that and my in-line question, this looks really good.

Regarding that inline comment: maybe at some point we might consider refactoring these matches into its own function? But this might very well be its own PR.

VuiMuich · 2021-09-16T19:42:43Z

I would appreciate some feedback on the code, and am happy to change anything if it goes against the projects architecture or best-practices. As I have only worked in smaller scale Rust projects, it was a bit hard to navigate the code at first. Is there some form of documentation about the project architecture available anywhere? I wasn't able to find a summary anywhere in the markdown files or the Github Wiki. Such a document would be pretty helpful for first-time contributors.

I agree we could use a lot better code documentation, I think the wiki should be more for user documentation (but could also use a bit more love, although it's not too bad lately, I guess).
Maybe somewhere between the finish of @cecton's rework and before the merge of #292 we could do call to arms to all contributors and for a while only accept PRs with either code quality improvements or adding documentation. (And fixing bugs of course.)

mautamu · 2021-09-16T19:49:29Z

Maybe somewhere between the finish of @cecton's rework and before the merge of #292 we could do call to arms to all contributors and for a while only accept PRs with either code quality improvements or adding documentation. (And fixing bugs of course.)

Could also be useful to time that around the PR that pushes us to Rust 2021.

hertg · 2021-09-16T20:15:54Z

I indeed think that the _without_window feels a bit unclear, but I have not yet a better idea. Maybe _blank_workspace? Or add a comment how it's meant? Idk.

I initially had something like width_ignoring_window_width_config but that was very long and also felt a bit unclear. I don't think the _blank_workspace is much clearer than _without_window, but I also can't think of better alternatives that aren't obnoxiously long.

Well, instead of having to find a good name for that method, we could also simply get rid of it. It's only used in the window-snap feature right now, mainly because I didn't have access to the window_count there. We could change that by either:

Get access to the current window-count somehow from the window-snap code, so I can pass it to the workspace.width(window_count) method.
Get access to the current window-count from the workspace directly, making the new window_count parameter obsolete. It felt a little bit weird that I had to pass this value from all the layouts to the width() method.

Maybe one of those is already possible by accessing the value through some existing properties (?), or maybe those are bad ideas... As I've said, I don't understand most of the code/project structure yet.

Besides that and my in-line question, this looks really good.

What do you mean with in-line question? Do you mean a direct comment on the code? If so, I can't find that. I think you have to submit a PR review before others can see those comments.

VuiMuich · 2021-09-16T17:29:17Z

src/layouts/center_main.rs

@@ -64,39 +64,41 @@ pub fn update(workspace: &Workspace, windows: &mut Vec<&mut Window>, tags: &mut
        return;
    }

+    let workspace_width = workspace.width(window_count);


I think I liked it better with keeping the function call in the match arms, since it is more clear when reading the code the width is calculated based on the number of windows.
But this is just a personal preference.

I extracted this to a variable for two reasons:

If I didn't extract this the line gets a bit long and fmt would force me to add a line break like here.

At most places where I replaced it, declaring this variable also prevents multiple unnecessary calls to the width() method. While I don't think that the method is particularly expensive, it's still a performance improvement. Which admittedly might be very small. :)

I see that I was a bit inconsistent about doing that, if there is a general preference of the maintainer(s) whether to create those variables or not, I can further adapt the code in the layouts.

Yea, I get that.
The fmt suggestion is a bit odd. I would have expected more something like this (note: am on mobile again, so the actual amount of indentation might not be fmt compliant):

_ => (workspace .width(window_count) as f32 / 100.0 * workspace .main_width(tags)).floor() as i32,

I guess we leave this as you suggested and with the layout-handler coming at some point there is quite a bunch of refactoring coming ahead anyways.
I think we could move almost all these matches to a dedicated function then.

I agree with @hertg mostly with reducing calls as .width now has more overhead.

VuiMuich · 2021-09-16T19:17:52Z

src/handlers/screen_create_handler.rs

@@ -11,6 +11,7 @@ pub fn process(manager: &mut Manager, screen: Screen) -> bool {
        screen.bbox,
        manager.tags.clone(),
        manager.layouts.clone(),
+        screen.max_window_width.or(manager.max_window_width),


One more thing:
If we could try to calculate this from workspace sizes in the config would be really good to be more consistent from the users view.
Can't we get the actual workspace size anywhere we have the workspace by workspace.xyhw?

I don't know if this is a general comment or if it is directed at me.
Unfortunately, I couldn't wrap my head around what xyhw and bbox exactly stand for, so I don't fully understand the comment. I'll try to dig into that the next time I work on the code.

Oops, totally missed to come back to this one.
But at the point I commented on this I hadn't understood yet, you are actually changing the workspace size, so I guess this should be good.

VuiMuich · 2021-09-16T20:56:35Z

I initially had something like width_ignoring_window_width_config but that was very long and also felt a bit unclear. I don't think the _blank_workspace is much clearer than _without_window, but I also can't think of better alternatives that aren't obnoxiously long.

Yeah, I didn't like blank_workspace either.

Well, instead of having to find a good name for that method, we could also simply get rid of it. It's only used in the window-snap feature right now, mainly because I didn't have access to the window_count there. We could change that by either:

That might work as well 😬

Get access to the current window-count somehow from the window-snap code, so I can pass it to the workspace.width(window_count) method.

Get access to the current window-count from the workspace directly, making the new window_count parameter obsolete. It felt a little bit weird that I had to pass this value from all the layouts to the width() method.

Maybe one of those is already possible by accessing the value through some existing properties (?), or maybe those are bad ideas... As I've said, I don't understand most of the code/project structure yet.

I totally feel you here. There are still parts of the code I am having a hard time figuring out whats going on. (to be fair though, I am by no means a seasoned developer and started learning Rust basically the same time I started getting onto this project 🤷‍♂️)
That said: IMO the snap feature would be a candidate for some major rework anyways. So maybe replace width_without_window with a snap_zone function?
As a side note: On my personal wish list for an improved snap_to_tile would then also be a preview, kind of like bspwm does with showing an empty window-frame where the next window will get placed (don't remember the exact mode rn)

What do you mean with in-line question? Do you mean a direct comment on the code? If so, I can't find that. I think you have to submit a PR review before others can see those comments.

Oh, right, sry. I was writing this on mobile and missed to send the review.

hertg · 2021-09-16T22:59:18Z

That said: IMO the snap feature would be a candidate for some major rework anyways. So maybe replace width_without_window with a snap_zone function?

That sounds like a pretty good idea to me. I can look into this snap thing and change the _without_window method to something specific for the snap behavior. If anyone has another suggestion, let me know. Otherwise I'll probably start to refactor that tomorrow or on the weekend. :)

AethanFoot · 2021-09-17T10:05:28Z

The code seems good, I find it a bit weird as you are less limiting the size of the window but its container (the workspace). Because of this we would need clear code documentation (comments) to help new contributors. (Idk how possible or easy it would be to make it an actual limit on the window, which could allow in the future per app sizes and to limit the size of floating windows. If this is a bit much don't worry). Another note would be to give the user the option to set a percentage of the workspace width (This could be set as a float for easier differentiation).

With the method naming, I feel keeping the original the same as it was and change the new method to something like width_limited() or width_computed().
Thanks.

PS I should have time soon to actually start #448, or should I wait for #472 now to save @cecton extra work.

hertg · 2021-09-17T10:33:19Z

The code seems good, I find it a bit weird as you are less limiting the size of the window but its container (the workspace).

I totally agree, and it felt weird doing so. The reason why I did was because of the IncreaseMainWidth functionality. As a user of this feature, I don't necessarily want the windows to be of exactly this max-size, because then I wouldn't be able to dynamically resize the master window as shown below. I don't actually care about the individual windows max-width that much, I mainly just don't want one window to fill the full monitor width of 5120px 😄. So I guess in some way, my goal is to actually limit the "workspace" width.

Another note would be to give the user the option to set a percentage of the workspace width (This could be set as a float for easier differentiation).

Do you mean for the max_window_width configuration or as an alternative config key? The configuration is typed as an i32 right now. I'm not sure if it might be a bit confusing if I change that to f32 and interpret it as pixel as soon as it doesn't have a decimal point.

With the method naming, I feel keeping the original the same as it was and change the new method to something like width_limited() or width_computed().

Yeah that naming sounds pretty self-explanatory, I can change it to something like that.

AethanFoot · 2021-09-17T10:57:50Z

Do you mean for the max_window_width configuration or as an alternative config key? The configuration is typed as an i32 right now. I'm not sure if it might be a bit confusing if I change that to f32 and interpret it as pixel as soon as it doesn't have a decimal point.

You could use a different key or you could use an enum, e.g.

pub enum MaxWidth {
    Percentage(f32),
    Pixel(i32),
}

Similar to margins. Where the pixels can be calculated and set in the same place in screen_create_handler.
Thanks.

lex148 · 2021-09-17T12:40:03Z

@hertg nice work here. I will give this a test today and then merge if everyone is happy with it. @hertg would you mind resolving the merge conflicts. i'm excited to get this one pulled in :)

hertg · 2021-09-17T14:40:02Z

@hertg nice work here. I will give this a test today and then merge if everyone is happy with it. @hertg would you mind resolving the merge conflicts. i'm excited to get this one pulled in :)

Sure. I'll address some feedback I got from the other people and then resolve the conflicts. I'll probably have some time for that tomorrow. :)

VuiMuich · 2021-09-17T17:02:28Z

Ooh, so much for reading on mobile. I totally missed the point, that you are actually limiting workspace width.
I actually quite like this move, but agree that this should be explicitly mentioned in commentary.
Also I think even more it would be better if possible to calculate the limit based on the workspace width in the config.
Right now I fail to find, how workspace size is handled differently if or if not configured in config.toml, so maybe we could also handle the default case more explicitly, as well?

Regarding the snap rework: thanks for volunteering, I'll open an issue for this later, to better keep track of the ideas.

VuiMuich · 2021-09-17T17:23:50Z

PS I should have time soon to actually start #448, or should I wait for #472 now to save @cecton extra work.

Would it make sense to rebase #448 to #472? I mean I'd love to have layouts per tag better yesterday than now 😊, but I guess I need to train my patience...

hertg · 2021-09-18T16:23:45Z

So I'm working on the PR right now, and I found a possible solution to also fix the weird flickering in the snap feature.
The issue is pretty obvious, the should_snap() checks the current xyhw of the window to check if it lies within the "snap zone". If it does, the window is re-positioned to wherever it should be when tiled. This means the window is tiled immediately and no longer floating, even if the user hasn't let go of the window yet. On the next move-event the window xyhw is set to the position where its tiled, so it obviously no longer is within the "snap zone".

A pretty easy solution for this would be to always check the windows float position, even if it isn't floating. Because we don't really care about the windows current tile position to check whether it should snap.

My problem is that I don't know how to get the windows floating position when it's currently not floating. There is the window.floating variable, but I don't understand what that stands for. It's some kind of offset, but offset to what? If I was able to easily get the windows actual floating xhyw (rather than an offset), I could easily fix the problem. Maybe that's just a matter of combining it with the correct property? I don't know which though 😄

To get this PR moving, I can stash the changes I made to the snap code and address them later, as it is a pre-existing issue and not a regression introduced here.

Btw. As was asked for here, it would be great if there was a community discord or something. Having such a place to ask questions about the code or to share knowledge would be great. It seems a bit awkward to ask quick questions via Github. What do you think about that?

…es instead of multiple method calls in layouts

AethanFoot · 2021-09-18T17:59:45Z

I don't mind making and setting up a server, however @lex148 would you prefer to set it up? Shall we create an issue for suggestions for it, or shall we wing it and see what everyone feels once added.
Thanks.

hertg · 2021-09-18T20:08:04Z

Alright, so I've updated the code and addressed your feedback:

More consistent use of variables for workspace_x and workspace_width in layouts to prevent unnecessary method calls and improve performance
Renamed the width_without_window() back to width() and named the new method width_limited(window_count) instead. Also added comments to those methods. I think it is much clearer this way.
As proposed by @AethanFoot The new max_window_width configuration can now be either an absolute pixel value (i32) or a relative percentage value (f32). Percentage can be set as value between 0 and 1. (0.5 => 50%)
Added a new Size model to represent sizes that can be relative (percentage) or absolute (pixel). I named it generic by design, in case the enum would be useful in other places. Let me know if you can think of a better alternative than Size or if you would prefer not to have a separate model just for that.

That's all for now. We can address the snap issue in a future PR :)

VuiMuich · 2021-09-19T15:13:32Z

Wow, this is looking super great now!
Sorry for missing out on most of the convo the past days.

I'll open an issue to keep track of the snap-rework ideas right away.

stevensonmt · 2021-09-20T02:48:12Z

I like this feature a lot and the code looks great. Conceptually though this seems like a different set of layouts rather than a setting for a window or workspace. Would it be feasible to create additional layouts that take the max_width setting from config.toml? This would make it easy to sort of toggle the feature on off by having both Monocle and MonocleMaxWidth enabled.

VuiMuich · 2021-09-20T04:39:31Z

I like this feature a lot and the code looks great. Conceptually though this seems like a different set of layouts rather than a setting for a window or workspace. Would it be feasible to create additional layouts that take the max_width setting from config.toml? This would make it easy to sort of toggle the feature on off by having both Monocle and MonocleMaxWidth enabled.

But as shown in one of the comments by @hertg this feature actually mixes very well with several layouts, especially when viewing more windows then a single one as monocle would.
More dynamic control of some features might actually be nice, but could be added nicely in another PR.
One idea I had quite a while ago would be a new command ConfigReload that reloads specific config elements (Keybinds, Tag IDs etc.) without restarting the worker. This could be even extended by a autoreload on file change option.

stevensonmt · 2021-09-20T05:46:03Z

Sorry, I should have clarified, Monocle was simply an example. It would mean adding layout enum variants for each layout you want a max_width option enabled.

hertg · 2021-09-20T12:36:54Z

Would it be feasible to create additional layouts that take the max_width setting from config.toml? This would make it easy to sort of toggle the feature on off by having both Monocle and MonocleMaxWidth enabled.

I'm not sure if creating completely separate layouts for this is better than applying the config to the existing ones, it would lead to a lot of duplicate code. If toggling the max-width feature is something people want in the future, there probably is a more user-friendly approach to achieve that than having to switch layouts.

Edit: Sorry, I sent the comment too early

You did remind me of something I missed though. I developed this feature, mainly with the CenterMaster layouts in mind. As it stands right now, it behaves a bit strange because the workspace limitation is based on the window_count rather than on the amount of columns. This leads to a bit of a strange behavior in the Monocle layout specifically, where the visible window just gets bigger as you open more windows..

The same goes for two column layouts, if the specified max-width is smaller than half of the workspace width.

Or any vertical stack layout

I should probably patch that, but I need some feedback on how the layouts should behave when the max_window_width configuration is set. I can think of the following options, let me know if you have more ideas:

Leave it as is, the workspace-width is limited based on the amount of open windows
Which is kinda weird
Limit the workspace-width based on the amount of columns, rather than the amount of windows
Leads to some of the available space to never be used in certain layouts
Ignore the max-window-width configuration in layouts like Monocle
Really just ignores the issue without addressing it, because the same would happen even in 3-column layouts, if you go wild and specifiy the max_window_width to be smaller than a third of the workspace width 😝

Personally, I'd probably prefer the second option, the only "drawback" of that is the following:

If you set a max_window_width smaller than your workspace width, 1-column layouts like Monocle will never fill the entire workspace
If you set a max_window_width smaller than half your workspace width, any 2-column layout will never fill the entire workspace
and so on...

I don't think that's e big issue though, if you have an ultra-wide monitor and set a max_window_width then you probably don't mind about a bit of unused space, if you really want to use all of the space you have, you probably want to switch to layouts that have 3+ columns anyway...

Do you guys have any opinion or other ideas? I would really appreciate hearing from people that also use ultra-wide monitors (34' / 49').

When should I address that? Personally I never use anything different than the CenterMain layouts on my 49' monitor, because of that, this isn't really a big issue for me. But my preference is not applicable to all users.

If this PR blocks other contributions from moving on, it's probably better to merge it as is and patch that later. If it doesn't, I can patch it directly here after considering the feedback.

AethanFoot · 2021-09-20T15:35:21Z

I would say the second option, as if the user doesn't want wasted space they would be best splitting the monitor into multiple workspaces. If this option becomes togglable per layout used, this would also solve the issue (as a note to this we may want to expand and/or rewrite the layout code to allow for the expanding options).

Thanks.

stevensonmt · 2021-09-20T16:15:57Z

Would it be feasible to create additional layouts that take the max_width setting from config.toml? This would make it easy to sort of toggle the feature on off by having both Monocle and MonocleMaxWidth enabled.

I'm not sure if creating completely separate layouts for this is better than applying the config to the existing ones, it would lead to a lot of duplicate code. If toggling the max-width feature is something people want in the future, there probably is a more user-friendly approach to achieve that than having to switch layouts.

Fair enough. I don't think it would have to be duplicate code necessarily. The max_width variants could call the regular variants but passing different dimension parameters based on the max width setting. In any case it looks like this is going to work in the paradigm you've already started so I won't belabor the issue. Cool feature.

hertg · 2021-09-20T16:47:55Z

so I won't belabor the issue. Cool feature.

You've got a point though, being able to dynamically toggle the width limitation might be cool. But I would personally prefer that to be toggleable dynamically per tag or something, rather than having to change layouts to toggle it. Being able to dynamically increase or decrease the max_window_width could also be quite useful.

But for the time being, it's probably better to go forward with this in the current state and let people use the feature in its basic form. If any pain-points arise or such additional feature-requests are wished for after people used it, I'll be happy to extend the functionality of this new feature in a future PR :)

VuiMuich · 2021-09-20T17:43:46Z

Personally I'd say this is ready to merge and these minor issues can be patched later on. But to be fair I only use a 14" Laptop 😛 and if I had a external monitor with the above aspect ratio I'd probably configure two square workspaces left and right and the rest in the center.

This reminds me, that at some point we had a feature request or discussion in the comments of one issue, about a 'fullscreen over all workspaces'. Which would also be nice, and might not being too far fetched as this PR proves, that we are actually capable of dynamic workspace sizes, which is awesome, and I believe quite unique.

Another idea that came to mind while reading this, was if it might be useful to have an optional config field allow_max_window_size = [] (name open for debate) that holds a list of layouts that use this feature.
I think deriving layouts with just this little feature addition might lead to a confusing amount of layouts.
If more control over this feature is desired I suggest we discuss this in a dedicated issue/discussion or on discord 🙂
We may want to keep in mind that this is quite a niche feature; at least I believe it is at the moment.

VuiMuich · 2021-09-20T17:52:16Z

Ok, you all rocketed past me, while I was writing my last comment on the subway 😂

And I was just about to write if we might want to toggle this feature, but thought maybe keep this for a later discussion.

I believe with gathering more and more dynamic and togglable features we are at a point where an actually soft reload or CongigReload, as I dubbed it in other places, would really be the next step.

hertg · 2021-09-20T21:31:45Z

I would say the second option

Update
I changed the behavior to limit the workspace width based on the column-count, rather than the window-count. I think it does make more sense like that.

In the demonstration below, I have 7 windows open and am switching through the different layouts. The max_window_width is set to 0.4 (40%).

As you can see, if you want to take advantage of the full monitor width, the layouts CenterMain, CenterMainBalanced, EvenHorizontal or GridHorizontal make the most sense on such an ultra-wide monitor.
There is already quite a lot of options to influence the behavior by tweaking the configured value. Simply setting the max_window_width to 0.5 would even make the 2-column layouts take advantage of the full available space. But I actually prefer it to have narrower, more centered windows when there are only 2 columns.

We may want to keep in mind that this is quite a niche feature; at least I believe it is at the moment.

I agree that this is a pretty niche feature, that's why we should keep the feature as basic as possible for now. But a lot of WMs aren't really ultra-wide monitor friendly without requiring custom patches, I hope this can make LeftWM stand out a bit in that regard. :)

hertg · 2021-09-20T21:45:09Z

src/models/size.rs

+/// an absolute pixel value or a relative percentage value
+#[derive(Serialize, Deserialize, Debug, Clone, PartialEq, Copy)]
+#[serde(untagged)]
+pub enum Size {


In retrospect, I think it is a bit weird that any int is automatically assumed to be a pixel value, and any float is assumed to be a percentage... Maybe in the long run, it would be cleaner to allow setting a unit and parse from that, similar to CSS. Where an absent unit would default to pixel.
250 => Pixel(250)
250px => Pixel(250)
250% => Percentage(250)

Maybe keep the float with 2.5 => Fraction(2.5)?
I Actually like the distinction of absolute sizes in int and relative sizes in float.

All in all, the size model is a really great achievement of this PR and I can see use of it in many other config options, like margins, gutters, scratch pad dimensions and position, default floating dimensions etc.
🥳

stevensonmt · 2021-09-21T17:00:34Z

I agree that this is a pretty niche feature, that's why we should keep the feature as basic as possible for now. But a lot of WMs aren't really ultra-wide monitor friendly without requiring custom patches, I hope this can make LeftWM stand out a bit in that regard. :)

FWIW the ability to define workspaces already makes leftwm a good tool for ultra wide monitors. This feature does make it more flexible and user friendly, though.

hertg · 2021-09-24T10:42:04Z

I added some documentation for this feature to the wiki:
https://github.com/leftwm/leftwm/wiki/Config#max-window-width

hertg added 4 commits September 14, 2021 00:49

implement max_window_width configuration, resize workspace if it exce…

40ebe44

…eds the max_window_width * window_count, update all layouts to use the new method on workspace

remove remaining code from local testing

c0a20b9

fix formatting issues reported by fmt

ed955dd

Merge remote-tracking branch 'upstream/master' into max-window-width

4cbe696

VuiMuich reviewed Sep 16, 2021

View reviewed changes

hertg added 3 commits September 18, 2021 18:38

rename x() and width() methods on workspace, consistently use variabl…

a33fc53

…es instead of multiple method calls in layouts

merge current master into feature branch

45819a1

fix formatting to satisfy clippy and fmt

ca535b9

allow setting absolute/relative width for 'max_window_width'

a4a0a14

fixed comments I accidentally mixed up earlier

ec4c763

VuiMuich mentioned this pull request Sep 19, 2021

Implement an ergonomic way for window snapping #486

Open

mautamu mentioned this pull request Sep 20, 2021

Add Discord link. Clean up a few other old issues; #487

Merged

hertg added 2 commits September 20, 2021 23:00

limit workspace based on column_count, rather than window_count

91cda2f

add missing commas to satisfy fmt

c96ebf9

hertg commented Sep 20, 2021

View reviewed changes

lex148 merged commit 2f78737 into leftwm:master Sep 22, 2021

hertg mentioned this pull request Sep 24, 2021

Scratchpad position #493

Merged

hertg mentioned this pull request Sep 25, 2021

[Feature] add configuration for max window width #475

Closed

Add 'max_window_width' feature #482

Add 'max_window_width' feature #482

Uh oh!

Conversation

hertg commented Sep 16, 2021

Uh oh!

VuiMuich commented Sep 16, 2021

Uh oh!

VuiMuich commented Sep 16, 2021

Uh oh!

mautamu commented Sep 16, 2021

Uh oh!

hertg commented Sep 16, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hertg Sep 16, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VuiMuich Sep 16, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VuiMuich commented Sep 16, 2021

Uh oh!

hertg commented Sep 16, 2021

Uh oh!

AethanFoot commented Sep 17, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hertg commented Sep 17, 2021

Uh oh!

AethanFoot commented Sep 17, 2021

Uh oh!

lex148 commented Sep 17, 2021

Uh oh!

hertg commented Sep 17, 2021

Uh oh!

VuiMuich commented Sep 17, 2021

Uh oh!

VuiMuich commented Sep 17, 2021

Uh oh!

hertg commented Sep 18, 2021

Uh oh!

AethanFoot commented Sep 18, 2021

Uh oh!

hertg commented Sep 18, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

VuiMuich commented Sep 19, 2021

Uh oh!

stevensonmt commented Sep 20, 2021

Uh oh!

VuiMuich commented Sep 20, 2021

Uh oh!

stevensonmt commented Sep 20, 2021

Uh oh!

hertg commented Sep 20, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AethanFoot commented Sep 20, 2021

Uh oh!

stevensonmt commented Sep 20, 2021

Uh oh!

hertg commented Sep 20, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hertg Sep 16, 2021 •

edited

Loading

VuiMuich Sep 16, 2021 •

edited

Loading

AethanFoot commented Sep 17, 2021 •

edited

Loading

hertg commented Sep 18, 2021 •

edited

Loading

hertg commented Sep 20, 2021 •

edited

Loading

hertg commented Sep 20, 2021 •

edited

Loading

VuiMuich Sep 21, 2021 •

edited

Loading