This question is regarding QML, QtQuick 1.1, Qt 4.8.6
I have seen source code of an embedded application, in which all the screens are loaded at start. For Example,
//Main.qml
Rectangle{ //Base Container
width:640
height:480
MainScreen{ id: main_screen} //Individual screen files are given here
SettingScreen1 { id:screen1}
SettingScreen2 { id:screen2}
HelpScreen1 {id: help_screen1}
...
...
...
}
and in the respective screen document, when a mouse area is clicked the Value of Z of the individual document is changed to make it appear front
//MainScreen.qml
Rectangle{
width: 640
height:480
z:1
//some buttons
//Mousearea for next button
onClicked: {screen1.z = 10}
//Mousearea for back button
onClicked: {screen1.z = 0}
}
My question is,
1. As from main.qml all the children are created at once and only their visibility of stack order is changed. Is this a good method?
2. When so many children are loaded at beginning what happens if I have like 200 screens. What is the effect in CPU load at start and while operation.
Is there any other method for screen transitions?
Other than component loader. I don`t want to use that feature
How this code is converted and showed in display as an object?
I will be very happy is least you can give hints in comments.
Thanks!!
To your questions:
1): Bad Idea. Using the z-index needs the engine to determine that the lower items are hidden completely. You should help the enigne if you are sure about this (which would be the case here) by setting the visibility to false. Then however, you would not need to use the z-index at all. Don't use the z-index. Don't!
However this won't solve that you might have 200 possibly complex views in your memory.
The Loader you mentioned is already a better start.
You can use it in combination with the visibility to preload pages that are likely to be shown soon, and unload them once you are sure they are not shown anytime soon (within the next one or two clicks)
2): The effect is: Long time of unresponsivenes until everything is loaded. The documentation sais: Show a splash-screen if you want to do something like this. In order to show the splash-screen, show it, then use a Loader to load all the other stuff... But in general: Don't do it, if not absolutly necessary. Load dynamically. Never use the z-index to hide screens completely. Load only what needs to be loaded... I feel repetitive...
Related
I have a toolbar defined as "toolBar" property of a ApplicationWindow.
When I resize the window I want that toolBar (if it's too large for the current size) handle overflow with a "more" item. After a lot of research I couldn't found anything on the web. I join some screenshot of what I have and what I want.
The second example is something I have done in pure C++.
In my research I also read something about toolbar only handle overflow in MainWindow and that maybe why I can't make it work in ApplicationWindow.
Thanks for your help.
It could be done if you go for a model driven toolbar items.
Then, if the toolbar view is not wide enough to fit everything, you can calculate the index it cuts out at, and implement a drop down menu with another view, this time vertical, that shows only items after the cutout index.
It is not ideal, but since there is no built in support for that, this is by far the easiest and quickest way to get the desired result.
I have items that can be dropped only to a small DropArea (called AcceptDropZone). This works fine.
Now I want the following behavior : if items are dropped elsewhere, they go back to their starting position when the user releases the mouse. To do this, I have added another DropArea (called RejectDropZone) in the background, that fills the entire window of the application.
The problem is that RejectDropZone consumes the onDropped event even when the items are dropped over AcceptDropZone. As RejectDropZone is in the background of the QML stack, I was expecting AcceptDropZone to get the event first, as for MouseArea components.
Is this a bug or a valid behaviour of overlapping DropAreas? How can I get the result I am looking for?
Thanks for your help;
Regards
For those who may be interested, here is the solution to my problem:
https://forum.qt.io/topic/71036/droparea-overlapping/6
Regards
I am working on a chat application for BlackBerry that leverages ListView to display chat messages. I have different kinds of messages and therefore I use multiple ListItemComponents, but what's more important, I use property: stickToEdgePolicy: ListViewStickToEdgePolicy.End to ensure that the scroll is positioned at the end when new chat messages arrive.
Everything is working fine, but sometimes the content of ListView starts shaking by few pixels up and down and that lasts infinitely. This is usually happening when a user is scrolling the view by swipe gestures and reaches the bottom. Also, this may happen if a new message has arrived. However, this never happens consistently! Also, worth to mention this happens with equal probability on square screen and rectangle screen devices.
While researching this, I found that the height of the view is affecting this jittering effect by making it less or more likely to happen, but none of the height values made it completely gone.
My question is addresed to the experienced BB10 developers, who practically saw this issue and know how to this fix.
The layout is pretty straightforward:
Container {
ChatTitle {
// this is just another Container with chat title Label
}
ListView {
id: chatEntries
stickToEdgePolicy: ListViewStickToEdgePolicy.End
topMargin: ui.sdu(1)
bottomMargin: ui.sdu(1)
...
listItemComponents: [
...
]
}
...
// few controls below the ListView, e.g. TextArea, Buttons.
}
Appreciate any help, thanks!
I have a scrollable and flickable ListView with 5+ elements and I'd like to have the elements which are shown at both ends zoomed out, transparent and slightly moved so the whole list becomes rounded up, sort of getting the shape of a wheel.
I think the two images describe it best:
That's what I have:
And that's what I want:
Since I'm also targeting devices without GL - although deprecated - I'd prefer a QtQuick 1.x version, however I'm happy with all I can get :)
Thanks a lot in advance!
The ListView is not exactly meant to do that.
Have a look at the PathView.
There are a lot of examples from the documentation, maybe you'll find there something very similar to what you want to do.
Otherwise you should put a MouseArea in your delegate and react to the entered and exited signals. Do not forget to update the size of the delegate accordingly to the size of its content if needed, otherwise the items will overlap each other.
That said, I'd maybe use the PathView to do that.
[qt 4.8]
To get correct window dimensions including its frame, I do the following (as described e.g. here, see comment from Daniel Hedberg).
mainWindow.move(-50000, -50000);
mainWindow.show();
// do something with the window dimensions
mainWindow.move(0, 0);
mainWindow.show()
This works fine, however, I have a problem with the move(0,0) call: It makes the window always appear at position (0,0), while I would like to have the default behaviour, this is, the application only suggests to the window manager that (0,0) is a good place to position the window, and the WM might decide to shift it if necessary to avoid overlapping. In other words, I would like to switch back to Qt's default behaviour as if there weren't a call to move at all.
How can I do that?
One solution is to store Windows original position and use that. For extra safety (in case screen resolution changes), check that entire window still fits on screen and move and even resize if it does not.
A hacky alternative would be to create and open empty, possibly transparent dummy window of the same size and see where it gets positioned. Then move the original there and close the dummy one. Reading your question carefully, I think this would do what you are after.
I don't know of a Qt way to ask Window Manager to reposition the window, so if you really need that, specify the OS etc details.
Looking into the source code of Qt, I can now partially answer my own question: To convert a call to move into a suggestion for positioning instead of a request, do this:
mainWindow.move(100, 100);
mainWindow.setAttribute(Qt::WA_Moved, false);
mainWindow.show();
I've tested the code under X11 using Qt 4.8.4, and hopefully it works with on other platforms too.
Unfortunately, this doesn't solve the very problem I have, namely to use show to get the (decorated) dimensions of an off-screen window which then gets moved to the screen, calling show again. It seems that the first call to show directly sets platform-specific window manager flags which aren't completely reset and reevaluated in the second call. Actually, I'm going to think that this is a bug in Qt, so I'll report it accordingly.