20
849
Fork
You've already forked fuzzel
83

Initial anchor support #213

Manually merged
dnkl merged 12 commits from jficz/fuzzel:add-window-anchor into master 2023年10月08日 15:20:24 +02:00
Contributor
Copy link

(削除) Only works from ini file, there's a problem with cmdline parsing
I need to find and fix. (削除ここまで)
fixed by subsequent commit(s)

~~Only works from ini file, there's a problem with cmdline parsing I need to find and fix.~~ _fixed by subsequent commit(s)_
Initial anchor support
All checks were successful
ci/woodpecker/pr/woodpecker Pipeline was successful
ee21cd574e
Only works from ini file, there's a problem with cmdline parsing
I need to find and fix.
Author
Contributor
Copy link

fixes #130

fixes #130
Fix command line parse
All checks were successful
ci/woodpecker/pr/woodpecker Pipeline was successful
0d0570652b
jficz changed title from (削除) WIP: Initial anchor support (削除ここまで) to Initial anchor support 2023年02月23日 10:33:44 +01:00
Update docs to include anchor
Some checks failed
ci/woodpecker/pr/woodpecker Pipeline failed
6e667db7d3
Author
Contributor
Copy link

Did a few tests, so far no apparent issues.

Updated man and ini docs.

Probably needs more polishing but works well (enough).

Did a few tests, so far no apparent issues. Updated man and ini docs. Probably needs more polishing but works well (enough).
dnkl left a comment
Copy link

Nice, thanks!

In addition to the changes below, can you also add a CHANGELOG entry?

Nice, thanks! In addition to the changes below, can you also add a CHANGELOG entry?
config.h Outdated
@ -42,0 +64,4 @@
{"bottom-left", ANCHOR_BOTTOM_LEFT},
{"bottom", ANCHOR_BOTTOM},
{"bottom-right", ANCHOR_BOTTOM_RIGHT},
};
Owner
Copy link

Please move this to config.c, to avoid a copy of it being instantiated in every .c file that includes config.h. Also please make the name member const.

I'd also prefer if you could down-case the variable name. Upper case is usually "reserved" for enum values and macros.

To make it externally visible (for command line parsing), remove static, and add an extern declaration in the header file. There's a small down side to this: you can't use sizeof() on it, outside of config.c. A simple workaround is to terminate the list with a NULL entry (see below).

config.h:

struct anchors_map {
 const char *name;
 enum anchors value;
};
extern const struct anchors_map anchors_map[];

config.c:

const struct anchors_map anchors_map[] = {
 {"top-left", ANCHOR_TOP_LEFT},
 ...
 {NULL, 0},
};

To iterate it in e.g. main.c:

for (size_t i = 0; anchors_map[i].name != NULL; i++) {
 ...
}
Please move this to `config.c`, to avoid a copy of it being instantiated in every `.c` file that includes `config.h`. Also please make the `name` member `const`. I'd also prefer if you could down-case the variable name. Upper case is usually "reserved" for enum values and macros. To make it externally visible (for command line parsing), remove `static`, and add an extern declaration in the header file. There's a small down side to this: you can't use `sizeof()` on it, outside of `config.c`. A simple workaround is to terminate the list with a NULL entry (see below). `config.h`: ```c struct anchors_map { const char *name; enum anchors value; }; extern const struct anchors_map anchors_map[]; ``` `config.c`: ```c const struct anchors_map anchors_map[] = { {"top-left", ANCHOR_TOP_LEFT}, ... {NULL, 0}, }; ``` To iterate it in e.g. `main.c`: ```c for (size_t i = 0; anchors_map[i].name != NULL; i++) { ... } ```
jficz marked this conversation as resolved
doc/fuzzel.1.scd Outdated
@ -106,2 +106,4 @@
Default: _not set_.
*-a*,*--anchor*=ANCHOR
The window anchor. Default: _center_.
Owner
Copy link

I think we should list all the allowed values here.

I think we should list all the allowed values here.
dnkl marked this conversation as resolved
main.c Outdated
@ -245,6 +245,7 @@ print_usage(const char *prog_name)
" -T,--terminal terminal command to use when launching\n"
" 'terminal' programs, e.g. \"xterm -e\".\n"
" Not used in dmenu mode (not set)\n"
" -a,--anchor window anchor (top, bottom, left, right and combinations)"
Owner
Copy link

I would suggest removing the top, bottom ... examples, and instead mention the default value:

window anchor (center)

This is similar to how other options are handled.

I would suggest removing the `top`, `bottom` ... examples, and instead mention the default value: ``` window anchor (center) ``` This is similar to how other options are handled.
jficz marked this conversation as resolved
First-time contributor
Copy link

