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

Custom border width when smart gaps hides gaps #11

Closed
senkowo opened this issue May 22, 2024 · 1 comment
Closed

Custom border width when smart gaps hides gaps #11

senkowo opened this issue May 22, 2024 · 1 comment
Labels
feature New feature or request

Comments

@senkowo
Copy link
Contributor

senkowo commented May 22, 2024

Missing behavior

Making the border width thinner or non-existent when smart gaps activates/hides gaps, bringing an appearance more like monocle mode.
To exemplify, if wideriver is ran with the args --border-width 2 --border-width-monocle 0 --smart-gaps and if only one view is present, then when in the monocle layout, there are no borders and the one view takes up the full screen. Meanwhile, if in any other layout with only one view present, there is a thick 2 pixel border that surrounds the one view taking up the full screen. It would be nice if this border could be made thinner or non-existent when in this specific situation (smart gaps && only one view && not monocle mode).

Desired solution

A new command line argument that sets a border width for when smart gaps activates/hides gaps (in layouts other than monocle). An argument like --border-width-smart-gaps <pixels>, where its value has no effect if --no-smart-gaps.
Some alternative solutions (although less desirable): a boolean argument that causes the smart gaps border width to be inherited from the value of --border-width-monocle.
Or one that simply sets the border width to 0.

Ideas

I made a fork and modified the source code to where it always inherits the value for --border-width-monocle if (view_count == 1 && tag->smart_gaps) at https://github.com/senkowo/wideriver-fork and it seems to be working just fine (I implemented the second of the three solutions I proposed since it's the easiest to implement). If it seems reasonable, maybe the first proposed solution could be implemented based on the change that I made to the fork. I'm not the best at C so I don't trust myself with implementing the rest just yet, but may in the future. It's also my first time ever making a feature/pull request so let me know if there's anything else I should do/know.

Thanks!

@senkowo senkowo added the feature New feature or request label May 22, 2024
@alex-courtis
Copy link
Owner

That's a fantastic idea - it is indeed very jarring when toggling between monocle and tiled.

The solution looks great, I'd be really grateful for a pull request, see CONTRIBUTING.md for instructions on setup, testing etc.

I'm happy to help you with documentation, tests etc. when you raise the PR - it doesn't have to be perfect.

Implementation plan:

  1. add the new argument to args.c
  2. test the new argument via args_parse_cli__valid
  3. add the boolean setting to Cfg
  4. apply it as you have done in displ.c
  5. add --help and man entry

alex-courtis added a commit that referenced this issue May 28, 2024
* always inherit monocle border width if smart_gaps and view_count 1

* added border-width-smart-gaps to args.c

* added border_width_smart_gaps to cfg.c and cfg.h

* replace the old test with the new option

* added border_width_smart_gaps to tst-args_cli.c

* important bug fix in args.c for border-width-smart-gaps

* added border-width-smart-gaps to usage.c

* added border-width-smart-gaps to documentation

* small addition to man page for border-width-smart-gaps

* fix typos monacle -> monocle

* fix indentation in args.c

* fixed two tests from passing (args_parse_cli__valid and args_parse_cli__bad_border_width_smart_gaps)

* generate doc

* prepare for minor release

* tidy includes

* add tip for smart gaps border width, shuffle argument order

---------

Co-authored-by: Alexander Courtis <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants