[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: Re: Not a regression, but shuld go into emacs-24
Date: Tue, 03 Jun 2014 09:23:00 +0200

>> 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

>>   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

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 

In what sense?  Does it flicker?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]