Fix typos
src: Yearly copyright bump This time on time!
client: Switch infobar dialog-* icons to emblem-* Switch the icons representing whether a feature is supported or not from the "dialog-*" set of icons, which can be hard to distinguish at small sizes, to the "emblem-*" set of icons, which are much more distinguishable, and actually designed as emblems. This means older icon sets such as Ubuntu's Humanity will no longer have a custom icon available, but the Breeze icons aren't too far out of place. Oxygen does not provide these icons, so include a fallback to the previous icon names.
client: Deprecate local highlight, migrate cleanup Deprecate "Local Highlights" for client and core setups, adapting the name "Legacy Highlights" as used with monolithic installs. Make the legacy nature more prominent, but keep support enabled. In the future, legacy highlights should be disabled and invisible except when connected to older cores. Rename "Remote Highlights" to "Highlights" and place first in the settings list. When using the "Import Legacy" button, migrate nickname highlight settings and offer to remove the old local highlight rules, avoiding redundant highlight rules. This should help reduce the cases where Highlight Ignore Rules are configured, but don't seem to respond due to client highlights overriding the core-side highlight ignore rules.
Revert "settings: Local Highlights, default Current nick" This reverts commit 8fb51dcb129db8399209e9d07b518063d1a910f1. Quassel 0.13 with core-side highlight support ("Remote Highlights") has been out for roughly 1.5 years (2018-11-17). Users have gotten confused by why highlight ignore rules don't work, only to find out client-side ("Local Highlights") were enabled instead. Disable local highlights by default to avoid this issue. Those using old cores can re-enable this.
src: Yearly copyright bump Let's welcome 2020.
Add missing includes For std::sort we should include <algorithm>.
Replace deprecated qSort with std::sort
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: Replace most remaining old-style connects by PMF ones Manually replace old-style connects (using the SIGNAL/SLOT macros) by the much more efficient and typesafe pointer-to-member-function- based ones. This fixes the cases where clazy could not auto-migrate to the new syntax for a variety of reasons. In most of the cases, we need to remove overloads or explicitly select the desired one, because the plain syntax cannot deal with overloads. Another issue is trying to connect to signals in a baseclass that are only declared in a derived class (which works with the old-style runtime connection handling, but obviously no longer with the compile-time version). Also do some selected cleanups in places.
clazy: Convert many old-style connects into function pointer based Since Qt5, signal/slot connections can be expressed using function pointers rather than the SIGNAL/SLOT macros. This is a) much more efficient, and b) provides a compile-time check for the sender and receiver being compatible. Let clazy auto-fix old-style connects where it can. However, a lot of occurrences remain where we'll need manual intervention for one reason or another.
modernize: Use auto where the type is clear from context Apply clang-tidy's modernize-use-auto fix, which uses auto where the type would otherwise be duplicated in the line (e.g. when casting a type, or creating an instance with 'new').
qt4-b-gone: Remove all code supporting Qt < 5.5 and KDE4 Remove compatibility code for Qt versions we no longer support.
settings: Local Highlights, default Current nick Re-enable nickname highlighting in Local Highlights by default. This fixes the issue of upgrading the client before the core resulting in loss of nickname highlighting. Many other options were discussed, such as unifying these settings (new UI work), automatically toggling/disabling local based on core features, auto-importing, etc, and though all better approaches, they will take a good bit more time to implement correctly. The focus is on fixing client-side settings properly in 0.14+, with profiles allowing for different settings per groups of clients, allowing deprecation of local highlights entirely. Partial revert of f2e4560b71a1888599ca2153eee36a9b4136c902 and 5fcc2f000757bb7c2578e09c8fc8c86a288c3cb5
client: Clarify highlight 'Channel' functionality Modify 'Channel' column tooltip to mention 'channel/query', since this actually refers to buffer name. As it's less likely someone will want to set highlights on queries as they trigger notifications by default, don't rename the column itself.
icons: Warn on missing icons Provide new helper functions icon::get() that replace the uses of QIcon::fromTheme. These functions still use fromTheme() internally, but log a warning if an icon could not be found. This should make it easier to detect problems with icons. Replace all uses of QIcon::fromTheme() with icon::get(), remove useless fallbacks as that should be taken care of by the normal icon loader mechanism. Update the icon import script accordingly.
mono: Move Local Highlights -> Legacy Highlights Rename "Local Highlights" as "Legacy Highlights", and rename "Remote Highlights" as plain "Highlights". Update the info-bar text and other references as appropriate. This reduces confusion over which highlights to configure in Monolithic mode.
common: Apply RegEx, CS column to sender, channel Modify scopeMatch to optionally treat the rule as a regular expression, and to treat it as case-sensitive or not. Modify highlight rule processing to... * Use scopeMatch for "Sender", allowing easy multi-sender rules * Treat both "Sender" and "Channel" as regular expressions if "RegEx" is checked, allowing for full regular expression power. (Breaks existing rules with RegEx matching, but in a different way) This means it is no longer possible to use RegEx matching for the "Sender" and "Channel" yet not on the phrase itself. However, it should be easy enough to work around this by using the same phrase regular expression Quassel does. This should simplify common highlight rules without limiting those who know regular expressions. Win-win, hopefully? Update tooltips to reflect these changes.
client: Explain Local Highlights vs. Remote Add footer to "Local Highlights" page to note that local highlights apply to the current device only, including a "Details..." button. Add a "Details..." dialog with a brief explanation and points out where to configure highlights for all devices. For Monolithic builds, indicate that "Remote Highlights" replaces "Local Highlights" to help avoid confusion. There's no remote core, so local highlights have no reason to exist other than to provide a path for upgrades.