Re: [Development] Let's drop MSVC 2019 for dev (6.8)

[Vladimir Minenko via Development]

Hello all,

FYI in this subject:

https://www.qt.io/blog/moving-to-msvc-2022-in-qt-68

--
Vladimir


On 12. Apr 2024, at 14:04, Oliver Wolff via Development 
 wrote:

Hey hey

On 15/03/2024 16:47, Thiago Macieira wrote:
On Monday, 5 February 2024 01:44:29 PDT Allan Sandfeld Jensen wrote:
I was trying to drop support for it in qtwebengine in 6.7, but the problem
was it was still used for qt packaging. But if we could at least switch
packing to vs2022, it would mean we could drop it in QWE.
Can we commit to this ASAP after the 6.7 release? We'll revisit later in the
cycle whether we still need 2019. Do note that Microsoft is preparing the next
release after 2022, as seen by their shipping 17.0 Tech Previews.
Jörg accidentally broke the C++ language level set up in dev, meaning we
didn't test C++20 mode with 2019 for a day or so, and some changes that
trigger 2019's broken C++20 support went in. If we don't drop 2019 by 6.8
release, we should force it to only compile in C++17 mode.

Sorry for the long silence. I talked to some people inside the company and we 
agreed on the following plan: We will try to get MSVC 2022 packages into 6.7 as 
soon as possible. For 6.8 we will then remove support for MSVC 2019 (and hope 
that not too many people rely on that being available in the next LTS release). 
That should give users some time to test the 2022 packages and they can report 
bugs and fall back to the 2019 packages if something breaks for them before we 
do the "hard cut".

Cheers,
Olli
--
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] Let's drop MSVC 2019 for dev (6.8)

[Vladimir Minenko via Development]

Hi,

I also think we should first get the 2022 compiler packages available for 
installation in parallel to the 2019 ones. This should be available for users 
for a while so that they have a transition period. Along with this, we should 
announce that the 2019 compiler will be dismissed by a specific date.

As we introduce Linux on ARM desktops and later Windows on ARM desktops, this 
can only be done IMHO after work on the release of 6.7 is finished, meaning in 
some of the 6.7.x slots.

Considering removal of MSVC 2019 in "Supported Configurations” in 
https://doc.qt.io/qt-6/windows.html should come after we provide a transition 
solution, IMHO

I fully appreciate the enthusiasm for using new capabilities in the newer 
compiler, but we should not forget the fact there are more users preferring the 
predictability of changes, and none like surprises with these topics.

--
Vladimir


On 6. Feb 2024, at 08:28, Allan Sandfeld Jensen  wrote:

On Tuesday, 6 February 2024 06:57:34 CET Jani Heikkinen via Development wrote:
How about instead we drop at an LTS+2 release? The next one is actually
6.7.
We can't switch this in 6.7 at this point anymore; we don't have packages
for MSVC2022 at the moment and doing this (adding new packages + removing
ones) change this late of process is too risky

Could you please switch packaging to msvc2022 in dev then, so we don\t have
this discussion and excuse yet again in 6 months?

Br
Allan



--
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] Raising the minimum to C++20

[Vladimir Minenko via Development]

Just as a reminder, the "C++20 is mandatory for users of Qt (Phase III)” 
(https://bugreports.qt.io/browse/QTBUG-109362) says "The tentative plan is Qt 
6.12+”

and "C++20 is required for the development and buiding of Qt itself (Phase II)” 
(https://bugreports.qt.io/browse/QTBUG-109361) - "The tentative plan is Qt 
6.9-6.11”

With all the respect to the power of C++20 and enthusiasm to use it from Qt 
Project developers, what should we expect from all other users if we would make 
this change in 6.8, considering:

a) just 4 months left to the Feature Freeze for 6.8
b) there is zero communication to users beyond the above issues on Qt But 
Reports and discussions on this mailing list (which is actually for Qt 
developers and not Qt users, BTW)
c) there is no other communication about the done and ongoing works introducing 
C++20 in Qt and plans for future versions, beyond the talk from Mark at QtWS22 
and careful reading of “What’s New” pages

Qt crashed such a change on users with C++11 and with C++17 in the past. Each 
time after this, there were much more negative responses than “thank you”s. I 
still hope we find a way to do this better this time. And just “faster” is not 
“better"

In the current shape, my vote is “no”.

--
Vladimir

On 3. Feb 2024, at 18:15, Thiago Macieira  wrote:

On Tuesday, 2 May 2023 17:39:01 PST Thiago Macieira wrote:
I don't have access to QNX and INTEGRITY toolchain information, so I'd like
to request that they simply match the feature list above, with minimal
workarounds.

What's the current state for those, for supporting Qt 6.8 or 6.9?

We have VxWorks coming in and I'd like it to meet a higher minimum bar than
"legacy". That is, I'd like VxWorks to require a C++20-compliant compiler
before being enabled in our CI, but that's only fair if we have a line-of-
sight to bringing everyone to C++20.

--
Thiago Macieira - thiago.macieira (AT) intel.com
 Cloud Software Architect - Intel DCAI Cloud Engineering
--
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] QtFluentMQ

[Vladimir Minenko via Development]

Hello  team fluentmq,

> We would need you guys to confirm that you'd have the ressource model and the 
> benefit to integrate the module to the commercial offer

I do not quite understand who exactly you expect to confirm and what you mean 
with "ressource model”.

Despite that, I also think the idea is cool and can bring new values for Qt 
when done. I think Volker outlined the next steps in his reply.

Greetings!

--
Vladimir Minenko
vladimir.mine...@qt.io
+49 171 90 61 461

Senior Product Manager, Qt Foundations, mobile and desktop platforms
The Qt Company - https://qt.io




On 23. Aug 2023, at 18:27, team fluentmq  wrote:

Hello,


>>If that is the ambition in the longer term, but you’d nevertheless want to 
>>start developing the project as a Qt module, then a repository in the
>>playground/ namespace on our gerrit server can be a good start.

That's actually the status we've left the discussion at from the backlog. Our 
expectation is to integrate the project as Qt module with total Qt governance. 
Though, we would still need maintainance roles assigned to us to make sure we'd 
be able to provide around the clock support as our cross-platform Suite would 
rely heavily on this module for the messaging.

