date:20160721

On quinta-feira, 21 de julho de 2016 20:23:19 PDT Oswald Buddenhagen wrote:
> On Thu, Jul 21, 2016 at 09:27:58AM -0700, Thiago Macieira wrote:
> > moc.prf with MSVC now depends on a side feature in qmake to help support
> > generating the moc_predefs.h file. If you're using MSVC, please remember
> > to
> > recompile qmake soon.
> 
> a much better recommendation is "run config.status (or configure -redo
> on windows) *every time* after pulling". this ensures that qmake is

configure -redo on Windows doesn't work at all on a shadow build:

On one run:
Unable to detect the platform from environment. Use -platform command line
argument or set the QMAKESPEC environment variable and run configure again.
See the README file for a list of supported operating systems and compilers.

On another:
Invalid option "win32-icc" for -platform.
See the README file for a list of supported operating systems and compilers

To redo the configuration, I have to use:

cmd \ /c $QTSRCDIR/configure -redo

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Remember to rebuild qmake in dev

On quinta-feira, 21 de julho de 2016 18:02:51 PDT Mitch Curtis wrote:
> It's probably worth pointing out what kind of errors we can expect should we
> forget (so that we can recognise the problem).

The moc_predefs.h file contains qmake's help output, as opposed to a valid C 
source file. Since that file is consumed by moc itself, you're going to get moc 
parsing errors.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

Hello, Everyone and Thiago.

>> SVG icons are not shown at all in static builds of Qt, but png icons are
>> fine (both icons are taken from resorse file). Static and shred Qt 5.6.1
>> build were done with same config settings except of cause "static".

> Remember to force the inclusion of the svg icon plugin into your application.

This seems a valuable advise which worked for me. I finally found how to do 
this, In pro-file add:
QTPLUGIN *= qsvg


Without this svg icons just do not render SILENTLY (in "static").

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Remember to rebuild qmake in dev

2016-07-21 Thread Oswald Buddenhagen

On Thu, Jul 21, 2016 at 09:27:58AM -0700, Thiago Macieira wrote:
> moc.prf with MSVC now depends on a side feature in qmake to help support 
> generating the moc_predefs.h file. If you're using MSVC, please remember to 
> recompile qmake soon.
> 
a much better recommendation is "run config.status (or configure -redo
on windows) *every time* after pulling". this ensures that qmake is
rebuilt, and possible adjustments to the configuration are done.
it takes about half a minute (soon much quicker, as we're about to
finally add chaching), and if nothing actually changes, it won't have
any impact on the subsequent rebuild.

this requirement certainly seems a bit arbitrary, but it's an inevitable
consequence of the qmake bootstrapping.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Remember to rebuild qmake in dev

It's probably worth pointing out what kind of errors we can expect should we 
forget (so that we can recognise the problem).

From: Development  on 
behalf of Thiago Macieira 
Sent: Thursday, 21 July 2016 6:27:58 PM
To: development@qt-project.org
Subject: [Development] Remember to rebuild qmake in dev

Hello

moc.prf with MSVC now depends on a side feature in qmake to help support
generating the moc_predefs.h file. If you're using MSVC, please remember to
recompile qmake soon.

This does not affect GCC (any OS) or the Intel compiler (any OS), as both
support the "dump macros" hidden feature. I have tested Clang but I did not
test clang-cl.

If clang-cl does not support compatibility with cl's -Bx argument, please edit
moc.prf line 34 and submit a patch.
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Remember to rebuild qmake in dev

Hello

moc.prf with MSVC now depends on a side feature in qmake to help support 
generating the moc_predefs.h file. If you're using MSVC, please remember to 
recompile qmake soon.

This does not affect GCC (any OS) or the Intel compiler (any OS), as both 
support the "dump macros" hidden feature. I have tested Clang but I did not 
test clang-cl.  

If clang-cl does not support compatibility with cl's -Bx argument, please edit 
moc.prf line 34 and submit a patch.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QtMultimedia] Still is supported, active?

On quinta-feira, 21 de julho de 2016 17:05:42 PDT Prav wrote:
> But this field is CHANGEBLE! So Fix Version SHOULD NOT BE KNOWN. It is how
> maintainer see planning of it currently.

That is not how we use the bug tracker, as I've explained. The rest of your 
email is not relevant.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QtMultimedia] Still is supported, active?

