Re: [Development] The sorry state of the Qt6 cross compile experience
No, you‘re not. But I already gave up seeing the absolute mess TQC has done with Qt6. Beste Grüße / Best regards, Alexander Nassian > Am 24.02.2021 um 12:59 schrieb Bogdan Vatra via Development > : > > Anyway, it seems I'm the only one who's bothered by this issues, so, I'll > stop > complaining. > > Yours, > BogDan. > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger https://bitshift-dynamics.com <https://bitshift-dynamics.com> Phone: +49 762158673 - 0 General support: i...@bitshift-dynamics.com <mailto:i...@bitshift-dynamics.com> Technical support: supp...@bitshift-dynamics.com <mailto:supp...@bitshift-dynamics.com> Accounting: invo...@bitshift-dynamics.com <mailto:invo...@bitshift-dynamics.com> ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Making Binary Incompatible Changes after Qt 6.0
4) Don‘t release a major version that lacks half of the modules of the prev version in a hurry for no reason. > Am 09.12.2020 um 09:15 schrieb Allan Sandfeld Jensen : > > So, we can: > > 1. Live with it or find a work around > 2. Break BC after 6.0.0 (we have don that before, though only when accidently > breaking BC in a point release) > 3. Break BC again "soonish", like after 6.2 or 6.5 > > Any other options? > > Best regards > 'Allan > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger https://bitshift-dynamics.com <https://bitshift-dynamics.com> Phone: +49 762158673 - 0 General support: i...@bitshift-dynamics.com <mailto:i...@bitshift-dynamics.com> Technical support: supp...@bitshift-dynamics.com <mailto:supp...@bitshift-dynamics.com> Accounting: invo...@bitshift-dynamics.com <mailto:invo...@bitshift-dynamics.com> ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Wither QString?
C++ hasn‘t even proper Unicode handling integrated. std::string is a mess in my
opinion.
Beste Grüße / Best regards,
Alexander Nassian
> Am 18.10.2019 um 02:30 schrieb Henry Skoglund :
>
> Hi, while writing lots of QString string fiddling code (keyboard macro
> utility) I feel something tugging at my sleeve:
> the upcoming C++20, looking at std::format(), it seems really handy, e.g.:
>
> std::string s = std::format("String '{}' has {} characters\n", string,
> string.length());
>
> // for a German flavor you can use arg #
> std::string s = std::format("{1} Zeichen lang ist die Zeichenkette '{0}'\n",
> string, string.length());
>
> // lots of formatting options with a ':' inside the curlies
> std::string s = std::format("{0:b} {0:d} {0:x}", 42); // s == "101010 42 2a"
>
> Using QString::arg() works fine but it's getting harder to ignore all the new
> C++ stuff and C++20 looks to be one of the bigger additions to the language
> since C++11.
>
> Perhaps the time has come to think about a retirement plan for QString?
>
> Rgrds Henry
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
--
—
bitshift dynamics GmbH
Neudorfer Str. 1, 79541 Lörrach
Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747
Geschäftsführer: Alexander Nassian, Markus Pfaffinger
http://www.bitshift-dynamics.de <http://www.bitshift-dynamics.de/>
Zentrale: +49 762158673 - 0
Fax: +49 7621 58673 - 90
Allgemeine Anfragen:
i...@bitshift-dynamics.com <mailto:i...@bitshift-dynamics.com>
Technischer
Support: supp...@bitshift-dynamics.com
<mailto:supp...@bitshift-dynamics.com>
Buchhaltung:
invo...@bitshift-dynamics.com <mailto:invo...@bitshift-dynamics.com>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] The age-old T* foo vs. T *foo
The * or & or && always have an impact on the actual type the variable has. So my logical implication would be that *, &, && has to be placed there: QObject* x and not QObject *x. Beste Grüße / Best regards, Alexander Nassian > Am 17.10.2019 um 20:06 schrieb Ville Voutilainen > : > > Since we are about to do a major version upgrade, should be stop being > a special snowflake in the C++ world and start attaching pointer-stars > and reference-ampersands to the type instead of to the variable? > > As a quick example of how our current style is just odd, consider > > for (auto & : oink) > > Sure, that's in accordance with our style. It looks very out of place when > coming back to our code after adventures in other code. Quick reading > of it tends to suggest that it's a by-value thing since quick eyes see > auto without any decorations. > > I don't expect the transition, should we agree to have it, to be easy > for people accustomed to the Qt style. I also don't have any sort of numbers > about whether our style is used elsewhere. In contrast, people with lots > of exposure to non-Qt style tend to have to fight ours, it just doesn't come > naturally. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de <http://www.bitshift-dynamics.de/> Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com <mailto:i...@bitshift-dynamics.com> Technischer Support: supp...@bitshift-dynamics.com <mailto:supp...@bitshift-dynamics.com> Buchhaltung: invo...@bitshift-dynamics.com <mailto:invo...@bitshift-dynamics.com> ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Static Package
There are many ways that are much better and do not have the problems static linking involves. Beste Grüße / Best regards, Alexander Nassian > Am 15.04.2019 um 01:47 schrieb Carlos Enrique Pérez Sánchez > : > > What do people think about providing official static packages? > > The reason is that the distribution of an application is much easier in a > single executable. For that reasons I've made many static qt builds and it's > always a lot of work to make it running. > I have success in building qt statically for console and widgets > applications, but I have not success on building Qt Quick Controls 2 > applications statically, mainly on Windows, because the graphics effects are > off, no shadows, no layer, no elevation, etc. > > There internet is full of people trying to build Qt statically, because Qt > Docs lacks information about building static packages and there are not > examples of commands to pass to configure. People even migrated to other > frameworks because they like static applications, and in Qt doing that is > always a pain. > > There is a Jira suggestion: > https://bugreports.qt.io/browse/QTBUG-72810 > > Please give an upvote there it if you agree. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de <http://www.bitshift-dynamics.de/> Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com <mailto:i...@bitshift-dynamics.com> Technischer Support: supp...@bitshift-dynamics.com <mailto:supp...@bitshift-dynamics.com> Buchhaltung: invo...@bitshift-dynamics.com <mailto:invo...@bitshift-dynamics.com> ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Does iMX6 support EGL on X11 feature?
> Am 23.03.2019 um 08:57 schrieb Denis Shienkov : > > > Otherwise you could just wrap Qwt in a QQuickPaintedItem to integrate that > > single QWidget component in the otherwise QtQuick UI > > QQuickPaintedItem use QPainter, so, the performance will be as with usual > QWidget. Yes, for that widget, but the rest would be offloaded. > > > Did you have a look on QChart.js? > > It is embedded device, there are no any HTML, JS and other stuff. QChart.js is the QtQuick port of Chart.js > > > > сб, 23 мар. 2019 г. в 00:03, Alexander Nassian > : >> Did you have a look on QChart.js? >> Otherwise you could just wrap Qwt in a QQuickPaintedItem to integrate that >> single QWidget component in the otherwise QtQuick UI. >> >> Beste Grüße / Best regards, >> Alexander Nassian >> >>> Am 22.03.2019 um 20:02 schrieb Denis Shienkov : >>> >>> Hi, >>> >>> Yes, but Qt Quick has not any good plotting library (as my app draw >>> "real-time" curves). QtCharts in not an option. :) >>> >>> I thought that maybe I could use the OpenGL widget in QtWidgets app to >>> render a curves there (e.g. with Qwt). But in this case I need in the >>> working OpenGL on X11 (which is not exists). >>> >>> >>> 22.03.2019 21:29, Alexander Nassian пишет: >>>> Then you should go with EGL and QtQuick if you want to utilize the GPU. >>>> X11 is mostly a horrible idea on embedded systems (and in general too if >>>> you would ask me). Widgets are drawn by the CPU as far as I know. >>>> >>>> Beste Grüße / Best regards, >>>> Alexander Nassian >> >> >> — >> >> bitshift dynamics GmbH >> Neudorfer Str. 1, 79541 Lörrach >> Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 >> Geschäftsführer: Alexander Nassian, Markus Pfaffinger >> >> http://www.bitshift-dynamics.de >> >> Zentrale: +49 762158673 - 0 >> Fax: +49 7621 58673 - 90 >> >> Allgemeine Anfragen: i...@bitshift-dynamics.com >> Technischer Support: supp...@bitshift-dynamics.com >> Buchhaltung: invo...@bitshift-dynamics.com -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de <http://www.bitshift-dynamics.de/> Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com <mailto:i...@bitshift-dynamics.com> Technischer Support: supp...@bitshift-dynamics.com <mailto:supp...@bitshift-dynamics.com> Buchhaltung: invo...@bitshift-dynamics.com <mailto:invo...@bitshift-dynamics.com> ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Does iMX6 support EGL on X11 feature?
Did you have a look on QChart.js? Otherwise you could just wrap Qwt in a QQuickPaintedItem to integrate that single QWidget component in the otherwise QtQuick UI. Beste Grüße / Best regards, Alexander Nassian > Am 22.03.2019 um 20:02 schrieb Denis Shienkov : > > Hi, > > Yes, but Qt Quick has not any good plotting library (as my app draw > "real-time" curves). QtCharts in not an option. :) > > I thought that maybe I could use the OpenGL widget in QtWidgets app to render > a curves there (e.g. with Qwt). But in this case I need in the working OpenGL > on X11 (which is not exists). > > > 22.03.2019 21:29, Alexander Nassian пишет: >> Then you should go with EGL and QtQuick if you want to utilize the GPU. X11 >> is mostly a horrible idea on embedded systems (and in general too if you >> would ask me). Widgets are drawn by the CPU as far as I know. >> >> Beste Grüße / Best regards, >> Alexander Nassian -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de <http://www.bitshift-dynamics.de/> Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com <mailto:i...@bitshift-dynamics.com> Technischer Support: supp...@bitshift-dynamics.com <mailto:supp...@bitshift-dynamics.com> Buchhaltung: invo...@bitshift-dynamics.com <mailto:invo...@bitshift-dynamics.com> ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Does iMX6 support EGL on X11 feature?
Then you should go with EGL and QtQuick if you want to utilize the GPU. X11 is
mostly a horrible idea on embedded systems (and in general too if you would ask
me). Widgets are drawn by the CPU as far as I know.
Beste Grüße / Best regards,
Alexander Nassian
> Am 22.03.2019 um 17:06 schrieb Denis Shienkov :
>
> Hi all,
>
> I'm trying to build a Yocto image, but the config tests fails on 'executing
> config test egl-x11' test with:
>
> > In file included from main.cpp:7:0:
> > main.cpp: In function 'int main(int, char**)':
> > main.cpp:15:20: error: cannot convert 'EGLNativeDisplayType {aka
> > wl_display*}' to 'Display* {aka _XDisplay*}' in initialization
> > Display *dpy = EGL_DEFAULT_DISPLAY;
> > ^
> > In file included from
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:38:0,
> > from
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/egl.h:39,
> > from main.cpp:7:
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglvivante.h:111:16:
> > note: class type 'wl_display' is incomplete
> > typedef struct wl_display * EGLNativeDisplayType;
> > ^~
> > main.cpp:16:50: error: cannot convert 'Display* {aka _XDisplay*}' to
> > 'EGLNativeDisplayType {aka wl_display*}' in initialization
> > EGLNativeDisplayType egldpy = XOpenDisplay("");
> > ^
> > In file included from main.cpp:9:0:
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/X11/Xlib.h:255:8:
> > note: class type 'Display {aka _XDisplay}' is incomplete
> > struct _XDisplay; /* Forward declare before use for C++ */
> > ^
> > main.cpp:17:11: error: cannot convert 'EGLNativeDisplayType {aka
> > wl_display*}' to 'Display* {aka _XDisplay*}' in assignment
> > dpy = egldpy;
> >^~
> > In file included from
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:38:0,
> > from
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/egl.h:39,
> > from main.cpp:7:
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglvivante.h:111:16:
> > note: class type 'wl_display' is incomplete
> > typedef struct wl_display * EGLNativeDisplayType;
> > ^~
> > main.cpp:18:42: error: invalid conversion from 'Window {aka long unsigned
> > int}' to 'EGLNativeWindowType {aka wl_egl_window*}' [-fpermissive]
> > EGLNativeWindowType w = XCreateWindow(dpy, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > 0, 0);
> >
> > ~^~
> > main.cpp:19:26: error: invalid conversion from 'EGLNativeWindowType {aka
> > wl_egl_window*}' to 'Window {aka long unsigned int}' [-fpermissive]
> > XDestroyWindow(dpy, w);
> > ^
> > In file included from main.cpp:9:0:
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/X11/Xlib.h:2243:12:
> > note: initializing argument 2 of 'int XDestroyWindow(Display*, Window)'
> > extern int XDestroyWindow(
> > ^~
> > Makefile:174: recipe for target 'main.o' failed
> > make: *** [main.o] Error 1
> test config.qtbase_gui.tests.egl-x11 FAILED
>
> so, my quiestion is: Is it possible to use an OpenGL on X11 with XCB backend?
> I need to accelerate the QWidgets application in some way... :(
>
> DR,
> Denis
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
--
Re: [Development] Enum classes in signals?
That’s why it is always good practice to only use FQTN in public headers anyway
;)
Beste Grüße / Best regards,
Alexander Nassian
> Am 06.02.2019 um 05:41 schrieb Giuseppe D'Angelo via Development
> :
>
> Il 05/02/19 18:16, Dmitriy Purgin ha scritto:
>> I couldn't figure out the exact combination but as far as I remember, if you
>> have namespaced code, you have to always fully qualify the enum class
>> parameters in signals and slots.
>
> This is actually also the case for enums and enum classes. For instance,
> consider
>
> class A : public QObject {
> Q_OBJECT
> public:
> enum class E { E1, E2, E3 };
> signals:
> void mySignal(E);
> };
>
> class B : public QObject {
> Q_OBJECT
> public slots:
> void mySlot(A::E);
> };
>
> This code compiles just fine, but you will NOT be able to connect mySignal1
> to mySlot using SIGNAL/SLOT.
>
> Doing it like this
>
> connect(a, SIGNAL(mySignal(E)), b, SLOT(mySlot(A::E)));
>
> won't work because the argument lists don't match (this connect version
> compares the parameter lists _as strings_, and obviously "E" is different
> from "A::E").
>
>
> Connecting it like this
>
> connect(a, SIGNAL(mySignal(A::E)), b, SLOT(mySlot(A::E)));
>
> will not find mySignal in A, because the lookup will search for a function
> with that signature _spelled exactly that way in the source code_. Such a
> function is not there; the source code spells "E" as parameter type, not
> "A::E".
>
> The solution hence is to declare the signal with an A::E parameter.
>
> My 2 c,
> --
> 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
--
—
bitshift dynamics GmbH
Neudorfer Str. 1, 79541 Lörrach
Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747
Geschäftsführer: Alexander Nassian, Markus Pfaffinger
http://www.bitshift-dynamics.de <http://www.bitshift-dynamics.de/>
Zentrale: +49 762158673 - 0
Fax: +49 7621 58673 - 90
Allgemeine Anfragen:
i...@bitshift-dynamics.com <mailto:i...@bitshift-dynamics.com>
Technischer
Support: supp...@bitshift-dynamics.com
<mailto:supp...@bitshift-dynamics.com>
Buchhaltung:
invo...@bitshift-dynamics.com <mailto:invo...@bitshift-dynamics.com>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Enum classes in signals?
Is it really deprecated? Didn’t find any notice and wonder how it could get deprecated as the f-ptr syntax is not functionally equivalent to the macro syntax. Beste Grüße / Best regards, Alexander Nassian > Am 05.02.2019 um 17:43 schrieb Jason H : > > While I prefer enum classes myself, I just had to connect to a signal with > one in it. This was unfortunate as I was attempting to use the old connection > syntax SIGNAL()/SLOT() macros. I was not aware that the old syntax were being > deprecated? What is the policy on this? > > Should signals not use enum classes? > Should Qt not use enum classes? > Should Qt support old connection syntax? Where/when? > Should all new connections be in the modern syntax? > > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de <http://www.bitshift-dynamics.de/> Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com <mailto:i...@bitshift-dynamics.com> Technischer Support: supp...@bitshift-dynamics.com <mailto:supp...@bitshift-dynamics.com> Buchhaltung: invo...@bitshift-dynamics.com <mailto:invo...@bitshift-dynamics.com> ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
Arrogant mails like this from you are the reason why CoD are popping even up. Talking about the right of „playing with the grown ups“ but writing so much BS that would already violate the proposed CoD. > Am 24.10.2018 um 17:42 schrieb Aleix Pol : > > On Wed, Oct 24, 2018 at 5:10 PM Jason H wrote: >> >> I am whole-heartedly against a Code of Conduct. While well-intentioned, >> anyone following the shit-show that is the Linux kernel code of conduct >> fiasco, I also think would be against the code of conduct as well. >> >> Immediately after imposing the Code of Conduct, past tweets by contributors >> and the accusations started flying and it devolved from there. In addition >> to several authorities on Open Source weighed in that yes, contributors can >> revoke the copyright of their prior contributions, which was threatened by >> those accused. Which would leave any software in a lurch. Now, it looks like >> those contributors might go to BSD... >> >> Having been interested in software from a very young age, and later >> specifically Open Source, one thing that appealed to me was that it was a >> meritocracy. The best code survives, your code contributions are limited >> only by your code being the best. Now we're saying it's not just your code, >> but also your behavior. We had an ideal, we had THE ideal - a place where >> only our ideas mattered. A place where nothing else mattered - not your >> gentatilia, your sexual identity, not your partner preference, not your >> political party - none of it. It was purely about lines of code. It was >> elegant and beautiful, and brutally simple. And now the social justice >> warriors are contaminating that perfection with code+conduct. So it goes >> from "this is the best code that could be written" to "this is the best code >> that could be written from an individual whose political ideals match our >> own". >> >> If we adopt this, does that mean there is a [git commit hook| gerrit >> review] installed that evaluates the contributor's social media to find >> controversial posts? >> If we adopt this, how do we assure we don't wind up in a Sarah Jeong >> situation (She's racist against white people, but the New York Times says >> that's "ok")? >> - How do assure that white people are adequately protected against reverse >> racism? >> -- Do we even agree that reverse racism [is possible to] exist(s) >> If we adopt this, what exactly are the political ideas a Qt contributor must >> espouse? >> - Are stances against illegal immigration "racist"? >> - Is "Sceintific racism" actual racism or just statistics? >> -- In a matter closer to home, where are we on James Damore situation? Would >> he be banned from this community? >> >> NONE of those questions should need to be contemplated by an Open Source >> software project. Open Source is about the Source. Not the source of the >> Source. >> >> In case it needs to be said- >> I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. >> But I am also against people judging other people's code for factors that >> have nothing to do with the code itself. I find that adding a value >> judgement of conduct to code to be intolerant. We had the ideal. >> I am FOR inclusion. I want everyone to feel welcome here. Everyone. >> >> We might identify as a "community" as we are people, but really we're an >> open source project, and at the end of the day what matters the most is what >> is in git. >> >> I oppose any Code of Conduct. And demand the answers be provided to the >> above questions PRIOR to passage (if it happens). >> >> I really want to know where we are with James Damore because I thought his >> paper was well-researched with a scientific basis? >> >> >> >>> Sent: Wednesday, October 24, 2018 at 3:17 AM >>> From: "Ulf Hermann" >>> To: "development@qt-project.org" >>> Subject: [Development] QUIP 12: Code of Conduct >>> >>> Hi, >>> >>> regarding our earlier discussions on a possible Code of Conduct, here as >>> well as at the Contributors' Summit 2017, I've pushed a QUIP with the >>> necessary rules and definitions: >>> >>> https://codereview.qt-project.org/243623 >>> >>> Please review it. >>> >>> regards, >>> Ulf > > Dear Jason, > I fail to see how you can feel entitled to give your opinion when > you've done no
Re: [Development] Fornux C++ Superset
OMFG, besides that these are not the most difficult problems in programming, ... that computer voice that just reads what the presentation says. Youtube Videos are not the messias, if it’s just a written down text, publish it as text. Why a voice that reads 1:1 what is visible on the screen? If you would‘ve slow it down you would at least get money from ads :D > Am 13.05.2018 um 23:26 schrieb Phil Bouchard <philipp...@gmail.com>: > >> On 04/26/2018 12:35 AM, Phil Bouchard wrote: >> On 04/25/2018 12:36 PM, Edward Welbourne wrote: >>>> memory leaks are the most difficult problems to solve. >>> >>> Well, no, they're not. >>> I've fixed *lots and lots* of memory leaks. >>> Some of them were a little tricky: most were trivial. >>> I can *see* memory leaks just by reading code. >>> It's one of the reasons code review makes memory leaks rare. >>> That and nice sensible disciplines like RAII. >>> >>> Use-after-free is usually harder to solve than a leak. >>> Deadlocks are almost always harder to solve. >> You're right: >> 1) Deadlocks are much more difficult to find >> 2) Then comes the use-after-free but they can be easily detected by throwing >> an exception with root_ptr >> 3) Then we have the memory leaks... > > I made a mistake here: use-after-free problems are actually easily solved by > FCXXSS because it discards all explicit calls to "delete" and implicitly use > them where they belong. So it's impossible to face that problem. > > In fact I have prepared a summary of our discussion and you can see the > execution of my previous example in real-time here: > https://youtu.be/vZL5X2FlZKU > > > Regards, > -Phil > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de <http://www.bitshift-dynamics.de/> Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com <mailto:i...@bitshift-dynamics.com> Technischer Support: supp...@bitshift-dynamics.com <mailto:supp...@bitshift-dynamics.com> Buchhaltung: invo...@bitshift-dynamics.com <mailto:invo...@bitshift-dynamics.com> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] #pragma once
Besides its possible flaws, it‘s simply nothing that the C++ standard defines. I also want to use some glibc features that maybe also commonly available but it is still not standard, even worse, the implementation is completely userdefined. That same discussion raises up once a year about STL containers and others and then some compiler proves that Qt‘s way is the better by introducing some kind of bug or binary incompatibility. Beste Grüße / Best regards, Alexander Nassian > Am 24.01.2018 um 12:32 schrieb Jean-Michaël Celerier > <jeanmichael.celer...@gmail.com>: > > I certainly have been bitten much more times by include guards that were the > same in different files (especially in old libraries where guards look like > #ifdef QUEUE_H because of course there is a single queue.h file in the whole > world, or because someone just copy-pasted the content of a file to another > and forgot changing include guards -- I plead guilty!) than whatever > hypothetic bug in pragma once GCC's implementation may have. > > Are there people here who had, just once, a bug due to #pragma once ? I never > met any. Across network drives, with precompiled headers, unity builds, with > MSVC, Clang, GCC, ccache, distcc and Icecream... > > > > --- > Jean-Michaël Celerier > http://www.jcelerier.name > >> On Wed, Jan 24, 2018 at 11:34 AM, Mitch Curtis <mitch.cur...@qt.io> wrote: >> >> >> > -Original Message- >> > From: Ville Voutilainen [mailto:ville.voutilai...@gmail.com] >> > Sent: Wednesday, 24 January 2018 11:25 AM >> > To: Alexander Nassian <nass...@bitshift-dynamics.com> >> > Cc: Mitch Curtis <mitch.cur...@qt.io>; development@qt-project.org >> > Subject: Re: [Development] #pragma once >> > >> > On 24 January 2018 at 12:22, Alexander Nassian <nassian@bitshift- >> > dynamics.com> wrote: >> > > Maybe because it’s not part of the C++ standard? >> > >> > #pragma once is not a replacement for include guards. >> >> Why not? >> >> > It's not part of the C++ standard because it doesn't always work >> >> In which ways? My quick search gave me these: >> >> https://stackoverflow.com/a/1946730/904422 >> https://en.wikipedia.org/wiki/Pragma_once#Caveats >> >> There's also this answer that highly recommends against it, but seems quite >> contended in the comments: >> >> https://stackoverflow.com/a/34884735/904422 >> >> > and modules are a superior solution anyway. >> >> How so? >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com Technischer Support: supp...@bitshift-dynamics.com Buchhaltung: invo...@bitshift-dynamics.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] #pragma once
Maybe because it’s not part of the C++ standard? Beste Grüße / Best regards, Alexander Nassian > Am 24.01.2018 um 11:13 schrieb Mitch Curtis <mitch.cur...@qt.io>: > > Why don't we use #pragma once in Qt like Qt Creator does? If it's due to old > compilers that we have to support, which ones are the problem? > > - Someone who just spent too much time looking at a confusing compiler error > caused by duplicated include guards. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com Technischer Support: supp...@bitshift-dynamics.com Buchhaltung: invo...@bitshift-dynamics.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Undeprecating QString::null
No it isn‘t about you. But your message suggested you blame it on Qt project ;) Anyway, default values are not part of a functions signature and don’t break binary compatibility. Beste Grüße / Best regards, Alexander Nassian > Am 16.01.2018 um 17:46 schrieb Uwe Rathmann <uwe.rathm...@tigertal.de>: > >> On Tue, 16 Jan 2018 17:26:51 +0100, Alexander Nassian wrote: >> >> Deprecated since Qt4 ... > > According to qstring.h: > > #if QT_DEPRECATED_SINCE(5, 9) > ... > #endif > > But come this is not about me and if I missed, that an API has been > declared as deprecated. It is about what to best in the current situation. > > Uwe > > > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com Technischer Support: supp...@bitshift-dynamics.com Buchhaltung: invo...@bitshift-dynamics.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Undeprecating QString::null
Deprecated since Qt4 (so it survived already two versions that were allowed to break binary compatibility) means that you had 12 (twelve) years to do the migration. How long should it be maintained? And again, it also could have been removed in Qt4 or 5. > Am 16.01.2018 um 17:16 schrieb Uwe Rathmann <uwe.rathm...@tigertal.de>: > > On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote: > >> Just change your code to use "= QString()", no #ifdef necessary. > > The "just change" introduces a binary incompatibility - right ? > > Please be aware, that Qwt is part of almost any Linux distro - according > to sourceforge it has more than 1000 additional downloads every week > since many years. > > All distro maintainers would not only have to upgrade the Qwt packages, > but also all packages depending on it - users would have to rebuild. > > Considering the strict compatibility rules you have for Qt you will > understand, that this is nothing I would like to do easily. > > But could you please comment on why this change is an improvement - > beyond getting rid of 3-4 lines in qstring.h ? > > Thanks, > Uwe > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- -- bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com Technischer Support: supp...@bitshift-dynamics.com Buchhaltung: invo...@bitshift-dynamics.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)
I agree with all of your points except the one where you reject the fear model. Just a single very simple example: Try to download Qt. You can buy the commercial license right from the home page, but in order to get the OSS version you have to click through numerous pages and have to search for the right links. When you managed to get right before the download the user is confronted with numerous arguments against the OSS version of them some are very vague if not to say false. Other example: I had a talk with several representatives who for example told me that „it‘s impossible to use Qt OSS in medical or automotive scenarios and I *have to* buy a license“. That‘s simply not true and shocked me even more. I could also bring two examples from my personal contact to TQC but I don‘t think thats a thing for a public mailing list. If you are interested, we could talk about this in a private conversation. These are just two examples from the last 1-2 years and there is always something new that encurages my view on the situation and it feels more and more like the OSS version is just a tumor on the feet of TQC. My wishes would be that TQC makes either a clear statement that OSS is an equal option (and treat it like this), or be so honest and drop it. But this situation feels very embarassing to me. And please don‘t get me wrong. I do respect your work at TQC, I do respect hat for you there must be a source of income, but there is are ways to achieve this without that bad habits that established the last 1-2 years. Beste Grüße / Best regards, Alexander Nassian > Am 13.10.2017 um 15:15 schrieb Jake Petroules <jake.petrou...@qt.io>: > > Thank you for addressing this point, Andy. > > I also want to respond to Alex's other comment, "Let the community do the > work and squeeze all customers and force them to use commercial licensing by > using fear..." > > First of all, look at the project statistics. The Qt Company is BY FAR the > largest contributor to the Qt Project. > > Secondly, we don't use "fear" to "force" customers to use commercial > licensing. Each license grants a specific set of rights and privileges. If > you're not willing or unable to abide by the terms of the Open Source > licenses under which Qt is available, then you need to consider an > alternative which provides a different set of rights and privileges that may > be better suited for your use case, one of which is commercial licensing. > > Also, please explain how The Qt Company will pay its expenses and its > employees, who in turn need to pay their rent and other bills, etc., without > a source of income. We're always looking for new ideas to expand our business > model, so if we could get free money out of thin air, that would be quite > excellent and we'd love for you to tell us how. > >> On Oct 13, 2017, at 3:00 PM, Andy Shaw <andy.s...@qt.io> wrote: >> >> To make it clear, it is Viktor’s opinion here and he can state it but it >> does not mean that it is the representation of all of The Qt Company here. >> It was one point of a larger mail which he took the time to write because he >> wants to open a discussion about how we can improve the review process as a >> community. Ideas are naturally welcome and not all of them are going to be >> agreeable to everyone, and not all of them are going to be accepted moving >> forward either. >> >> I personally don’t agree with the specific point made regarding where the >> contribution has come from as I believe that everyone should be treated >> equally when it comes to reviewing, just because you are or have been an >> employee of The Qt Company should not grant you any extra lenience when it >> comes to reviewing. As Eddie has already mentioned for his own sake, I also >> appreciate the feedback and the fact that someone is critically looking at >> my change. I may have been working with Qt for 17 years, but I still learn >> and I still make mistakes, my changes should be reviewed in exactly the same >> manner as anyone elses should be. I expect that and prefer it too. >> >> Andy >> >> Fra: Development <development-bounces+andy.shaw=qt...@qt-project.org> på >> vegne av Alexander Nassian <nass...@bitshift-dynamics.com> >> Dato: fredag 13. oktober 2017 14.51 >> Til: Somers Andre <an...@familiesomers.nl> >> Kopi: "development@qt-project.org" <development@qt-project.org> >> Emne: Re: [Development] Speeding up the review process (was: PostgreSQL >> cross compile for Pi) >> >> That shows exactly the mindset of the TQC administration. Let the community >> do the work and squeeze all customers and force the
Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)
Sorry if I insulted somebody, that was not my intend. But the proposal alone fits too well into numerous things that happened the last months to the public presentation of Qt and TQC. Starting with the simple task of trying to download the OSS version of Qt which is the most complicated possible way currently and even if you managed to come to the right page, you get scared by all the bad things TQC writes would happen if someone uses the L-GPL version. Best regards, Alexander Nassian > Am 13.10.2017 um 15:05 schrieb Jedrzej Nowacki <jedrzej.nowa...@qt.io>: > > Please, do not jump immediately to a conclusion. It was Viktor's proposal > which does not represent "TQC administration" whatever it is. Qt-project has > own rules and it is self-governmented. Just to be fair, you could also notice > my answer to the proposal: >> I do not agree. An employer name does not matter. > and I do work for The Qt Company. > > Cheers, > Jędrek > > On piątek, 13 października 2017 14:51:13 CEST Alexander Nassian wrote: >> That shows exactly the mindset of the TQC administration. Let the community >> do the work and squeeze all customers and force them to use commercial >> licensing by using fear... >> >> >> Beste Grüße / Best regards, >> Alexander Nassian >> >>> Am 13.10.2017 um 14:46 schrieb André Somers <an...@familiesomers.nl>: >>> >>> Op 13/10/2017 om 13:04 schreef Viktor Engelmann: >>>> 4. I don't think we need to be as paranoid towards contributions from our >>>> own employees as we need to be towards external contributions.> >>> So much for open government... >>> >>> André >>> >>> ___ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development > > -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com Technischer Support: supp...@bitshift-dynamics.com Buchhaltung: invo...@bitshift-dynamics.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)
That shows exactly the mindset of the TQC administration. Let the community do the work and squeeze all customers and force them to use commercial licensing by using fear... Beste Grüße / Best regards, Alexander Nassian > Am 13.10.2017 um 14:46 schrieb André Somers <an...@familiesomers.nl>: > > > > Op 13/10/2017 om 13:04 schreef Viktor Engelmann: >> 4. I don't think we need to be as paranoid towards contributions from our >> own employees as we need to be towards external contributions. >> > So much for open government... > > André > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com Technischer Support: supp...@bitshift-dynamics.com Buchhaltung: invo...@bitshift-dynamics.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt and IoT infographic
Maybe they count "platforms" not as OSs but as platform plugins in Qt xD Beste Grüße / Best regards, Alexander Nassian > Am 24.08.2017 um 23:05 schrieb Thiago Macieira <thiago.macie...@intel.com>: > >> On Thursday, 24 August 2017 14:00:01 PDT Thiago Macieira wrote: >> PS: it also says "Artificial Intelligence" in "The Backbone" part. How is >> that relevant to Qt or where is it exposed in Qt? > > It also says "12+ supported platforms". Where does that number come from? I > can count 7: > > - Linux > - Windows > - macOS > - Android > - iOS / tvOS / watchOS > - QNX > - INTEGRITY > > Even if you split the Apple embedded platforms, that's still 9. WinRT > shouldn't be split from Windows, since it's still Windows; Embedded Linux is > still Linux and so are all the different Linux distributions. > > Don't add FreeBSD there just because I like developing with it more than on > macOS. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Passing QSize, QPoint, QTime and other small structs by value
I don't care, I always pass const-ref ;) Beste Grüße / Best regards, Alexander Nassian > Am 07.04.2017 um 13:30 schrieb Konstantin Tokarev <annu...@yandex.ru>: > > > > 07.04.2017, 13:41, "Sergio Martins" <sergio.mart...@kdab.com>: >> Hi, >> >> Some time ago I documented the guidelines on passing by value vs >> const-ref: >> https://wiki.qt.io/API_Design_Principles#Passing_by_const-ref_vs._Passing_by_value >> This was discussed in #qt-labs at the time and informally +2'd there. >> >> But the reality is that passing small structs by value is not very >> popular and Qt's API mostly passes them by const-ref. >> >> I think this is a good time to have a more formal conversation, >> bikeshed+popcorn, then write a QUIP and hopefully change the API for Qt >> 6. >> >> The guideline is very simple: >> - If your type has a non-trivial copy-CTOR or non-trivial DTOR then pass >> by const-ref, no matter how small it is, to avoid calling those methods. >> *[1] >> - If your type has trivial CTOR and trivial DTOR, pass by value if it's >> small, otherwise const-ref. Small meaning <= 16 bytes. > > I think such rule should be enforced by tooling, e.g. something like clazy. > > Btw, do you consider case when properties of type in question are changed > in future Qt version, e.g. new fields or ctors are added (in case of > non-public > class/struct)? > >> >> The idea is that by value allows the struct's members to be passed in >> CPU registers, see [2] for extensive research. >> >> The good news is, even if you don't care about raw performance, passing >> by value is more convenient, as you type less code, so IMO, more fun to >> use. >> >> [1] - Shared pointers should go by value though, I'll try to prove it in >> the QUIP. >> [2] - >> http://www.macieira.org/blog/2012/02/the-value-of-passing-by-value/ >> >> Cheers, >> -- >> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer >> Klarälvdalens Datakonsult AB, a KDAB Group company >> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >> KDAB - The Qt, C++ and OpenGL Experts >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com Technischer Support: supp...@bitshift-dynamics.com Buchhaltung: invo...@bitshift-dynamics.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal for "container-oriented deterministic memory manager"
If Qt Quick Compiler doesn't sell anything, why is it then only GPL and commercial? It is obvious that it is just for pushing people to the commercial model. Thiago Macieira <thiago.macie...@intel.com> schrieb am Mi. 28. Dez. 2016 um 01:50: Em terça-feira, 27 de dezembro de 2016, às 19:22:27 BRST, Phil Bouchard escreveu: > On 12/27/2016 04:36 AM, Phil Bouchard wrote: > > On 12/27/2016 02:04 AM, Konstantin Tokarev wrote: > >> IMO obvious option is to postpone GC while animation is running. > >> I would consider such behavior a bug. > > > > That could work for most apps and certainly mine but some Javascript > > webpages / QML games have continuous animations. > > Qt developed a QtQuickCompiler which is great but the end result is > still not a 100% perfect and software engineering needs to be nothing > less than that otherwise you won't sell anything. Considering it has sold something, your assertion is proven false. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: i...@bitshift-dynamics.com Technischer Support: supp...@bitshift-dynamics.com Buchhaltung: invo...@bitshift-dynamics.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
Installing additional versions is broken and, more annoyingly (but I personally only have limited need for that) using the online installer behind a proxy is also broken (can't download meta). Beste Grüße / Best regards, Alexander Nassian > Am 29.11.2016 um 18:22 schrieb Jake Petroules <jake.petrou...@qt.io>: > > >> On Nov 29, 2016, at 2:54 AM, Marco Piccolino <marco.a.piccol...@gmail.com> >> wrote: >> >> We just had a little discussion about this on QtMob >> (http://slackin.qtmob.org) where everybody does iOS/Android, and most people >> do it on a macOS host. >> It looks like people tend to use the online installer. >> When it comes to the offline installers (which in our case are mainly used >> for checking out betas, it seems) an installer for each platform seems to be >> the preferred option. >> This said, it seems that the main concern for our mobile devs is actually >> the size of the Qt for iOS distribution per se and people would like to have >> the option to not install simulator builds. > > I guarantee you we'll never do that while qmake remains the Qt build system. > But in Qt 5.9 when Qt is built as shared libraries for iOS, a lot of the > excess size should be moved out into external dSYM (debug symbol) files which > can be made an optional component in the online installer. > > Also, 32-bit iOS is not long for this world, so we may be able to halve the > size within the next few years when Apple removes all 32-bit support (even > for applications) from iOS. > >> Br, >> Marco Piccolino - QtMob community manager >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Jake Petroules - jake.petrou...@qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > ___ > 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.9
As for embedded Linux it’s not only the build and deployment itself (I usually have a separate VM for each customer and board), but much more the nature of the device itself. On the target all „real“ interfaces and features are enabled. On the desktop I disable them to speed things up and/or to compensate missing hardware - which is also really useful for automated tests. Beste Grüße / Best regards, Alexander Nassian > Am 29.11.2016 um 08:42 schrieb Jake Petroules <jake.petrou...@qt.io>: > > I don't know what sort of cross build and deployment environment you've set > up, but I've worked with Qt Creator developing on actual embedded Linux > hardware and the code-deploy-test cycle is lightning fast; no slower than > desktop at all. > > iOS may be slower in particular due to our suboptimal build process > implementation on that platform (and thus recommending that you use the iOS > Simulator instead might not be a viable alternative), but I at least have > never noticed any problems with slowness here so I'm not sure what you're > referring to. > > Android, I'm not sure. Again, possibly due to the suboptimal build process > implementation, but at least the emulators are blazing fast these days > compared to the original SDK back in 2010 or so. > >> On Nov 28, 2016, at 11:37 PM, Alexander Nassian >> <nass...@bitshift-dynamics.de> wrote: >> >> I don’t get the use case for having *only* iOS installed on my system. As >> well as for example only a cross Qt for an embedded device (iOS is >> practically the same thing). The normal development cycle should be (at >> least in my opinion) mainly develop on the desktop and check on the target >> in a regular manner. The cross build and deployment is enormously slower >> than on the desktop (which is ok with a cycle as I described), so why would >> I ever *only* use the cross build and deployment? Same thing for Android. >> Same thing for any embedded Linux target, but in contrast to Android and iOS >> we don’t deliver prebuilt binaries for them. >> >> Beste Grüße / Best regards, >> Alexander Nassian >> >>> Am 29.11.2016 um 08:24 schrieb Jani Heikkinen <jani.heikki...@qt.io>: >>> >>>> -Original Message- >>>> From: Development [mailto:development- >>>> bounces+jani.heikkinen=qt...@qt-project.org] On Behalf Of Jake Petroules >>>> Sent: maanantaina 28. marraskuuta 2016 20.23 >>>> To: Alexander Blasche <alexander.blas...@qt.io> >>>> Cc: development@qt-project.org; releas...@qt-project.org >>>> Subject: Re: [Development] Qt 5.9 >>>> >>>> >>>>> On Nov 28, 2016, at 7:40 AM, Alexander Blasche >>>> <alexander.blas...@qt.io> wrote: >>>>> >>>>> Ok, let's summarize and restate the package list for Qt 5.9 based on the >>>> comments provided on this mail thread. The list describes the delta to Qt >>>> 5.8 >>>> packages: >>>>> >>>>> * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 >>>>> * For iOS we drop 7.x and support 8.x, 9.x, 10.x >>>> >>>> * For tvOS we drop 9.x and support 10.x >>>> * For watchOS we drop 2.x and support 3.x >>>> >>>>> * MinGW remains 5.3 using 32 bit >>>>> * Add MSVC 2017 64bit desktop >>>>> * Add MSVC 2017 UWP (x64, x86, armv7) >>>>> * Drop MSVC 2013 x86 >>>>> * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and >>>> WinPhone 8.1 >>>>> * Drop standalone macOS Android installer; One having iOS & Android >>>> >>>> As I said, let's not, and instead drop the massive macOS+iOS+Android >>>> installer in favor of an iOS-only installer. >>> >>> Is it really so that users of iOS installer needs only iOS binaries and >>> nothing for desktop side? >>> >>> In this case I agree this might be the optimal solution but this doesn't >>> decrease amount of our installers and that's why I prefer just dropping >>> that one & keep those two old ones: >>> - one just for macOS + another one for macOS, iOS & Android >>> >>> br, >>> Jani >>> >>>> >>>>> * For Windows Android start doing Android Windows build with MinGW53 >>>>> * Start supporting QNX 7.0 >>>>> >>>>> -- >>>>> Alex >>>>> >>>>> ___ >>
Re: [Development] Qt 5.9
I don’t get the use case for having *only* iOS installed on my system. As well as for example only a cross Qt for an embedded device (iOS is practically the same thing). The normal development cycle should be (at least in my opinion) mainly develop on the desktop and check on the target in a regular manner. The cross build and deployment is enormously slower than on the desktop (which is ok with a cycle as I described), so why would I ever *only* use the cross build and deployment? Same thing for Android. Same thing for any embedded Linux target, but in contrast to Android and iOS we don’t deliver prebuilt binaries for them. Beste Grüße / Best regards, Alexander Nassian > Am 29.11.2016 um 08:24 schrieb Jani Heikkinen <jani.heikki...@qt.io>: > >> -Original Message- >> From: Development [mailto:development- >> bounces+jani.heikkinen=qt...@qt-project.org >> <mailto:bounces+jani.heikkinen=qt...@qt-project.org>] On Behalf Of Jake >> Petroules >> Sent: maanantaina 28. marraskuuta 2016 20.23 >> To: Alexander Blasche <alexander.blas...@qt.io >> <mailto:alexander.blas...@qt.io>> >> Cc: development@qt-project.org <mailto:development@qt-project.org>; >> releas...@qt-project.org <mailto:releas...@qt-project.org> >> Subject: Re: [Development] Qt 5.9 >> >> >>> On Nov 28, 2016, at 7:40 AM, Alexander Blasche >> <alexander.blas...@qt.io> wrote: >>> >>> Ok, let's summarize and restate the package list for Qt 5.9 based on the >> comments provided on this mail thread. The list describes the delta to Qt 5.8 >> packages: >>> >>> * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 >>> * For iOS we drop 7.x and support 8.x, 9.x, 10.x >> >> * For tvOS we drop 9.x and support 10.x >> * For watchOS we drop 2.x and support 3.x >> >>> * MinGW remains 5.3 using 32 bit >>> * Add MSVC 2017 64bit desktop >>> * Add MSVC 2017 UWP (x64, x86, armv7) >>> * Drop MSVC 2013 x86 >>> * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and >> WinPhone 8.1 >>> * Drop standalone macOS Android installer; One having iOS & Android >> >> As I said, let's not, and instead drop the massive macOS+iOS+Android >> installer in favor of an iOS-only installer. > > Is it really so that users of iOS installer needs only iOS binaries and > nothing for desktop side? > > In this case I agree this might be the optimal solution but this doesn't > decrease amount of our installers and that's why I prefer just dropping that > one & keep those two old ones: > - one just for macOS + another one for macOS, iOS & Android > > br, > Jani > >> >>> * For Windows Android start doing Android Windows build with MinGW53 >>> * Start supporting QNX 7.0 >>> >>> -- >>> Alex >>> >>> ___ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> -- >> Jake Petroules - jake.petrou...@qt.io >> The Qt Company - Silicon Valley >> Qbs build tool evangelist - qbs.io >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > ___ > Development mailing list > Development@qt-project.org <mailto:Development@qt-project.org> > http://lists.qt-project.org/mailman/listinfo/development > <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] tag in QTextEdit
Instead of begging on a maillist and otherwise implementing it proprietary in your application, wouldn't it be an option to contribute the support of these tags to the Qt project? Beste Grüße / Best regards, Alexander Nassian > Am 26.11.2016 um 19:59 schrieb ser00 <sersve...@gmail.com>: > > I create topic in Forum > https://forum.qt.io/topic/73709/when-qtextedit-will-understand-tag-strike May > you add support of tag to QTextEdit and other classes? It is useful > for paste rich text from browsers. If no and never, please tell it and I will > write support manually to my application. What about add some other not > supported tags? It may be or never? > > P.S. I correct my program code for support the tag manually in my child class > , so the problem is not relevant for me now. But for other users may be. > > Sergey > > ___ > 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.9
Also a +1 from me. Its simply the easiest and most hassle free way for newcomers to start on Windows and it runs everywhere. In my opinion 32bit should have been completely stopped 10 years ago, but sadly the reality is ugly. Beste Grüße / Best regards, Alexander Nassian > Am 25.11.2016 um 19:29 schrieb Kevin Kofler <kevin.kof...@chello.at>: > > Bo Thorsen wrote: >> The reason for doing 32 bit MSVC releasees is 3rd party libraries. Is >> that a valid reason for MinGW? I would have thought that the guys using >> it pretty much have to compile everything themselves anyway. > > C libraries are normally interoperable between VC and MinGW. Even C++ > libraries with a purely extern "C" API should work with both compilers. Only > the C++ ABI is incompatible. > > So you can have a 32-bit binary-only DLL that works with MinGW32, but of > course not with MinGW64. > >Kevin Kofler > > ___ > 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] Basing Qt Creator Coding Style on C++ Core Guidelines?
Will there be now 10 BC discussions every year? At least it feels like. Why can't it be decided and then accepted by everyone as is? In my personal opinion I don't care much about BC but I'm happy that it blocks STL usage because its brutally unnatural and I stumbled so often over different behaviors of it on different platforms and compilers that I have a real hate on the STL. Beste Grüße / Best regards, Alexander Nassian > Am 19.11.2016 um 10:22 schrieb Иван Комиссаров <abba...@gmail.com>: > > Maybe we should start another thread about BC? > I'm not convinced that MacOS is the only system when mixing libc++/stdlib > makes sence. On linux you can do the same. If we will use stl, the Qt version > installed from packages can't be used for development, you should use > libc++/stdlib Qt version from Qt site. Not a problem, really. > The problem is the incompatibility between compiler versions. I had a plugin > build with gcc 4.7 and i spent 2 hours to find the reason why it crashed with > library build with gcc 4.8 (i didn't know that compiler updated on build > host). The problem was that std::unordered_map was BiC. > So, Qt have to support each gcc (actually, stdlib/libc++ version) major > version. > And you will have reinstall Qt (almost) each time you update the compiler > package. > Correct me if i'm wrong. > > 2016-11-19 10:04 GMT+03:00 Marc Mutz <marc.m...@kdab.com>: >> On Friday 18 November 2016 22:12:44 Thiago Macieira wrote: >> > Em sexta-feira, 18 de novembro de 2016, às 20:37:26 PST, Marc Mutz >> > escreveu: >> > > There's no reason for Qt to extend its BC guarantees to other libraries. >> > > STL, GSL, Boost, std::exception, you name it. They are outside of Qt's >> > > realm and therefore do not fall under the Qt BC rules. >> > >> > Which is the reason we can't accept them in our ABI. The rules are >> > incompatible. >> >> If you extend this argument to its logical conclusion, Qt should be BC >> between >> debug and releases on MSVC. Many libraries manage. Gpgme, e.g. Why doesn't >> Qt? >> >> You see, that argument is completely empty. The STL is forbidden because >> people are uncomfortable with it, not because it causes BiC. The >> debug/release >> stuff on MSVC is allowed to be BiC because people have come to accept it as >> reality. Neither one is any more right or wrong inherently, than the other. >> >> Thanks, >> Marc >> >> -- >> Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer >> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >> Tel: +49-30-521325470 >> KDAB - The Qt, C++ and OpenGL Experts >> ___ >> 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] Compile errors, Qt configured with -qreal float
> Am 27.10.2016 um 08:23 schrieb Marc Mutz <marc.m...@kdab.com>: > >> On Thursday 27 October 2016 01:23:15 Thiago Macieira wrote: >> On quinta-feira, 27 de outubro de 2016 00:49:21 PDT Ola Røer Thorsen wrote: >>>> https://codereview.qt-project.org/175025 >>> >>> That's sort of a "sledge hammer" fix. Wouldn't this make it easier to be >>> careless about mixing floats and doubles? I think it's a good practice to >>> avoid mixing when possible, with regards to performance especially on >>> smaller embedded devices. >> >> Yes and no. qMax and qMin have been the bane of qreal for the last 10 years >> because they are template functions. Solving those two will solve 95%+ of >> the qreal=float issues. That means the chance of having a release that >> fails to build under that condition lessens considerably. > > And, again, by proprietarily extending a perfectly adequate std > functionality, > we lock ourselves deeper into our NIHS, losing new functionality provided by > newer std versions, in this case: variadic std::min/max. > And depend more and more on different std implementations that introduce different behavior on different platforms and compilers? And let external software (that gcc issue is not that long in the past) break Qt's binary compatibility? Personally, I always prefer the uniform Qt style as I can rely on that platform and compiler independent functionality. Also I prefer code that looks like made out of a single piece. I don't like to incorporate x different libraries with x different coding and API styles. If so, I could also go and use GTK *ugh* Just my 2 cents ;) Best regards, Alexander Nassian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt build without Virtual Keyboard
Hi, We are trying to build 5.7 on Linux without OpenGL support (so no QtQuick either) and are facing a build error in qtvirtualkeyboard „Module quick not found“. Is QtQuick now mandatory, or is this a known bug? And why is the virtual keyboard building at all when choosing L-GPL? That’s not very nice. Beste Grüße / Best regards, Alexander Nassian, bitshift dynamics GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How can I only select border not inside rectangle to select QGraphicsRectItem
Hi, Please note that development@qt-project.org is the mailing list for developers _of_ Qt. Developers who _use_ Qt should use inter...@qt-project.org. Beste Grüße / Best regards, Alexander Nassian, bitshift dynamics GmbH > Am 03.10.2016 um 23:51 schrieb itviewer <assang...@gmail.com>: > > Hi, > I draw a rectangle with QGraphicsRectItem. it only has a border and not be > filled. like this: > <1.png> > > when I click inside the rectangle,it will be selected，but I would like only > click on the border to select, not inside. > how can i get it? > > Thanks. > > > itviewer > ___ > 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] Using semicolons in JS (QML)
I personally use semicolons always when {} is incorporated. And {} I'm using
when its more than a single statement.
Beste Grüße / Best regards,
Alexander Nassian, bitshift dynamics GmbH___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Too long text in qlabel crashes my gdm
FTR on my macOS machine with Qt 5.7.0 it doesn’t crash.
What Qt version do you use? QApplication::UnicodeUTF8 is unknown as well as the
translate() overload that your code uses.
Beste Grüße / Best regards,
Alexander Nassian, bitshift dynamics GmbH
> Am 29.09.2016 um 22:08 schrieb Kotanski, Jan <jan.kotan...@desy.de>:
>
> Hi,
>
> I've noticed that too long test in qlabel e.g.
>
> void retranslateUi(QDialog *Dialog)
>{
>Dialog->setWindowTitle(QApplication::translate("Dialog", "Dialog", 0,
> QApplication::UnicodeUTF8));
>char str[2000];
>for(int i=0; i<1999;i++)
> str[i] = 'a';
>str[1999]='\0';
>label->setText(QApplication::translate("Dialog", str, 0,
> QApplication::UnicodeUTF8));
>} // retranslateUi
>
> crashed my gdm (for gnome 3).
>
> Is it a known problem? How to fix it?
>
> More info on:
>
> https://www.riverbankcomputing.com/pipermail/pyqt/2016-September/038145.html
>
> Bests,
> Jan
> ___
> 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] Too long text in qlabel crashes my gdm
Hi,
Does this also happen if you use QString instead of char[]?
Beste Grüße / Best regards,
Alexander Nassian, bitshift dynamics GmbH
> Am 29.09.2016 um 22:08 schrieb Kotanski, Jan <jan.kotan...@desy.de>:
>
> Hi,
>
> I've noticed that too long test in qlabel e.g.
>
> void retranslateUi(QDialog *Dialog)
>{
>Dialog->setWindowTitle(QApplication::translate("Dialog", "Dialog", 0,
> QApplication::UnicodeUTF8));
>char str[2000];
>for(int i=0; i<1999;i++)
> str[i] = 'a';
>str[1999]='\0';
>label->setText(QApplication::translate("Dialog", str, 0,
> QApplication::UnicodeUTF8));
>} // retranslateUi
>
> crashed my gdm (for gnome 3).
>
> Is it a known problem? How to fix it?
>
> More info on:
>
> https://www.riverbankcomputing.com/pipermail/pyqt/2016-September/038145.html
>
> Bests,
> Jan
> ___
> 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] Using platform-native APIs for terminating QThreads
> Am 05.09.2016 um 18:38 schrieb Giuseppe D'Angelo <giuseppe.dang...@kdab.com>: > > Il 05/09/2016 16:08, Viktor Engelmann ha scritto: >> We can lock away OUR guns so the user can't shoot himself in the foot >> with them, but if he goes out and buys his own gun, there is nothing we >> can (or should) do about it. > > That's not the point. The point is that every time we do an apparently > innocuous change (maybe thinking "surely we never promised POSIX > semantics for our threads!") it turns out that instead there are people > out there that are relying on this behaviour (for whatever reason). Please don’t get me wrong, but that would imply that if enough people (for whatever reason) expect eg. QSettings to be compatible with WinAPI calls that should be changed. If I’m not wrong QThread doesn’t event expose the native handle in a reliable way, so why should Qt support API abuse by the user? Beste Grüße / Best regards, Alexander Nassian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Using platform-native APIs for terminating QThreads
Hi, Is, or should, that even be supported? I’m just wondering because when I’m using Qt to create a thread, I also use Qt to quit it. Why should anybody use a „foreign“ API? Beste Grüße / Best regards, Alexander Nassian > Am 02.09.2016 um 12:32 schrieb Giuseppe D'Angelo <giuseppe.dang...@kdab.com>: > > Howdy, > > I'm trying to introduce a change [1] which will make QThread invoke > std::terminate in case an exception is thrown from the new thread > (including, but not limited to: user's reimplementation of QThread::run; > slots listening to the QThread::started / finished signals; custom event > dispatchers). > > The idea is to align ourselves to what std::thread does. > > There's a small catch, however: user code might be using platform-native > APIs such as pthread_exit(3) in order to make a QThread quit. > > On some implementations (notably: glibc), pthread_exit is implemented by > throwing an exception, because it needs to run the pushed cleanup > handlers. The net result is that, with my change applied, pthread_exit > won't make the thread exit but crash the application instead (!). > > The question for the ML is: is this a scenario Qt has ever officially > supported, and a scenario that we should support in the future? > > (QThread documentation does not talk about how QThread itself is > implemented, so actually relying on the that it has pthread semantics is > already a slight API abuse by the users). > > [1] https://codereview.qt-project.org/#/c/167240/ > > Cheers, > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 > KDAB - The Qt Experts > > ___ > 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] [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming...
May I kindly ask why PDF shall now be disabled on embedded systems? Best regards, Alexander Nassian > Am 12.08.2016 um 15:03 schrieb Kai Koehne <kai.koe...@qt.io>: > > Hi, > > Unfortunately, we're having great difficulties to get patches integrated into > Qt WebEngine in the last days, right now due to qtlocation not compiling > (QTBUG-55229). Unless the situation resolves itself over the weekend, I'd > like to ask for an exception for getting features into 5.8 for Qt WebEngine > even after Monday morning. > > The features still waiting to get merged are > Printing: https://codereview.qt-project.org/#/c/162928/ and following > Printing of CSS backgrounds: https://codereview.qt-project.org/#/c/167484/ > Support for certificate transparency: > https://codereview.qt-project.org/#/c/167275/ > Support for custom QML context menu/ dialogs: > https://codereview.qt-project.org/#/c/162263/, > https://codereview.qt-project.org/#/c/165731/ > Support for Qt Quick 2 Controls dialogs: > https://codereview.qt-project.org/#/c/162262/ > > Regards > > Kai > > >> -Original Message- >> From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io@qt- >> project.org] On Behalf Of Jani Heikkinen >> Sent: Monday, August 08, 2016 12:58 PM >> To: development@qt-project.org >> Cc: releas...@qt-project.org >> Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 >> Feature Freeze coming... >> >> Hi all, >> >> >> >> >> Qt5.git integration in 'dev' succeed during the weekend and we have soft >> branched '5.8' from 'dev'. It means Qt 5.8 Feature Freeze will be effect 15th >> August 2016 as well as final branching from 'dev' to '5.8' >> >> >> >> >> >> So please start using '5.8' for changes targeted to Qt 5.8 release and >> finalize >> ongoing ones in 'dev'. Final downmerge from 'dev' to '5.8' will happen >> Monday 15th Aug (morning). >> >> >> >> >> Please make sure >> >> >> - All new modules for Qt 5.8 are in 'dev' & part of qt5.git >> >> >> - All mandatory new features are in 'dev' now or coming in within a week? >> >> >> - New feature page contains all new features etc: >> https://wiki.qt.io/New_Features_in_Qt_5.8 >> >> >> >> >> We will create first src packages from latest qt5.git integration as soon as >> possible. Please check the packages immediately when available to see if >> something important is missing. Those packages should be quite close to Qt >> 5.8 alpha packages so it will be really important to check the packages now. >> >> >> >> >> br, >> >> Jani >> >> >> >> >> >> Jani Heikkinen >> Release Manager >> >> The Qt Company >> Elektroniikkatie 13 >> 90590 Oulu Finland >> jani.heikki...@qt.io >> +358 50 4873735 >> http://qt.io <http://qt.io/> >> >> >> <http://qt.io/> >> <http://www.facebook.com/Qt> >> <http://www.twitter.com/qtproject> >> <https://www.linkedin.com/company/the-qt-company/> >> <https://plus.google.com/104580575722059274792> >> <https://www.youtube.com/QtStudios> > > ___ > 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] Adding 3rdpary libraries to QtSerialBus
> Am 11.08.2016 um 22:22 schrieb Thiago Macieira <thiago.macie...@intel.com>: > > On quinta-feira, 11 de agosto de 2016 19:50:35 PDT Alexander Nassian wrote: >>> And they're LGPLv2. The v3 clauses cause lots of companies to run away. >> >> Really? v3 just clarifies some of the implications of v2 in a more suitable >> way for lawyers. Many people that run away don't know how to get their >> products safe with the requirement to let the user on the system. But it's >> possible and no real reason against v3. > > The "v3" is hardly "just clarifies" over the v2. It adds at least two extra > provisions: > * the patent grant > * the "installation instructions" clause I recommend you viewing the Video with Dr. Till Jäger which is published on the Qt website - he also supports the view that mostly the same requirements exist (at least in european law) with 2.1 based on the license's spirit and wording: https://www.qt.io/qt-licensing-terms/ > > Regardless of whether the reasons why companies run away is valid or not, the > fact is that they do. I submit Evidence A: Apple stopped updating GCC when it > went GPLv3 in version 4.3 and instead started their own compiler. Apple's license strategy is not really an evidence. Apple was never a big fan of any kind of GPL licensed software. Which is understandable due to the BSD and more Unixishes nature of OS X. The license was surely one of the reasons for LLVM/Clang, but definetly not the only one. > > So it's unimportant whether the reasons are valid. It's important that we > understand the consequences if we do choose to accept an LGPLv3 dependency. > Sure. That's imprtant. Sorry if some people see me overtaking this thread with offtopic, but I just wanted to state my sight on this issue that came up as part of this thread. Best regards and have a nice weekend! Alexander Nassian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding 3rdpary libraries to QtSerialBus
Interesting enough that Qt itself switched the OSS license to v3 ... > Am 11.08.2016 um 22:22 schrieb Thiago Macieira <thiago.macie...@intel.com>: > > On quinta-feira, 11 de agosto de 2016 19:50:35 PDT Alexander Nassian wrote: >>> And they're LGPLv2. The v3 clauses cause lots of companies to run away. >> >> Really? v3 just clarifies some of the implications of v2 in a more suitable >> way for lawyers. Many people that run away don't know how to get their >> products safe with the requirement to let the user on the system. But it's >> possible and no real reason against v3. > > The "v3" is hardly "just clarifies" over the v2. It adds at least two extra > provisions: > * the patent grant > * the "installation instructions" clause > > Regardless of whether the reasons why companies run away is valid or not, the > fact is that they do. I submit Evidence A: Apple stopped updating GCC when it > went GPLv3 in version 4.3 and instead started their own compiler. > > So it's unimportant whether the reasons are valid. It's important that we > understand the consequences if we do choose to accept an LGPLv3 dependency. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding 3rdpary libraries to QtSerialBus
Am 11.08.2016 um 19:42 schrieb Thiago Macieira <thiago.macie...@intel.com>: > >> On quinta-feira, 11 de agosto de 2016 19:12:26 PDT Alexander Nassian wrote: >> Why should that not be possible? With Chromium we already have L-GPLv2 and >> many other. Qt itself is also available as v3. > > WebKit (including JSC) was an exception and Chromium inherited that > exception. > It's one that didn't please commercial customers much. > > And they're LGPLv2. The v3 clauses cause lots of companies to run away. Really? v3 just clarifies some of the implications of v2 in a more suitable way for lawyers. Many people that run away don't know how to get their products safe with the requirement to let the user on the system. But it's possible and no real reason against v3. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding 3rdpary libraries to QtSerialBus
Why should that not be possible? With Chromium we already have L-GPLv2 and many other. Qt itself is also available as v3. Beste Grüße / Best regards, Alexander Nassian > Am 11.08.2016 um 18:21 schrieb Thiago Macieira <thiago.macie...@intel.com>: > >> On quinta-feira, 11 de agosto de 2016 15:28:47 PDT André Hartmann wrote: >> In this thread, Kurt Van Dijck proposed his network interface >> enumeration library [2], licensed under LGPL V3 > > That would be a first if we allowed this. It's unlikely that we'll allow > importing of an LGPLv3-licenced library. > > Instead, I advise: > 1) detect the library at compile time, installed system-wide > 2) add a workaround without that library, as the commercial version of >QtSerialBus will most likely not enable this library > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: change QML Flickable's flickableDirection default value to AutoFlickIfNeeded in 5.8
Hi Andrea, Good proposal! But one little hint: The current behavior is not that confusing as you describe. On iOS and OS X for example the current behavior is normal. Beste Grüße / Best regards, Alexander Nassian http://www.bitshift-dynamics.de > Am 26.07.2016 um 16:12 schrieb Andrea Bernabei <and.berna...@gmail.com>: > > Hello everyone, > > I'd like to propose changing the default value of QML Flickable's > flickableDirection in Qt 5.8. > > The current default value is Flickable.AutoFlickDirection > The description is: it "allows flicking vertically if the contentHeight is > not equal to the height of the Flickable. Allows flicking horizontally if the > contentWidth is not equal to the width of the Flickable." > > It seems to me like the current default was chosen to make it so that the > surface is always draggable except for things like vertical ListViews (where > contentWidth==width, or the same for height in the case of horizontal lists). > > I propose we should change the default value to Flickable.AutoFlickIfNeeded > (added by Shawn, Flickable's maintainer, in 5.7 > https://codereview.qt-project.org/#/c/150388/ ). > > I'll try using bullet points to avoid a wall of text. > > Proposal: > Change default Flickable's flickableDirection to AutoFlickIfNeeded in Qt5.8, > and only available when importing QtQuick >= 2.8 > > Why: > The current behaviour is a bit confusing. If we only take the horizontal > dimension into account: > - content narrower than Flickable --> content IS draggable (why?) > - content same size as Flickable --> content NOT draggable > - content wider than Flickable --> content IS draggable > > While with the proposed change: > - content narrower than Flickable --> content NOT draggable > - content same size as Flickable --> content NOT draggable > - content wider than Flickable --> content IS draggable > > I believe the new behaviour is better, the content is only draggable when > dragging "makes sense", i.e. when dragging would reveal additional content > that would otherwise be hidden. > > What do you guys think? > > Cheers, > Andrea (faenil) > ___ > 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.7.0 Toolchain on RasPI2
Hi Thiago, Would be great if you could be a little bit more specific. I’m using exactly the same toolchain and the same sysroot for 5.5.1 and 5.7.0. The 5.5.1 build works perfectly, the 5.7.0 build fails while linking. Is the GCC 4.8.3 which is used for Raspian not supported anymore? Beste Grüße / Best regards, Alexander Nassian > Am 20.06.2016 um 09:02 schrieb Thiago Macieira <thiago.macie...@intel.com>: > > On domingo, 19 de junho de 2016 21:36:21 PDT Alexander Nassian wrote: >> EGLFS and others were disabled because of the already mentioned linker >> error. >> >> /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-g >> nueabihf/libpthread.so.0: undefined reference to `__mktemp@GLIBC_PRIVATE' > > This is a toolchain error. Fix your toolchain. > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.7.0 Toolchain on RasPI2
The configure command is: ../qt-everywhere-opensource-src-5.7.0/configure -opensource -confirm-license -no-pch -no-xcb -nomake tests -make libs -device linux-rasp-pi2-g++ -nomake examples -device-option CROSS_COMPILE=/home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/current_toolchain/arm-linux-gnueabihf- -sysroot /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs -no-gcc-sysroot -prefix /usr/local/qt-5.7.0 -vEGLFS and others were disabled because of the already mentioned linker error./home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/libpthread.so.0: undefined reference to `__mktemp@GLIBC_PRIVATE'/home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/librt.so.1: undefined reference to `__clock_settime@GLIBC_PRIVATE'/home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/librt.so.1: undefined reference to `__clock_getcpuclockid@GLIBC_PRIVATE'/home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/libpthread.so.0: undefined reference to `__call_tls_dtors@GLIBC_PRIVATE'/home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/libpthread.so.0: undefined reference to `__madvise@GLIBC_PRIVATE'/home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/librt.so.1: undefined reference to `__clock_nanosleep@GLIBC_PRIVATE'/home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/libpthread.so.0: undefined reference to `__ctype_init@GLIBC_PRIVATE'/home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/librt.so.1: undefined reference to `__clock_getres@GLIBC_PRIVATE'/home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/librt.so.1: undefined reference to `__clock_gettime@GLIBC_PRIVATE’Please find attached the complete configure log. Beste Grüße / Best regards,Alexander NassianAm 19.06.2016 um 21:18 schrieb Thiago Macieira <thiago.macie...@intel.com>:On domingo, 19 de junho de 2016 17:44:21 PDT Alexander Nassian wrote:Hi,Currently I’m doing a 5.7.0 build for RasPI 2 with Raspian using the„official“ toolchain (arm-linux-gnueabihf-g++ (crosstool-NGlinaro-1.13.1+bzr2650 - Linaro GCC 2014.03) 4.8.3 20140303 (prerelease)).EGLFS wasn’t detected (don’t need it atm either)configure -v output showing why it was discarded missing.and the build stopped witha linker error because of missing clock_gettime in QElapsedTimer. You didn't include the error message. Please include the link command-line too.Thecommon recommendation adding -lrt to the linker options didn’t work becauseconfigure will then don’t detect C++11 support. Information missing.I didn’t find anything related in the bug tracker (or maybe I searched thewrong way). For this reason I wanted to ask here if this is a knownproblem, or a known wrong configuration thing? If not I would be happy toprovide configuration, compiler output, etc..None of those are known issues.-- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center___Development mailing listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development configure.log Description: Binary data ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.7.0 Toolchain on RasPI2
Hi, Currently I’m doing a 5.7.0 build for RasPI 2 with Raspian using the „official“ toolchain (arm-linux-gnueabihf-g++ (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) 4.8.3 20140303 (prerelease)). EGLFS wasn’t detected (don’t need it atm either) and the build stopped with a linker error because of missing clock_gettime in QElapsedTimer. The common recommendation adding -lrt to the linker options didn’t work because configure will then don’t detect C++11 support. So I started a 5.5.1 build as a reference and suddenly EGLFS support was automagically detected and it went perfectly over the linking of QtCore. I didn’t find anything related in the bug tracker (or maybe I searched the wrong way). For this reason I wanted to ask here if this is a known problem, or a known wrong configuration thing? If not I would be happy to provide configuration, compiler output, etc.. Beste Grüße / Best regards, Alexander Nassian___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Internal compiler error when building dev branch of qtbase with MSVC2015 on Windows 10
Do you know this and did you already tried the suggested steps to fix? https://support.microsoft.com/en-us/kb/305980 Beste Grüße / Best regards, Alexander Nassian > Am 20.05.2016 um 11:11 schrieb Mitch Curtis <mitch.cur...@qt.io>: > > Is anyone else able to reproduce this? I configured Qt with the following > arguments (shadow build): > > -debug -developer-build -opensource -confirm-license -nomake tests -nomake > examples -opengl desktop > > If I use nmake instead of jom, the only error comes from qlogging.cpp. > > I've attached the output of jom. > ___ > 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] Stop insertion QTextEdit unicode character.
You see the condition in line 2288: d->interactionFlags & Qt::TextEditable) && QGuiApplication::styleHints()->useRtlExtensions() So, right-to-left writing direction must be active and the input field must be editable. Are you using or do you need RTL writing? If not, you could just disable it as a quick fix. Maybe this context menu should be en-/disableable by the application developer? I don’t know enough about RTL systems, do they need this coding selection? Beste Grüße / Best regards, Alexander Nassian > Am 09.05.2016 um 09:59 schrieb kang joni <kangjon...@gmail.com>: > > Sorry for my bad English, Quick grep-ing in qtbase 5.6 > src/widgets/widgets/qwidgettextcontrol.cpp at line 3254 just found my > case here. I don't know how to use this. And I didnt aware any of docs > explaining this. If you right click on editable QLineEdit or QTextEdit > there should be "Insert Unicode control > character", sorry my former title was bit wrong typo here. So, back > to my case whenever I type from ASCII and then accidentally clicking > from "Insert Unicode control > character" with any selecting LRM,RLM ... etc I didn't know how to > switch back to type ASCI I character with exception close app window > and reopen it again, and everything would be normal again. This all > happen in all Qt apps. > ___ > 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] Does Qt 5.6 still depend on ICU?
As far as I know Chromium also depends on ICU and without WebKit or WebEngine you may but need not to use ICU. But I sadly don't know if and what features are (internally) missing if Qt is not built with ICU - for our applications we always have to build it with because of WebKit/WebEngine. Beste Grüße / Best regards, Alexander Nassian > Am 07.05.2016 um 23:25 schrieb Roland Winklmeier > <roland.m.winklme...@gmail.com>: > > Dear Qt Devs, > > I'm currently preparing installers for a cross platform application > (Win, Linux, OSX). I have investigated, which dependencies apart from > the Qt5 libraries themselves are need to be shipped as well. But I'm a > bit confused about the role of ICU. > > From wiki pages (https://wiki.qt.io/Qt_5.6_Tools_and_Versions and > https://wiki.qt.io/Building_Qt_5_from_Git), I understood that, ICU is > only required for QtWebkit. I also learned that the ICU version shipped > in Qt 5.6.0 is 56.1. > > However, I found the following facts a bit inconsistent: > * Windows is actually shipping 54.1 instead of 56.1. Was the upgrade > missed or is this on purpose? To me it is a minor issue, but I'm curious. > * Official Windows QtCore binary is not linked against ICU libraries (at > least from what I can see in dependency walker). Does it link at runtime? > * Official Linux QtCore binary in contrast is linked against ICU > (verified with ldd). > * Official OS X QtCore binary again is not linked against ICU. > > Now my question: > Is ICU mandatory for all platforms or maybe only for Linux? Ideally I > could just skip shipping it in my installer, since I'm using a custom > Qt5 build on my Debian server (I did not yet manage to use the official > installer on a headless server with an install script). But I want to be > sure, what features I'm loosing before any decision. ? > > *guess mode on* > I guess, ICU was shipped previously because of QtWebkit. Since QtWebkit > is no longer shipped in official installers, could ICU also be removed? > I know what ICU is, but why is it shipped without linking against it? > *guess mode off* > > Cheers Roland > ___ > 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-Project misrepresented on qt.io
I also see a growing trend at The Qt Company on trying to sell more commercial licenses by creating fear because of the opensource licenses. At any corner you hear „ohh, ohh that may not be legal to distribute, but just be sure buy a license“. This makes me kind of sad. I love Qt, I love commercial services and I love open source. Commercial support or additions to opensource projects should be sold by providing a benefit to the customer, not by creating fear. Just my 2 cents, Alexander Nassian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
