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
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
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.
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:
> -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
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.
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
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
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
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
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
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
> 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
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
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
> -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],
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
17 matches
Mail list logo