On quinta-feira, 21 de julho de 2016 10:20:59 PDT Prav wrote:
> Hello, Everyone.
> 
> > Bugs are fixed when they are fixed. You won't get any estimate before the
> > developer actually starts fixing the issue. And even then, it may take
> > months or more until it actually gets fixed.
> 
> Agree but devil is in details. Currently there is a practice to not fill-out
> necessary fields for the bugs and not to change its status. I exactly mean
> * Not changing from Reported to Opened (or Need Info or Closed) ... like it
> is with discussed QTBUG-53019 (1/2 year old) 

Bugs should be triaged, which means they should go to Opened, Need Info or 
Closed in a timely basis. This is a mistake and should be corrected.

> * Not assigning responsible person in Assignee field like it is for ex. with 
> QTBUG-46812 (1 year old) 

Assignee is only important when the bug is being worked on. If no one is 
working on it, Unassigned is fine.

> * Not assigning Fix Version/s ... which can mean there is no plans for the
> bug. No plans can be because of 3 reasons:
> I do not care and going to silently ignore the bug
>   OR
> I agree with the bug but have so many bugs to fix already so that
> this is to far from my 1 month plan (or 3 month plan or 1 year plan ...
> nobody knows what plan is meant) OR
> I except the bug but do not want to bother myself with filling this
> field about my plans

Or, the actual case, which is neither: "Fix version" is assigned when the fix 
is committed to that particular version and the issue moves to Closed. "Fix 
version" is not used for wishes, but for actual fact.

> This is probably means that we need some easy to use query in bug-tracker
> system which can show up "unprocessed bugs" ... which is bugs with state
> Reported
> OR
>   no Assignee
> OR
>   no Fix version
> With sorting from oldest creation date to newest.

Just the first counts as "untriaged".

> If Yoann Lopes will fill the bugs fields why in the world would Denis
> Shienkov ever wrote this letter. Never. Because attitude to the bug will be
> clear to him.

Or, like I've just proven, people can misunderstand intentions and might still 
have complained. If the bug had been accepted (status Opened) but no work done 
in one year, I can bet there would still be complaining now.

> And Denis can only live with this (like trying to fix himself, or hire
> someone or stick to Qt 5.5.1 forever or whatever else)

This option is open to you right now. Why are we spending time discussing the 
issue report attributes instead of fixing the issue?

> I IMHO see Denis Shienkov's personal attacks to Yoann Lopes quite reasonable

Personal attacks ARE NEVER REASONABLE.

I'm going to repeat myself: PERSONAL ATTACKS ARE COMPLETELY UNACCEPTABLE.

You can and should frankly discuss technical issues. You can argue why a 
commit should be different, why a bug deserves a different priority and you 
can argue that someone should dedicate more time to a given task.

However, I don't care how much you may hate someone for any perceived or real 
insult, work or lack of work. YOU NEVER ATTACK PERSONALLY. That's entirely 
unacceptable under the Qt Project governance rules and any governance rules of 
any project I participate in and especially helped create. I only know of one 
notable exception that permits personal attacks and almost everyone I know 
(except the involved ones) think it's a bad idea to permit it.

> And I totally agree that "Bugs are fixed when they are fixed". And agree
> that maintainers need to respect Best Practices of working with
> bug-tracking ALSO (which exactly mean filling out ALL these 3 fields ...
> they ALL are important).

Except that our practice is not to set those fields. The only field that could 
have been set in this particular case is the Status: the bug should have been 
triaged and then transitioned from Reported to Opened.

> Can Qt Product Managers arise the importance of Best Practices of working
> with bugs-tracker for developers?

We already have. I remember discussing this in one of the Contributor Summits. 
It should be in the wiki somewhere.

> Can someone create this query inside bug-tracker system and share it with
> everyone so that unprocessed bugs can be shown?

Everyone can. It's easy with JIRA. Takes a couple of clicks to find all bugs 
that are in Reported state and needs to be triaged. Takes a couple of other 
clicks to find all Open bugs (verified to be issues) and thus any developer can 
take ownership of and start working.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Stack Overflow Documentation

2016-07-21 Thread André Somers




Op 21/07/2016 om 16:35 schreef Sze Howe Koh:

On 21 July 2016 at 19:04, Mitch Curtis  wrote:

Hello.

Stack Overflow Documentation is now in Beta. You can read more about it here:

