Re: [Development] Heads-up: what's new in '6.6' doc needs your updates

[ekke]

would be great to get the recommended Android Target API, NDK and 
openSSL versions if there are changes to 6.5

thx

Am 14.06.23 um 08:52 schrieb Jani Heikkinen via Development:


Hi all,

https://code.qt.io/cgit/qt/qtdoc.git/tree/doc/src/whatsnew/whatsnew66.qdoc 
seems 
to be quite unfinished ☹It would be good to get some more content 
there for Qt 6.6 Beta1 (which is planned to happen during this week). 
So please do at least most important updates now; finalizing and 
polishing can then happen later in beta phase.


br,

Jani

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Commercial LTS Qt 5.15.4 released

[ekke]

I love Qt / QML - always after comparing with React Native or Flutter: 
Qt/QML for me is the best and easiest way to develop
I'm a license holder - fortunately I'm eligible for the 
'SmallBusinessLicense' 
https://www.qt.io/pricing/qt-for-small-business#eligible - this license 
fits perfect into my budget as a single independent mobile app developer 
- thx to Qt making this possible

I understand why Qt is splitting between commercial and OpenSource
I don't understand why 5.15 isn't open for Open Source until Qt 6.2 will 
be delivered containing all the modules from Qt 5


ekke


Am 13.05.21 um 09:25 schrieb Jyrki Yli-Nokari:

The decision will eventually alienate OS community which will force current 
licensees consider the viabilty of the platform for their next generation of 
products. There is a lot of air in the QtC stock price as a result of the new 
licensees and how well Qt/Qml fits the needs. I certainly hope that the 
decision will be reconsidered before any of the big licensees switches to react 
native.
As a Qt and React developer I can say that the entry barrier is high but at 
least Facebook is certainly more predictable platform provider than a single 
Finnish company from strategic infra investment standpoint.

I am not a license holder and am a long time critic of QtC licensing to 
startups.

And I love Qml


Jyrki Yli-Nokari  kirjoitti 13.5.2021 kello 10.22:

The decision will eventually alienate OS community which will force current 
licensees consider the viabilty of the platform for their next generation of 
products. There is a lot of air in the QtC stock price as a result of the new 
licensees and how well Qt/Qml fits the needs. I certainly hope that the 
decision will be reconsidered before any of the big licensees switches to react 
native.
As a Qt and React developer I can say that the entry barrier is high but at 
least Facebook is certainly more predictable platform provider than a single 
Finnish company from strategic infra investment standpoint.

I am not a license holder and am a long time critic of QtC licensing to 
startups.

And I love Qml


André Somers  kirjoitti 12.5.2021 kello 22.22:



On 12-05-2021 17:51, Thiago Macieira wrote:

On Wednesday, 12 May 2021 08:30:52 PDT Frank Hemer wrote:

On Mittwoch, 12. Mai 2021 17:26:50 CEST Thiago Macieira wrote:

Even maintainers who like me don't get access to the source, it's
important
to know the release was made.

Not having access to sources for maintainers is simply ridiculous.

The problem is licensing, not Qt Company's willingness. They offered when this
all began. But since it's not open source, I can't look at it.


When then means that QtC is committing things into modules without that 
modules' maintainer being able to look at it for legal reasons. Ridiculous 
indeed. It would make me question (had I been a maintainer, which I am 
certainly not) if I'd want to keep that hat on at all.

André


___
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 mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Can your module be included in Qt 6?

[ekke]

Am 26.06.20 um 13:49 schrieb Tor Arne Vestbø:



On 26 Jun 2020, at 13:41, ekke  wrote:

I have noticed that Qt for Android will take some time - what about iOS ? Will 
I be able to port iOS Apps to Qt 6 ? Would help to prepare and test mobile apps 
for Qt6 while waiting for Android.

Both Android and iOS support is part of 6.0. The part that’s deferred is the 
Android _extras_, the helper module for more native integration on Android. But 
running a cross platform Qt Quick app should work fine on both platforms.

Tor Arne

aaah - thanks for the info - so I can take the QtSummit Conference App 
as my first candidate :)


then only other apps with the need of Intents etc have to wait. 
hopefully QtBluetooth will come soon to Qt6, because many of my mobile 
business apps need Bluetooth for mobile BarcodeScanners or Printers.


ekke

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

Re: [Development] Can your module be included in Qt 6?

[ekke]

I have noticed that Qt for Android will take some time - what about iOS 
? Will I be able to port iOS Apps to Qt 6 ? Would help to prepare and 
test mobile apps for Qt6 while waiting for Android.


hopefully Android and Bluetooth / Location / Positioning won't take too 
much time to find their way into Qt 6 ;-)


ekke

Am 26.06.20 um 11:53 schrieb Lars Knoll:

Hi all,

We’re now closing in on our checkpoint for the structure/platform 
freeze for Qt 6.0. This means we will start nailing down the final 
list of modules and platforms that will be part of Qt 6.0 (or released 
together with 6.0) during next week.


In case you maintain a module in Qt, please have a final look 
https://wiki.qt.io/Checklist_for_Qt_6.0_inclusion 
<https://wiki.qt.io/Checklist_for_Qt_6.0_inclusion> and ensure the 
data for your module is up to date. If it is not marked as ready there 
by Monday, it won’t be part of Qt 6.0 and will have to wait for 6.1 
before the module can get included.


As you can see, the scope of 6.0 will be reduced compared to 5.15. 
This is a similar approach to what we did with 5.0, where we also 
tried to focus on the essential modules first and added other 
functionality a bit later again.


Cheers,
Lars


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

Re: [Development] Qt Multimedia as Add-on in Qt 6

[ekke]

esp Camera is essential for mobile apps
but if it's integrated smooth into the Installer and I have only  to 
check one additional checkbox then it would be ok for me to get it from 
the marketplace


Am 22.05.20 um 16:16 schrieb Jason H:

Will this have repercussions in the Maintenance tool?
I don't really think that calling Multimedia an "add on" is a reflection of 
reality, post 1994.
For mobile kits (iOS, Android) these are essential features. Sorry, Qt just can't get 
away with drawing rectangles and text in 2020. I fear this is more maligning of mobile by 
Lars. I think this will result in providing a lower tier of service than compared to the 
"essentials".

I object, and wish multimedia to remain an essential part of Qt.






Sent: Friday, May 22, 2020 at 3:47 AM
From: "Lars Knoll" 
To: "Giuseppe D'Angelo" 
Cc: "Qt development mailing list" 
Subject: Re: [Development] Qt Multimedia as Add-on in Qt 6

Hi,


On 21 May 2020, at 18:08, Giuseppe D'Angelo via Development 
 wrote:

Hi,

Il 21/05/20 11:38, Val Doroshchuk ha scritto:

The license is not changed, plans just to not ship QtMultimedia with Qt 
essentials,
can be installed separately. Possibly we also support only a limited set of 
platforms.
Qt Essentials must work on every platform, according to the definition of 
essentials.

While of course it's up to each module maintainer to decide on its status (and thus, if QtMM 
doesn't qualify for "Essentials" any more, can become an "Addon"), I'm left 
wondering why does this imply being moved to the Marketplace, out of Qt itself?


* Is this part of a broader plan, aiming at streamlining the Qt offer to just 
mean Essentials, while the Addons get moved to the marketplace?

This is something I’ve been at least mentioning at the Contributor Summit 
already. Distributing it through the market place is mainly a different means 
of packaging it and decoupling the release schedules. A user should still be 
able to discover and install Qt MM (or other add-ons delivered through the 
market place) in the installer, just as today.

But yes, this goes then towards streamlining Qt 6 a bit. Reducing the set of 
things that you have to install, and making more modules optional.

("Qt offer" is of course inaccurate, given the many offers available, but you 
get my drift...).


* If so, are all the practical issues for such addons sorted out? First few 
things that come to mind:

1) Version numbering scheme, release schedule

This needs some sorting out, I agree.


