Scrollbar.IndicatorHovered returns false while the scrollbar is being
dragged because Scrollbar.drag is grabbing the pointer while dragging.
Add a new method Dragging and use that. This would allow us to render
the indicator differently for hovering and dragging, but for now we just
draw it as hovered while it's being dragged.
Signed-off-by: Dominik Honnef <dominik@honnef.co>
---
widget/list.go | 8 +++++++-widget/material/list.go | 2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/widget/list.go b/widget/list.go
index ae395736..9c442943 100644
--- a/widget/list.go+++ b/widget/list.go
@@ -163,7 +163,8 @@ func (s *Scrollbar) AddDrag(ops *op.Ops) {
}
// IndicatorHovered returns whether the scroll indicator is currently being
-// hovered by the pointer.+// hovered by the pointer. Note that this returns false while the scrollbar+// is being dragged.func (s *Scrollbar) IndicatorHovered() bool {
return s.indicator.Hovered()
}
@@ -174,6 +175,11 @@ func (s *Scrollbar) ScrollDistance() float32 {
return s.delta
}
+// Dragging returns whether the scroll indicator is currently being dragged.+func (s *Scrollbar) Dragging() bool {+ return s.dragging+}+// List holds the persistent state for a layout.List that has a
// scrollbar attached.
type List struct {
diff --git a/widget/material/list.go b/widget/material/list.go
index 81a7c984..cc1a2b01 100644
--- a/widget/material/list.go+++ b/widget/material/list.go
@@ -126,7 +126,7 @@ func (s ScrollbarStyle) Layout(gtx layout.Context, axis layout.Axis, viewportSta
s.Scrollbar.Layout(gtx, axis, viewportStart, viewportEnd)
// Darken indicator if hovered.
- if s.Scrollbar.IndicatorHovered() {+ if s.Scrollbar.IndicatorHovered() || s.Scrollbar.Dragging() { s.Indicator.Color = s.Indicator.HoverColor
}
--
2.36.1
On Thu Jun 30, 2022 at 02:30, Dominik Honnef wrote:
> Scrollbar.IndicatorHovered returns false while the scrollbar is being> dragged because Scrollbar.drag is grabbing the pointer while dragging.> Add a new method Dragging and use that. This would allow us to render> the indicator differently for hovering and dragging, but for now we just> draw it as hovered while it's being dragged.>> Signed-off-by: Dominik Honnef <dominik@honnef.co>> ---> widget/list.go | 8 +++++++-> widget/material/list.go | 2 +-> 2 files changed, 8 insertions(+), 2 deletions(-)>> diff --git a/widget/list.go b/widget/list.go> index ae395736..9c442943 100644> --- a/widget/list.go> +++ b/widget/list.go> @@ -163,7 +163,8 @@ func (s *Scrollbar) AddDrag(ops *op.Ops) {> }> > // IndicatorHovered returns whether the scroll indicator is currently being> -// hovered by the pointer.> +// hovered by the pointer. Note that this returns false while the scrollbar> +// is being dragged.
Why not keep it simple and return true from IndicatorHovered when
dragging?
> func (s *Scrollbar) IndicatorHovered() bool {> return s.indicator.Hovered()> }> @@ -174,6 +175,11 @@ func (s *Scrollbar) ScrollDistance() float32 {> return s.delta> }> > +// Dragging returns whether the scroll indicator is currently being dragged.> +func (s *Scrollbar) Dragging() bool {> + return s.dragging> +}> +
YAGNI?
> // List holds the persistent state for a layout.List that has a> // scrollbar attached.> type List struct {> diff --git a/widget/material/list.go b/widget/material/list.go> index 81a7c984..cc1a2b01 100644> --- a/widget/material/list.go> +++ b/widget/material/list.go> @@ -126,7 +126,7 @@ func (s ScrollbarStyle) Layout(gtx layout.Context, axis layout.Axis, viewportSta> s.Scrollbar.Layout(gtx, axis, viewportStart, viewportEnd)> > // Darken indicator if hovered.> - if s.Scrollbar.IndicatorHovered() {> + if s.Scrollbar.IndicatorHovered() || s.Scrollbar.Dragging() {
This change indicates that returning true from IndicatorHovered seems
logical.
> s.Indicator.Color = s.Indicator.HoverColor> }> > -- > 2.36.1
"Elias Naur" <mail@eliasnaur.com> writes:
> On Thu Jun 30, 2022 at 02:30, Dominik Honnef wrote:>> Scrollbar.IndicatorHovered returns false while the scrollbar is being>> dragged because Scrollbar.drag is grabbing the pointer while dragging.>> Add a new method Dragging and use that. This would allow us to render>> the indicator differently for hovering and dragging, but for now we just>> draw it as hovered while it's being dragged.>>>>>>> Signed-off-by: Dominik Honnef <dominik@honnef.co>>> --->> widget/list.go | 8 +++++++->> widget/material/list.go | 2 +->> 2 files changed, 8 insertions(+), 2 deletions(-)>>>> diff --git a/widget/list.go b/widget/list.go>> index ae395736..9c442943 100644>> --- a/widget/list.go>> +++ b/widget/list.go>> @@ -163,7 +163,8 @@ func (s *Scrollbar) AddDrag(ops *op.Ops) {>> }>> >> // IndicatorHovered returns whether the scroll indicator is currently being>> -// hovered by the pointer.>> +// hovered by the pointer. Note that this returns false while the scrollbar>> +// is being dragged.>> Why not keep it simple and return true from IndicatorHovered when> dragging?
I agree that ideally IndicatorHovered returns true even while dragging.
However, I don't think it should return true simply because we're
dragging: the cursor can move off the indicator once dragging has begun.
That is, we can legitimately be dragging without hovering the indicator.
I'm not familiar enough with the input handling to implement that
behavior. ISTM that the drag's grab makes this difficult to do.
>>> func (s *Scrollbar) IndicatorHovered() bool {>> return s.indicator.Hovered()>> }>> @@ -174,6 +175,11 @@ func (s *Scrollbar) ScrollDistance() float32 {>> return s.delta>> }>> >> +// Dragging returns whether the scroll indicator is currently being dragged.>> +func (s *Scrollbar) Dragging() bool {>> + return s.dragging>> +}>> +>> YAGNI?>>> // List holds the persistent state for a layout.List that has a>> // scrollbar attached.>> type List struct {>> diff --git a/widget/material/list.go b/widget/material/list.go>> index 81a7c984..cc1a2b01 100644>> --- a/widget/material/list.go>> +++ b/widget/material/list.go>> @@ -126,7 +126,7 @@ func (s ScrollbarStyle) Layout(gtx layout.Context, axis layout.Axis, viewportSta>> s.Scrollbar.Layout(gtx, axis, viewportStart, viewportEnd)>> >> // Darken indicator if hovered.>> - if s.Scrollbar.IndicatorHovered() {>> + if s.Scrollbar.IndicatorHovered() || s.Scrollbar.Dragging() {>> This change indicates that returning true from IndicatorHovered seems> logical.>
It's not uncommon for scrollbar indicators to render differently for
hovered and clicked. I just went with the easy option here and render
them identically. I wouldn't be surprised if you'd want to change this
in the future.
However, on second thought, I'm not happy with "Dragging" and its
implementation. The indicator can be in a state where it's being clicked
but not yet being dragged. I.e. it's "active" but hasn't moved yet. For
styling, we're really interested in clicked, regardless of dragging.
What do you think?
>> s.Indicator.Color = s.Indicator.HoverColor>> }>> >> -- >> 2.36.1
On Thu, 30 Jun 2022 at 14:11, Dominik Honnef <dominik@honnef.co> wrote:
>> "Elias Naur" <mail@eliasnaur.com> writes:>> > On Thu Jun 30, 2022 at 02:30, Dominik Honnef wrote:> >> Scrollbar.IndicatorHovered returns false while the scrollbar is being> >> dragged because Scrollbar.drag is grabbing the pointer while dragging.> >> Add a new method Dragging and use that. This would allow us to render> >> the indicator differently for hovering and dragging, but for now we just> >> draw it as hovered while it's being dragged.> >>> >> >> >> >> Signed-off-by: Dominik Honnef <dominik@honnef.co>> >> ---> >> widget/list.go | 8 +++++++-> >> widget/material/list.go | 2 +-> >> 2 files changed, 8 insertions(+), 2 deletions(-)> >>> >> diff --git a/widget/list.go b/widget/list.go> >> index ae395736..9c442943 100644> >> --- a/widget/list.go> >> +++ b/widget/list.go> >> @@ -163,7 +163,8 @@ func (s *Scrollbar) AddDrag(ops *op.Ops) {> >> }> >>> >> // IndicatorHovered returns whether the scroll indicator is currently being> >> -// hovered by the pointer.> >> +// hovered by the pointer. Note that this returns false while the scrollbar> >> +// is being dragged.> >> > Why not keep it simple and return true from IndicatorHovered when> > dragging?>> I agree that ideally IndicatorHovered returns true even while dragging.> However, I don't think it should return true simply because we're> dragging: the cursor can move off the indicator once dragging has begun.> That is, we can legitimately be dragging without hovering the indicator.>> I'm not familiar enough with the input handling to implement that> behavior. ISTM that the drag's grab makes this difficult to do.>> >> >> func (s *Scrollbar) IndicatorHovered() bool {> >> return s.indicator.Hovered()> >> }> >> @@ -174,6 +175,11 @@ func (s *Scrollbar) ScrollDistance() float32 {> >> return s.delta> >> }> >>> >> +// Dragging returns whether the scroll indicator is currently being dragged.> >> +func (s *Scrollbar) Dragging() bool {> >> + return s.dragging> >> +}> >> +> >> > YAGNI?> >> >> // List holds the persistent state for a layout.List that has a> >> // scrollbar attached.> >> type List struct {> >> diff --git a/widget/material/list.go b/widget/material/list.go> >> index 81a7c984..cc1a2b01 100644> >> --- a/widget/material/list.go> >> +++ b/widget/material/list.go> >> @@ -126,7 +126,7 @@ func (s ScrollbarStyle) Layout(gtx layout.Context, axis layout.Axis, viewportSta> >> s.Scrollbar.Layout(gtx, axis, viewportStart, viewportEnd)> >>> >> // Darken indicator if hovered.> >> - if s.Scrollbar.IndicatorHovered() {> >> + if s.Scrollbar.IndicatorHovered() || s.Scrollbar.Dragging() {> >> > This change indicates that returning true from IndicatorHovered seems> > logical.> >>> It's not uncommon for scrollbar indicators to render differently for> hovered and clicked. I just went with the easy option here and render> them identically. I wouldn't be surprised if you'd want to change this> in the future.>> However, on second thought, I'm not happy with "Dragging" and its> implementation. The indicator can be in a state where it's being clicked> but not yet being dragged. I.e. it's "active" but hasn't moved yet. For> styling, we're really interested in clicked, regardless of dragging.> What do you think?>
Clicked (or Pressed) seems better than Dragging. WDYT, Chris?
Elias
> > > This change indicates that returning true from IndicatorHovered seems> > > logical.> > >> >> > It's not uncommon for scrollbar indicators to render differently for> > hovered and clicked. I just went with the easy option here and render> > them identically. I wouldn't be surprised if you'd want to change this> > in the future.> >> > However, on second thought, I'm not happy with "Dragging" and its> > implementation. The indicator can be in a state where it's being clicked> > but not yet being dragged. I.e. it's "active" but hasn't moved yet. For> > styling, we're really interested in clicked, regardless of dragging.> > What do you think?> >>> Clicked (or Pressed) seems better than Dragging. WDYT, Chris?
Agreed. The important thing, really, is that the user has initiated a
mouse interaction with the indicator (other than using the scroll
wheel).