I was thinking the anchoring in addition to an option for an invisible external margin would be cool. This would prevent potential overlap with bars and allow for some breathing room from the edge of the screen. Not sure if this feasible as I'm not familiar with C or how Wayland deals with windows, but wanted to throw the idea out.

I was thinking the anchoring in addition to an option for an invisible external margin would be cool. This would prevent potential overlap with bars and allow for some breathing room from the edge of the screen. Not sure if this feasible as I'm not familiar with C or how Wayland deals with windows, but wanted to throw the idea out.
Owner
Copy link

I was thinking the anchoring in addition to an option for an invisible external margin would be cool. This would prevent potential overlap with bars and allow for some breathing room from the edge of the screen. Not sure if this feasible as I'm not familiar with C or how Wayland deals with windows, but wanted to throw the idea out.

Sure, it's possible to set anchor margins in Wayland. And I agree that'd be nice to have as well.

Note that bars usually set an exclusion zone, meaning nothing should ever overlap with them anyway.

> I was thinking the anchoring in addition to an option for an invisible external margin would be cool. This would prevent potential overlap with bars and allow for some breathing room from the edge of the screen. Not sure if this feasible as I'm not familiar with C or how Wayland deals with windows, but wanted to throw the idea out. Sure, it's possible to set anchor margins in Wayland. And I agree that'd be nice to have as well. Note that bars usually set an exclusion zone, meaning nothing should ever overlap with them anyway.
Move anchors_map values to config.c
Some checks failed
ci/woodpecker/pr/woodpecker Pipeline failed
0b81037477
* Update anchors_map iteration logic
* Update documentation
* Add changelog entry
Author
Contributor
Copy link

@dnkl made the changes you requested (finally :) )

@dnkl made the changes you requested (finally :) )
Merge branch 'master' of codeberg.org:dnkl/fuzzel into add-window-anchor
Some checks failed
ci/woodpecker/pr/woodpecker Pipeline failed
aa08c0b538
dnkl left a comment
Copy link

Mostly looking good, but I do have a couple of nits, see below.

I'd also like to see the new command line option being added to the shell completions (completions/*).

Mostly looking good, but I do have a couple of nits, see below. I'd also like to see the new command line option being added to the shell completions (`completions/*`).
@ -778,0 +795,4 @@
anchor = anchors_map[i].value;
break;
}
}
Owner
Copy link

There's a value_to_enum() function in config.c that you should be able to use here.

There's a `value_to_enum()` function in `config.c` that you should be able to use here.
Author
Contributor
Copy link

sorry, I'm a bit slower lately - what would I use the function for?

sorry, I'm a bit slower lately - what would I use the function for?
Author
Contributor
Copy link

so I gave it another thought and I think that unless I want to statically enumerate all the options (again!) in the code, the function value_to_enum() doesn't really help here. But the idea itself is good so I went on with a little experiment, which resulted in this: jficz/fuzzel@10c5d9370d

It's a rather large change in the codebase outside the scope of this MR and it's probably pretty bad, but it allows for ultimately cleaner code without duplicated static arrays of strings in the middle of the code and also allows better code reuse outside of config.c.

off topic: I found the name of the function confusing and I'd suggest to rename the function to value_in_enum() or perhaps even more accurately value_from_enum() but that would require a lot of refactoring since there are other functions with the same naming logic.

so I gave it another thought and I think that unless I want to statically enumerate all the options (again!) in the code, the function `value_to_enum()` doesn't really help here. But the idea itself is good so I went on with a little experiment, which resulted in this: https://codeberg.org/jficz/fuzzel/commit/10c5d9370dec6578415f8b5a317530d6f4ee0e3f It's a rather large change in the codebase outside the scope of this MR and it's probably pretty bad, but it allows for ultimately cleaner code without duplicated static arrays of strings in the middle of the code and also allows better code reuse outside of config.c. off topic: I found the name of the function confusing and I'd suggest to rename the function to `value_in_enum()` or perhaps even more accurately `value_from_enum()` but that would require a lot of refactoring since there are other functions with the same naming logic.
Owner
Copy link

Let's keep it as is for now :)

Let's keep it as is for now :)
dnkl marked this conversation as resolved
doc/fuzzel.1.scd Outdated
@ -108,0 +117,4 @@
- _bottom-left_
- _bottom_
- _bottom-right_
Owner
Copy link

I would suggest copying the description from fuzzel.ini.

I would suggest copying the description from fuzzel.ini.
jficz marked this conversation as resolved
Author
Contributor
Copy link

zsh completion tested and working, fish untested

zsh completion tested and working, fish untested
dnkl manually merged commit 7cf672e9d2 into master 2023年10月08日 15:20:24 +02:00
Owner
Copy link

Thanks!

Thanks!
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
dnkl/fuzzel!213
Reference in a new issue
dnkl/fuzzel
No description provided.
Delete branch "jficz/fuzzel:add-window-anchor"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?