Not a regression, but shuld go into emacs-24

Not a regression, but shuld go into emacs-24

[Jan Djärv]

Hello.

Jump-scrolling with Gtk+ scrollbars does not work with emacs 24 or 23.
Previously a left click on the through jumped one page forward or backwards.
A middle click on the through jumped to the place where the click was made.
A right click did nothing.

Or that was the intention.  It turns out that jumping probably never has 
worked with Gtk+.  The situation is now more pronounced as Gtk+ 3 at some 
point changed the meaning of
left click (previously page scroll, now jump)
middle click (previously jump, now does nothing)
and right click (previously did nothing, now does page scroll).

I would therefore like to commit this to the emacs-24 brach, even if the error 
is also present in emacs-23:

=== modified file 'src/xterm.c'
--- src/xterm.c	2014-05-29 16:47:49 +0000
+++ src/xterm.c	2014-06-01 10:36:07 +0000
@@ -4460,6 +4460,7 @@
            part = scroll_bar_handle;
            whole = gtk_adjustment_get_upper (adj) -
              gtk_adjustment_get_page_size (adj);
+          position = value;
            portion = min ((int)position, whole);
            bar->dragging = portion;
          }

Thanks,

	Jan D.

Re: Not a regression, but shuld go into emacs-24

[martin rudalics]

 > +          position = value;

How/why does this value differ from that returned by
gtk_adjustment_get_value?

As an aside: Why is the third argument of x_send_scroll_bar_event called
PORTION while inherently it's a POSITION relative to WHOLE?  Doesn't
such nomenclature clash with that of say XTset_vertical_scroll_bar where
PORTION represents the size of the slider wrt WHOLE?

martin

Re: Not a regression, but shuld go into emacs-24

[Jan Djärv]

Hi.

2014-06-01 14:31, martin rudalics skrev:
>  > +          position = value;
>
> How/why does this value differ from that returned by
> gtk_adjustment_get_value?

That returns the value the scroll bar has before the scroll, not what it will be.

>
> As an aside: Why is the third argument of x_send_scroll_bar_event called
> PORTION while inherently it's a POSITION relative to WHOLE?  Doesn't
> such nomenclature clash with that of say XTset_vertical_scroll_bar where
> PORTION represents the size of the slider wrt WHOLE?
>

position is not needed, I removed it.  It is called portion in Motif/Lesstif 
(xm_scroll_callback) also, thats where it originates.  x_send_scroll_bar_event 
itself calls it portion.  xaw_scroll_callback calls it portion.  Has not 
caused any confusion what I know of.  Its a tiny cosmetic thing.

	Jan D.

Re: Not a regression, but shuld go into emacs-24

[martin rudalics]

 > position is not needed, I removed it.  It is called portion in
 > Motif/Lesstif (xm_scroll_callback) also, thats where it originates.
 > x_send_scroll_bar_event itself calls it portion.  xaw_scroll_callback
 > calls it portion.  Has not caused any confusion what I know of.  Its a
 > tiny cosmetic thing.  Jan D.

I'm currently trying to set up horizontal scroll bars so please help me
clarify this issue.  The comment of x_set_toolkit_scroll_bar_thumb says

/* Set the thumb size and position of scroll bar BAR.  We are currently
    displaying PORTION out of a whole WHOLE, and our position POSITION.  */

That of x_send_scroll_bar_event says

/* Send a client message with message type Xatom_Scrollbar for a
    scroll action to the frame of WINDOW.  PART is a value identifying
    the part of the scroll bar that was clicked on.  PORTION is the
    amount to scroll of a whole of WHOLE.  */

So the term PORTION in x_send_scroll_bar_event seems semantically
equivalent to the term POSITION in x_set_toolkit_scroll_bar_thumb and
not to the term PORTION in x_set_toolkit_scroll_bar_thumb.  Is that
interpretation correct?

Thanks, martin

Re: Not a regression, but shuld go into emacs-24

