[layout=boxy] - does not seem to work very well? ...depending on specific user environment

[dreamcat4]

Boxy layout: I would like to see a video if possible?

3) Requested of video for boxy layout

OK @felixfung, BOXY LAYOUT: Hopefully this video can be some help, to see for yourself my own experiences:

NOTE: this version skippy is from previous day, the commit df30bdf .. which was the PR #63

https://drive.google.com/file/d/1ce2Pbon12xR4mszkKPA2BX8BUnysJhyw/view?usp=sharing

Hopefully it shows you why the boxy layout has not been so good for me.

I do actually support these general ideas for development, and encourage your visions. Since these new layouts like boxy layout (and others to build upon that). Indeed it can help to organize into groups. And to offer some choices in the view mode(s). Really great initiative. Very much so.

However my own experience here it seems like not-finished feature. So it might be helpful to try to identify for in which specific situation(s) and environment this mode can render itself (either better or worse).

Should this be the default setting?

I hope you may agree that when a new user uses ANY program for the first time, they should be given a sensible defaults options. Which is not so prone to breakage, or lead to a rather poor initial user experience. So the boxy layout (as a default)... it still seems premature at this point right? Until the feature can progress some more, to become something more refined. And just more robust. And handle any variety of user's desktops in a reliable fashion.

However even then I still strongly believe that we should engage and participate more the user base in this discussion. To actually ask which is their preferred as their own default setting.

A request to users might be better deferred to later - if you still have improvements / and more work pending to develop this feature. But until then... this still seems a bit more like an experimental feature?

So what's the problem?

My biggest number #1 issue with this layout:

That each window ends up being individually very, very, small. Like tiny. So there is then most of the screen is not used and dead space. This (in practical sense) makes it a lot harder to see well each tiny window previews, what they contain etc.

So that is probably the biggest thing I can specifically point to, in terms of general usability. Because the rest... i do not understand really.

The concept is supposed to be more ordered somehow? ... but it does actually translate into a positive user experience.

What is my system like?

• I have 2 different monitors here
• Main PC monitor is ultrawide, 3440x1440p
• 2nd Monitor is a 1080p TV (big screen). Of standard aspect ratio. (therefore they are each different resolutions)
• The screen layout for (of 1 desktop) is arranged like this: [3440p][1080p]
• So 4 virtual desktops, each is very wide, arranged across horizontally like this:
• [__1__][__2__][__3__][__4__]

Can I help to debug boxy layout any further?

Well I would hope you can try to reproduce locally. Because I myself am not really so able to tolerate using this ATM. At least until some further improvements. However if you do want to get more feedback (for changes).... I would like to help in due course. However I am just a lot slower than you. To be waiting on that response. Sorry if that is a drag, as you prefer to keep momentum and more more quickly. (Which is a good productivity BTW, well done).

Especially if there is something in my environment which I forgot to include here. And you can please ask, for further clarifications. As to what else can be affecting your layout algorithm negatively.

Mostly because in present state it's just really too unusable here for me, (not much fun at all). Because the window previews are just way too small.

But also don't really need this layout (for myself personally). Because I remember where each my windows is. So they don't need for me to be presented as 'grouped' or 'organized'. (it's not matter to me). Even when used in expose mode. Or alt+tab (is actually all the same to me, just invoke via mouse or keyboard is the only difference, if it stays on the screen or is dissmissed automatically after releasing held keys).

For now I shall just move forwards, to try your new(est) PRs, maybe play a bit with the virtual pager. Maybe also can try the memory leak fixes for a while (wait / see for any segfault).

[felixfung]

I see what you mean now :)

First, as you experience, boxy layout has a limitation: it tries to lump thumbnails into triangular shapes:

o o o o o o o

This is suboptimal use of screen space and result in thumbnail sizes smaller than optimal. This algorithmic sub-optimum can be improved later.

Your desktop set up and windows usage greatly expose various user-friendliness shortcomings. I really love it!

Right now, I would like to prioritize now on fixing technical debts, memory leaks, segfaults, xerrors, performance issue #54. After that the more functional side, layout and pager.

The intention of boxy layout is for use when showAllDesktops = false. Then preservation of windows positions makes sense and is significantly desirable. When showAllDesktops = true, preservation of windows position inherently makes a lot less sense, it would be preservation of virtual desktop relations that's most important. Then, ideal use case would be more in the line of pager. Or, like your personal desire, layout that maximizes screen usage and thumbnail size, and layout ordering that preserves stack ordering (that's the current behaviour?).

Long ago I understood there are 3 main use cases:

1. Alt-tab use, single or all virtual desktops.
2. Expose on single virtual desktop windows.
3. Paging of all virtual desktops.

