cycloptic

For whatever reason this is not well documented, but all the theme's colors are available with a special syntax in the CSS: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gtk/theme/A...

So for example you should be using this to use the user's foreground and background color:

    color: @theme_fg_color;
    background-color: @theme_bg_color;

You can use some modifier functions on those colors too to compute additional colors: https://developer.gnome.org/gtk4/stable/ch39s02.html

I would suggest against trying to piggy back on built-in CSS styles; usually with the default widgets you want to favor composition over inheritance. But if you really need to you can use the GTK inspector to look at the styles on any given system widget, that should be a bit easier than grepping through the CSS.

>All I have are mpd, dbus, pulseaudio, mako which I can easily run from my sway/config

The thing is, you want service management here. Sway is not a service manager and won't handle monitoring of the processes, socket activation, logging, etc.

>to do things that have no reason to be platform specific.

If you ever try to port systemd code to non-Linux platforms you will see that this is not true. There are lots of things in Linux that have no real analog on other platforms, and it seems strange to fault a project for taking advantage of those. (BSD is the same way when you get into that too)

Journald stores a lot of metadata and it is difficult to effectively store metadata without having some kind of structured format. (And before someone says it, storing JSON on disk or trying to split the metadata across files would probably be much worse than binary logs)

I am honestly surprised we haven't seen a good GUI pop up around systemd yet that allows for simple service creation and configuration like that.

>The problem was that AWS is better at acquiring customers for their competing hosting service.

I would actually take this a step further and say the problem was that Elastic apparently never had no plan for how to deal with Amazon. If hosting is ever on the table, this has to be part of the plan from the beginning. For every customer that says "your hosted solution won't work for us, we're thinking about deploying on AWS" they have to be able to translate that into profit. This seems like a lose-lose for Elastic as they have effectively ceded all that away to this fork. The use of SSPL also seems like nonsense here that won't result in them seeing a dime from Amazon.

>you can see what kind of response that's gotten

I don't think we have. Like I said, I have not seen any serious offers to work on a non-intrusive patch for this, to put up the time and/or money and to maintain it for the number of years required. That's what you want to look for. And if you want to bring it upstream, you have to sell it to them in a way that shows it will not increase their maintenance burden or break the currently in-place designs. (This is not a GNOME specific thing, this is how basically every open source project operates. You generally can't just dump code on upstream and expect it to go well)

If you want to do fundraising, some trusted person has to put in the time to do it and to manage the money.

If you have a working patch for this that makes it a configurable option then just use that. There is no harm in submitting that as a merge request either, worst case it gets rejected again and you're in the same spot you are now. I don't believe a real non-intrusive patch was ever submitted for this, everything out there just seems to be a revert back to some old functionality that breaks other things. (Please don't waste maintainer time submitting patches that are broken or hacky, or patches that were already rejected. When in doubt talk about it with them first before submitting anything, and make sure your patch is actually new and addresses all the concerns that were made in the bug tracker already)

If it does get rejected then you do the same thing you'd do with any other open source project: convince your distro to carry the patch. I think the key here is to just not lose sight of the goal which is to get enough support somewhere to have the patch maintained, if you don't care to become an upstream developer and work closely with them then you can skip that and just do the same process but only with a downstream that is relevant to you.

If the patch still needs a lot of work/money to get it to the point where it's stable and doesn't break other things, well, now you know why upstream doesn't want to do it... so with that I would say a way to help would be to commit to maintaining this for however many years you expect to be using the patch. I can't give you a specific quote (I don't have any interest in working on this, sorry) but based on average developer rates you probably should expect to spend at least a few thousand dollars on this total, over several years of maintenance time, if you are not the one who is going to be writing the code. Of course, you can reduce the burden on yourself by getting a distro to share the cost, which is why I suggested that first :)

I'll try to respond to each of these:

AFAIK the only component that really relies on logind is GDM. If you don't want GDM and are comfortable using another display manager to launch your GNOME session, that should work fine, although I haven't tested this in a while. You may also be able to launch your session manually the old way, without a session manager, although that will probably require you to use setuid X which comes with the usual caveats. It's probably a total no-no if you're using wayland. If you decide you want GDM and wayland then you still don't need systemd-logind for session management, you can use elogind, or you can grab BSD's patches for consolekit support. The real issue there is that GDM requires some kind of session management, if you want to do this without any other daemons whatsoever, then you will have to reimplement parts of logind/consolekit inside GDM.

With the search services, there is a switch for that in settings under "Search."

With dconf, that is not actually integral to the toolkit. The API that applications use is GSettings, which requires a backend to actually store the settings, and dconf is just one of those backends. You can disable the dconf backend and just use the one that writes ini files to your home directory, or use some other backend. Technically apps can try to force the dconf backend but I've never seen one that does this.

>lest people make the mistake of building stuff on top of it.

This is the kind of hyperbole I'm talking about... As with any open source, you don't have to use the parts you don't want. GNOME as a whole is a pretty big project, and like most projects, some of its parts are stable and up-to-date, and some aren't. Lots of other desktops build on pieces of GNOME technologies because they work, and replace the parts they're unhappy with. So I'm sorry if you feel a particular component made a mistake, but it really does not have to be a mistake that affects you, if you handle things the right way.

Can you be more specific about what kind of citation you're looking for?

I am not saying don't be pissed off, I am saying please channel that energy to help to fix the underlying problems/attitudes. I can give suggestions on how to do this, if you're interested to hear it, so we can maybe have a chance to finally get some issues fixed. Beating the same dead horse going on years now is just not going to help this, regardless of what your perceptions of certain developer's attitudes are. If complaining about lost goodwill was ever a substitute for being persuasive and getting things done and taking initiative to restore the goodwill, it would have worked years ago, and we wouldn't be here talking about this now.

And just to be clear, harassing developers who have said "no I don't want to work on feature XYZ" is never acceptable and never has good results. If somebody says no and is just not interested, we leave them alone and we find someone else who does want to work on that feature.

I just doubt these users are ever going to care about setting up their own snap server, and if they do, they will quickly find out it's not possible and just switch to something else. (For example, plain old Flatpak is in the Debian and Ubuntu repos)

That "must not be so buggy that we refuse to support them" is a requirement for all packages that Debian ships, the difference with the nonfree packages is that if a breaking bug happens, the only real option there is to delete the package until the vendor fixes it.

I don't get the hate directed at snaps. Yeah they're not great, just don't use them. Ubuntu is just Debian, you can just grab packages from the usual Debian repos and use your .debs as normal.

The issue with further publicizing those images is that Debian cannot reasonably offer community support for those nonfree bits. Only the vendor can, or some other company that signed a deal with the vendor. (Canonical happens to be one of those companies)

You don't need to use or install that stuff though, stuff like snappy is totally optional... just like the nonfree drivers.

That's why I said if you plan to install the nonfree drivers anyway :)

IMO, if you plan to install nonfree drivers anyway and don't know or care which ones you need, just use ubuntu.

A goal of Debian (and some other distros) is to have a system that is 100% freely and legally modifiable by the user.

What you're saying is not the only alternative, really what everyone would prefer is if the firmware was just made open source. It's very disappointing that hardware vendors have various reasons they can't do this for older hardware that they don't even manufacture anymore or derive any profit from at all.

To be clear, my request is to avoid rehashing old arguments that have gone nowhere, and stick to providing new information when we can.

I am sorry if I'm being pushy, it just gets extremely tiring to see all the same type of comments for years on places like here and on /r/linux. You don't have to listen to me if you don't want, it's just my humble plea.

Please don't discount yourself like that, by resigning to the usual HN snark. I think you're smart and capable of much more. If there is new, important and relevant information brought to them, they will listen to that. (This applies to most big projects I've seen, not any one in particular. The smaller niche ones that commit to having their small narrow audience are the ones I've seen that tend to be resistant to new ideas)

I don't mean criticism, we (HN users) all have heard all the criticism a hundred times before. I mean actual actionable feedback that someone is able to work with, e.g. if there are problems with the design then we can bring some concrete data that shows new, reliable information. That means taking honest efforts to establish two-way communication where there is none.

I'm asking nicely, can we please not do this? Let's not exacerbate the problems of bad communication by using more sarcasm and hyperbole. If there is some particular thing that can be done to improve areas where there are perceived design proclivities, can we focus on that instead?

>I'm not sure why GNOME screensaver cannot do something like this.

This actually is fixed in upstream GNOME because the screensaver is now built into the shell. The problem here is exclusively with cinnamon-screensaver and other components derived from gnome-screensaver, which is unmaintained and upstream GNOME considers it obsolete.

Unfortunately the KDE wayland session is still somewhat unstable. GNOME's wayland session is farther along in this regard.

If the license is so badly worded that nobody can understand it, it needs to be corrected. I agree you should not hire a lawyer for that, it's not your lawyer's job to fix some other company's license for them. It's a shame that MongoDB appears to have completely lost interest in drafting SSPLv2.

No offense but this advice is rather risky and legally dangerous, please don't tell people to potentially put their products in jeopardy by doing this. The correct thing to do is for MongoDB/Elastic to just clarify the wording in the license.

I don't see how that is an example of ideological reasons, or how that contradicts what I said. It seems like exactly what I was saying -- GNOME, Ubuntu and XFCE all have their own separate APIs for things. I've seen that issue posted here and on reddit so many times and I never understood why anyone considers it any more significant than all the other times a random open source project removed a deprecated API or did an incompatible version bump. Yes, I get it, it's frustrating when upstream is a moving target, but that's exactly what he's saying. You can choose to follow the moving target or you can target a platform that moves slower.

And because I have to keep saying this, that is a non-issue now anyway. XFCE supports the new app indicator protocol, and since Ubuntu dropped unity their support for it is available as a standard GNOME extension: https://extensions.gnome.org/extension/615/appindicator-supp...

Can you please just remove the image? The context is obscure and long gone, and I doubt there is any way for an outsider to see it as anything other than a hateful meme targeted at ruby, given the context of the rest of the memes on that page.

Edit to respond to your edit: please can you commit to removing or changing anything else in your documentation that confuses or angers people? I think you have an understanding that having good quality, accessible documentation is important. So why not commit to having that? It's entirely what documentation writers are supposed to do. It doesn't have to be a full time job unless someone wants it to be, you can do the process of improving things slowly, one step at a time with everyone chipping in. Do you really want things to stop here where some of your documentation pages look like a twitter feed?

And I say this because I think it's somewhat of an inevitability -- over time, someone has to remove the memes and in-jokes. There is no way a newcomer is ever going to understand what they all mean. Yes people can look in archive.org but that's less important than what's actively on the website.

>dbus was Linux only at the time and solving this with dbus would cut off any BSD users from that feature

I'm sorry but this has never been true during the development of wayland. A quick search shows dbus has been in freebsd since 2004, before wayland even existed: https://svnweb.freebsd.org/ports/head/devel/dbus/Makefile?vi...

The problem with creating additional wayland-only solutions is that they tend to need good, strong implementations in the toolkits first for it to really make sense over a dbus implementation that already exists. (The wayland api is not particularly friendly for application programmers) The person advocating for the protocol is usually the one who has to implement that.

How? The Red Hat developers have to follow the same review process as everyone else. If your argument is that contributors with more experience and clout are more likely to get their patches merged, how is that different from any other project? Does it really matter what company they work for? And should we be penalizing Red Hat just because they happened to be in the Linux business for a long time?

The best way in any open source project to make sure a feature is implemented, is to write it yourself and submit a merge request. I don't think any open source desktop is special in this regard, the same rules apply. I am not sure what you're trying to point out by saying that some developers work for Red Hat, the same rules apply to them. If they want features implemented, they write the code and they submit it upstream. What else should happen here? Should they just stop submitting patches and let upstream stagnate?