Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January

[Vlad Stelmahovsky]

you guys getting "famous":
https://www.theregister.com/2021/01/05/qt_lts_goes_commercial_only/

On Wed, Jan 6, 2021 at 12:15 PM Volker Hilsheimer 
wrote:

> > On 5 Jan 2021, at 21:18, Max Paperno  wrote:
> >
> > On 1/5/2021 1:02 PM, Adam Light wrote:
> >> On Tue, Jan 5, 2021 at 7:56 AM Volker Hilsheimer <
> volker.hilshei...@qt.io > wrote:
> >>Apart from that: is Qt 5.15.2 really so broken that people can’t use
> >>it without getting more patches?
> >> I can't speak to 5.15 as we decided not to upgrade since it's not a
> real LTS release (we do not believe we are eligible to purchase a
> commercial license), but the minor fixes that come later in LTS releases
> (5.9 and 5.12) have often fixed problems our users have reported in our
> application, particularly on macOS. Due to behavior changes in different Qt
> minor versions (again, primarily on macOS), we typically change the Qt
> minor version only when we release a new major version of our application
> (~every 2-3 years).
> >> LTS releases have been critical in our successful use of Qt, and I am
> not sure what will happen moving forward.
> >> Adam
> >
> > Hear, hear.  Stuck on 5.12 here.
> >
> > Working on OS projects, commercial is not even an option, and resources
> (e.g. for testing/fixing on every new Qt release) are very limited (read:
> one person often does everything). E.g. testing one app on 5.14.1 yielded 3
> breaking Qt issues which had to be fixed upstream, and mostly didn't make
> it into .2 either. LTS (after like a .3 or so update) is the only way to go
> IMHO, the others are for testing/playing.
> >
> > I'm so sick of "scheduled releases come hell or high water" in the
> programming world (in general, not just Qt).  The quality is (usually)
> crap.  Once upon a time this release quality was called
> Alpha/Beta/Preview/NFP (not for production).  Qt6 has literally been called
> as being "primarily" for testing/feedback.  That's a new major release
> now?  /further rant aborted
> >
> > Sorry, I'm only passionate about it because I love what Qt does and I
> love when it does it well and consistently.  Everyone who's helped make it
> that way is my hero, thank you!
> >
> > -Max
>
>
> Hi Max and Adam,
>
>
> What can do better to avoid such regressions from making it into a
> release, or preferably into the code, in the first place? Nobody, not even
> the Qt Company management :P *wants* to release crappy quality on time.
>
> What we know about those bugs is that they passed all code reviews, and
> didn’t get caught by any of the thousands of tests we run for every change
> on half a dozen platforms. And we know that the only way they were
> discovered is real users testing real applications against the released
> version of Qt.
>
> So, what we have is clearly not good enough, but if the last 15 years of
> writing unit tests etc hasn’t gotten us to a better place, then maybe “more
> of the same” can’t be the only strategy.
>
> Is your experience that we release stuff “come hell or high water" in
> spite of severe bugs being reported during beta testing? We do spend a lot
> of time triaging incoming bug reports, and a severe enough bug can always
> block a release.
>
> Or do we not discover the issues until the .0 release because few people
> test the pre-releases? That seems to be supported by the data we have about
> downloads and general activity in response to pre-releases.
>
>
> Volker
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>


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

Re: [Development] QML 3 and JavaScript

[Vlad Stelmahovsky]

sounds promising :->

On Mon, Nov 11, 2019 at 7:11 PM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:

> Il 11/11/19 11:31, Kevin Kofler ha scritto:
> > So, whereas we C++ developers get to deal with all the deprecations and
> > porting for Qt 6, QML developers can just stick to QML 2 forever and keep
> > their code completely unchanged because you are going to maintain the
> entire
> > old QML 2 for them??? How is that fair?
>
> Who said that no QML 2 behaviors will get deprecated? :-P
>
> Cheers,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>


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

Re: [Development] Why does Q_ENUM() need qRegisterMetaType()?