I always knew expose on all virtual desktops is kind of an ill-defined use case.

We have 3 pretty distinct use cases that if you wish to use for the purpose of one, but has the setup for another, (e.g. you intend to use alt-tab but gets paging, or want expose on single desktop but get alt-tab) then you feel hugely underwhelmed. And when there is only one set of default values, we get into a dilemma.

But why only one set of default values?

We should expand one sample config file to two: expose and alt-tab use; paging is an additional command and does not need/accept config file. In addition, we put in explanation and instruction on the sample config and pros/cons.

I hope we are on the same page now?

[dreamcat4]

The intention of boxy layout is for use when showAllDesktops = false. Then preservation of windows positions makes sense and is significantly desirable. When showAllDesktops = true, preservation of windows position inherently makes a lot less sense

OK so for this setting, we should just move that setting to be right next to (after) the layout = boxy line in the config. And include that ^^ comment to say, (like columns mode) it makes sense together for boxy layout. In combination. To group this into more coherent set of them together.

Or, like your personal desire, layout that maximizes screen usage and thumbnail size,

Just to add a little more to this point... in XD layout mode (traditional). There is 1 thing that i find most pleasing: it is very much fastest way to identify windows quickly by their actual size. Because when skippy makes the traditional previews each is sized exactly correspond to the size of the actual window. So (speed wise) it is immediate to identify those. And this makes the workflow of actually switching to desired window the fastest.

So for a different 'more ordered' layout style (which can be boxy, or something else) that has uniform and grid-aligned sized windows (like a uniform grid).... then that super power is actually lost. It is then a trade of (in exchange) for some other presumed benefit(s)... for example a regular column alignment makes better a vertical column traversal (for that current columns algorithm, which again: i do not actually use).

• Alt-tab use, single or all virtual desktops. = YES
• Expose on single virtual desktop windows. = INCOMPLETE
• Paging of all virtual desktops. = YES

ok so for the 2nd one:

• Expose on single + ALL virtual desktop windows

I always knew expose on all virtual desktops is kind of an ill-defined use case.

yet this is how i have been using skippy since... pretty much always. I am not sure what you mean by ill-defined? ... you do not have any further to elaborate?

I hope we are on the same page now?

No because:

• 1. Exactly the above point: that I still do not see expose as being such distinct use case from ALT+TAB use case... never have done!

As I explained,here is my comment again:

Even when used in expose mode. Or alt+tab (is actually all the same to me, just invoke via mouse or keyboard is the only difference, if it stays on the screen or is dismissed automatically after releasing held keys).

• In fact: can actually invoke to expose with the ALT+TAB key too. Same way. But hitting it in a particular way. Then it stays up on the screen. For mouse etc.

• 2. And this boxy layout (very clearly) still is not a mature feature.
• 3. And it still strongly believe requires (at least an honest attempt) of consultation with regular users. To at least try... and actually get some feelings outside what people out there is using. More or less. (whether a response or not)

So those particular things ^^^,

• So to repeat: It's like a WIP feature this boxy layouts. Still very new thing.

• And I still don't see the benefit! Merely stating it's like ordered... does not actually explain to me how it is better. As for WHY is better.... it's different! But that is matters of personal preference. So where does the actual usability benefit get explained?

This may go in comment in the sample rc. file at least (if nothing else)

For now, i recommend:

• Group the 3 setting together within single config. And repeat it.... Group 1 is uncommented. And group 2 is #commented out (so only one group is active at a time).

Then user just needs to comment / uncomment a group of 3 options.

This is probably best compromise for time being. All users can see there the 2 clear choice, without missing other ones in another file.

[felixfung]

First to clarify, boxy layout preserves window sizes, just like xd layout. I am 100% with you that preserving window sizes is important for quick identification of windows.

There IS fundamental difference between expose and alt-tab:

preference	alt-tab	expose	paging
position preservation	depends on user preference	preserve relative positioning loosely but not overlapping	preserve within virtual desktop, expand virtual desktop positioning
prev/next sorting	windows z-order	expanded layout position (per column)	per virtual desktop (per row)
animation	not important	important	so-so

If you agree with this table, then expose over all desktops is not a perfect idea, because we have windows position per virtual desktop, and positional relation between virtual desktops. We can prioritize one positioning over the other, but in the end, for a user who has many windows opened over all the virtual desktops, the thumbnail sizes would be small anyway. If you look at the opening comment of #56, I have a clear idea how to do expose on all virtual desktops while prioritizing virtual desktop positioning over windows positioning, but i decided against it because I think it would not be good use case.

In the end, skippy-xd is about quick selection of windows by visual cues. The visual cues include user expectations on windows z-ordering, size, positioning, virtual desktop position, thumbnail. Based on different purpose, different cues are prioritized over other visual cues. The above table is my attempt to explain different priorities based on use case.

