javafx.scene.input.*Event classes construction

Pavel Safrata pavel.safrata at
Mon Nov 19 08:25:25 PST 2012

Hi Steve,
the code maps the integer to KeyCode and does the same thing as the 
other constructor accepting the KeyCode directly. So the only use right 
now would be creating a KeyEvent based on some native event. However, I 
believe that if we want to support it, we should rather consider 
publishing the KeyCode method that does the mapping. That would be done 
in scope of the RT-20448, right now the raw code is (should be) 
completely hidden to users.

On 19.11.2012 16:52, steve.x.northover at wrote:
> Hi all,
> This sounds right.  Can the integer codes in the constructors be used 
> for anything today?
> Steve
> On 19/11/2012 4:19 AM, Martin Sladecek wrote:
>> Richard, what do you think?
>> The approved changes were pushed to the repository already, so it 
>> would be good to fix the issues Pavel found ASAP.
>> And there's also one more thing that should be changed. In the 
>> original proposal, there are integer codes in the KeyEvent 
>> constructors, but the feature request to add them is still open ( 
>> Since KeyEvents 
>> currently operates with KeyCode enum only, these constructors should 
>> be removed and only the constructor with KeyCode should be left in 
>> the API.
>> Thanks,
>> -Martin
>> On 11/08/2012 12:42 PM, Pavel Safrata wrote:
>>> Hello,
>>> shame on me, I'm really sorry for getting here so late. I've just 
>>> read through the proposal and I'd like to propose several changes 
>>> before it starts to be used by apps.
>>>> DragEvent:
>>>> public DragEvent copyFor(Object source, EventTarget target, Object 
>>>> gestureSource, Object gestureTarget, Dragboard dragboard)
>>>> public DragEvent copyFor(Object source, EventTarget target, Object 
>>>> gestureSource, Object gestureTarget, TransferMode transferMode, 
>>>> EventType<DragEvent> eventType)
>>> I think we should not complicate the API with those two methods. 
>>> They have no obvious usage for users and I think all existing 
>>> internal usages can be removed by a simple refactoring.
>>>> MouseEvent:
>>>> public MouseEvent(EventType<? extends MouseEvent> eventType, double 
>>>> x, double y, double screenX, double screenY, MouseButton button,int 
>>>> clickCount, boolean shiftDown, boolean controlDown, boolean 
>>>> altDown, boolean metaDown,  boolean primaryButtonDown, boolean 
>>>> middleButtonDown, boolean secondaryButtonDown, boolean synthesized, 
>>>> boolean popupTrigger)
>>> I would drop this one, there is a similar one with one more 
>>> argument: stillSincePress. This argument is not that special, we can 
>>> use the other method instead. There are places in robot where we're 
>>> not sure what to put there, but it doesn't really justify for having 
>>> this duplicated method (it should rather be fixed there).
>>>> TouchEvent:
>>>> public boolean isDirect() // was impl_ because (according to a 
>>>> comment in code) there are no indirect events yet, but GestureEvent 
>>>> already has this public.
>>> I think we should not publish isDirect() and that we should remove 
>>> the "direct" argument from constructors. Currently touch events are 
>>> always direct. We are able to produce indirect touch events from 
>>> TrackPad, but our API specifically states that we don't and won't 
>>> deliver them. They are just prepared for the possibility that we add 
>>> custom gesture recognizers in the future that may work with those 
>>> indirect events, but it is not really certain we'll ever do that, 
>>> and if we will, it is not certain if it will be allowed to feed 
>>> custom events to them. So publishing this useless flag would be 
>>> pretty confusing right now.
>>> Finally, to make TouchEvent constructor usable, we need also 
>>> constructor for TouchPoint.
>>> Let me once more apologize for the late response.
>>> Thaks,
>>> Pavel
>>>> -Martin
>>>> On 06/15/2012 11:44 PM, Richard Bair wrote:
>>>>>>>> As for the approach, I think you do the constructors with all 
>>>>>>>> params (since events are immutable you have no choice really -- 
>>>>>>>> static factory or constructor and I prefer in this case a 
>>>>>>>> constructor) + builder (auto generated).
>>>>>>> And what do you think about impl_copy methods? Personally I 
>>>>>>> think we should remove them completely and turn them to some 
>>>>>>> internal utility methods.
>>>>>> My initial thought was a copy constructor.
>>>>>>> Also, some events are not 100% immutable, as they are modified 
>>>>>>> during the Scene processing through some impl_methods, like 
>>>>>>> MouseEvent.impl_setClickParam. We'd either need to make some/all 
>>>>>>> of the Event fields protected and do this modifications through 
>>>>>>> subclasses or create some "accessor" in javafx.scene.input 
>>>>>>> package for calling these methods from javafx.scene package.
>>>>>> Good question, I guess we can revisit these in context of the 
>>>>>> other impl_ method removal things we're working on.
>>>>>> Richard

More information about the openjfx-dev mailing list