[Vlad Stelmahovsky]

isn't Q_ENUM is deprecated and now Q_ENUMS should be used instead? or vice
versa...always forgetting :)

On Thu, Jul 4, 2019 at 4:14 PM Olivier Goffart  wrote:

> On 04.07.19 12:43, Tom Isaacson wrote:
> >> The problem is that moc only generates the code that calls
> qRegisterMetaType if it sees Q_DECLARE_METATYPE. Actually, it does a bit
> more than that. It could as well do it for Q_ENUM type, just not
> implemented yet.
> >>
> >> We should consider doing it for all the types used in
> signals/slots/properties.
> >>   But it does not do it because that could be a potential breaking
> change for forward declared types.
> >> Maybe something for Qt6.
> >
> > It's very confusing. You said yourself on
> https://woboq.com/blog/q_enum.html that "These enums are automatically
> declared as a QMetaTypes (no need to add them in Q_DECLARE_METATYPE
> anymore)." So Q_ENUM replaces Q_DECLARE_METATYPE and provides additional
> functionality but requires you to add an additional call to
> qRegisterMetaType? That seems backward.
>
>
> I know, the whole story behind Q_DECLARE_METATYPE and qRegisterMetaType
> is a
> bit confusing.
>
> Regarding Q_ENUM specifically, it could be fixed in moc, to be in the list
> of
> the type that are declared.
>
>
> > Can I use Q_DECLARE_METATYPE and Q_ENUM and avoid qRegisterMetaType?
>
> Yes, youu can use both Q_DECLARE_METATYPE and Q_ENUM
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>


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

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Vlad Stelmahovsky]

nope, there is QML interface

On 1/10/19 2:22 PM, Uwe Rathmann wrote:

On Thu, 10 Jan 2019 13:24:14 +0100, Vlad Stelmahovsky wrote:


Qwt is nice but supports only QWidgets, right?

True, but Qt/Charts is also QWidgets only.

Uwe

___
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] Requesting a repository for Lottie-Qt implementation

[Vlad Stelmahovsky]

Qwt is nice but supports only QWidgets, right?

so any mobile or Desktop/QML is not supported. Probably this is one of 
the reasons


and its not HW accelerated

On 1/10/19 1:00 PM, Uwe Rathmann wrote:

On Thu, 10 Jan 2019 10:48:37 +, Tuukka Turunen wrote:


Related to your comment about the Qt Charts being limited I would tend
to disagree.

https://www.qtcentre.org/threads/69718-QChartView-and-QScatterSeries-
overrdide-the-label-of-a-QPointF

https://www.qtcentre.org/threads/69094-3D-Plot

I leave it up to you to google for more ...

You might have noticed, that questions on the Qt mailing lists regarding
Qt/Charts mostly end up in not being answered, but at least you find this
statement from the maintainer:

https://lists.qt-project.org/pipermail/development/2016-November/
055337.html

If you prefer "simple charting" or "not be the be-all-end-all charting
solution" over "limited" - I don't care, we can agree on Miikkas wording.

But it doesn't affect my conclusion, that Qt users ( including your
customers ) would have a better solution, if you would have contributed
to an existing 3rd party library instead of reinventing the wheel.


Discussion about Qt Charts is of course welcome, but perhaps not that
relevant for discussion about creating a new repository for Lottie-Qt.

True, but Qt/Chart is a good example of what happens, when ignoring
existing 3rd party software without technical reasons.

And on a more general note: if LGPLv2+ makes code not being appropriate
for the Qt project, then don't be surprised that you are not attractive
for developers without having a business case in mind.

My 2 cents,
Uwe

___
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] QTBUG-61258 and Qt3D status

[Vlad Stelmahovsky]

>I will rewrite my software with another tool again...

good luck with that

On 12/28/18 5:37 PM, anton wrote:

I was considering using Qt and
I even did a prototype of a mostly working tool half a year ago.

But looking at the strange development culture and quality attitude
I think I give it up.