[Jan Djärv]

Hello.

2 jun 2014 kl. 09:05 skrev martin rudalics <rudalics@gmx.at>:

> So the term PORTION in x_send_scroll_bar_event seems semantically
> equivalent to the term POSITION in x_set_toolkit_scroll_bar_thumb and
> not to the term PORTION in x_set_toolkit_scroll_bar_thumb.  Is that
> interpretation correct?

Only for a jump scroll.  When dragging or scrolling by page, PORTION passed to x_send_scroll_bar_event is zero, as is WHOLE. 
For jump scroll, PORTION is the position of the scroll bar thumb that we jump to.
 
The values of PORTION in x_send_scroll_bar_event and x_set_toolkit_scroll_bar_thumb are different.  The first has values as defined by the scroll bar.  For Gtk+, Motif and Xaw this is a value between 0 or 1 and 10000000.

The values to x_set_toolkit_scroll_bar_thumb are in characters, i.e. show PORTION characters for the buffer, starting at character POSITION.  The buffer has a total of WHOLE characters.

	Jan D.

Re: Not a regression, but shuld go into emacs-24

[martin rudalics]

 > Only for a jump scroll.  When dragging or scrolling by page, PORTION
 > passed to x_send_scroll_bar_event is zero, as is WHOLE.

IIUC in XmCR_DRAG we set PORTION to 'cs->value', in xg_scroll_callback
we set PORTION to 'position' and in xaw_scroll_callback we explicitly
pass 'position' as PORTION argument.  So in all three cases we pass a
position.  And IIUC we pass zero for PORTION and WHOLE iff when we end
scrolling (when the user releases the slider).

 > For jump scroll, PORTION is the position of the scroll bar thumb that we jump to.

I didn't look into jump scroll so far.  But what you say here indicates
that jump scroll also passes a position via the PORTION argument.

 > The values of PORTION in x_send_scroll_bar_event and
 > x_set_toolkit_scroll_bar_thumb are different.  The first has values as
 > defined by the scroll bar.  For Gtk+, Motif and Xaw this is a value
 > between 0 or 1 and 10000000.

Yes (in my experience Gtk+ can handle WHOLE directly as is).

 > The values to x_set_toolkit_scroll_bar_thumb are in characters,
 > i.e. show PORTION characters for the buffer, starting at character
 > POSITION.  The buffer has a total of WHOLE characters.

But the values passed to x_send_scroll_bar_event are in characters too
(and the value of WHOLE is supposed to be the same as when setting the
thumb).  Or am I missing something?

martin

Re: Not a regression, but shuld go into emacs-24

[martin rudalics]

 > But the values passed to x_send_scroll_bar_event are in characters too
 > (and the value of WHOLE is supposed to be the same as when setting the
 > thumb).

