[i3ass] master command

[budRich]

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]

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

[budRich]

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.