UILoader vs UIC
-
What losses, if any, at use UILoader for all application, that is, without wearing UIC ?
-
I'm not sure I understand. You're asking what's the difference between loading .ui files at compile-time and run-time?
Well, if so, then that's exactly it ;)If you use uic you're generating code and compiling it, so it takes longer to compile but is ready when you run the app. You also don't need additional files or resources.
When you load .ui on run-time you pay time penalty for IO access (reading the file and interpreting it) and more complicated deployment, but gain flexibility in modifying ui without recompiling the app.
A simple trade-off that depends on your needs.
-
The performance in interpreted mode is acceptable?
There are other problems besides the performande?Excuse my horrible english.
-
Again - it depends what acceptable means to your case. There is no universal answer. It's ok for some cases, unacceptable for others.
Some examples might help.
Imagine an app that runs on an IO weak system - like loads all files from slow hard drive, through some port or across the network. If it's gonna lag for, say, 10 seconds to get to the files every time you open up a bigger dialog than it's bad. If it runs from a fast ssd and only loads small files then it might be perfectly ok.
Another example is if you want to let your users modify the .ui files. Like you're designing a plugin system or something. In that case the editable nature might very well outweight a small lag when it loads.Another issue is file size. The executable image is loaded into the memory. If you have an app that has hundreds of widgets and is suppose to run on a memory constrained mobile device then large executable might be bad.
So to reiterate. there is no definite answer that one is good and other is bad. There are simply considerations.
The factors are:
- executable size
- compilation time
- loading(IO) speed
- parsing(CPU) speed
- ease of use - loader requires some coding, uic is pretty much automatic
- easy editing - no recompilation needed in case of external files (but re-linking still required if .ui is placed as a .qrc resource)
- ease of deployment - many external files means more difficult packaging and distribution (installer etc.), especially on mobile platforms
Now you just need to prioritize these for your case, maybe do some tests or benchmarks and pick the right one for you.
-
Ok
Thank for your reply.
For applications type ERP, i believe in acceptable performace.
-
Good question, not yet started to use resources in my project. Let's see what the more experienced staff says.
-
Good question, not yet started to use resources in my project. Let's see what the more experienced staff says.
-
bq. if you use uic.loadUi in your file do you still need to compile the resources?
or will auto compile the UI file and the resources?Which resources do you mean?
UILoader is not a compiler. It parses a .ui file (which is an ordinary XML text file) and creates instances of widgets specified there. The actual types need to be either already defined in the executable or by loading a plugin.Resources have little to do with it. If the loaded widgets use some resources they need to be available (loaded) in the executable, just like with any other widgets.
If you're asking about the .ui file itself used as a resource than as I said it's just an ordinary text file so you can place it in a resource like anything else.
-
bq. if you use uic.loadUi in your file do you still need to compile the resources?
or will auto compile the UI file and the resources?Which resources do you mean?
UILoader is not a compiler. It parses a .ui file (which is an ordinary XML text file) and creates instances of widgets specified there. The actual types need to be either already defined in the executable or by loading a plugin.Resources have little to do with it. If the loaded widgets use some resources they need to be available (loaded) in the executable, just like with any other widgets.
If you're asking about the .ui file itself used as a resource than as I said it's just an ordinary text file so you can place it in a resource like anything else.
-
let say i did an ui file, qdialog with a button, that button have and icon image. so for that i did a resource file, and added and image.
if i press control+r to see a preview, i get the window with a button with the icon right?
if i use ui.load will i get the icon image? or i do have to compile the resources using pyrcc4?
-
let say i did an ui file, qdialog with a button, that button have and icon image. so for that i did a resource file, and added and image.
if i press control+r to see a preview, i get the window with a button with the icon right?
if i use ui.load will i get the icon image? or i do have to compile the resources using pyrcc4?
-
That's what I thought, image resources, .rc files
-
That's what I thought, image resources, .rc files
-
When using an image in an editor you can either give it a file system path or select a resource.
The file system path will work with QUiLoader as long as the referenced file is available at the deployment site in the specified directory.
If you use an absolute path there's no way to guarantee target machine will have it readable or at all. Relative paths are a tiny bit better because the "relative" part depends on the working directory of your app and to have it reliable you would need to figure out location of your file and use something like "setWorkingDirectory":http://doc.qt.io/qt-5/quiloader.html#setWorkingDirectory which is not that pretty.Resources on the other hand get either compiled into the exe or loaded from binary resource blob. After selecting a resource in the editor it looks up the given .qrc (a text) file and stores a resource path of that item e.g. ":/images/foo.jpg" in the .ui file. This is not the path the image has on a disk, but the resource path that a compiled resource would result in.
Having said that this method will work as long as a runtime resource with that path is available, which means either a .qrc file containing such item was compiled into the executable or a binary resource was registered using "QResource":http://doc.qt.io/qt-5/qresource.html#registerResourceThe .ui file holds a path only. Nothing more. Assuring the path is valid at runtime is a separate activity and it's not the job of QUiLoader.
-
When using an image in an editor you can either give it a file system path or select a resource.
The file system path will work with QUiLoader as long as the referenced file is available at the deployment site in the specified directory.
If you use an absolute path there's no way to guarantee target machine will have it readable or at all. Relative paths are a tiny bit better because the "relative" part depends on the working directory of your app and to have it reliable you would need to figure out location of your file and use something like "setWorkingDirectory":http://doc.qt.io/qt-5/quiloader.html#setWorkingDirectory which is not that pretty.Resources on the other hand get either compiled into the exe or loaded from binary resource blob. After selecting a resource in the editor it looks up the given .qrc (a text) file and stores a resource path of that item e.g. ":/images/foo.jpg" in the .ui file. This is not the path the image has on a disk, but the resource path that a compiled resource would result in.
Having said that this method will work as long as a runtime resource with that path is available, which means either a .qrc file containing such item was compiled into the executable or a binary resource was registered using "QResource":http://doc.qt.io/qt-5/qresource.html#registerResourceThe .ui file holds a path only. Nothing more. Assuring the path is valid at runtime is a separate activity and it's not the job of QUiLoader.
