[patch] Stable WindowList in mcedit

[psprint]

Hi,
I've been irritated by the files fluctuating in the WindowList? window – it only brings chaos to workflow and is driven by the Z-ordering of widgets – currently focused must be the last one in WGroup::widgets list. So it's actually a raw order imposed by implementation properties. I've fixed this in this patch:

• a new class WOrderKeptDialog is inheriting WDialog,
• it holds a GPtrArray with the same WEdit objects as in base WGroup::widgets,
• array is populated on start up (MSG_INIT) and then updated after each handled message from WDialog callback,
• an additional feature – the files are being sorted so that headers and their corresponding sources (.h/.hpp/.c/.cpp) are adjacent and with headers first.

What do you think? Fix or wontfix? IMO, this change has been asking for a patch. It also allows to finally have e.g.: Alt-1, Alt-2, etc. shortcuts switching to the first buffer, and second, etc. implemented in a following patch.

[andrew_b]

Replying to psprint:

• an additional feature – the files are being sorted so that headers and their corresponding sources (.h/.hpp/.c/.cpp) are adjacent and with headers first.

mc editor core will not be populated with .h/.hpp/.c/.cpp-only features.

[psprint]

I've fully generalized the sorting and hidden it behind two options:

• files that are similar are grouped to be adjacent,
• similar means: only differing in extension and/or in case (ASCII only),
• the order within the cluster is: lexicographic order of extensions,
• so e.g.: .c files will be sorted before .h files in the cluster,
• the order can be reversed by an option and the clustering disabled too.

The options are:

• editor_cluster_similar_filenames, default true,
• editor_cluster_similar_filenames_reversed, default true (so that C/C++ files have headers first by default :).

I've decided to make the clustering enabled by default. After all, if unstable, fluctuating list of files is OK, then why nicely sorted and grouped one wouldn't?

Here's an ​asciinema recording.

[psprint]

generic clustering

[ossi]

z-ordering is effectively LRU, which is kinda the default for task-switcher-like dialogs. this doesn't contradict with assigning stable numbers to windows. and intuitive selection from a long list can be done with incremental filtering like you already implemented elsewhere.

[psprint]

Do you edit with MCEdit much, or rather not? IMO, if you would work with MCEdit on multiple files on regular basis you would have to agree that the constant reordering of windows is a mess with which it is hard to live on.

I attach an additional patch implementing Ctrl-x 1, Ctrl-x 2 … Ctrl-x 0 switching between the properly ordered windows.

[ossi]

i don't, for reasons already explained elsewhere. but i use qt creator, whose ctrl-tab-invoked document switcher also does LRU, just like my window manager's alt-tab-invoked task switcher does. it's the intuitive thing to do, which is why just about everyone does it, at least by default.

obviously, LRU's usefulness breaks down beyond a certain depth, but at this point any kind of "direct menu" becomes practically unusable, and you need some kind of search/filter function to make it efficient. qt creator has its "locator" (ctrl-k-invoked) for that, which integrates just about every possible "text based content addressing mode" into a single widget - and it's awesome.

[psprint]

it isn't LRU – you have CK_WindowNext, which moves the last file to the front (!), and CK_WindowPrev, that swaps the current and the previous (it's the most usable one IMO). ​a proof. LRU means the more focus and memorability for a file the more recent it is, while MC requires to have a memory of the last file – the one that a normal person remembers least.

[psprint]

PS. You see how much code I do write – it's all in MCEdit. So could you just trust me that current window switching is very irritating?

[andrew_b]

IMO, StableWindowList?.patch is overdesign. Just the second list can be added to editor. That list will hold opened windows in order of them was opened regardless of Z-order of windows as widgets.

[ossi]

So could you just trust me that current window switching is very irritating?

or, you know, you could actually explain the issue precisely at the beginning, rather than trying to convince everyone of your solution for whatever-it-is.

the only thing that is wrong with the window _list_ is that it's exactly backwards. this is only half as bad, as the cursor is still placed on the right file, but i'm all for inverting it.

the behavior of CK_WindowNext and CK_WindowPrev appears kinda swapped, but otherwise sounds exactly like what one would expect - it's the exact equivalent of pressing alt-shift-tab and alt-tab in the window manager. what completely breaks the usability is the fact that one cannot keep alt pressed and use (shift-)tab to navigate further in the given direction. i don't think this even can be implemented at all, as i'm not aware of a way to get notified of modifier key status changes inside a tty (side channels could be exploited under X11 and in VTs, but that would still leave some cases unaddressed). to salvage that functionality, CK_WindowNext and CK_WindowPrev would have to actually pop up the window list, instantly navigate it, and when pressed repeatedly navigate further, but unlike in a "real" task switcher, the selection would have to be confirmed by pressing enter rather than just releasing a modifier key. this would take away the possibility to switch to the previously focused window with just one hotkey, but that probably isn't too bad.

the alternative is concluding that pressing enter is too much, and LRU is overrated anyway. that's what you did: it's exactly the same as linux treats VTs (which one can navigate with alt-left/right), and quite many applications treat tabs (which are naturally arranged in a constantly visible fixed-order row, so that actually makes sense).

i have no stakes in this, so i'll leave the maintainers decide which approach they prefer.

regarding your approach, i don't think it's sensible to sort the files alphabetically (and to introduce mostly meaningless micro-options to mask the fact that you want to treat .h files specially). instead, the order should be imposed by file opening order. ideally, the numbers would stick even if files are closed in the middle; the freed up "slots" would be re-used by later opened files, just as is the case for VTs. the window list could offer the possibility to manually change the order (e.g., by pressing shift-up/down on or by mouse-dragging an entry).

[psprint]

Replying to ossi:

So could you just trust me that current window switching is very irritating?

or, you know, you could actually explain the issue precisely at the beginning, rather than trying to convince everyone of your solution for whatever-it-is.

the only thing that is wrong with the window _list_ is that it's exactly backwards. this is only half as bad, as the cursor is still placed on the right file, but i'm all for inverting it.

I can argue and prove that it's more than that – it's essentially broken, because:

• the only way to move across the files is the rear side.

Only WindowNext allows to navigate across all files (WindowPrev can go only 1 step), and it works, like you've said the same as pressing alt-shift-tab, i.e.: from the end. I think that this explains my huge frustration – for a long time I've had to move to next via, through the last files. Huge inconvenience.

I will address other posts later.

[ossi]

by 'list' i meant the "list ..." option from the window menu, i.e., the "open files" dialog, which should be kind of obvious from the things i wrote about it. do you agree that it behaves like a regular LRU? the entire next paragraph builds on this.

[psprint]

Replying to andrew_b:

IMO, StableWindowList?.patch is overdesign. Just the second list can be added to editor. That list will hold opened windows in order of them was opened regardless of Z-order of windows as widgets.

Well it's you that advised me to go with software engineering approach (to inherit and extend) rather than with a hacker approach (to do small, crucial changes to the existing objects), and I think that it was a good direction. IMO, it pays much also in this patch – WOrderKeptDialog is being used only for the editor main dialog object, the rest of the code uses plain WDialog, which is a good thing. And, also, I've become allergic to do the hacker thing – I wouldn't want to inject the new order-aware code into existing WDialog, cluttering it… I think that the proposed solution is clean and well done from the engineering point of view. Could the "order isn't needed in all Dialogs" point lead you to accept the patch as it is? It's basically what you've said to me at the MultiSearch patch – that not all WListboxes need to have their events to be forwarded/obtained from a paired WInput (so new extending them classes should be created).