2) CI testing / platform coverage

That should be ok for now, although if an add-on targets several Qt versions at 
once, we don’t yet have a good mechanism to deal with that in CI.


3) Compatibility promise (own API/ABI stability, which Qt versions it works 
with, etc.)

I think it will be good to give add-ons a bit more flexibility there how to 
handle it. This is because different add-ons have rather different 
requirements, that we’ve so long all tried to shoehorn into the Qt release 
process. Compare for example WebEngine that needs frequent updates due to new 
Chromium releases with e.g. Qt SVG that only receives a very limited amount of 
bug fixes.


4) Where to put the docs, release notes, etc.

Into the package and on the web site as usual.


* What about the KDE/Qt agreement? Are the list of Essential and Addon modules being 
re-evaluated there as well? QtMM is not really at liberty of changing license because 
it's an "Essential" (in the agreement).

There’s the agreements legal term, and the status in terms of the agreement is 
something we can’t change without agreement from the board of the KDE Free Qt 
Foundation.

When the new agreement was done some years ago, we tried to align terms with 
what we had in Qt Project at that time. But things do change and I believe we 
can change what we see as essential and add-on in terms of the project (and in 
the commercial packages) independently of the agreement.

This is confusing to some extent as the legal agreement uses the same terms as 
we’re using, but the terms are defined in the agreement itself, and limited to 
the scope of the agreement. They don’t dictate how we package or name things in 
our releases (as long as the conditions set forth in the agreement are 
fulfilled).

The main thing the agreement mandates is the licensing of add-on and essential 
modules. But the only real difference between add-ons and essentials (as 
defined in the agreement) are that essentials have to be LGPLv3, while *new* 
add-ons can be GPLv3. We can’t change licensing of currently supported modules 
without agreement from the foundation in neither case. We also can’t reduce the 
scope of the agreement, so Qt Multimedia will be part of that agreement no 
matter how we package and deliver it to our users.

Cheers,
Lars

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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[ekke]

I'm using QList in many cases, per ex:
C++:
  QList myList();

QML:
  ListView { ... model: xxx.myList()

C++
  QVector myList();

getting Error from QML ListView: Unknown method return type: 
QVector


(tested with Qt 5.13.2)

perhaps I misunderstood something or will QML in Qt6 have no problems 
with QVector(QObject*) ?


ekke

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

Re: [Development] Changes to Qt offering

[ekke]

Am 29.01.20 um 09:57 schrieb Cristián Maureira-Fredes:


I really want to believe that the new startup price is the beginning
of having ad-hoc pricing for everyone, and hopefully in the future
we can also see "medium-size company prices" or
"freelancer developer licenses", but such decisions cannot be made
at the same time.

Once the new startup pricing is out, the company will analyze if it was
a good move, and evaluate special future offerings,


the new pricing will only fit to very very small business or single 
developers, so I imagine that there won't be so many licenses sold. 
analyzing this one year later could give the answer "it doesn't work - 
let us stop it".


would be much better to change the limitations (increase max revenue) to 
get a larger amount of new devs using this


also it would be a good idea to have license prices for medium sized 
businesses, so everyone starting with small-biz-license knows what to 
pay if he/she has success and grows with Qt.


I know some features are missing, but over all Qt is such a great 
platform for mobile apps. Since QQC2 you can create cool and performant 
mobile apps. (Looking forward to Qt6/QML3 where all is compiled to C++)


I'm speaking on dev conferences, demonstrating apps at conferences and 
customers, writing articles for magazines. Licensing costs always was 
the barrier for other devs to jump on Qt. Now with $499/year it's much 
better to argument against usw of Xamarin, Flutter, ReactNative


Hope TQC will adjust definition of small business and also provide 
license for medium business.


--

ekke (ekkehard gentz)

independent software architect
international development native mobile business apps
Qt Mobile: Android, iOS, W10 (former projects: BlackBerry 10)
workshops - trainings - app development

*Qt Champion
BlackBerry Elite Developer
*
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:e...@ekkes-corner.org
my blog: http://ekkes-corner.org
app development blog: http://appbus.org

twitter: @ekkescorner
LinkedIn: http://linkedin.com/in/ekkehard/
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490

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

Re: [Development] Changes to Qt offering

[ekke]

Am 28.01.20 um 11:14 schrieb coroberti .:

On Tue, Jan 28, 2020 at 11:55 AM Konstantin Shegunov
 wrote:




The third change is that The Qt Company will in the future also offer a lower 
priced product for small businesses. That small business product is btw not 
limited to mobile like the one Digia had some years ago, but covers all of Qt 
for Device Creation.


I see a couple of issues here. Firstly, 100k/year *turnover* isn't a small 
business, that's a nano-company (i.e. 1-2 devs max) and if they're providing a 
device alongside the software that 100k is going to be eaten in no time. Notice 
we are not talking profit here, but raw revenue. Whoever from sales came up 
with that number, really did a botched up job with it. On that note, even if we 
accept that it's applicable, the straightforward math shows you want to bill 
0.5% - 2.5% of the total turnover, so while this sounds good initially it 
really isn't that shiny when you crunch the numbers. That offering is stillborn 
from my point of view.

Agree with Konstantin that the definition of a small business isn't realistic.
The realistic one is up to 5 developers and up 500k/year USD sales.

...

So, hello, Qt-company, and consider to make something really friendly
for small businesses ...


+1 Konstantin and coroberti

I'm only a single mobile app developer and for me it is ok with 100k and 
$499/year


but I know many developers from small businesses (2-5 devs) and it's 
really not realistic to think they have less 100k sales total per year ;-)


coroberti's idea (up 500k sales per year) covers the target (StartUp, 
Small Business) much better and is something making it easier to 
motivate mobile app devs to use Qt instead of Flutter, Xamarin, React or so.


please rethink your definition of StartUp / SmallBusiness to make this 
license a success for Qt


ekke

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

Re: [Development] Changes to Qt offering

[ekke]

Am 27.01.20 um 15:34 schrieb Lars Knoll:

...

The third change is that The Qt Company will in the future also offer a lower 
priced product for small businesses. That small business product is btw not 
limited to mobile like the one Digia had some years ago, but covers all of Qt 
for Device Creation.


sounds great

would this per ex enable mobile apps to integrate MQTT ?

ciao

ekke

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

Re: [Development] QTCS2019 Notes from QtQml session

[ekke]

thanks Elvis, Filippo, Ulf,

now I know what to do the next months to make my apps QML3 - ready ;-)

yes - then my code will be better re-usable and cleaner as now

will blog about all those refactorings

ciao

ekke

Am 26.11.19 um 09:20 schrieb Elvis Stansvik:
> Den mån 25 nov. 2019 kl 22:08 skrev Filippo Cucchetto
> :
>> @Ekke
>> I think you should redesign your qml the other way around. For your problem 
>> there're multiple solutions
>> 1) Use some sort of StackView.view attached property. This is *usually* 
>> implemented with a simple upward hierarchy lookup of the first instance of a 
>> StackView.
>> In this way you get the reference of the StackView from leaf nodes.
>> 2) Pass a StackView reference  to the Page at the point of instantiation
>> Page1 {
>>id: page1
>>view: stackView // used inside Page implementation
>> }
>> 3) JUST DO THE RIGHT THING. Your page qml should not have code that directly 
>> calls the the StackView (This couples the Page to know that there's a 
>> StackView).
>> Instead your page should just expose signals or items. The wiring between 
>> these signals and view is done outside.
>> For example instead of:
>>
>> // Page1,qml
>> Item {
>>   Button { onClicked: stackView.doSomething() }  // Reference StackView by 
>> id..magically...awful!!
>> }
>>
>> Do like this
>> // Page1.qml
>> Item {
>>   property alias loginButton: button
>>   Button { id: button }
>> }
>>
>> // Somewhere.qml
>>
>> Page1 {
>>loginButton.onClicked: stackview.doSomething() // Logic outside view
>> }
> I agree. An analog to this in Qt/C++ land would be doing something like
>
> auto foo = static_cast(parent());
> // Use foo
>
> in a child widget, which is certainly a code smell (making assumptions
> about the context).
>
> The changes suggested would hurt our code base a little, because I
> know we're guilty of this transgression in some places of our QML as
> well. But I think it's worth it and the changes needed would improve
> our code.
>
> Just my 2 cents.
>
> Elvis
>
>> This solution allows Page1 to be just a view (like an old .ui file).
>> In other words Page1 interface implies that there's a button or  a clicked 
>> signal but you're free to connect its
>> clicked signal to a StackView or SwipeView since wiring is done outside it.
>>
>> A even better solution is to delegate this to a FSM
>>
>> Page1 {
>>   loginButton.onClicked: fsm.login()
>> }
>>
>> And then use a state of the FSM for handling the current page of the 
>> StackView
>>
>> StackView {
>>   currentPageComponent: {
>>   if (fsm.loginState.active) {
>>return loginPageComponent
>>   } else if (fsm.connectedState.active) {
>>   return connectedState.Compononent
>>  }
>>   }
>> }
>>
>> Best regards,
>>
>> Filippo
>>
>>
>> Il giorno lun 25 nov 2019 alle ore 16:54 ekke  ha 
>> scritto:
>>> Am 25.11.19 um 15:53 schrieb Ulf Hermann:
>>>>> Yeah, that's going to make using QML in actual applications a whole lot
>>>>> harder. For instance, sometimes access to some root node is needed even
>>>>> from deep leaf files. Removing that capability is quite a drastic measure.
>>>> Yes, but the problems with this construct are the same as with generic
>>>> context properties: Your QML component requires some context that it
>>>> doesn't declare. Therefore your code is not reusable and brittle wrt
>>>> addition of properties in other places.
>>> h :(
>>>
>>> because of my own project rules my code is re-usable through all my projects
>>>
>>> from discussions here I learned to use SingletonInstance which can
>>> replace the properties I set in my root (main.qml)
>>>
>>> but there are many other situations where I thinkl this won't help
>>>
>>> per ex
>>>
>>> main.qml --> StackView --> Page1 --> Page2 --> Popup
>>>
>>> from main there are some StackViews (+ Pages) switchedby Drawer
>>>
>>> Page1 or Page2 can be used on top of different StackViews
>>>
>>> there are some properties and functions from StackView used by Pages or
>>> Popup. Can access them via id because all my StackViews have same id
>>>
>>> any idea how this should be refactored for QML 3 without loosing all the
>>> cool flexibility ?
>>>
>>>> Mind th

Re: [Development] QTCS2019 Notes from QtQml session

[ekke]

Am 25.11.19 um 15:53 schrieb Ulf Hermann:
>> Yeah, that's going to make using QML in actual applications a whole lot 
>> harder. For instance, sometimes access to some root node is needed even 
>> from deep leaf files. Removing that capability is quite a drastic measure.
> Yes, but the problems with this construct are the same as with generic 
> context properties: Your QML component requires some context that it 
> doesn't declare. Therefore your code is not reusable and brittle wrt 
> addition of properties in other places.

h :(

because of my own project rules my code is re-usable through all my projects

from discussions here I learned to use SingletonInstance which can
replace the properties I set in my root (main.qml)

but there are many other situations where I thinkl this won't help

per ex

main.qml --> StackView --> Page1 --> Page2 --> Popup

from main there are some StackViews (+ Pages) switchedby Drawer

Page1 or Page2 can be used on top of different StackViews

there are some properties and functions from StackView used by Pages or
Popup. Can access them via id because all my StackViews have same id

any idea how this should be refactored for QML 3 without loosing all the
cool flexibility ?

>
> Mind that all those dynamic lookups will still live on in QML 2, and we 
> will maintain QML 2 throughout Qt6. They just won't be valid in QML 3.

of course my goal is to go to QML 3

ekke

>
> Ulf
> ___
> 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] Qt 5.12.1 released

[ekke]

Am 01.02.19 um 11:23 schrieb Jani Heikkinen:
> Hi,
>
> Qt 5.12.1 is released today. See more info from blog post: 
> http://blog.qt.io/blog/2019/02/01/qt-5-12-1-released/
cool :)
>
> Big thanks to everyone involved!

+1

ekke

>
> 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] HEADS-UP: Branching from '5.12' to '5.12.1' started

[ekke]

Hi,

great to hear :)

wish you luck !

will try the RC-snapshot this evening

ciao
ekke

Am 29.01.19 um 11:32 schrieb Jani Heikkinen:
> Hi,
>
> We have "RC" packages under testing. So far all seems to be pretty much OK so 
> if nothing new & serious enough found we should be able to get the release 
> out during this week. Let's keep our fingers crossed.
>
> br,
> Jani
>
> btw, there is Qt 5.12.1 "RC" snapshot available via online installer if you 
> want to take a tour. It is almost what we expect to release; only couple of 
> changes is in after that one
>
> ____
> From: Development  on behalf of ekke 
> 
> Sent: Tuesday, January 29, 2019 12:24 PM
> To: development@qt-project.org
> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1'  
> started
>
> Am 23.01.19 um 17:03 schrieb Kai Koehne:
>>> -Original Message-
>>> From: Development  On Behalf Of ekke
>>> Sent: Wednesday, January 23, 2019 9:45 AM
>>> To: development@qt-project.org
>>> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' 
>>> started
>>>
>>> seems this time it's a rocky path to release Qt 5.12.1
>> We're still struggling with a change in configure that made system library 
>> paths absolute - good for local installations, but problematic for the 
>> binary packages, which are supposed to work in different setups:
>>
>>  https://bugreports.qt.io/browse/QTBUG-72903
>>
>> Kai
>>
> what do you think - is there a chance to get Qt 5.12.1 this week ?
>
> thx
>
> ekke
>
> ___
> 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] HEADS-UP: Branching from '5.12' to '5.12.1' started

[ekke]

Am 23.01.19 um 17:03 schrieb Kai Koehne:
>> -Original Message-
>> From: Development  On Behalf Of ekke
>> Sent: Wednesday, January 23, 2019 9:45 AM
>> To: development@qt-project.org
>> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' 
>> started
>>
>> seems this time it's a rocky path to release Qt 5.12.1
> We're still struggling with a change in configure that made system library 
> paths absolute - good for local installations, but problematic for the binary 
> packages, which are supposed to work in different setups:
>
>  https://bugreports.qt.io/browse/QTBUG-72903
>
> Kai
>
what do you think - is there a chance to get Qt 5.12.1 this week ?

thx

ekke

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

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

[ekke]

Am 23.01.19 um 17:03 schrieb Kai Koehne:
>> -Original Message-
>> From: Development  On Behalf Of ekke
>> Sent: Wednesday, January 23, 2019 9:45 AM
>> To: development@qt-project.org
>> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' 
>> started
>>
>> seems this time it's a rocky path to release Qt 5.12.1
> We're still struggling with a change in configure that made system library 
> paths absolute - good for local installations, but problematic for the binary 
> packages, which are supposed to work in different setups:
>
>  https://bugreports.qt.io/browse/QTBUG-72903
>
> Kai
>
I'm waiting for 5.12.1 because 5.12 is blocked on Android because of
https://bugreports.qt.io/browse/QTBUG-72101


wish you luck to figure out the correct configure to be able to release
5.12.1

thx for your hard work

ekke

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

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

[ekke]

seems this time it's a rocky path to release Qt 5.12.1

Am 08.01.19 um 08:32 schrieb Jani Heikkinen:
> Hi all,
>
> Branching from '5.12' -> '5.12.1' is finally (almost) done; qtbase and 
> qttools is  still ongoing, there were some conflicts and so on manual merge + 
> normal integration is needed there. Work is ongoing and should be ready 
> today. 
>
> So from now on '5.12.1' is for soon coming Qt 5.12.1 release and staging 
> there is restricted to release team only. And '5.12' is for Qt 5.12.2.
>
> Target is to get Qt 5.12.1 out as soon as possible. We will create initial 
> changes files soon so please finalize those immediately to be able to proceed 
> with the release. Release blocker list here: 
> https://bugreports.qt.io/issues/?filter=20430 Please make sure all release 
> blockers are visible in the list!
>
> We will release first snapshot for Qt 5.12.1 during this week as well
>
> br,
> Jani
> 
> From: Development  on behalf of Jani 
> Heikkinen 
> Sent: Monday, January 7, 2019 7:37 AM
> To: Aleksey Kontsevich; ekke; developm...@lists.qt-project.org
> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to   '5.12.1'  
>   started
>
>> -Original Message-
>> From: Development  On Behalf Of
>> Aleksey Kontsevich
>> Sent: lauantai 5. tammikuuta 2019 12.23
>> To: ekke ; developm...@lists.qt-project.org
>> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1'
>> started
>>
>> Hi,
>>
>> What about QTBUG-72687 and QTBUG-72227?
>>
> QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry.
>
> br,
> Jani
> ___
> 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 mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] HEADS-UP: Branching from '5.12' to '5.12.1' started

[ekke]

noticed that the list of blocker issues for Qt 5.12.1 is reduced to only
2 open issues

so hopefully we can expect Qt 5.12.1 next days

thanx
ekke
Am 14.01.19 um 13:20 schrieb Tuukka Turunen:
> Hi,
>
> Some release blocker bugs have been found in the testing, so we'll need a few 
> fixes before the release.
>
> For more details, see: https://bugreports.qt.io/issues/?filter=20430 
>
> Yours,
>
>   Tuukka
>
> On 14/01/2019, 12.59, "Development on behalf of ekke" 
>  wrote:
>
> Hi,
> are there any news abolut Qt 5.12.1 release ?
> 
> thanx
> 
> ekke
> 
> Am 09.01.19 um 09:56 schrieb Liang Qi:
> > qtbase and qttools final down merges are done,
> >
> > https://codereview.qt-project.org/#/c/249324/
> > https://codereview.qt-project.org/#/c/249362/
> >
> > And also qt5 5.12->5.12.1 final down merge is done,
> >
> > https://codereview.qt-project.org/#/c/249362/
> >
> > —Liang
> >
> >> On 8 Jan 2019, at 08:32, Jani Heikkinen  wrote:
> >>
> >> Hi all,
> >>
> >> Branching from '5.12' -> '5.12.1' is finally (almost) done; qtbase and 
> qttools is  still ongoing, there were some conflicts and so on manual merge + 
> normal integration is needed there. Work is ongoing and should be ready 
> today. 
> >>
> >> So from now on '5.12.1' is for soon coming Qt 5.12.1 release and 
> staging there is restricted to release team only. And '5.12' is for Qt 5.12.2.
> >>
> >> Target is to get Qt 5.12.1 out as soon as possible. We will create 
> initial changes files soon so please finalize those immediately to be able to 
> proceed with the release. Release blocker list here: 
> https://bugreports.qt.io/issues/?filter=20430 Please make sure all release 
> blockers are visible in the list!
> >>
> >> We will release first snapshot for Qt 5.12.1 during this week as well
> >>
> >> br,
> >> Jani
> >> 
> >> From: Development  on behalf of 
> Jani Heikkinen 
> >> Sent: Monday, January 7, 2019 7:37 AM
> >> To: Aleksey Kontsevich; ekke; developm...@lists.qt-project.org
> >> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to   
> '5.12.1'started
> >>
> 
> ___
> 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] [Releasing] HEADS-UP: Branching from '5.12' to '5.12.1' started

[ekke]

Am 14.01.19 um 15:03 schrieb Fabrice Mousset | GEOCEPT GmbH:
> Hi,
>
> I can't see issues with given link 
> (https://bugreports.qt.io/issues/?filter=20430)
> I always got this error: " A value with ID '11040' does not exist for the 
> field 'project'."
remove the ,11040 from search string and it works ;-)
>
> Regards
>
> Fabrice
>
> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von ekke
> Gesendet: Montag, 14. Januar 2019 14:26
> An: development@qt-project.org
> Betreff: Re: [Development] [Releasing] HEADS-UP: Branching from '5.12' to 
> '5.12.1' started
>
> Am 14.01.19 um 13:20 schrieb Tuukka Turunen:
>> Hi,
>>
>> Some release blocker bugs have been found in the testing, so we'll need a 
>> few fixes before the release.
> so fingers crossed to get it out soon
>
> ekke
>
>> For more details, see: https://bugreports.qt.io/issues/?filter=20430 
>>
>> Yours,
>>
>>  Tuukka
>>
>> On 14/01/2019, 12.59, "Development on behalf of ekke" 
>>  
>> wrote:
>>
>> Hi,
>> are there any news abolut Qt 5.12.1 release ?
>> 
>> thanx
>> 
>> ekke
>> 
>> Am 09.01.19 um 09:56 schrieb Liang Qi:
>> > qtbase and qttools final down merges are done,
>> >
>> > https://codereview.qt-project.org/#/c/249324/
>> > https://codereview.qt-project.org/#/c/249362/
>> >
>> > And also qt5 5.12->5.12.1 final down merge is done,
>> >
>> > https://codereview.qt-project.org/#/c/249362/
>> >
>> > —Liang
>> >
>> >> On 8 Jan 2019, at 08:32, Jani Heikkinen  wrote:
>> >>
>> >> Hi all,
>> >>
>> >> Branching from '5.12' -> '5.12.1' is finally (almost) done; qtbase 
>> and qttools is  still ongoing, there were some conflicts and so on manual 
>> merge + normal integration is needed there. Work is ongoing and should be 
>> ready today. 
>> >>
>> >> So from now on '5.12.1' is for soon coming Qt 5.12.1 release and 
>> staging there is restricted to release team only. And '5.12' is for Qt 
>> 5.12.2.
>> >>
>> >> Target is to get Qt 5.12.1 out as soon as possible. We will create 
>> initial changes files soon so please finalize those immediately to be able 
>> to proceed with the release. Release blocker list here: 
>> https://bugreports.qt.io/issues/?filter=20430 Please make sure all release 
>> blockers are visible in the list!
>> >>
>> >> We will release first snapshot for Qt 5.12.1 during this week as well
>> >>
>> >> br,
>> >> Jani
>> >> 
>> >> From: Development  on behalf of 
>> Jani Heikkinen 
>> >> Sent: Monday, January 7, 2019 7:37 AM
>> >> To: Aleksey Kontsevich; ekke; developm...@lists.qt-project.org
>> >> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to   
>> '5.12.1'started
>> >>
>> 
>> ___
>> 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 mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] HEADS-UP: Branching from '5.12' to '5.12.1' started

[ekke]

Am 14.01.19 um 13:20 schrieb Tuukka Turunen:
> Hi,
>
> Some release blocker bugs have been found in the testing, so we'll need a few 
> fixes before the release.

so fingers crossed to get it out soon

ekke

>
> For more details, see: https://bugreports.qt.io/issues/?filter=20430 
>
> Yours,
>
>   Tuukka
>
> On 14/01/2019, 12.59, "Development on behalf of ekke" 
>  wrote:
>
> Hi,
> are there any news abolut Qt 5.12.1 release ?
> 
> thanx
> 
> ekke
> 
> Am 09.01.19 um 09:56 schrieb Liang Qi:
> > qtbase and qttools final down merges are done,
> >
> > https://codereview.qt-project.org/#/c/249324/
> > https://codereview.qt-project.org/#/c/249362/
> >
> > And also qt5 5.12->5.12.1 final down merge is done,
> >
> > https://codereview.qt-project.org/#/c/249362/
> >
> > —Liang
> >
> >> On 8 Jan 2019, at 08:32, Jani Heikkinen  wrote:
> >>
> >> Hi all,
> >>
> >> Branching from '5.12' -> '5.12.1' is finally (almost) done; qtbase and 
> qttools is  still ongoing, there were some conflicts and so on manual merge + 
> normal integration is needed there. Work is ongoing and should be ready 
> today. 
> >>
> >> So from now on '5.12.1' is for soon coming Qt 5.12.1 release and 
> staging there is restricted to release team only. And '5.12' is for Qt 5.12.2.
> >>
> >> Target is to get Qt 5.12.1 out as soon as possible. We will create 
> initial changes files soon so please finalize those immediately to be able to 
> proceed with the release. Release blocker list here: 
> https://bugreports.qt.io/issues/?filter=20430 Please make sure all release 
> blockers are visible in the list!
> >>
> >> We will release first snapshot for Qt 5.12.1 during this week as well
> >>
> >> br,
> >> Jani
> >> 
> >> From: Development  on behalf of 
> Jani Heikkinen 
> >> Sent: Monday, January 7, 2019 7:37 AM
> >> To: Aleksey Kontsevich; ekke; developm...@lists.qt-project.org
> >> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to   
> '5.12.1'started
> >>
> 
> ___
> 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] [Releasing] HEADS-UP: Branching from '5.12' to '5.12.1' started

[ekke]

Hi,
are there any news abolut Qt 5.12.1 release ?

thanx

ekke

Am 09.01.19 um 09:56 schrieb Liang Qi:
> qtbase and qttools final down merges are done,
>
> https://codereview.qt-project.org/#/c/249324/
> https://codereview.qt-project.org/#/c/249362/
>
> And also qt5 5.12->5.12.1 final down merge is done,
>
> https://codereview.qt-project.org/#/c/249362/
>
> —Liang
>
>> On 8 Jan 2019, at 08:32, Jani Heikkinen  wrote:
>>
>> Hi all,
>>
>> Branching from '5.12' -> '5.12.1' is finally (almost) done; qtbase and 
>> qttools is  still ongoing, there were some conflicts and so on manual merge 
>> + normal integration is needed there. Work is ongoing and should be ready 
>> today. 
>>
>> So from now on '5.12.1' is for soon coming Qt 5.12.1 release and staging 
>> there is restricted to release team only. And '5.12' is for Qt 5.12.2.
>>
>> Target is to get Qt 5.12.1 out as soon as possible. We will create initial 
>> changes files soon so please finalize those immediately to be able to 
>> proceed with the release. Release blocker list here: 
>> https://bugreports.qt.io/issues/?filter=20430 Please make sure all release 
>> blockers are visible in the list!
>>
>> We will release first snapshot for Qt 5.12.1 during this week as well
>>
>> br,
>> Jani
>> 
>> From: Development  on behalf of Jani 
>> Heikkinen 
>> Sent: Monday, January 7, 2019 7:37 AM
>> To: Aleksey Kontsevich; ekke; developm...@lists.qt-project.org
>> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to   '5.12.1' 
>>started
>>

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

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

[ekke]

Am 07.01.19 um 09:08 schrieb Aleksey Kontsevich:
> Very strange. 

Aleksey,

it would help if you would answer the open questions at QTBUG-72687

ekke

>
> -- 
> Best regards,
> Aleksey
> Linked in  https://www.linkedin.com/in/alekseykontsevich
>
>
> 07.01.2019, 07:37, "Jani Heikkinen" :
>>>  -Original Message-
>>>  From: Development  On Behalf Of
>>>  Aleksey Kontsevich
>>>  Sent: lauantai 5. tammikuuta 2019 12.23
>>>  To: ekke ; developm...@lists.qt-project.org
>>>  Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1'
>>>  started
>>>
>>>  Hi,
>>>
>>>  What about QTBUG-72687 and QTBUG-72227?
>> QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry.
>>
>> br,
>> Jani

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

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

[ekke]

Am 20.12.18 um 10:40 schrieb Jani Heikkinen:
>> ...
> Hi!
>
> There is still open p0 (QTBUG-72561) and fixes are coming in '5.12'. That's 
> why final downmerge is delayed. Target is to get that done still during this 
> week. But that means Qt 5.12.1 will happen on January 2019 
>
> br,
> Jani

Hi,

QTBUG-72561 is fixed, also QTBUG-72101 :)

Thanks to all the hard work done to fix these issues.

Hopefully Qt 5.12.1 now isn't too far away ;-)

Wish you a GREAT 2019

ekke

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

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

[ekke]

Am 20.12.18 um 10:40 schrieb Jani Heikkinen:
>> -Original Message-
>> From: Development  On Behalf Of
>> ekke
>> Sent: torstai 20. joulukuuta 2018 11.21
>> To: developm...@lists.qt-project.org
>> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1'
>> started
>>
>> Am 10.12.18 um 11:47 schrieb Jani Heikkinen:
>>> Hi all,
>>>
>>> We have soft branched '5.12.1' from '5.12' today. Please start using it for
>> new changes targeted to Qt 5.12.1 release. We will finalize branching and do
>> final downmerge from '5.12' to '5.12.1' Monday 17th December so there
>> should be enough time to finalize ongoing changes in '5.12' and start using
>> '5.12.1'.
>>> Target is to get Qt 5.12.1 out really soon, latest at the beginning of 
>>> January
>> 2019
>>
>> Hi,
>>
>> thanks for all the fixes for 5.12.1
>>
>> are there any news about the current plan ?
>>
>> 2018 or beginning of January 2019 ?
> Hi!
>
> There is still open p0 (QTBUG-72561) and fixes are coming in '5.12'. That's 
> why final downmerge is delayed. Target is to get that done still during this 
> week.
fingers crossed
>  But that means Qt 5.12.1 will happen on January 2019 

thanks for the info

ekke

>
> br,
> Jani

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

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

[ekke]

Am 10.12.18 um 11:47 schrieb Jani Heikkinen:
> Hi all,
>
> We have soft branched '5.12.1' from '5.12' today. Please start using it for 
> new changes targeted to Qt 5.12.1 release. We will finalize branching and do 
> final downmerge from '5.12' to '5.12.1' Monday 17th December so there should 
> be enough time to finalize ongoing changes in '5.12' and start using 
> '5.12.1'. 
>
> Target is to get Qt 5.12.1 out really soon, latest at the beginning of 
> January 2019

Hi,

thanks for all the fixes for 5.12.1

are there any news about the current plan ?

2018 or beginning of January 2019 ?

thx

ekke

>
> br,
> Jani Heikkinen
> Release Manager
>
> ___
> Development mailing list
> developm...@lists.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] [Qt-creator] Qt 5.12.0 Beta4 released

[ekke]

Am 08.11.18 um 13:38 schrieb Eike Ziller:
>
>> On 8. Nov 2018, at 13:04, ekke  wrote:
>>
>> just downloading Beta 4
>>
>> why is QtCreator 4.8.0 Beta-2 not available under "Preview" from Online 
>> Installer ?
> We haven’t released it yet.
> We would like to update Qt Creator to use Qt 5.12 before we release beta2, 
> and are facing infrastructure issues after performing some required updates 
> for that. We hope to have packages soon.
> Qt 5.11-based nightly packages are available at 
> http://download.qt.io/snapshots/qtcreator/4.8/4.8.0-beta2/
thx Eike,

now I understand it better - have overlooked that the 4.8.0-beta2
downloads are from nightly build snapshots

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

Re: [Development] Qt 5.12.0 Beta4 released

[ekke]

just downloading Beta 4

why is QtCreator 4.8.0 Beta-2 not available under "Preview" from Online
Installer ?

