Hi!
Zelgadis, Rylleman is right. Let me explain a bit how does it work:
The top window receives the keyboard event (kb event) and I have written the
code to decide who should handle the event before the default handler does the
job for the main window. Usually, without my code, once that the main window
dispatch the event, it is passed to the focused widget to allow it to handle
it. That's how gtkmm people explained me that is happening.
So with my changes I warp the kb event beofre it is handled by the main window.
In the code I look up for the focused child widget and at the moment, it always
asks to the widget to try to handle the keyboard event and if it is handled,
then it returns. If it is not handled then the code asks the main window to
handle it and returns the handling result (true if handled and false if not
handled)
The information that we have in the event wrapper is just the keyboard event
values (with the modifiers). The thing is that the decision about if the child
widget must handle the event before (or only) the top window must be taken
based on two possible information:
1) What's the action that correspond to the kb event received.
2) If the focused child widget must handle the event before (or only) the top
window.
For example, there are cases that the focused child widget must try to handle
the event first. If you're editing a entry widget type, it must try to handle
all the events received and the top window shouldn't receive the kb event if it
is handled by the widget. Imagine that you have "escape" mapped to stop the
render. If you're editing a entry widget and press "escape" it should always
stop the edition of the widget and not stop the render. In contrary if the main
window handles the event you cannot get out of edition mode from the edit
widget when press "escape".
In other cases the widget shouldn't handle the keyboard event. For example,
currently the event CTRL-A triggers the "select all ducks" action. But if the
focused widget is the Layer Tree it selects all the layers (kb event handled by
the tree widget). So in this case we need to look up the action that
corresponds to this kb event, and if it is a priority action (and the widget
doesn't prioritize) then the event must be handled by the top window first.
The problems are:
1) Determine the action based on the keyboard event. I've not found a direct
way to do that using the gtkmm api
2) Dynamic cast the focused widget to determine its type and stablish a
priority list of which widget must try to handle the event first. I need to
learn to cast between widgets types.
I'm sure that we will find a good satisfactory solution for this.
Cheers!
________________________________
De: David Rylander <[email protected]>
Para: [email protected]
Enviado: Viernes 16 de marzo de 2012 9:09
Asunto: Re: [Synfig-devl] New release is near
I agree that it should be fixed but I do not agree with you that it
should be done one by one by request.
The reason it got messed up in the first place is a request (by me) to
be able to use single key shortcuts which before was messing with field
inputs.
To have a much more flexibility on setting custom keys.
If we set which keys should be handled one by one we go in the other
direction, heavily narrowing down the users flexibility.
If not easily solved any other way I think it's much better to go back
to the old behaviour for now.
The limitation the single keystroke and input fields caused was much
less limiting to the user than a hard set shortcuts behaviour would be.
-David
2012-03-16 08:54, Zelgadis skrev:
> 16 марта 2012 г. 3:02 пользователь Carlos Lopez Gonzalez
> <[email protected]> написал:
>> Hi!
>> I'm merging the latest modifications in the master branch of the git repo.
>> If you have one patch that you think it should go with the next release or
>> do you think that there are remaining bugs that are a must fix, please let
>> us know here.
>> Cheers!
>> Carlos
> Hi!
> I would like to have shortcut keys fixed -
> http://synfig.org/forums/viewtopic.php?f=15&t=3407
> My proposal is not to create list of all events - this will take too
> much time. My proposal is to fix events one by one - per request. For
> example I would request to fix CTRL+A - is should be handled
> globally I think and passed to the canvas (instead of layers dock).
> If this is not the target for new release - I'm not insist. ^___^
> K.
>
>
>
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Synfig-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/synfig-devl
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Synfig-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/synfig-devl