As to the licensing and commercial support, well that's would motivate the 
redesign and implamentation of the project under Qt. We would need you guys to 
confirm that you'd have the ressource model and the benefit to integrate the 
module to the commercial offer. Our product make us of the commercial licensing 
model so no issue on our side.

As to the test tooling  for this project: Apart from the Plumber open source 
project that we use as the (agnosticà CLI tool, all the tooling in-use are 
docker compositions of the respective official MQ platform images and perf 
tools which are available with an open source licensing model. The test tooling 
would be the same as the one used by Qt.

With regards to the developpement guidelines, well that would be easy, our 
developpers are Qt specialist that are familiar with both the public and 
private Qt idoms. Both the proposed designs are compliant with the core 
guidelines, they vary in the way the public API would be exposed:

  *   The bridge design (Abstraction/PIMPL tree) is compatible with Qt PIMPL 
idiom and enforces more type safety using an abstraction tree for API exposure 
instead of polymorphic aggregation like it would normally be the case for the 
RHI approach for example while still proving the unsafe functionallity oriented 
approach through runtime reflexion access (we're using QtProtobuf to generate 
our APIs which MOC-able types).

  *   The functionality oriented design proposal is similar to the RHI 
integration and threats the messaging as a loossly configuratable and 
commanable API where few or none of the platform dependant implementation is 
exposed in the public namespace thus providing an ideal type erasure, this 
we're mostly reluctant about. It works well with the RHI API because the 
runtime is tighthly coupled to the hardware, the user can easily debug the 
runtime by capturing frames and inspecting the graphics commands. using. With a 
distributed system, this would be a much tedious task had the user issued any 
careless wrongfull assumption.


>>If that is the ambition in the longer term, but you’d nevertheless want to 
>>start developing the project as a Qt module, then a repository in the
>>playground/ namespace on our gerrit server can be a good start. As pointed 
>>out on the wiki-page above, the qt-labs/ namespace is a bit special and
>>reserved for employees of The Qt Company.
That sounds good.

>>Does the project’s code live anywhere today where we can have a look? That 
>>would probably be a good start.
Currently, We have 2 design proposals for the cross MQ platform design that we 
can provide you UML diagrams for. We did not decide yet on which to adopt for 
the project, maybe you can help decide which one is better suited for the 
project from a user friendliness and safety point of view ?
As to the backends, we have a standalone private propriatary Qt based Kafka C++ 
code that is just waiting to be integrated in a cross MQ platform design and an 
ongoing AMQPP standalone implementation that bearely started. This is not 
available in a public repo. If you think you'd be ok to move forward with the 
project according to your ressource model for licensing and integration, we'd 
have no issue openning the sources under a Qt GPL licensing model and move 
everything to the playground.

Br
 QtFluentMQ Team





From: Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>>
Sent: Wednesday, August 23, 2023 4:57 PM
To: team fluentmq mailto:fluen...@outlook.com>>
Cc: development@qt-project.org<mailto:development@qt-project.org> 
mailto:development@qt-pr

Re: [Development] Raising the minimum to C++20

[Vladimir Minenko via Development]

Hello all,

on this occasion, I would like to call the Qt Development community for 
conscious and pragmatic decisions when it comes to changes in the "minimum C++ 
standard”.

For some reason, Qt became known to do these switches on some “surprising" 
basis. I recall well as a colleague was leaving the office in frustration some 
day in 2016 and saying, “I now need a break”, just because he installed Qt 
5.7.0 (C++11) and realized that his (large) project does not compile anymore, 
out of sudden and without any notice in advance. We cannot change how things 
happened in 5.7 or 6.0 (C++17), but we can make it better in the future.

On Dec 21st last year, I sent an email to this list with the subject "About the 
timeline and phases to support C++20 with and in Qt”:

https://www.mail-archive.com/development@qt-project.org/msg42196.html

This email also refers to related issues on Qt Bug Reports to the roadmap and 
plans with C++20:

“…1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360
2. C++20 is required for the development of Qt itself -
https://bugreports.qt.io/browse/QTBUG-109361
3. C++20 is mandatory for users of Qt -
https://bugreports.qt.io/browse/QTBUG-109362
4. Long term: C++23, Qt7, and unsorted  -
https://bugreports.qt.io/browse/QTBUG-109363
…”

It would be great to have a coordinated and well-communicated migration this 
time. Please consider commenting or even co-working on these issues.

Just to leave a note for clarification for one topic mentioned below on this 
thread. A more conservative approach to mandating C++ standards is not only 
driven by the support of such “exotic” platforms like QNX or VxWorks, which 
might be slow following changes in desktop compilers. There are many regular Qt 
users who do not have the luxury of switching compilers or libc in their 
projects as often as they would like to. Plus, I got to know some really big Qt 
fans in embedded development using embedded Linux who, unfortunately, got stuck 
on some older BSPs. They feel being ignored in their concerns by developments 
in Qt, with Qt 6.0 and C++17 in particular, but they still need to get their 
jobs done and get products on the market. So please do not forget these folks!

Please correct me if I’m wrong, but I think, Qt can still use new compiler 
versions even if not mandating the latest C++ standard.

Greetings!

--
Vladimir

On 3. May 2023, at 08:58, Sune Vuorela  wrote:

On 2023-05-03, Thiago Macieira  wrote:
13, while Ubuntu 22.04 and Debian 11 (current stable) have GCC 11. Debian will
probably release its next stable before Qt 6.7, though whether it'll still
upgrade from GCC 12 to 13 I don't know. When we released Qt 6.0, our minimum

Debian 12 "Bookworm" is planned for june 10th, and will be with gcc 12.

/Sune

--
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] Do we need VS2019 for Qt 6.6?

[Vladimir Minenko via Development]

Hi,

I’m sorry to say, but from my perspective, this change cannot be done in 6.6. I 
think 6.7 is better. And this is why.

I just had a look at the anonymous telemetry data which is sent from Qt 
Creator. There is a setting for this where you can turn it on and off. So the 
below numbers cover only those users who use Qt Creator for builds and have 
telemetry on.

In 2022 and 2023, around 24M builds ran on Windows in around 600K unique 
installations worldwide which had at least 10 builds in this period of time. 
Not even a single one used MSVC2022. The most widely installed is MSVC2019 v29 
followed by v28. Most installations (around 250K) are on Qt 6.2. Qt 5.15 has 
around 60K installations.

Statistically, it would be correct to conclude that none of the MSVC2022 users 
had turned telemetry on or that all MSVC2022 users use Visual Studio and not Qt 
Creator. But the above numbers are still telling us that we will disappoint a 
large number of users unlisting MSVC2019 from Qt 6.6. Yes, I was reading the 
beginning of this thread and I do know that the regular maintenance of MSVC2019 
ends relatively soon. Still, it is hard to ignore these numbers.

--
Vladimir



On 30. Jan 2023, at 10:40, Allan Sandfeld Jensen  wrote:

On Montag, 30. Januar 2023 10:03:53 CET Giuseppe D'Angelo via Development
wrote:
On 30/01/2023 09:07, Allan Sandfeld Jensen wrote:
I would add my support to removing it from 6.6, It would simplify the
continued updating of Chromium that is starting to depend on c++20
features
that doesn't work well in VS2019.

Out of curiosity, how does this interact with the plans of having
qtwebengine work with multiple Qt versions? E.g. should one ensure that
Qt 6.2 works fine in C++20 mode with MSVC 2022, if one wants to use
latest-QtWebEngine on 6.2?

So far the plan is that QtWebEngine will only work back to last LTS, so 6.6
will work with 6.5  and I think MSVC2019 and MSVC2022 are binary compatible?

Note we do not need C++20 in Qt in general. We have an interface boundary
between Chromium and Qt code using absl.

Best regards
Allan


--
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] About the timeline and phases to support C++20 with and in Qt

[Vladimir Minenko via Development]

Hello all,

I want to share on this mailing list a proposal for the timeline and phases to 
support C++20 with and in Qt. Writing this, I’m aware that there were other 
discussions about the support of C++20 on this mailing list. This message is a 
step to get a list of features that all Qt users can expect along a certain 
timeline. We want to make the landing with the adoption of new C++ standards 
“softer” than it used to happen in the past, yet prompt enough to make sure 
that Qt keeps and enlarges its popularity among C++ developers.

We got four user stories on Qt Bug Reports:

1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360
2. C++20 is required for the development of Qt itself - 
https://bugreports.qt.io/browse/QTBUG-109361
3. C++20 is mandatory for users of Qt - 
https://bugreports.qt.io/browse/QTBUG-109362
4. Long term: C++23, Qt7, and unsorted  - 
https://bugreports.qt.io/browse/QTBUG-109363

These user stories are linked to selected features from the list once created 
by Marc in https://bugreports.qt.io/browse/QTBUG-99243

The above list is sorted in the order of time. Still, a particular "Fix 
Version” is not set yet. We (all) have to set this, though. ASAP for #1, and by 
the time we ship the version set in #1, we should set the version for #2, etc. 
See the list of all releases at https://wiki.qt.io/QtReleasing#Qt_releases

In addition, there is a task https://bugreports.qt.io/browse/QTBUG-109469 to 
add a new page or extend an existing page (Supported Platforms?) with details 
about the support of C++ standards. Plus, we need to get a simple way to test 
the capabilities of a toolchain, see 
https://bugreports.qt.io/browse/QTBUG-109470.

The latter should be a help mainly for Qt users on embedded platforms. Those 
folks have serious problems again and again with "fast moves” towards new C++ 
standards since they do not have the luxury of quick updates of compilers and 
standard libraries as known on desktops.

Please have a look at the above issues, comment on Qt Bug Reports, and make 
changes if applicable.

And now, the most important point ;-) - Merry Christmas and Happy New Year!

--
Vladimir Minenko
vladimir.mine...@qt.io
+49 171 90 61 461

Senior Product Manager, Qt Foundation
The Qt Company - https://qt.io

c/o Regus / Josephspitalstraße 15
80331 Munich, Germany



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

Re: [Development] Jira tickets for Qt Print Support (Was: Volunteer wanted: update use of CUPS API)

[Vladimir Minenko]

> I'd like to nominate Mike as default assignee for Qt 3D

+1  for Mike! I worked with Mike (Krus) on a project in my “previous life"! 
Ride on, Mike!

--
Vladimir



On 1. Jun 2022, at 16:03, Sze Howe Koh 
mailto:szehowe@gmail.com>> wrote:

On Thu, 5 May 2022 at 16:41, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:

On 5 May 2022, at 10:32, Alex Blasche 
mailto:alexander.blas...@qt.io>> wrote:

-Original Message-
From: Development 
mailto:development-boun...@qt-project.org>> 
On Behalf Of Sze
Howe Koh
On Mon, 4 May 2020 at 15:19, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:

On 4 May 2020, at 09:08, Albert Astals Cid via Development
mailto:development@qt-project.org>> wrote:

P.S: Someone should really really remove John Layt as printinting
mantainer stuff, i don't think he's been around for years.

Agreed. I’ll remove him.

Cheers,
Lars

All of the printing-related tickets still get auto-assigned to John.
There are lots of recently-opened ones:

The much more difficult question is who the new default assignee is. Was
this anywhere mentioned?

Otherwise, it makes no difference whether John is the auto assignee or
not.

If there is no maintainer then the default assignee should be
“Unassigned”. Although that might not make any difference in practice of
fixing those issue, it does make a difference in being honest about the
situation.

Cheers,
Tor Arne

Changing the default of Qt Print Support to "Unassigned" sounds
reasonable in this case. How does this occur?

Also, Qt 3D tickets are auto-assigned to Sean Harmer who hasn't been
active in ~1.5 years [1]. Mike Krus has been manually taking recent
tickets [2] and has privately expressed willingness to take Sean's
place -- I'd like to nominate Mike as default assignee for Qt 3D. As
far as I'm aware, the formal procedure for this and the eligibility
criteria are not specified in any QUIP -- does it make sense to add
Jira default assignees to QUIP 2?


Regards,
Sze-Howe

[1] https://codereview.qt-project.org/q/owner:sean.harmer%2540kdab.com
[2] https://bugreports.qt.io/secure/ViewProfile.jspa?name=mkrus
[3] http://quips-qt-io.herokuapp.com/quip-0002.html
___
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] Please allow recording of as many sessions as possible at QtCS 2022