Am 08.11.18 um 11:52 schrieb Jani Heikkinen:
> Hi,
>
> We have released Qt 5.12.0 Beta4 today. As earlier you can get it via online 
> installer. Delta to beta3 attached.
>
> Please make sure you will report all findings in Jira. Please make sure all 
> Qt 5.12.0 release blockers are visible in release blocker list 
> (https://bugreports.qt.io/issues/?filter=19961). Target is to get RC out 15th 
> November so all fixes needs to be in latest Tue 13th November; there isn't 
> that much time anymore to fix remaining blockers...
>
> br,
> Jani Heikkinen
> Release Manager
>
>
>
>
> ___
> 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] Control 2 : Does StackView garbage collect popped items ?

[ekke]

Am 23.02.18 um 18:25 schrieb Fabrice Salvaire:
> Dear all,
>
> I am experimenting a way to implement a wizard interface featuring a
> next and previous page navigation using QML Control 2.
>
> I tried to achieve this using StackView but I receive the error
> "TypeError: Type error' when I try to access popped items later, for
> example with console.info(popped_item_array)  It looks like a kind of
> garbage collection of the Qt object returned by push and pop.  But I
> could not figure out any explanation of this behaviour on the Qt doc
> https://doc-snapshots.qt.io/qt5-5.11/qml-qtquick-controls2-stackview.html#unwinding-items-via-pop
>
> Note: I hope I am on the right channel for such technical question.
Hi Fabrice,

the developers list is for the developers of Qt

you should use the 'interest' list (users of Qt) or ask at the Forum
https://forum.qt.io/category/12/qml-and-qt-quick

BTW: here's a blog article and demo app at github about QQC2 StackView:
https://appbus.wordpress.com/2016/05/27/stacked-pages-app/ it's from
2016 - so not all is covered but perhaps will give you some ideas

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

Re: [Development] Goodbye

[ekke]

Jake,

thx for all the valuable help I got from you while using Qt to develop
mobile Apps

wish you the best for the future

ekke

Am 09.02.18 um 21:14 schrieb Jake Petroules:
> Steve Jobs once said:
>
>> “I have looked in the mirror every morning and asked myself: "If today were 
>> the last day of my life, would I want to do what I am about to do today?" 
>> And whenever the answer has been "No" for too many days in a row, I know I 
>> need to change something.”
>
> After 8 years of Qt, it's time to say goodbye. Both from my employment in The 
> Qt Company and my roles in the Qt Project. I'd like to thank those of you in 
> the company and in the Qt Project who have supported me over the years in 
> various ways. It's been a great adventure. Friday, February 23rd will be my 
> last day.
>
> I hereby relinquish my role as Maintainer of Apple build system support 
> across all projects under the Qt Project umbrella (nominating Oswald 
> Buddenhagen as my replacement), and my role as Maintainer of the Apple 
> watchOS platform (nominating Tor Arne Vestbø as my replacement).
>
> Please feel free to contact me at jake.petrou...@petroules.com if you have 
> any questions, comments, or otherwise.
>
> I wish you all the best.
>
> Sincerely,
> Jake Petroules
> ___
> 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] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[ekke]

Am 01.03.17 um 13:38 schrieb Marc Mutz:
> On Wednesday 01 March 2017 13:13:17 Lars Knoll wrote:
>>> Let’s conclude this topic now by moving on towards 5.9 as Tuukka
>>> proposed. After some thinking I also agree that this is the best course
>>> of action from where we are right now.
>> This also implies that bug fixes should now get pushed to the 5.9 branch
>> and we should close the 5.8 branch soon.
> I disagree. Even if you cannot produce releases from 5.8 anymore, that's our 
> stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then* you can 
> close 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6?
>
> Thanks,
> Marc
>
+1 from me
just cherry-picked from 5.8 to get a Show-Stopper-Bug fixed
https://appbus.wordpress.com/2017/02/28/patch-qt-5-8-0-for-qtbug-59026/

-- 

ekke (ekkehard gentz)

independent software architect
international development native mobile business apps
BlackBerry 10 | Qt Mobile (Android, iOS)
workshops - trainings - bootcamps

*Qt Champion
BlackBerry Elite Developer
BlackBerry Platinum Enterprise Partner*

max-josefs-platz 30, D-83022 rosenheim, germany
mailto:e...@ekkes-corner.org
blog: http://ekkes-corner.org
apps and more: http://appbus.org

twitter: @ekkescorner

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

Re: [Development] Revisiting high-DPI configuration options

[ekke]

Am 22.06.16 um 14:46 schrieb Morten Sorvig:
>> On 22 Jun 2016, at 10:30, Michael Zanetti <michael.zane...@canonical.com> 
>> wrote:
>>
>>
>>
>> On 20.06.2016 15:00, Morten Sorvig wrote:
>>> Another reason to not spend time on it would be that integer is, or is going
>>> to be, the dominating use case. Wayland and Apple is integer, so are most of
>>> the Android device categories. For Windows and desktop in general there are
>>> currently lots of fractional hardware and configurations.
>> I don't think this is true. From all the devices (phones/tablets) we
>> support Ubuntu on, none is a full integer multiplier. I really don't see
>> how it is going to fly if only full integers are supported. After all,
>> all the Ubuntu Devices are actually based on Android hardware, so surely
>> there the same issue would happen, no?
>>
> What I have for Android devices are tables like this: (there are various
> sources, see below)
>
> 0.75 - ldpi
> 1.0 - dpi
> 1.5 - hdpi
> 2.0 - xhdpi
> 3.0 - xxhdpi
> 4.0 - xxxhdpi
>
> The factor here is DisplayMetrics.density. This suggests integer factors, or
> at least a convergence towards integer factors if we allow that new Android
> devices are xhdpi or better.
my android device  reports 3.5 for

qApp->primaryScreen()->devicePixelRatio()


Does this mean Qt is using 4.0 and not 3.5 as scale factor ?
Images are correctly used from @4

ekke
> It think what is happening is that the hardware may be non-integer, but then
> Android maps that to a device class with a fixed scale factor. We can use that
> scale factor in Qt - any error introduced by it (if the hardware is some 
> fraction
> between classes) will be matched by the native UI.
>
> If Qt applications are going to see fractional factors on Ubuntu then that’s
> a point in favor of making Qt work better in that configuration.
>
> Morten
>
> http://stackoverflow.com/questions/3166501/getting-the-screen-density-programmatically-in-android
> https://groups.google.com/forum/#!msg/android-developers/g56jV0Hora0/9d8p8QJg1ksJ
>

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

Re: [Development] The behaviour of Image / image provider are different from 5.5.1 to 5.6 in iOS

[ekke]

perhaps devicePixelRatio is 3.0 - this would have the effect to get 170.666
http://doc.qt.io/qt-5/qimage.html#setDevicePixelRatio

