| Geth | Terminal-Widgets/main: 6 commits pushed by (Geoffrey Broadwell)++ | 03:44 | |
| Terminal-Widgets/main: d18a1f9b7f | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/Input/Menu.rakumod Separate current v. selected for better menu KB UX |
04:04 | ||
| Terminal-Widgets/main: 5 commits pushed by (Geoffrey Broadwell)++ | 06:39 | ||
| japhb | Speaking of polish, a lot of that ^^ was polish | 06:41 | |
| Geth | Terminal-Widgets/main: 616bf45e94 | (Geoffrey Broadwell)++ | 2 files Support NO_COLOR env var and theme variant autodetection |
06:55 | |
| patrickb | I played a bit with the DirTree example. Things I noticed: | 08:14 | |
| - When scrolling below the end, it scrolls past the last line. Intuitively I'd have expected the last line to stay on screen (possibly my intuition is wrong here). | 08:15 | ||
| - It's not possible to open an empty directory with the keyboard. (With a mouse click it works though.) | 08:16 | ||
| - Keyboard events seem to "pile up". So when keeping the finger on the "down" key, the selection moves downwards. When releasing the button, the selection keeps moving downward for a noticable amount of time. I can imagine this to be difficult to solve, if so this is a pretty low prio issue, so can gladly be ignored for the foreseeable future. | 08:20 | ||
| - I find the click behavior of the scrollbar unintuitive. It's click only, right? My expectation was for the scroll bar to be drag-n-drop. It took quite a while to realize it's not actually reacting to DND, but only to the click. Possibly DND is actually a bad idea. But maybe it's possible to distinguish clicks from drags and ignore the drags entirely? Then it'd be easier to realize that dragging | 08:30 | ||
| is not happening. | |||
| I think the only sane way for dragging to be implemented is "live dragging" i.e. the scroll happens while moving the mouse, even before the mouse up event. | 08:33 | ||
| japhb | You're right, the scrolling past the last line is a bug. I've put that on my list. | 16:37 | |
| I'll take a look at the empty directory bug. That's kinda weird, since I try to keep keyboard and mouse behavior near-equivalent. | 16:39 | ||
| The KB event pile up is probably your key repeat being faster than your redraw rate. It may help to set the TW_DEBUG env var to some uint > 0 to see refresh timing info. | 16:41 | ||
| The click behavior of the scrollbar itself is known goofy. Currently a click makes a proportional move depending on where you click it. That's NOT my long-term intent. The plan is to split this into two behaviors: 1. Click and drag on the handle to move freely, and 2. Click on the uncovered part of the bar on either side of the handle to move by a screenful that direction. | 16:43 | ||
| The second behavior is already half implemented in the code, but I haven't enabled mouse drag events yet, so haven't got #1. That's probably got to go on the short list, because the current scrollbar behavior annoys me too. | 16:44 | ||
|
21:44
librasteve_ left
|
|||