I've been looking for a way how to change QML's Dial component's angle range. From documentation I know it's 140 degrees from "north" to both sides and the angle property is marked as read-only.
I currently have the default 280 degree range. Is there a way to change the range to for example 240 degrees?
I don't want to write the entire dial myself, the default actually works really well. The purpose of the change is purely aesthetical.
Thanks for any suggestions!
This is highly dependable on which QuickControls Style (Default, Universal, Fusion e.t.c.) you are using but in all cases, you will need to inject/modify part of the built-in components and create your hacked version of Dial
It is very good to know how the dial itself is written, simply finding Default styled Dial on GitHub over here This points us to some DialImpl component, using Woboq online qt sources, it can be traced here and because QQuickDefaultDial is private class, we can't do much with it, therefore you will have to reimplement DialImpl yourself and provide your background (and possibly also handle).
Finally your Dial version can be implemented in this manner
// MyDial.qml
import QtQuick 2.15
import QtQuick.Controls 2.15
Dial {
background: Item {
// Your background definition
}
}
Alternatively you can also directly implement your Dial template
Related
I am developing a qml app in qt5 with circular gauge. I want to port application qt 6. But in qt 6 qtquick extras is missing, so circular gauge is not available. Is qt planning to make it available in next releases of qt6? What can I do instead of using circular gauge in qt6?
Is there anyone who knows about it?
As far as I know there are no plans yet to port it to Qt 6. You could create a suggestion on Jira to express your interest in having it.
The code is here and here if you want to try to port it yourself or just use parts of it (keeping in mind the license, which is LGPL).
As you stated in the question, CircularGauge is not available in Qt6. So what can you do?
As a minimal effort, you can substitute CircularGauge with a functional similar component, for instance, RangeSlider. Of course, a RangeSlider looks nothing like a CircularGauge, but, it will, at least, allow you to compile and run your application. It will give you an application to test whilst you decide your options.
Then, as others have stated, you need to spend more effort allocated to porting. If you refer to the source code of CircularGauge, you see that they're using Canvas with a custom onPaint implementation. You could do the same in your port, or, you can find an alternative, e.g. Shape with ShapePath, etc. These efforts are non-trivial, and it boils down to the level of effort you wish to invest.
On Windows, I've found that d3d9 works way smoother when resizing the window, compared with d3d12. However, I can't find a way to set QT_ANGLE_PLATFORM to "d3d9" from inside the program itself, not as environment variable.
There's app.setAttribute(Qt::AA_UseOpenGLES); to force the use of ANGLE, but I've found no way to configure ANGLE further.
Is there such a way? I don't want to set or change any environment variables on end-user machines. Or is this the wrong thing to do?
Thanks!
Both can create objects dynamically.
When should Loader be preferred over Qt.createQmlObject and vice versa in QML?
The Loader can be regarded as a placeholder for a particular object. It also gives you the ability to reference the underlying object through the Loader's id.
Qt.createQmlObject is generally more powerful than a Loader, because you can instantiate as many objects as you want, and also it doesn't have the overhead of the Loader. But you have to take care to keep track of what you create in order to be able to reference it.
The other functions Qt.createComponent() and then createObject() offer similar advantages, plus the possibility to pass properties to be used in the object's creation instead of setting them only after it has been created.
I personally see very little point in Loader and rarely use it, if at all in production code. IMO it was introduced for the sake of the "non-programmer" much like most of the recent development, such as the new designer and QML .ui files, which I find kind of annoying, but it is understandable - trying to increase adoption by non-programmers.
I'm trying to use to SketchUp API to navigate around 3D models (zoom, pan, rotate, etc). My ultimate aim is to integrate it with a Leap Motion app.
However, right now I think my first step would be to figure out how to control the basic navigation gestures via the Sketchup API. After a bit of research, I see that there are the 'Camera' and the 'Animation' interfaces, but I think they would be more suited to 'hardcoded' paths and motions within the script.
Therefore I was wondering - does anyone know how I can write a plugin that is able to accept inputs from another program (my eventual Leap Motion App in this case) and translate it into specific navigation commands using the Sketchup API (like pan, zoom, etc). Can this be done using the 'Camera' and the 'Animation' interfaces (in some sort of step increments), or are there other interfaces I should be looking at.
As usual, and examples would be most helpful.
Thanks!
View, Camera and the Animation class is what you are looking for. Maybe you don't even need the Animation class, you might just be ok with using the time in the UI class. Depends on the details of what you will be doing.
You can set the camera directly like so:
Sketchup.active_model.active_view.camera.set(ORIGIN, Z_AXIS, Y_AXIS)
or you can use View.camera= which also accept a transition time argument if you find that useful.
For bridging input you could always create a Ruby C Extension that takes care of the communication between the applications. There are some quirks in getting C Extensions work for SketchUp Ruby as oppose to regular Ruby though - depending on how you compile it.
I wrote a hello world example a couple of years ago: https://bitbucket.org/thomthom/sketchup-ruby-c-extension
Though note that I have since found a better solution for Windows, using the Development Kit from Ruby Installers: http://rubyinstaller.org/
This answer is related to my comment above regarding the view seemingly 'jumping' when I assign a new camera to the current view using camera=, but not if I use camera.set.
I figured out this was happening because the camera FOV for the original camera was different, and the new camera was defaulting to an FOV of 30. By explicitly creating the camera with the optional perspective and FOV arguments from the initial camera solves this problem:
new_camera = Sketchup::Camera.new new_eye, new_target, curr_camera.up, curr_camera.perspective?, curr_camera.fov
Hope people find this useful!
I feel like I'm missing something since I can't see any way to easily do a cross-platform cursor in Qt. That is, I'd like to use a standard cursor editor, or just a common cursor file type, and stick it in the resource file.
I see a couple platform specific manners providing handles (meaning I couldn't load from a resource) or a generic way taking a pixmap. In the pixmap method I would then have to find someway to store the hotspot along with the pixmap.
I don't want animated cursors, just a plain color image (32x32).
What is the easiest way to handling this?
I'm currently working on an application where I'd like to have some nice custom cursors. The way I'm doing that is:
Add an image to a Qt resource file (*.qrc) - I am working with PNG with transparency exported from an SVG (always have your original art sources in SVG for things like this in case you need scaling)
<RCC>
<qresource prefix="/">
<file alias="default">cursors/cursor_default.png</file>
</qresource>
</RCC>
This will allow you to ship your cursors along with your application since Qt resource files are converted to C++ sources, which are then added to your binary
In your source code do:
QPixmap cursor_pixmap = QPixmap(":cursor_default");
QCursor cursor_default = QCursor(cursor_pixmap, 0, 0);
setCursor(cursor_default);
There are two important things to notice here both related to the constructor of the QCursor - the pixmap you add to it and the hotspot coordinates (here both set to 0 which is the top left corner of the pixmap that represents the shape of your cursor). There are actually 2 constructors for QCursor which are imho useful here:
- `QCursor::QCursor(const QBitmap &bitmap, const QBitmap &mask, int hotX = -1, int hotY = -1)` - this allows you to use a mask to manipulate the pixels of your cursor
- `QCursor::QCursor(const QPixmap &pixmap, int hotX = -1, int hotY = -1)` - if you are working with a PNG or other supported image format which allows transparency you can omit the mask as it is in my case.
The hotspot is a very essential part of a cursor - it tells your application which part of your cursor is the "trigger" that is the spot which does something compared to the rest which is just fancy visuals and nothing functional.
While looking for resources on Qt customization of cursors I found this article (the image above is from it), which I can totally recommend every one, interested in this topic, to read.
In terms of storing the hotspot I don't think that something like this is necessary. After all your resource files are compiled and added to the binary hence when you assign a hotspot to a cursor inside your code it will be there. I doubt that any OS actually has a format (let alone multi-platform one) that stores both the cursor and its hotspot due to the fact that depending on the application you may want to change the hotspot (for example due to scaling the bitmap itself in order to have multiple sizes) which would be a lot more difficult if you have it bound to the cursor's bitmap. If you really want to go the distance with this (I would advise against it) you can create your own custom file format which contains both. Since the Qt resource files are - to my knowledge - meant for managing images you would have to implement the whole IO mechanics in order to support your custom format.
Hope this helps. The solution above is as cross-platform as you can get with the Qt framework. Note however that the custom QCursor will only be available inside your application and wherever you have set it in. Cursor that is above the window frame for example is considered OS-specific due to the fact that the window frame itself is an OS-specific feature and if you want to alter its behaviour you will have to go a lot deeper (and also outside Qt's safe zone) meaning check how cursors are handled on an OS-level.