Re: [code] [textadept] Curses scrollbars

From: Chris Emerson <c-ta.att.mail.nosreme.org>
Date: Thu, 1 Mar 2018 09:40:25 +0000

Hi Mitchell,

Sorry for the lack of response! I haven't been very active here for a while
as Textadept's been working well for me. The change seems good - I'll find
some time to update to Textadept 10 and try it out, but if you don't hear
anything assume I'm happy. :-)

Thanks,

Chris

On Mon, Feb 26, 2018 at 09:24:39PM -0500, Mitchell wrote:
> Hi,
>
> Another late e-mail, but I didn't see a follow-up to my proposed patch. I've committed it anyway[1]. More information in the thread below.
>
> Cheers,
> Mitchell
>
> [1]: https://foicica.com/hg/textadept/rev/280da84f4e7b
>
> On Wed, 11 Mar 2015, Mitchell wrote:
>
> >Hi Chris,
> >
> >On Wed, 11 Mar 2015, Chris Emerson wrote:
> >
> >>Hi Mitchell,
> >>
> >>On Fri, Dec 05, 2014 at 11:53:49AM -0500, Mitchell wrote:
> >>>On Thu, 4 Dec 2014, Chris Emerson wrote:
> >>>>One little annoyance: you can't drag the scroll bar in a non-focused
> >>>>view;
> >>>>the first click instead focuses that view, and then dragging works.
> >>>>
> >>>>I note that selecting text in an unfocused view also behaves slightly
> >>>>differently to the GUI version - as above the first time acts as the
> >>>>focus-moving click, and then you can select. (In the GUI it selects and
> >>>>focuses at the same time).
> >>>
> >>>When the mouse is pressed, the mouse event is sent to the currently
> >>>focused view. If the view determines the mouse event happened
> >>>outside of it (which is the case for what you've been reporting),
> >>>then the view discards the event, and Lua gets a chance to handle it
> >>>(which it does, by focusing the view clicked on). Subsequent mouse
> >>>events are then sent to the newly focused view, and scrolls and
> >>>selections will occur normally.
> >>>
> >>>In order to match GUI behavior completely, Textadept's C core must
> >>>determine where the click occurred and focus the proper view (if
> >>>necessary) before sending the mouse click to the view. This
> >>>duplicates the Lua mouse handling code already in place, so I'm not
> >>>sure how I feel about it. (The Lua mouse handling is based on your
> >>>code and is required for split view dragging at least.)
> >>>
> >>>Do you have any thoughts on this?
> >>
> >>I have some not very timely thoughts:
> >>
> >>How about:
> >>* Adding a Lua API to pass a mouse event into a view
> >>* Pass all mouse events to Lua rather than trying the current view first
> >>
> >>I think that would mean that a Lua handler could emulate the "right"
> >>behaviour with a combination of goto_view and forwarding the events.
> >>
> >>Even if the handler you ship doesn't go to the trouble of checking
> >>view.buffer.[hv]_scroll_bar and (click on appropriate edge), it means
> >>users can have their own handler which does exactly what they want.
> >
> >Thanks for your feedback. It helped me come up with an idea that seems to
> >work. It involves utilizing a return value from an `events.MOUSE` handler --
> >if non-`true`, try again on the current view (which may have been switched to
> >by a handler!)
> >
> >Patch attached. If you agree with it, then I'll commit it.
> >
> >Cheers,
> >Mitchell
>
> Mitchell
> --
> You are subscribed to code.att.foicica.com.
> To change subscription settings, send an e-mail to code+help.att.foicica.com.
> To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
>

-- 
You are subscribed to code.att.foicica.com.
To change subscription settings, send an e-mail to code+help.att.foicica.com.
To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
Received on Thu 01 Mar 2018 - 04:40:25 EST

This archive was generated by hypermail 2.2.0 : Thu 01 Mar 2018 - 06:32:23 EST