http://stackoverflow.com/tour/documentation

It is much more accessible than our contribution system, so I see a lot of 
documentation/example contributions going there instead of to Gerrit.

I also wonder if we should consider the popularity (i.e upvotes) of the pages 
there when we decide which examples to create and add to our documentation.

That makes sense to me. Another similar metric is how often a question
gets asked at our forum, although this is a bit hard to count.



I wonder if the licensing is such that the frameworks like Qt can benefit from the 
content by "upstreaming" it into their own documentation.

According to your link, Stack Overflow Documentation contributions are
licensed the same way as regular Stack Overflow, i.e. CC BY-SA 3.0.
We'll need a legal expert's input to be sure, but from what I
understand we can't relicense CC BY-SA 3.0 material under GFDL 1.3...

(Perhaps we can ask Stack Overflow for an exception?)



I'm interested to hear what others think about this.


I still think the removal of the documentation annotation feature that 
was on the online documentation a year or two ago is regrettable 
mistake. Instead of extending the feature by  making it more 
fine-grained, be able to integrate it into documentation viewer. There 
was good content there, and it was discouraging for the members of the 
community who had been contributing to it to see it just being removed 
instead of used.


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QtMultimedia] Still is supported, active?

2016-07-21 Thread Robin Burchell

On Thu, Jul 21, 2016, at 04:05 PM, Prav wrote:
> Agree with you if this field was unchangeable once it was set (nobody
> knows the future exactly ... ).
> But this field is CHANGEBLE! So Fix Version SHOULD NOT BE KNOWN. It is
> how maintainer see planning of it currently.

Looking at my current world of choice: QtQuick (not QML, & not Controls)
currently has - roughly - 385 open bugs. Three maintainers (Shawn &
myself for QtQuick, Gunnar for scenegraph parts) - one of which works on
Qt full time - plus a number of assorted contributors (in and outside
the Qt Company) who all have their own priorities, wants, needs, and
desires.

The very nature of an open source project is that the resources that it
has are unreliable. Outside of the core of people paid to work on it,
there is no predictability about how much effort people are able to put
in, let alone the completely unpredictable nature of software estimates,
which is a widely known problem: I expect you've heard of it before so I
won't go into it. And of the core of people paid to work on it, they
have their priorities set based on a number of different variables:
things they want to work on, things they are paid to work on, feature
work vs bugs (and then: paid customers vs not, etc).

On top of that, many bugs can't be estimated just by looking at the
report. It requires knowledge of the code to find a fix, to understand
possible implications and side-effects, testing, etc. I'm the first
person to tell you that I don't have a clue how long a number of the
bugs filed on QtQuick will take to fix right now, simply because I don't
have an immediate understanding of what the problem actually is.

I've rambled a bit here, but the point that I'm trying to make is: even
if I *wanted* to, I couldn't try plan all 385 of those into something
sensible, even if I was willing to spend all of the time that I spend
looking at code/bugs/reviews on the meta-work that you're proposing
(planning with all of those people) here. And that's just for one small
part of Qt.

Long story short, I don't see that happening. I don't think it's
actually written down or formalised anywhere, but AFAIK, fix version
tends to only be set on bugs that are actually fixed, to indicate which
version the fix is going to land in, or on high priority blockers.

-- 
  Robin Burchell
  ro...@viroteck.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QtMultimedia] Still is supported, active?



> -Original Message-
> From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
> project.org] On Behalf Of Prav
> Sent: Thursday, 21 July 2016 4:06 PM
> To: development@qt-project.org
> Subject: Re: [Development] [QtMultimedia] Still is supported, active?
> 
> Hello, Everyone.
> 
> >> If "Fix Version" is filled by Yoann Lopes 6 months ago then he will
> >> get this estimation and can decide to hire Woboq or someone else to
> >> fix or whatever.
> 
> > This is an unreasonable expectation to place on developers. For
> > blockers (which, as far as I understand, this was not), yes, the fix
> > version is most likely going to be known, but for many bugs, it's
> > extremely difficult to know when they will be fixed. Things happen,
> > priorities change. Also, there are always lots of bugs waiting to be
> fixed. It's a huge product.
> 
> Agree with you if this field was unchangeable once it was set (nobody
> knows the future exactly ... ).
> But this field is CHANGEBLE! So Fix Version SHOULD NOT BE KNOWN. It is how
> maintainer see planning of it currently.

