I have multiple loaded components stacked one top of another.
if One loaded component is overlapping on other component , is there any way we can detect the number of items in the component is overlapped by other component.
visible property is not working in this scenario.
Iterate (recursively) QQuickItem::childItems() in C++ would be one way, as suggested. For event delivery we use QQuickItemPrivate::paintOrderChildItems(), which just sorts the same list by z-order; but it's private API. Alteratively there is QQuickItem::childAt(x, y). dumpItemTree() is for debugging. The docs for that also show you how to visit all items recursively in QML: https://doc-snapshots.qt.io/qt6-dev/qml-qtquick-item.html#dumpItemTree-method
Related
I have a set of QML items distributed all over my UI. They display data from a remote device and their content needs to be updated regularly. The Items are spread on several tabs and hidden in nested ListView instances, so most of them won't be visible to the user all the time.
In order to keep the bandwidth low I want to update only those items that are currently visible to the user.
I am looking for the right hook to get the information which of these Items is currently displayed from within the Item, without relying on information from the parents. If they were all placed in ListView delegates I could use the delegate's Components onCompleted and onDestroyed signals. Since this is not the case I am stuck at finding out how to get this information.
Am I missing something here? Is there an onPaintFinished signal or something similar? My workaround would be to add that logic to the parent containers, but that would be tedious, since there are several kinds of container that can contains these display Items.
Instances that are on delegates of a ListView will not exist until they would be in the visible range or the cache range around the visual area of the list view. If the delegate moves outside of that range, it is destroyed. So, no need to worry about instances hidden there.
Furthermore, items are currently not visible are also not drawn. They are not entered into the scene graph, and hence, not rendered. So, instances of your items appearing on tabs that are currently not current will also not be drawn. However, these items do still exist of course.
Figuring out if an item is effectively visible or not is quite a hard problem though. QML delegates part of that to OpenGL (clipping for instance). There is not feedback on the result of that. You could in theory lift that information out of the renderer, but that would require customizing that and that is very hard. You could take a look at the heuristics that GammaRay uses to warn about items not being visible. Perhaps you can take some inspiration from that.
Can anyone clarify this statement from the WatchKit Development Tips page?
Simplify controller scenes.
Reduce the number of hidden objects as much as possible to significantly improve load time. For example, five versions of a controller’s layout in a single controller scene will result in all objects being created before the controller is displayed
I've read it a few dozen times now and can't figure out what it's trying to say.
What is a "scene"? Is it referring to the Storyboard scene?
Are "hidden objects" referring to literally hidden UI elements like a hidden button?
How is it possible to have five versions of a controller's layout? This just does not compute.
When a storyboard is loaded, and there are, say, 10 different WKInterfaceControllers in the file, will that be very slow even if the initial controller is blank? Aren't these only loaded as-needed? Or, would it be better to have a single table with 10 prototype rows - each of which is actually a stand-alone interface - which are only instantiated one at a time?
Because we can't programmatically add interface elements to controllers in the current version of WatchKit, any interface elements that we might need to display must be included in a Storyboard scene. By including these initially-hidden elements, we can programmatically hide or unhide these elements as needed.
For example, it's common to include a full-screen label that is initially hidden. Then, if a full-screen message needs to be shown for some reason, the text is populated, the label is unhidden, and the rest of the elements on the screen are hidden. To make hiding a set of elements easier, they're typically included in a WKInterfaceGroup, so that only the top-level group element needs to be hidden.
So, to answer your questions:
Indeed, a "scene" is a standard Storyboard scene.
Yes, "hidden objects" is referring to literally hidden objects as I've described above.
Using the method I've described, you could create five top-level WKInterfaceGroup elements, each with its own set of controls and layout. Then, you'd likely unhide the one that makes sense to display and hide all the others.
I use these techniques in my own app, though I typically don't have more than three top-level groups.
So yes, because it takes time to initialize and layout all of these elements (even if they're hidden), the recommendation is to keep it to a minimum.
Regarding the loading of interface controllers in a storyboard, you're correct that only the interface controllers that are needed are loaded. However, if you have a set of five page-based controllers, they'll all be loaded and initialized before the first page is activated. Other controllers would then be loaded as appropriate.
Creating unique rows is another possibility, but whether you do that or simply hide/unhide top-level groups depends on your app's specific needs. As always, it's worth testing on actual hardware.
I have created a widget which inherits QListWidget.
My goal is for it to accept files dropped into it from an external file manager, and for the user to be able to reorder the elements in the widget. I can achieve both, but not at the same time.
If I just set
myWidget->setDragDropMode(QListView::InternalMove);
myWidget->setDragEnabled(true);
I can reorder the items within the widget, but I can't drop external items into it.
If I reimplement the dragMoveEvent, dragEnterEvent and dropEvent events, all of them just having acceptProposedAction(); and some debug messages inside them, I can drop external files into my widget, but I can no longer rearrange the items.
Is there a way to have the above two at the same time, or do I have to manage the items myself in the reimplemented functions? If so, how can I know if a dropped item is internal or external, and how can I know from which position it was taken and into which position in the list it was dropped into?
If I parse the mimeData which I got from the event, I can see whether it as a file or a text, and I get "qabstractitemmodeldatalist" if it was an internal item, but it still doesn't give me its position.
I can check event->pos() to know in pixels where the drop has been made, and event->source() to learn about what was dropped there, but is this really best practice, to start calculating pixel values and adding objects "manually"?
The solution was very simple: I just had to call the functions of the parent class at the end of each function I've overridden.
void myWidget::dropEvent(QDropEvent *event)
{
do_stuff_with_received_data(event);
QListWidget::dropEvent(event);
}
Hy!
I'm building a top view 2D map, that it's objects are stored on the server.
The kind of objects are 10 and might be a photo, label, button, lists, mix of them or labels with tooltips.
The component must request the "areas" that are missing on screen.
An area is 1000x1000 px and is cached in flex.
To move in the map, will be like in google maps (drag-and-drop)
I should be able to have another list and move objects from one to another using drag-an-drop on objects. Ex.: I grab an objects from a list and I move it on this map, I release the mouse button and the item is placed there.
Now the problem is: I build a custom component for this trying to emulate the item renderer for performance and recyclage, implement drag-and-drop on objects and request the areas that are missing?
or
I extend the List component from spark and I add some features as multiple kind of itemrenderers and use recycle on them. Of course it must be able to request the missing areas on the screen and cache it's data.
Maybe create a custom layout is needed too.
What I need is something that must be really fluid, so the lighter this component is, the better!
Thanks for your help! (:
UPDATE:
*There will be not any object over another.
*I will not use hitTest on bitmaps because all bitmaps are wrapped in another component,as they,for now are itemrenderers.
Anyway I already begin to do this using a class that extends the SkinnableDataContainer and a custom layout. As the layout is not like a grid, is sparse, random items at diferent points(x, y).
Now I have this problem: https://stackoverflow.com/questions/4192934/how-to-get-the-localx-and-localy-relative-to-item-renderer-and-not-to-the-spark
Maybe you could use a combination of some of the following:
A canvas background (for layered components), looks fluid if using hitTest. Split up the canvas using constraintColumn/constraintRow for a grid layout.
Use hitTest (on items bitmapdata) for collision detection, and move the items to a new position (if items are dropped on top of one another).
Use a combo of mouseDown, mouseMove, mouseUP (example here) for drag n drop.
Use a 2D/3D indexed array to track the position of items (example here)
In my flex project i used one option like Link button . If i like it will be open new page
contain more information and components . Which container is suitable one ?
Where is used viewstack and stages ? if you know please explain it . or refer me
With states you can have objects in each state with the same id - this cannot be done with a viewstack. Usually states are used when a group of objects are shared amongst the different "states" or "views". So for example you can have a textinput in each one of your states and give each one the same id of "username". When you reference the "username" id it will use the object in the currently enabled state. If you try to do this with a viewstack it will throw an error saying you've defined an id of "username" multiple times.
So as a wrap up... use states when you're adding or removing components from a set of components shared throughout each state. Use a viewstack when each view is different and do not share components.
Use states when your views are very similar and only differ based on a few controls or components. If you have too many AddChild / RemoveChild elements it becomes more difficult for a developer to follow your code.
A ViewStack also supports deferred instantiation through the "creationPolicy" attribute. This means that only the first Container in a ViewStack will be initialized when the ViewStack loads. This can really speed up load time of your application if you (A) have a lot of children in the ViewStack or (2) the children are large / complex components.