[i3ass] master command #200

New issue

Open

opened 2023-07-22 15:52:29 +00:00 by budRich · 2 comments

budRich commented

2023-07-22 15:52:29 +00:00

(Migrated from github.com)

Some functionality of i3ass is replacing core functions of i3. Like i3viswiz left replaces the builtin focus left, i3Kornhe left replaces move left, i3fyra -a|--float replaces floating toggle. i3fyra --move left could be used instead of i3Kornhe left but it is not recommended. i3flip replace focus next. also not the uppercase K and spelling of Kornhe, what does it even mean?

I think it is to late, to rewrite and deprecate options of existing commands, but a good solution and enhancement would be something like this:

alias	command	effect
`i3ass focus DIRECTION`	`i3viswiz DIRECTION`	replace i3 built in `focus`
`i3ass focus next\|prev`	`i3flip next\|prev`	replace i3 built in `focus`
`i3ass move DIRECTION`	`i3Kornhe DIRECTION`	replace i3 built in `move`
`i3ass move next\|prev`	`i3flip --move next\|prev`	replace i3 built in `move`
`i3ass toggle float`	`i3fyra --float`	replace i3 built in `toggle float`
`i3ass toggle layout`	`i3fyra --layout redo`	fyra layout toggle
`i3ass toggle zen`	`i3zen`	zen toggle
`i3ass layout LAYOUT`	`i3fyra --layout LAYOUT`	fyra layout set
`i3ass layout toggle`	`i3fyra --layout redo`	why not
`i3ass set i3fyra-workspace WORKSPACE`	`i3var set i3fyra_ws WORKSPACE`	set i3fyra workspace without need for environment
`i3ass run [class=URxvt instance=termsmall] COMMAND`	`i3run --class URxvt --instance termsmall -- COMMAND`	replace exec
`i3ass help focus\|move\|toggle\|layout\|set\|run`	man i3viswiz\|i3Kornhe ...

this is just an example, but we would end up with a interface that is close to default i3, viswiz, flip and Kornhe becomes focus|move .

i3ass toggle zen is longer than the original i3zen but it is much clearer how it will work.

i3list, i3get, i3king

The commands in the i3ass repo can be divided into three groups.

manual windowmanagement (focus, move, layout, zen) and program launching (i3run), they require almost no configuration
automatic windowmanagement, i3king and in a sense i3run, these requires configuration, and a desire to use them
shellscript tools, i3list, i3get, i3viswiz (when it outputs stuff), i3var

i3king is kind of independent and its commandline is straight forward, so it feels un-necessary to include it with the i3ass aliases. imo, only the first group + i3run and maybe later i3term should be included.

I don't think this will be difficult or complicated to setup. Another benefit, is that if a new way of using for instance i3run, like when i3run --command was deprecated in favor for i3run -- command the UI for i3ass run [CRITERIA] COMMAND will stay the same.

@1ntronaut , what do you think about this?

