Ticket #4296 (closed enhancement: wontfix)
Any interest in alternate window list implementation in mcedit?
Reported by: | psprint | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | mcedit | Version: | master |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Branch state: | no branch | Votes for changeset: |
Description
I thought about implementing an alternate window listing that would be button based instead of listbox based. Basically, for each opened file a button with basename as the label plus preceding hotkey.is being created and displayed in 2 columns. What do you think? For me, the window listing is more clean, elegant than the listbox with long, messy full paths… You can check out an implementation that I have for my mcedit fork here: https://asciinema.org/a/442162, If there would be an intention of including it also in upstream, I can then prepare patch.
Change History
Note: See
TracTickets for help on using
tickets.
you can't always use only basenames, as that may be ambiguous. you need a smart algo that elides common parts instead. that would be a worthwhile addition to the window list regardless of other changes.
note that your impl is still "listbox based", as you can navigate it as before. this is good, only your wording is misleading.
the two colums are fine (though why stop at two?), but you need to make it sort rows-first as the panels do, as otherwise it's hard to follow.
but more fundamentally i wonder whether that really is an improvement over the multi-key incremental filtering. after all, you still have to find the files in the list visually, and the hotkeys usually change as files are opened and closed. this concept is overall the same as numbered tabs, and for example qt creator avoids it because of the associated usability concerns.