I will rewrite my software with another tool again... too much surprises
in Qt.

Your story is only one of similar ones.

This is sad, because I really would like to use Qt and I like KDE as one
example.

Greetings
Anton

Am 14.12.18 um 14:07 schrieb Massimo Callegari:

Hi devs,
I hate to write these emails, but Jira and Gerrit don't really work for
me. (and at this point I suspect I definitely have BAD luck)

The question this time is: what's the deal with Qt3D ?
Since a year or so, submitting Qt3D issues to Jira or even contributing
on Gerrit is like writing to /dev/null. Not even a "please close" is
considered.
I take all the efforts are going on Qt3D Studio, but what about all the
rest ?

Please let me explain what I'm doing.

I run a quite popular open source project called Q Light Controller+
(https://www.qlcplus.org)
It's a software to control stage lighting and it's entirely based on Qt.
Over the years I adopted more and more Qt modules and (here's my bad
luck) I stumbled on every possible Qt bug.
At some point I wanted to find a solution to preview in 3D and in real
time the lighting simulation.
I followed the Qt3D 2.0 developments for years and when I felt it was
mature enough, I started to code the 3D preview.
Since I don't have the necessary OGL skills for what I needed, I was
willing to pay someone to do the job.
I contacted KDAB for an official quotation and they didn't even reply to
me. So I crowdfunded the feature among my users and paid someone else to
develop the 3D techniques.
The bright side is that with Qt3D as it is, we've been able to achieve
this (https://youtu.be/eI_NfA_vyA0) and this (https://youtu.be/yoQVzYR-NwM).
On the other hand, performance sucks and since Qt 5.11, a few
regressions started to kick in.
The blocking one for me is QTBUG-69721. I invested time and effort to
adopt the DAE format, cause it supports named+nested meshes, and it's
XML, so it can be tracked on GitHub.
Since 5.11, meshes can no longer be picked on macOS, so it means I
cannot release any version of my software there. (also cause of broken
video playback on core context QTBUG-51064)

So I evaluated glTF, being another nice open format...and found a disaster.
The current scene import plugin does not conform to the Khronos 1.0
reference samples. Even the "wine" example bundled in Qt3D doesn't work!
So basically Qt is bundling a nearly useless feature.
Plus, Blender 2.80 beta has started to roll, and it finally supports
native export to glTF2.0not supported by Qt3D.
So I spent a few days and got preliminary glTF 2.0 support. With PBR
materials it looks pretty awesome! (see screenshots in QTBUG-61258)
I submitted my code to Gerrit
(https://codereview.qt-project.org/#/c/247080/) and invited as many
reviewers as possible.
Almost 2 weeks passed and I got ZERO comments/reviews by any Qt
Company/KDAB developer.
I mean, don't you want it? Not even in Qt3D Studio?

This is very discouraging for developers like me who spend their time
trying to improve Qt.
If this attitude keeps going, I will end up not contributing at all in
the future, and I suppose I'm not alone on this.

So, once again, what's the deal with Qt3D?

Please explain, cause to me it looks in a quite abandoned state right
now. (management-wise speaking)
Thanks,
Massimo

___
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] qml TextField in material design has too short bottom line

[Vlad Stelmahovsky]

I can confirm the issue

partial workaround is to assign width to undefined

br,

Vlad

On 12/18/18 3:02 PM, Tomas Konir wrote:

Hi,

I'm using this qml code:

importQtQuick2.12
importQtQuick.Controls2.4
importQtQuick.Window2.12
Window{
visible:true
 title:qsTr("HelloWorld")
TextField{
anchors.fill:parent
}
}
with this result:
textfield.png
You can see too short line below text (should be from start to end of 
window).

Am i doing something wrong or this is expected behavior or a bug ?
(Qt 5.12.0)
Regards
Tom

--
Tomas Konir
Czech Republic


___
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] Build system for Qt 6

[Vlad Stelmahovsky]

you mean "hard to work with"?

On 11/1/18 9:34 AM, Bogdan Vatra via Development wrote:

Hi,

   GN is the closest build system to QBS, the only problem it has it's
controled by Google and these guys are sometime had to work with.

Cheers,
BogDan.

În ziua de joi, 1 noiembrie 2018, la 10:30:01 EET, Nikolai Kosjar a scris:

On 10/29/18 1:17 PM, Lars Knoll wrote:

Given that we are confident we can build Qt 6 with cmake, I believe that
it makes most sense to follow down that route.

Just some observation:

LLVM/Clang is a bigger project using CMake for some longer time and
coincidentally, just now, there is a discussion whether they should add
GN build files to their repositories as, let me quote:

"""
cmake is great for many use cases, but in my opinion local day-to-day
development isn't one of them.
"""

Clang: https://lists.llvm.org/pipermail/cfe-dev/2018-October/060006.html
LLVM: https://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html

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



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

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

Re: [Development] Build system for Qt 6

[Vlad Stelmahovsky]

while I really disappointed with this decision, I dont agree that Qt6 is 
dead because of its build system. we are using Qt not because of qmake


Also, Qbs is open source, so its also not dead.


br

On 10/30/18 10:50 AM, Denis Shienkov wrote:

Hi all, my personal things:

Welcome to the era of stagnation and dinosaurs. The new
"revolutioning" Qt6 will be released semi-dead. It will
be overgrowned with mold, moss and fungi in the form of
CMake. This will not be a new life, but it will be an
attempt to prolong the convulsions.

A real new life could give the QBS, that pushed be a new
branch of the spiral of development. It would stimulate
be the QBS integration with others IDE and etc.

PS: I don't know, what is it: or an "effective management"
or an "evil intent" or an  "CMake lobby", or "not enough
money". Perhaps the thesis that "Millions of flies cannot
be mistaken when they choose shit" works here.

Anyway, RIP QBS, You were a great friend, I never forget you.
I drink Vodka and grieve about the innocently murdered projects
for the sake of conjuncture.

== R I P, QBS ==

IMHO, :(

вт, 30 окт. 2018 г. в 12:08, Richard Weickelt >:



> Qbs is something that has been developed almost exclusively by
The Qt
> Company. As such, TQtC had to also look at it from a business
perspective
> and how it fits into the larger picture of making Qt successful.
To make
> a long story short, while Qbs is pretty cool and interesting
technology,
> it doesn’t really help us expand the Qt ecosystem and usage.

Qbs has made the development of multi-platform applications with
multiple
libraries a breeze for me. Even projects that contain firmware for
different
target architectures in addition to a Qt application are no
problem at all
with Qbs. Thanks to Qbs, I can focus on code and not on the build
system. I
achieve more in less time.

I always thought that Qbs was a great example for using QML.

> To make Qbs really successful would require a rather large
effort and
> investment in promoting it towards the larger C++ ecosystem as a new
> build tool. At the same time it has to be an open source product
to stand
> any chance in the market. Together this makes it challenging for
TQtC to
> see how to recover that investment. Thus this investment would
be at the
> expense of other things we’d like to do, like improving our IDE,
working
> on rearchitecting and cleaning up our core frameworks for Qt 6
or the
> design tooling we are currently investing into. The Qt Company
believes
> that those other investments are more important for the future
of Qt than
> our choice of build tool.

It seems that Qbs never got much traction within the Qt Company
either.
Outside the regular blog posts, I don't see any attempt to promote Qbs
anywhere. Correct me if I'm wrong. I may have noticed that Jake
Petroules
did his best to get the word out, but I guess that was his private
mission
rather than his official role in the Qt Company. What I can't
complain about
is the unprecedented dedication and professionalism of Christian,
Jörg and
Jake on this project. Also all support questions were answered in
lightning
speed.

> As such, we were left with the question on whether we need Qbs
as the
> build system for Qt 6 or whether cmake (as the other
alternative) would
> be up to the task.
> [..]
> Given that we are confident we can build Qt 6 with cmake, I
believe that
> it makes most sense to follow down that route. In case you’re
interested,
> you can have a look at the cmake prototype code for qtbase on
Gerrit in
> the wip/cmake branch. Please also let us know if you’re
interested in
> helping with the effort of porting Qt’s build system over to cmake.
>
> We have been developing Qbs over the last years, and as such are
> committed to it for some more time. We are planning on another
feature
> release in the first quarter of next year and will support it in Qt
> Creator for at least another year. Qbs is open source and if someone
> wants to take over and develop it further let us know as well.
I’d also
> like to use this place to thank Christian and Jörg for all their
great
> work on Qbs  (and of course also anybody else who contributed to
it).

How can we leverage from the next half year to smoothly turn Qbs
into a
community-owned OS project? Does anybody know a positive
role-model for this?

I don't want to miss out on the productivity gains I've made with
Qbs, but
on the other hand I have very little free time. However, I would
voluntarily
contribute to the documentation of Qbs.

Richard


___
Development mailing list

Re: [Development] Build system for Qt 6

[Vlad Stelmahovsky]

feels like you hit the wall at full speed. disappointing :(

On 10/29/18 1:17 PM, Lars Knoll wrote:

Hi all,

As you will probably remember, there have been lively discussions around what 
kind of build tool to use for Qt 6 both during Qt Contributor Summits as well 
as on this mailing list.

There has been a strong consent that we should move away from qmake as our 
build tool for Qt due to many shortcomings and the burden we have maintaining 
the system.

Thiago wrote a set of relatively strict requirements for such a build tool in 
his mail in July. While some of the requirements had a bit of a Linux specific 
background, they have been a good basis.

There have been rather lively discussions around alternatives, but most focused 
around two possible choices for us: Qbs and cmake.

Qbs is something that has been developed almost exclusively by The Qt Company. 
As such, TQtC had to also look at it from a business perspective and how it 
fits into the larger picture of making Qt successful. To make a long story 
short, while Qbs is pretty cool and interesting technology, it doesn’t really 
help us expand the Qt ecosystem and usage.

To make Qbs really successful would require a rather large effort and 
investment in promoting it towards the larger C++ ecosystem as a new build 
tool. At the same time it has to be an open source product to stand any chance 
in the market. Together this makes it challenging for TQtC to see how to 
recover that investment. Thus this investment would be at the expense of other 
things we’d like to do, like improving our IDE, working on rearchitecting and 
cleaning up our core frameworks for Qt 6 or the design tooling we are currently 
investing into. The Qt Company believes that those other investments are more 
important for the future of Qt than our choice of build tool.

As such, we were left with the question on whether we need Qbs as the build 
system for Qt 6 or whether cmake (as the other alternative) would be up to the 
task.

Given that background, we’ve done some more research on using both Qbs and 
cmake to build Qt. Both projects did give us good results but we were actually 
surprised on how far we got with cmake in a rather limited period of time.

In addition, cmake has the advantage of being very widely used in the C++ 
ecosystem (amongst many others by KDE), has a very wide support in many IDEs 
and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of knowledge about 
the build system available in the ecosystem. Using it with Qt 6 would also mean 
that we can focus our support on two build systems for our users (qmake and 
cmake) and we would not have to add a third one to the mix.

Given that we are confident we can build Qt 6 with cmake, I believe that it 
makes most sense to follow down that route. In case you’re interested, you can 
have a look at the cmake prototype code for qtbase on Gerrit in the wip/cmake 
branch. Please also let us know if you’re interested in helping with the effort 
of porting Qt’s build system over to cmake.

We have been developing Qbs over the last years, and as such are committed to 
it for some more time. We are planning on another feature release in the first 
quarter of next year and will support it in Qt Creator for at least another 
year. Qbs is open source and if someone wants to take over and develop it 
further let us know as well. I’d also like to use this place to thank Christian 
and Jörg for all their great work on Qbs  (and of course also anybody else who 
contributed to it).

Cheers,
Lars
___
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] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Vlad Stelmahovsky]

have you tried QOpenGlWidget ?

otherwise you dont have other options: plain QWidget's does not HW 
accelerated


or, you can extend QtCharts to be more QtQuicker and more featured. 
everyone will be happy :)


