The top bar is only shown if the user is connected to at least one
network. Only then it is possible to open the recent mentions popup.
Only toggle the recent mentions popup if the user is connected to at
least one network so the popup will not open over the connect view.
It may not be desirable to host all plugins on npm, allow for local packages to
be installed given a package name with a `file:` prefix.
This is still more restrictive than what yarn would support but allows us to still
verify the thelounge compatibility by reading the package.json file.
`yarn add` messes up with local filepaths and generates a lockfile that is
"outdated" as far as any other yarn commands go, which makes them error out.
For some reason `yarn install` fixes that and hence we run that after an install.
Here's the diff of yarn.lock between the broken state after `yarn add file:$path`
and `yarn install`
--- yarn.lock.2.afterAdd 2021-06-02 00:10:52.365134018 +0200
+++ yarn.lock.3.afterinstall 2021-06-02 00:13:27.122760442 +0200
@@ -2194,7 +2194,7 @@
safe-buffer "^5.1.2"
yallist "^3.0.3"
-thelounge-plugin-shortcuts@/home/reto/sourcecode/thelounge-plugin-shortcuts:
+"thelounge-plugin-shortcuts@file:../../sourcecode/thelounge-plugin-shortcuts":
version "1.0.12"
dependencies:
thelounge "4.2.0"
The only thing it does is switch an absolute path to a relative one for whatever
reason.
On some IRC networks, users have vanity host masks with colors or other text styling.
Rizon is one such network.
For example, a user connecting from 127.0.0.1 could instead have the host
angerson@this.is.my.host.mask. this.is.my.host.mask may have IRC color code
characters in it, which without this change would be displayed as a bunch of jumbled
garbage in the /whois response or join/part messages.
Resolves#4232.
Because the "Username" components still had the same ":key" vue tried to in-place update them. This doesn't quite work for objects (in this case "user" or "user.original"). Thus we change the key for the search so that it actually inits a new component and thus evaluates its content correctly.
Tested on latest Chromium / Firefox. In case of .m4a files they want audio/x-m4a and not audio/m4a, in case of .flac files they want audio/flac and not audio/x-flac. The module we useed to detect the types however detects them only as audio/x-m4a and audio/x-flac as they are not offical IANA supported mime types (not in IANA spec == "x-" prefix): https://www.iana.org/assignments/media-types/media-types.xhtml Though flac is not in the IANA spec many programs such as the file command (https://man7.org/linux/man-pages/man1/file.1.html) and Chromium (flac) / Firefox (x-flac and flac) support audio/flac only or both.
