Re: [Development] QWidget::setWindowState(Qt::WindowStates) vs QWindow::setWindowState(Qt::WindowState)
Hej Thomas, Please don't take silence as some indication that people are offended. I just think you found a corner case that no one has considered and do not consider one way or the other. You ask for the best way to proceed: As usual with issues like this, you should enter a bug in the bug tracker. Bo Thorsen. Den 18-01-2017 kl. 16:21 skrev Thomas Søndergaard: I hope my previous email wasn't offensive or downright stupid; no one has replied. I certainly meant no disrespect. While I'm waiting for a response, let me throw a specific proposal out there. First, I assume the correct solution is to extend QWindow and QPlatformWindow so they can deal with compound states such as Qt::WindowMaximized|Qt::WindowMinimized, just like QWidget can. Since QWindow::setWindowState(Qt::WindowState) and Qt::WindowState QWindow::windowState() cannot be modified, I'm thinking of adding Qt::WindowStates QWindow::fullWindowState() const; void QWindow::setFullWindowState(Qt::WindowStates); and Qt::WindowStates QPlatformWindow::fullWindowState() const; void QPlatformWindow::setFullWindowState(Qt::WindowStates); The existing QWindow::windowState() would then be implemented using the effectiveState() function from qwidget.cpp (I'd move it over) I can experiment with these changes and implementing them in the xcb and windows platform plugins, but early feedback is always great, so I avoid wasting time. Thanks for making Qt Thomas On 17 January 2017 at 21:37, Thomas Søndergaard <thomas.sonderga...@karoshealth.com <mailto:thomas.sonderga...@karoshealth.com>> wrote: Hi, I'm looking at the Qt code with intention to fix it so this code QWidget widget; widget.setWindowState(Qt::WindowMaximized); widget.showMinized(); will show the window iconified and when the user (or program) unminimize the window it pops up maximized. This is currently not possible (QTBUG-57882 <https://bugreports.qt.io/browse/QTBUG-57882>). I've been trying to read the Qt code and it seems to me the problem is that QWindow::setWindowState(Qt::WindowState) and QPlatformWindow::setWindowState(Qt::WindowState) only take a Qt::WindowState argument not a Qt::WindowStates argument. This seems to make it impossible to set the correct state on the windows-system window. Is this intentional or a known issue? I would be happy to get suggestions for how this is best fixed. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] two questions about the build system of Qt
Den 29-11-2016 kl. 19:53 skrev Cor-Paul Bezemer: Hi, I am a researcher in a team that is working on build systems and we are doing a case study on missing dependencies in the Qt 5.3.0 build system. I know that Qt 5.3.0 is an old version but the case study is part of a paper that has been under review for more than a year now. Could you say a bit more about why you are doing this and what you are hoping to achieve? It's not often that I see someone investigating things like the two issues you found. Thanks, Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
Den 23-11-2016 kl. 23:10 skrev Thiago Macieira: On quarta-feira, 23 de novembro de 2016 21:14:52 PST Simon Everts wrote: That is not relevant here. I am using Windows 10 (64-bit) but I am still forced (because of 3rt-party-libraries) to develop 32-bit-Qt-applications. Even if the operating system is 64-bit there can be a lot of 32-bit application, e.g. VS 2013 and VS 2015 are still 32-bit applications. +1 As a machine manufacturer we are still deploying 32bit windows systems because of this reason. We'll be on 64bit windows soon, but need to support the 32bit systems for at least 5 years. A lot of industrial computer suppliers still install 32bit images on computers because there aren't any 64bit drivers available for the hardware. Good, thanks for the information, Simon and Helmut. I know the sample size here is horrible, but in your opinion what compiler should we keep offering a 32-bit binary build for? MSVC 2013 MSVC 2015 MinGW 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. I don't know, though. I won't ever use MinGW myself unless a customer forces me to. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016
Den 08-09-2016 kl. 14:19 skrev Konstantin Tokarev: > The only problem is that you have to run moc on each of the .h files. Run moc from inside script when you generate header. Yes, I thought about that at the time as well. While simple enpough, there are some complications. You would have to run moc exactly like if it was done by the qmake built makefiles, with exactly the same environment and arguments. Not impossible, but it does sound brittle. For example different qmake versions might do things differently. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016
Den 08-09-2016 kl. 13:47 skrev Milian Wolff:
On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote:
Den 05-09-2016 kl. 20:49 skrev Milian Wolff:
As an incredibly simple example, make is inherently limited in that it
cannot even represent a rule with multiple outputs (there are some
workarounds, but they are hacky and rather limited in how they can be
applied). And ninja is no magic bullet here either, because that still
represents a static build graph, whereas the content of Qbs' build
graph
can actually change during the execution of the build.
Can you give an example for why we should care? This may sound
flame-baity,
but I'm really truly interested. I simply don't care about my build
system, as long as it gets the job done without too much hassle (and yes,
that is the case for me personally with cmake), and fast, too (which is
the case with ninja). See also below.
I can answer that because I asked for this feature all the way back at
QtCS in Bilbao.
The context I was talking about was code generators. At the time I had
built a code generator that created both the Qt and the PHP side of a
client-server system. It had a single JSON file that described a server
with the available remote methods on it. The output from the C++ code
generator was a .h and .cpp file per method and a single .h and .cpp
that described the server. So on qmake run time you can't know how many
output files you have unless you force the user to run qmake every time
you modify the JSON description.
And to make the problem worse, the customer wanted each of the classes
describing a remote call to be qobjects with a Q_OBJECT so a moc run is
required.
AFAIK this is impossible to do with both qmake and cmake. Not just hard,
actually impossible.
At least for CMake, I don't think so - if I'm not misunderstanding the
problem. You add a target that depends on your .json file, and then whenever
that is changed you generate headers. Then you add a dependent target which
runs moc. And then you let your actual target depend on that one?
And the reason is that you can't know until build
time what files you have to run moc on. (Now as a mental exersize,
imagine having multiple server descriptions in a single json file...)
That is not an issue, no? You have one file that you need your targets depend
on - the JSON file. If that one changes, the dependent targets must be
rebuild.
It's possible to do in pure make by calling the code generator and
creating a sub make file and then calling make on that. But you can't do
that in any way that supports hitting the build button once in QtCreator.
I finally solved this by convincing the customer it was sufficient to
have a qobject base class for the remote calls and live without the meta
object descriptions on those. And yes, this is a very specific case. But
it's an example of something that neither cmake nor qmake can do because
they have a makefile generating step.
Maybe this seems more important to me than others because I'm a huge fan
of custom built code generators for stuff like database connections and
client-server communications.
I'm not yet convinced.
Ok, go try it. Create a simple python or perl script that reads a file.
The file just has a single number N inside it. And based on N the script
outputs those files:
server.h
method1.h
method2.h
...
methodN.h
Inside method1.h you write this:
#include
class Method1 : public QObject {
Q_OBJECT
};
server.h has this:
#include "method1.h"
...
#include "methodN.h"
class Server {
public:
Method1* call1() { return new Method1; }
...
MethodN* callN() { return new MethodN; }
};
In main.cpp you instantiate Server.
The only problem is that you have to run moc on each of the .h files.
Solution to the problem is only accepted if you can press build one
single time inside both Visual Studio and Qt Creator and it builds this
even when you modify the input file and the main.cpp.
I'm sure there are ways you can make the build call cmake or force a
build to fail and rebuild, and that's what you can currently do. And
those all feels annoying when you work on the project.
You asked why modifying the tree at build time could be necessary. This
is one of the (probably very few) examples of it.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016
Den 05-09-2016 kl. 20:49 skrev Milian Wolff: As an incredibly simple example, make is inherently limited in that it > cannot even represent a rule with multiple outputs (there are some > workarounds, but they are hacky and rather limited in how they can be > applied). And ninja is no magic bullet here either, because that still > represents a static build graph, whereas the content of Qbs' build graph > can actually change during the execution of the build. Can you give an example for why we should care? This may sound flame-baity, but I'm really truly interested. I simply don't care about my build system, as long as it gets the job done without too much hassle (and yes, that is the case for me personally with cmake), and fast, too (which is the case with ninja). See also below. I can answer that because I asked for this feature all the way back at QtCS in Bilbao. The context I was talking about was code generators. At the time I had built a code generator that created both the Qt and the PHP side of a client-server system. It had a single JSON file that described a server with the available remote methods on it. The output from the C++ code generator was a .h and .cpp file per method and a single .h and .cpp that described the server. So on qmake run time you can't know how many output files you have unless you force the user to run qmake every time you modify the JSON description. And to make the problem worse, the customer wanted each of the classes describing a remote call to be qobjects with a Q_OBJECT so a moc run is required. AFAIK this is impossible to do with both qmake and cmake. Not just hard, actually impossible. And the reason is that you can't know until build time what files you have to run moc on. (Now as a mental exersize, imagine having multiple server descriptions in a single json file...) It's possible to do in pure make by calling the code generator and creating a sub make file and then calling make on that. But you can't do that in any way that supports hitting the build button once in QtCreator. I finally solved this by convincing the customer it was sufficient to have a qobject base class for the remote calls and live without the meta object descriptions on those. And yes, this is a very specific case. But it's an example of something that neither cmake nor qmake can do because they have a makefile generating step. Maybe this seems more important to me than others because I'm a huge fan of custom built code generators for stuff like database connections and client-server communications. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Behavior of mapToGlobal function when application is not the one active.
Den 02-08-2016 kl. 14:22 skrev NIkolai Marchenko: A little bit of context: I am trying to organize getting interface positions/sizes out of an application via RPC interface. To do this I have inserted grpc server code into a GUI app and grpc client into another, testing application. Essentially, when the client app sends a signal, the main app should do button->mapToGlobal(QPoint(0,0,)) and return this via RPC. What happens in fact, is that unless I specifically press the "get coordinates" button on the main app, the coordinates I get are completely wrong. Scenario 1: mapToGlobal at the button press of the same app: correct coordinates Scenario 2: mapToGlobal at rpc signal from client app: completely wrong coordinates AND size, coordinates for buttons in the same layour are the same. What can this be? Please send this to the interest mailing list instead. This is not the appropriate list. And when you resent it, you have to send some code as well because the but will be in your code and we can't help with that unless we see it. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] Native event filter in QtService
Hi all, I'm copying this to devel, because it fits in a discussion a week or two ago. Den 24-06-2016 kl. 10:56 skrev Tony Rietwyk: qtservice_win.cpp around line 830 at your reference [1] installs its own nativeEventFilter - probably displacing yours. I suspect you'll need to merge the Qt filter into yours, and get rid of that install. That is impossible for commercial projects because the solutions are LGPL only. You can't copy LGPL code into your own code base unless you are using GPL or LGPL yourself. And that's why I copied this message to devel, because there was a discussion on whether to add solutions to Qt Core or not. And one of the arguments against is that people can just use the solutions as they are. This is one case, where apparently that's not (at least currently) possible. I can come up with a couple of workarounds for this, sure. But these are all brittle and may not work if the solutions code is changed. *From:*Interest [mailto:interest-bounces+tony=rightsoft.com...@qt-project.org] *On Behalf Of *Julius Bullinger *Sent:* Friday, 24 June 2016 5:25 PM *To:* inter...@qt-project.org Interest *Subject:* [Interest] Native event filter in QtService I’m trying to write a small (windows only) service based on QtService [1] listening for some USB device events. For this, I created a NativeDeviceEventFilterclass based on QAbstractNativeEventFilter. It works perfectly when used in a QCoreApplication. Now, when installing this event filter in my UpdaterServiceclass, it isn’t being called. I tried each of: application()->installNativeEventFilter(deviceEvent_); QCoreApplication::instance()->installNativeEventFilter(deviceEvent_); QAbstractEventDispatcher::instance()->installNativeEventFilter(deviceEvent_); both in the service’s constructor and start()method, as well as using a local instance of NativeDeviceEventFilter, but none of these worked. The event just isn’t registered at all. Has anyone ever done something like this? Or is there another way to receive native messages (MSG structs) in a QtService? Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtSingleApplication in Qt proper?
Den 17-06-2016 kl. 08:26 skrev Thiago Macieira: And, what about QtService from QtSolutions ? I don't know what that does. On Windows it implements the interface so you can register a Qt application as a service and the users can control from the standard windows services panel - starting, stopping, automatic startup etc. It also provides methods for controlling this from code. It works very well. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ?
Den 13-06-2016 kl. 12:16 skrev Denis Shienkov: QScopedPointer? Do you have real example? ;) Well, as Sean wrote it lacks the move, but if all you're after is to use it for a pointer in a class or make a local dynamically allocated var exception safe, then QScopedPointer is fine. It's limited in it's use, but that doesn't mean it's unusable. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ?
Den 12-06-2016 kl. 12:59 skrev Denis Shienkov: No, use of the C++11 Standard Library features is not permitted Lousy to hear it... How to do then RAII to avoid a leaks e.g. for Windows handles (HANDLE, HKEY, HDEVINFO and other stuff)? QScopedPointer? Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fixing QRect::width() / height()
Den 15-03-2016 kl. 14:07 skrev Marc Mutz:
Hi,
No, this is not about the +1.
QRect is internally represented as QPoint topLeft, bottomRight, which means it
can hold rectangles for which width() and height(), returning ints, may
overflow, e.g.
QRect{{INT_MIN, INT_MIN}, QPoint{0, 0}}
QRect{{INT_MIN, INT_MIN}, QPoint{INT_MAX, INT_MAX}}
While these may seem like pathological cases that never occur in practice, the
auto-test checks such rectangles, and if it didn't the next attacker would.
It is therefore important to provide a fix width() and height().
There are two options I can see:
qint64 width64() const;
unsigned int width??() const;
The first returns the result as a 64-bit quantitiy, preserving the negative
widths of unnormalised rectangles, and never overflowing, but possibly
penalises 32-bit platforms without 64-bit register support.
The second still overflows for left() == INT_MIN, right() == INT_MAX, because
of the +1 (don't highjack this thread, you have been warned! :), would only
work on normalized rects, but doesn't require a 64-bit quantitiy.
Opinions on which one to choose? One? The other? Both?
There is another option that doesn't mean a change of signature: Bound
the result. So if the real result is > INT_MAX, return INT_MAX. Same for
INT_MIN.
Yes, it's not the correct result, but I completely agree with you that
it's a theoretical problem. As long as it's documented in the width() I
really don't see the problem with this solution.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]
Den 27-02-2016 kl. 20:07 skrev Thiago Macieira: On sábado, 27 de fevereiro de 2016 12:56:11 PST Olivier Goffart wrote: First of all, note that you're asking that a) installing generated code b) including such generated code from your public headers Not necessarily installed: - The feature might be used only for application code or implementation without having the need of installing them. - The build system can be adapted such that moc is run on headers containing object template from a library, and put these generated code in the build directory. Ok, this is an interesting solution. I don't like it, but it's workable. If you want to use template QObjects, you need to tell your buildsystem where the header files declaring such a QObject are (/usr/include/...) and which template expansion of it you want. Each one. Then moc gets run for creating the meta object for those classes, which will need to be Q_DECL_EXPORT'ed from your module. Well, you could give the include path to moc and let it search? If the compiler can find the proper file, moc can too. In qmake it would be possible to add something like EXTERNAL_TEMPLATE_HEADERS += foobar.h And magic stuff happens... It sounds like this is something that would require qmake, moc and qdoc support, not just moc-ng. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about QCoreApplicationData::*_libpaths
Den 21-01-2016 kl. 14:15 skrev Milian Wolff: On Donnerstag, 21. Januar 2016 05:44:05 CET Kevin Kofler wrote: I consider reserve() to be a technical detail and a micro-optimization I really should not have to bother with in 99+% of the cases. That's how it should be. This is very wrong. In my experience with profiling applications, the most hotspots can be fixed by adding reserve to loops where the size is known or can be guessed. This has a tremendous effect on runtime speed, also for QVector using realloc And this is how it is. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] What kind of airplane we want to build?
Den 20-01-2016 kl. 15:12 skrev Marc Mutz: On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote: I think it would be productive for the discussion to build story of what we want to do. A story of the big picture. Maybe as a first step we can show how we tackle problems with Qt 5 and what are the proposed technologies in the future C++ standard. For me, Qt always was "the C++ standard library that C++ lacked". Ever since Qt 3, it also integrated pretty well with the rest of the standard library. That was easy, because pretty much the only thing that the standard library had and Qt didn't were the algorithms, and Qt and the STL algorithms integrated well. And there were conversion functions for pretty much everything to/from std. We even deprecated our algorithms when we started requiring full C++98 support in 5.0. We used to roll our own atomics, but dropped them in 5.7 when we required partial C++11 support. We rolled our own foreach, and now it looks like we're dropping it in favour of range-for. I would like that trend to continue. The likely next candidates are threads, futures and locks. It sounds like everyone completely agrees on this. But that doesn't mean it has to happen for every single class that might be implemented in STL. Now that C++ punches out a new standard every three years, I would change that into "Qt is the part of the C++ standard library that C++ sill lacks". I would like Qt to continue to integrate well with the standard library and phase out its own solutions as the standard library catches up. We have been doing that in the past. It's just as C++ standardisation accelerates, so will the need to phase out Qt features that got superseded. I agree with this, but there might be problems with the release cycle of Qt here. It's impossible to keep backwards compatibility while we switch to new C++ versions. So either the Qt major releases will start happening more often, or there are features that will just have to wait. Thiagos list of things he has already implemented for Qt 6 is a good example of this. I perceive, however, that for many people, Qt is what makes them forget they're working on C++, a language they would not otherwise poke at with a long stick. They probably also cannot tolerate writing std::sort(v.begin(), v.end()) instead of qSort(v). But Qt is available in D and Python, too, so ... why do they use C++ if they so hate it? Why do you think people hate C++? I love C++ but I hate the string classes. I like some part of the std containers, I don't like their API. In the same category of argument, I love Qt, but I hate that we don't use exceptions. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about QCoreApplicationData::*_libpaths
Den 19-01-2016 kl. 15:00 skrev Marc Mutz: In Qt 6: 1. ... dropping CoW ... I'm against any change that does this. I know you hate and loathe them. I don't. I think this alone makes Qt containers worth while. And it doesn't matter what arguments you give, I already know and understand them. The pros of CoW to me outweigh the cons. We disagree on this, and that's perfectly okay. However, there are also things in this argument where I agree with you. I do think there are more containers in Qt than necessary. It's not necessarily the case that Qt needs to have all types of lists, for example. And I would like to see Qt offer the use of std:: containers in the API. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about QCoreApplicationData::*_libpaths
Den 15-01-2016 kl. 12:20 skrev Marc Mutz: Consider QVector: it has been Qt-ifed by both adding (technically) useless duplicate Qt-ish API, CoW, and a Qt-specific type classification scheme plus corresponding optimisations that make it very hard to argue for std::vector use instead. The Qt community had two decades where they could have influenced the direction std::vector would take so it could allow the same optimisations that QVector has, but the time and energy was instead put into re-writing the containers for every major release (yes, for Qt 5, too, and Thiago's Qt 6 QVector again looks much different from the Qt 5 one). The CoW makes QVector slow and increase code size, leads to hidden detaches that not even Qt experts regularly avoid in their daily work, and doesn't even work properly because you can take iterators into a QVector and, after copying the vector, change both copies through the iterator into the first. That is a conscious trade-off because making the container unsharable, as it must become once it hands out iterators, would make CoW fail to take effect _all the time_. But it leads to careless copying of QVectors that also doesn't really help with porting to std::vector. All the while - and I don't believe I'm saying this - std::vector *blazes the trail* with move semantics, emplace_back and stateful allocators (making QVarLengthArray all but useless). Does QVector use move semantics? No. Does QVector have emplace_back? No. Does QVector have an allocator, even one that, citing Alexandrescu, actually deals with allocation? No. Does QVector, even with Q_PRIMITIVE_TYPE payloads, expand to less code as std::vector? No: https://codereview.qt-project.org/145587 (comment from 01-14 11:21). Does QVector have a debug mode comparable to that of std::vector implementations? Nope. We have seen this rant from you several times before. The way I see it is that I use QVector when I want the implicit sharing, std::vector when I need speed. Maybe I have a different focus, but I just don't see the need for raw speed very often. On embedded applications I'm very sensitive to it, of course. But on the Windows desktop, I have yet to see an application where the choice of QVector or std::vector makes any kind of difference to the user. Sure, they are there. And there are areas in the model of an application where we should consider speed always. But for the vast majority of the lines of code I write, it makes no difference at all. If it doesn't make a codewise difference, then obviously a faster framework class is better. However, my customers have developers that are a lot less experienced than us. And it's my observation that using the Qt classes over the std classes lead to fewer mistakes and faster applications. It seems much easier to shoot yourself in the foot with std. I don't know why this is, it's only what I observe when I look at code written by others. This is why we need to stop duplicating std API. It's not Qt's core competency to meddle with things we only have a half-interest in. It's fun to write QOptional. Until it isn't anymore. And then the (Qt) world needs to live with the poor-man's std::optional for the next few decades. Now this is where we completely agree, although probably for slightly different reasons. I would not mind removing some (maybe even most) of the Qt containers for Qt 6 or 7 and forcing people to learn the use std instead. Hash, map, set and linked list would be the first I'd get rid of. And I don't care for the binary compatibility with different compilers argument - just stop shipping binary builds on linux and let people with other compilers on Windows and Mac compile themselves. But there will be reasons why some of them should be here. Having CoW containers is very useful sometimes. And this is only about the containers, I would never support anyone trying to use the horrible abominations that are std::string or std::wstring. Or the std streams *shudder*. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
Den 29-12-2015 kl. 18:47 skrev Matthew Woehlke: On 2015-12-26 20:17, Kevin Kofler wrote: And what is hard to parse for humans? The "char* p,q" "issue"? That's a formatting bug then, this ought to be written "char *p, q", which makes it very clear what is going on. That's... debatable. Personally, I dislike combining names and type information. And it doesn't always work out so nicely. What, for example, is the type of 'q' here?: char const* const *p, q; Explicit pointer/reference types and multiple declarations should simply not appear in the same statement¹. Period. This is getting quite off-topic, even for this thread. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Sending key events on Qt 5.5.0
That's completely besides the point I was making. I'm saying you shouldn't abuse the shortcuts as a message system (which is exactly what you do). If you want to send events, find another way. Bo. Den 17-09-2015 kl. 12:16 skrev christian.paffhau...@ehrhardt-partner.com: > > Hi Bo Thorsen, > > thanks for that. But it's a little bit more complicated. There is no > PushButton. We record all keyboard input events, buffer them in a own key > event class, which is derived by QKeyEvent, and accepting the original > events. So the original key event will never reach the action. If our > internal states say ready for keyboard input, we sending our key event via > QApplication::sendEvent. In this part of the code, i know nothing about a > action somewhere. I only know about incoming key events and resending them. > > The PushButton was only a demonstrator :-) > > Regards > Christian > > Mit freundlichen Grüßen / Best regards > > Ehrhardt + Partner GmbH & Co. KG > > i.A. Christian Paffhausen > Software Developer > > Development Group User Interfaces > > ** > Ehrhardt + Partner GmbH & Co. KG > Software - Systeme für Warehouse - Logistik > Alte Roemerstrasse 3 > D-56154 Boppard-Buchholz > Handelsregister Koblenz HRA 4605 > GF Marco Ehrhardt > Tel. : (+49) 67 42 / 87 27 0 > Fax : (+49) 67 42 / 87 27 50 > E-Mail: i...@ehrhardt-partner.com > Internet: www.ehrhardt-partner.com > > (Embedded image moved to file: pic13977.jpg) > > > > > From: Bo Thorsen <b...@vikingsoft.eu> > To: development@qt-project.org > Date: 17.09.2015 11:37 > Subject: Re: [Development] Sending key events on Qt 5.5.0 > Sent by: development-bounces > +christian.paffhausen=ehrhardt-partner@qt-project.org > > > > Den 17-09-2015 kl. 11:21 skrev christian.paffhau...@ehrhardt-partner.com: >> i have a problem with manually sending key events and shortcuts on Qt >> 5.5.0. >> >> In our application, we have a QAction with a F5 shortcut in a toolbar. > When >> i press the toolbutton everything works fine. When i press the F5 key on > my >> keyboard too. >> But when i press a pushbutton, where the connected slot generate a >> QKeyEvent and send this event via QApplication::sendEvent nothing will >> happen. >> With Qt 5.4.1 it works, but with 5.5.0 not. >> >> I have attached a small example app, which describes my problem. >> >> Is this problem already known? Have you a patch or work around for me? > > Hi Christian, > > The solution: tAction->trigger() > > I'm not trying to be cute or anything. This is what you should do. > Abusing the short cut system to send messages between widgets is a bad > idea. > > That said, I also think you should report this as a bug. The behaviour > change between 5.4 and 5.5 is bad. But I've seen 5.5 behaviour change > bug reports closed as invalid for weird reasons, so you might not have > any luck. > > I hope this helps. > > Bo Thorsen, > Director, Viking Software. > > -- > Viking Software > Qt and C++ developers for hire > http://www.vikingsoft.eu > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Sending key events on Qt 5.5.0
Den 17-09-2015 kl. 11:21 skrev christian.paffhau...@ehrhardt-partner.com: > i have a problem with manually sending key events and shortcuts on Qt > 5.5.0. > > In our application, we have a QAction with a F5 shortcut in a toolbar. When > i press the toolbutton everything works fine. When i press the F5 key on my > keyboard too. > But when i press a pushbutton, where the connected slot generate a > QKeyEvent and send this event via QApplication::sendEvent nothing will > happen. > With Qt 5.4.1 it works, but with 5.5.0 not. > > I have attached a small example app, which describes my problem. > > Is this problem already known? Have you a patch or work around for me? Hi Christian, The solution: tAction->trigger() I'm not trying to be cute or anything. This is what you should do. Abusing the short cut system to send messages between widgets is a bad idea. That said, I also think you should report this as a bug. The behaviour change between 5.4 and 5.5 is bad. But I've seen 5.5 behaviour change bug reports closed as invalid for weird reasons, so you might not have any luck. I hope this helps. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
Den 03-07-2015 kl. 07:09 skrev Ansel Sermersheim: On 7/2/15 2:23 PM, Milian Wolff wrote: On Thursday 02 July 2015 23:00:43 Bernhard wrote: Unfortunately adding signals of the template’s type is exactly what I would have needed several times. In that case there is no clean solution. I once added QVariant based signals as a workaround but that was ridiculous. In modern times having powerful C++ generic programming features it is a shame that QObject doesn’t support this. IMHO this is one of the features (like C++11) that need to be introduced in Qt as fast as possible if it should not appear old-fashioned soon. You can use C++11 (and even C++14 and newer) with Qt just fine. Heck, it even uses a lot of C++11 features internally. So what exactly do you mean by the above? Yes, you can use C++11 in your application. Our viewpoint is that Qt developers should be able to use C++11 internally in the project. They are slated to allow most of C++11 like decltype, rvalue references, and lambdas in 2016. However, things like constexpr will still not be allowed. More importantly, there are many features of C++11 you cannot use in your application like smart pointers. Ok, you can use them, but you cannot use them to interact with Qt. To a modern C++ programmer this comes across as a significant limitation. This answer is going to be one big IMHO. Anything that stops people from throwing shared pointers all over the code is A Good Thing. As someone once said: Shared pointers are a solution in search of a problem. Scoped pointers are fine, but shared pointers indicate a lack of handling of responsibility and ownership, which indicates bad design. For you to use this as a reason for forking Qt is a very bad indication. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] -Winconsistent-missing-override warning with latest Xcode and Qt 5.5
Den 01-07-2015 kl. 18:36 skrev Edward Sutton: Is there a work-around I could use in my Qt project file? Upgrade to 5.5.1. It's already fixed. The problem was not deemed important enough to affect the 5.5.0 release. My Chicago based sales rep told me that ( somewhere buried in my license fine print ) I could not release software using unreleased versions of Qt Enterprise. Your boss should tell you not to release software based on a 2 day old x.y.0 release. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] date/time adjust for (auto) testing
Den 03-06-2015 kl. 08:38 skrev André Somers: We have applications that use the current date and time at places spread around the code. For normal operations, that works very nicely. However, we find that for (auto) testing, it would be very convenient if we could trick the application into believing it is some other date/time, so that we can test if certain behaviours work the way we would like to automatically. Currently, these tests take a lot of time because we actually need to manually adjust the system date and time, do some stuff, then adjust again, etc. It would be really confortable if there was some control to set a date/time offset (so the time keeps running) or a fixed date/time to be returned from currentDate(), currentTime() or currentDateTime() respectively. I guess access to such a thing does not belong in the main Qt classes, but is really a testing tool, so perhaps it could find refuge in QtTest somewhere. Would a contribution adding such a thing stand any chance of being accepted, or would this be considered out of scope or even unwanted? An alternative might be to hook the windows kernel API, but that may be much tricker to get right and may have unforseen consequences for the code injected by Squish doing the actual testing. To me it sounds like you need to create your own static current...() functions so you can control the output for unit tests instead. Or even better: Modify the tests so you can adapt the compares to something that handles the current time and date. Date is simple enough (yes, it can fail if you run the test at exactly 23.59.59.9). For the time you just allow for a couple of seconds difference. I *really* don't like the idea of creating a system to add offsets to the QDateTime::currentDateTime (or friends). Then we can't depend on the output being correct, which means any unit tests you write using it are useless. If you really want to modify the output of current...() then you might consider preloading a library over Qt that does it for you. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] date/time adjust for (auto) testing
Den 03-06-2015 kl. 12:26 skrev André Somers: If you really want to modify the output of current...() then you might consider preloading a library over Qt that does it for you. I am considering that option as well, but that would require me to hook into the windows kernel calls. Like I said, that approach is much trickier and have a bigger chance of having side effects on for instance Squish. No, I meant preloading over the QDateTime::currentDateTime function. You can load a dll that replaces specific functions in another dll, which means you can replace any Qt method you want to. Or at least that's possible in theory. I've never actually done it on windows. I can perfectly understand you don't want to mess with windows kernel hooks. But doing dll injection on Qt itself might be okay for running your unit tests. On linux you can do this with LD_PRELOAD as well. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of Qt Quick 1 in Qt 5
Den 08-05-2015 kl. 14:44 skrev André Somers: Frederik Gladhorn schreef op 8-5-2015 om 14:39: Hi, I think the dust has settled quite a bit and the declarative module is becoming better by the day. We have seen it evolve and the new Java Script engine is running smoothly (and actively worked on, sadly it will have one known crasher in the 5.5 beta release which has been fixed in the mean time, so it should be good for everyone with the 5.5 RC). One question is if there is any reason to maintain Qt Quick 1 in the future. It adds burden on maintenance, needs to be patched regularly to move with changes in qtbase etc. Since KDE moved over the Plasma desktop to Qt Quick 2 (on which I'm writing this email), I feel confident that the time has come to move everyone over. For the no opengl acceleration use case, we provide the Qt Quick 2D Renderer as backend. (https://blog.qt.io/blog/2015/01/22/introducing-the-qt-quick-2d-renderer/) In short, is there any reason not to remove Qt Quick 1 from Qt 5.6? Yes, there are reasons. Qt Quick 1 is the entrancepoint to moving your Qt 4 Application to Qt 5. In our case, we are using Quick 1 exactly because it uses QPainter based rendering and not openGL. We are rendering the scenes on a printer. Using Quick 1, that is easy. Using Quick 2, that is basicaly not doable without either reimplementing the elements you want to render or doing other major work. You are aware of http://doc.qt.io/qt-5/qquickpainteditem.html, right? This makes it pretty trivial to port painter based items to QtQ2. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] Call for Papers to Qt World Summit now open
Den 05-05-2015 kl. 09:24 skrev Kojo Tero: Hello! The call for papers to the Qt World Summit has been opened. We welcome you to share your insight, experience and inspiration at our 12th annual Qt event. For details on the themes and instructions for submitting your abstracts, please see this blog post: http://blog.qt.io/blog/2015/04/30/experts-wanted-call-for-papers-qt-world-summit-2015/ The deadline for submission is missing, isn't it? Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QQmlEngine and ObjectOwnership
On 04/28/2015 12:08 PM, Massimo Callegari wrote: Hi everyone, I want to share my experience with the garbage collection of registered classes through qmlRegisterType. I got crazy to understand why my application was randomly crashing and I hope this will help others in the future. Basically if you want to expose a C++ class in the QML world, you do something like: qmlRegisterTypeMyClass(com.myapp.classes, 1, 0, MyClass); Then you can use the class methods exposed with Q_PROPERTY in QML like this: MyClass.myProperty The thing is that when dealing with class pointers, the QML engine performs garbage collection of the exposed classes when it no longer needs them. If your classes are created in C++ (new MyClass()) at some point in the C++ code, you will find that the class has been destroyed by QML !! This causes a bunch of segFaults like there is no tomorrow. So, after getting crazy to discover this, I discovered also that there is a method of QQmlEngine to assign the ownership of a class: QQmlEngine::setObjectOwnership(myNewClass, QQmlEngine::CppOwnership); After adding this simple line after a myNewClass = new MyClass(), everything started to working properly. Note that in my application, classes created in C++ exist as long as the application lives. Now, I found pretty counter-intuitive that a class created in C++ is actually owned by QML ( QQmlEngine::JavaScriptOwnership) I believe the default ownership should be CppOwnership if the class is created in C++ and then, in case, the developer can do the other way around, letting QML to handle the destruction of QObjects. Hi Massimo, No, the default is correct. When you expose types to the QML engine, it will construct and destruct objects of your types as it wants to. If you want to have objects that are not controlled by the engine, you can either use qmlRegisterUncreatableType or expose object as context properties with viewer-rootContext()-setContextProperty(). The uncreatable types are useful if you have an object that returns an object of this type. Remember to set the parent of those objects. The fix you found is actually the proper way to do this, if you want to create QML objects and control the deletion of them. This is not normally what you would do, so it should not be the default. In the area where you are here - dynamic creation of QML objects - there be mighty dragons. Careful where you go with this. It is much easier to avoid this area completely by using Loader objects and registering global objects to the contexts. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Marking BB10 unsupported
Hi Vladimir, Den 24-03-2015 kl. 10:23 skrev Vladimir Minenko: On 24/03/15 09:04, Blasche Alexander wrote: The BB10 code in Qt is not just the platform plugin. Does this statement apply to all other BB10 code throughout other Qt modules? Following this question from Alex, and actually asking more Rafael. What do you mean exactly with mark the BlackBerry 10 platform unsupported? Which problem do you like to solve? To mind comes sensors, qtlocation, bluetooth, nfc and maybe multimedia. On top of this, the current implementation of QPA for BB10 is very much interlinked with the QNX one, it is basically almost the same. While clarifying which problem will mark the BlackBerry 10 platform unsupported actually solve, I just want to warn that making actual changes in code in that respect will result in quite some work. I'm not sure if somebody in the project has that much time for this. And just out of curiosity, how do I distinguish QNX from BB10.The line is often very blurry. Indeed. It is just as easy as on other platforms which have used a core OS and have added middleware and apps on top. Do you know the way how to distinguish Linux from Andriod which runs on top of it? Generally, there are defines set by configure which let you check you you run on pure QNX or on BB10. I could be wrong in this, so please correct if there are mistakes. When BB10 is unsupported, if a fix for QNX breaks BB10, that's acceptable (undesirable, of course, BB10 might come back). Things should work on QNX. Whether or not it works on BB10 is not important. Bugs for BB10 are basically irrelevant, QNX bugs are not. There will be no active development on BB, QNX will be kept up to date. I don't think this makes much of a difference for QNX, if any. One of my customers use the on screen BB keyboard on QNX, and this might have an impact. But other than weird stuff like this, I don't think you have to worry. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
Den 18-03-2015 kl. 08:31 skrev Knoll Lars: On 18/03/15 07:44, Bo Thorsen b...@vikingsoft.eu wrote: Den 17-03-2015 kl. 23:45 skrev Thiago Macieira: On Tuesday 17 March 2015 17:14:38 Jan Kundrát wrote: On Tuesday, 3 February 2015 08:33:46 CET, Knoll Lars wrote: * Qt WebKit While I understand the reasons on why you want to remove this one, I think that this goes against the promise of compatibility at [1]: Qt essentials define the foundation of Qt on all platforms. They are available on all supported development platforms and on the tested target platforms. They will remain source and binary compatible during Qt 5. Both Qt WebKit and Qt WebKit Widgets are listed under Essentials. QtScript and QtDeclarative are listed as Addons, and could probably go. Yes, they are listed under Essentials, and we’ll need to move them over to add-ons. Unfortunately, we rely on a lot of 3rd party code (ie. WebKit) with the module, and as you probably know there were major changes in the landscape happening there when Google decided to for the whole thing and go their own way. Unfortunately this simply made it impossible for us to continue with Qt WebKit as before. We had to make some hard decisions, and the result was to focus on the new Webengine module, as we didn’t see a way to continue to support WebKit properly. You're of course free to do whatever you want to do -- it's just that the project has promised that this won't happen. We promised not to break source or binary compatibility. Where are we doing that? Removing classes is as binary incompatible as you can possibly make it. Deprecating an API is different from removing it. Deprecating is about asking people not to use this for new code/projects anymore. Of course, but you said that it will be removed in 5.6. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
Den 17-03-2015 kl. 23:45 skrev Thiago Macieira: On Tuesday 17 March 2015 17:14:38 Jan Kundrát wrote: On Tuesday, 3 February 2015 08:33:46 CET, Knoll Lars wrote: * Qt WebKit While I understand the reasons on why you want to remove this one, I think that this goes against the promise of compatibility at [1]: Qt essentials define the foundation of Qt on all platforms. They are available on all supported development platforms and on the tested target platforms. They will remain source and binary compatible during Qt 5. Both Qt WebKit and Qt WebKit Widgets are listed under Essentials. QtScript and QtDeclarative are listed as Addons, and could probably go. You're of course free to do whatever you want to do -- it's just that the project has promised that this won't happen. We promised not to break source or binary compatibility. Where are we doing that? Removing classes is as binary incompatible as you can possibly make it. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Den 20-02-2015 kl. 12:32 skrev Olivier Goffart: On Friday 20 February 2015 11:15:32 BogDan wrote: I fully agree with you, but, sadly, I think it will not be possible in 5.x. We started supporting C++98 during the course of Qt 4.x. We dropped MSVC 6, in Qt 4.5 (despite there was still people using it) and were able to finally use member template functions for example and deprecate qObjectFind and such. I don't see why we could not force C++11 during Qt 5.x lifetime. Remember that Qt 6 is in the very far future if it is going to ever exist. Qt 5 is there to stay a long time. At some point we are going to drop MSVC 2008 and GCC 4.4 The question is when. And to answer this question we can use the facts such as how many people are still needing it. Is supporting those worth the burden. Since we're talking about lambdas, it's MSVC 2010 as well. I don't know what the status of lambdas is in MSVC 2012, since almost no one seems to use it. 2013 is the first fairly decent C++11 compiler. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 02/19/2015 09:41 PM, Matthew Woehlke wrote:
On 2015-02-19 15:21, Marc Mutz wrote:
On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
more than 400 lambdas in Creator's source
Sounds like lambdas are overused (as any new language feature is overused
before it's fully understood by the resp. language community).
Maybe, maybe not.
I'm not sure I've even *written* 400 lambdas yet :-), but I find myself
using them most often in QObject::connect. Basically, a lambda saves
writing a protected (or worse, *private*) slot by allowing the relevant
code to be written inline. These are rarely more than a few lines long,
and it's not unusual for them to be one-liners, e.g.:
connect(d-UI.scrollBar, QAbstractSlider::valueChanged,
[d](int value){ d-scrollTo(value); });
The above is basically a private slot that's *actually private*. I've
also had cases of needing to connect a signal to a slot where the slot
needs to be called with additional (constant) arguments; these tend to
look like the above also.
This is also how I tend to use lambdas, and I agree they are great.
Especially for network requests, they are so much better than the old
style code.
But this is an implementation convenience only. You can't convince me to
drop VS2010 to be able to use them internally inside Qt. Or 2008 for Win
CE or old gcc for blackberry or one of all the other answers that have
been given in those threads over the last couple of weeks.
Andrés question about how this would change the API is a lot more
interesting. I so far haven't seen a single case where someone has
described how access to lambdas might improve the API. If they are
there, I'd love to see them, because maybe this would teach me something
I haven't figured out yet.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] JSON 64 bit int
Hi guys,
ATM QJsonValue doesn't have a way to read a 64 bit integer or unsigned
integers. The standards doesn't seem to limit the contents of an int.
And I know of several projects that use this.
{i:1e33} gives a 0 if I convert the number to int (which is fair
enough). If I convert to variant, it gives me a double.
I would like to have some more conversion available. uint, qint64 and
quint64 would be great. It sucks that I have to find the place in the
original string and parse it myself.
Would patches for this be accepted or is there a reason those aren't
added yet?
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
Den 10-02-2015 kl. 23:17 skrev Allan Sandfeld Jensen: On Tuesday 10 February 2015, Oswald Buddenhagen wrote: On Wed, Feb 11, 2015 at 12:37:41AM +0400, Konstantin Ritt wrote: Yes, that would be an ideal solution. Unfortunately, that would also break a LOT of existing code. i was thinking of making it explicit with a smooth migration path - add QUtf8String (basically QByteArray, but don't permit implicit conversion to avoid encoding mistakes) and QUcs4String (and QUtf16String as an alias for current QString - for all the windows function calls). the main effort would be adding respective overloads to all our api. then deprecate QString, and prune it in qt6. then maybe re-add it as an alias for utf8string a few minor versions down. does that sound feasible? Maybe with C++11 we don't need QString that much anymore. Use std::string with UTF8 and std::u32string for UCS4. This would make me very unhappy. I'm doing a customer project right now that uses std::string all over the place and there is real pain involved in this. It's an almost empty layer over char* and brings none of the features of QString. Of all the failures of the C++ standards committee, std::string is the worst. Any string class has to be unicode. What it uses internally is an implementation detail (which is what started this thread). It's fine to have a pure ascii string type as well, but there are so few cases left in real world applications where this is useful. What QString internally uses is a pure optimization question, and I'll leave that to others. But whatever is decided, I want to be sure it keeps some of the things QString offers: 1) Unicode! Don't assume the user remembers to use utf8. qlabel-setText(stdString) *will* fail. Leaving decisions on encoding to users is a bad idea. 2) length() returns the number of chars I see on the screen, not a random implementation detail of the chosen encoding. 3) at(int) and [] gives the unicode char, not a random encoding char. std::string fails at those completely basic requirement, which is why you will never see me use it, unless some customer API demands it or I'm in one of those exceptional cases where there is sure to be ascii only in the strings. Another note: Latin1 is the worst idea for i18n ever invented, and it's by now useless, irrelevant and only a source for bugs once you start to truly support i18n outside of USA and Western Europe. I would be one step closer to total happiness if C++17 and Qt7 makes this encoding completely unsupported. I know this I've made the statements here a bit harsh, but I see the same kinds of problems again and again in customer code, when they chose to use std::string all over the place. They give the same arguments I've seen here - optimized, faster, etc - and add a few like easier to switch away from Qt, backend is std/boost only and no Qt allowed and so on. And they pay for it in development time, bugfixing and angry users. Sure, QString isn't optimized for some cases. But I'll take a less optimized class any day over something that brings heaps of bugs. Then I have time to focus on optimizing the serious things instead of fixing bugs. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
Den 10-02-2015 kl. 23:17 skrev Thiago Macieira: My current thinking is: 1) modernise our headers with macros, now 2) allow people to use Q_NULLPTR where it helps with readability 3) disallow replacing of zeroes with Q_NULLPTR except as required by rules #1 or #2 Two examples: a)void *ptr = 0; b)str.toInt(0, 0); In (a), use of Q_NULLPTR would make the code noisier, so don't use it. In (b), the first 0 could be replaced with Q_NULLPTR to indicate that yes we know it's a pointer, as opposed to an integer. I think this is a perfect set of rules and sums up most of the discussion nicely. +1. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
Den 11-02-2015 kl. 11:58 skrev Giuseppe D'Angelo:
On 11 February 2015 at 11:40, Bo Thorsen b...@vikingsoft.eu wrote:
{i:1e33} gives a 0 if I convert the number to int (which is fair
enough). If I convert to variant, it gives me a double.
Because it _is_ a double, given that JSON is a subset of Javascript,
and numbers in Javascript are IEEE754 64bit floating point numbers.
(And it's also a strict subset, given that JSON omits the handling of
+/- infinity and NaN...). I'm not too happy with the fact that
QJsonValue has int in its API...
I know this is the history of JSON, but it's no longer the reality. The
use of JSON are all over the place now and they are not restricting
themselves to Javascript numbers. You can find requests in the bug
tracker for what I just asked about - JSON is no longer just about
Javascript.
We have one of two choices here: Follow a restrictive schema that is no
longer a description of how it's used. Or follow what users outside of
the Javascript world would like to have.
It's so easy to say we just follow the standard. But I have two current
projects where my customers say they send me a 64 bit database ID in a
JSON value. Converting those through a double might work, but can you
guarantee this? Yes, they do something that's wrong. But this is how I
see JSON used these days. Restricting the JSON values to a set of types
from one of the simplest typesystems found in programming languages is
just silly IMHO.
If I say to my customers they have to send me another language because
the Qt JSON library can't read 64 bit unsigned integers they say Qt
sucks, switch to another JSON library.. We can't win here.
Well, there's actually a third option: Give me the original QByteArray
that the value comes from. If there was a way to get this, I can convert
the value any way I want. Something like QByteArray bytes() const
would allow for any kind of parsing on our side. I'd be fine with this
as a workaround that would allow us to stay with the spec.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
Den 11-02-2015 kl. 13:27 skrev Giuseppe D'Angelo:
On 11 February 2015 at 12:12, Bo Thorsen b...@vikingsoft.eu wrote:
It's so easy to say we just follow the standard. But I have two current
projects where my customers say they send me a 64 bit database ID in a JSON
value. Converting those through a double might work, but can you guarantee
this?
No, because IEEE754 64-bit floating point numbers can't represent all
64 bit integers... the right solution, from a JSON point of view, is
not sending a number but a string.
Exactly, that's why I wrote might. You don't know if the number you
get is correct or not.
But we can't get the string from {i:1}. You get an empty string if you
do toString on the i value.
And that's the problem. People have web APIs that return uint64 as a
number and I need to get that number. ATM the only way is to read it
from the full QByteArray. If the toString would never fail and give me
the contents or I can get the bytes from it or add the extra type
reading functions - all three would work. The current meagre API is
pretty much the only way that doesn't.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
. That's a large blob, but the most important instances of it are: a. Not marking types as movable or primitive. We might actually want to have a policy to mark complex types explicitly as complex, to allow easier fixing of missing declarations. The rule here should be that every new class or struct that may at some point be held in a container must have a q_declare_typeinfo. Rationale: it's impossible to add them after release, since changing the typeinfo changes the memory layout of QList, making the change BIC. b. Using QLists when they are not optimally efficient. For a QList to be optimally efficient, the type T must be movable (or primitive) and sizeof T == sizeof (void*) (yes, different on 32 and 64-bit platforms!). For a QList to be acceptable (actually, it's not, but it's at least not horribly inefficient), replace == sizeof(void*) with = sizeof(void*). The rule should be that you need to accompany any use of QList that isn't already mandated by existing APIs (QListQVariant, say), by a static_assert that QList is optimally efficient. There are patches in the pipeline to make this easier than checking QTypeInfo yourself. Of course, when QList is not efficient, you should use a QVector instead. c. Using QMap. As Alex Stepanov put it: every use of a map should be discussed in a face-to-face meeting with your manager. Since we don't have that, I'd change this to: Everyone wishing to use a QMap should implement one before using it for the first time. Then you'd see what you inflict on the world. In the vast majority of cases, a sorted vector is much faster, due to locality-of-reference. A RB-tree is optimized for wildly mixing insertions, lookups, and removals. When you can batch updates and separate them from lookups, time-wise, then a sorted vector is usually preferrable. d. Algorithmic complexity. Avoid O(n²) like the plague. Anthing worse than that should get a big fat comment saying why it's necessary (like: this optimisation algorithm is equivalent to the knapsack problem, so I need to use this exponential algorithm, because a) we need the global optimum, not a local one, and b) the set is always less than four elements. I could go on and on with this. Like using a set for de-duplication, then converting to a list and sorting that (because, surprise, QSet is std::unordered_set), but there's really no substitute to understanding what you're doing and no set of rules, however large, will give you that. Using std algorithms would, though, as far as they go. I'm sorry, this has become so much longer than planned... Thanks for reading up to here. May your code be the better for it, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] qmake bug 17533
I have been working on trying to fix https://bugreports.qt.io/browse/QTBUG-17533. The fix itself is really simple: Remove line 559 of qmake/generators/makefiledeps.cpp. But when I tried compiling Qt itself with the modified qmake, I got a compile error. The bug is that qmake doesn't set main.moc as a dependency in the makefile of the test case. The problem I hit in the Qt code was that there now was a different file that wasn't set as a dependency. Does anyone here know this code? It feels like an area where there could be dragons buried. So before I spend a lot of quality time with my debugger, trying to fix the new problem. The question I have right now is if it makes sense to write a more detailed and precise parser of C/C++ strings in the dependency generator. If none of you know the code or this specific area of it, I'll continue with the debugging and figure it out. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qmake bug 17533
On 02/09/2015 02:07 PM, Oswald Buddenhagen wrote: On Mon, Feb 09, 2015 at 01:34:55PM +0100, Bo Thorsen wrote: I have been working on trying to fix https://bugreports.qt.io/browse/QTBUG-17533. The fix itself is really simple: [...] riight ... Well, it is. But it showed other problems... :) So before I spend a lot of quality time with my debugger, trying to fix the new problem. The question I have right now is if it makes sense to write a more detailed and precise parser of C/C++ strings in the dependency generator. it may be that i replace that code wholesale in the next weeks. code already exists (since five years ...), but it wasn't developed in a very cooperative way, and nobody bothered upstreaming it into qmake so far. Ok, so how do you want me to proceed with this? I have decided to spend time on qmake. But if you replace the code, it's wasted effort. If you have a branch with your improvements, I can work with you on that branch instead. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Impossible to do review after a logon
I think the problem is on your side. I don't have any problems with it on Windows/Chrome. Bo. Den 08-02-2015 kl. 12:39 skrev Denis Shienkov: UPD2: This happens on Windows Firefox 35.0.1 only, though on Linux Rekonq this works fine. 2015-02-08 11:32 GMT+00:00 Denis Shienkov denis.shien...@gmail.com mailto:denis.shien...@gmail.com: UPD: Also I can go to my account settings on: * https://codereview.qt-project.org/#/settings/ also can view a goups: * https://codereview.qt-project.org/#/settings/group-memberships but others url's: * https://codereview.qt-project.org/#/settings/preferences * https://codereview.qt-project.org/#/settings/projects * https://codereview.qt-project.org/#/settings/contact * https://codereview.qt-project.org/#/settings/ssh-keys * https://codereview.qt-project.org/#/settings/http-password * https://codereview.qt-project.org/#/settings/web-identities * https://codereview.qt-project.org/#/settings/agreements are unavailable for me (I got same error as above). BR, Denis 08.02.2015 14:12, Denis Shienkov пишет: Hi all, After logon on https://codereview.qt-project.org/#/, and rtying to enter on any commit to @expand it, I got a following error: Working... Code Review - Error Server Unavailable 0 But if a try to do same without logon, then I can view content of any patch, to see any comments, and so on. What happens with codereview ? BR. Denis ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
Den 08-02-2015 kl. 21:25 skrev Olivier Goffart: On Sunday 08 February 2015 19:15:18 Giuseppe D'Angelo wrote: Il 08/02/2015 17:58, Thiago Macieira ha scritto: So we come back to this question again and again: if you can't upgrade the OS and upgrade the compiler, why do you want to upgrade Qt? Because people want to use the latest features / bugfixes for developing their product, and yet they need to target such platforms... If Qt 5.5 is LTS, some bugs fixes could be backported. As for the new feature, if they can cope with an old system and compiler, they can also cope with old Qt. Even if that implies re-inventing a few wheels. So the question is: If we were to drop MSVC2008, about how many companies or developers do you think will choose not to use Qt because of that instead of using it? Is there perhaps a lot of paying customer using it who would stop paying licenses? With a 5.5, LTS TQtC could have a reason for potential customers to start buying licenses. WinCE, MSVC2008, maybe a couple of others. If customers need this for a bugfixed Qt, buy the licenses. I think it would be perfect, if we could find a way to proceed that could support the business of TQtC. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
Den 08-02-2015 kl. 22:42 skrev André Pönitz:
On Sun, Feb 08, 2015 at 10:17:40PM +0100, Allan Sandfeld Jensen wrote:
What would be the point of macros if they always expanded? The entire point
and usefulness of these macros is that they expand to standard keywords when
those standard keywords exists.
What's the point of using a macro in circumstances where a portable, standard
conforming, safe-to-use, shorter-to-type, version _without_ using a macro
exists?
I.e. in case of a simple pointer initialization, why should one *ever* prefer
void something()
{
Foo *f = Q_NULLPTR;
...
}
over
void something()
{
Foo *f = 0;
...
}
?
For the sake of keeping this part of the discussion simple, I specifically
mean 'Q_NULLPTR, the macro', _not_ 'nullptr', and I specifically mean the
context of initializing a local pointer variable. So: Any advantage? Any
advantage outweighing the disadvantages?
For this simple example, there is absolutely no benefit. Not even if you
had replaced Q_NULLPTR with nullptr.
But you forget that it isn't about this simple case. It's about the
harder cases, which makes you want to compile your code with warnings
about 0 for pointers. And that's impossible if at least the Qt headers
are not clean for it.
Whether we should use Q_NULLPTR in the cpp files is more of our own choice.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
Den 04-02-2015 kl. 15:56 skrev Olivier Goffart: On Wednesday 04 February 2015 09:23:12 Knoll Lars wrote: On 04/02/15 10:20, Olivier Goffart oliv...@woboq.com wrote: Also, is it not time to decide which platform are we going to stop supporting in Qt 5.6? For example, if we were to decide to start using some of the C++11, we should drop MSVC 2008 which would allow us to already use things like auto and decltype. We could also drop gcc 4.4 which would let us lambda function. In principle I agree. The problem with 2008 is that this is currently the only compiler supporting Windows Embedded 7, so we can’t easily get rid of it. Dropping gcc 4.4 is afaik not a big problem. The question then is how relevant will Windows Embedded 7 be in 2016 when Qt 5.6 will be there. And if it is worth to limit ourselves because of it. Sounds to me like 5.5 will be a release that will be around for a while then. This could be the one where those who need webkit, VS 2008 og Qt Quick 1 would use. So declaring support for this will continue for a while could make it easier to remove those parts. If this could be the case, it could even be considered to go even further and get rid of more stuff. VS 2010 would be one possibility. I'm writing this with VS 2010 open for the project I'm currently on, so I know it's still in use :) But getting rid of this opens for a lot more C++11 features. What I'm suggesting here is sort of a mini major release. It doesn't feel like a 6.0 is necessary yet, but as the 5 line is mayby around half through it's life, it might not be a bad idea to make a longer term release. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.3 still open?
Den 03-02-2015 kl. 13:18 skrev Tomasz Olszak: 2015-02-03 10:55 GMT+01:00 Bo Thorsen b...@vikingsoft.eu: Den 03-02-2015 kl. 08:35 skrev Knoll Lars: It’s not strictly closed, but I don’t think we’ll create a release from 5.3 anymore. Ok, that answers the question I posted, but not the next one. Should I do a new patch against 5.4 instead? If yes, how would I do this in gerrit? Submit it to gerrit. Depending if will you submit patch as a private person or company employee you need to agree to individual or corporate CLA (http://qt-project.org/contributionagreement.html). Next depending on how critical is this bug submit it to 5.4.1 or 5.4 branch (or dev branch). I assume you are fimiliar with gerrit and git if not see (http://qt-project.org/wiki/Gerrit-Introduction and http://qt-project.org/wiki/Setting-up-Gerrit) Also it is worth to see how to submit a patch in http://qt-project.org/wiki/Qt-Contribution-Guidelines Thanks for the description, but the problem was that I already submitted the 5.3 patch to gerrit. I'm not sure how to handle a switch in the branch I'm sending it against. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.3 still open?
Den 03-02-2015 kl. 13:33 skrev Oswald Buddenhagen: On Tue, Feb 03, 2015 at 07:35:55AM +, Knoll Lars wrote: It’s not strictly closed, but I don’t think we’ll create a release from 5.3 anymore. it's been several months since i did the last batch integration, and nobody asked for more since then, so i think we can say it's dead. On Tue, Feb 03, 2015 at 01:20:13PM +0100, Bo Thorsen wrote: I already submitted the 5.3 patch to gerrit. I'm not sure how to handle a switch in the branch I'm sending it against. gerrit lacks a frontend feature to change the target branch of existing changes. you can ask me for retargeting changes administratively (just tell the source target branch and change-id). if you're in too much of a hurry for that, you can simply push for the new branch and abandon the first change. Thanks, Oswald. I'll need to update with a test anyway, so I'll just push it to 5.4 as a new change and abandon the old. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.3 still open?
Den 03-02-2015 kl. 08:35 skrev Knoll Lars: It’s not strictly closed, but I don’t think we’ll create a release from 5.3 anymore. Ok, that answers the question I posted, but not the next one. Should I do a new patch against 5.4 instead? If yes, how would I do this in gerrit? On 03/02/15 07:52, Bo Thorsen b...@vikingsoft.eu wrote: Hi guys, I fixed a bug for 5.3, but Marc asked if it was still open. I don't know that it isn't? Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] 5.3 still open?
Hi guys, I fixed a bug for 5.3, but Marc asked if it was still open. I don't know that it isn't? Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Requesting a break in behavior in QML Text element
Den 30-01-2015 kl. 08:51 skrev Mathias Hasselmann: Am 30.01.2015 um 08:12 schrieb Bo Thorsen: Den 29-01-2015 kl. 23:24 skrev Robin Burchell: Hi, Rationale: Text.AutoFormat is a terrible misfeature in almost every case out there. [...] I agree that it would be better to set plain text as the default. In most cases it's what there is in the Text elements anyway. This is at least the case for most applications I have come across. But we can't do this before 6.0. It's a clear API change that will affect every single QML application with rich text in Text elements, where they don't explicitly set the format. And why would anyone set it if they accept rich text? AutoFormat is superior to plain text in that it can accept plain text as well. We would not accept such a change for QWidget based classes, so we can't accept it for QML elements either. Sorry, but that's nonsense. With QML we can as we have versioned import statements. They are made exactly for cases like this, incompatible API changes: If the proposed change only gets implemented for import QtQuick 2.5 all existing applications will keep running as they'll import QtQuick 2.4 at maximum. You are right that this is a possibility. But it's not without cost to do this. It adds complexity for Qt developers to keep multiple versions alive and weird bugs for our users. You say it's easy for developers to upgrade to a new version and then so a quick search and replace. This is only correct if you assume that developers know they have to do this. I really don't like forcing people to have to go through a list of things that must be done when upgrading from one minor QML version to another. IMHO that's an abuse of the concept. If this was a big problem that should be fixed, sure. But I tried to argue why it's not as big a problem as the OP said. I completely disagree that having the versioning gives the right to change all kinds of details. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Requesting a break in behavior in QML Text element
Den 29-01-2015 kl. 23:24 skrev Robin Burchell: Hi, Rationale: Text.AutoFormat is a terrible misfeature in almost every case out there. [...] I agree that it would be better to set plain text as the default. In most cases it's what there is in the Text elements anyway. This is at least the case for most applications I have come across. But we can't do this before 6.0. It's a clear API change that will affect every single QML application with rich text in Text elements, where they don't explicitly set the format. And why would anyone set it if they accept rich text? AutoFormat is superior to plain text in that it can accept plain text as well. We would not accept such a change for QWidget based classes, so we can't accept it for QML elements either. The security implications you mention are true enough, but they are documented, and it's only a problem where you have user specified content. However, calling it a security problem is IMHO stretching the argument a bit. The 1pixel argument is not a security problem, it's a privacy problem. The batteri usage is not a security problem, it's a resource problem. I do agree that this is a valid issue, though. The whole security argument is based on external loading. So why not add a bool property where we can disable this? Seems to me the whole argument is pretty much invalid if there was such a property and by default this was set to OnlyLocalResources. This would also be good to have on Image. Yes, you are right that AutoFormat takes a few cpu cycles to figure out what the contents are. But that's micro optimization and not a great argument in an API debate. Bo. -- Viking Software Qt and C++ experts for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++ QML Interface thoughts
Den 06-01-2015 kl. 12:47 skrev Luke Parry: I am having issues trying to implement a c++ qml interface/wrapper that supports virtual overrides. Something functionally similar to boost::python would be excellent. This should be generic enough to also support non-QObject classes too so it rules out signals and slots. On first glance, it is fairly trivial to implement a wrapper that calls methods for the pointer, however implementing virtual overrides soon becomes difficult. I want to achieve something like this ( http://pastebin.com/t3k957Hf ) In principle, this would work creating instances in QML but not the other way transforming from a c++ instance. Is this feasible with QML without some compromise? I would like to think I'm missing something subtle or something blatantly obvious. Sounds to me like you're basically recreating the QObject based connection between QML and C++ without using QObject. That seems silly to me. If you're going to do this, accept that you're using QObject based subobjects and then you don't need to do this at all. Anyway, if you insist on doing this, the trick would probably be to make the QObject wrapper object have a pointer to the real non-QObject object. Use aggregation instead of inheritance. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
Den 17-10-2014 12:22, Julien Blanc skrev:
On 17/10/2014 10:15, Christian Kandeler wrote:
On 10/17/2014 08:48 AM, Kurt Pattyn wrote:
As we are developing for aerospace, avionics, defence and healthcare, we
are confronted on a daily basis with a lot of very stringent rules that we
have to comply with (irrespective if some people might find these rules
outdated, stupid, ridiculous or not). That's why we always compile with as
much compiler warnings as possible. Our code must be audited by an external
office anyways, so we better make sure we can avoid a bad report as soon as
possible.
Some examples of 'stupid' rules (which after second consideration aren't
that stupid after all):
- a switch statement must always have a default statement (also all cases
must be handled)
Doesn't this actually make the code *worse* when using enums? Adding a
default statement when you handle all possible values will inhibit
genuine compiler warnings when you forget to add a case for a newly
added enum value. In fact, this is almost guaranteed to happen in a
non-trivial project, so this rule seems almost absurdly wrong to me.
That one is always subject to debate. There is one thing not to forget
in favor of this rule : enums are *not* guaranted to have a value
amongst the defined ones. Undefined behaviour in that case is not an option.
I wish i could have both a default statement and my compiler warning…
switch (enumValue) {
case E1: ...; break;
case E2: ...; break;
case Nope1:
case Nope2:
// Intentionally not handled
break;
}
Boom. Can I invoice you for this now? :)
Bo.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
Oh, come on. It's just one example of one bad rule. And even if you don't accept my example for it, I can just give you another. I have a base class that declares an interface for subclasses. One method requires that the subclass looks at one of the input files and determines the date. To do this, the method declaration has three different arguments, and each of the subclass will use anything from one to three of those. When a subclass doesn't use one of the arguments, it breaks the rule. Obviously a rule written by C programmers that thought they could just apply their knowledge to C++. I will stand by my initial statement: MISRA is irrelevant for a framework. Whether you might use it in your application is up to you. But even here, I can see you break this example. I won't respond again to this thread, it's already too far off topic. Bo. Den 15-10-2014 kl. 10:52 skrev Kurt Pattyn: On 15 Oct 2014, at 09:48, Poenitz Andre andre.poen...@theqtcompany.com wrote: Kurt Pattyn pattyn.k...@gmail.com wrote: On 14 Oct 2014, at 10:21, Bo Thorsen b...@vikingsoft.eu wrote: Den 14-10-2014 08:59, Kurt Pattyn skrev: how do these applications comply with MISRA? MISRA is impossible to comply with for a framework. For example, consider the required rule 0-1-11: There shall be no unused parameters (named or unnamed) in non-virtual functions. With this, void f(int /*no_longer_used*/) is illegal. For any non-trivial framework that keeps binary compatibility, this will over time be hit. On second thought, I think this is a very bad example. Even while you keep binary compatibility, you break semantics here. This is typically a case where one should break binary compatibility. Are you seriously asking for a new major Qt release just because a new implementation of some function does not require some parameter anymore? Yes, if the semantics of the method changes. I can hardly imagine that obsoleting a parameter from a method does not have any behavioural impact in the calling application. This even holds for the case when the signature of the method does not change at all, but the semantics do. I remember once having replaced strict floating point compares with qFuzzyCompares. Although this was internal to Qt this change was - correctly - rejected. Cheers, Kurt Andre' Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
Den 14-10-2014 08:59, Kurt Pattyn skrev: how do these applications comply with MISRA? MISRA is impossible to comply with for a framework. For example, consider the required rule 0-1-11: There shall be no unused parameters (named or unnamed) in non-virtual functions. With this, void f(int /*no_longer_used*/) is illegal. For any non-trivial framework that keeps binary compatibility, this will over time be hit. There are also cases where base classes get info to methods that subclasses do not need. Sure, I can do something that could fool an automatic code checker, but that doesn't mean the rule is not violated. This is just one example. MISRA is something you use for your own code, if you feel the need to hurt or punish yourself. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt List Items in 5.3
Den 13-10-2014 00:44, Lee Powell skrev: I know all you folks are busy as this is probably not a high community request, but if you would consider adding dashes and stars to list items at the very least that would be awesome. We'd be happy to implement first and raise a merge request with the qt repository for the text based bullet styles if Digia debs were not able to add the dash and star decorations. Please let me know your preference. Sounds like this is a low risk feature. But since no one else have requested it for the many years those classes have been used, it's also a low gain feature. I suggest you try and create as small a patch as possible and do a merge request for it. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
Hi Tomaz, Den 10-10-2014 kl. 00:43 skrev Tomaz Canabrava: QConfig config; QConfigGroup root = config.root(); QConfigGroup window = root.group(window); This looks a bit more complicated from the user point of view than it needs to be. But this might be because I don't know what the QConfig class does. If it's pretty much only a wrapper that holds the root and the file name, I would prefer that it's not exposed to the user. First possible way: QConfig config(optional filename); config.setValue(... QConfigGroup window(config, window); or QConfigGroup config(optional filename, optional QConfig) Thiago asked you not to use references. A design where you have an internally shared object that is the top config could work around this. But, as I said above, I'm not sure what your plans are for your QConfig class, and what the responsibilities of it are. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] export gobal enums to QML
Den 02-09-2014 07:48, Salomon, Florian skrev:
Hi,
i’d like to know, if there is any possibility to export global enums
(defined in a separate header file) to QML?
#include “errcodes.h”
Class A : QObject
{
Q_OBJECT
Q_ENUMS(eErrorIDs)
public:
enum globalErrCodes eErrorIDs;
}
Hi Florian,
No, you have to declare the enums directly in the QObject derived class.
The generated moc code won't work if you don't.
Side note: If someone on this list is looking for a pet project, this
might be a good candidate. I think it's the third time someone has asked
this on devel or interest in the last couple of months.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStorageInfo
Den 29-08-2014 05:51, Joseph Crowell skrev: On 8/29/2014 2:34 AM, Thiago Macieira wrote: On Thursday 28 August 2014 14:18:06 Rutledge Shawn wrote: I want an API that makes it clear that detection may fail or be ambiguous. Call it storage locality or storage remoteness or, hopefully, some better name. The more types we start to add, the more difficult it becomes. We can provide an extra attribute for those types that are determined to be local to report whether they're fixed, removable, virtual or unknown. There could be a hybrid (maybe it's even common already… I'm not a user of commercial cloud storage yet so don't know): cloud storage with a big local cache, so that many files are available offline, but not everything. In the database use case maybe it should be considered local, because performance will be OK, but it's not strictly true. That's a good point and worth the fourth state. Some applications may accept using it because it's fast. Some others may refuse because huge amounts of data might be uploaded to the cloud. I wouldn't want a constantly-changing database getting sync'ed. That said, I can't fathom a way of detecting this in any current system, with any API. Is it possible to know that a folder is a Dropbox Synced folder? I don't think it is. Dropbox is completely local. They have an application that checks for local or remote changes and copies to the other side when that happens. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStorageInfo
Den 29-08-2014 12:46, André Somers skrev: Thiago Macieira schreef op 29-8-2014 06:32: Could be, but I want to be really clear that it should only be local, remote and unknown. I don't want other types like removable magnetic, removable optical, removable solid state, virtual regular filesystem, virtual special, etc. Just wondering, but what exactly is the problem with providing more details if such details are available? A combination of flags local, removable and optical would be quite informative. The problem with flags like this that if they are there, then a return value with the absence of the optical flag set means that it's not an optical disk. Flags are bools, they don't mean yes, no or unknown. The flag shows the presence of something or the absence of something. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStorageInfo
Den 27-08-2014 10:40, Knoll Lars skrev: On 26/08/14 21:00, Thiago Macieira thiago.macie...@intel.com wrote: On Tuesday 26 August 2014 12:58:41 Kuba Ober wrote: Unless we want to make this a tri-state: definitely local, definitely remote, could be either. Absolutely. It’s not even an option not to distinguish those three states. The consumer of this data can then decide which side to err on if it wishes to be conservative. It also allows the application to query the user for a clarification, if necessary. This is definitely an enum, not a bool. I want to be clear: this should be very restrictive. We can't simply add this to a list of other flags about the storage, because otherwise people won't understand that they *must* handle the couldn't-decide case. At most, we could make it a tetra-state (or is it quadri-state?): local, virtual, remote, unknown But I think that's a bad idea because it introduces even more confusion. Is a FUSE-based filesystem local, virtual or remote? It can be any of them. Besides, all of Linux's procfs, sysfs and tmpfs are virtual, yet tmpfs should be treated like a regular filesystem. Or a unionfs mount. And then there are bind mounts... Oh, did we mention btrfs subvolumes? QStorageInfo currently has a bug there. Btrfs subvolumes are mount points not listed in /etc/mnttab. I agree that there are many complex corner cases where we can’t exactly know. But let’s not forget about the common case, where we actually can determine whether the file system is local or not. I think we all agree that it’s very helpful to many applications to know this. So saying we don’t help at all here because we can’t solve 100% of the problems is wrong and not what Qt is about. So I am all for a tri/quad state here. Local, Remote Other/Unknown. And maybe a Special for things such as procfs. Let’s be conservative with it and rather have a bit too much in Other/Unknown, but let’s also help people that need the information and give the right answer for the common cases. So I’d say let’s add the enum and getters for it. We can have a default implementation that returns Unknown, and then reimplement it on each platform to do something more sensible. I haven't seen anyone ask for info on what type a drive is, if it's not local. André did, but when he explained later, he said that what they check for is if it's a local drive or not. The two use cases I saw in this thread were both of the type where they checked that storage was on a local drive because something else would be too slow. This assumption might be wrong in some cases anyway, so I hope they only warn that it might be bad. From following the discussion, it sounds like what actually be needed is a isLocal() method that return yes, no or unknown/somethingelse. That's a bit simpler and has the advantage that we won't have to expand on it to be exact when people come up with weird new hybrid solutions. And this could certainly satisfy Thiago to the point where it would always be accurate. Maybe there are cases where a heuristic would offer better results than total accuracy - I don't know that. But it is at least possible to make sure that the answer is as correct as the OS allows it to be. That is harder to do if you want a quad state that might grow to quintet, sextet and so on as new types emerge. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStorageInfo
Den 25-08-2014 17:16, André Somers skrev: Thiago Macieira schreef op 25-8-2014 17:09: On Monday 25 August 2014 13:46:12 André Somers wrote: ?? schreef op 25-8-2014 13:24: Can you provide an usecase why you need this feature? Sure. In our product, we support having the user choose where to put his database. However, we only support doing that on a local file system, as experience has shown us that using our database system on a network drive is too unreliable and leads to database corruption. Therefore, we need to detect the file system type when the user selects a location for the database. Do fuse filesystems count as local? Does it depend on what's on the other side of the fuse daemon? How about filesystem type, does it work on ntfs-3g, vfat, etc.? Lucky for us, this only runs on Windows, so no fuse or ntfs-3g to deal with. http://dokan-dev.net/en/ vfat should work fine though, though I don't think we've tested that use case. We (currently) supply the hardware as well, and deliver with NTFS formatted drives. We were asked for a use case. I gave one, and even though you can think up all kinds of scenario's where the line gets blurry, that does not mean that there are no use cases for the simple case. We currently use windows API to discover this information. Appearently, microsoft thinks that the information is relevant /and/ can be delivered with reasonable certainty. Which is probably the way people will have to go about doing it. Since this distinction isn't reliably available on Linux and it is on Windows, then the proper way would be to be able to get the native handle on the drive to call Windows methods on it. This is the same I do when I need to do native stuff on Windows in Windows (nice terminology). I think it's a mistake to attempt covering all use cases in Qt. It's much better to do the common things and allow for native calls too. So what you could do is describe what you would need to call the Windows functions for the drive type info. Then we could make sure that the storage classes can give this to you. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QOptional
Den 21-08-2014 11:43, Иван Комиссаров skrev:
Иван Комиссаров
21 авг. 2014 г., в 13:25, Simon Hausmann simon.hausm...@digia.com
написал(а):
On Thursday 21. August 2014 13.13.15 Иван Комиссаров wrote:
To be honest: I find the bool ok variant much easier to read.
if (value) on an auto variable can mean so many things. In the
above example you could very easily think: Ah, toInt returns an int,
so the type of value is probably int, so if (value) checks if it's
non-zero.
I don't think that makes for a very intuitive API. Yes, it's less to type,
but
less isn't always more :)
Writing toInt() method itself becomes more easier too:
QOptionalint toInt()
{
if (error)
return QNothing();
return value;
}
Compare with
int toInt(bool *ok = 0)
{
if (ok)
*ok = !error;
if (error)
return 0;
return value;
}
Also, using Optional/Maybe types can lead to a more functional-style code -
you can store error state in a member variable or return using bool as shown
above (which leads to extra code if (error) { ok = false; return T(); }) or
you can use maybe-type. I used this approach for parsing network messages -
without optionals i had to use a reentrant class that stored an error state,
with optionals i removed the entire class and replaced it with a pack of
thread-safe functions (taking QByteArray and returning OptionalQVariantList
where QVariantList is parsed data (yes, empty list is valid))
I have been monitoring this thread with a bit of scepticism.
And I'm sorry, but I don't see this as an improvement. It seems more
like clutter with classes instead of clutter in the syntax supported
version. The new object based version seems to me like overengineering
to solve a non-existing problem. And it's even slower than the current
version, not that I see this as an important argument, though.
I do support the argument to not implement a class that will come with
stl later. Yes, there might be a slight advantage to introduce it now,
in case there are cases in Qt where those classes could help solve real
problems instead of the above example. But if those conversion functions
is all you can come up with, I think it's a bad idea to get ahead of stl
here. So what if we have to wait for Qt 7 instead of Qt 6 to use
std::optional, if the gain is marginal anyway? *Please* don't add more
stl copied classes just because the stl committee is slow.
Please stay with the current implementation.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWayland stable branch
Den 12-08-2014 01:27, Thiago Macieira skrev: On Monday 11 August 2014 23:35:28 Robert Griebl wrote: Hi all, Someone deleted the 'stable' branch in the QtWayland repo (on Gitorious) today. Since this breaks the Yocto meta-qt5 recipe I'm wondering if (a) a stable branch will come back, or (b) it is gone for good and we have to fix the Yocto recipe. It won't come back. The Yocto recipe will need to be updated every 6 months to match the new release. At first sight, this might look wrong to some, but it isn't. As any other distribution (I know this term isn't really correct), Yocto must decide what release it wants to use, not just use the latest. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Accept the contributor agreement
Den 18-06-2014 09:05, Haataja Ismo skrev: Hi, Actually you are right, this seems to be a bug in the new gerrit version so please file a bug report here I just did: https://bugreports.qt-project.org/browse/QTQAINFRA-864 This was fixed yesterday so hopefully accepting contributor agreement now works fine for everybody. Confirmed. Oswald fixed it yesterday :) Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Accept the contributor agreement
Hi guys, I have left ICS and set up my own company again. One of the things I'll spend time on is to fix bugs and work on the widget parts. I just wrote the first bug fix and was going to try and get this in. But the codereview page won't give me the option of accepting the the individual contributor agreement. At this page http://qt-project.org/legal.html it says there will be a lineedit in which I should type I Agree and a button. But those are not there. When I click the Individual button I get the agreement for review, but nothing else. I tried with Chrome and IE, same result. Any clues? Bo Thorsen. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Accept the contributor agreement
Hi Sergio, Den 17-06-2014 14:23, Sergio Ahumada skrev: On 17.06.2014 13:28, Bo Thorsen wrote: Hi guys, I have left ICS and set up my own company again. One of the things I'll spend time on is to fix bugs and work on the widget parts. I just wrote the first bug fix and was going to try and get this in. But the codereview page won't give me the option of accepting the the individual contributor agreement. At this page http://qt-project.org/legal.html it says there will be a lineedit in which I should type I Agree and a button. But those are not there. When I click the Individual button I get the agreement for review, but nothing else. I tried with Chrome and IE, same result. Any clues? Bo Thorsen. Actually you are right, this seems to be a bug in the new gerrit version so please file a bug report here https://bugreports.qt-project.org/browse/QTQAINFRA/component/19470 I also manage to reproduce it, you just get to see the agreement but no button to accept it. I just did: https://bugreports.qt-project.org/browse/QTQAINFRA-864 Thank you for checking. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