On 8/29/18 11:39 AM, Denis Shienkov wrote:

Hi all.

I have an Apalis iMX6 board with the Yocto's image with the working 
'eglfs' and 'linuxfb'  backends (without of X11 support).


I need to create a 'pure' QtWidgets application, where I need to use a 
real-time plotting with the Qwt library (using the Qt Quick is not an 
option, as there the QtCharts is not ready for usage) .


But, I'm sadly surprised that a 2D painting takes ~100% CPU loading as 
with the 'eglfs' and as with 'linuxfb' backends. It is not an 
acceptable, because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU 
loading.


Is any workarounds for this? Maybe I need to re-build the Yocto's 
image to enable the X11 'xcb' support?


BR,
Denis



___
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] Qt 5.12 new features

[Vlad Stelmahovsky]

A bit unclear about deprecating QQC1
Since in QQC2 no TreeView and even no plans for this, isn't it a bit too
early to deprecate QQC1?

thanks

On Thu, Aug 16, 2018 at 4:02 PM Jason H  wrote:

> 5.11 included WebGL TP2. Is there any change? Why is it staying TP2, or
> should it be TP3?
>
> 5.12 looks like it'll be a pretty great update!
>
> I'm not sure what's on the agenda for 5.13... but as I mentioned on
> interest, one pain point I continually have is the amount of custom
> platform integrations for mobile. This is one area where Xamrain excels, as
> they have a simple property on an object you can set to control things like
> the status bar visibility, the screen brightness, etc. The downside is the
> Xamarin stuff is all platform-specific so using a iOS property on Android
> won't work. This is one area where Qt can leapfrog the other platforms
> including React Native by being cross platform. Anything that doesn't
> require me to write Obj-C is a very good thing!  I figure this would need
> to be a few Qt Quick/QObject Singletons. Notifications should be supported
> too, and this could also be used for desktop platform notifications as
> well. The notifications support would only need to cover being messaged my
> the platform, and not any display - this would get me out of having to deal
> with Obj-C almost completely. (My beef wi
>  th ObjC is other than being not good at it, is whatever I'm writing isn't
> cross-platform. Java I am more comfortable with, so I complain less, but I
> still cringe on the non-portability!)
>
> Looking forward to 5.12!
>
> > Sent: Wednesday, August 15, 2018 at 12:50 AM
> > From: "Jani Heikkinen" 
> > To: "development@qt-project.org" 
> > Subject: [Development] Qt 5.12 new features
> >
> > Hi,
> >
> > Qt 5.12 Feature Freeze will be in effect Mon 20th August and we should
> have already now pretty good understanding what is new in Qt 5.12. So
> please update 5.12 new features page here:
> https://wiki.qt.io/New_Features_in_Qt_5.12
> >
> > br,
> > Jani
> >
> >
> >
> >
> >
> > ___
> > 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
>


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

