Re: [Development] QtQuick.Layouts and content margins
On 25/02/19 15:57, Mitch Curtis wrote:
> My only issue with it is that I don't know if it will see much use
> outside of your use case. Usually if all items in a layout have the
> same margins, you would just apply those margins to the layout
> managing them instead. While I appreciate that that won't work in
> your case (because the Layout might not be within another, so the
> attached margin properties won't have any effect, and anchor margins
> are not included in its implicit size), I do wonder if there are
> other approaches you could take. What other options have you
> considered?
My immediate issue can be fixed by wrapping the layout into an Item that
aliases its properties and computed the proper implicit size:
==
import QtQuick.Layouts 1.2
import it.mardy.Desktop.private 1.0
Item {
default property alias data: layout.data
implicitWidth: layout.implicitWidth + layout.anchors.leftMargin +...
...
ColumnLayout {
id: layout
anchors {
leftMargin: Style.layoutLeftMargin
topMargin: Style.layoutTopMargin
rightMargin: Style.layoutRightMargin
bottomMargin: Style.layoutBottomMargin
}
spacing: Style.layoutVerticalSpacing
}
}
==
> What about just making the API that provides the style's
> margins available to the user so they can do it themselves?
That might happen as well, but the goal is not to require the user to
know about this class.
> Also, it would be good if you could provide some examples of other
> (more common) use cases that would benefit from this.
Well, having all items inside a layout share the same margins is quite
common. People currently do it with anchors and playing with the
(implicit) size of the parent, but it's not optimal.
The advantage of doing this in the layout items themselves is that there
the problem is reduced to some trivial arithmetic, without the need to
play with parent items.
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"
On Monday February 25 2019 12:24:31 Kevin Funk wrote: > That makes sense in theory. QMake will switch to a different mkspec when you > pass `-spec ...` when building an external project. It's impossible to > instruct CMake to do the same right now, as the mkspec is hardcoded in the > CMake config files of the Qt install. > > Maybe there should be a way to overwrite the mkspec used via a -DQT_MKSPEC > parameter, with the potential drawback of being able to create a broken I'm testing a patch which leaves in the CMAKE_MKSPEC variable (with the current hardcoded setting as a default). So far I haven't noticed any differences but I haven't yet pushed things to the limit. CMake gives the user plenty of opportunity to create a broken configuration; as long as any new option complies with the "garbage in/out" principle there shouldn't be a problem :) > be a potential solution, but again, would require quite a lot of additional > CMake code I'm afraid. Not something I'd envision to maintain for all the > different mkspecs we have. You could consider an approach where you do a reasonable amount of inferring for the foreseeable configurations, and raise an error requiring the user to set the variable explicitly when there's a too big mismatch with the Qt build configuration. No idea if that's better than just using the current hardcoded default with a possibility for manual override. > Yes, that's why this hasn't popped up on the bug tracker so far I think. It's > again an artificial problem: Maybe, but one that can become a real problem anytime. Probably. So maybe my example was too good in a sense (it's been too long since I did any development on MSWin), but what when one of the mkspec headers introduces something that somehow depends on the C++ runtime in use (on Linux; here too I'm not certain if it is officially "not done" but libc++ appears to be mixable with libstdc++ when built against that runtime)? R ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Coin maintenance update
Do you have any records for the qt5 integration history? How many minutes is average? Or what is next step in your plan? For example, let COIN to decide when to pick up an approved qt5 submodule update? I think there is no hope to stage any qt5 changes in work hour, perhaps same in midnight. In same direction of your change, perhaps to limit the qt5 integration numbers in parallel is bit better than the 15 minutes one. —Liang > On 25 Feb 2019, at 13:41, Aapo Keskimölö wrote: > > Dear Developers, > > > It has recently been raised to our attention that some integrations > might be very slow to progress in order to resolve their workitems and > we have found out that this is very likely due to some large multimodule > builds, eg. qt5, keeping the access to resources for itself. > > Since we are not exclusively building the selfish qt5, I have decided to > introduce a new timeout which will cancel integration if its scheduling > takes more than 15 minutes. We are expecting to see some integrations to > be cancelled due to the related change, but hopefully we will also > unblock the scheduler letting rest of the work continue. Let me know if > this makes your life impossible and we will see if we can improve that > situation, somehow. > > > May the forces of CI be with you, > > Aapo > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Maintainers, your action needed: Qt 5.12.2 changes files
Hi all, Please finalize changes files now; It would be really weird to delay the release because of missing changes file... br, Jani From: Development on behalf of Jani Heikkinen Sent: Thursday, February 21, 2019 10:19 AM To: development@qt-project.org Subject: [Development] Maintainers, your action needed: Qt 5.12.2 changes files Hi, Initial ones here: https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.12.2%22,n,z Please take it over, do needed modifications and get '+2' during this week. br, Jani Heikkinen Release Manager ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtQuick.Layouts and content margins
> -Original Message-
> From: Development On Behalf Of
> Alberto Mardegan
> Sent: Monday, 25 February 2019 1:05 PM
> To: development@qt-project.org
> Subject: Re: [Development] QtQuick.Layouts and content margins
>
> On 25/02/19 11:23, Mitch Curtis wrote:
> > So would it look something like this?
> >
> > // implicit size is 118 x 64
> > ColumnLayout {
> > defaultLeftMargin: 12
> > defaultRightMargin: 12
> > defaultBottomMargin: 12
> > defaultTopMargin: 12
> >
> > // implicit size is 100 x 40
> > Button {
> > Layout.leftMargin: 6 // override default
> > }
> > }
>
> Yes. Sounds good? :-)
My only issue with it is that I don't know if it will see much use outside of
your use case. Usually if all items in a layout have the same margins, you
would just apply those margins to the layout managing them instead. While I
appreciate that that won't work in your case (because the Layout might not be
within another, so the attached margin properties won't have any effect, and
anchor margins are not included in its implicit size), I do wonder if there are
other approaches you could take. What other options have you considered? What
about just making the API that provides the style's margins available to the
user so they can do it themselves?
Also, it would be good if you could provide some examples of other (more
common) use cases that would benefit from this.
CCing Jan Arve since he wrote the code.
> Ciao,
> Alberto
>
> --
> http://www.mardy.it - Geek in un lingua international
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Coin maintenance update
Dear Developers, It has recently been raised to our attention that some integrations might be very slow to progress in order to resolve their workitems and we have found out that this is very likely due to some large multimodule builds, eg. qt5, keeping the access to resources for itself. Since we are not exclusively building the selfish qt5, I have decided to introduce a new timeout which will cancel integration if its scheduling takes more than 15 minutes. We are expecting to see some integrations to be cancelled due to the related change, but hopefully we will also unblock the scheduler letting rest of the work continue. Let me know if this makes your life impossible and we will see if we can improve that situation, somehow. May the forces of CI be with you, Aapo ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtQuick.Layouts and content margins
On 25/02/19 11:23, Mitch Curtis wrote:
> So would it look something like this?
>
> // implicit size is 118 x 64
> ColumnLayout {
> defaultLeftMargin: 12
> defaultRightMargin: 12
> defaultBottomMargin: 12
> defaultTopMargin: 12
>
> // implicit size is 100 x 40
> Button {
> Layout.leftMargin: 6 // override default
> }
> }
Yes. Sounds good? :-)
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"
On Monday, 25 February 2019 11:04:31 CET René J.V. Bertin wrote: > On Monday February 25 2019 10:18:01 Kevin Funk wrote: > > Hi, > > >From my quoted message: > > >> Now, I think it's not entirely relevant whether or not this particular > > >> setting is a left-over due to me not trashing the entire Qt build > > >> directory > > >> before rebuilding with clang. The fact is that you should be able to > > >> build > > >> Qt with one compiler and dependent software with another. > > So you confirm that the path indeed depends on the compiler used during the > Qt build Well, yes. That's what currently happens. The mkspec used cannot be altered when using CMake afaics. > (and that my installed copy resulted from rebuilding with clang). > > The question remains though why this path determined at Qt build time and > not at the dependent's build time. > After all you use CMake to build some > dependent instead of Qt itself, and CMake makes it easier to use any > compiler than QMake. That makes sense in theory. QMake will switch to a different mkspec when you pass `-spec ...` when building an external project. It's impossible to instruct CMake to do the same right now, as the mkspec is hardcoded in the CMake config files of the Qt install. Maybe there should be a way to overwrite the mkspec used via a -DQT_MKSPEC parameter, with the potential drawback of being able to create a broken configuration (cf. a MinGW build against a Qt MSVC install; which can't be mixed), but I don't know. Deferring the mkspec from CMAKE_CXX_COMPILER would be a potential solution, but again, would require quite a lot of additional CMake code I'm afraid. Not something I'd envision to maintain for all the different mkspecs we have. So far we haven't had any reports of this issue, and I'd rather leave that for Qt6 times where we need to find a different solution regarding mkspecs when building Qt with CMake anyway. > The differences between GCC and clang tend to be small, but take an MSVC > build of Qt on MSWin, and then build some KDE project with > -DCMAKE_CXX_COMPILER=clang++ ; could be more problematic, no? Yes, that's why this hasn't popped up on the bug tracker so far I think. It's again an artificial problem: - Differences between GCC & Clang are tiny (in fact qplatformdefs.h for both of them are almost similar). - In the example your mention you'd need to use Clang's clang-cl.exe as compiler anyway, which is a drop-in replacement for MSVC's cl.exe and thus should accept anything from win32-msvc/qplatformdefs.h anyway. Regards, Kevin > > R. -- Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Interest] Need help with deprecated QVariant functions
Il 21/02/19 21:09, Christian Ehrlicher ha scritto: >> the two functions qVariantFromValue() and qVariantSetValue() are >> deprecated but the replacements QVariant::setValue() / fromValue() are >> using exactly those two functions... >> Those two functions are some of the last obsolete functions which did >> not yet get decorated with QT_DEPRECATED but since this is affects a >> major class of Qt I don't think it's a task for me. Giuseppe D'Angelo (22 February 2019 21:38) replied: > Could it simply be possible to move the implementation of > qVariantSetValue to QVariant::setValue, and then have the former call > the latter, instead of viceversa? I have filed QTBUG-74043 to track this; feel free to take over as assignee if you've the time to investigate. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"
On Monday February 25 2019 10:18:01 Kevin Funk wrote: Hi, From my quoted message: > >> Now, I think it's not entirely relevant whether or not this particular > >> setting is a left-over due to me not trashing the entire Qt build > >> directory > >> before rebuilding with clang. The fact is that you should be able to > >> build > >> Qt with one compiler and dependent software with another. So you confirm that the path indeed depends on the compiler used during the Qt build (and that my installed copy resulted from rebuilding with clang). The question remains though why this path determined at Qt build time and not at the dependent's build time. After all you use CMake to build some dependent instead of Qt itself, and CMake makes it easier to use any compiler than QMake. The differences between GCC and clang tend to be small, but take an MSVC build of Qt on MSWin, and then build some KDE project with -DCMAKE_CXX_COMPILER=clang++ ; could be more problematic, no? R. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"
On Monday, 25 February 2019 09:56:42 CET René J.V. Bertin wrote:
> Hi,
>
> Trying to get an answer to the question below once more.
> In a nutshell: shouldn't the CMAKE_MKSPEC (or some equivalent) be preserved
> in the installed CMake modules such that the correct mkspec directory is
> added to the compiler's header include search path?
Hey,
The header include path is part of the _qt5_corelib_extra_includes CMake var.
See:
% ag -s mkspecs /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/
/usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfigExtrasMkspecDir.cmake
2:set(_qt5_corelib_extra_includes "${_qt5Core_install_prefix}/lib/x86_64-
linux-gnu/qt5//mkspecs/linux-g++")
That's what you're looking for, right?
If I instead build Qt5 myself using Clang, I end up with this location in the
.cmake file:
% ag -s mkspecs lib/cmake
lib/cmake/install/Qt5Core/Qt5CoreConfigExtrasMkspecDir.cmake
2:set(_qt5_corelib_extra_includes "${_qt5Core_install_prefix}/.//mkspecs/
linux-clang")
Looks all fine to me?
Regards,
Kevin
> Or should that directory be excluded altogether?
>
> R.
>
> ---
> I just noticed something strange in the huge compiler commandlines you tend
> to get while building KDE applications. An application configured to build
> with clang adds qt5/mkspecs/linux-g++-64 to the header include path (with
> -isystem, at that).
>
> At first I thought this was an error in that my Qt install (5.9.7, FWIW) was
> built with GCC but since a release or two I changed to building Qt with
> clang too.
>
> Now, I think it's not entirely relevant whether or not this particular
> setting is a left-over due to me not trashing the entire Qt build directory
> before rebuilding with clang. The fact is that you should be able to build
> Qt with one compiler and dependent software with another.
>
> Am I overlooking an existing way to get the correct mkspec directory added
> to the header search path?
>
> The source for Qt5CoreConfigExtrasMkspecDir.cmake suggests this is set via
> CMAKE_MKSPEC but that variable is no longer referenced in the installed
> cmake modules (again, in Qt 5.9). So even setting this on the commandline
> doesn't have any effect - but CMake should be able to infer at least the
> most common mkspec dirnames from CMAKE_CXX_COMPILER(_ID) ...
>
> Thanks,
> R.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
--
Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] CMake Workshop Summary
Although it seems to have been fixed for ninja : https://gitlab.kitware.com/cmake/cmake/merge_requests/430 On Mon, Feb 25, 2019 at 10:02 AM Jean-Michaël Celerier < jeanmichael.celer...@gmail.com> wrote: > > It is not bad, but it is not great either :-). For example one needs to > _link_ > QtCore before compilation on other things can be started, it is quite > visible > on an under-powered machines, where linking takes time. > > I think that this would still generally be the case with CMake, there are > longstanding issues opened about it : > https://gitlab.kitware.com/cmake/cmake/issues/1 > https://gitlab.kitware.com/cmake/cmake/issues/17528 > > Best, > Jean-Michaël > > > On Mon, Feb 25, 2019 at 9:32 AM Christian Kandeler < > christian.kande...@qt.io> wrote: > >> On Mon, 25 Feb 2019 08:13:29 + >> Jedrzej Nowacki wrote: >> >> > On Friday, February 22, 2019 7:18:36 AM CET Thiago Macieira wrote: >> > > But do note that our parallelism isn't that bad right now. >> > >> > It is not bad, but it is not great either :-). For example one needs to >> _link_ >> > QtCore before compilation on other things can be started, it is quite >> visible >> > on an under-powered machines, where linking takes time. Similar, >> redundant >> > synchronization point is on the module level. >> >> Also, the examples could have per-app granularity and just start building >> as soon as the respective module is ready, >> >> >> Christian >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development >> > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake Workshop Summary
> It is not bad, but it is not great either :-). For example one needs to _link_ QtCore before compilation on other things can be started, it is quite visible on an under-powered machines, where linking takes time. I think that this would still generally be the case with CMake, there are longstanding issues opened about it : https://gitlab.kitware.com/cmake/cmake/issues/1 https://gitlab.kitware.com/cmake/cmake/issues/17528 Best, Jean-Michaël On Mon, Feb 25, 2019 at 9:32 AM Christian Kandeler wrote: > On Mon, 25 Feb 2019 08:13:29 + > Jedrzej Nowacki wrote: > > > On Friday, February 22, 2019 7:18:36 AM CET Thiago Macieira wrote: > > > But do note that our parallelism isn't that bad right now. > > > > It is not bad, but it is not great either :-). For example one needs to > _link_ > > QtCore before compilation on other things can be started, it is quite > visible > > on an under-powered machines, where linking takes time. Similar, > redundant > > synchronization point is on the module level. > > Also, the examples could have per-app granularity and just start building > as soon as the respective module is ready, > > > Christian > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"
Hi, Trying to get an answer to the question below once more. In a nutshell: shouldn't the CMAKE_MKSPEC (or some equivalent) be preserved in the installed CMake modules such that the correct mkspec directory is added to the compiler's header include search path? Or should that directory be excluded altogether? R. --- I just noticed something strange in the huge compiler commandlines you tend to get while building KDE applications. An application configured to build with clang adds qt5/mkspecs/linux-g++-64 to the header include path (with -isystem, at that). At first I thought this was an error in that my Qt install (5.9.7, FWIW) was built with GCC but since a release or two I changed to building Qt with clang too. Now, I think it's not entirely relevant whether or not this particular setting is a left-over due to me not trashing the entire Qt build directory before rebuilding with clang. The fact is that you should be able to build Qt with one compiler and dependent software with another. Am I overlooking an existing way to get the correct mkspec directory added to the header search path? The source for Qt5CoreConfigExtrasMkspecDir.cmake suggests this is set via CMAKE_MKSPEC but that variable is no longer referenced in the installed cmake modules (again, in Qt 5.9). So even setting this on the commandline doesn't have any effect - but CMake should be able to infer at least the most common mkspec dirnames from CMAKE_CXX_COMPILER(_ID) ... Thanks, R. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake Workshop Summary
On Mon, 25 Feb 2019 08:13:29 + Jedrzej Nowacki wrote: > On Friday, February 22, 2019 7:18:36 AM CET Thiago Macieira wrote: > > But do note that our parallelism isn't that bad right now. > > It is not bad, but it is not great either :-). For example one needs to > _link_ > QtCore before compilation on other things can be started, it is quite visible > on an under-powered machines, where linking takes time. Similar, redundant > synchronization point is on the module level. Also, the examples could have per-app granularity and just start building as soon as the respective module is ready, Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtQuick.Layouts and content margins
> -Original Message-
> From: Development On Behalf Of
> Alberto Mardegan
> Sent: Sunday, 24 February 2019 12:29 PM
> To: development@qt-project.org
> Subject: [Development] QtQuick.Layouts and content margins
>
> Hi there!
> I'm working on a desktop style for QtQuick.Controls 2 [1], and I'm currently
> investigating the issue of layouts. My current approach is to define my own
> ColumnLayout element like this:
>
> ==
> import QtQuick.Layouts 1.2
> import it.mardy.Desktop.private 1.0
>
> ColumnLayout {
> anchors {
> leftMargin: Style.layoutLeftMargin
> topMargin: Style.layoutTopMargin
> rightMargin: Style.layoutRightMargin
> bottomMargin: Style.layoutBottomMargin
> }
> spacing: Style.layoutVerticalSpacing } ==
>
> where the Style element is a singleton which retrieves the default layout
> margins encoded in the QStyle.
>
> Now, there's are a couple of problems with this solution: if the user of my
> layout does not set the "anchors.fill" property, but instead positions the
> layout using "x", "y", "width" or "heigh" properties, the margins will be
> ignored.
> The other (bigger) problem is that the implicit size of my layout is
> wrong: it should include the margins!
>
> My proposal is to add a set of "margins" properties to QtQuick.Layout's
> items, which would set the default content margins for all child items that
> don't explicitly set their own via the attached Layout properties.
> These margins would also be taken into account when computing the implicit
> size of the layout.
So would it look something like this?
// implicit size is 118 x 64
ColumnLayout {
defaultLeftMargin: 12
defaultRightMargin: 12
defaultBottomMargin: 12
defaultTopMargin: 12
// implicit size is 100 x 40
Button {
Layout.leftMargin: 6 // override default
}
}
> If this looks like a good idea, I can try and propose a patch.
>
> Ciao,
> Alberto
>
> [1]: https://gitlab.com/mardy/qqc2-desktop
>
> --
> http://www.mardy.it - Geek in un lingua international
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] CMake Workshop Summary
On Friday, February 22, 2019 7:18:36 AM CET Thiago Macieira wrote: > But do note that our parallelism isn't that bad right now. It is not bad, but it is not great either :-). For example one needs to _link_ QtCore before compilation on other things can be started, it is quite visible on an under-powered machines, where linking takes time. Similar, redundant synchronization point is on the module level. Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
