I have a JavaFX application that implements drag & drop behavior to and from external applications working with one exception.
If I drag a file, say from desktop on Windows, into my application while holding control-key down (copy operation instead of move), I do not know how to detect that it is indeed a copy operation and not move operation.
I can check the control key when dragging out from the application, but this does not seem to work vice versa.
Any ideas?
DragEvent has a getAcceptedTransferMode()-method that does the trick.
Related
Is it possible to write tests for a JavaFX application, which do not fail upon mouse mouvement generated by the human user ?
I am a beginner in JavaFX and TestFX, and it seemed to me that TestFX stops everything as soon as it detects that the mouse has been moved.
In another project, which uses Eclipse RCP and SWTBot, this seemed to work out-of-the-box, as long as the application under test had the focus. Is there any way to get the same behaviour with TestFX, or any other test framework for JavaFX ?
As a workaround, on Linux, it's generally advised and useful to create another X session (using Xephyr for example) and to run tests in this X session by setting the right DISPLAY property.
With that, the event processing is isolated on both DISPLAYs so tests are not "polluted" by parallel human actions on the other DISPLAY and can run with less troubles.
I'm implementing Qt's drag and drop API across Windows and X. When I pick up an object in the app running on X and drag it, it leaves a white ghost trail of itself on the window underneath, as if the window underneath is being slow to repaint where the dragged object was previously obscuring part of itself.
I believe that this is symptomatic of the same problem that Qt has just solved with resizing windows causing flicker in child widgets on X windows - i.e. the dragged object is treated as a separate native window and therefore X handles the clipping from the dragged object to the window underneath. Since X does this in a different way to Qt, we get the ghosting effect.
Has anyone experienced the same problems? One solution that comes to mind is to use the same technique as detailed in the blog article linked above and stop the dragged object being treated as a native window, presumably at the cost of drag and drop being limited to my application only (I have no problem with this). Would anyone know how to force drag and drop operations to be internal only?
EDIT: I'm using QDrag::setPixmap to set the graphical representation of the dragged object - it is important that I retain this in favour of a standard drag cursor as this interface is being used on a touchscreen device and will hence have no visible cursor.
I'm now of the opinion that short of editing and then compiling my own build of Qt (not an option for me), I can't force drag and drop operations to be internal only.
Equally, I can't find any way of getting rid of the ghost trail by tweaking my window manager settings or using a compositing window manager (thanks anyway though #atomice). Using OpenGL as the renderer increases the screen repaint speed slightly, but is not perfect and introduces its own problems (see Starting a Qt drag operation on X11 w/ OpenGL causes screen flicker). I would still be very interested to hear any ideas though.
I have, however, got a workaround for my problem which works on both Windows and X. Here's a simplified version:
void DoDrag()
{
//Prepare the graphical representation of the drag
mDragRepresenter = new QWidget(QApplication::activeWindow());
mDragRepresenter->setAttribute(Qt::WA_TransparentForMouseEvents);
mDragRepresenter->SetPixmap(GenerateDragPixmap());
RepositionDragRepresenter();
mDragRepresenter->show();
QTimer UpdateTimer;
connect(&UpdateTimer, SIGNAL(timeout()), this, SLOT(RepositionDragRepresenter()));
UpdateTimer.start(40);
//Start the drag (modal operation)
Qt::DropAction ResultingAction = Drag->exec(Qt::CopyAction);
UpdateTimer.stop();
delete mDragRepresenter;
}
void RepositionDragRepresenter()
{
mDragRepresenter->move(QApplication::activeWindow()->mapFromGlobal(QCursor::pos()) - mDragRepresenterHotSpot);
}
An X11 window is only created for a drag operation if a QDrag::mimeData()->hasImage() is true. If you modify your code so it doesn't use an image then you will just get a drag cursor instead which won't trigger a repaint of the windows underneath.
You don't specify what kind of object you are dragging or how you are setting up the drag operation. Can you add some code to show that?
I'm using the PopUpManager to bring a bunch of event windows up.
I want to make it so that only one window can be open at a time, but I don't see anywhere in the code that tracks open windows to set up a conditional. I guess it just creates the windows and then sets them free?
Thinking about a windowCount variable that increments when I add a window and decrements when I remove one, but since the PopupManager is called in different classes I'd have to start throwing events all over the place. I can do that, but I'm wondering if there's a more straightforward method?
The systemManager (rather than PopUpManager, go figure...) provides information on the currently opened popup windows.
If your popups are all model then you will be interested in 'systemManager.numModalWindows':
The number of modal windows. Modal
windows don't allow clicking in
another windows which would normally
activate the FocusManager in that
window. The PopUpManager modifies this
count as it creates and destroys modal
windows.
Otherwise try out 'systemManager.popUpChildren':
An list of the topMost (popup) windows
being parented by this ISystemManager.
An ISystemManager has various types of
children, such as the Application,
popups, tooltips, and custom cursors.
You can access the top-most windows
through the popUpChildren property.
The IChildList object has methods like
getChildAt() and properties like
numChildren. For example,
popUpChildren.numChildren gives the
number of topmost windows and you can
access them as
popUpChildren.getChildAt(i).
I see a few options:
1) Make all your windows modal; so that the application can't be used until the window is closed. This is a argument to the createPopUp method on the PopUpManager. Presumably you do not have Popups creating other popups.
2) Create your own Manager class, possibly an extension of the PopUpManager class that keeps track of all open windows. Then you'd have a single source of all PopUps and could maintain them that way.
I use the last Qt version for a projet and QProcess. I want to lauch program from my application by using QProcess. I want to display a QGraphicsView transparent on full screen over the launched program.
For the moment: I hide the view, launch the program, sleep during 5 seconds and show the view. I want that my view keep the focus and stay on the top level? Is there any better way to do that? A custom setting for the QGraphicsView?
Create your QGraphicsView (or the window that contains it) with the Qt::WindowStaysOnTopHint flag
Once you run a program in QProcess, you have limited control over it. Qt does not provide details about other applications that are running, you won't know where the launched application is being displayed unless it tells you explicitly.
If you have access to the code of the application you're running, it is possible put a transparent overlay on top a given widget, or widgets, that could then record mouse clicks and other interactions. It's also possible to override events and record basic information about the application's use.
I have an AIR application with a system tray icon. When clicked it shows and activates the app. This is working as expected when the app is hidden (docked), however if I select another application so my app is in the background clicking on the system tray icon does nothing.
Oddly I also have a contextual menu on the system tray icon, which has an option to restore, this calls the same event handler as ScreenMouseEvent.CLICK, yet works.
I expect it's something to do with the contextual menu changing the focus, perhaps it's a bug in how AIR works with the system tray, perhaps it's just something I'm missing. Would be good to know if that's the case.
Thanks in advance
Rob
//instead of just calling
activate();
//call
nativeApplication.activate()
//or even better
nativeApplication.activate(nativeWindow);
Update based on OP's input: if you have multiple windows open for the application, use:
nativeApplication.activate(nativeApplication.openedWindows[0]);
If you are not in the main WindowedApplication class, you can use the static property NativeApplication.nativeApplication to get a reference to the singleton object.
WindowedApplication.activate()
Activates the underlying NativeWindow (even if this application is not the active one).
NativeApplication.activate(window:NativeWindow = null)
Activates this application. If the operating system allows activation, then the specified window is activated and brought to the desktop foreground; that is, in front of the windows of other applications. (If the window parameter is null, then a visible window of this application is activated.)
livedocs is not clear on why this is happening. It says activate() activates the underlying native window - one would expect it to be brought to the front when it is activated, but that's not happening.