Re: [Development] Stepping down as maintainer

[Vlad Stelmahovsky]

JavaScript easier

On Mon, Mar 19, 2018 at 1:59 PM, Denis Shienkov 
wrote:

> Hi all,
>
> As I can see recently, is is not a good tendence in Qt... Many peoples
> leaves from Qt.. What happens? Or I'm mistake? :)
>
> 19.03.2018 15:39, Gunnar Sletta пишет:
>
> Hi,
>
> After quite some time of not being active in Qt, I am now formally stepping 
> down as maintainer. It has been a great ride, but I simply don't have time to 
> follow up Gui and Scene Graph and it makes sense that the people who are 
> active in these areas also become the go-to guys.
>
> I've already spoken with Eskil and Lars, and propose the following list of 
> people to formally take over my areas:
>
> Tor Arne Vestby - QPA and window system integration
> Laszlo Agocs - OpenGL/Vulkan
> Eirik Aavitsland - Image Formats and QPainter
> Andy Nichols - Scene Graph
>
> (Other specific maintainers in QtGui stay unchanged)
>
> Thanks,
> Gunnar
> ___
> Development mailing 
> listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>


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

Re: [Development] [BB++] Now is 3.5x faster than Node.JS

[Vlad Stelmahovsky]

over C++ ??