[Vladimir Minenko]

Hello all,

I just added a note with an appeal to record as many sessions as possible at 
the upcoming QtCS 2022:

https://wiki.qt.io/Qt_Contributors_Summit_2022_-_Program

Please make it possible! I hate to miss this cool stuff, but I might...

Thanks!

--
Vladimir Minenko
vladimir.mine...@qt.io
+49 171 90 61 461

Senior Product Manager, Qt Foundation
The Qt Company - https://qt.io


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

[Development] Use of new asymmetric / hybrid CPU architectures in Qt for more energy efficiency

[Vladimir Minenko]

Hello all,

with the introduction of the new Apple Silicon, Apple brought the concept of 
low power, efficiency cores to the market.

For a while, Apple provides APIs for application developers to provide hints to 
the OS about the role and type of work done in different threads in an app. 
They call it Quality-of-Service (QoS) Classes. See 
https://bugreports.qt.io/browse/QTBUG-93946

Windows 11 seems to support this in a different form on Intel CPUs:

https://www.intel.com/content/www/us/en/developer/articles/guide/alder-lake-developer-guide.html

Apparently, the Linux kernel 5.18 is going to get support for Intels Thread 
Director which would do the same on Linux:

https://www.tomshardware.com/news/intel-thread-director-coming-to-linux-5-18

https://9to5linux.com/linus-torvalds-announces-first-linux-5-18-kernel-release-candidate

I think it would be a great new feature in Qt to support efficient computing in 
a cross-platform way!

Maybe we can also co-work with KDE and make one more step in their Blue Angel 
initiative!

https://invent.kde.org/teams/eco/blue-angel-application

Have a nice weekend!

--
Vladimir Minenko
vladimir.mine...@qt.io
+49 171 90 61 461

Senior Product Manager, Qt Foundation
The Qt Company - https://qt.io


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

[Development] Qt - connected first. Your takes? Feedback?

[Vladimir Minenko]

Hello all,

as it was mentioned in https://www.qt.io/blog/qt-roadmap-for-2022, there are 
more topics in development at the moment.

We once called one of those "Connected First" 
(https://bugreports.qt.io/browse/QTBUG-98086). In this email, I wanted to list 
a few use cases which we like to cover and ask for your feedback or suggestions 
for any alternative approaches or technologies which you see as more important. 
Hm… Might be a bit longer email. Please do not TL;DR too soon ;-)

Our long-term goal is to ensure that Qt developers can use API provided by 
services on the network and even create such services in a simple way. It is 
possible to do this with Qt today on the client side, but a lot of boilerplate 
code should be written or additional libraries are required. The server side 
would require a lot of work.

There are two directions for “in a simple way”. One is to reduce the amount of 
boilerplate code needed when using existing services, like https://reqres.in 
which is available for testing. This would be a must for all those who need to 
use the existing service API. The second “simple way” is to use IDL and code 
generation when both the server and the client sides are in development and API 
can be (re)defined.

Despite the “bare-metal” REST and OpenAPI as its API management and code 
generation counterpart, there is also gRPC / Protocol Buffers and GraphQL.

Our current plan is to start with reviving and finishing the Lightweight 
HTTP-Server (https://bugreports.qt.io/browse/QTBUG-60105) and provide basic 
support for gRPC with Protocol Buffers 
(https://bugreports.qt.io/browse/QTBUG-98027).

Later on, we want to explore what can be simplified when using Qt with existing 
REST-based services and with those which are based on OpenAPI

Some of this was already mentioned in 
https://wiki.qt.io/Qt_Network_Workshop_2016, see the "REST details” section. 
Well. almost 6 years passed after this.

Additionally, we want to integrate the old and new Qt Interface Framework 
(https://doc-snapshots.qt.io/interfaceframework/index.html) as an element in 
Connected First.

It is more open, if and how GraphQL fits these needs and if there will be a 
sufficient value for Qt users to support GraphQL in Qt directly. GraphQL is an 
advanced and certainly fascinating technology and growing fast. First 3rd-party 
API are already available, e.g. https://github.com/APIs-guru/graphql-apis lists 
some of those.

What is your view on these use cases? Feedback and comments about choices as 
listed? Missing ones?

Cheers!

--
Vladimir Minenko
vladimir.mine...@qt.io
+49 171 90 61 461

Senior Product Manager, Qt Foundation
The Qt Company - https://qt.io


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

[Development] Qt World Summit 2021: 5 days left to submit your presentation proposal

[Vladimir Minenko]

Hi,

Just in case, you missed this, but still have interesting topics to give talk 
about. And I know, you have! :-) 

The submission of presentation proposals is open until Aug 9th.

https://www.qt.io/blog/call-for-presentations-for-qt-world-summit-2021

Cheers!

--
Vladimir 

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

Re: [Development] Mirror IRC channels on KDE's Matrix Instance

[Vladimir Minenko]

I also use Element (on MacOS) since the Qt CS times. Here are some hints from 
my experience. For the Qt CS, I created an account on 
matrix.org and added it to Element. This is a separate 
account, not your KDE account.

Chat channels are called “Rooms” in Element. Searching for Rooms is under Rooms 
-> “+” -> "Explore public rooms”, but the search doesn’t work so well or the 
indexing is not ready for the new mirrored IRC channels yet. I tried to search 
for “qt”, and only the one for Qt Created shows up.

I added channels directly by copy-n-paste from the list in the Cristians’s 
email into the"Explore rooms” field showing up under  "Explore public rooms” , 
e.g. #qt:kde.org . It cannot be found, but you can just hit the 
“join” button and you are done.

I hope this helps!

PS. As a yet another web app, Element eats another 700MB RAM, plus 1.4GB RAM 
for its “renderer" on my mac… 2GB per a web app?… Wow…

—
Vladimir

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

Re: [Development] Nominating Ivan Solovev as approver

[Vladimir Minenko]

+1

Yeah! I had a pleasure to follow some of his works as a new colleague.

--
Vladimir


On 15. Jun 2021, at 13:36, Cristián Maureira-Fredes 
mailto:cristian.maureira-fre...@qt.io>> wrote:

+1

I think Ivan has been doing a really good job,
it would be nice to have him as an approver!

Cheers

On 6/15/21 1:17 PM, Alex Blasche wrote:
Hi,
I'd like to nominate Ivan Solovev as an approver for the Qt Project.
Ivan has been working on various parts of the Qt6 port and has regularly 
contributed to QtBase  modules, QtPositioning, QtNfc & other modules. 
Personally, I am particularly thankful for his help in furthering the Qt 
Bindings support in QtPositioning and his review of countless other patches in 
the same domain.
He has authored the following patches:
https://codereview.qt-project.org/q/owner:ivan.solovev%2540qt.io,100
and reviewed the following:
https://codereview.qt-project.org/q/reviewer:ivan.solovev%2540qt.io,100
Since  both our office rooms share one wall I am also thankful for many 
technical discussions who broke the enforced solitude of the corona days :)
--
Alex
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

--
Dr. Cristián Maureira-Fredes
R&D Manager

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin

Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
___
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] [Announce] Qt Automotive Suite 5.15.0 Released

