Lower the amount of inputs to set a limit

[MCOfficer]

So here's the thought that originally brought me here.

Though Throttle works just fine, I found myself a little frustrated by having to perform at least 5 sequential inputs just to set a limit in one direction:
Right-click -> Set *load limit -> click into TextBox -> Enter number -> (Click into Unit Selector -> Select Unit -> ) Apply.

There are Some small things around the number input itself that would help, for example:

• Bringing the TextBox into focus immediately
• or using DragValues instead of TextBoxes
• My personal favourite: somehow make the TextBox react to the Scroll Wheel while hovering
• Same thing for the Unit Selector: The default is a great touch so I've never had to use it, but trying to scroll on hover felt natural to me
• If not using a modal: Ditch the Apply button, use any input immediately (after half a second of grace period)

But there's also the option of replacing the Modal entirely. So here's a few ideas:

1. Set the Limit in the Table Itself

• 👍Instant Access
• requires immediate apply (no Apply button)
• 👎hard to access because the rows keep jumping about
• 👎yet more columns, so table width is a concern

2a. Set the Limit in the Detail Panel

• probably the safest option, just move the entire Context Menu and modal into the right-hand panel
• 👍Almost instant access
• 👍fixes all problems with 1)

2b. Set the Limit in a dedicated Panel

• Same as 2a, but with an extra panel... somewhere? Maybe a popup bottom-left?

3. Move the Inputs into the Context Menu

• 👍Almost instant access
• Best with instant apply and more mouse-centric input (DragValue, scrolling)
• 👎occasionally the context menu blanks out for one frame with "Unattributed traffic cannot be limited". That could lead to issues when trying to make it stateful, and making it keep input state between frames...

---

Just wanted to throw these at your proverbial wall and see what sticks.

Having written them down,

I went from being a fan of 3. to a fan of 2a. - there is space at the bottom of the details panel. and I don't see many downsides. It's decoupled from the constant table sorting, and all the input sensing in the table area. And just like the other ideas, it's easily visible to the user.

one could even lean towards 2b by adding a horizontal divider halfway down, making the layout fixed regardless of content size. Kind of like the IntelliJ family can have two distinct "panels" in the same sidebar:

[FrancescoCoding]

Thanks for writing this up.

2a gets my vote too, and it's cheaper than it looks. The detail panel already has the exe_path key and already shows a read only rule summary, so it's mostly turning that label into live controls. base_rule / send_rule / set_blocked are key driven already, so block and remove rule move down there unchanged.

I'd keep the modal around as a second route rather than delete it, so LimitModal shrinks to just "which process, which direction" and wraps the same input widget the panel uses. Worth having that as one shared function either way, otherwise the parse and commit logic lives in two places and drifts. 2a also sidesteps your concern in 3), since the panel can show a persistent disabled state instead of a label that blanks for a frame.

Two things I'd add:

• 2a alone doesn't save many inputs. Select, click, type, Apply is still 4. It only really pays off if the Apply button goes too, so I'd do both at once. Worth noting the debounce should fire on idle after the last keystroke rather than a fixed timer, otherwise typing 50 commits 5 on the way, probably you meant the same thing.
• Not sold on DragValue though. The panel scrolls because of the history plot, so a wheel over input eating that gets annoying, and dragging is fiddly for a value you usually know. I'd rather go with a row of preset chips above the box that set the value outright, something like 10 / 25 / 50 / 100, plus autofocus and Enter to commit. That's one click for the common case since most people want a round number anyway, and the box stays for anything else. Stepper arrows on the input and up/down arrow keys while it's focused would be a nice extra on top for nudging. Keeping the TextEdit also means empty still means unlimited, so nothing changes there.

[MCOfficer]

2a it is, then. Also concur on ditching the apply button, and the debounce.

I like your idea of quick preset values. I also thought of a horizontal slider over preset values, but the only advantage i see over chips is less UI clutter. But it's probably best to move the controls first, and think about optimizing later.

The other thing I keep coming back to is, how do you define useful presets for users with wildly different connections? Someone with a 10Mbit line wouldn't be well served by 3 of the chips being irrelevant to them; likewise a fibre user needs at least some of the chips to be within their speed range.
And the answer is probably, you don't, you just go for some serviceable defaults and let the users configure them. So then throttle needs some persistent config.

For persistance, I've had my eyes on amethystate for a while, but it might be a little overkill for us. I guess the easiest path is to co-opt the way rules.json et al. are written?