I use two different QGraphicView's and do drag'n'drop between them. The dragdrop does work very well so far. In one of my QGraphicView's I have items that receive hover events so that they are lighted when the mouse moves on them. The problem is that during drops and also during moves on items, the hover events won't get called. Is it possible to overcome this behaviour somehow? The hover events mark the places the drop can occur in my view and the items then have to be dropped at the right places accordingly (they can only be inserted at specific places and the user should get some feedback).
I hope I could describe my problem...I posted no code for now, because I do not know if this is even possible.
Thanks!
I'm not too familiar with the graphics view framework yet, but you'll probably need to subclass QGraphicsView (if you haven't already) and override QWidget::DragEnterEvent. Depending on how you coded your objects, they might also have a DragEnterEvent that you can use.
In either case you'd accept the QDragEnterEvent and have it trigger the hover event. Hope that points you in the right direction.
Related
I'm looking for the most concise way to deal with focus in an application which renders a map in a canvas component. You can pan the map location using arrow keys or ASWD keys. So far, I've been giving the canvas focus at startup and handling key pressed events via canvas.setOnKeyPressed().
This works fine, but I've always known that a problem was on the horizon when other components enter the picture. Once you interact with another component, it gains focus, and you're unable to scroll around the canvas map. I can prevent this from happening with some components like Hyperlinks or Buttons (I don't need tab-navigation) with something like this for those components:
sidePanel.getChildren().forEach(node -> node.setFocusTraversable(false));
But, when we get to things like TextArea or TextField, those do need to hold focus while they're being edited. And I'll need some way to return focus back (or at least unfocus those components) without being an annoyance to the user. (I don't want to have to click the canvas for it to regain focus.)
The options I see for returning focus back to the canvas after the user is done with those fields seem to be:
Add a key handler (ex. ESC or ENTER keypress) on EACH of these components which returns focus back to the canvas.
Maybe not so concise, and a bit of a pain... also feels a bit fragile; if I miss something and the canvas loses focus, it would fail - I need a 100% reliable solution.
Extend each of these components and add similar code to return focus back to Canvas
Even nastier and requires using custom components in Scene Builder, which
is not ideal.
Add a global event handler on the Scene and transmit events to the controller which owns the canvas
I believe an event filter would accomplish this - but on the other hand if the user is simply using arrow keys to move around a TextArea, I wouldn't want the Canvas map to move!
To solve the above problem, possibly the global event handler could ignore ASWD and arrow keypresses if the focus is on certain types of components? Is this worth trying, or am I neglecting a problem this would create?
Are there any other simple options out there that I've missed - and what would you suggest as the best option here? I'd like an automatic solution that doesn't require remembering to add some workaround code every time a UI component is added.
I am using "javafx.scene.control.ComboBox" on Java 8 and I noticed that whenever the combobox does not have room below and instead pops up, the bordering styling of the elements switches as if it still pops down.
How can I access the styling for that to fix it?
Managed to fix this by actually extending the ComboBoxListViewSkin. In there, I've stuck a method that updates the styling, and does that by calling super.getPopup(), gets the AnchorY of that and compares it with the combo-box Y. After determining if the popup is below or above the combo, I set the correct styling on super.getListView...
Also, that method I've added, has to be called from the "ON_SHOWN" event of the combo-box.
I've tried several other variants but the damn thing just yields unstable behavior.
I am trying to implement a scenario where two Qt windows will be placed side by side and they will be kind of sticky to each other. By dragging one of them, the other also gets dragged. Even when doing an alt-tab they should behave like a single window.
Any help or pointer will be extremely helpful.
-Soumya
What you describe sounds like it's a good fit for a "docking" scenario. You're probably most familiar with docking from toolbars; where you can either float a toolbar on its own or stick it to any edge of an app's window. But Qt has a more generalized mechanism:
http://doc.qt.io/qt-5/qtwidgets-mainwindows-dockwidgets-example.html
http://doc.qt.io/qt-5/qdockwidget.html
It won't be a case where multiple top level windows are moved around in sync with their own title bars and such. The top-level windows will be merged into a single containing window when they need to get "sticky". But IMO this is more elegant for almost any situation, and provides the properties you seem to be seeking.
Install a event filter on the tracked window with QObject::installEventFilter() and filter on QEvent::Move
You can then change the position of tracking window whenever your filter is called with that event type.
I found a way to keep two windows anchored: when the user moves a window, the other follows, keeping its relative position to the moved one.
It is a bit of a hack, because it assumes that the event QEvent::NonClientAreaMouseButtonPress is sent when the user left clicks on the title bar, holding it pressed while he moves the window, and releasing it at the end, so that QEvent::NonClientAreaMouseButtonRelease is sent.
The idea is to use the QWidget::moveEvent event handler of each window to update the geometry of the other, using QWidget::setGeometry.
But the documentation states that:
Calling setGeometry() inside resizeEvent() or moveEvent() can lead to infinite recursion.
So I needed to prevent the moveEvent handler of the windows which was not moved directly by the user, to update the geometry of the other.
I achieved this with result via QObject::installEventFilter, intercepting the summentioned events.
When the user clicks on the title bar of WindowOne to start a move operation, WindowOne::eventFilter catches its QEvent::NonClientAreaMouseButtonPress and sets the public attribute WindowTwo::skipevent_two to true.
While the user is moving WindowOne, WindowTwo::moveEvent is called upon the setGeometry operation, performed on WindowTwo from WindowOne::moveEvent.
WindowTwo::moveEvent checks WindowTwo::skipevent_two, and if it is true, returns without performing a setGeometry operation on WindowOne which would cause infinite recursion.
As soon as the user releases the left mouse button, ending the window move operation, WindowOne::eventFilter catches QEvent::NonClientAreaMouseButtonRelease and sets back the public attribute WindowTwo::skipevent_two to false.
The same actions are performed if the user clicks the titlebar of WindowTwo, this time causing WindowOne::skipevent_one attribute to be set to true and preventing WindowOne::moveEvent to perform any setGeometry operation on WindowTwo.
I believe this solution is far from being clean and usable. Some problems:
I am not sure when and why QEvent::NonClientAreaMouseButtonRelease and QEvent::NonClientAreaMouseButtonRelease are dispatched, apart from the case considered above.
When/if one window is resized without user interaction or without the proper mouse clicks from the user, probably everything will go the infinite recursion way.
There is no guarantee that those mouse events will be dispatched the same way in the future.
Free space for more...
Proof of concept:
https://github.com/Shub77/DockedWindows
I have a List component from which I'd like to be able to remove items using drag & drop, but without having a specific target. If you use the mac, the behaviour I'm looking for is something like what the Dock uses; when you drag something out of the bounds of the control it should get an icon that indicates that it'll be deleted (OSX uses a cloud or something?) and then if you release it it will be removed from the list.
How can I do this?
(If I need to provide a more clear description, please comment; I'll fill in what I can)
In my experience with drag/drop in Flex, you cannot simply drag something out and handle that. There is no dragOut event (unfortunately), so that would leave you up to the task of writing dragOver and dragDrop listeners on all the containers surrounding your dragInitiator and handling the process accordingly.
It's more time consuming and can become complicated if any of these controls already have specific dragOver and dragDrop event handlers.
Hope this helps.
Having no Flex experience all I can offer is some psuedo code which resembles how I implemented a similar effect in JavaScript, but hopefully it will get you started.
Essentially what you'll want to do is during your drag event measure the current coordinates of the object you're dragging to see if they intersect the original container and when they fall outside of its bounds call the logic to update the icon in order to indicate it will be removed. Then, on the drop event, check the coordinates once more and delete the item if needed.
OK I've got a little more research on this done so I'm going to totally rephrase the question:
I have two trees, I want to be able to drag items from one tree to the other. In the receiving tree I have some logic that allows or denys the drop. I am using the native cursor feedback Like this :
DragManager.showFeedback(DragManager.COPY);
DragManager.showFeedback(DragManager.NONE);
When the logic determines NONE it properly rejects the item except the drop position indicator sticks like in the screenshot.
I know now that neither dragComplete, nor dragDrop are being fired in this situation, so I have no function to put code into that would clean that up. So how can I listen for this drag rejection?
ScreenShot shows app After drop
alt text http://img687.imageshack.us/img687/2245/treeindicatorstuck.png
Thanks
~Mike
PS with my other question: how-do-i-detect-that-drag-and-drop-operation-ended We have a way of getting an event to fire so we can clean up the tree control. I'm attaching an event listener to the stage so that as the mouse is moved (maybe I'll put it on a timer)it will constantly check if dragmanager.isdragging if it's not it will fire the tree.hideDropFeedBack. This still begs the question, what event is changing the isDragging Boolean and how do I listen for it?
You need to call tree.hideDropFeedback(); or event.target.hideDropFeedback(); to remove the drop indicators.