Based on the table and my own use, boxy is decent (not perfect) for expose. You can try boxy layout on one virtual desktop, with 2-5 windows of various sizes and positions. Ok maybe a maximum of 8 windows. (Realistically how many windows should one put into one virtual desktop and expect efficiency?) I hope you understand what I mean by expose, otherwise it would be hard for you to understand how I envision it :)

[dreamcat4]

Ok... this helps to be a bit clearer now. Thank you for explaining these levels. For the sake of your terminology I am going to try to refer now (your ways).

Beginning to understand these open question / dillema. Around what is needed to move forwards to more coherent feature set (that is more flexible usage / multiple invocation methods).

Perhaps some aspects within our terminology is not fully clear. But you table is getting towards that. There is indeed still some underlying assumptions about virtual desktop usage... which you have explained well those specifics. At least I can understand better of it now.

OK my NEW goal here (of my next section) ... is to try and give some real world use-case. That is workflow oriented. To approach from a workflow perspective. Then see how our software does or does not rise to that challenge:

Example user workflow

So my workflow (real world). It looks something a bit like this:

Initially (after reboot). I only have 2-4 windows open per virtual desktop. And none (or very few) are occluded.

But you do work. Then at some point 1+ virtual desktops becomes much busier.

Then the actual content of a specific desktop is dependent whether it's:

A) a designated static layout, for a being dedicated to some recurring task(s).

Or

B) if it's a temporary 'busy' area, where work is actively being done in an ad-hoc state or manner. Then windows are being opened and closed in some unpredictable, more chaotic manners.

Window types and lifetimes

The windows themselves falls into 3 categories:

• 1. Some of the windows per screen (1-2) are always for a dedicated (fixed) tasks, fixed purposes on those screens (and mostly static).
• 2. Yet other window(s) are even more global. A fewer number will be pinned to always appear across all virtual desktops. Always available.
• 3. Then for some later desktops, which will become more active, with transient work. Those may then end up having more than 3 windows open. Perhaps many windows. A chaos. As work happens.

This represents a variety balance / mixture of real workflows, which is organized (loosely) across different designated virtual desktops. With [some] of the virtual desktops being pretty static, always same. While [others] virtual desktops can be lasting either: only a few minutes. Or across several hours. Or for a couple of days.

Where things falls down

The observed point (of above) is that there is not a consistent 1 to 1 mapping of windows onto desktops. (Or to multiple monitors either). There is a cross contamination. Which has a point to itself. And crosses those neatly defined boundaries.

So this is where the concept of providing a consistent navigation per individual virtual desktop falls down (for consistently invoking same exact mode).... And in more chaotic situation are where (as you have pointed out)... this boxy layout does not work so well, but especially when in combination of showAllDesktops = true.

Which was what we previously discussed above... for my video today, why I could not utilize this mode for it's intended purpose. OK moving forwards...

Show All Desktops Setting