[Vladimir Minenko (talking to machines)]

I’m very happy to see this release of Qt Auto finally going out to the public! 
And I’m very proud about all the things being done in this release! Best 
tributes and thanks to all who contributed to it and made it going out! 

Cheers!

—
Vladimir


From: List for announcements regarding Qt releases and development 

Reply: development@qt-project.org 
Date: 2. September 2020 at 17:55:10
To: List for announcements regarding Qt releases and development 
, releas...@qt-project.org 
Subject:  [Development] [Announce] Qt Automotive Suite 5.15.0 Released  

Hi everyone!  
   
I am happy to announce that Qt Automotive Suite 5.15.0 has been released.  

Check the blog post for more details,  
https://www.qt.io/blog/qt-automotive-suite-5.15.0-released  
   
Big thanks to everyone involved!  
   
br,  
Jukka Jokiniva  
Release Manager  
The Qt Company  
   


___
Announce mailing list
annou...@qt-project.org
https://lists.qt-project.org/listinfo/announce
___
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] Marking BB10 unsupported

[Vladimir Minenko]

On 24/03/15 09:04, Blasche Alexander wrote:
> The BB10 code in Qt is not just the platform plugin. Does this
> statement apply to all other BB10 code throughout other Qt modules?

Following this question from Alex, and actually asking more Rafael. What 
do you mean exactly with "mark the BlackBerry 10 platform unsupported"? 
Which problem do you like to solve?

> To mind comes sensors, qtlocation, bluetooth, nfc and maybe
> multimedia.

On top of this, the current implementation of QPA for BB10 is very much 
interlinked with the QNX one, it is basically almost the same.

While clarifying which problem will "mark the BlackBerry 10 platform 
unsupported" actually solve, I just want to warn that making actual 
changes in code in that respect will result in quite some work. I'm not 
sure if somebody in the project has that much time for this.

> And just out of curiosity, how do I distinguish QNX from BB10.The
> line is often very blurry.

Indeed. It is just as easy as on other platforms which have used a core 
OS and have added middleware and apps on top. Do you know the way how to 
distinguish Linux from Andriod which runs on top of it?

Generally, there are defines set by configure which let you check you 
you run on pure QNX or on BB10.

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

Re: [Development] Deprecating BlackBerry Playbook support

[Vladimir Minenko]

+1

This was in discussion for a while anyway...

--
vm

On 09/02/15 08:19, Knoll Lars wrote:
> No objections from my side. Unless someone else raises a very good
> argument (I can’t see what that would be) within the next 48 hours, please
> go ahead.
>
> Cheers,
> Lars
>
> On 06/02/15 16:55, "Rafael Roquetto"  wrote:
>
>> Hello,
>>
>> Unless anyone is willing to help, I would like to propose deprecating and
>> consequently removing BlackBerry Playbook code from Qt sources.
>> This would mainly affect the QNX plugin.
>>
>> Reasons:
>> - the Playbook NDK is old and its compiler does not keep up with
>> newest
>>   C++11 improvements inside Qt Code.
>> - the Playbook NDK diverges considerably from the standard BB10 NDK,
>>   making it non-trivial to keep a common codebase.
>> - It's a defunct platform.
>> - Maintenance time is limited.
>>
>> If anyone objects, please raise your hands.
>>
>> Cheers,
>> Rafael
>>
>> --
>> Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
>> Klarälvdalens Datakonsult AB, a KDAB Group company
>> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
>> KDAB - Qt Experts - Platform-independent software solutions
>
> ___
> 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] Platform maintainers

[Vladimir Minenko]

In addition to the below, I would suggest adding Rafael Roquetto as a
second maintainer for the QNX platform. Rafael was tightly involved in the
development of Qt5 for QNX and is working on several customer projects
using Qt on QNX.

—
Vladimir

On 26.09.14 14:04, "Vladimir Minenko"  wrote:

>On 25.09.14 12:17, "Knoll Lars"  wrote:
>>QNX is open for the moment, I’d love to hear proposals.
>
>I propose Bernd Weimer for this role. Bernd has a long-term experience
>working with Qt in general and was developing many core elements of the
>current QPA for QNX. I know only very few other persons who know this code
>at a comparable level and/or worked on it that much.
>
>https://codereview.qt-project.org/#/q/owner:bweimer,n,z
>
>—
>Vladimir
>
>___
>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] Platform maintainers

[Vladimir Minenko]

On 25.09.14 12:17, "Knoll Lars"  wrote:
>QNX is open for the moment, I’d love to hear proposals.

I propose Bernd Weimer for this role. Bernd has a long-term experience
working with Qt in general and was developing many core elements of the
current QPA for QNX. I know only very few other persons who know this code
at a comparable level and/or worked on it that much.

https://codereview.qt-project.org/#/q/owner:bweimer,n,z

—
Vladimir

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

Re: [Development] Harmonizing the Qt 5.x Documentation

[Vladimir Minenko]

On 12.03.14 10:37, "Pasion Jerome"  wrote:
>1) The 5.0 and 5.1 documentation are already in the archives:
>http://doc.qt.digia.com/qt-5.0/qtdoc/index.html
>http://doc.qt.digia.com/qt-5.1/qtdoc/index.html
>The links to them will be published soon (around the time the redirects
>will be in place) here: http://doc.qt.digia.com/archives/index.html