It sure is changeable, and we do change it... when:

1) It's a blocker and it has to be fixed by a certain version.
2) The bug is fixed.

Read this thread:

http://lists.qt-project.org/pipermail/development/2015-November/023847.html

The conclusion from the chief maintainer was:

> I think this makes most sense. The old way where we had a Fix Version set for 
> open bugs is at the minimum confusing to users. Usually it's worse, because 
> it creates false expectations. Setting a Fix Version on an open bug is 
> somewhat of a commitment by us that we will do what we can to get that bug 
> fixed for this version. And that's more the exception than the rule, ie. It 
> makes the bug a showstopper for that release.

Which implies that if anything, we'd create a separate field for estimated fix 
dates, if we ended up doing that at all. Being an estimated fix date, and given 
everything that has already been said so far, this field will never be close to 
accurate enough to be relied upon. This defeats the purpose of it for 
situations where someone actually wants to contribute a fix and is (for some 
reason) relying on it to know whether they can begin working on it, rather than 
just taking action and contacting the responsible developer. And if it's not 
useful in that scenario, when would it be useful?

That is to say, P1s and P0s will (hopefully) always get fixed quickly, but 
anything beyond that depends on a huge factor of things. There's no useful 
estimate that can be given unless the set of bugs is tiny. Even if estimates 
could be given for some specific bugs, there's no guarantee it would be for the 
ones that Denis is interested in, and so you'd still end up with people being 
wished away to hell... and I think we can both agree that hell is not a 
productive working environment.

> If you maintain something you know best about plans. So share your
> estimation! (this field is here for a reason).

Nope, that's not what it's for.

> You know tasks, you visit meetings there plans are discussed, you
> communicate with other who involved ... you know situation with module
> better then others ... so why not share your vision in this simple field?

See above.

> Moreover this field can be used to better support prioritization for
> maintainer plans.

I don't see how this changes anything. The maintainer already has an overview 
over the priority of bugs. As always, people will disagree with that priority, 
and, as always, they'll get told the same things they're being told by others 
in this thread.
 
> Bugs with same priority but lower Fix Version have higher priority. So
> actually beneficial for maintainers too.
> 
> 
> Moreover there are other 2 fields which also need to be set. And not
> filling them give instability for the bug too.
> Do not want instability in feedback ... make bug's state stable. Easy!
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Stack Overflow Documentation

2016-07-21 Thread Sze Howe Koh

On 21 July 2016 at 19:04, Mitch Curtis  wrote:
> Hello.
>
> Stack Overflow Documentation is now in Beta. You can read more about it here:
>
> http://stackoverflow.com/tour/documentation
>
> It is much more accessible than our contribution system, so I see a lot of 
> documentation/example contributions going there instead of to Gerrit.
>
> I also wonder if we should consider the popularity (i.e upvotes) of the pages 
> there when we decide which examples to create and add to our documentation.

That makes sense to me. Another similar metric is how often a question
gets asked at our forum, although this is a bit hard to count.

> I wonder if the licensing is such that the frameworks like Qt can benefit 
> from the content by "upstreaming" it into their own documentation.

According to your link, Stack Overflow Documentation contributions are
licensed the same way as regular Stack Overflow, i.e. CC BY-SA 3.0.
We'll need a legal expert's input to be sure, but from what I
understand we can't relicense CC BY-SA 3.0 material under GFDL 1.3...

(Perhaps we can ask Stack Overflow for an exception?)

> I'm interested to hear what others think about this.

Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QtMultimedia] Still is supported, active?



> -Original Message-
> From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
> project.org] On Behalf Of Prav
> Sent: Thursday, 21 July 2016 1:32 PM
> To: development@qt-project.org
> Subject: Re: [Development] [QtMultimedia] Still is supported, active?
> 
> Hello, Everyone.
> 
> > If you want this bug fixed, or to improve the QtMM quality there are far
> better ways:
> 
> > - Get a Qt support license from the Qt Company and raise the issue to
> > them. They very often help raising important customer issues like this
> > one to P1 since in the end, it's that money that pays Qt Company
> developers.
> > - Try to fix the issue yourself. You already did more than many users
> > by bisecting the issue, thanks for that. But if this issue is really a
> > showstopper like you say, it can't be that Yoan is the only person in
> > the world that can and would be willing to fix it.
> > - Hire somebody to fix the bug. We at Woboq can help fixing nasty
> > issues like those in a very reasonable timeframe, KDAB does so as well.
> 
> Here is also one important detail. If Denis need to decide to hire someone
> he need information about plans of fixing the bug.
> If he need to wait 1/2 year to get estimation that this bug is not going
> to be fixed in nearest months this can make him piss off. Easy imaginable!
> 
> If "Fix Version" is filled by Yoann Lopes 6 months ago then he will get
> this estimation and can decide to hire Woboq or someone else to fix or
> whatever.

