QSS version Management
-
Hello,
This is more of version management for the Qt Style Sheet file.
When we use the style, we may undergo various revisions for the modifications.
I would like to version control the file.
I was thinking off managing the version through a dummy style.
Example:
MyVersion { version: 1.0; }
I understand that this is more of manual version management. But still I can have a control on the version.
Is there any better way to manage the version for qss file?
Thanks,
Kumara -
If you're using a version control system like git or svn then the kinda natural solution is to leave the versioning to them, and refer to the revision number or hash if you need to.
If you want to include a version number in the file itself then no need to create a dummy style (that may baffle the parser). You can simply add a comment on top of it:
/* v1.0.0 */
, but there's really nothing stopping anyone from modifying this file and forgetting to increment the number so it's your decission. -
@Chris-Kawa Hey Chris,
Thanks a lot for the quick response.
I understand your point on using the source control software like SVN, GIT, etc for the versioning.
I was thinking about containing the version in the file because,
Say for example, I have a Qt based application ver1.0 and the stylesheet belongs to that - ver1.0. Qt Application would have the widgets and the stylesheet would have styles for them.Tomorrow, I have removed some of the widgets and added few newly. But I have forgotten to update the stylesheet.
So that brings out incompatibility.
Before I set the stylesheet to qApp, I would like to read the version from pro file, read the version from stylesheet and compare and find out the compatibility. Is it possible?
I completely agree without point of manually managing the version is more error prone.
Please let me know if you have any thoughts on this..
Thanks,
Kumara -
The only case I can see this useful is if you're gonna let the end users switch theses files so that the number is actually a way to have some minimum format validation. In that case the comment would be enough and you can just parse it before you apply the stylesheet (e.g. ead the first line and use QRegularExpression to extract the version number). As for reading a version from .pro file - these are compile time files - there is no .pro file on the users machine. What you can do is add the version to the DEFINES and then use that in your code.
Otherwise it's like giving a version number to a .cpp or an image file. It gives you nothing (or very little) and can be a cause of problems if someone modifies it without updating the version too.
Tomorrow, I have removed some of the widgets and added few newly. But I have forgotten to update the stylesheet.
So that brings out incompatibility.It's exactly like saying I have a header and a cpp. I'm adding/removing some code in the cpp file, but forgot to update the header to expose that. So that brings out null pointer errors and crashes.
I think we can both agree that adding a version constant to the header won't do you any good in this case.This should be managed on some testing level, not with a runtime cost of checks. I think a version should refer to a whole build. Versioning single files can easily become a hard to manage can of worms.
-
@Chris-Kawa said:
Chris, I completely agree with you and it makes sense to me.
The whole build be called out for a version and that should be managed at testing level. Not by versioning through comments, which doesnt makes sense.Thanks a lot for taking much time in making me clear.
On the fly just got a thought in my mind on versioning the Makefile. qmake generates make fine with the below header:
############################################################################# # Makefile for building: bin/blah # Generated by qmake (2.01a) (Qt 4.8.4) on: Fri Jul 31 16:22:38 2015 # Project: blah.pro # Template: app # Command: /home/kumararajas/ti-sdk-am335x-evm-07.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/qmake -o Makefile blah.pro #############################################################################
I do see the version of qmake
qmake (2.01a) (Qt 4.8.4)
Incompatible qmake can cause a problem. So the qmake is being bundled with the Qt version as a whole build.
Hopefully, I am OK with the understanding. Please let me know if you have any more thoughts on this.
Thank you!
Cheers,
Kumara