The thing is that flatpak is added to path and working fine, because it is in /usr/share/gdm/env.d/... *but* its overwriting the XDG_DATA_DIRS variable there, if you comment that line out flatpak is broken but snaps are there.

@sunnyflunk did that already but nothing changed, tried it with bash and zsh as my main login shell

So I'm opening this up again, because its a valid issue.
The issue is that on gnome wayland there is no "main" bash/zsh/... shell from which the xserver is started so the bash profiles aren't read and enviroment variables aren't set.
Upstream fixed this in this commit: https://gitlab.gnome.org/GNOME/gnome-session/commit/7e307f8ddb91db5d4051c4c792519a660ba67f35
This obviously doesn't work on Solus, because there is no /etc/profile but a /usr/share/etc/profile and so the login shell never gets run. I tried to manually fix that and see if it works afterwards, but unfortunally there seems to be another issue somewhere.
The obvious user facing issue this creates is that /snap/bin isn't added to the $PATH and /var/lib/snapd/desktop isn't added to $XDG_DATA_DIRS, so Snaps just don't show up in Gnome. The other issue is that $QT_QPA_PLATFORMTHEME is not set to gtk2, so Qt apps (eg. KeepassXC,...) isn't using *any* styling at all.

Update the component and don't install unnecessary files

Fix packaging

@sunnyflunk Thanks!
Here is the lsusb ouput:

Hello,
Can you add MFC-J220?
Would be great thanks!

@JoshStrobl they released 0.10.0 as Beta, is Beta enough for being included in the repo or should we wait for stable 1.0.0?

Remove unecessary builddep fontconfig

Use yarn instead of npm to build the package

Updating the License and adding the correct build deps

Change the default shortcut for switching tabs, because the default overrides
the globale workspace switching shortcut of budgie, to only using Ctrl instead
of using Ctrl+Alt.

Update the component

@JoshStrobl If wanted a user could install ipfs and let the daemon start at boot via a systemd script, afterwards a localhost json api is exposed so client software can directly transfer files from/to IPFS.
A direct use case would be that you could run https://d.tube which is a dececntraliced/blockchain video portal based on https://steemit.com that hosts its video files directly in ipfs, and the web UI makes it possible to use a local ipfs node instead of going through the http gateway and thus theoretically reduce latency.

Funny thing, bluetooth on my Dell only started to work after the update to 4.14, before it didn't work at all and would crash network-manager/gnome-control-center.

Update to a new Noto Version to support Android 8 (Oreo) emojis.

fontconfig 2.12.5 is out with emoji support
also
gtk+ 3.22.21 which has the emoji picker in supported text views afaik

@kyrios123 yeah I noticed to so it'll probably take some more months until this lands in all the stable releases of the software

So its in:
pango 1.40.12
cairo 1.15.8
So only thing left is a new fontconfig release and than everything should be ready to go for full emoji support.

Okay so I updated to linux-current 2 weeks ago and had no lock up/crash since then so I suppose it was a kernel bug, because linux-lts doesn't like my shiny new XPS 15 2017.
Anyways this can be closed as fixed in updated kernel I think.

Nevermind logging out and back in starts the daemon process and it works as expected.

Updated to latest gnome-screensaver and tried normal hibernation which worked perfectly fine and gnome-screensaver didn't crash.
And also after my suspend to hibernate thing it worked flawlessly two times in a row. So it was probably related to some bug in gnome-screensaver.

Okay waking up after normal suspend seems to crash the lockscreen but it just restarts and its fine after that, I can unlock the session and everything is back to how it was

Okay so the crash happend again and now I'm more and more thinking its because I use a systemd service to switch from normal suspend to hibernate after one hour and then for some reason it can't restore from that because something is scrued.
Just for reference here is my systemd unit:

Okay I'll let this open for a few days so I get some time to test this and then I'll close this as resolved

So I just updated everything on unstable and it seems to be working just fine now so its either mesa or kernel or linux-firmware

Next update on this: I was experimenting with systemd services that wake the computer from suspend to hibernate it again if it is untouched for some time. And waking from suspend crashed always Xorg, while normal suspend only did that sometimes.
After the rollback from the latest linux-firmware to the version we have now the suspend to hibernate thing worked like a charm so I suspect that the issue was in the firmware stack somewhere.

Okay seems to be a regression bug in the kernel.
At least the latest 4.9.37 kernel update seems to fixed the issue, I tried it a few times and it always came back normally without any crashes.
I'll leave this open until I can assure that it is definitly fixed.

Yeah I ran clr-boot-manager update again to remove some of my cmdline options to make sure those aren't the reason and thus I only have the current kernel.
I'm on UEFI adn i set timeout for the boot so I always see the options.
If you mean the CVE update to xorg yesterday, it was happening before and after that.
In the logs after the GPU hangs systemd tries to restart all services and thus creating new sessions for my user and lightdm.

I switched to unstable last Saturday I think and I have latest xorg from unstable so 1.18.something. I updated that one yesterday but I don't think its an xorg issue more like kernel or Mesa, I'll maybe locally revert the latest changes and try by myself.
If it is relevant this is on a Dell XPS 15 9560.

@DataDrake okay will remember that, I don't care if it gets accepted or not wasn't too much work

Probably ties into fprint which exposes a dbus api

Soo this time it should be everything fixed.

Here is an updated version of the build files, it should be much better now.

Here is an updated patch, its now building from source and it seems the api keys are not a problem.

Here is a patch to repackage I can probably make one that uses the official source but i'm not sure how that works with API keys in the tarball.

Thanks its fixed now.
@ikey :

After running

After running

Would be nice if support for the MFC-J220 could also be added, the download site is here:
http://support.brother.com/g/b/downloadtop.aspx?c=de&lang=de&prod=mfcj220_all

Sorry I'm busy lately I will come back to this in one or two weeks hopefully

And one time more

I will add the component in a sec

@JoshStrobl actually as far as i understand if someone wants to use the web version and inotify he has to use this otherwise the way would be pyinotify

Thats completly fine!

Here is the patch