ekke
Am 11.04.16 um 14:36 schrieb Federico Buti:
> Hi Ben,
>
> I've solved the issue by multiplying width/height to
> qApp->devicePixelRatio(). That should be 3 on iPhone 6 and should
> provide the correct result.
> I'm not sure if that's a bug or it is intended behaviour and I
> actually didn't investigate the issue a lot since I was just testing
> stuff. 
>
> Hope someone else can confirm it's a bug or expected.
>
> Cheers,
> F.
>
> On 11 April 2016 at 14:28, Ben Lau <xben...@gmail.com
> <mailto:xben...@gmail.com>> wrote:
>
>
>
> On 11 April 2016 at 20:19, ekke <e...@ekkes-corner.org
> <mailto:e...@ekkes-corner.org>> wrote:
>
> Am 11.04.16 um 14:07 schrieb Ben Lau:
>>
>> On 11 April 2016 at 19:59, ekke <e...@ekkes-corner.org
>> <mailto:e...@ekkes-corner.org>> wrote:
>>
>> Am 11.04.16 um 12:38 schrieb Ben Lau:
>>> Hi,
>>>
>>> I am writing an image provider that read all the images
>>> to memory at startup. And I found that the behaviour is
>>> different from 5.5.1 to 5.6 in iOS. Seems that it is
>>> undocumented. I wonder is it an expected behaviour or a bug?
>>>
>>> That is the example project:
>>> 
>>> https://github.com/benlau/quickcross/tree/master/tests/imageprovider
>>>
>>> That is the code of my image provider:
>>>
>>> QImageQCImageProvider::requestImage(constQString,QSize*size,c
>>> onstQSize)
>>> {
>>> Q_UNUSED(requestedSize);
>>> QCImageLoader*loader=QCImageLoader::instance();
>>> QImageresult;
>>> if(loader->contains(id)){
>>> result=loader->image(id);
>>> *size=result.size();
>>> }
>>> returnresult;
>>> }
>>> Code to display image:
>>> Image {
>>>   id: image
>>>   source: "image://arts/Lenna.png" // An 512x512 image
>>> }
>>> In Qt 5.5.1 with iPhone6, the property of image will be set to:
>>> width: 512
>>> height: 512
>>> sourceSize: Qt.size(512,512)
>>> However, in Qt 5.6 with iPhone6, it becomes:
>>> width: 170.6
>>> height: 170.6
>>> sourceSize: Qt.size(512,512)
>>> The display size of image is different.
>>>
>>>
>> now from Qt 5.6 HighDPI is supported for all platforms.
>> iPhone has scaling factor 3
>>
>> 170.6 * 3 = 512
>>
>>
>> ekke
>>
>>
>> But Qt 5.5 on iOS also support HighDPI. Their result are
>> different.
>>
>>
> have you tried to explicitely set
>
> QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
>
>
> ekke
>
>
> I have tried to set / not-set this line. It don't make any different.
>
>
> ___
> Development mailing list
> Development@qt-project.org <mailto: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] The behaviour of Image / image provider are different from 5.5.1 to 5.6 in iOS

[ekke]

Am 11.04.16 um 14:07 schrieb Ben Lau:
>
> On 11 April 2016 at 19:59, ekke <e...@ekkes-corner.org
> <mailto:e...@ekkes-corner.org>> wrote:
>
> Am 11.04.16 um 12:38 schrieb Ben Lau:
>> Hi,
>>
>> I am writing an image provider that read all the images to memory
>> at startup. And I found that the behaviour is different from
>> 5.5.1 to 5.6 in iOS. Seems that it is undocumented. I wonder is
>> it an expected behaviour or a bug?
>>
>> That is the example project:
>> https://github.com/benlau/quickcross/tree/master/tests/imageprovider
>>
>> That is the code of my image provider:
>>
>> QImageQCImageProvider::requestImage(constQString,QSize*size,c
>> onstQSize)
>> {
>> Q_UNUSED(requestedSize);
>> QCImageLoader*loader=QCImageLoader::instance();
>> QImageresult;
>> if(loader->contains(id)){
>> result=loader->image(id);
>> *size=result.size();
>> }
>> returnresult;
>> }
>> Code to display image:
>> Image {
>>   id: image
>>   source: "image://arts/Lenna.png" // An 512x512 image
>> }
>> In Qt 5.5.1 with iPhone6, the property of image will be set to:
>> width: 512
>> height: 512
>> sourceSize: Qt.size(512,512)
>> However, in Qt 5.6 with iPhone6, it becomes:
>> width: 170.6
>> height: 170.6
>> sourceSize: Qt.size(512,512)
>> The display size of image is different.
>>
>>
> now from Qt 5.6 HighDPI is supported for all platforms.
> iPhone has scaling factor 3
>
> 170.6 * 3 = 512
>
>
> ekke
>
>
> But Qt 5.5 on iOS also support HighDPI. Their result are different.
>
>
have you tried to explicitely set

QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);


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

Re: [Development] The behaviour of Image / image provider are different from 5.5.1 to 5.6 in iOS

[ekke]

Am 11.04.16 um 12:38 schrieb Ben Lau:
> Hi,
>
> I am writing an image provider that read all the images to memory at
> startup. And I found that the behaviour is different from 5.5.1 to 5.6
> in iOS. Seems that it is undocumented. I wonder is it an expected
> behaviour or a bug?
>
> That is the example project:
> https://github.com/benlau/quickcross/tree/master/tests/imageprovider
>
> That is the code of my image provider:
>
> QImageQCImageProvider::requestImage(constQString,QSize*size,constQSize)
> {
> Q_UNUSED(requestedSize);
> QCImageLoader*loader=QCImageLoader::instance();
> QImageresult;
> if(loader->contains(id)){
> result=loader->image(id);
> *size=result.size();
> }
> returnresult;
> }
> Code to display image:
> Image {
>   id: image
>   source: "image://arts/Lenna.png" // An 512x512 image
> }
> In Qt 5.5.1 with iPhone6, the property of image will be set to:
> width: 512
> height: 512
> sourceSize: Qt.size(512,512)
> However, in Qt 5.6 with iPhone6, it becomes:
> width: 170.6
> height: 170.6
> sourceSize: Qt.size(512,512)
> The display size of image is different.
>
>
now from Qt 5.6 HighDPI is supported for all platforms.
iPhone has scaling factor 3

170.6 * 3 = 512


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

Re: [Development] [Announce] Qt 5.7 Alpha released

[ekke]

Am 30.03.16 um 22:44 schrieb Thiago Macieira:
> On quarta-feira, 30 de março de 2016 22:24:30 PDT ekke wrote:
>> hi,
>>
>> are there any news on Qt 5.7 Beta ?
> Yes, see the minutes from yesterday's release meeting. It was posted to the 
> releasing mailing list.
thx.
wasn't aware of this
only looked at https://wiki.qt.io/Qt-5.7-release
>> is 2016-03-31 still valid ?
> No.
>

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

Re: [Development] [Announce] Qt 5.7 Alpha released

[ekke]

hi,

are there any news on Qt 5.7 Beta ?
is 2016-03-31 still valid ?

thx

ekke

Am 11.03.16 um 09:18 schrieb List for announcements regarding Qt
releases and development:
>
> Hi all!
>
>  
>
> Qt 5.7 Alpha release is out, see
> http://blog.qt.io/blog/2016/03/11/qt-5-7-alpha-released/
> <http://blog.qt.io/blog/2016/03/11/qt-5-7-alpha-released/>
>
>  
>
> As earlier, Alpha is source code delivery only. The plan forward is
> now to create a beta (including binary packages) during the next few
> weeks.
>
>  
>
> Big thanks for everyone who were involved to make this happen!
>
>  
>
> Br,
>
> Akseli
>
>  
>
>
>
> ___
> Announce mailing list
> annou...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/announce
>
>
> ___
> 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] Scalable UIs in QtQuick (take 2)

[ekke]

Am 19.02.16 um 18:27 schrieb Welbourne Edward:
>> The user should choose the text size,
> Indeed - ideally as a device setup action that configures a
> device-global parameter that all apps get to work with.  All font sizes
> should be specified in terms of the user-selected "comfortable size to
> read" for a font.  The screen size, measured in this font-sizes's em
> unit, may be rather small for some users and significantly bigger for
> other users.  That's, to some degree, true today - different devices
> have different-sized screens after all - but we'd need designers to
> start taking it seriously and stop thinking they can "fix" this by
> having the design respond to the "physical" size (in mm) of the screen.
In BlackBerry Cascades implementation I'm never using points or pixels,
I'm using predefined sizes:
TitleText
SubtitleText
Smalltext
LargeText
XLargeText
BigText
...
... and I was sure on all BB10 devices with different dpi the font size
is the same.
It's not so easy not to re-think for Qt 5.6 and using px

I like the qt.labs.controls where I can use colors as accent or primary etc.
that's intuitive

-- 

ekke (ekkehard gentz)

independent software architect
international development native mobile business apps
BlackBerry 10 | Qt Mobile (Android, iOS)
workshops - trainings - bootcamps

*BlackBerry Elite Developer
BlackBerry Platinum Enterprise Partner*

