Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[swm-gaps] gaps should not be applied to modeline #100

Closed
jamesmccabe opened this issue Apr 5, 2018 · 13 comments
Closed

[swm-gaps] gaps should not be applied to modeline #100

jamesmccabe opened this issue Apr 5, 2018 · 13 comments

Comments

@jamesmccabe
Copy link

When I turn on swm-gaps it moves my modeline and adds gaps to it.
I presume this should not be the default behavior and maybe it was only tested using Polybar instead of the Stump modeline?

Screenshot:
2018-04-05-223601_1366x768_scrot

Here is my .stumpwmrc.

Removing defun add-outer-gaps function seems to fix the problem but the outergaps feature is lost.

@npavlinek
Copy link
Contributor

I'm not the author of this module, but maybe this was intended? Although looking at the screenshot of the module, maybe not.

Perhaps there should be an option whether a user wants to apply gaps to the modeline or not. Thoughts?

@lepisma
Copy link
Contributor

lepisma commented Apr 24, 2018

I am the author (for the outer gaps thing). I used polybar so didn't face this issue. I agree about having an option for applying gaps to modeline.

I think it might need some refactoring since the outer gaps were implemented by resizing the whole head. Allowing modeline might mean changing this.

@lepisma
Copy link
Contributor

lepisma commented Apr 24, 2018

Another way might be to make the modeline aware of gaps and have it position itself correctly. Though I am not sure which way is going to be easier/better. Thoughts?

@jamesmccabe
Copy link
Author

Thanks for the replies. My Lisp skills are poor so I don't know how easy it would be to implement the features. My guess is not very easy 😁. If we could just make the modeline stay in default position I would be happy with that.

Having the option to apply gaps to the modeline or turning it off would be cool though.
Applying gaps to the modeline could be another module maybe with separate code? I'm not sure if that would work either.

@lepisma
Copy link
Contributor

lepisma commented Apr 24, 2018

I will give it a shot this weekend.

@lepisma
Copy link
Contributor

lepisma commented Apr 29, 2018

I have a possible fix in here. There are now three kind of gaps defined by the following variables:

  1. *head-gaps-size*. This is what borders the monitor. Everything (including modeline) comes inside its boundary. You would want to set it to 0.
  2. *outer-gaps-size* mimicks the behaviour of the older variable with same name but adds asymmetric gaps around individual windows after checking if they are facing monitor edges.
  3. *inner-gaps-size* is the same old thing.

Here is a quick picture to describe these.

screenshot_20180429_181105 png

The outermost gaps are due to *head-gaps-size*. The innermost (around all edges of window) are due to *inner-gaps-size* and the extra gaps for the monitor facing edges is from *outer-gaps-size*.

Try the fork and see if it behaves correctly. If all looks fine, then I will create a PR here.

@jamesmccabe
Copy link
Author

jamesmccabe commented Apr 30, 2018

Thanks Abhinav it seems to work fine. I am getting an error message though which doesn't effect the functionality though. It only appears when the gaps are toggled on.

Error in Command 'toggle-gaps': The function STUMPWM:ONLY-TILE-WINDOWS is undefined.

Maybe I am doing something wrong?

2018-05-01-001919_1366x768_scrot

@npavlinek
Copy link
Contributor

npavlinek commented Apr 30, 2018

I just tried it myself. Seems to work fine. @lepisma

How are you getting that error? @jamesmccabe (I tried the same config with the binding as you and get no error)

@lepisma
Copy link
Contributor

lepisma commented May 1, 2018

Which version of stumpwm are you using @jamesmccabe? (although the missing function is around a year old so don't know if this matters).

@jamesmccabe
Copy link
Author

Sorry I am using stumpwm version 1.0.0 so I think this is the problem. I will test the git version later.

@lepisma
Copy link
Contributor

lepisma commented May 1, 2018

Right, I now realize that v1 doesn't have that fn. Since, v1 is latest stable release, should I revert the change that I made (lepisma@08918d7)? I think addon modules should at least work with the latest stable.

@lepisma
Copy link
Contributor

lepisma commented May 1, 2018

Or I can also take this opportunity to ask @dbjergaard if v1.0.1-rc can go as a stable release? I feel there are sufficient amount of really useful changes in the rc. Its also been working without any hiccups for me at least. How are others feeling about it?

@npavlinek
Copy link
Contributor

Maybe you should have a look at this: stumpwm/stumpwm#454, @lepisma.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants