Fix battery slider snapping to unsupported charge limits#5384
Conversation
|
@poeggi hello, Thanks, but I'm not sure if it makes a big difference :) It just prevents you from dragging a circle at all over this range, which can confuse people even more (making them think UI is lagging?) |
|
Obviously I can only speak for myself, i find this solution feels more natural. That said, I though fixing keyboard arrow keys could make sense also ... but trying my own patch - found they were also not working. So I fixed this. |
|
What about this, to make it more clear? 
|
|
So with this PR we could have two improvements: 1) make slider arrow-key controllable and 2) visually hint towards possible values (on any given platform) => (#2 implementation follwing now) |
|
@poeggi thanks, With keyboard controls - you can already control it. I agree, it's not super convenient that you need to hold left/right key a bit longer to jump over non-supported range (i.e. you need to let it do 2 steps form 80 to 90 to jump to 100 instead of just clicking a key). From other side it kind of prevents accidental toggles. Actually whole keyboard control for the slider was initially added for a blind guy. For highlighting range - I was thinking about this before, I just didn't find a good UI solution that won't look cluttered :| |
|
Your call obviously. All I can do is make proposals. |
|
Or alternative idea - more subtle: |
|
Commiting code for this last (more subtile) proposal - built and tested, works here. |
On models with restricted charge limits (e.g. GA403), the slider allowed dragging to values like 90% which the backend immediately remapped to 100%, causing a jarring jump on mouse release. Extract the clamping logic into ClampLimit() and use it to derive the actual supported stop points for the slider at init time, so snapping happens while dragging rather than after letting go.
Step-based increment got stuck at boundaries between stops — e.g. pressing Right at 80% would try 85%, which snapped back to 80%. Now jumps to the next/previous stop directly when Stops is set.
Draws small rounded tick marks behind the slider bar at each supported charge limit position, so valid stops are visible while dragging.
Replace tick lines with small filled circles matching the bar color, drawn behind the bar so they peek out as subtle round bumps hinting at the discrete snap positions.
|
I would like to have this added, I often change between 60 and 80% and keep accidentally setting it to 65/75 for a second. It's no big deal of course but still a quality of life improvement. |
|
@EminGT it's a bit different thing :) It just prevents you from dragging tracker at 85-95 range at all |
|
@EminGT , this is what it looks like usage-demo.mp4 |
|
Yeah being able to actually see the dot on the available points makes it so much easier to just click on the right spot on the slider without having to manually move around the slider to "find" 80. |
|
In this video you can see how I'm struggling to go between 60 and 80 back to back, although a bit exaggerated :P Recording.2026-05-12.215752.mp4 |
|
@EminGT if you will click anywhere between 40% and 60% dot will end up on minimum supported value (60%), so it's quite easy :) |
|
@seerge hope you don't mind me disagree as I also felt usability is impaired without this change - that's why I prepared it in the first place. When I started using G-Helper - which I really love btw! - I have been convinced for weeks that the charge slider was broken, which is why I wanted to write a bug report earlier (and soon after looking into it found investigating it is not broken, just behaving awkwardly). Also, having to spam the keyboard or hold button pressed to get past that "dead zone" does not feel like a normal use scenario - rather a quirk (you may get used to). You can tell, I am still in favor of my own patch ;-) ... but again - waiting for your decision of course. |
|
Yeah even if it snaps to 60% when I click on 40%, it's still just finicky and still a problem when wanting to specifically set it to 70% for example. |
|
Hi @seerge - just wanted to ask if there is anything I can do to help come to a conclusion if this is something to merge or discard? Here to make any adjustments to the PR if needed. |
|
@poeggi hi, sorry for a slow response :) I didn't had time to settle in my head yet. In reality I don't see it as very big UI problem in a first place. Honestly, i don't understand why Asus has started restricting charge limits at all in newer models, as on G14 2022 (the one i used to develop app initially) it was possible to set any limit, even 95%, that's from where whole UX/UI solution comes from. And I even had idea to add actual battery charge to a same bar (but didn't add it yet) :) |
|
Hey guys, nice to see you. I'm starting to learn C# after Java, as I've found some drawbacks. Now I'm trying to write Stealer. |
seerge
force-pushed
the
main
branch
3 times, most recently
from
7f3d94c to
26b5f5c
Compare
4 participants
On models with restricted charge limits (e.g. GA403), the slider allowed dragging to values like 90% which the backend immediately remapped to 100%, causing a jarring jump on mouse release.
Extract the clamping logic into ClampLimit() and use it to derive the actual supported stop points for the slider at init time, so snapping happens while dragging rather than after letting go.
See #5383