Just to give a brief user feedback. Not sure the above really helps, at
least not right now. Google does not like any of those links. A search
query "site:doc.qt.digia.com/qt-5.1/ QString" returns an empty page, where
is it works as expected with "site:qt-project.org/doc/qt-5.1 QString".
Generally, the best search result for "QString" on Google is from Qt 4.7
and "Qt Platform Abstraction" comes only from
qt-project.org/doc/qt-5.0/qtdoc/qpa.html‎ as if QPA was dismissed from 5.1

Using Google for a detailed search is for now, IMHO, the most efficient
approach since it is more powerful than the search in docs in Qt Creator,
plus a direct navigation through pages does not get you to all articles
since some of them do not get linked well for some reasons. The mentioned
Chrome plugin is interesting in that context.

I hope the harmonization steps will make this better. Thanks!

--
Vladimir

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

[Development] Does Qt need a unified, cross-platform app deployment for devices and desktops?

[Vladimir Minenko]

Hello all,

I just wanted to bring up for a discussion an enhancement which concerns not 
only BlackBerry 10 as a platform, but also other platforms Qt runs on as well.

We recently submitted the change 
https://codereview.qt-project.org/#change,75441 (still WIP) which allows a Qt 
developer on BB10 just to do "make deploy" on a random .pro file to get that 
project packaged and deployed in a BB10 device without any additional typing. 
BB10 has already a full integration for these steps Qt Creator. The above 
change targets to significantly simply steps required on the command line. This 
is not only for those who (still) use the command line, but also for a CI 
system which would be able to automatically create and deploy test apps and 
unit tests in a cross platform manner and without "insider hacks".

In the course of discussions on Gerrit wrt this change, there was a feedback 
that a unified cross-platform solution would be much better than a yet another 
deployment tool. No doubts, such a solution would be great in the future, and 
this is the reasons for this email. I just hope this does not block us making 
Qt on BB10 a comfortable development environment.

A quick run over available information feeds [1] shows that basically only 
Android and BB10 have a one-go deployment infrastructure for apps. Others are a 
kind of an independent task to get done in addition to application development 
without any cross-platform support from Qt.

So the question is if owners/maintainers of all platform see this need and we 
can agree targeting some unification done in a future Qt release.

[1]:

Mac desktop:
http://qt-project.org/doc/qt-5.0/qtdoc/deployment-mac.html
iOS:
http://blog.qt.digia.com/blog/2013/03/05/qt-for-ios-preview/
Win desktop:
http://qt-project.org/forums/viewthread/25714
Win RT:
http://blog.qt.digia.com/blog/2013/06/14/introduction-to-windows-rt-frameworks/
Android:
http://blog.qt.digia.com/blog/2013/10/09/android-deployment-in-qt-5-2/
Linux:
http://qt-project.org/doc/qt-5.0/qtdoc/deployment-x11.html
BlackBerry 10
http://qt-project.org/doc/qtcreator-3.0/creator-deployment-bb10.html


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request for new Playground Repo

[Vladimir Minenko]

On 21.11.13 10:03, "Kevin Krammer"  wrote:

>On Wednesday, 2013-11-20, 19:36:00, Andrew Wooster wrote:
>> Hi, I'd like to request the creation of a new playground repository.
>> 
>> Name: BlackBerry Extras
>> 
>> Description: A repository for creating BlackBerry specific APIs that are
>> useful for implementing Qt functionality.
>> 
>> Let me know if there are any questions.
>
>Since I saw PPS being mentioned as one of the extra APIs, isn't that also
>available on stock QNX?

Yes, it is. We can target to make a new API for PPS which would unify
advantages of all current implementations and approaches. Still the fact
remains that a few things work on bare QNX in a different way than on BB10
because the latter is a complete application platform and the former is
just a pure OS.

>I.e. would it make sense to follow the naming used for the QPA or is the
>plan 
>to mostly add BB specific APIs?

Does this mean considering QNX are a "core platform" and BB10 sitting on
top of it? This sounds sensible.

--
vm

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request for new Playground Repo

[Vladimir Minenko]

We actually have got a few more APIs which we would move to that
repository either right now, or later when it becomes an add-on. Some of
those APIs need to go under a review to sort our what would be the place
to put them in.

For now, we are asking for a home to start with.

Cheers!

--
Vladimir

On 20.11.13 23:47, "André Pönitz"
 wrote:

>On Wed, Nov 20, 2013 at 07:51:34PM +, Knoll Lars wrote:
>> On 20/11/13 20:36, "Andrew Wooster"  wrote:
>> 
>> >Hi, I'd like to request the creation of a new playground repository.
>> >
>> >Name: BlackBerry Extras
>> >
>> >Description: A repository for creating BlackBerry specific APIs that
>>are
>> >useful for implementing Qt functionality.
>> >
>> >Let me know if there are any questions.
>> 
>> If the purpose is the same as the other QPlatformExtras modules, I¹m
>>happy
>> to add it.
>
>I am not.
>
>The general approach is wrong, for several reasons:
>
>1. Splitting the platform extras already on the module level means that
>everybody who wants to use some of the extras even buried behind #ifdef's
>somewhere deep in his code has to add platform specific conditional code
>like
>
>   !isEmpty(QT.x11extras.name) {
>QT += x11extras
>DEFINES += I_CAN_USE_X11EXTRAS
>} else {
>warning("x11extras module not found, ")
>}
>
>to his buildsystem(s), for each of the platforms he want to "fully"
>support. This is a maintanance burden not just for the buildsystem itself
>but also extends to conditional packaging/installation.
>
>2. The setup is inherently fragile as only part of the code is used, and
>part
>not even checked on a specific developer's machine at a time, bearing the
>risk of the classic "compile fix" or "CI" "ping pong".
>
>3. The approach does not scale as it does not offer a natural place for
>features that are not available on all platforms, but on more then one.
>Putting random sort-of-sharable code into qtbase is not a good alternative
>either.
>
>
>There is no perfect solution, but the further "down" the conditionals
>are in the code the less impact they have on all three aspects, and
>the more code can be shared between the "backends".
>
>Merging the platform into a single module with fat #ifdefs QT_OS_XYZ
>in the headers would already alleviate the problem on the build system
>level, and upwards (packaging...), while providing the same interface
>to the actual code. That'd be a uniform improvemnt over the current setup.
>
>Andre'
>___
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Where and how does Qt define which platforms are supported?

