Capturing modifier keys in a TextBuffer

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Capturing modifier keys in a TextBuffer

Gtkmm mailing list
I can capture key strokes when entering text in a TextBuffer by deriving
from TextBuffer and overloading on_changed(), but I would also like to
know whether a modifier (ctrl, shift, alt) is used with certain keys. Is
this possible?


_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Capturing modifier keys in a TextBuffer

Gtkmm mailing list
Not sure, but I think that is the wrong question, since I would imagine the textbuffer should only care about what text is in it, not how the text got there. What widget are you using with the text buffer? Probably you should check the keyboard state there instead.

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Capturing modifier keys in a TextBuffer

Gtkmm mailing list
TextView. I've tried connecting to
textview.signal_key_press_event().connect() but never see any activity.
Would you expect a different result by deriving from TextView and
overloading on_key_press_event?


On 06/22/2018 06:26, Daniel Boles via gtkmm-list wrote:

> Not sure, but I think that is the wrong question, since I would
> imagine the textbuffer should only care about what text is in it, not
> how the text got there. What widget are you using with the text
> buffer? Probably you should check the keyboard state there instead.
>
>
> _______________________________________________
> gtkmm-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtkmm-list

--
Those who dance are considered insane by those who cannot hear the music.
    — George Carlin
_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Capturing modifier keys in a TextBuffer

Gtkmm mailing list
hmm, you might need to connect before the default handler if you didn't already, to intercept the state, then return false so it can carry on doing what it normally does.


_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Capturing modifier keys in a TextBuffer

Gtkmm mailing list
On 22 June 2018 at 14:43, Daniel Boles <[hidden email]> wrote:
hmm, you might need to connect before the default handler if you didn't already, to intercept the state, then return false so it can carry on doing what it normally does.

I should clarify that I didn't really think about whether that's the right way to do it... but if you can make it work, it seems simplest.

Deriving and overriding the default handler vfunc could achieve the same thing since obviously you replace the base one and then can choose to chain up after your added stuff, or even replace it altogether. It may or may not be worth the hassle though.


_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Capturing modifier keys in a TextBuffer

Gtkmm mailing list
         m_pView->signal_key_press_event ().connect ( sigc::mem_fun (
*this, &Test::OnKeyPressEvent ), sigc::first );

I've never done this before, and my best guess offends the compiler.
What's the correct way?


On 06/22/2018 06:49, Daniel Boles via gtkmm-list wrote:

> On 22 June 2018 at 14:43, Daniel Boles <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     hmm, you might need to connect before the default handler if you
>     didn't already, to intercept the state, then return false so it
>     can carry on doing what it normally does.
>
>
> I should clarify that I didn't really think about whether that's the
> right way to do it... but if you can make it work, it seems simplest.
>
> Deriving and overriding the default handler vfunc could achieve the
> same thing since obviously you replace the base one and then can
> choose to chain up after your added stuff, or even replace it
> altogether. It may or may not be worth the hassle though.
>
>
>
> _______________________________________________
> gtkmm-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtkmm-list

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Capturing modifier keys in a TextBuffer

Gtkmm mailing list
The glibmm SignalProxy takes a 2nd argument indicating whether to connect after, which defaults to true



_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Capturing modifier keys in a TextBuffer

Gtkmm mailing list
In reply to this post by Gtkmm mailing list
Bingo! Simple and effective. Thanks!


On 06/22/2018 06:49, Daniel Boles via gtkmm-list wrote:

> On 22 June 2018 at 14:43, Daniel Boles <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     hmm, you might need to connect before the default handler if you
>     didn't already, to intercept the state, then return false so it
>     can carry on doing what it normally does.
>
>
> I should clarify that I didn't really think about whether that's the
> right way to do it... but if you can make it work, it seems simplest.
>
> Deriving and overriding the default handler vfunc could achieve the
> same thing since obviously you replace the base one and then can
> choose to chain up after your added stuff, or even replace it
> altogether. It may or may not be worth the hassle though.
>
>
>
> _______________________________________________
> gtkmm-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtkmm-list

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list