max-josefs-platz 30, D-83022 rosenheim, germany
mailto:e...@ekkes-corner.org
blog: http://ekkes-corner.org
apps and more: http://appbus.org

twitter: @ekkescorner
skype: ekkes-corner
LinkedIn: http://linkedin.com/in/ekkehard/
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490

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

Re: [Development] Scalable UIs in QtQuick (take 2)

[ekke]

I'm just evaluating mobile development with Qt 5.6Beta,
qt.labs.controls, Android, Material
and have set Qt::AA_EnableHighDpiScaling

now it would be cool to "think" in cm or mm

for my device (BlackBerry PRIV, Android 5.1.1)
with 544 ppi, where devicePixelRatio (scaling factor) is 3.5

would be more intuitive to define
Rectangle {
width: 1 cm
height: 0.6 cm
}
compared with
Rectangle {
width: 64
height: 40
}
and then to calculate:
64 * 3.5 = 224 / 544 ppi = 0.41 in = 1.04 cm

BTW: HighDpiScaling works great.
added images (to compare sizes with Rectangles):
test.png (64x40)
t...@2x.png (128x80)
t...@3x.png (192x120)
t...@4x.png (256x160)

devicePixelRatio of 3.5 was exactly in the middle between @3x and @4x
Qt uses the next larger one: t...@4x.png and scaled it down to 3.5
tested this also with a much larger image - all is well done.
great work !

-- 

ekke (ekkehard gentz)

independent software architect
international development native mobile business apps
BlackBerry 10 | Qt Mobile (Android, iOS)
workshops - trainings - bootcamps

*BlackBerry Elite Developer
BlackBerry Platinum Enterprise Partner*

max-josefs-platz 30, D-83022 rosenheim, germany
mailto:e...@ekkes-corner.org
blog: http://ekkes-corner.org
apps and more: http://appbus.org

twitter: @ekkescorner
skype: ekkes-corner
LinkedIn: http://linkedin.com/in/ekkehard/
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490

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

Re: [Development] Request for a new playground project

[ekke]

+1
this sounds great - I'm also looking for BaaS with Qt Mobile development

Am 12.02.16 um 14:57 schrieb Guillaume Charbonnier:
> Hi all,
>
> Following engin.io <http://engin.io/> services ramping down
> notification, Qt mobile developers (like me) are lacking a MBaaS
> (mobile backend as a service) that would play nicely with Qt. 
> I think this lack could be quite a big impedance for the promotion of
> Qt for mobile development as most mobile applications use the basic
> features a MBaaS offer...
>
> I would like to start a playground project (with the help of everyone
> interested in that topic) to offer a set of Qt classes and QML
> elements to manage the following services :
> • authentification and authorization (with social login)
> • datastore (nosql)
> • push notifications
> • statistics
>
> I think it would be great to design this new module to be backend
> agnostic. Thus supporting several backend providers such as :
> - google Firebase
> - BaasBox
> - IBM Cloudant
> - Apigee
>
> I have never participate in Qt project so I am an absolute beginner in
> this field. 
> I have read the development topics in the wiki despite some of them
> state to be outdated - any advice and recommandation will be
> greatly appreciated.
> Here is a link to the corresponding forum topic
> : 
> https://forum.qt.io/topic/63777/looking-for-engin-io-replacement-joining-our-effort-initiative
>
> To conclude, I think it would be helpful to create a playground
> project for this project, hence my request :
> _Description_ : Qt Mobile Backed as a Service
> _Playground project name_ : MBaaS
>
> Best regards.
> Guillaume
>
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 

ekke (ekkehard gentz)

independent software architect
international development native mobile business apps
BlackBerry 10 | Qt Mobile (Android, iOS)
workshops - trainings - bootcamps

*BlackBerry Elite Developer
BlackBerry Platinum Enterprise Partner*

max-josefs-platz 30, D-83022 rosenheim, germany
mailto:e...@ekkes-corner.org
blog: http://ekkes-corner.org
apps and more: http://appbus.org

twitter: @ekkescorner
skype: ekkes-corner
LinkedIn: http://linkedin.com/in/ekkehard/
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490

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

[Development] Qt.labs controls problem

[ekke]

Hi,

just started Qt development and installed Qt 5.6 beta for Android and iOS
All went well and I'm able to deploy sample apps to my (Android)
BlackBerry PRIV :)

The slider also works well: switching between virtual and hardware
keyboard works as expected

Most samples are looking ugly because of High DPI - but that's the
reason why I waited for Qt 5.6 Beta to start Qt development for mobile ;-)
I want to use High DPI support, the labs controls and Material Design.

As a first step I followed the instructions here:
https://doc-snapshots.qt.io/qt5-5.6/qtlabscontrols-gettingstarted.html
and copied the content to main.cpp and main.qml

unfortunately it fails:

|W/libtest_q2_controls.so(15994): (null):0 ((null)):
QQmlApplicationEngine failed to load component
W/libtest_q2_controls.so(15994): (null):0 ((null)):
file:///data/data/org.qtproject.example.test_q2_controls/files/main.qml:-1
File not found |

also in design mode Qt.quick 2.6 isn't available

am I missing anything ?

thanks for any hints.

(see also my entry in forum:
https://forum.qt.io/topic/63824/unsupported-qt-quick-version-main-qml-not-found
)
-- 

ekke (ekkehard gentz)

independent software architect
international development mobile apps for BlackBerry 10
workshops - trainings - bootcamps

*BlackBerry Elite Developer
BlackBerry Platinum Enterprise Partner*

max-josefs-platz 30, D-83022 rosenheim, germany
mailto:e...@ekkes-corner.org
blog: http://ekkes-corner.org
apps and more: http://appbus.org

twitter: @ekkescorner
skype: ekkes-corner
LinkedIn: http://linkedin.com/in/ekkehard/
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490

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

Re: [Development] Qt.labs controls problem

[ekke]

just got the answer in forum.
had to change the path to main.qml:

|QQmlApplicationEngine engine;
engine.load(QUrl(QStringLiteral("qrc:/main.qml")));|

now it works and I can go on :)

ekke

Am 05.02.16 um 13:27 schrieb ekke:
> Hi,
>
> just started Qt development and installed Qt 5.6 beta for Android and iOS
> All went well and I'm able to deploy sample apps to my (Android)
> BlackBerry PRIV :)
>
> The slider also works well: switching between virtual and hardware
> keyboard works as expected
>
> Most samples are looking ugly because of High DPI - but that's the
> reason why I waited for Qt 5.6 Beta to start Qt development for mobile ;-)
> I want to use High DPI support, the labs controls and Material Design.
>
> As a first step I followed the instructions here:
> https://doc-snapshots.qt.io/qt5-5.6/qtlabscontrols-gettingstarted.html
> and copied the content to main.cpp and main.qml
>
> unfortunately it fails:
> |W/libtest_q2_controls.so(15994): (null):0 ((null)):
> QQmlApplicationEngine failed to load component
> W/libtest_q2_controls.so(15994): (null):0 ((null)):
> file:///data/data/org.qtproject.example.test_q2_controls/files/main.qml:-1
> File not found |
> also in design mode Qt.quick 2.6 isn't available
>
> am I missing anything ?
>
> thanks for any hints.
>
> (see also my entry in forum:
> https://forum.qt.io/topic/63824/unsupported-qt-quick-version-main-qml-not-found
> )
> -- 
>
> ekke (ekkehard gentz)
>
> independent software architect
> international development mobile apps for BlackBerry 10
> workshops - trainings - bootcamps
>
> *BlackBerry Elite Developer
> BlackBerry Platinum Enterprise Partner*
>
> max-josefs-platz 30, D-83022 rosenheim, germany
> mailto:e...@ekkes-corner.org
> blog: http://ekkes-corner.org
> apps and more: http://appbus.org
>
> twitter: @ekkescorner
> skype: ekkes-corner
> LinkedIn: http://linkedin.com/in/ekkehard/
> Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490
>
>
>
> ___
> 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