This is an unreasonable expectation to place on developers. For blockers 
(which, as far as I understand, this was not), yes, the fix version is most 
likely going to be known, but for many bugs, it's extremely difficult to know 
when they will be fixed. Things happen, priorities change. Also, there are 
always lots of bugs waiting to be fixed. It's a huge product.

The more reasonable approach to this is to contact the maintainer or the 
current assignee and let them know that you're planning on working on it, to 
avoid stepping on each other's toes.

But then again.. we both know that anyone who is *serious* about getting 
something fixed would have taken this approach, right? :) Only those who 
complain (regardless of the facts and realities presented to them) while making 
no attempts to come forward with a solution would consider this an effective 
use of their time.

> Currently he is in "floating"/unstable/non-informative situation. So less
> reasons to act smart and more food for emotional letters.
> If this situation looks fine for maintainers then there is no sense in
> shutting up Denis. What to expect? People cry/insult if it hurts and no
> one listen. So predictable!
> 
> Maintainers need to think about bug-reporters ALSO ... and keep bug-
> reporters in stable state.
> Imagine if for this bug "Fix Version" was filled with "Qt 6.0" then Denis
> Shienkov will get estimation of what waits him. And he can act.
> If for some reasons this estimation will be changed by maintainer to let's
> say 6.5 (or 5.10) then bug-reporter will send email notification to Denis
> about change of attitude to the bug he care about. Easy!
> 
> So IMHO here we have violation of Best Practices of bug-tracking from
> maintainer and emotional angry-letter as the result of 1/2 year influence
> of this violation on bug-reporter. Simple!
> 
> That is why I propose to create query in bug-tracker which will show up
> such violations.
> This is not about fixing bugs ... this is about respecting from
> maintainer's side the bug-tracker fields which need to be filled and which
> influences bug-reporters.
> 
> Just fill 3 fields.
> Done!
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QtMultimedia] Still is supported, active?

Hello, Everyone.

> If you want this bug fixed, or to improve the QtMM quality there are far 
> better ways:

> - Get a Qt support license from the Qt Company and raise the issue
> to them. They very often help raising important customer issues like
> this one to P1 since in the end, it's that money that pays Qt Company 
> developers.
> - Try to fix the issue yourself. You already did more than many
> users by bisecting the issue, thanks for that. But if this issue is
> really a showstopper like you say, it can't be that Yoan is the only
> person in the world that can and would be willing to fix it.
> - Hire somebody to fix the bug. We at Woboq can help fixing nasty
> issues like those in a very reasonable timeframe, KDAB does so as well.

Here is also one important detail. If Denis need to decide to hire someone he 
need information about plans of fixing the bug.
If he need to wait 1/2 year to get estimation that this bug is not going to be 
fixed in nearest months this can make him piss off. Easy imaginable!

If "Fix Version" is filled by Yoann Lopes 6 months ago then he will get this 
estimation and can decide to hire Woboq or someone else to fix or whatever.
Currently he is in "floating"/unstable/non-informative situation. So less 
reasons to act smart and more food for emotional letters.
If this situation looks fine for maintainers then there is no sense in shutting 
up Denis. What to expect? People cry/insult if it hurts and no one listen. So 
predictable!

Maintainers need to think about bug-reporters ALSO ... and keep bug-reporters 
in stable state.
Imagine if for this bug "Fix Version" was filled with "Qt 6.0" then Denis 
Shienkov will get estimation of what waits him. And he can act.
If for some reasons this estimation will be changed by maintainer to let's say 
6.5 (or 5.10) then bug-reporter will send email notification to Denis
about change of attitude to the bug he care about. Easy!

So IMHO here we have violation of Best Practices of bug-tracking from maintainer
and emotional angry-letter as the result of 1/2 year influence of this 
violation on bug-reporter. Simple!

That is why I propose to create query in bug-tracker which will show up such 
violations.
This is not about fixing bugs ... this is about respecting from maintainer’s 
side the bug-tracker fields which need to be filled and which influences 
bug-reporters.

Just fill 3 fields.
Done!

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Ynt: Boot to Qt Device problem.

2016-07-21 Thread Bahadır Can

I can't check if the uboot is too old because board can't boot itself when i 
use flashboot image of Qt. So I can't update uboot from sd card too. It does 
nothing basically.


Also uboot is working at yocto images if it shows it is okay.


Gönderen: Bahadır Can 
Gönderildi: 20 Temmuz 2016 Çarşamba 16:41:49
Kime: development@qt-project.org
Konu: Boot to Qt Device problem.


Hello Qt Developers Team,


I am currently working on a Sabre Automative Board with i.MX6Quad. I just 
started to use Qt Embedded .


I am following this guide :


http://doc.qt.io/QtForDeviceCreation/qtee-preparing-hardware-imx6sabresd.html


I insterted a clean SD card to my device and run the flash boot to Qt Device. 
(with the option Sabre SD i.MX6Quad)


After installation of image finished. I inserted SD card  to Board and 
restarted the board but nothing happened. (Terminal and screen didn't work.)


I also tried it with a beaglebone black but got nothing on it too.


Am I missing any steps?


Thanks from now.


Bahadır

Preparing SABRE SD i.MX6Quad | Qt 5.7 for Device 
Creation
doc.qt.io
Take the following steps to prepare Freescale SABRE SD i.MX6Quad for Boot to 
Qt: Note: It is important that you repeat the steps in this section after you 
update Qt ...



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Stack Overflow Documentation

Hello.

Stack Overflow Documentation is now in Beta. You can read more about it here:

http://stackoverflow.com/tour/documentation

It is much more accessible than our contribution system, so I see a lot of 
documentation/example contributions going there instead of to Gerrit.

I also wonder if we should consider the popularity (i.e upvotes) of the pages 
there when we decide which examples to create and add to our documentation. I 
wonder if the licensing is such that the frameworks like Qt can benefit from 
the content by "upstreaming" it into their own documentation.

I'm interested to hear what others think about this.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QtMultimedia] Still is supported, active?

Hello, Everyone.

>> So while I agree that angriness is not helpful for mail list ... messages 
>> like this
>> are probably the seed to rethink strategy of working with bugs.

> Somewhat a side remark, but the unfortunate consequence of this thinking is
> that the objectively best way to get a lot of Qt developers interested in your
> problem is to write e-mails that breach of etiquette (to put it mildly).

This will NOT ever be a result (unfortunate consequence) of such thinking. And 
this is again about details. Proposed reaction is NOT about fixing Denis's bug.
Proposed improvements probably will not help with exactly this bug ever as this 
is more about maintainer's work.
Because if fixing start to be a result of insulting in emails/mailinglist ... 
then mailinglist became in majority "insulting platform"

Improvement is for making bug-tracking better is sense of giving less reasons 
for bug-reporters in general to ever write such letters.
And as result will be lower insulting ... and NOT like you have said
> "objectively best way to get a lot of Qt developers interested in your 
> problem is to write e-mails that breach of etiquette"
... we always meet this devil in details.


Predictable "unfortunate consequence" of not improving will be more such 
letters (IMHO). Which mean that "objectively best way" (as you have said) to 
react to such letters is
to improve bug-trackering in general ... to give less food to write such 
letters.

Food for this is "floating"/unstable state of reporter which comes from silent 
behaviour of maintainer (bug is unprocessed ... which means necessary fields 
are still blank).
Do NOT make reporter's state unstable and you will never get unstable messages 
from reporter. EASY!


> If Denis would have written a reasonable e-mail asking about the status of Qt
> Multimedia (without insults, attacks, and wishing anyone to hell), we most
> probably won't have this discussion.

> I think Denis should end this e-mail thread by apologizing, and start a new 
> one
> in a reasonable way.

Agree. But his behavior is the result of some objective problems which should 
not be rejected ALSO.

I think this is about of mutual respect. Maintainer have to consider influence 
of keeping silent about bugs as NEGATIVE INFLUENCE on bug-reporter.
And IMHO this influence is not fully understanded by some maintainers ... and 
now we have Denis's letter.

I do not know what can be the best analogy ... probably it is like
when you ask librarian about some missing book you can not find and he/she does 
not answer ... with not NO, not YES ...
zero reaction on you ... just keep doing something he/she was doing ... this 
surely earlier or later will piss you off.
And next event - reaction ... it depends on person. And you gess what ... some 
people will start insulting!
So here we are ... predictable percent of insulting in such cases.


Again IMHO ... in this case probably better to ask both sides to make 1 step 
toward peace.
Yoann Lopes to process the bug (fill the fields ... not fixing it ... fixing is 
up to mainteiners plans which should come from bugs priority) and Denis 
Shienkov to apologies for rudeness.



PS
People with high emotional level can be considered as bad because of negative 
effect of insulting overs.

BUT having such persons inside society helps find problems earlier because they 
are ones who feels problems most painfully because of this high emotionality.
So this feature can be used by society in positive key. And I do not reject 
that insulting practice badly influence society too. Here we simply have 
phenomenon (medal) with two sides


And I agree that probably we can start another thread for discussion of ways to 
improve bug-tracker.
Because this thread has some too negative messages which gives unproductive 
effect for cooperation for improving things.

Let's see if Denis will start the new thread for making bug-tracker better 
place. And I will copy with pleasure my letter about my vision on improvements 
in this thread.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] [Windows] Qt Versions/Kit auto-detection doesn't work on snapshots

