src: Yearly copyright bump This time on time!
src: Yearly copyright bump Let's welcome 2020.
src: Yearly copyright bump ... and it's still January!
modernize: Reformat ALL the source... again! It's been more than six years since we last used an autoformatter on the codebase. Tooling has progressed, so has the language and of course our personal preferences. Use clang-format this time to reformat the whole codebase, following the rules laid out in .clang-format (which one can use for configuring an IDE, too, if it supports autoformatting). Overall, the new style is not too different from what we used before, with one significant change: We now attach pointer/reference indicators (*&) to the type rather than the name, i.e. we left-align. While this is a major deviation from the Qt style which we use for almost everything else, it aligns more closely with many other projects, as well as the C++ documentation and STL. It also makes more sense semantically, because */& are really part of the type. Other changes include (but are not limited to): - Use only one blank line between function definitions - Categorize includes from generic/system to local, sorting each category alphabetically. The generic-to-local sort order seems to be more common than the other way round, so we use that. - In .cpp files, the corresponding header is always included first. This is a general recommendation, because it makes it harder to accidentally introduce a reliance on transitive includes in headers. - Consistently break initializers in ctors before the comma, so the commas are left-aligned together with the colon. - Use two spaces between code and trailing comments. Note that sometimes even clang-format gets things wrong. In a few places, formatting was manually fixed; however, reviewing a diff of almost 80k lines is a rather boring task, so we didn't thoroughly go through all the changes. Wrong formatting can always be fixed in follow-up commits, anyway. Note also that we don't intend to re-run clang-format on a regular basis, nor do we want to religiously follow a hardcoded set of rules for new code in the future. Where it makes sense, the rules may be bent in favor of better readability or more pleasing code.
modernize: Use 'using' instead of 'typedef'
modernize: Use nullptr Let clang-tidy fix all occurrences where nullptr should be used instead of 0.
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.
Semi-yearly copyright bump It's no longer 2016.
common: Represent core/client features as string list in the protocol The previous way of representing all supported features as a bit-wise combination of flags is reaching its limits, due to the fact that the old Features enum didn't have a defined width, and thus the compiler can (and does) choose to represent it as a 16 bit value even though the serialization in the protocol is defined as a 32 bit value. In order to solve this problem, and to make feature negotiation more robust, a new field "FeatureList" is added to both "ClientInit" and "ClientInitAck" handshake messages that holds a string list with the supported features. Clients still send both "Features" and "FeatureList" fields when registering, in order to support older cores. The core now omits the legacy "CoreFeatures" field if the client indicates support for extended features. Support for extended features is indicated as the legacy feature 0x8000. Note that legacy features are a subset of the new extended features. Clients supporting extended features are encouraged to send the full list, including legacy ones, in their FeatureList field. Internally, the string-based feature list is mapped to a std::vector<bool> to provide for fast lookup of enabled features. The new methods Client::isCoreFeatureEnabled() and Peer::hasFeature() allow for convenient checking. Both client and core now output a log message if there is a mismatch between the peers.
Minor cleanups
Implement UI and serialization logic for sender modes
Replace Protocol::Handler enum with enum class
Don't return const refs from methods This is dangerous and should be avoided where possible. Closes GH-302.
Implement changes requested in review - Make Peer::_connectedSince, Peer::_buildDate, Peer::_clientVersion private, add getters/setters - Correct parameter naming in doxygen comment for SignalProxy::restrictTargetPeers - Remove SignalProxy::_peers - Initialize SignalProxy::_sourcePeer to nullptr - Add Q_UNUSED for peer parameter for CoreSession::changePassword - Correct indentation in src/qtui/CMakeLists - Use pragma in src/qtui/coresessionwidget.h - Fix header ordering in src/qtui/coresessionwidget.h - Fix header ordering in src/qtui/coresessionwidget.cpp
Implement a basic UI for showing connected clients
Add initial implementation for showing and kicking connected clients Adds the possibility to show a list of connected clients, and allow to kick other (or your own) clients of the same user.
Bring copyright headers into 2016 That took some time...
Fix build with Qt-5.5 http://code.qt.io/cgit/qt/qtbase.git/commit/?id=ebef2ad1360c80ad62de5f4a1c4e7e4051725c1c
Merge pull request #117 from mamarley/oldcoresslconfig Add back the SSL protocol selection dialog box for old cores.
Make PeerPtr work for RPC calls While most of the functionality was already in place, it turns out that we need to enable loading/saving PeerPtr from/to a QVariant in order for SignalProxy to work properly. I'm honestly not sure why it seemed to work without this when implementing the TransferManager, but it's obvious it's required.