From jhihn at gmx.com Wed Jan 4 16:43:39 2017 From: jhihn at gmx.com (Jason H) Date: Wed, 4 Jan 2017 16:43:39 +0100 Subject: [Qt-creator] QML dir hierarchy Message-ID: I am cross posting this to QtC and Interest because it's a combinational issue. My QML projects are getting sizable, I'd like to start breaking my QML resources down in a hierarchy, but my attempt at that has failed. Given: qml.qrc / - app.js - Screen1.qml - Component1.qml - Screen1.qml - Component3.qml - Component4.qml - Screen1.qml - Component2.qml I'd like to break it down into: qml.qrc / - Screens / -- Screen1.qml -- Screen1.qml -- Screen1.qml - Components / -- Comoponent1.qml -- Comoponent2.qml But I was not able to accomplish this in QtC. So I hacked the QRC file to have two prefix entries: and However this resulted in errors. Also, in QtC they weren't folderized, they just appeared as screens/Screen1.qml ... components/Component1.qml ... How can I accomplish a folderized QRC? Currently, the filesystem is flat, but I don't mind adding them to actual folders if that would help. From Tobias.Hunger at qt.io Thu Jan 5 12:32:18 2017 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Thu, 5 Jan 2017 11:32:18 +0000 Subject: [Qt-creator] QML dir hierarchy In-Reply-To: References: Message-ID: <1483615936.797.9.camel@qt.io> Hi Jason, In Creator I see the qrc files with subfolders. I guess that is because we have them in subfolders on the file system (see attached screenshot). This is how the qrc file looks like:              QmakeProjectManager.mimetypes.xml         images/dark_unknown.png      Best Regards, Tobias On Wed, 2017-01-04 at 16:43 +0100, Jason H wrote: > I am cross posting this to QtC and Interest because it's a combinational > issue.  > > My QML projects are getting sizable, I'd like to start breaking my QML > resources down in a hierarchy, but my attempt at that has failed. > Given: > > qml.qrc / > - app.js > - Screen1.qml > - Component1.qml > - Screen1.qml > - Component3.qml > - Component4.qml > - Screen1.qml > - Component2.qml > > I'd like to break it down into: > qml.qrc / > - Screens / > -- Screen1.qml > -- Screen1.qml > -- Screen1.qml > - Components / > -- Comoponent1.qml > -- Comoponent2.qml > > But I was not able to accomplish this in QtC. So I hacked the QRC file to have > two prefix entries:   and   prefix="/components"> However this resulted in errors. > > Also, in QtC they weren't folderized, they just appeared as  > screens/Screen1.qml > ... > components/Component1.qml > ... > > How can I accomplish a folderized QRC? Currently, the filesystem is flat, but > I don't mind adding them to actual folders if that would help.  > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -------------- next part -------------- A non-text attachment was scrubbed... Name: resources.png Type: image/png Size: 16908 bytes Desc: resources.png URL: From jhihn at gmx.com Thu Jan 5 16:44:12 2017 From: jhihn at gmx.com (Jason H) Date: Thu, 5 Jan 2017 16:44:12 +0100 Subject: [Qt-creator] QML dir hierarchy In-Reply-To: <1483615936.797.9.camel@qt.io> References: , <1483615936.797.9.camel@qt.io> Message-ID: Ah, ok, so it is possible in filesystem folders, but not possible for groupings of qresource elements with prefix="" attributes within a QRC. > Sent: Thursday, January 05, 2017 at 6:32 AM > From: "Tobias Hunger" > To: "qt-creator at qt-project.org" > Subject: Re: [Qt-creator] QML dir hierarchy > > Hi Jason, > > In Creator I see the qrc files with subfolders. I guess that is because we have > them in subfolders on the file system (see attached screenshot). > > This is how the qrc file looks like: > > >      >         QmakeProjectManager.mimetypes.xml >         images/dark_unknown.png >      > > > Best Regards, > Tobias > > On Wed, 2017-01-04 at 16:43 +0100, Jason H wrote: > > I am cross posting this to QtC and Interest because it's a combinational > > issue.  > > > > My QML projects are getting sizable, I'd like to start breaking my QML > > resources down in a hierarchy, but my attempt at that has failed. > > Given: > > > > qml.qrc / > > - app.js > > - Screen1.qml > > - Component1.qml > > - Screen1.qml > > - Component3.qml > > - Component4.qml > > - Screen1.qml > > - Component2.qml > > > > I'd like to break it down into: > > qml.qrc / > > - Screens / > > -- Screen1.qml > > -- Screen1.qml > > -- Screen1.qml > > - Components / > > -- Comoponent1.qml > > -- Comoponent2.qml > > > > But I was not able to accomplish this in QtC. So I hacked the QRC file to have > > two prefix entries:   and   > prefix="/components"> However this resulted in errors. > > > > Also, in QtC they weren't folderized, they just appeared as  > > screens/Screen1.qml > > ... > > components/Component1.qml > > ... > > > > How can I accomplish a folderized QRC? Currently, the filesystem is flat, but > > I don't mind adding them to actual folders if that would help.  > > _______________________________________________ > > Qt-creator mailing list > > Qt-creator at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/qt-creator > > -- > Tobias Hunger, Senior Software Engineer | The Qt Company > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B_______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator > From imikejackson at gmail.com Thu Jan 5 18:12:48 2017 From: imikejackson at gmail.com (Mike Jackson) Date: Thu, 05 Jan 2017 12:12:48 -0500 Subject: [Qt-creator] CMake Server Integration Feedback Message-ID: <586E7E90.9010909@gmail.com> Just pulled the latest QtCreator 4.3 beta build and installed CMake 3.7.1 on my macOS 10.10.5 machine. First impressions are this is really cool. I more or less like the new layout that QtCreator presents. I do have some questions/feedback that could probably be fixed by our project updating some of our cmake code. See attached image. A lot of our "sub projects" do not list a but all of the source codes listed under . What cmake variable is QtCreator keying off of? I would be happy to make sure the proper variable is setup. At some point in the past we moved away from using the CMake "Project" command in all the sub-directories to help fix something else (Maybe Xcode or Creator or Visual Studio generation). The top level project listed is not really the top level project at all. It is some sub-project where the CMake code probably uses the "Project" command. Is there a way to indicate to QtCreator that the _first_ "Project" command that is found is used as the top level project? Is there a way to cut down on the number of embedded folders that are shown (/Users/mjackson/Workspace/DREAM3D_Plugins/$PLUGIN_NAME in my example) by setting some sort of PROJECT_ROOT_DIR cmake variable? That might be nice to have. Again, this is looking really awesome for CMake & QtCreator integration. CMake really feels like a first class citizen in QtCreator. -- Mike Jackson [mike.jackson at bluequartz.net] BlueQuartz Software, LLC. -------------- next part -------------- A non-text attachment was scrubbed... Name: CmaekServerIntegrationFeedback.png Type: image/png Size: 85508 bytes Desc: not available URL: From imikejackson at gmail.com Thu Jan 5 21:21:14 2017 From: imikejackson at gmail.com (Mike Jackson) Date: Thu, 05 Jan 2017 15:21:14 -0500 Subject: [Qt-creator] CMake Server Integration Feedback In-Reply-To: <586E7E90.9010909@gmail.com> References: <586E7E90.9010909@gmail.com> Message-ID: <586EAABA.4080407@gmail.com> The issue with the top level project is based on alphabetically listed projects and it looks like QtCreator takes the first one. The other issue with the is because those source folders are actually outside of the folder that has the top level CMakeLists.txt file. Not sure there is really any way of fixing that issue. -- Mike Jackson [mike.jackson at bluequartz.net] Mike Jackson wrote: > Just pulled the latest QtCreator 4.3 beta build and installed CMake > 3.7.1 on my macOS 10.10.5 machine. First impressions are this is really > cool. I more or less like the new layout that QtCreator presents. I do > have some questions/feedback that could probably be fixed by our project > updating some of our cmake code. > > See attached image. > > A lot of our "sub projects" do not list a but all of > the source codes listed under . What cmake variable is > QtCreator keying off of? I would be happy to make sure the proper > variable is setup. At some point in the past we moved away from using > the CMake "Project" command in all the sub-directories to help fix > something else (Maybe Xcode or Creator or Visual Studio generation). > > The top level project listed is not really the top level project at all. > It is some sub-project where the CMake code probably uses the "Project" > command. Is there a way to indicate to QtCreator that the _first_ > "Project" command that is found is used as the top level project? > > Is there a way to cut down on the number of embedded folders that are > shown (/Users/mjackson/Workspace/DREAM3D_Plugins/$PLUGIN_NAME in my > example) by setting some sort of PROJECT_ROOT_DIR cmake variable? That > might be nice to have. > > Again, this is looking really awesome for CMake & QtCreator integration. > CMake really feels like a first class citizen in QtCreator. > From tobias.hunger at gmail.com Thu Jan 5 21:40:11 2017 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 5 Jan 2017 21:40:11 +0100 Subject: [Qt-creator] CMake Server Integration Feedback In-Reply-To: <586E7E90.9010909@gmail.com> References: <586E7E90.9010909@gmail.com> Message-ID: Hi Mike, On Thu, Jan 5, 2017 at 6:12 PM, Mike Jackson wrote: > Just pulled the latest QtCreator 4.3 beta build and installed CMake 3.7.1 on > my macOS 10.10.5 machine. First impressions are this is really cool. I more > or less like the new layout that QtCreator presents. I do have some > questions/feedback that could probably be fixed by our project updating some > of our cmake code. Good:-) > See attached image. > > A lot of our "sub projects" do not list a but all of the > source codes listed under . What cmake variable is > QtCreator keying off of? I would be happy to make sure the proper variable > is setup. At some point in the past we moved away from using the CMake > "Project" command in all the sub-directories to help fix something else > (Maybe Xcode or Creator or Visual Studio generation). is used for files that are outside of what cmake considers to be the source or build directory of that target. You already found that out:-) > The top level project listed is not really the top level project at all. It > is some sub-project where the CMake code probably uses the "Project" > command. Is there a way to indicate to QtCreator that the _first_ "Project" > command that is found is used as the top level project? Yes, there is a bug there. Creator currently picks the first project it gets from cmake. Apparently cmake does not keep the projects in the order they are encountered (which is what I assumed it would do). Fixing that is on my todo list. > Is there a way to cut down on the number of embedded folders that are shown > (/Users/mjackson/Workspace/DREAM3D_Plugins/$PLUGIN_NAME in my example) by > setting some sort of PROJECT_ROOT_DIR cmake variable? That might be nice to > have. There is no such variable AFAIK. CMake assumes that all sources are below the top-level cmake file and creator follows that. > Again, this is looking really awesome for CMake & QtCreator integration. > CMake really feels like a first class citizen in QtCreator. Thanks! It is fun to make this work:-) Best Regards, Tobias From imikejackson at gmail.com Thu Jan 5 21:52:06 2017 From: imikejackson at gmail.com (Mike Jackson) Date: Thu, 05 Jan 2017 15:52:06 -0500 Subject: [Qt-creator] CMake Server Integration Feedback In-Reply-To: References: <586E7E90.9010909@gmail.com> Message-ID: <586EB1F6.1050404@gmail.com> Tobias Hunger wrote: > Hi Mike, > > On Thu, Jan 5, 2017 at 6:12 PM, Mike Jackson wrote: >> Just pulled the latest QtCreator 4.3 beta build and installed CMake 3.7.1 on >> my macOS 10.10.5 machine. First impressions are this is really cool. I more >> or less like the new layout that QtCreator presents. I do have some >> questions/feedback that could probably be fixed by our project updating some >> of our cmake code. > > Good:-) > >> See attached image. >> >> A lot of our "sub projects" do not list a but all of the >> source codes listed under. What cmake variable is >> QtCreator keying off of? I would be happy to make sure the proper variable >> is setup. At some point in the past we moved away from using the CMake >> "Project" command in all the sub-directories to help fix something else >> (Maybe Xcode or Creator or Visual Studio generation). > > is used for files that are outside of what cmake > considers to be the source or build directory of that target. > > You already found that out:-) With the magic of .gitignore I was able to move these "external" projects inside of the top level directory so this is solved. I'll pass this trick onto our other developers > >> The top level project listed is not really the top level project at all. It >> is some sub-project where the CMake code probably uses the "Project" >> command. Is there a way to indicate to QtCreator that the _first_ "Project" >> command that is found is used as the top level project? > > Yes, there is a bug there. Creator currently picks the first project > it gets from cmake. Apparently cmake does not keep the projects in the > order they are encountered (which is what I assumed it would do). > Fixing that is on my todo list. > A reasonable assumption :-) But looking forward to the fix.. >> Is there a way to cut down on the number of embedded folders that are shown >> (/Users/mjackson/Workspace/DREAM3D_Plugins/$PLUGIN_NAME in my example) by >> setting some sort of PROJECT_ROOT_DIR cmake variable? That might be nice to >> have. > > There is no such variable AFAIK. CMake assumes that all sources are > below the top-level cmake file and creator follows that. With my changes to my cmake codes the project display is starting to look better. It still feels like I have a lot of extra folders included in each of my sub projects. Does QtCreator get this list from the "include_directories()" command from CMake? I can see our code might be a bit sloppy when it comes to defining those include directories. Or we are getting carry over from other projects and getting their include_directories? I'll try some stuff out and try to report back. > >> Again, this is looking really awesome for CMake& QtCreator integration. >> CMake really feels like a first class citizen in QtCreator. > > Thanks! It is fun to make this work:-) > > Best Regards, > Tobias Mike J. From pbontrag at jaguarlandrover.com Thu Jan 5 22:14:37 2017 From: pbontrag at jaguarlandrover.com (Bontrager, Matt) Date: Thu, 5 Jan 2017 13:14:37 -0800 Subject: [Qt-creator] qtvirtualkeyboard Custom Style "scaleHint" Message-ID: Question: How Do I Compute the "scaleHint"? I am developing a custom style for the qtvirtualkeyboard. According to this page , it says: This value is determined by the physical size and the design size of the keyboard. I understand that the physical size of the keyboard and the design size of the keyboard are used to compute the scaleHint, but it doesn't say *how* it uses those to factors to determine it. Can someone explain what that actually means and also... how do I compute the actual value of the scaleHint? Thanks in advance. Best, *Matt Bontrager* Senior Software Developer Future Technology Infotainment, Electronic and Software Systems *T:* +1.971.256.9743 *| M: *+1.503.550.0727 Jaguar Land Rover North America, LLC 1419 NW 14th Avenue, Portland, OR 97209 JaguarUSA.com | LandRoverUSA.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.wingard at crosscontrol.com Wed Jan 4 18:55:18 2017 From: alexander.wingard at crosscontrol.com (Wingard, Alexander) Date: Wed, 4 Jan 2017 17:55:18 +0000 Subject: [Qt-creator] QML dir hierarchy In-Reply-To: References: Message-ID: That can absolutely be done. Made a quick example: // This is how the qrc is structured Qml.qrc ======= main.qml MyAsset.qml alert.png // And this is how you can address components under prefixes Main.qml ========== import QtQuick 2.1 import QtQuick.Controls 1.0 import "qrc:/assets" // NEEDED FOR COMPONENTS UNDER PREFIXES! ApplicationWindow { visible: true width: 640 height: 480 title: qsTr("Hello World") MyAsset { // Available due to the explicit import of qrc:/assets anchors.centerIn: parent } Image { // Path pattern: "qrc:/< path>" // Tip: You can use aliases in qml.qrc to shorten paths for files in subfolders. source: "qrc:/images/alert.png" } } Hope that helped! /Alex Alexander Wingård Software Developer www.crosscontrol.com CrossControl making machines smart, safe and productive -----Original Message----- From: Qt-creator [mailto:qt-creator-bounces+alexander.wingard=maximatecc.com at qt-project.org] On Behalf Of Jason H Sent: den 4 januari 2017 16:44 To: interestqt-project.org; qt-creator Subject: [Qt-creator] QML dir hierarchy I am cross posting this to QtC and Interest because it's a combinational issue. My QML projects are getting sizable, I'd like to start breaking my QML resources down in a hierarchy, but my attempt at that has failed. Given: qml.qrc / - app.js - Screen1.qml - Component1.qml - Screen1.qml - Component3.qml - Component4.qml - Screen1.qml - Component2.qml I'd like to break it down into: qml.qrc / - Screens / -- Screen1.qml -- Screen1.qml -- Screen1.qml - Components / -- Comoponent1.qml -- Comoponent2.qml But I was not able to accomplish this in QtC. So I hacked the QRC file to have two prefix entries: and However this resulted in errors. Also, in QtC they weren't folderized, they just appeared as screens/Screen1.qml ... components/Component1.qml ... How can I accomplish a folderized QRC? Currently, the filesystem is flat, but I don't mind adding them to actual folders if that would help. _______________________________________________ Qt-creator mailing list Qt-creator at qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator ________________________________ Actuant Corporation Email Notice This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and/or CONFIDENTIAL. This email is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this email is not an intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return mail and permanently delete the copy you received. Thank you. From Even.Kristoffersen at Honeywell.com Thu Jan 5 09:07:24 2017 From: Even.Kristoffersen at Honeywell.com (Kristoffersen, Even (NO14)) Date: Thu, 5 Jan 2017 08:07:24 +0000 Subject: [Qt-creator] [Interest] QML dir hierarchy In-Reply-To: References: Message-ID: <92000C074E92194CB9110465E5C338BE577391B5@de08ex3001.global.ds.honeywell.com> Try putting your QML files in subfolders. You will probably want to do this sooner or later anyway to keep your source tree manageable as the project grows. Just beware that you then have to import the folder of the components you are using from within the QML files unless they are in the same folder. IE. import "../Components" from your screen files. -Even -----Original Message----- From: Interest [mailto:interest-bounces+even.kristoffersen=honeywell.com at qt-project.org] On Behalf Of Jason H Sent: 4. januar 2017 16:44 To: interestqt-project.org ; qt-creator Subject: [Interest] QML dir hierarchy I am cross posting this to QtC and Interest because it's a combinational issue. My QML projects are getting sizable, I'd like to start breaking my QML resources down in a hierarchy, but my attempt at that has failed. Given: qml.qrc / - app.js - Screen1.qml - Component1.qml - Screen1.qml - Component3.qml - Component4.qml - Screen1.qml - Component2.qml I'd like to break it down into: qml.qrc / - Screens / -- Screen1.qml -- Screen1.qml -- Screen1.qml - Components / -- Comoponent1.qml -- Comoponent2.qml But I was not able to accomplish this in QtC. So I hacked the QRC file to have two prefix entries: and However this resulted in errors. Also, in QtC they weren't folderized, they just appeared as screens/Screen1.qml ... components/Component1.qml ... How can I accomplish a folderized QRC? Currently, the filesystem is flat, but I don't mind adding them to actual folders if that would help. _______________________________________________ Interest mailing list Interest at qt-project.org http://lists.qt-project.org/mailman/listinfo/interest From Even.Kristoffersen at Honeywell.com Thu Jan 5 09:58:31 2017 From: Even.Kristoffersen at Honeywell.com (Kristoffersen, Even (NO14)) Date: Thu, 5 Jan 2017 08:58:31 +0000 Subject: [Qt-creator] [Interest] QML dir hierarchy In-Reply-To: <92000C074E92194CB9110465E5C338BE577391B5@de08ex3001.global.ds.honeywell.com> References: <92000C074E92194CB9110465E5C338BE577391B5@de08ex3001.global.ds.honeywell.com> Message-ID: <92000C074E92194CB9110465E5C338BE57739229@de08ex3001.global.ds.honeywell.com> Note, this won't help with the QRC view unfortunately, it will still display as path list instead of folderized. If you want to keep using the QRC view only then you have to use prefix as you mentioned, but I believe you have to import the prefix. Maybe this was the cause of the error you saw. Another option is to use the OTHER_FILES option in your .pro file. OTHER_FILES += \ RES/qml/*.qml \ RES/qml/Components/*.qml \ RES/qml/Screens/*.qml This will add a folderized QML folder in your project explorer. -Even -----Original Message----- From: Interest [mailto:interest-bounces+even.kristoffersen=honeywell.com at qt-project.org] On Behalf Of Kristoffersen, Even (NO14) Sent: 5. januar 2017 09:07 To: interestqt-project.org ; qt-creator Subject: Re: [Interest] QML dir hierarchy Try putting your QML files in subfolders. You will probably want to do this sooner or later anyway to keep your source tree manageable as the project grows. Just beware that you then have to import the folder of the components you are using from within the QML files unless they are in the same folder. IE. import "../Components" from your screen files. -Even -----Original Message----- From: Interest [mailto:interest-bounces+even.kristoffersen=honeywell.com at qt-project.org] On Behalf Of Jason H Sent: 4. januar 2017 16:44 To: interestqt-project.org ; qt-creator Subject: [Interest] QML dir hierarchy I am cross posting this to QtC and Interest because it's a combinational issue. My QML projects are getting sizable, I'd like to start breaking my QML resources down in a hierarchy, but my attempt at that has failed. Given: qml.qrc / - app.js - Screen1.qml - Component1.qml - Screen1.qml - Component3.qml - Component4.qml - Screen1.qml - Component2.qml I'd like to break it down into: qml.qrc / - Screens / -- Screen1.qml -- Screen1.qml -- Screen1.qml - Components / -- Comoponent1.qml -- Comoponent2.qml But I was not able to accomplish this in QtC. So I hacked the QRC file to have two prefix entries: and However this resulted in errors. Also, in QtC they weren't folderized, they just appeared as screens/Screen1.qml ... components/Component1.qml ... How can I accomplish a folderized QRC? Currently, the filesystem is flat, but I don't mind adding them to actual folders if that would help. _______________________________________________ Interest mailing list Interest at qt-project.org http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest at qt-project.org http://lists.qt-project.org/mailman/listinfo/interest From nunosantos at imaginando.pt Thu Jan 5 10:14:32 2017 From: nunosantos at imaginando.pt (Nuno Santos) Date: Thu, 5 Jan 2017 09:14:32 +0000 Subject: [Qt-creator] [Interest] QML dir hierarchy In-Reply-To: <92000C074E92194CB9110465E5C338BE57739229@de08ex3001.global.ds.honeywell.com> References: <92000C074E92194CB9110465E5C338BE577391B5@de08ex3001.global.ds.honeywell.com> <92000C074E92194CB9110465E5C338BE57739229@de08ex3001.global.ds.honeywell.com> Message-ID: <40DB1B5B-555F-4BDA-9C57-D6A3AA91AD14@imaginando.pt> Keep your qml resources inside folders / /resources /resources/icons /resources/images /resources/qml /resources/fonts create a .qrc file on the .pro dir or inside resources. Open .qrc with editor and choose to add existing files. Select the files inside the dirs (icons, images, qml, fonts). The files will automatically be added with the respective paths as prefix. > On 05 Jan 2017, at 08:58, Kristoffersen, Even (NO14) wrote: > > Note, this won't help with the QRC view unfortunately, it will still display as path list instead of folderized. > > If you want to keep using the QRC view only then you have to use prefix as you mentioned, but I believe you have to import the prefix. Maybe this was the cause of the error you saw. > > Another option is to use the OTHER_FILES option in your .pro file. > > OTHER_FILES += \ > RES/qml/*.qml \ > RES/qml/Components/*.qml \ > RES/qml/Screens/*.qml > > This will add a folderized QML folder in your project explorer. > > > -Even > > -----Original Message----- > From: Interest [mailto:interest-bounces+even.kristoffersen=honeywell.com at qt-project.org] On Behalf Of Kristoffersen, Even (NO14) > Sent: 5. januar 2017 09:07 > To: interestqt-project.org ; qt-creator > Subject: Re: [Interest] QML dir hierarchy > > Try putting your QML files in subfolders. > You will probably want to do this sooner or later anyway to keep your source tree manageable as the project grows. > > Just beware that you then have to import the folder of the components you are using from within the QML files unless they are in the same folder. > IE. import "../Components" from your screen files. > > -Even > > -----Original Message----- > From: Interest [mailto:interest-bounces+even.kristoffersen=honeywell.com at qt-project.org] On Behalf Of Jason H > Sent: 4. januar 2017 16:44 > To: interestqt-project.org ; qt-creator > Subject: [Interest] QML dir hierarchy > > I am cross posting this to QtC and Interest because it's a combinational issue. > > My QML projects are getting sizable, I'd like to start breaking my QML resources down in a hierarchy, but my attempt at that has failed. > Given: > > qml.qrc / > - app.js > - Screen1.qml > - Component1.qml > - Screen1.qml > - Component3.qml > - Component4.qml > - Screen1.qml > - Component2.qml > > I'd like to break it down into: > qml.qrc / > - Screens / > -- Screen1.qml > -- Screen1.qml > -- Screen1.qml > - Components / > -- Comoponent1.qml > -- Comoponent2.qml > > But I was not able to accomplish this in QtC. So I hacked the QRC file to have two prefix entries: and However this resulted in errors. > > Also, in QtC they weren't folderized, they just appeared as screens/Screen1.qml ... > components/Component1.qml > ... > > How can I accomplish a folderized QRC? Currently, the filesystem is flat, but I don't mind adding them to actual folders if that would help. > _______________________________________________ > Interest mailing list > Interest at qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > _______________________________________________ > Interest mailing list > Interest at qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > _______________________________________________ > Interest mailing list > Interest at qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest From mitch.curtis at qt.io Fri Jan 13 16:54:21 2017 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 13 Jan 2017 15:54:21 +0000 Subject: [Qt-creator] qtvirtualkeyboard Custom Style "scaleHint" In-Reply-To: References: Message-ID: Hi Matt. You can see how the scaleHint is calculated here: http://code.qt.io/cgit/qt/qtvirtualkeyboard.git/tree/src/virtualkeyboard/styles/KeyboardStyle.qml#n60 I’ve created a bug report for the lacking documentation: https://bugreports.qt.io/browse/QTBUG-58154 PS: this list is for Qt Creator; you’re better off asking on the Interest mailing list for general Qt stuff. Cheers. From: Qt-creator [mailto:qt-creator-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Bontrager, Matt Sent: Thursday, 5 January 2017 10:15 PM To: qt-creator at qt-project.org Subject: [Qt-creator] qtvirtualkeyboard Custom Style "scaleHint" Question: How Do I Compute the "scaleHint"? I am developing a custom style for the qtvirtualkeyboard. According to this page, it says: This value is determined by the physical size and the design size of the keyboard. I understand that the physical size of the keyboard and the design size of the keyboard are used to compute the scaleHint, but it doesn't say how it uses those to factors to determine it. Can someone explain what that actually means and also... how do I compute the actual value of the scaleHint? Thanks in advance. Best, Matt Bontrager Senior Software Developer Future Technology Infotainment, Electronic and Software Systems T: +1.971.256.9743 | M: +1.503.550.0727 [http://www.jaguarlandrover.com/email/jlr.jpg] Jaguar Land Rover North America, LLC 1419 NW 14th Avenue, Portland, OR 97209 JaguarUSA.com | LandRoverUSA.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbontrag at jaguarlandrover.com Fri Jan 13 21:56:26 2017 From: pbontrag at jaguarlandrover.com (Matt Bontrager) Date: Fri, 13 Jan 2017 12:56:26 -0800 Subject: [Qt-creator] qtvirtualkeyboard Custom Style "scaleHint" In-Reply-To: References: Message-ID: <8678787326560371963@unknownmsgid> Thanks very much Mitch! Both for the reference link as well as the tip on where to post in the future. Best, Matt Bontrager Senior JavaScript Developer Jaguar Land Rover Sent from my iPhone On Jan 13, 2017, at 07:54, Mitch Curtis wrote: Hi Matt. You can see how the scaleHint is calculated here: http://code.qt.io/cgit/qt/qtvirtualkeyboard.git/tree/src/virtualkeyboard/styles/KeyboardStyle.qml#n60 I’ve created a bug report for the lacking documentation: https://bugreports.qt.io/browse/QTBUG-58154 PS: this list is for Qt Creator; you’re better off asking on the Interest mailing list for general Qt stuff. Cheers. *From:* Qt-creator [ mailto:qt-creator-bounces+mitch.curtis=qt.io at qt-project.org ] *On Behalf Of *Bontrager, Matt *Sent:* Thursday, 5 January 2017 10:15 PM *To:* qt-creator at qt-project.org *Subject:* [Qt-creator] qtvirtualkeyboard Custom Style "scaleHint" Question: How Do I Compute the "scaleHint"? I am developing a custom style for the qtvirtualkeyboard. According to this page , it says: This value is determined by the physical size and the design size of the keyboard. I understand that the physical size of the keyboard and the design size of the keyboard are used to compute the scaleHint, but it doesn't say *how* it uses those to factors to determine it. Can someone explain what that actually means and also... how do I compute the actual value of the scaleHint? Thanks in advance. Best, *Matt Bontrager* Senior Software Developer Future Technology Infotainment, Electronic and Software Systems *T:* +1.971.256.9743 *| M: *+1.503.550.0727 Jaguar Land Rover North America, LLC 1419 NW 14th Avenue, Portland, OR 97209 JaguarUSA.com | LandRoverUSA.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre.hartmann at iseg-hv.de Mon Jan 16 12:06:56 2017 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Mon, 16 Jan 2017 12:06:56 +0100 Subject: [Qt-creator] =?utf-8?q?Generic_highlighter_f=C3=BCr_Bitbake_*=2Ei?= =?utf-8?q?nc_files?= Message-ID: I found the bitbake-syntax-highlighter generic highlighter on Github [1] and started to use it for my bitbake receipes with QtCreator. Highlighting of .bb and .bbappend files works well, but .inc files are not highlighted at all. If I edit the XML file and change "*.inc" to "*.bbinc" in the extension list line and rename my file, the highlighting is fine. But that's not what I want to do :) Any ideas on this? Best regards, André I have tried QtCreator 3.4 and 4.2. [1] https://github.com/ikoveshnikov/bitbake-syntax-highlighter From Eike.Ziller at qt.io Mon Jan 16 12:10:54 2017 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 16 Jan 2017 11:10:54 +0000 Subject: [Qt-creator] =?utf-8?q?Generic_highlighter_f=C3=BCr_Bitbake_*=2E?= =?utf-8?q?inc_files?= In-Reply-To: References: Message-ID: <91ACD85C-C28C-4B2E-80CD-89736C51FF03@qt.io> > On Jan 16, 2017, at 12:06 PM, André Hartmann wrote: > > I found the bitbake-syntax-highlighter generic highlighter on Github [1] and started to use it for my bitbake receipes with QtCreator. > > Highlighting of .bb and .bbappend files works well, but .inc files are not highlighted at all. If I edit the XML file and change "*.inc" to "*.bbinc" in the extension list line and rename my file, the highlighting is fine. But that's not what I want to do :) > > Any ideas on this? Looks like it conflicts with the highlighter for Doxyfile Br, Eike > > Best regards, > André > > I have tried QtCreator 3.4 and 4.2. > > [1] https://github.com/ikoveshnikov/bitbake-syntax-highlighter > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From annulen at yandex.ru Mon Jan 16 12:28:43 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 16 Jan 2017 14:28:43 +0300 Subject: [Qt-creator] =?utf-8?q?Generic_highlighter_f=C3=BCr_Bitbake_*=2E?= =?utf-8?q?inc_files?= In-Reply-To: <91ACD85C-C28C-4B2E-80CD-89736C51FF03@qt.io> References: <91ACD85C-C28C-4B2E-80CD-89736C51FF03@qt.io> Message-ID: <1297531484566123@web32j.yandex.ru> 16.01.2017, 14:11, "Eike Ziller" : >>  On Jan 16, 2017, at 12:06 PM, André Hartmann wrote: >> >>  I found the bitbake-syntax-highlighter generic highlighter on Github [1] and started to use it for my bitbake receipes with QtCreator. >> >>  Highlighting of .bb and .bbappend files works well, but .inc files are not highlighted at all. If I edit the XML file and change "*.inc" to "*.bbinc" in the extension list line and rename my file, the highlighting is fine. But that's not what I want to do :) >> >>  Any ideas on this? > > Looks like it conflicts with the highlighter for Doxyfile Actually, *.inc file extension may correspond to different file types depending on context, e.g. LLVM project uses this extension for 1) C++ "header" files intended to be included in the middle or at the end of source file, and 2) for TableGen include files. > > Br, Eike > >>  Best regards, >>  André >> >>  I have tried QtCreator 3.4 and 4.2. >> >>  [1] https://github.com/ikoveshnikov/bitbake-syntax-highlighter >>  _______________________________________________ >>  Qt-creator mailing list >>  Qt-creator at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/qt-creator > > -- > Eike Ziller > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > eike.ziller at qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator -- Regards, Konstantin From Eike.Ziller at qt.io Mon Jan 16 12:48:13 2017 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 16 Jan 2017 11:48:13 +0000 Subject: [Qt-creator] Proposal: Increase requirements for compiling Qt Creator to GCC>=4.9 Message-ID: <53A91E89-E9F4-4731-9E95-AEDB03ADFBDA@qt.io> I propose increasing the GCC compiler requirements for compiling Qt Creator, starting with 4.3, to GCC >= 4.9. https://codereview.qt-project.org/182471 This allows us to use parts of C++14, which will most probably not have a huge impact on how we write code, but contains a few goodies in some special areas anyhow. (http://en.cppreference.com/w/cpp/compiler_support) As far as I can see, the main supported platform (in the default configuration) that we will loose when doing this is Ubuntu 14.04 which should be acceptable with 16.04 being the “current” LTS. *_t versions of various type traits —---------------------------- std::decay_t (instead of “typename std::decay::type”) std::result_of_t std::enable_if_t … No reason not to use it. https://codereview.qt-project.org/182060 make_unique and make_shared —---------------------------- Makes the code shorter and more readable, and has a few smaller benefits. Afaics no reason not to use it. reverse iterators std::(c)rbegin/(c)rend —---------------------------- Afaics no reason not to use it. (make_)(integer|index)_sequence —---------------------------- You probably don’t care, but I do (a little) ;) https://codereview.qt-project.org/182231 decltype(auto) —---------------------------- Since we do not allow “auto a = b;” in our coding style, this is probably mostly useful in some situations with templates to avoid writing auto foo(….) -> decltype(….) when the return type depends on function arguments. Can be written as decltype(auto) foo(….) in the cases where the decltype expression was the expression that is returned. https://codereview.qt-project.org/182096 auto for normal functions —---------------------------- So far our coding style only allows auto for a very limited set of situations: • when the type is repeated in the same statement • when the type is some unwieldy template construct (e.g. iterator types), or lambda • implicitly for the return value of lambdas I think we should keep use of auto restricted, and keep the rules as is. The gain in readability is worth the effort. Generalized Lambda Captures —---------------------------- [foo = bar + 1]() {…} Probably not many uses for it, but I also don’t see a reason why not to use it occasionally. Generic lambda expressions —---------------------------- Allows using “auto” in parameter lists for lambdas: "[](const auto &name) {…..}” instead of “[](const QString &name) {….}”, “[](auto kit) {…}” instead of “[](Kit *kit) {…}”. I’m not sure about this one. It can be useful when actually using it polymorphic, i.e. reuse the lambda for different types, but that is not happening often in our code. In the “normal” case it can be more concise if the type(s) that are passed to the lambda have long names or are templated. For the template case we can of course apply the usual rule for “auto”. If the lambda is used as a parameter to some algorithm (anyOf, transform, findOr), the type of the parameter should be pretty clear from context. In other situations, it is not so clear. Also the gain, for single-use lambdas and when the type names are not too long, is very small. Br, Eike -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Tobias.Hunger at qt.io Mon Jan 16 13:23:27 2017 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Mon, 16 Jan 2017 12:23:27 +0000 Subject: [Qt-creator] Proposal: Increase requirements for compiling Qt Creator to GCC>=4.9 In-Reply-To: <53A91E89-E9F4-4731-9E95-AEDB03ADFBDA@qt.io> References: <53A91E89-E9F4-4731-9E95-AEDB03ADFBDA@qt.io> Message-ID: <1484569405.797.36.camel@qt.io> On Mon, 2017-01-16 at 11:48 +0000, Eike Ziller wrote: > I propose increasing the GCC compiler requirements for compiling Qt Creator, > starting with 4.3, to GCC >= 4.9. > https://codereview.qt-project.org/182471 +1 Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Marco.Bubke at qt.io Mon Jan 16 13:26:30 2017 From: Marco.Bubke at qt.io (Marco Bubke) Date: Mon, 16 Jan 2017 12:26:30 +0000 Subject: [Qt-creator] Proposal: Increase requirements for compiling Qt Creator to GCC>=4.9 In-Reply-To: <53A91E89-E9F4-4731-9E95-AEDB03ADFBDA@qt.io> References: <53A91E89-E9F4-4731-9E95-AEDB03ADFBDA@qt.io> Message-ID: +1 It fixes many annoying bugs too! I would like to use auto for return types if they are returning long types like iterators, tuples, pairs or a mixture of them. Something like std::pair::const_iterator, bool> findEntry(const std::pair &items, int value) { auto found = std::lower_bound(items.begin(), items.end(), value, [] (const SomeClass &entry, int value) { return entry.someSpecialValue = value; }); return {found, found != items.end()}; } I like to use function to document the code to avoid long hard to read methods and the code is easily unit testable because the method does one thing. The same would be apply to generic templates. ________________________________ From: Qt-creator on behalf of Eike Ziller Sent: Monday, January 16, 2017 12:48:13 PM To: qt-creator at qt-project.org Subject: [Qt-creator] Proposal: Increase requirements for compiling Qt Creator to GCC>=4.9 I propose increasing the GCC compiler requirements for compiling Qt Creator, starting with 4.3, to GCC >= 4.9. https://codereview.qt-project.org/182471 This allows us to use parts of C++14, which will most probably not have a huge impact on how we write code, but contains a few goodies in some special areas anyhow. (http://en.cppreference.com/w/cpp/compiler_support) As far as I can see, the main supported platform (in the default configuration) that we will loose when doing this is Ubuntu 14.04 which should be acceptable with 16.04 being the “current” LTS. *_t versions of various type traits —---------------------------- std::decay_t (instead of “typename std::decay::type”) std::result_of_t std::enable_if_t … No reason not to use it. https://codereview.qt-project.org/182060 make_unique and make_shared —---------------------------- Makes the code shorter and more readable, and has a few smaller benefits. Afaics no reason not to use it. reverse iterators std::(c)rbegin/(c)rend —---------------------------- Afaics no reason not to use it. (make_)(integer|index)_sequence —---------------------------- You probably don’t care, but I do (a little) ;) https://codereview.qt-project.org/182231 decltype(auto) —---------------------------- Since we do not allow “auto a = b;” in our coding style, this is probably mostly useful in some situations with templates to avoid writing auto foo(….) -> decltype(….) when the return type depends on function arguments. Can be written as decltype(auto) foo(….) in the cases where the decltype expression was the expression that is returned. https://codereview.qt-project.org/182096 auto for normal functions —---------------------------- So far our coding style only allows auto for a very limited set of situations: • when the type is repeated in the same statement • when the type is some unwieldy template construct (e.g. iterator types), or lambda • implicitly for the return value of lambdas I think we should keep use of auto restricted, and keep the rules as is. The gain in readability is worth the effort. Generalized Lambda Captures —---------------------------- [foo = bar + 1]() {…} Probably not many uses for it, but I also don’t see a reason why not to use it occasionally. Generic lambda expressions —---------------------------- Allows using “auto” in parameter lists for lambdas: "[](const auto &name) {…..}” instead of “[](const QString &name) {….}”, “[](auto kit) {…}” instead of “[](Kit *kit) {…}”. I’m not sure about this one. It can be useful when actually using it polymorphic, i.e. reuse the lambda for different types, but that is not happening often in our code. In the “normal” case it can be more concise if the type(s) that are passed to the lambda have long names or are templated. For the template case we can of course apply the usual rule for “auto”. If the lambda is used as a parameter to some algorithm (anyOf, transform, findOr), the type of the parameter should be pretty clear from context. In other situations, it is not so clear. Also the gain, for single-use lambdas and when the type names are not too long, is very small. Br, Eike -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Qt-creator mailing list Qt-creator at qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eike.Ziller at qt.io Mon Jan 16 13:39:05 2017 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 16 Jan 2017 12:39:05 +0000 Subject: [Qt-creator] Proposal: Increase requirements for compiling Qt Creator to GCC>=4.9 In-Reply-To: References: <53A91E89-E9F4-4731-9E95-AEDB03ADFBDA@qt.io> Message-ID: <382F0DC8-4370-4DBB-A031-F11FD16F17B8@qt.io> > On Jan 16, 2017, at 1:26 PM, Marco Bubke wrote: > > +1 > > It fixes many annoying bugs too! > > I would like to use auto for return types if they are returning long types like iterators, tuples, pairs or a mixture of them. > > Something like > > std::pair::const_iterator, bool> findEntry(const std::pair &items, int value) > { > auto found = std::lower_bound(items.begin(), items.end(), value, [] (const SomeClass &entry, int value) { > return entry.someSpecialValue = value; > }); > > return {found, found != items.end()}; > } > > I like to use function to document the code to avoid long hard to read methods and the code is easily unit testable because the method does one thing. The same would be apply to generic templates. Actually our coding rules currently only state that auto is allowed "When assigning iterator types”, but maybe we find a formulation for allowing “unwieldy template constructs” (which iterators is a part of). > From: Qt-creator on behalf of Eike Ziller > Sent: Monday, January 16, 2017 12:48:13 PM > To: qt-creator at qt-project.org > Subject: [Qt-creator] Proposal: Increase requirements for compiling Qt Creator to GCC>=4.9 > > I propose increasing the GCC compiler requirements for compiling Qt Creator, starting with 4.3, to GCC >= 4.9. > https://codereview.qt-project.org/182471 > > This allows us to use parts of C++14, which will most probably not have a huge impact on how we write code, but contains a few goodies in some special areas anyhow. > (http://en.cppreference.com/w/cpp/compiler_support) > > As far as I can see, the main supported platform (in the default configuration) that we will loose when doing this is Ubuntu 14.04 which should be acceptable with 16.04 being the “current” LTS. > > *_t versions of various type traits > —---------------------------- > std::decay_t (instead of “typename std::decay::type”) > std::result_of_t > std::enable_if_t > … > No reason not to use it. > https://codereview.qt-project.org/182060 > > make_unique and make_shared > —---------------------------- > Makes the code shorter and more readable, and has a few smaller benefits. > Afaics no reason not to use it. > > reverse iterators std::(c)rbegin/(c)rend > —---------------------------- > Afaics no reason not to use it. > > (make_)(integer|index)_sequence > —---------------------------- > You probably don’t care, but I do (a little) ;) > https://codereview.qt-project.org/182231 > > decltype(auto) > —---------------------------- > Since we do not allow “auto a = b;” in our coding style, this is probably mostly useful in some situations with templates to avoid writing > auto foo(….) -> decltype(….) > when the return type depends on function arguments. Can be written as > decltype(auto) foo(….) > in the cases where the decltype expression was the expression that is returned. > > https://codereview.qt-project.org/182096 > > auto for normal functions > —---------------------------- > So far our coding style only allows auto for a very limited set of situations: > • when the type is repeated in the same statement > • when the type is some unwieldy template construct (e.g. iterator types), or lambda > • implicitly for the return value of lambdas > > I think we should keep use of auto restricted, and keep the rules as is. The > gain in readability is worth the effort. > > Generalized Lambda Captures > —---------------------------- > [foo = bar + 1]() {…} > Probably not many uses for it, but I also don’t see a reason why not to use it occasionally. > > Generic lambda expressions > —---------------------------- > Allows using “auto” in parameter lists for lambdas: > "[](const auto &name) {…..}” instead of “[](const QString &name) {….}”, > “[](auto kit) {…}” instead of “[](Kit *kit) {…}”. > > I’m not sure about this one. > > It can be useful when actually using it polymorphic, i.e. reuse the lambda for different types, but that is not happening often in our code. > In the “normal” case it can be more concise if the type(s) that are passed to the lambda have long names or are templated. For the template case we can of course apply the usual rule for “auto”. > If the lambda is used as a parameter to some algorithm (anyOf, transform, findOr), the type of the parameter should be pretty clear from context. > In other situations, it is not so clear. > Also the gain, for single-use lambdas and when the type names are not too long, is very small. > > Br, Eike > -- > Eike Ziller > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > eike.ziller at qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > > > > > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From andre.hartmann at iseg-hv.de Mon Jan 16 14:38:50 2017 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Mon, 16 Jan 2017 14:38:50 +0100 Subject: [Qt-creator] =?utf-8?q?Generic_highlighter_f=C3=BCr_Bitbake_*=2E?= =?utf-8?q?inc_files?= In-Reply-To: <1297531484566123@web32j.yandex.ru> References: <91ACD85C-C28C-4B2E-80CD-89736C51FF03@qt.io> <1297531484566123@web32j.yandex.ru> Message-ID: <3376d77d-157c-3e58-775a-5a0483792429@iseg-hv.de> Hi Konstantin, Hi Eike, > Actually, *.inc file extension may correspond to different file types Sure, *.inc is a very generic extension - it was not my idea to name the files this way. > Looks like it conflicts with the highlighter for Doxyfile You're right, disabling the fallback directory for the generic highligher (which was filled with Kate definitions by Ubuntu) solved the problem for me. Thanks for your help and best regards, André Am 16.01.2017 um 12:28 schrieb Konstantin Tokarev: > > > 16.01.2017, 14:11, "Eike Ziller" : >>> On Jan 16, 2017, at 12:06 PM, André Hartmann wrote: >>> >>> I found the bitbake-syntax-highlighter generic highlighter on Github [1] and started to use it for my bitbake receipes with QtCreator. >>> >>> Highlighting of .bb and .bbappend files works well, but .inc files are not highlighted at all. If I edit the XML file and change "*.inc" to "*.bbinc" in the extension list line and rename my file, the highlighting is fine. But that's not what I want to do :) >>> >>> Any ideas on this? >> >> Looks like it conflicts with the highlighter for Doxyfile > > Actually, *.inc file extension may correspond to different file types depending on context, e.g. LLVM project uses this extension for 1) C++ "header" files intended to be included in the middle or at the end of source file, and 2) for TableGen include files. > >> >> Br, Eike >> >>> Best regards, >>> André >>> >>> I have tried QtCreator 3.4 and 4.2. >>> >>> [1] https://github.com/ikoveshnikov/bitbake-syntax-highlighter >>> _______________________________________________ >>> Qt-creator mailing list >>> Qt-creator at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/qt-creator >> >> -- >> Eike Ziller >> Principal Software Engineer >> >> The Qt Company GmbH >> Rudower Chaussee 13 >> D-12489 Berlin >> eike.ziller at qt.io >> http://qt.io >> Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja >> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B >> >> _______________________________________________ >> Qt-creator mailing list >> Qt-creator at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/qt-creator > From david.schulz at qt.io Wed Jan 18 10:55:55 2017 From: david.schulz at qt.io (David Schulz) Date: Wed, 18 Jan 2017 10:55:55 +0100 Subject: [Qt-creator] Introducing the python based cdb dumper Message-ID: Hi all, The local values provided by debuggers contain very basic data, which in most cases isn't helpful at all. We are using dumpers/extensions to convert these data into user friendly information. Python based dumpers have been used for quite a long time now when debugging with GDB. The LLDB engine also dumps values via these dumpers. Both debuggers provide a python interpreter and interface allowing to access debugger internals from python code. In contrast: the CDB engine uses an extension (dll) loaded into the debugger to collect data and dump values. This requires us to maintain two different approaches on dumping values. Unfortunately the CDB doesn't provide a python interface. So, let's introduce one. First step was to lower the barrier for new debuggers using the python dumpers by reducing the interface required by our dumpers to a minimum. Big thanks to Andre to take care of that. Next step was to provide all necessary information from the CDB in a python module that can be accessed by the python dumper, fortunately this task was easier than expected. Final step and currently in process is packaging and delivering the extension with Qt Creator. And here comes the downside: We need to accept a new license (https://docs.python.org/3.5/license.html) when using the python enabled CDB extension. The idea is to have an extra component (selected by default) for the CDB extension when installing Qt Creator on Windows. This way you could still use Qt Creator without accepting the license, but you won't be able to debug with CDB. Any opinions regarding the python license or the dumper topic in general? Whoever want to test the python based dumpers need to define an environment variable PYTHON_INSTALL_DIR that points to a Python 3.5 installation matching the bitness of your Qt before building Qt Creator. The same path needs to be added to the PATH environment variable before executing Qt Creator. Feel free to contact me on any available channel if you encounter any problems. TL;DR: I want to use python in the CDB extension. Debugging with the CDB will require accepting a new license (https://docs.python.org/3.5/license.html). For testing: Define PYTHON_INSTALL_DIR pointing to a python 3.5 installation before building Qt Creator and add python to your PATH before executing Qt Creator. Greetings David From adrozdoff at gmail.com Wed Jan 18 13:02:06 2017 From: adrozdoff at gmail.com (Alexander Drozdov) Date: Wed, 18 Jan 2017 22:02:06 +1000 Subject: [Qt-creator] Show all project files in stocked CMake plugin in Hackers way Message-ID: Hi, Not a question, just a life-hack :-) Changes, that allows showing all project files in project view is discarded . Clarification that Project View is not a Project View but Build System View is added to the documentation. So, now there is no way to propagate CMakeProjectManager2 changes to the upstream at all. But we can still display all files using stock plugin and existing functionality. Just hack it using fake CMAKE_TOOLCHAIN_FILE... *Idea: * - using `file(GLOB_RECURSE ...)` scan project tree for files - create fake target ALL_PROJECT_FILES with this files - put it to the fake toolchain file to avoid modification of the original CMakeLists.txt - pass fake toolchain file to the cmake executable via Kit CMake properties... *Solution:* https://gist.github.com/h4tr3d/0b610a507ed42faeb3c32e2700fabb13#file-qtc-scan-all-cmake Solution allows to configure globbing expression for scanner per build configuration. Via Kit CMake configuration it can be configured per-kit. Look into Gist for complete instruction. *Screen shot:* https://htrd.su/wiki/_media/zhurnal/2017/01/18/qtc-all-files-wa.png It can be extended to allow passing exclude globbing expression. -- WBR, Alexander Drozdov http://htrd.su -------------- next part -------------- An HTML attachment was scrubbed... URL: From imikejackson at gmail.com Wed Jan 18 15:23:24 2017 From: imikejackson at gmail.com (Mike Jackson) Date: Wed, 18 Jan 2017 09:23:24 -0500 Subject: [Qt-creator] 4.3 Beta with CMake Server Integration Feedback (II) Message-ID: <587F7A5C.8060707@gmail.com> Have been trying the nightly builds. Typically I need to delete the CMakeLists.txt.user from my project directory to get a successful configuration. The first time QtCreator tries to run cmake something exits with error code -1. I try the configuration step again and things seem to work. When change the executable to be run through the normal button on the left side I get 3 "versions" of every target, for example, DREAM3D, DREAM3D2,DREAM3D3. I have cmake 3.7.2 installed. This is on OS X 10.10.5 with Xcode 7.2.1 tooling. Thanks for all the hard work on this. It looks like it is coming along nicely and will be a great addition to QtCreator. -- Michael A. Jackson BlueQuartz Software, LLC [e]: mike.jackson at bluequartz.net From b.terrier at gmail.com Wed Jan 18 16:43:40 2017 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Wed, 18 Jan 2017 16:43:40 +0100 Subject: [Qt-creator] How to specify remote directory in Qt Creator using qbs Message-ID: Hi, Is there a way to tell Qt Creator to deploy the exe in a particular folder of a remote Linux device when using qbs? When using qmake this can be done by setting "target.path = /foo/bar". Thanks. BR Benjamin Terrier From Jake.Petroules at qt.io Wed Jan 18 19:03:38 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 18 Jan 2017 18:03:38 +0000 Subject: [Qt-creator] [Qbs] How to specify remote directory in Qt Creator using qbs In-Reply-To: References: Message-ID: Group { fileTagsFilter: product.type // equivalent to fileTagsFilter: ["application"] qbs.installDir: "/foo/bar" } > On Jan 18, 2017, at 7:43 AM, Benjamin TERRIER wrote: > > Hi, > > Is there a way to tell Qt Creator to deploy the exe in a particular folder > of a remote Linux device when using qbs? > > When using qmake this can be done by setting "target.path = /foo/bar". > > Thanks. > > BR > > Benjamin Terrier > _______________________________________________ > Qbs mailing list > Qbs at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From tobias.hunger at gmail.com Wed Jan 18 19:19:56 2017 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Wed, 18 Jan 2017 19:19:56 +0100 Subject: [Qt-creator] 4.3 Beta with CMake Server Integration Feedback (II) In-Reply-To: <587F7A5C.8060707@gmail.com> References: <587F7A5C.8060707@gmail.com> Message-ID: Hi Mike, On Wed, Jan 18, 2017 at 3:23 PM, Mike Jackson wrote: > Have been trying the nightly builds. Typically I need to delete the > CMakeLists.txt.user from my project directory to get a successful > configuration. The first time QtCreator tries to run cmake something exits > with error code -1. The only way the cmake server may exit with error code -1 is that the socket can not get created. I worked on that today, but the patches are still on gerrit. For now you could make sure to delete the socket in the build directory:-) > I try the configuration step again and things seem to > work. When change the executable to be run through the normal button on the > left side I get 3 "versions" of every target, for example, DREAM3D, > DREAM3D2,DREAM3D3. Oh, I did not notice that yet. Can I download that project somewhere so I can try it? Maybe it is something in the CMakeLists.txt. > I have cmake 3.7.2 installed. This is on OS X 10.10.5 with Xcode 7.2.1 > tooling. > > Thanks for all the hard work on this. It looks like it is coming along > nicely and will be a great addition to QtCreator. Thank you for testing and providing feedback! Best Regards, Tobias From imikejackson at gmail.com Wed Jan 18 21:07:43 2017 From: imikejackson at gmail.com (Mike Jackson) Date: Wed, 18 Jan 2017 15:07:43 -0500 Subject: [Qt-creator] 4.3 Beta with CMake Server Integration Feedback (II) In-Reply-To: References: <587F7A5C.8060707@gmail.com> Message-ID: <587FCB0F.5070002@gmail.com> Sure, the project is at http://www.github.com/bluequartzsoftware/dream3d there are dependencies on the following other repositories: http://www.github.com/bluequartzsoftware/CMP http://www.github.com/bluequartzsoftware/SIMPL http://www.github.com/bluequartzsoftware/SIMPLView Those then depend on the following: CMake, Boost, Eigen, HDF5, ITK, Qt5.6, TBB, Qwt. It takes a bit to get everything installed and compiled. We have tried several ways to compile/install all the dependent libraries such as Scripts and a CMake SuperBuild. There always seems to be some tweaking of the scripts to get everything compiled. I just tried configuring with the source code for CMake 3.7.2 and I do not get any duplicate targets. Interesting. Maybe there is something "non-standard" in our use of CMake for the DREAM.3D project. The http://www.github.com/bluequartzsoftware/SIMPL project is our "base" project and can be compiled by itself (but still needing the CMP repo and most of the other dependent libraries. This is a smaller project and there are only a few duplicates and some non-duplicate targets. Let me see if I can track down the issue on our end. Glad to hear about the socket. I'll just make it standard to remove the socket file until the fixes are in. -- Michael A. Jackson 400 S. Pioneer Blvd Owner, President Springboro, Ohio 45066 BlueQuartz Software, LLC EMail: mike.jackson at bluequartz.net Voice: 937-790-1601 Web: http://www.bluequartz.net Fax: 937-746-0783 Tobias Hunger wrote: > Hi Mike, > > On Wed, Jan 18, 2017 at 3:23 PM, Mike Jackson wrote: >> Have been trying the nightly builds. Typically I need to delete the >> CMakeLists.txt.user from my project directory to get a successful >> configuration. The first time QtCreator tries to run cmake something exits >> with error code -1. > > The only way the cmake server may exit with error code -1 is that the > socket can not get created. I worked on that today, but the patches > are still on gerrit. > > For now you could make sure to delete the socket in the build directory:-) > >> I try the configuration step again and things seem to >> work. When change the executable to be run through the normal button on the >> left side I get 3 "versions" of every target, for example, DREAM3D, >> DREAM3D2,DREAM3D3. > > Oh, I did not notice that yet. Can I download that project somewhere > so I can try it? Maybe it is something in the CMakeLists.txt. > >> I have cmake 3.7.2 installed. This is on OS X 10.10.5 with Xcode 7.2.1 >> tooling. >> >> Thanks for all the hard work on this. It looks like it is coming along >> nicely and will be a great addition to QtCreator. > > Thank you for testing and providing feedback! > > Best Regards, > Tobias From mathias at taschenorakel.de Thu Jan 19 08:15:55 2017 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Thu, 19 Jan 2017 08:15:55 +0100 Subject: [Qt-creator] Show all project files in stocked CMake plugin in Hackers way In-Reply-To: References: Message-ID: <7a950efa-e26f-3bb0-beba-f1a82a7fbbff@taschenorakel.de> Interesting hack. How about just using the built-in file system view? Ciao, Mathias Am 18.01.2017 um 13:02 schrieb Alexander Drozdov: > Hi, > > Not a question, just a life-hack :-) > > Changes, that allows showing all project files in project view is > discarded . Clarification > that Project View is not a Project View but Build System View is added > > to the documentation. So, now there is no way to propagate > CMakeProjectManager2 > changes to the upstream at all. > > But we can still display all files using stock plugin and existing > functionality. Just hack it using fake CMAKE_TOOLCHAIN_FILE... > > *Idea: * > - using `file(GLOB_RECURSE ...)` scan project tree for files > - create fake target ALL_PROJECT_FILES with this files > - put it to the fake toolchain file to avoid modification of the > original CMakeLists.txt > - pass fake toolchain file to the cmake executable via Kit CMake > properties... > > *Solution:* > https://gist.github.com/h4tr3d/0b610a507ed42faeb3c32e2700fabb13#file-qtc-scan-all-cmake > > Solution allows to configure globbing expression for scanner per build > configuration. Via Kit CMake configuration it can be configured per-kit. > Look into Gist for complete instruction. > > *Screen shot:* > https://htrd.su/wiki/_media/zhurnal/2017/01/18/qtc-all-files-wa.png > > It can be extended to allow passing exclude globbing expression. > > -- > WBR, Alexander Drozdov > http://htrd.su > > > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator > From b.terrier at gmail.com Thu Jan 19 09:13:40 2017 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Thu, 19 Jan 2017 09:13:40 +0100 Subject: [Qt-creator] [Qbs] How to specify remote directory in Qt Creator using qbs In-Reply-To: References: Message-ID: 2017-01-18 19:03 GMT+01:00 Jake Petroules : > Group { > fileTagsFilter: product.type // equivalent to fileTagsFilter: ["application"] > qbs.installDir: "/foo/bar" > } > This does not seems to work. Qt Creator still copies the binary to "/" on the remote device. From Jake.Petroules at qt.io Thu Jan 19 09:21:18 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 19 Jan 2017 08:21:18 +0000 Subject: [Qt-creator] [Qbs] How to specify remote directory in Qt Creator using qbs In-Reply-To: References: Message-ID: <0A318B84-3380-4B79-BB47-5AB6095A7B90@qt.io> Sorry, I forgot to say you also need qbs.install: true in the Group. So: Group { fileTagsFilter: product.type // equivalent to fileTagsFilter: ["application"] qbs.install: true qbs.installDir: "/foo/bar" } > On Jan 19, 2017, at 12:13 AM, Benjamin TERRIER wrote: > > 2017-01-18 19:03 GMT+01:00 Jake Petroules : >> Group { >> fileTagsFilter: product.type // equivalent to fileTagsFilter: ["application"] >> qbs.installDir: "/foo/bar" >> } >> > > This does not seems to work. Qt Creator still copies the binary to "/" > on the remote device. -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From b.terrier at gmail.com Thu Jan 19 09:35:09 2017 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Thu, 19 Jan 2017 09:35:09 +0100 Subject: [Qt-creator] [Qbs] How to specify remote directory in Qt Creator using qbs In-Reply-To: <0A318B84-3380-4B79-BB47-5AB6095A7B90@qt.io> References: <0A318B84-3380-4B79-BB47-5AB6095A7B90@qt.io> Message-ID: It is already set. I had already Group { fileTagsFilter: product.type qbs.install: true } from Qt Creator project creation wizard. Also I am using qbs 1.6.0 and Qt Creator 4.1.0 2017-01-19 9:21 GMT+01:00 Jake Petroules : > Sorry, I forgot to say you also need qbs.install: true in the Group. So: > > Group { > fileTagsFilter: product.type // equivalent to fileTagsFilter: ["application"] > qbs.install: true > qbs.installDir: "/foo/bar" > } > >> On Jan 19, 2017, at 12:13 AM, Benjamin TERRIER wrote: >> >> 2017-01-18 19:03 GMT+01:00 Jake Petroules : >>> Group { >>> fileTagsFilter: product.type // equivalent to fileTagsFilter: ["application"] >>> qbs.installDir: "/foo/bar" >>> } >>> >> >> This does not seems to work. Qt Creator still copies the binary to "/" >> on the remote device. > > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > From adrozdoff at gmail.com Fri Jan 20 04:09:04 2017 From: adrozdoff at gmail.com (Alexander Drozdov) Date: Fri, 20 Jan 2017 13:09:04 +1000 Subject: [Qt-creator] Show all project files in stocked CMake plugin in Hackers way In-Reply-To: <7a950efa-e26f-3bb0-beba-f1a82a7fbbff@taschenorakel.de> References: <7a950efa-e26f-3bb0-beba-f1a82a7fbbff@taschenorakel.de> Message-ID: Hi, IMHO: *Pros:* 1) Tree view more comfortable for project navigation. File system view not allow it. 2) Right globbing pattern can be used for tree filtering as end-user want. File system view allows only hidden files ignoring. 3) This files will be shown in Locator search using filter "Files in Current Project". "Files in File System" good filter too, but you must strongly known where needed file located. *Cons:* 1) UI freeze on a big projects (LLVM one of them) for a 2-10 sec when cmake completed and project tree rebuilded. 2) Using this solution all files will be passed to the code model too. And it can be broken. https://bugreports.qt.io/browse/QTCREATORBUG-17607 should help (but it should help in most other cases too). 3) File system view simple to keep synchronized with FS using FileSystemWatcher. This solution requires cmake restart. 2017-01-19 17:15 GMT+10:00 Mathias Hasselmann : > Interesting hack. How about just using the built-in file system view? > > Ciao, > Mathias > > Am 18.01.2017 um 13:02 schrieb Alexander Drozdov: > >> Hi, >> >> Not a question, just a life-hack :-) >> >> Changes, that allows showing all project files in project view is >> discarded . Clarification >> that Project View is not a Project View but Build System View is added >> > 183cd0cbd9a559ce7e1018e014bc> >> to the documentation. So, now there is no way to propagate >> CMakeProjectManager2 >> changes to the upstream at all. >> >> But we can still display all files using stock plugin and existing >> functionality. Just hack it using fake CMAKE_TOOLCHAIN_FILE... >> >> *Idea: * >> - using `file(GLOB_RECURSE ...)` scan project tree for files >> - create fake target ALL_PROJECT_FILES with this files >> - put it to the fake toolchain file to avoid modification of the >> original CMakeLists.txt >> - pass fake toolchain file to the cmake executable via Kit CMake >> properties... >> >> *Solution:* >> https://gist.github.com/h4tr3d/0b610a507ed42faeb3c32e2700fab >> b13#file-qtc-scan-all-cmake >> >> Solution allows to configure globbing expression for scanner per build >> configuration. Via Kit CMake configuration it can be configured per-kit. >> Look into Gist for complete instruction. >> >> *Screen shot:* >> https://htrd.su/wiki/_media/zhurnal/2017/01/18/qtc-all-files-wa.png >> >> It can be extended to allow passing exclude globbing expression. >> >> -- >> WBR, Alexander Drozdov >> http://htrd.su >> >> >> _______________________________________________ >> Qt-creator mailing list >> Qt-creator at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/qt-creator >> >> _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator > -- WBR, Alexander Drozdov http://htrd.su -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Mon Jan 30 16:32:04 2017 From: jhihn at gmx.com (Jason H) Date: Mon, 30 Jan 2017 16:32:04 +0100 Subject: [Qt-creator] B&R mobile platform icons could be a little better Message-ID: The iOS and Android icons are a little too close IMHO. It would be nice if there was a higher visual contrast in between them. I'd recommend dropping the device framing all together and just focus on the platform logo. Maybe also use android green for Android and white for iOS? Otherwise maybe change the background color of the device? -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2017-01-30 at 10.27.28 AM.png Type: image/png Size: 5222 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2017-01-30 at 10.27.37 AM.png Type: image/png Size: 5185 bytes Desc: not available URL: