Birdtray sounds like what you’re looking for. It allows you to close Thunderbird to the system tray so that it runs in the background. Thunderbird already throws notifications to GNOME, and should continue to do so while running in the background in the way.
There’s desperate need to a library that’s simpler to use than wlroots or smithay - but unless it supports more protocols (later shell, gamma control, session lock), I don’t think this is a real a alternative yet.
I was thinking similar, though I'm also still on X with nVidia and XFCE and am in a weird way* with programming.
I have my own custom XFWM theme that is really minimal (12px title with 8px tall buttons with some being wider to compensate, somewhat outdated example) and I'd like to expand upon it (floating titles, inset window buttons, dynamic button width, media integration) but I've looked at examples and don't understand enough to even get just a rectangle for a titlebar (though X I assume for something basic, X would probably still be the easiest).
*= the only language that I'm interested in (due to it being easy in a style I like while still having performance/capability/flexibility etc) is not popular, and worse is I have lost a bit of hope/confidence in its future (as well as its bus factor reducing further because the person who made the package manager+installer and a book walked away) so I still haven't really done much with it.
I've asked about this on the Fediverse once already and didn't get any responses.
Also note that bindings for Godot 4.X (or some other not-superheavy Linux-compatible engine that has an editor especially) are a big part of what I want, so some specifics that may work on paper otherwise might not fit the bill either. Also because polygonal art (meme made with 3.X, 4.0 eye animation, not-yet-in-4.X test of someone elses' PR)
I completely agree. I invest time in implementing protocols within the library, allowing it to handle many tasks autonomously, thus relieving developers from manually wiring everything themselves—without compromising flexibility oc. Regarding “later shell,” did you mean “layer shell”? Developers can certainly still implement protocols not included with Louvre on their own, but that’s not quite the intended approach.
Fedora Sericea is my current daily driver. Loving it so far. I’ve used Sway, River, and Hyprland on Arch, Fedora, and NixOS. The combination of an immutable system augmented by flatpaks and distrobox are supporting my goal to never wipe the drive again.
Sway is more stable and lightweight for me than Hyprland. I don’t use Nvidia hardware at all. The lead Dev on Hyprland is a treasure though. 10/10 for that human being.
The operating system in use shouldn’t be a factor. Consider opening your laptop to perform a thorough cleaning, and also consider replacing the thermal paste as well. If you’re not comfortable doing this yourself, taking it to a repair shop is a viable option. Investing in a cooling stand for the laptop would also be beneficial…
Replacing the thermal paste is essential. It dries out over time and stops conducting heat effectively. Cleaning the fans and radiator fins is important too. Takes an hour or so if you don’t know what you’re doing so shouldn’t take long. I’ve kept my laptop going for years by doing that every 2 years or so.
Honestly, I haven’t explored Vulkan yet. I initially chose GLES 2.0 as the primary renderer to ensure compatibility with a wide range of hardware. Introducing Vulkan myself would be a time-consuming task unless I receive assistance.
Regarding XWayland, Louvre doesn’t currently support it, so it’s naturally excluded. Well, it technically can run in rootful mode, but that is somewhat pointless. To enable independent window management, I believe I would need to create a mini X server, a task I haven’t tackled as of now.
Probably all of them have better Vulkan than opengl drivers (due to drivers being simpler). David Arlie rather quickly implemented first Vulkan driver for AMD once Vulkan was first released. Just in case you need incentive.
I was thinking of starting something similar as a learning exercise, but I’m really limited in time and not skilled as much in c++, so it would probably lead nowhere. Now I can just build on top - if I get any time for this, will come probably with questions.
Anyway, this idea was to make something modern. Without the legacy crap. Actual goals were:
Vulkan only (move gfx API Info the future)
no x/xwayland (most of the apps in newer toolkits already support Wayland, the others I’d rather avoid)
Interesting, I don’t recall where I read about Vulkan support still being experimental in many Mesa drivers; it might have been an outdated post. I’ll look into it, and perhaps I’ll decide to dive into learning Vulkan. Additionally, there are buffer-sharing mechanisms that already work smoothly with GLES, so I need to explore if the situation is similar for Vulkan. Thanks for your response, and if you have the time and inclination to help include it, feel free to do so! 😄
Lots of cleaning advice, but let me add this bit: If you crack it open and use a can of air on it, unplug the CPU fan first. Super easy if you’ve gone that far.
Lets see if I got this right, you (the OP), the creator of Louvre, managed to create an example compositor that looks like a better desktop experience than the entire KDE and GNOME teams could ever develop with their infinite wisdom and funding? Fucking amazing. :)
I know this is an example, but seriously following the “copy apple down to the last pixel” approach you should consider creating a DE for Linux that doesn’t have themes or any user tweaks, just a simple and pixel-perfect copy of macOS. The problem with GNOME and KDE is that they both fail in simple design principals such as proportions, item spacing and whatnot while Apple, and you by extension, excels in that aspect.
Furthermore my personal opinion is that GNOME tries to reinvent everything and ends up fucking things up and creating situations like the lack of desktop icons going into the activities view by default etc. KDE however does some other stuff right but they fail really badly in terms of proportions and item spacing. Their taskbar is also a shame, for a group that says they want to copy Windows’ style they aren’t doing that well.
Desktop experiences when it comes to design peaked with macOS Monterey (after that Apple did changes to the settings that are still not polished) and in terms of usability they peaked with the release of Exposé, Spaces and later their integration on Mission Control (initially bad but now they seem better).
If you do create a 1:1 copy of macOS desktop experience (and keep it updates) as a new DE you’ll most likely become very popular in no time. It doesn’t need themes, customization and all the personalization that would make it really hard to create, just a simply pixel perfect copy of macOS.
Thanks! While I may have nailed server-side decorations in that example, as you know, there is too much other stuff to take into account to make a DE actually functional. So, I respect a lot what KDE and GNOME do and the innovations they make. I actually want to create a macOS clone, hahaha. That is one of the reasons I started this project. I will soon continue working on a library for exposing global menus in Wayland/X11. Qt allows defining a custom platform plugin, enabling us to plug external systems for managing global menus. Sadly, I think GTK4 no longer supports that, so I believe an approach would be to display a standard menu with basic functions for apps that don’t support it.
Ohh, that’s cool. How far do you want to go with this? I had the idea of using a custom wayland protocol to make per-app global menus instead of per-window so you can have an app open without any windows, like on macOS, in the compositor I wanted to write. However writing a compositor using wlroots is still incredibly difficult if you have no prior experience so the whole thing didn’t get very far yet. If that’s something you want to do too, I’d be very interested in this.
(Speaking of, why did you decide not to build this on top of wlroots?)
I actually already created a library for that called Heaven (github.com/CuarzoSoftware/Heaven), but I want to rewrite it to make it simpler and add backends for different IPC mechanisms (Unix domain sockets and D-Bus).
It allows apps to create as many menu bars as they want. The idea is that when one of its toplevel windows is activated, it can notify the “topbar app” to display a specific menu bar. The compositor also informs the “topbar app” about the currently active client. So, it has three APIs: one for apps, another for the “topbar app,” and another for the compositor. Apps are identified by their PID.
Now, with respect to the second question, a long time ago, I tried to create a compositor using QtWayland, which had the most documentation at that time. However, it had some problems with certain interfaces that made the compositor crash. So, I then looked for wlroots but could find no documentation whatsoever, so I decided to start from scratch. As time passed, I began to learn and understand how protocols work, realizing that one of the most challenging things was implementing protocols correctly, as there are too many interfaces that depend on each other, and you need to implement them all before you can see results and validate that it works. That’s why I decided to create this lib, even as my university thesis, with the focus of offering a default and basic implementation of each protocol so that developers can see a functional compositor from the start and then gradually and specifically override whatever they need, being able to validate each feature they add immediately. Of course, there are many other complicated things I had to learn, such as the DRM/KMS API, buffer sharing through DMA, among other stuff. I really appreciate wlroots, though. I learned a lot by analyzing its source code, and surely today I would be able to create a compositor with it, hahaha.
I’m using Claws Mail. It has a plugin that can do notifications in many ways, including a tray icon. You can configure it to start hidden in the tray, configure how often it checks email and on which accounts, to which folders the notification should react etc.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.