[Vladimir Minenko]

Hi all,

during one of the last release meetings, we had a chat about "Tier 1" or 
reference platforms. I mentioned that IMHO the "Tier 1" notion known in Qt 
prior Qt5 is not used in Qt5 anymore. I was not able to provide references off 
the top of my head, and now I took some time to collect references. I post it 
now to the dev list to get feedback/opinions from all.

Since I was missing a reliable navigation, I used a search on Google with a 
limit in its scope:

* site:qt-project.org/wiki
* site:doc-snapshot.qt-project.org/qt5

I observed the following:

* The Qt5 documentation does not use the "Tier" notion to define levels of 
platform support. At least Google does not find the word "Tier" in docs. A grep 
over the entire source code of most modules does not bring any results either. 
Instead, "reference configurations" are defined: 
http://doc-snapshot.qt-project.org/qt5-nosubdir/supported-platforms.html

* The Qt Project wiki does know "Tier 1", but in turn, it does not know 
"reference configurations". Plus, it provides its own version of related 
definitions: http://qt-project.org/wiki/Platform_Support, including a dead link 
to Qt docs (I was about to correct it, but did find that page in docs anymore). 
The wiki also mentions the key word "Tier" on a few other pages, e.g. 
http://qt-project.org/wiki/Qt-Quality-Gate-Criteria

* Still, the context of Qt5 apparently has some traces of the "Tier" 
definition, e.g. it names Windows Embedded Compact 7 a Tier 2 platform, see 
http://qt-project.org/wiki/New-Features-in-Qt-5.1

Finally, a search over emails on the dev list 
(site:lists.qt-project.org/pipermail/development) brings more 
classifications/proposals:
http://lists.qt-project.org/pipermail/development/2012-November/007876.html

The purpose of this email is not to point out something what is not done or 
wrong. The purpose of this email to initiate a discussion and a work to get 
this done and create a clear definition where Qt runs on and how related 
platforms are classified.

Opinions/feedback? Who is going to join a work on this? Can this topic get on 
the todo list for the final 5.2 release?

Thanks!

--
Vladimir
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Please reschedule and review QTBUG-3786: QThreadPool synchronization defect in expiration mechanism.

[Vladimir Minenko]

Hi,

We are working on a very strange issues occurring in the QThreadPool and 
suspect the below is related:

https://bugreports.qt-project.org/browse/QTBUG-3786

Just recently there was a comment that this bug still occurs in 4.8.4.

It would be more than very helpful if somebody will review the status of this 
(open for three years) and update the report accordingly.

Thanks!

--
Vladimir Minenko
Technical Manager Qt, BlackBerry
http://developer.blackberry.com/qt
+49 160 9898 3242

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Setting the priority of bug reports created the Qt Support team

[Vladimir Minenko]

On 19.02.13 18:25, "Frederik Gladhorn"  wrote:
>See also my mail from two weeks ago ([Development] issue tracker rights).
>
>I think we need to make a few more adjustments and really need more
>people 
>with bug triaging rights.

Actually, there is a good reminder, since there were others concerns with
the way how bugs are currently triaged. Peter was commenting about labels,
for example.

I would like to bring up another aspect. We (Qt in BlackBerry) are
strongly considering to move known Qt issues from an internal tracker into
https://bugreports.qt-project.org/ and later on, redirect Qt related
issues reported by BackBerry developers into BlackBerry
https://bugreports.qt-project.org/ as well.

Our motivation for this is very simple: keep Qt bugs going to one place
and avoid fragmentation.

Handling a few BlackBerry related issues which were already posted on
https://bugreports.qt-project.org/, I started doubting if we can really
use https://bugreports.qt-project.org/ for operations. The major problem
is that the only what a normal user do is commenting on bugs. I know this
topic is not directly related to the actual posting by Andy. I just wanted
to raise my hand and underline that there are more triage related problems
with https://bugreports.qt-project.org/

-- 
Vladimir Minenko

Technical Manager, Qt
http://developer.blackberry.com/qt
+49 160 9898 3242


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How and when recent 4.8 docs will be published on http://qt-project.org/doc/qt-4.8

[Vladimir Minenko]

On 17/01/13 14:51, Giuseppe D'Angelo wrote:
> http://doc-snapshot.qt-project.org/4.8/qsettings.html is instead
> recreated nightly or so, so you'll see the note added in that commit.

Aha! Ok... How should one know that the docs on 
http://qt-project.org/doc/qt-4.8/ are from 4.8.4? In the older days the 
html templates used to have a footer with the release number. This 
footer war not retained when the new style was applied.

Should I file a bug for this to keep this on the radar?

Btw, Google seems to not like http://qt-project.org/doc/qt-4.8/

The first hit in search for QSettings returns this page:

http://doc.qt.digia.com/qt/qsettings.html

The URL http://doc-snapshot.qt-project.org/4.8/qsettings.html is not 
even on the top 100. I think there is something wrong that web pages.

PS. Not sure if you know, but according some research in Qt some time 
back in the past, by far more than half of developers use web search to 
find Qt docs...


--
Vladimir


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] How and when recent 4.8 docs will be published on http://qt-project.org/doc/qt-4.8

[Vladimir Minenko]

Hi folks,

it looks like the docs published on http://qt-project.org/doc/qt-4.8 are 
far behind the actual 4.8 status.

For example this change

https://codereview.qt-project.org/#change,40308

is not yet reflected in

http://qt-project.org/doc/qt-4.8/qsettings.html

We are now working to publish more details and update the current pages 
(see my signature) about Qt on BlackBerry 10. One choice is certainly to 
copy the docs we need into our site, but this is by far not the best 
choice, since it will fragment docs. This was the case for the docs in 
Cascades, and I would like to find a better way to Qt as while in the 
native SDK of BlackBerry 10, e.g. using links.  I cannot use links to 
http://qt-project.org/doc/qt-4.8 since the content is outdated.

