I remember that SWT/JFace has a representation for actions that is independent of graphical user interface elements (such as a button or menu item). This way, when the interface changes, the underlying action model remains the same. For example, I may create an action "Find" that is detached from any particular menu or button.
I am not finding a corresponding notion in JavaFX 8. Does it have it?
Here's a page explaining SWT/JFace's Action. Note that it is different from an event, and therefore different from JavaFX's ActionEvent.
There is no equivalent functionality in the core JavaFX libraries, though ControlsFX provides a similar API.
Related
I am attempting to implement the Daydream keyboard into an app built in Unity and am not able to get this to work. I have added the keyboard prefab as a sibling of the main camera and added two input fields with the onpointerclick function added as instructed. I however get a null reference exception and assume this is due to the daydream keyboard delegate field being blank. The example scene in the SDK shows the daydream delegate example prefab but I am unsure how to implement this for two input fields. Also does the keyboard render in the Unity editor or must it be built and run on a phone?
This is an old question and has probably already been answered, but I figured I'd publicize my answer anyway.
For those reading, if you haven't checked out the Keyboard Demo scene that can be found within the Demos folder of the Google VR Unity package, I would highly recommend doing so. Following this object hierarchy has worked for me in the past.
To answer your first question, it seems that they have included a KeyboardDelegateExample object within the scene's hierarchy, and then used this object as the Keyboard Delegate in the GVRKeyboardManager.
They manage to fake an Input Field by creating a background and overlaying a Text object on top. If this method does not suffice and using an Input Field is crucial in your particular case, then drop your Input Fields into two separate GVRKeyboardCanvas objects.
Clicking on either canvas will activate the GVR Keyboard. You may have to add a small script to manage the transitioning of the input field.
Lastly, no the GVR Keyboard does not render in the Unity Editor, it only appears while running a build. Hopefully this will be addressed in later releases. There are also Keyboard plugins that you may find useful on the Asset Store.
I want to use a custom input device for multitouch input in a Qt application. I plan to create QTouchEvents based on my raw input data. I also want to generate custom gestures.
As far as I understand, I have to subclass QGestureRecognizer, create a QGesture for the widget I want to control and implement recognize() to filter my QTouchEvents and trigger the gesture when appropriate.
Now I have two questions:
Is this the correct way to do things?
How do I make sure that QTouchEvents still reach my widget (e.g. for dragging) when I already use them in my QGestureRecognizer? Or should all interaction with my widget be in form of gestures?
My progress on this matter so far, should anyone find themselves in a similar situation:
1.: It may be the right way but it doesn't work. Even after registering my recognizer with the application, it does not receive any QTouchEvents. I therefore installed my recognizer as an eventFilter for the target widget.
2.: At least when using an eventFilter, one can pass the event to the original receiver. See http://doc.qt.io/qt-5/qobject.html#eventFilter.
I would like to know what the established procedure is for initializing the controls within a Qt custom dialog box. In the code I am writing, the dialog would present a QListView containing directories from an object passed (by reference) to the dialog class during construction. When the dialog is displayed, I obviously want the list to display the directories currently configured in the object.
Where should this be done though? Perhaps in the overridden showEvent() method?
Background: I used to do a lot of MFC programming back in the day, and would have done this sort of stuff in the OnCreate method, or some such, once the window object had been created.
Thankfully Qt doesn't require you to do any hooking to find the moment to create things (unless you want to). If you look over the Qt examples for dialogs, most do all the constructing in the constructor:
http://doc.qt.io/archives/qt-4.7/examples-dialogs.html
The tab dialog example--for instance--doesn't do "on-demand" initializing of tabs. Although you could wire something up via the currentChanged signal:
http://doc.qt.io/archives/qt-4.7/qtabwidget.html#currentChanged
Wizard-style dialogs have initializePage and cleanupPage methods:
http://doc.qt.io/archives/qt-4.7/qwizardpage.html#initializePage
http://doc.qt.io/archives/qt-4.7/qwizardpage.html#cleanupPage
But by and large, you can just use the constructor. I guess the main exception would be if find yourself allocating the dialog at a much earlier time from when you actually display it (via exec), and you don't want to bear the performance burden for some part of that until it's actually shown. Such cases should be rare and probably the easiest thing to do is just add your own function that you call (like finalizeCreationBeforeExec).
In the examples for RobotLegs, it appears that mediators are used on every button/textArea, rather than on the custom component that contains these children. This would be very time consuming would it not?
From Joel Hooks InsideRia Example
Dependency injection works better with
unambiguous classes. What this means
is that by extending TextArea into our
new MessageView class, we are creating
a specific view component for the
dependency injection to act upon. This
is important if our application were
to have several TextAreas that served
different purposes. By dividing up our
classes in this way, we are clearly
defining the intent of the class and
allowing for the dependency injection
tools to do their jobs effectively.
No, don't mediate every child component. Your components should be organized into groups that perform related actions. In the examples the components are extremely simple and do not reflect what a real application would look like.
One rule of thumbs I use is thinking if that component needs any communication with the rest of the application, or if its only a part of a whole. Keep in mind that mediator are only intended to serve as a bridge between the view and the app.
For example, if I've a view with a form (asume a login form) I don't mediate all the child components (the textfields, the buttons, etc.) because it would be pointless and would have a proliferation of classes and objects on runtime. When I do the form I think, what does the view by its own? and what the other parts of the app should do with it?
When the user fills the form and clicks a button, the view dispatches an event (LoginRequestEvent, for this case), and then the mediator should redispatch that event, making the mediator very lean.
But with practice of the framework, you'll come up with this feel of what you shold mediate. For instance, in one app I mediate every item renderer of a list, and on other I mediate a view stack with two or three navigation contents.
Hope it helps
I want a widget like the properties window in Visual Studio or NetBeans. It basically has two columns: the name of the property on the left, and the value on the right. The value needs to be able to be restricted to certain types, like 'bool' or 'float' (with valid ranges), but should also support more complex types (perhaps requiring a popup dialog when clicked, and then it can just display a toString() version in the window. I'm sure I can add most of those features myself, but what's the best base widget to start with?
Oh... grouping of properties is good too (like a tree I guess). And property editing should invoke a callback (send a signal).
Qt designer has properties exactly like you want. They are most likely implemented with QTreeView. You can always look at the source code.
QTreeView or QTableView. Do all (ok, most) of the heavy lifting with a specialized model that handles all of your type restrictions and what-not. Check out delegates as well.
Here's a link led to github, it might be useful.
another userful link