The showAllDesktops setting (in skippy's current settings and code) is entirely independent to expose mode. (or alt-tab). But is fixed (global) to the running daemon instance. Regardless of and chosen invocation mode.... this is maybe an issue.

1 daemon runs with same single config file... which must be either showAllDesktops = true, or showAllDesktops = false.

And either layout = boxy or layout = xd...

Analogy

Different categories of windows all mixed up. All open together in same session....

So here is my stupid analogy:

you have a leopard, a monkey, and a zebra in the zoo. (maybe housed each in different cages, but maybe some animals shares together cages and zones). But we are trying to be feeding them all with the same exact food. Yet the zebra eats only grass, the leopard eats only meat. And the monkey eats only fruit and nuts.

Sorry because maybe that is somewhat a poor analogy, it might be confusing.

How can we improve?

If we made the showAllDesktops like a cmdline flag... then that could potentially be more flexible invocation. Right? Well maybe that is one way. Or maybe we could just make it part of a multiple groupings set within the settings. Because to invoke a CLIENT, to send message through socket, to tell skippy to show: with a specific group of settings. That is different thing, than the daemon loading the config when daemon starts (that is persistent in background).

You recently added a separate --expose and --pager modes. So would it make sense to have 3rd --alt-tab mode (or to be called xd invocation mode, whichever)....

I think this is a case when that --mode becomes it's own independent cmdline flag. Not to combine it with --activate or --toggle flag together.

OK so lets image that we can do something like....

At the moment, cmdline is --toggle-expose or --activate-paging --> this could be re organized (a little) to split into seperate flags.

for example:

--all-desktops --layout=[xd|boxy|paging] [--toggle|--activate]

then in config file:

# use these default mode when no cmdline flag is given
defaultLayout = boxy
showAllDesktops = false # this might become a redundant setting
sort = [columns|rows] # IDK about this setting, to be cmdline or not (maybe dont bother to touch it ATM)

or (if you don't like above)

--mode=[group1|group2|group3] [--toggle|--activate]

Then in settings file we have separate group1,2,3 for each.

[group1]
setting_1 =
setting_2 =
setting_3 =

[group2]
setting_1 =
setting_2 =
setting_3 =

Maybe one of those can be a way forwards here? To make more coherent multiple ways to instantiate skippy. Without being fixed into a static setting of the daemon config.

I suppose this still is not clearly figured out yet. But we seem to be heading in this general sorts of direction. At least I hope so...

Like one way when we want to invoke in expose mode, another way as alt tab mode. Depending what is the current virtual desktop (or what is the current workspace). And which keybinding. Or if we click on an icon.

My Question:

Is this better than running 3 different skippy daemons in parallel?

Because we could instead tackle this by running multiple skippy daemons (each with different configs)... but maybe that is a bit headache in other respects. Like leads to some conflicts. Or something.

I hope this feedback makes sense. Because it is quite late here (in my time zone). And not thinking so clear in these small hours.

[felixfung]

Happy that we are converging towards the same page :)

I think skippy-xd is a very good app because it can handle all 3 use cases with virtually identical core code, and across all WMs. It's really quite amazing, isn't it!

Currently, already a user can invoke all 3 use cases, or more. #48 allowed us to do that :) A user simply holds a few config files, then do

cp [config_to_use] ~/.config/skippy/skippy-xd.rc
skippy-xd --config-reload
skippy-xd [invokation commands]

By holding different config files and appropriate mapping of hot keys, a user can do all 3 use cases or mix/match to their liking.

In terms of adding command line flags, I would be inclined to minimize it. Otherwise in one extreme every line in the config file can be switched by command line option... that leads to unmaintainability of the flags.

The only reason I put in the entry point in paging is that there is no alternative. Layout and focus sorting can be done simply via config file, but creating ClientWin as focus object for virtual desktops... actually yes potentially can be done also.... so perhaps in the future I might revert the entry points to paging, group layout+focus sorting+proxy windows into a bundle, and this bundle can be accessed by config file or command line flag. But that will be after resolving technical debts.

Btw with a little effort I can make boxy layout arrange virtual desktops in 2x2 grids rather than current 1x4 grids, that will make your experience with boxy less bad but still bad :)

[dreamcat4]

Happy that we are converging towards the same page :)

I think skippy-xd is a very good app because it can handle all 3 use cases with virtually identical core code, and across all WMs. It's really quite amazing, isn't it!

I was just thinking after my last comments (and seperate from actual skippt implementation matters)... we could maybe start some other discussion "overview" thread. To better identify those wider range of recurring user use-cases. That form the whole "landscape" or "universe" where any program like skippy can inhabit. Even though some of those use cases are not possible for skippy (due to limitations in it's implementation).

But we can at least place individual solutions better, after having a set of better define use cases....

So I believe in software waterfall model. This is called "Use case Driven Development" or "Use Case Design and Development" (UCDD).

So in this model that does not need to hold any up any pending skippy dev work, and can be discussed in parallel timeframe. Of wishlist type stuff, or to benefit other people in other projects, for example who want to replicate what skippy has done, and re-implement in other languages (or for wayland etc).

But that will be after resolving technical debts.

ok

Btw with a little effort I can make boxy layout arrange virtual desktops in 2x2 grids rather than current 1x4 grids, that will make your experience with boxy less bad but still bad :)

ok, yes any such improvements most welcome. but no urgency while you already have other pending things to stay busy with in the pipeline. but many thanks for considering this. or other ways maybe to improve this mode. again (mostly) if there are ways to ultilize the screen real estate. With less % dead area overall. Much appreciated.

[felixfung]

Factors that identify a window:

• z-ordering
• size
• positioning
• virtual desktop position
• thumbnail

Out of these, the two of us agree that size should be preserved. And thumbnail presented whenever possible. Hence we are left with:

• z-ordering
• position
• virtual desktop location

And we are left with the same table, adding a new row "priority" for clarity

preference	alt-tab	expose	paging
priority	windows z-order	window position	virtual desktop location
prev/next sorting	windows z-order	expanded layout position (per column)	per virtual desktop (per row)
position preservation	depends on user preference	preserve relative positioning loosely but not overlapping	preserve within virtual desktop, expand virtual desktop positioning
animation	not important	important	so-so
virtual desktop filtering	no preferences	prefers single desktop	all desktops

[felixfung]

P.S. there are window properties, e.g. window state, window name, window class. These can be filtered by user specification, #53.