Title: Re: [Qt-creator] [Windows] Qt Versions/Kit auto-detection doesn't work on snapshots

Hello, Julius.

I noticed a strange behavior on snapshots for a while now. Neither Qt versions nor kits are detected at all.

With Creator 4.0.x, everything works perfectly (Qt 5.6.1 & Qt 5.7, MinGW and MSVC 2015).

I tried:
● Installing 4.0.83 snapshots to a different location with a new profile
● Installing 4.0.83 snapshots to a different location with an existing profile
● Manually overwriting 4.0.x with an existing profile
● Manually overwriting 4.0.x with a new profile

None of these options resolve the issue. The Qt versions stays empty, although I can use already configured kits in my projects.
Returning back to the stable release makes them return.

What do you mean works perfectly. It is possible to install independent Qt version 4.0.x from QtC-only installer in some separate folder and get any Auto-detection of Qt-kits in its Build & Run settings!?

It never worked for me for every version of QtC. And this is probably because "autodetected" Qt-kits are not autodetected at all ... but they are those that QtC have in settings in QtC's installation folder. This is how I think this "autodetection" is really happening.

Is this a known issue, or even expected? Should I file a bug?

I think this is issue and bug ... but in misleading naming ("Auto-detected") in QtC GUI.
So you have chance to fight for the bug only from this perspective :)

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QtMultimedia] Still is supported, active?

2016-07-21 Thread Jocelyn Turcotte