After reviewing the last couple of issues (#195 , #194, #182) , I realize that using i3ass can be quite confusing. Especially if the user has been following the project for a long time, since commands have merged in and out of each other, gotten renamed, options deprecated and renamed e.t.c. Some functionality of i3ass is replacing core functions of i3. Like `i3viswiz left` replaces the builtin `focus left`, `i3Kornhe left` replaces `move left`, `i3fyra -a|--float` replaces `floating toggle`. `i3fyra --move left` could be used instead of `i3Kornhe left` but it is not recommended. `i3flip` replace `focus next`. *also not the uppercase K and spelling of Kornhe, what does it even mean?* I think it is to late, to rewrite and deprecate options of existing commands, but a good solution and enhancement would be something like this: | alias | command | effect | |:-------|:----------------|:---------| |`i3ass focus DIRECTION` | `i3viswiz DIRECTION` | replace i3 built in `focus ` | | `i3ass focus next\|prev` | `i3flip next\|prev` | replace i3 built in `focus ` | |`i3ass move DIRECTION` | `i3Kornhe DIRECTION` | replace i3 built in `move ` | |`i3ass move next\|prev` | `i3flip --move next\|prev` | replace i3 built in `move ` | |`i3ass toggle float` | `i3fyra --float` | replace i3 built in `toggle float ` | |`i3ass toggle layout` | `i3fyra --layout redo` | fyra layout toggle | |`i3ass toggle zen` | `i3zen` | zen toggle| |`i3ass layout LAYOUT` | `i3fyra --layout LAYOUT` | fyra layout set | |`i3ass layout toggle` | `i3fyra --layout redo` | why not | |`i3ass set i3fyra-workspace WORKSPACE` | `i3var set i3fyra_ws WORKSPACE` | set i3fyra workspace without need for environment | |`i3ass run [class=URxvt instance=termsmall] COMMAND` | `i3run --class URxvt --instance termsmall -- COMMAND` | replace exec | |`i3ass help focus\|move\|toggle\|layout\|set\|run` | man i3viswiz\|i3Kornhe ... | this is just an example, but we would end up with a interface that is close to default i3, viswiz, flip and Kornhe becomes focus|move . `i3ass toggle zen` is longer than the original `i3zen` but it is much clearer how it will work. ### i3list, i3get, i3king The commands in the i3ass **repo** can be divided into three groups. 1. manual windowmanagement (focus, move, layout, zen) and program launching (i3run), they require almost no configuration 2. automatic windowmanagement, i3king and in a sense i3run, these requires configuration, and a desire to use them 3. shellscript tools, i3list, i3get, i3viswiz (when it outputs stuff), i3var i3king is kind of independent and its commandline is straight forward, so it feels un-necessary to include it with the i3ass aliases. imo, only the first group + i3run and maybe later i3term should be included. I don't think this will be difficult or complicated to setup. Another benefit, is that if a new way of using for instance `i3run`, like when `i3run --command` was deprecated in favor for `i3run -- command` the UI for `i3ass run [CRITERIA] COMMAND` will stay the same. @1ntronaut , what do you think about this?

1ntronaut commented

2024-07-08 01:57:22 +00:00

(Migrated from github.com)

same goes here, had written reply long time ago, but never posted it.

A globalization of several main/important/most used commands in the i3ass suite seems to me a great idea.

I would however, like to add (request) some functionality I think is very desirable.

The new commands are dependent on the values of
i3list[AWP] and i3list[LVI]

the commands should do the following:

1. check which i3fyra containers are active and visible ; then (depending on i3fyra's split, orientation and containers in family order: change focus from currently focused i3fyra container to the next/previous visible i3fyra container (the focus should also wrap)
  An example in my case:
- main split = AC ; orientation=horizontal

 A | B
===|---
 C | D

+ container A is now hidden:

   | B
 C |---
   | D

+ `i3ass focus-con next`:
+ move focus from container C -> B
+ if repeated: move focus from container B -> D
+ if repeated move focus from container D -> C  ( container focus wrapped

1. I'd like to propose the same functonality for moving i3fyra containers
check which i3fyra containers are active and visible ; then (depending on i3fyra's split, orientation and containers in family order: move currently focused i3fyra container to the next/previous visible i3fyra container (the move should also wrap)
An example in my case:
- main split = AC ; orientation=horizontal
- i3ass move-con next, container A hidden in this example
- container A is now hidden:

   | B
 C |---
   | D

+ move i3fyra container from container C -> B (this auto-hides container C; focus also moves to container B)
+ if repeated: move i3fyra container from container B -> D (focus also moves to container D)
+ if repeated move i3fyra container from container D -> C  ( container movement wrapped, this unhides container C; and additionally also focuses container C)

proposal nr. 2 couuld pose a challenge maybe ; I think you'd have to introduce a new entry (obtained through i3list containing a value for previously visible i3fyra containers, for use in i3fyra container movement cycle, for the autohide and unhide functionality to correctly occur, targeting the correct i3fyra container; esp. if not all containers are visible when this command runst for the first time

however, you're the dev here, I don't think I'm up to the task of writing a compatible and functional script to handle above proposal functionalities...
I just thought it might provide valuable additions in i3fyra's functionality/capabilities..

cheers,
intronaut

same goes here, had written reply long time ago, but never posted it. A globalization of several main/important/most used commands in the i3ass suite seems to me a great idea. I would however, like to add (request) some functionality I think is very desirable. The new commands are dependent on the values of `i3list[AWP]` and `i3list[LVI]` the commands should do the following: - 1. check which i3fyra containers are active and visible ; then (depending on i3fyra's `split`, `orientation` and `containers in family order`: change focus from currently focused i3fyra container to the next/previous visible i3fyra container (the focus should also wrap) An example in my case: + main split = AC ; orientation=horizontal ``` A | B ===|--- C | D ``` + container A is now hidden: ``` | B C |--- | D ``` + `i3ass focus-con next`: + move focus from container C -> B + if repeated: move focus from container B -> D + if repeated move focus from container D -> C ( container focus wrapped - - - - 2. I'd like to propose the same functonality for moving i3fyra containers - check which i3fyra containers are active and visible ; then (depending on i3fyra's `split`, `orientation` and `containers in family order`: move currently focused i3fyra container to the next/previous visible i3fyra container (the move should also wrap) An example in my case: + main split = AC ; orientation=horizontal + `i3ass move-con next`, container A hidden in this example + container A is now hidden: ``` | B C |--- | D ``` + move i3fyra container from container C -> B (this auto-hides container C; focus also moves to container B) + if repeated: move i3fyra container from container B -> D (focus also moves to container D) + if repeated move i3fyra container from container D -> C ( container movement wrapped, this unhides container C; and additionally also focuses container C) - - - proposal nr. 2 couuld pose a challenge maybe ; I think you'd have to introduce a new entry (obtained through `i3list` containing a value for `previously visible i3fyra containers, for use in i3fyra container movement cycle`, for the autohide and unhide functionality to correctly occur, targeting the correct i3fyra container; esp. if not all containers are visible when this command runst for the first time however, you're the dev here, I don't think I'm up to the task of writing a compatible and functional script to handle above proposal functionalities... I just thought it might provide valuable additions in i3fyra's functionality/capabilities.. cheers, intronaut

👍 1

budRich commented

2024-07-11 21:55:05 +00:00

(Migrated from github.com)

And as you mention it will get tricky to keep track of container parents. Another edge case is if container order "has changed", like in example two, after step two, lets say container C has been made visible again (by other means), and then container A, then container A and C is swapped, then C is hidden. or something like that, it gets weird.

But focus/move to next visible container should be "easy". Big thanks for this suggestion.

Also, regarding wrapping the focus/movement. Without testing or anything, i wonder if it shouldn't follow this priority pattern (assuming horizontal layout AC + BD families):

try to sibling within same family (A->C, C->A, B->D) (UP/DOWN)
use the same algorithm as i3viswiz focus left/right to find next parent

Also, if the target container is not tabbed or stacked, i think this should respect the focus order of the target container, which i3viswiz focus left/right/up/down very counsiously doesn't respect. But it will not be difficult to do it here.

On topic, i don't even remember what i did with the i3ass command, i haven't looked at this project in months. Its time to give i3ass some love, i think there is a new i3 release coming soon also so its good to get in the groove a bit.

Sounds like great ideas! But I wonder in proposal nr.2 if it really is desirable to move a container to a not visible one. I imagine the action being triggered by a keybinding and used in a alt-tab kind of way. And using same example as you, lets say hours have passed between step two and three, and user have "forgotten" that the D container was originally moved from ,now hidden C, and B is visible, here i would more expect to next-move to B. And as you mention it will get tricky to keep track of container parents. Another edge case is if container order "has changed", like in example two, after step two, lets say container C has been made visible again (by other means), and then container A, then container A and C is swapped, then C is hidden. or something like that, it gets weird. But focus/move to next visible container should be "easy". Big thanks for this suggestion. Also, regarding wrapping the focus/movement. Without testing or anything, i wonder if it shouldn't follow this priority pattern (assuming horizontal layout AC + BD families): 1. try to sibling within same family (A->C, C->A, B->D) (UP/DOWN) 2. use the same algorithm as i3viswiz focus left/right to find next parent Also, if the target container is not tabbed or stacked, i think this should respect the focus order of the target container, which i3viswiz focus left/right/up/down very counsiously doesn't respect. But it will not be difficult to do it here. On topic, i don't even remember what i did with the i3ass command, i haven't looked at this project in months. Its time to give i3ass some love, i think there is a new i3 release coming soon also so its good to get in the groove a bit.

🚀 1