When windows are created after skippy is invoked...

[felixfung]

When windows are created after skippy is invoked:

1. focus may be stolen from skippy-xd to that of the new window; this behaviour probably depends on the WM
2. skippy will not display those windows

Similarly, when a window is destroyed while skippy is invoked, the layout is NOT updated, i.e. there will be a "hole" in the layout of exposed windows. I think this is actually more efficient for users' workflow because the users eyes do not have to adjust to new layout.

Ideal skippy behaviour is to update layout when new windows is created, with animation between old and new layout of course. And skippy should always retain user keyboard control. When new windows are destroyed, there is a bit of dilemma or controversy. I am personally leaning towards not updating layout. However, when windows are destroyed and then created, then the layout is changed anyway, and the asymmetry between creation->update and destroy->no update may be confusion for users.

For this task, we first determine what behaviour we prefer. The implementation would probably be in the main loop XEvent polling for CreateNotify and DestroyNotify.

[dreamcat4]

it is certainly a complex / difficult problem to deal with.

my general (top level) feelings are that it would be helpful, if trying to improve / solve that it also is going to work for any potential future 'daemon mode'

because if skippy can run all of the time, the it can remember iconified windows too. which is then a win-win. (not to implement a daemon mode here too, just make decisions about this feature that is compatible / does not prevent)

but perhaps whatever choices we can make, it is always good for daemon mode. regardless of the specifics. then this feature we could regard as a pre-requisite for that other work. not to worry.

in terms of specific decisions where to put new windows, or if to remove gaps.... i am not really certain what is actually feasible. but you seem to have summarized quite well the different considerations. i am - not sure i mind too much.

and if some of the behaviour / choice can easily be configured (for no extra development hassle). just to give the user some level of choice... then that would be pretty cool. a bonus

=====

but if you want to hear my dreams (and it isn't too important anymore, since i am eventauly later switching to wayland):

my feeling is that there is more consideration over re-ordering based on activation history. and this is very much related to ease of use for the alt+tab usages. for effecient keypress.

for example (while skippy is running). if i have 10 applications open. but i am frequently switching between only 3 applications. then it is highly beneficial to re-order windows sequence (in skippy preview). so that those 3 applications gets moved together in the centre of the window.

so in the code, in the linked list traversal of clientwins, that can be considered as a re-sorting of the linked list order. some cuts, some element inserts. to re-shuffle the list so they are put to the middle. with some simple algorithm.

(and perhaps i already worked some ways on this problem, but my working code had bugs / too unstable and so i never uploaded it)

however that re-ordering is less problem when skippy is being quit then re-opened. wheras a daemon mode it would perhaps be requiring some animation. idk

=====

anyhow i am doubtful you would care about that too much. as you probably do not use skippy in such ways. and perhaps it would not be any reason to think it's a matter if we disregard this consideration, to not impact or be relevant to these other decision here. just a food for thought.

getting back to the point of this issue, i don''t mind if you take the lead on this.

in meantimes i just am going to try testing your other code / for other prs, for regression to check the alt+tab behavious remains ok / intact (as per your other recent request of me - happy to do so, just taking my time over it)

[felixfung]

It is possible to add code and features so that skippy can accommodate BOTH exposed usage and alt-tab usage, by invoking skippy with different commands or configurations. For your "dream" usage, it is doable, the change would be quite localized to layout_run() and do_layout().

I will summarize expose and alt-tab usage in a different issue item.

[felixfung]

After thinking a little bit, I think it is best to leave this alone to the current state/implementation:

When windows are created during skippy-xd invocation, skippy-xd does not recognize them and the user oblivious of the new windows.

When a window is destroyed during skippy-xd invocation, skippy-xd and the user is aware, and the window disappears from view, but the rest of the layout does not change.

If we change the layout to accommodate newly created windows, we need animations to guide the eye. It would lead to a whole mess of newly introduced states within skippy-xd invocation, including ready, animating, and potentially block user input if windows are being created continuously. Or we decide to allow user input during animation. It would be too much work, too many states, too much potential complication, for too little gain.

Skippy-xd is a window selector, to help a user select windows efficiently, not for a user to stay within for a long period of time.

Hence, we will not pursue this feature.

[dreamcat4]

If we change the layout to accommodate newly created windows, we need animations to guide the eye. It would lead to a whole mess of newly introduced states within skippy-xd invocation, including ready, animating, and potentially block user input if windows are being created continuously. Or we decide to allow user input during animation. It would be too much work, too many states, too much potential complication, for too little gain.

agreed, is difficult problem to solve well. And not without significant efforts / changes