modernize: Remove old-style slot usage in NetworkModelController Use member function pointers in NetworkModelController and related classes, instead of old-style slots and invokeMethod().
src: Mark symbols to be exported where needed Generate export headers for the Quassel modules, and mark all relevant classes and function to be exported so that shared libraries can be linked against without globally exporting all symbols. This is a hard requirement for Windows DLLs, and more efficient on other platforms, too. For now, this was done incrementally until everything linked properly. In the future, we may consider explicitly defining the public interfaces for each module, and trying to minimize the linker interface e.g. by PIMPLing.
cmake: Link resources statically, and init locally Link resource libraries statically in order to avoid problems with symbol exporting. Move resource initialization from main() into the respective libraries.
cmake: Autogenerate most of the .qrc resource files With the CMake support from the previous commit, resource files can now be autogenerated. Do this for almost all resources; the hicolor one is special because it uses aliases, and the i18n one requires more work that is going to be added in a follow-up commit. Combine several of the previous resources (e.g. different icon sets) to reduce complexity. This wasn't possible previously due to the various configuration-specific combinations, but can now be done dynamically by extending the glob patterns accordingly.
cmake: Modernize build system Move to the modern, property-based way of using CMake. This simplifies a lot of things: - No need to manually specify interface include dirs and libraries of dependencies - No need to carry around variables - Clear separation of local and global dependencies and definitions - No need for hacks to make the triple-executable thing work Provide convenience functions to set up library and executable targets. This will make it very easy in the future to split up some modules, as well as move towards using shared libraries. Use the modern, property-based way of using Qt, too. This removes the need for the deprecated qt5_use_modules() macro, and a bunch of manual things we had to do to get the compile flags right for the different Quassel executables. Also make use of CMake's AUTOUIC and AUTORCC to avoid a bunch of boilerplate for dealing with .ui files and Qt resources. Move the .ui files from their subdirectory into the qtui directory, since the separation doesn't really make too much sense. We'd rather want to split the QtUi module into smaller parts/libraries. Remove a bunch of unnecessary stuff from the CMake files.
cmake: Remove build system support for Qt4/KDE4 In our quest to modernize the codebase, remove support for the long-dead Qt4 libraries (and consequently, also for integration into KDE4) from the build system.
Automatically synchronize CoreInfo when on connect and disconnect This refactors CoreInfo to be a single common class rather than separate classes for the core and client, adjusts it to properly use the SyncableObject infrastructure, and adds support for dynamically updating the list on both the client and core when a client connects or disconnects, keeping the list up-to-date at all times. Forwards and backwards compatibility is maintained, though the updated client is required in order for the automatic updating to work. Signed-off-by: Janne Koschinski <janne@kuschku.de> Co-authored-by: Janne Koschinski <janne@kuschku.de> Co-authored-by: Michael Marley <michael@michaelmarley.com>
dcc: Introduce TransferModel for DCC file transfers This model serves as input for a yet-to-come widget for displaying the current list of transfers.
Remove support for network detection via Solid Now that we rely on Qt 4.8 and up, we can use QNCM on all platforms. Solid::Networking didn't do anything else, and is deprecated in KDE Frameworks in favor of QNCM anyway. Also improved the core connection settings dialog a bit.
Use link dependencies between Quassel modules Rather than expressing build dependencies between the Quassel modules through add_dependency, we should treat those as link dependencies instead. This has the added advantage that transitive deps work properly (including properties like include dirs).
Avoid race conditions in the build system Adding resource files in multiple targets is a bad idea, because CMake will happily generate them multiple times too, and unfortunately also in the same location. With Qt5, this actually lead to a misgenerated oxygen_kde.qrc some times. Now we add the resources in the module they belong to, which not only avoids these race conditions, but also saves some time during compile, because every resource file is only processed once now. Changing this triggered yet another race condition, where not all translations would be generated by the time the corresponding .qrc was needed. Adding a fugly add_dependencies(mod_common po) fixes this; however we may want to find a cleaner way to properly express deps between the language files and the qrc.
Completely rework the dependency handling in the build system Traditionally, optional build dependencies are handled in CMake via offering options and conditionally searching for the needed packages. This leads to having lots of options, boilerplate for telling the user which features are enabled or not, unclear handling of automagic dependencies, and so on. These days, CMake offers a much nicer way: feature_summary() and friends. To make use of this, one calls find_package unconditionally and then sets properties on the package that tell CMake if the dependency is optional or required, its purpose, a description of the package etc. At the end of configuration, CMake then displays a nice summary of all the packages searched for and (not) found, as well as other features. Quassel now makes use of this modern way of specifying dependencies, replacing most of the former options (they're still there, but unused now, and will be removed soon). Note that one can still disable an optional dependency Foo by passing -DCMAKE_DISABLE_FIND_PACKAGE_Foo=TRUE to CMake. I also took the opportunity to radically clean up and fix how we handle dependencies throughout the build system: * We no longer set an extra CMake variable to indicate that a package was found, but use the Foo_FOUND variable directly * Compile definitions and include directories are no longer set globally in the root CMakeLists.txt, but in the Quassel modules where they're actually needed; this should speed up compiling ever so slightly and generally make things much cleaner * Libraries are now linked directly to the Quassel modules that use them, rather than to the executable. This prepares us for making the modules shared libraries at some point, and is anyway The Right Thing™ to do * Fully support Qt5 in the build system, including finding the proper version of dependencies where appropriate and available Note that the changes to the build system are not complete yet, and some things may be broken now. Note also that while Qt5 is now supported in the build system, the code itself still requires many changes to actually compile with Qt5, so don't even try.
Improve the CMake option stuff We now use cmake_dependent_option() to express dependencies between the various options that you can give to CMake for configuring Quassel; for example, enabling KDE4 now forces some options to OFF regardless of the user-selected value (which will, however, be preserved in case KDE integration is disabled again later). This also renames WITH_QT5 to USE_QT5 (and adds a USE_QT4, too); this seems to have emerged as the standard way to select a Qt version for dual-Qt packages. However, Qt4 is still selected by default unless you force Qt5 by setting the USE_QT5 flag. BTW, don't get your hopes up, Qt5 support is still broken... Once it's working, we may select Qt5 as default for certain platforms. Additionally we renamed QT to QT_PATH to make the function of this flag more clear.
Simplify handling of (dual-)Qt in the build system We've used a somewhat complex way to link the various targets to the required Qt libraries (and use the correct defines and CFLAGS...), because when that stuff was written, there were no target properties in CMake, and thus it was not easily possible to build targets within the same scope with different settings. Therefore, we couldn't use the QT_USE_FILE and had to write our own library handling. These days, target properties exist, and Qt5 came up with a nice way to attach the needed properties based on the Qt modules in use: qt5_use_modules() This was later backported to Qt4, too, replacing the old way of having to include QT_USE_FILE which would then set global variables. We now make use of this; because qt4_use_modules() only showed up in CMake 2.8.10, we've copied that function. It will be used only if it's not present in CMake proper. As a bonus, I've also wrapped all the qt-related macros into functions that do the check for the Qt version we want to build against, and select the proper macro to call, thus removing lots of WITH_QT5 conditionals from the rest of the build system. Note that Qt5 support is still incomplete, anyway.
Enable automoc Finally we can make use of this very convenient CMake feature and have the moc stuff handled automagically. No need to list the headers anymore for feeding them into the long-deprecated qt4_wrap_cpp macro. Also, this should compile a bit faster and lead to slightly better optimized code, because automoc will combine all the generated moc stuff for a target into a single translation unit. Note that we could get rid of various empty .cpp files (where all the code is in the header) by just adding the header to the sources list; that way, automoc will pick them up. There is no need to have a dummy .cpp file for that.
Refactor the transfer stuff Well, sometimes refactorings come sooner than usual. While thinking about the next steps, I decided to handle the actual transfer logic inside Transfer rather than TransferManager - now that we can have selective (peer-based) sync calls as well, that makes more sense than outsourcing that to TransferManager. Thus, it now makes lots of sense to have ClientTransfer and CoreTransfer, as the logic will be quite different. I also took the opportunity to clean up the accessors and make them safer; you can now get a non-const CoreTransfer pointer, for example, but still only a const ClientTransfer pointer. Also, some useful signals have been added.
Basic infrastructure for file transfers This introduces the Transfer class as well as TransferManager and the specialized versions for client and core. It also adds the needed accessors in Client and CoreSession as well as the SyncableObject stuff to make it all work together. To make something happen, a Transfer needs to be created on the core side with the appropriate attributes; it needs then to be synchronized and handed over to CoreTransferManager::addTransfer(). This will trigger the creation of the appropriate Transfer object on the client side, adding this to the ClientTransferManager as soon as synchronization is complete (meaning, the transferAdded() signal will be fired with a fully synchronized Transfer object). Note that the list of transfers is not synchronized (yet?), so there won't be a transfer history on re-sync.
Abstract away the protocol handshake code This continues (and hopefully mostly concludes) the work begun in 0e1b154 - abstracting away everything protocol-related from the rest of the code, so we can later add another protocol. It's also nice to not have all sorts of network- and protocol-related stuff intertwined into central classes like Core and CoreConnection. Note that nothing should change for end-users, modulo bugs. So new and old client and core should work together in all combinations, with and without SSL and/or compression. Please let me know if something's wonky. That's also true for things like connection failure handling and reconnects, as there have been many changes in those areas. Turns out that abstracting the handshake stuff was much harder and much more invasive than the previous work in SignalProxy. Turns also out that the legacy handshake protocol is not the best ever. So this touches lots of places in the code; sorry for a diff with over 3000 lines, but there was no way to sanely split the commits. Anyway, here's the gist of it: * Add auth handlers on both core and client side that process the handshake based on the generic message types in protocol.h - lots of code moved from CoreConnection and Core into the new classes. Note that "AuthHandler" is a stupid name for what it does, so we'll probably rename it to HandshakeHandler or something later. * Extend LegacyPeer to translate the new message types to and from the legacy format, moving protocol-specific code out of the existing classes. Right now only "compat mode" is supported, i.e. the handshake we've been using for what feels like a decade. In the future, some of that should be done much nicer whilst keeping the same wire format. For now, there's several quirks in LegacyPeer to somehow map the insanities in the existing protocol to something that won't bite us in the future once we want to clean up that mess. * Auth handlers will create the peer now - this is because later on the peer we need will be determined by protocol detection, which is part of the handshake. * Use the generic protocol message types directly where it makes sense (in particular for things like SessionState) - instead of QVariantMaps. * Lots of cleanups, API changes etc. were done in passing. * Probably more that I choose to not remember right now.
Fix buildsys to work without DBus
Add support for Qt5 in the build system Support for building against Qt5 can now be enabled by passing -DWITH_QT5=1 to CMake. Note that your Qt5 installation (the qmake location) needs to be in your PATH, unless it's already in one of the standard system locations. Needless to say that Qt5 support in Quassel is highly experimental, though surprisingly it seems to work mostly fine already. A README.Qt5 with known issues is forthcoming. As a side effect, I've cleaned up the build system a bit and got rid of QT_USE_FILE and the related fugly hacks for Qt4 (so that the -I and -D options now actually match the modules we're building against).