I know there were several difficulties in the past in the docs domain, 
but we need this to start getting better, for 4.8 too.

Any comments? Do I miss something?

--
Vladimir Minenko
Technical Manager, Qt
http://developer.blackberry.com/qt
+49-160-9898-3242

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious

[Vladimir Minenko]

> Sounds reasonable.
> Laszlo

Folks, how can we conclude on this?

There were two votes "Sounds reasonable", one comment with doubts from Tuukka 
and one more "natural" from Sergio.

How do we proceed now? More comments? Some details for the expressed doubts? 
Some actions?

Thanks!

--
Vladimir


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] Bumping Qt 4 version to 4.8.5

[Vladimir Minenko]

> I agree with Ossi. Your request doesn't make sense, Vladimir.
> 
> If you're taking the latest 4.8 branch instead of the released packages, 
> you're
> in for a lot more trouble. I suggest creating your own branch based on
> 4.8.4 and cherry-picking any commits you need into it.

Ok... Well, I can also ask a good question why you bump the version to 4.8.5 
before it is actually released. You probably will have a good answer, likewise 
I will also have a good answer why bumping the version disturbs our integration 
right now. But, all this does not help by the end of the day...

In short, 1) we cannot wait for official 4.8.x releases and work directly on 
the master, 2) we have no time for manual cherry-picking into an internal 
branch and decided to take all commits as long as a snapshot passes our testing.

As mentioned in my previous email, changing the version of Qt changes the 
version of the so libs, which we have to reflect while building device images. 
Sometimes, there is just no time for this, and an entire update of Qt in 
BlackBerry 10 is in danger to get stuck. We currently just cannot afford this! 

Fine, we will just revert that commit if needed... Anyway, we had a chance to 
hear about this on-time. This is good. Previously, it was rather a surprise...

Cheers!

--
Vladimir

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] Bumping Qt 4 version to 4.8.5

[Vladimir Minenko]

> After yesterdays release we are planning to bump the Qt 4 version to 4.8.5.

Guys, would it be a big problem to wait with this until the end of this week? 
We are releasing the final NDK this week and a change in the version is will 
cause trouble. We will definitely revert it internally which will bring Qt in 
the NDK out of sync with the upstream Qt...

Please wait! 

Thanks a lot in advance!

--
Vladimir

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Who is administering Gerrit/Codereview?

[Vladimir Minenko]

Hi,

Who can be contacted concerning problems with an account on 
https://codereview.qt-project.org?

One of my colleagues has problems to register an email address for his account. 
The server returns Application Error - Server Error - Invalid Token after the 
click on the confirmation link.

Please let me know.

Thanks!

--
Vladimir Minenko
Technical Manager, Qt
+49-160-9898-3242



-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] FW: Digia and the comunity for Qt

[Vladimir Minenko]

Forwarding this from the marketing list.

I think folks who commented on "Blurring the lines between Qt-Project and 
Digia", but not subscribing to the Marketing list, might be interested in 
reading this.

Cheers!

--
Vladimir

From: marketing-bounces+vminenko=rim@qt-project.org 
[mailto:marketing-bounces+vminenko=rim@qt-project.org] On Behalf Of Barrios 
Katherine
Sent: 15 October 2012 13:20
To: market...@qt-project.org
Cc: Yrvin Knut; Verma Gurudutt
Subject: [Marketing] Digia and the comunity for Qt

Hi all,

I thought I would write a short note to let everyone know that, we at Digia, 
haven't forgotten about the community and definitely want to work together with 
you to help promote Qt.

We have started a project to look for community moderators for our social media 
channels. Since we have an incredibly small marketing team compared to what 
Nokia had and no web community people, this will take some time, and we 
therefore, need your help.

That said, as we are evaluating all the channels, unfinished projects, projects 
in the works and more from what we inherited from Nokia, we can't move as fast 
as we would want.

Please note that we don't want to in any way make the Qt channels and 
promotions, Digia only. This is a misconception and has never been the intent.

Let's continue the conversation on how to promote Qt together via this Qt 
Project marketing mailing list.

Thanks and regards,
Katherine

Digia, Qt

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Greetings from RIM and from Qt on BlackBerry 10

[Vladimir Minenko]

Hello all,

I now finally took some time to drop this message to all who work on Qt. There 
are a few reasons why not any earlier and why now.

First of all, congratulations to Qt with the new home! I am sure, Digia will be 
a very good home with many exciting possibilities!

Also congratulation with 4.8.3! Even though there was a bump for RIM in the way 
how it was released (other story), Qt 4.8.3 is big news for in another sense.

Qt 4.8.3 is going to be the first functional release of Qt on BlackBerry 10. We 
are currently working on a new public beta release of BlackBerry 10 which is in 
preparation for BlackBerry Jam Americas next week. Yes, it was possible to load 
Qt apps on Playbook, but Qt was not integrated in the Playbook device firmware 
and apps are not accepted in the AppWorld (for now).

This is different with BlackBerry 10. Qt is there and you can use it for apps 
development. I certainly count Qt Quick here too, btw. All this will be very 
beneficial for Qt running in QNX in general, which is the base of BlackBerry 
10. Quite some people worked very hard to make it happen... This is one of the 
reasons, why it was so silent after our talks on Qt Contributor Summit in 
Berlin this summer. And writing this, I would like to mention folks from KDAB. 
They did a master job for Qt on BlackBerry 10 and QNX!

Another interesting fact to mention is that RIM now has a dedicated Qt team 
instead of various folks scattered across the company and taking care of Qt on 
part-time basis. Qt is much too important for BlackBerry 10 and needs a real 
team. It is really "real" now, since from the beginning of September we are 5 
persons with quite some open positions.

There are still more than many things to do. Hm, as usually... One of the most 
important areas is to get a proper home for Qt on RIM's developer pages in 
addition to our wiki on Qt-Project.org (http://qt-project.org/wiki/BlackBerry) 
and the new group http://qt-project.org/groups/qt-blackberry-and-qnx .

Enough stories, back to work!

Have a nice evening/day/morning! :-)

Cheers!

--
Vladimir Minenko
Technical Manager, Qt

Research In Motion
Central Tower, level 15
Landsberger Str 110
80339 Munich
Germany




-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development