> On 21 Jul 2016, at 11:01, Denis Shienkov  wrote:
> 
> @ Thiago,
> 
> >The one you linked to is P2 - Important. It's neither critical nor
> showstopper.
> 
> It isn't I did the decision about assigning the P2 status. I personally would 
> establish P0/P1 if it would make sense (but, it is just "empty work" which 
> won't change anything).  
> Since many bugs with P1 statuses still are not considered.
> 
> > It's not critical, according to whoever triaged it.
> 
> If the AVI video playback shows with 0.5-1 FPS then it is not critical for 
> you? Then it is strange for me... o_O
> 
> > Where's your proof?
> 
> My proof - it is a BUG tracker and current QtMM status.
> 
> @ Kai,
> 
> > I think Denis should end this e-mail thread by apologizing, and start a new 
> > one
> in a reasonable way.
> 
> I do not consider myself as the guilty person and I have nothing to apologize.

I think that the bug is important, and I can understand how hard this bug can 
affect the product that you're trying to ship but you can't be angry at Yoan 
personally. If he choses to fix your bug to justify his salary, he will have to 
decide what else NOT to do, which will most likely make somebody else angry. 
It's his decision as to what to fix, and knowing how difficult it is to 
maintain a cross-platform multimedia library I think that you greatly 
underestimate his value as the QtMM maintainer in your message.

The real issue is that QtMM is understaffed, and I can only see one outcome 
resulting from you making him responsible for your user's disappointment: make 
him less motivated to do his job to the point where nobody else wants to work 
on QtMM. Is this what you want?

If you want this bug fixed, or to improve the QtMM quality there are far better 
ways:

- Get a Qt support license from the Qt Company and raise the issue to them. 
They very often help raising important customer issues like this one to P1 
since in the end, it's that money that pays Qt Company developers.
- Try to fix the issue yourself. You already did more than many users by 
bisecting the issue, thanks for that. But if this issue is really a showstopper 
like you say, it can't be that Yoan is the only person in the world that can 
and would be willing to fix it.
- Hire somebody to fix the bug. We at Woboq can help fixing nasty issues like 
those in a very reasonable timeframe, KDAB does so as well.

It can be frustrating relying on somebody else for your own software's quality, 
but open source projects have no responsibilities other than managing a flow of 
efforts toward a common goal. The project itself isn't responsible for fixing 
every issue or regression and there has to be a system of mutual benefit 
(usually ultimately involving money) to make things go forward. Food and coffee 
needs to go in the mouth of developers to produce those patches through key 
presses and mouse clicks, and anger doesn't help growing coffee.

Cheers,

Jocelyn Turcotte
http://woboq.com

> 
> BR,
> Denis
> 
> 
> 
> 
> 2016-07-21 10:41 GMT+03:00 Kai Koehne :
> > -Original Message-
> > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> > [...]
> > So while I agree that angriness is not helpful for mail list ... messages 
> > like this
> > are probably the seed to rethink strategy of working with bugs.
> 
> Somewhat a side remark, but the unfortunate consequence of this thinking is
> that the objectively best way to get a lot of Qt developers interested in your
> problem is to write e-mails that breach of etiquette (to put it mildly).
> 
> If Denis would have written a reasonable e-mail asking about the status of Qt
> Multimedia (without insults, attacks, and wishing anyone to hell), we most
> probably won't have this discussion.
> 
> 
> 
> I think Denis should end this e-mail thread by apologizing, and start a new 
> one
> in a reasonable way.
> 
> Just my 2 cents,
> 
> Kai
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QtMultimedia] Still is supported, active?

2016-07-21 Thread Denis Shienkov

@ Thiago,

>The one you linked to is P2 - Important. It's neither critical nor
showstopper.

It isn't I did the decision about assigning the P2 status. I personally
would establish P0/P1 if it would make sense (but, it is just "empty work"
which won't change anything).
Since many bugs with P1 statuses still are not considered.

> It's not critical, according to whoever triaged it.

If the AVI video playback shows with 0.5-1 FPS then it is not critical for
you? Then it is strange for me... o_O

> Where's your proof?

My proof - it is a BUG tracker and current QtMM status.

@ Kai,

> I think Denis should end this e-mail thread by apologizing, and start a
new one
in a reasonable way.

I do not consider myself as the guilty person and I have nothing to
apologize.

BR,
Denis




2016-07-21 10:41 GMT+03:00 Kai Koehne :

> > -Original Message-
> > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> > [...]
> > So while I agree that angriness is not helpful for mail list ...
> messages like this
> > are probably the seed to rethink strategy of working with bugs.
>
> Somewhat a side remark, but the unfortunate consequence of this thinking is
> that the objectively best way to get a lot of Qt developers interested in
> your
> problem is to write e-mails that breach of etiquette (to put it mildly).
>
> If Denis would have written a reasonable e-mail asking about the status of
> Qt
> Multimedia (without insults, attacks, and wishing anyone to hell), we most
> probably won't have this discussion.
>
>
>
> I think Denis should end this e-mail thread by apologizing, and start a
> new one
> in a reasonable way.
>
> Just my 2 cents,
>
> Kai
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QtMultimedia] Still is supported, active?

2016-07-21 Thread Kai Koehne

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> [...]
> So while I agree that angriness is not helpful for mail list ... messages 
> like this
> are probably the seed to rethink strategy of working with bugs.

Somewhat a side remark, but the unfortunate consequence of this thinking is
that the objectively best way to get a lot of Qt developers interested in your
problem is to write e-mails that breach of etiquette (to put it mildly).

If Denis would have written a reasonable e-mail asking about the status of Qt
Multimedia (without insults, attacks, and wishing anyone to hell), we most
probably won't have this discussion.



I think Denis should end this e-mail thread by apologizing, and start a new one
in a reasonable way.

Just my 2 cents,

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QtMultimedia] Still is supported, active?