Re: [Development] Qt 5.9

2016-11-24 Thread Simon Everts
Op wo 23 nov. 2016 om 23:10 schreef Thiago Macieira <
thiago.macie...@intel.com>:

>
> I know the sample size here is horrible, but in your opinion what compiler
> should we keep offering a 32-bit binary build for?
>
> MSVC 2013
> MSVC 2015
> MinGW
>
>

Currently we're using Qt5.5 with MSVC2010 and Qt5.7 with MSVC 2013.
I have no problem updating the compiler when updating to a new minor Qt
release since we use windeployqt. If Qt is installed in the PATH, then I
would only update the compiler on a major Qt release or compile it using a
infix.
I'm not considering using MinGW professionally. We had issues with it in
the past and also use tools like Intel Parallel Studio and Resharper-c++
that integrate with MSVC.

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


Re: [Development] Qt 5.9

2016-11-23 Thread Simon Everts
Op wo 23 nov. 2016 om 11:45 schreef Helmut Mülner :

>
>
> That is not relevant here. I am using Windows 10 (64-bit) but I am still
> forced (because of 3rt-party-libraries) to develop 32-bit-Qt-applications.
> Even if the operating system is 64-bit there can be a lot of 32-bit
> application, e.g. VS 2013 and VS 2015 are still 32-bit applications.
>

+1

As a machine manufacturer we are still deploying 32bit windows systems
because of this reason. We'll be on 64bit windows soon, but need to support
the 32bit systems for at least 5 years. A lot of industrial computer
suppliers still install 32bit images on computers because there aren't any
64bit drivers available for the hardware.

We have no need to create 64bit apps, so its easier to just only create
32bit apps so it's compatible with all systems we need to maintain.

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


Re: [Development] What kind of airplane we want to build?

2016-01-21 Thread Simon Everts
2016-01-20 15:48 GMT+01:00 Ziller Eike :
>
> >  But Qt is available in D and Python, too, so ...
> > why do they use C++ if they so hate it?
>
> Maybe they don’t hate it, but still wished it had a less verbose API if you 
> don’t need the verbosity.

Understanding why people choose c++ and Qt is important when you want
to look at the broader picture.

I work in Industrial Automation business and program mainly in c++/Qt,
c#/.NET/WPF and Js/HTML5/Polymer, targeting windows (WES) as that
seems to be the standard in the PLC / Automation industry. At least on
our branch...
I split them in language / framework / user-interface. As that's is
how I would compare them and choose the stack that's best for the job
that needs to be done.

If I would need to choose 1 stack to do it all it would be Qt, but
that's my personal opinion. For our business C#/.NET is the standard
go-to language on our department for desktop applications, simply
because all our programmers know it (easy to learn?)  and it's easy to
hire programmers to jump-in if required. The same goes for Js/HTML5,
but we use that more for the mobile / crossplatform apps.

C++/Qt is used in our vision software doing image processing. We'd
like to have more control over the compiler / optimizations, no
garbage collector and no marshalling etc.

When I try to use Qt for other apps I'm not making friends with our
other programmers, but I actually find it easier to create small
applications with Qt because of the simple to use and consistant API.
I also find it harder to do things wrong as opposed to .NET. Also in
QtCreator it's very easy and fast to call up the API reference for
classes. With VisualStudio i always have to search, but maybe i'm
doing something wrong here. The point is that in .NET is always need
to look things up. In Qt the API more intuitive. It's important that
I'm comparing Qt and .NET/WPF here, not c++ and c#.

When comparing c++ and c# then I feel there is a large difference in
productivity. When I've done work in C# using VisualStudio with
Resharper or in Javascript/NodeJS, and then go back to c++ in
QtCreater I feel not very productive. Refactoring plays a role here,
but also language features. Downside of using VisualStudio with c++ is
the lack of intellisense for QML (I do love the progress done in
QtCreator though :) )

In C# it can be very productive to use lambda delegates as signal handlers.
Or in NodeJS a lambda as a callback: const client = net.connect({port:
8124}, () => { //'connect' listener }
Yesterday I tried to do something like this in a quick way for a
unit-test with with the connected event of the QWebSocket, Tried
connecting the signal to a lambda expression and it worked, but I
wonder if it saved me time making it :)
The point here is that if the API supports using those new language
features, than that already could make the language feel a lot more
productive.
Another example would be the chaining of promises in javascript (with
.then and.catch, is that possible with QFuture?) and or the
async/awaitable functions in c#.

When writing the user interface I definitely would prefer QML above
fighting browsers with HTML/CSS or chewing XML with XAML. Although I
sometimes would wish to have an easy way of styling standard
components like in CSS using classes and mixins.

Using qmake for small projects is also ok, it's easier to handle than
a visual studio project for version control. But if the project is
larger and needs to use subdirs, than i would have a hard time
explaining it to other programmers. But showing them a CMakeLists.txt
would scare them away i think ;)

These are just some observations from my point of view, maybe some
points are obvious, but I hope it can contribute to this discussion :)

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