Hi Ian, Thanks again but... I honestly don't see how to solve my problem...
What I really need is to catch the value when a key is pressed... not merely to know when the *entry* value has changed: What can I do from that ?...and How to know which value has changed ?. You see what I mean ? Please, take this piece of code http://pastebin.com/LqTrph4i, and you'd verify that the handler "get_key_info" is not called when a key is pressed. And the question is... How to force it ? Thanks, Glus 2016-10-29 20:37 GMT+02:00 Ian Martin <martin...@vodafone.co.nz>: > Hi Glus, > > first of all, your Entry widget already responds to key presses (so long > as you have called set_editable() ). When you push on the key with "a" on > it, it puts an "a" in the widget. So you don't need to add that > functionality; it already exists. > > Second, you can always connect to the signal_changed() when the user > inserts text, and do what you like with their input, including changing > what is displayed, e.g. if they type "w", modify the text so a "J" is > inserted in the textbuffer. I'm really struggling with a use case that > makes sense outside of capitalisation, but then I'm sure there is one, > especially if the input is words. > > Ian. > > On 30/10/16 01:01, Glus Xof wrote: > > Hi Ian, > > Thanks a lot for your explanations, but... I don't see what al all you > propose and how to apply it with Gtk::Entry widgets, while (almost to > me...) they seems not to emit such key press signals, normally... even > adding/setting a key press mask. > > In addition, I don't see how to (safely) change the value that will be set > inside the entry widget. > > Some help ? > > Glus > > > > 2016-10-28 21:20 GMT+02:00 Ian Martin <martin...@vodafone.co.nz>: > >> Hi Glus, >> >> You almost certainly don't want to change what code the key outputs; its >> far more likely you want to change what the program does in response to >> that key. If you reprogram the key, then you confuse your users; they're >> expecting WASD to output those letters, even if the program uses that >> information at times to obtain a direction. If you reprogram the key then >> when they try to input a word, unexpected things happen; at best, the >> keyboard becomes an exercise in cryptography. >> >> By connecting the signal_key_press_event >> <https://developer.gnome.org/gtkmm/3.22/classGtk_1_1Widget.html#a4b64421cad754fbd49ae17cbfe4814d0>, >> you can handle the input however you like; if the program determines it's >> not applicable, the default is that the signal is passed up to the next >> handler. If you wish to block all responses to keyboard input outside your >> own function, simply return true (You'll possibly also have to block the >> key_release_event ). >> >> Ian. >> >> On 28/10/16 22:00, Glus Xof wrote: >> >> Hi Ian, >> >> 2016-10-28 4:31 GMT+02:00 Ian Martin <martin...@vodafone.co.nz>: >> >>> You probably don't want to change the value that key returns; >>> >> That's exactly what I'm trying to do... >> >> ... I need a method, or some way, capable to fix, in the scope of the >> application, another values to a physical keyboard keys. >> ... I'm wonder if Gdk::Device::set_key () should be the suitable tool. If >> so, if I'm not wrong... could you link me the info about the macros >> index... the first parameter ? >> >> it's more likely you're trying to connect to a >>> Gtk::Widget::signal_key_press_event(). That lets you do what you want >>> with the signal when a user presses a key. >>> >>> Check the documentation- you have to enable a mask to use this signal. >>> >> >> In my case is a very bad option... >> >> Thanks >> >> Glus >> >> >>> Ian. >>> >>> On 28/10/16 04:35, Glus Xof wrote: >>> >>> Hi guys, >>> >>> I'm looking for the way, in Gtk+, to reprogram the keyboard keys >>> values... >>> >>> Maybe, should be possible from using: (I don't know) >>> >>> Glib::RefPtr<Gdk::Device> device_keyboard = >>> ...get_display()->get_default_seat()->get_keyboard(); >>> >>> (I don't know if I explained it so clearly...but I hope so though) >>> >>> Glus >>> >>> >>> _______________________________________________ >>> gtkmm-list mailing >>> listgtkmm-list@gnome.orghttps://mail.gnome.org/mailman/listinfo/gtkmm-list >>> >>> _______________________________________________ gtkmm-list mailing list >>> gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list >> >> _______________________________________________ >> gtkmm-list mailing >> listgtkmm-list@gnome.orghttps://mail.gnome.org/mailman/listinfo/gtkmm-list >> >> _______________________________________________ gtkmm-list mailing list >> gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list > >
_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