Which is obviously incorrect.  But `scroll-bar-scale' simply divides
PORTION by WHOLE to get a buffer position.

martin

Re: Not a regression, but shuld go into emacs-24

[Jan Djärv]

Hello.

2 jun 2014 kl. 20:02 skrev martin rudalics <rudalics@gmx.at>:

> > Only for a jump scroll.  When dragging or scrolling by page, PORTION
> > passed to x_send_scroll_bar_event is zero, as is WHOLE.
> 
> IIUC in XmCR_DRAG we set PORTION to 'cs->value',

XmCR_DRAG is jump in Motif speak.

> in xg_scroll_callback
> we set PORTION to 'position'

No we don't, please look at the current code.  portion and whole are initialized to 0 and
only set for JUMP.

> and in xaw_scroll_callback we explicitly
> pass 'position' as PORTION argument.

Because that callback does not distinguish between the different scroll modes.


>  So in all three cases we pass a
> position.  And IIUC we pass zero for PORTION and WHOLE iff when we end
> scrolling (when the user releases the slider).

Iff is clearly wrong.  Look  at xg_scroll_callback and do tell me how portion and whole gets a value other than zero when scroll is not GTK_SCROLL_JUMP.
Ditto for xm_scroll_callback when cs->reason is not XmCR_DRAG.

> 
> > For jump scroll, PORTION is the position of the scroll bar thumb that we jump to.
> 
> I didn't look into jump scroll so far.  But what you say here indicates
> that jump scroll also passes a position via the PORTION argument.
> 
> > The values of PORTION in x_send_scroll_bar_event and
> > x_set_toolkit_scroll_bar_thumb are different.  The first has values as
> > defined by the scroll bar.  For Gtk+, Motif and Xaw this is a value
> > between 0 or 1 and 10000000.
> 
> Yes (in my experience Gtk+ can handle WHOLE directly as is).

This looks ugly when WHOLE changes.  The Gtk+ scroll bar does not redraw nicely.

	Jan D.

> 
> > The values to x_set_toolkit_scroll_bar_thumb are in characters,
> > i.e. show PORTION characters for the buffer, starting at character
> > POSITION.  The buffer has a total of WHOLE characters.
> 
> But the values passed to x_send_scroll_bar_event are in characters too
> (and the value of WHOLE is supposed to be the same as when setting the
> thumb).  Or am I missing something?
> 
> martin

Re: Not a regression, but shuld go into emacs-24

[martin rudalics]

 >> IIUC in XmCR_DRAG we set PORTION to 'cs->value',
 >
 > XmCR_DRAG is jump in Motif speak.

So is "dragging the slider" equivalent to 'jump' in Emacs speak?  Then I
misunderstood the nomenclature completely.  I always thought a 'jump' is
what happens when I click some position above or below the slider.

Reading http://comments.gmane.org/gmane.emacs.devel/6201 confuses me
even more.

 >> in xg_scroll_callback
 >> we set PORTION to 'position'
 >
 > No we don't, please look at the current code.  portion and whole are initialized to 0 and
 > only set for JUMP.

You're obviously right.  I was paying attention only to slider-based
actions.  PORTION and WHOLE seem to be not used for anything else.

 >> and in xaw_scroll_callback we explicitly
 >> pass 'position' as PORTION argument.
 >
 > Because that callback does not distinguish between the different scroll modes.

What is a "scroll mode"?  Something like "page increment" or "jump
scroll"?

 >>   So in all three cases we pass a
 >> position.  And IIUC we pass zero for PORTION and WHOLE iff when we end
 >> scrolling (when the user releases the slider).
 >
 > Iff is clearly wrong.  Look  at xg_scroll_callback and do tell me how
 > portion and whole gets a value other than zero when scroll is not
 > GTK_SCROLL_JUMP.

Yes (see above).  But for jumping we always pass a position expressed as
the portion of WHOLE that comes before the start of the slider.  I still
think that using the term PORTION to express the relative position of
the slider in one case and the relative size of the slider in the other
is unfortunate.  Obviously, after working with the code for years this
distinction boils down to a cosmetic issue ...

 > Ditto for xm_scroll_callback when cs->reason is not XmCR_DRAG.

Yes (see above).

 >>> For jump scroll, PORTION is the position of the scroll bar thumb that we jump to.
 >>
 >> I didn't look into jump scroll so far.  But what you say here indicates
 >> that jump scroll also passes a position via the PORTION argument.

So apparently I was _only_ looking into jump scroll so far.

 >>> The values of PORTION in x_send_scroll_bar_event and
 >>> x_set_toolkit_scroll_bar_thumb are different.  The first has values as
 >>> defined by the scroll bar.  For Gtk+, Motif and Xaw this is a value
 >>> between 0 or 1 and 10000000.
 >>
 >> Yes (in my experience Gtk+ can handle WHOLE directly as is).
 >
 > This looks ugly when WHOLE changes.  The Gtk+ scroll bar does not redraw nicely.

In what sense?  Does it flicker?

martin

Re: Not a regression, but shuld go into emacs-24

[Jan D.]

martin rudalics skrev 2014-06-03 09:23:
>  >> IIUC in XmCR_DRAG we set PORTION to 'cs->value',
>  >
>  > XmCR_DRAG is jump in Motif speak.
>
> So is "dragging the slider" equivalent to 'jump' in Emacs speak?  Then I
> misunderstood the nomenclature completely.  I always thought a 'jump' is
> what happens when I click some position above or below the slider.
>

It is equivalent in Motif and Gtk+ speak, i.e. the callback can't 
distinguish between the two.  Dragging and jumping are handeled the same.

>  >> and in xaw_scroll_callback we explicitly
>  >> pass 'position' as PORTION argument.
>  >
>  > Because that callback does not distinguish between the different
> scroll modes.
>
> What is a "scroll mode"?  Something like "page increment" or "jump
> scroll"?

Yes, page increment/decrement, and step increment/decrement are modes.
As is drag and jump.

>
>  >>> The values of PORTION in x_send_scroll_bar_event and
>  >>> x_set_toolkit_scroll_bar_thumb are different.  The first has values as
>  >>> defined by the scroll bar.  For Gtk+, Motif and Xaw this is a value
>  >>> between 0 or 1 and 10000000.
>  >>
>  >> Yes (in my experience Gtk+ can handle WHOLE directly as is).
>  >
>  > This looks ugly when WHOLE changes.  The Gtk+ scroll bar does not
> redraw nicely.
>
> In what sense?  Does it flicker?
>

I haven't tried lately, but Gtk+ 2 flickered a lot when its maximum 
value changed.  For example typing at the bottom of a buffer would 
change the value for every key press.

	Jan D.

Re: Not a regression, but shuld go into emacs-24

[martin rudalics]

 > It is equivalent in Motif and Gtk+ speak, i.e. the callback can't
 > distinguish between the two.  Dragging and jumping are handeled the
 > same.

That means for Motif the cs->value represents either a click on the
scroll bar or that the slider has changed position?  And for Gtk+ it's
VALUE passed to xg_default_icon_file that represents both (and not the
return value of gtk_adjustment_get_value as was presumed before your
recent change)?

martin

Re: Not a regression, but shuld go into emacs-24

[Jan D.]

martin rudalics skrev 2014-06-03 11:41:
>  > It is equivalent in Motif and Gtk+ speak, i.e. the callback can't
>  > distinguish between the two.  Dragging and jumping are handeled the
>  > same.
>
> That means for Motif the cs->value represents either a click on the
> scroll bar or that the slider has changed position?  And for Gtk+ it's
> VALUE passed to xg_default_icon_file

What? -------------^^^^^^^^^^^^^^^^^^^

> that represents both (and not the
> return value of gtk_adjustment_get_value as was presumed before your
> recent change)?

Yes.

	Jan D.

Re: Not a regression, but shuld go into emacs-24

[martin rudalics]

 >> That means for Motif the cs->value represents either a click on the
 >> scroll bar or that the slider has changed position?  And for Gtk+ it's
 >> VALUE passed to xg_default_icon_file
 >
 > What? -------------^^^^^^^^^^^^^^^^^^^

Grrr...  I meant xg_scroll_callback obviously.

 >> that represents both (and not the
 >> return value of gtk_adjustment_get_value as was presumed before your
 >> recent change)?
 >
 > Yes.

Thanks for the clarifications, martin

Re: Not a regression, but shuld go into emacs-24

[Stefan Monnier]

> I would therefore like to commit this to the emacs-24 brach, even if the
> error is also present in emacs-23:

Sounds OK,


        Stefan

Re: Not a regression, but shuld go into emacs-24

[Jan Djärv]

2014-06-01 16:15, Stefan Monnier skrev:
>> I would therefore like to commit this to the emacs-24 brach, even if the
>> error is also present in emacs-23:
>
> Sounds OK,
>

Thanks, checked in.

	Jan D.