Re: [Development] Qt6 source changes
On 2018-10-31 16:46, Thiago Macieira wrote: Qt6 won't be fully source-compatible. The idea is that we'll break it to fix things, but attempt to keep compatible as much as possible to avoid death by a thousand paper cuts. Does this rule out some kind of smart pointer that would be used to hold QObject*? I've seen lots of commercial code bases in the past where QObject inheriting classes are combined with QExplicitlySharedDataPointer - while at the same time relying on having a parent in those QObjects. Semantically: - There's some class for which QObject benefits like Signals/Slots are required - They are strongly owned by some other QObject based entity - A lot of code stores a reference to them (In terms of a QESDP), where either: - the reference _should_ be invalidated during destruction - the existence of such reference (to a child) _should_ stop the parent from destroying that child. - The overhead of QPointer is not desirable I know these requirements are kind of a paradox. But both variants of this are a pattern, I find relatively often in customer's code bases. I would really like to have an easy way to give such customers a "sane" way forward. Sascha ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Monday, February 25, 2013 05:12:48 PM Joerg Bornemann wrote: On 25/02/2013 16:27, Jake Thomas Petroules wrote: I'd prefer Qt namespace with no platform indicators, i.e.: Qt::toHICON Qt::toHBITMAP Qt::toCGImageRef Qt::toNSString It's obvious to which platform each function belongs; there's no need to qualify it beyond necessary. If WinRT introduces an NSString class and OS X adds HBITMAPs only then should we think about adding the platform name to the function. :) That means we're restricting ourselves to type conversion functions? A function that's potentially useful on more than one platform wouldn't be possible. Why would a function that is potentially useful on more than one platform go to platform extras? Sascha ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Monday, February 25, 2013 05:50:06 PM Joerg Bornemann wrote: On 25/02/2013 17:25, Sascha Cunz wrote: Why would a function that is potentially useful on more than one platform go to platform extras? Because it's working on native types (more than just one) and encoding all type names into the function name would be strange. The same function name could make sense on a different platform. Note that I'm talking about the function name, not the full signature. Actually, i don't get this: If there is some feature that is reasonable to have on more than one platform, then Qt should probably abstract it with a Qt-ish API, right? That's at least how things worked for ages. In terms of Qt 5, this would probably result in an add on QtFooFeature, which is tagged as available for the platforms it works upon. If on the other hand there's a complex feature that is bound to one platform and it is not yet covered by a add on on it's own, this feature should be properly abstracted into a Qt-ish Api, too, right? Properly abstracted here refers to a class inside the add on's namespace. As far as i can see, this leaves two kinds of functions that could possibly become members of the Qt- or the addon's namespace: - Functions that extent the API of an already abstracted feature (i.e. QString or QImage) with platform specific code. These would provide platform specific additions to the feature itself. If there is one of them, they could as well go to a namespace; If it is foreseeable that their number will increase by time, they should probably go into a class; c.f. qt4's qt_mac_XXX stuff for unified toolbar support. - Functions that convert Qt objects into their native pendant. These don't introduce new features themselves. They just provide compatibility to additional features of the native platform. These usually don't overlap in signature. Sascha ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt's generated cmake files
On Monday, February 18, 2013 07:18:44 AM Stephen Kelly wrote: On Monday, February 18, 2013 03:27:32 Sascha Cunz wrote: I am using FIND_PACKAGE and QT_USE_MODULES in each subdirectory of my cmake source tree like shown in [2]. This is required, because I have a generic stub that encapsules the differences from Qt4/5 and use that in several different projects. So i actually don't know in advance what git submodules are in use and what Qt modules they depend on. Hi there, You seem to be doing some things which are not recommended. You shouldn't be starting with finding qmake Maybe things changed since I set this up, but I never got this to work reliable without appending the cmake_prefix. I.e.: On windows I might have installed Qt to X:\Qt5\bin - how would cmake know that I installed Qt there, unless I append the prefix path? Considering the smallness of most of my projects, when something goes wrong that is not easily explained, probably caused by invalid build or when switching platforms, i tend to completely remove my build directory and do a fresh cmake run followed by a full build. As I don't want to populate the cache every time, I settled on searching for qmake in $path and append the cmake_prefix_path with qt's install path. Isn't this a valid approach? What would be better yet still that simple? and you shouldn't include() the config files directly. Using include() directly is likely to have unintended consequences. Ah, I see. Will try that. The appropriate way to write an umbrella infrastructure is something like what is in these files: http://quickgit.kde.org/index.php?p=extra-cmake-modules.gita=blobf=find- modules%2FFindQt5Transitional.cmake http://quickgit.kde.org/index.php?p=extra-cmake- modules.gita=blobf=modules%2FECMQt4To5Porting.cmake Why do you duplicate the RCC macro? Just for one reason: To have a unique name with Qt4 and Qt5. Actually, might as well be an old habbit: In older projects I used to duplicate the Qt-Macros in order to automatically group files into virtual folders for Visual Studio projects. But looking at this instance once again, I think you indeed have a point here: I should just wrap the original in a macro. I just created a project which calls find_package(Qt5Core) in two subdirectories and uses Qt5Core_INCLUDE_DIRS, and it works for me. Please file a bug with a minimal testcase, preferably using find_package instead of include() as you do. Thanks for your input. I will investigate this further based on your comments. Sascha ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt's generated cmake files
Hi Stephen, after the merge from [stable] to [dev] branch, my jenkins server noticed that there is a problem with compiling my stacks against Qt5. After looking over all the changes, I found out that there is an issue with the gerrit change 47230 [1] and am trying to find a way to solve or at least work around it. I am using FIND_PACKAGE and QT_USE_MODULES in each subdirectory of my cmake source tree like shown in [2]. This is required, because I have a generic stub that encapsules the differences from Qt4/5 and use that in several different projects. So i actually don't know in advance what git submodules are in use and what Qt modules they depend on. Since the above mentioned change, my QT_PREPARE macro keeps resetting Qt5Core_INCLUDE_DIRS and does not add the $qtprefix/include anymore (which is done in Qt5CoreConfigExtra.cmake). The builds then fail in Qt internal includes, like: In file included from /var/lib/jenkins/qt5/include/QtCore/QAtomicInt:1:0, from /var/lib/jenkins/home/w/MacGitver_Qt5_GCC/src/libGitWrap/libGitWrap/BasicObject.hpp:20, from /var/lib/jenkins/home/w/MacGitver_Qt5_GCC/src/libGitWrap/libGitWrap/BasicObject.cpp:17: /var/lib/jenkins/qt5/include/QtCore/qatomic.h:42:28: fatal error: QtCore/qglobal.h: No such file or directory compilation terminated. Can you think of an easy way to solve this? Sascha [1] https://codereview.qt-project.org/#change,47230 [2] https://github.com/macgitver/MacGitver/blob/development/cmake/Qt5.cmake#L131-L163 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU and Windows
Am Freitag, 11. Januar 2013, 23:07:25 schrieb Shaw Andy: [...] Microsoft in the past has also said that you should keep the -MD(d)/-MT(d) setting consistent so it is the same across all libraries and applications, [...] Which is cool, if you can manage it. But it's far from what happens in the real world. In the real world you have foreign libraries to load, doesn't matter if these are stock libraries provided from Microsoft, from 3rd parties or even yourself. It is not uncommon to have all kinds of memory managers mixed in one application (some windows libraries still use MSVC6's runtime as dll). [snip] Granted it is tricky to ensure it happens in the real world, but we are in the position to ensure that we do in fact do the right thing in this case then shouldn't we actually do so? In my book, the right thing to do is - as Thiago said - to ensure that memmory allocated by library X is also freed by library X. Everything other, including the play-safe recommendation from Microsoft above, looks like a workaround to me. An additional reasoning comes to mind: If one ever wanted to use a memory profiler that is not a virtual-machine (like valgrind) or does dependency injecting but depends on code-augmentation, you won't have any luck getting this setup unless you compile all 3rd party provided code with that augmentation, too. Sascha ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Updating Daemon/Service Support
[...] The difference is that 'operate' and 'configure' are two different tasks and thus usually require two different interfaces. The 'operate' interface of an anti-malware service is to monitor data and network traffic. The 'configure' interface is most probably a seperate application which allows for tweaking the service parameters. The 'operate' interface of a web server is to listen on a specific port and hand out data when requested. The 'configure' interface is most probably a seperate application or a configuration file which allows for tweaking the service parameters. I don't oppose to all of that. Just that it has to happen through a QLocalSocket. As soon as I want to configure such a service remotely, I'm bound to rely on SSH-tunneling or such. In that case I'd want to make that interface TCP based and add authentification to it. If - like originally suggested - the 'daemon framework' provided us with the QLocalSocket restriction, I had no easy way doing that. It is quite unlikely that a service has either just the one (does something which can't be configured) or just to other (does nothing which can be configured). And it is quite unlikely that a service has a single interface for both tasks. I've written quite some services that just plug into a fixed database and get all they need from there... [...] This simplest form describes an IPC technique that is currently not deployed in Qt. It would be cool to have it, but it has nothing to do with a 'Daemon- Framework'. What you describe here sounds to me like something between DBUS and COM, readily tailored towards Qt's singal/slot mechanism. Qt already allows to serialize any datatype known to the meta type system, provides means for IPC (D-Bus is just one example) and has a code generator which implements our objects (moc) and allows for handling asynchronous signals and slots. So in principle I don't see a reason why Qt shouldn't or couldn't create stub implementations of the shared Q_INTERFACE which uses IPC to communicate across process boundaries. By all means then, find someone to implement it. Could turn out to be yet another shiny gem in the bag of Qt-Evangelists. You are right, this is not directly related - or bound to - the 'Daemon Framework'; but I'm in any case forced to use IPC when creating an interactive service. Here we come together again... Because this was, what I initially wanted to say: 1. We don't need to communicate with the daemon for administrative operations like starting / pausing / stopping. We _must_ integrate into the native OS- provided meachnisms. 2. Even configuration and/or monitoring a daemon belong to the daemon's bussiness logic. This requires IPC, that much i don't disagree, but: 3. Qt has already a good collection of IPC mechanisms built in (file-based, database-based, network-based, local IPC via various ways, DBUS ...). There is no need to limit us to a local-socket. Sascha ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Updating Daemon/Service Support
All services/daemons must be able to interface with other processes: Here, I almost agree :-) (a)- a client-process can request-a-client-operation to occur on that service/daemon But this is totally orthogonal to the application being a daemon/service. To some daemons your application talks HTTP, SMTP, mysql-protocol or whatever others... Why would someone writing a cron-alike daemon want to listen on some QLocalSocket? (b)- a process can query or control the service/daemon (such as to pause it, or stop it, etc.) That is the task of: - launchctl on Mac - Service-Manager / net start / ServiceControlManager-API on Windows - Init-Scripts (or interfaces to them) on Linux [This describtion meats OpenRC, Upstart, systemd and even SysVInit, right?] Without using those, you blindly bypass any security mechanisms that the OS itself provides for services/daemons. I really wouldn't like anybody on my system capable of creating a QLocalSocket to also be able to stop a service. Thus, some inter-process communication is always required. IPC can also be shared-memory or files on disk. This has nothing to do with a QLocalSocket. Sascha ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Updating Daemon/Service Support
Am Dienstag, 27. November 2012, 08:16:20 schrieb Lukas Geyer: Am 27.11.2012 06:15, schrieb Sascha Cunz: A daemon/service has two interfaces: (i) user/system-API oriented, and (ii) one internal. The first presents the interface to the outside world on how to control the service. This interface needs to integrated into the system - e.g. Windows Service API, systemd, shell scripting, user query. Right. However, this interface also needs to be able to talk to the daemonized process which has had its user-interface (e.g. Tty) removed from it. You can only do that using some form of communications - network port, message queues, etc. But why would it want to do that? I mean: Is there a generic gain that is not already provided by the operating system itself? Yes. Each service which needs to interact with the user requires some sort of IPC to provide a graphical interface, as interactive services are not allowed on most modern operating systems (not to mention design considerations). As you said: this applies _only_ to those that needs to interact with the user. These are not the majority on the operating systems I use (Windows and Linux, mostly). Basically each service has three different 'interfaces': - lifetime control: start, stop, restart, installation, removal and alike. This is (usually) not a responsibility of the service, but solely the system (ie. the Service Manager, systemd and alike). The 'Daemon Framework' may provide platform-independent means (a set of classes and a simple tool using those) to interact with the platform-specific service management system to control the lifetime of a service and to interact with the system to provide status and receive events. Agreed. - the 'service': which basically abstracts the task the service has been installed for, e.g. serving data over HTTP for a web server, scanning disks for an antivirus service, transferring data for a backup service. 'The Daemon Framework' does not have to provide any support for this interface, as it is purely application-specific and already provided by other parts of Qt (QTcpServer, QFile, QFileSystemWatcher and alike). Agreed. - the configuration or user interface: which basically allows for interacting with the user, which might be in the simplest form a configuration file, but more often then not this is full-blown application to do service-specific tasks, be it the user interface for the antivirus service (configuration of the scan engine, add and remove localtions, on-demand scanning and alike) or the backup service (add or remove jobs, on-demand backup and alike). Where is the difference to the previous bullet? As a user (as in 'using the framework to develop service applications and user clients') I expect (as in 'I would like to see') from the 'Daemon Framework' to: - provide a set of classes which allow for interacting with the system-specific service manager, both from the service application (report status, request reload or restart, notification of system events and alike) as well from the user client or a configuration or installation utility (start, stop, restart, install, remove and alike). That would be awesome to have! - provide no support for the 'service' interface. Agreed. - provide support to interact with the service from a (graphical) user client in a flexible, transparent way. How can this be _generic_? This stuff obviously belongs to the bussiness logic of the daemon/service. In its 'simplest' form this is a Q_INTERFACE implemented on the service side and generated on the client side, which automatically routes all signals, slots, properties and method calls to the service application using some kind of (local and non-local) IPC. If needed, I expect to be able to 'go deeper', selecting a specific IPC method, directly accessing the IPC and alike. This simplest form describes an IPC technique that is currently not deployed in Qt. It would be cool to have it, but it has nothing to do with a 'Daemon- Framework'. What you describe here sounds to me like something between DBUS and COM, readily tailored towards Qt's singal/slot mechanism. Another thing that comes to mind would be a towards-Qt-tailored implementation of Google's protobuf [1]. But again: This isn't service-specific. There are use-cases for 2 desktop-apps to talk in that manner to each other. Just think about Microsoft's PDB-Server, which is acutally a background process (but not as fullblown to be called service) that the IDE, Debugger and Compiler use. - provide support to interface with the service directly. Well, again, I don't think that a daemon-framework should force a specific way of interaction to the user (=developer). I mean, hey, so we may finally get a suitable out-of-the-box command line parser after two decades of development ;-) Yes, please! :-) On a sidenote: There is a scope for non-interactive, but QGuiApplication