On Sat, Jul 22, 2017 at 5:43 PM, Phil Bouchard <philipp...@gmail.com> wrote:

> On 07/22/2017 05:52 AM, Vlad Stelmahovsky wrote:
>
>> Phil,
>> Can you please explain benefits of having C++ -> WebAssembly ?
>>
>
> Assembling speed (about 20% faster) and execution speed (about 3.5x
> faster):
> http://webassembly.org/docs/faq/
>
>
> Regards,
>
> -Phil
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



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

Re: [Development] [BB++] Now is 3.5x faster than Node.JS

[Vlad Stelmahovsky]

Phil,
Can you please explain benefits of having C++ -> WebAssembly ?

thanks

On Fri, Jul 21, 2017 at 5:48 PM, Phil Bouchard  wrote:

> On 07/21/2017 02:10 AM, Lorn Potter wrote:
>
>>
>> On 21 Jul 2017, at 2:22 pm, Phil Bouchard  wrote:
>>>
>>>
>>> So I would like to know if Qt thinks what I am proposing (BB++ -> C++ ->
>>> WebAssembly) is a good plan.
>>>
>>
>> What does this have to do with Qt?
>>
>
> For a web engine I don't think it's possible to swap the Javascript engine
> entirely but it is possible to introduce the BB++ -> C++ -> WebAssembly
> sequence.
>
> For the QML / Javascript dual then it could be replaced by with the QML /
> BB++ dual and, which harness the power of C++14 and Root.Ptr and we can
> just let the compiler do the hard work.
>
>
> Thanks,
> -Phil
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



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

Re: [Development] dev doesnt builds

[Vlad Stelmahovsky]

In my desperate attempt to build it I even re-clone whole qt5 repo from
scratch. still doesnt works

On Thu, Sep 22, 2016 at 4:37 PM, Alexander Blasche 
wrote:

> Hi
>
> >Cannot read .qt5/qtbase/src/corelib/qtcore-config.pri: No such file
> or directory
> >Cannot read .qt5/qtbase/src/gui/qtgui-config.pri: No such file or
> directory
> >Project ERROR: Could not find feature system-zlib.
> >Makefile:45: recipe for target 'sub-src-make_first' failed
> >make[1]: *** [sub-src-make_first] Error 3
> >make[1]: Leaving directory '../qt5/qtbase'
> >Makefile:78: recipe for target 'module-qtbase-make_first' failed
> >make: *** [module-qtbase-make_first] Error 2
>
> >is there a workaround for this?
>
>
> I had the same problem. Make sure that you have an up-to-date qt5.git
> checkout for dev as well. In combination with git clean the problem solved
> itself for me.
>
> --
> Alex
>



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

[Development] dev doesnt builds

[Vlad Stelmahovsky]

Hi

trying build dev branch and got this error all the time:


Cannot read .qt5/qtbase/src/corelib/qtcore-config.pri: No such file or
directory
Cannot read .qt5/qtbase/src/gui/qtgui-config.pri: No such file or
directory
Project ERROR: Could not find feature system-zlib.
Makefile:45: recipe for target 'sub-src-make_first' failed
make[1]: *** [sub-src-make_first] Error 3
make[1]: Leaving directory '../qt5/qtbase'
Makefile:78: recipe for target 'module-qtbase-make_first' failed
make: *** [module-qtbase-make_first] Error 2


is there a workaround for this?

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

[Development] [Interest] QtLocation Map bearing and tilt

[Vlad Stelmahovsky]

Hi

any plans to bring back bearing and tilt support for Map {} ?
May be with Qt3D2 ?

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