Icon themes modifying the developer-provided icons was always a strange thing to me in many Linux distributions.
Even often hard or hidden to disable this behavior.
My workaround already was using Breeze, since it does the least modification compared to other themes available by default. Glad to see it continue in this direction.
Well, the point of custom icon themes is, you know, customize an icon theme.
That being said, it's expected the default icon theme does little to nothing about customizing a third party icon. When I was involved (briefly) with the KDE VDG back when 5 was about to be launched I proposed a icon style that looked completely different of what Breeze looks right now - maybe something in between of what Oxygen looks like and Breeze looks like. But Jens Reutenberg told me it couldn't go in that direction since they needed to ship certain icons "as-is", like the Firefox one, so it was better to do something that could fit anything so those "special" icons wouldn't look out of place.
Some people like to diss on flat/minimalism styles but for some situations there is a reason they look that way.
It takes me at least 3 times as long to find what I need with these minimalist monochrome icons, though. I always opt to the more colorful ones, if possible.
Can't you just right click an icon, set it to whatever you want (including the original one), and then lock it so subsequent theme changes won't change it? DE people are moving in all the wrong directions :/
The submission title makes it a bigger deal than it is, the article clarifies that "The team reasoned that overriding another developer's branding is rude, and it also lacks the resources to maintain the icons as branding changes over time." and "Anyone who misses the old look is welcome to create a new icon theme and upload it to the KDE Store.". Nothing has really changed, especially not newsworthy.
I meant independent of this change about monochrome icon sets in general. Like in settings dialogues the menu on the left side. I'm fastest just going by the colors before I have parsed anything else. But yes, also the same applies in the context menu -> open with. So I welcome them not replacing the original app icons with monochrome ones. At first I read the news the wrong way around.
As I understand it from reading the original post, they are leaving the third party apps default icon. They're not overiding with monochrome icons. Bad title by a probable AI rewrite, please read the original KDE blog post linked elsewhere in the thread.
This is KDE's decision on their Breeze theme. Distributions can ship the icon set with third party icons if they want.
Some of the proposed solutions are problematic. A public transport systems absolutely needs to be reliable for the people who use it.
Skipping stops is the worst in that regard and breaks the whole point.
No schedule causes issues downstream, since now there won't be a schedule to depend on when needing to switch to trains or other busses.
But in general, the only thing to realistically improve without decreasing reliability is the amount of time spent at a stop (also mentioned in the article).
All in all, I see these suggestions as "what to do in a worst-case scenario", i.e. if the service already has major issues.
No-schedule works fine if (and only if) service is sufficiently frequent, say every 5 minutes. The overwhelming majority of intra-city trips will have 3 transfers or less in a well designed bus network and when planning to catch a less frequent service, it's acceptable to bake in a 15 minute safety margin.
Is someone going to regularly take a trip that requires them to take 4 buses? I largely avoid trips that would require even a single bus transfer (admittedly, the Boston bus system is pretty terrible, meaning bus transfers are daunting when contemplating trips).
Yeah, 4 buses sounds terrible. I already don't like it when my trip to that one fancy office is bus-metro-tram instead of just bus/tram and metro. I would totally hate if buses in question were overcrowded, smelling hobos and not having a schedule.
Is this the usual European supremacy propaganda? Yes, of course it is.
Here in Graz, Austria, if nobody wants to get off at a bus stop and nobody is there waiting for the bus, it continues right on to the next stop. It all seems to work, somehow.
If the expectation is that the bus will stop at every bus stop in its path.
Vs. a larger system can easily have "commuter", "direct", "express", "park-n-ride", and other busses, with different expectations.
Plus the trivial case - the bus will roll past a stop which has 0 people waiting for a bus, if no current passenger has pulled the "Getting Off at Next Stop" signal cord.
Depends. If the timetable is packed or the buses are already bunched, skipping a stop is actually preferable - unless you want to hop off at that stop, too bad then! ;)
This is one of the things I find infuriating about the Subway in NYC.
There are local trains and express trains. Often, you'll have to wait on the platform for an extra ~10 minutes for a local (v.s. getting on the first available express).
Then partway through the journey, they'll declare that the local needs to go express to make up time. You'll be kicked off and told to wait for the next train.
To make matters worse, the next train is usually in the same predicament, so you end up waiting indefinitely (or giving up and finding another way home).
Sounds like a dark pattern to push people towards express. If the train changes how fast it moves or where it stops, that's their problem. The passengers should be allowed to get off at the nearest stop to their original destination, and any potential difference in fares should be eaten by the operator
I was confused by the legends between the first and second image?
Both have p=2 and p=4 yet look different, I believe that this is wrong, as the sentence before the second image states "increasing p". Hope I'm not missing something
> Although the survey is not statistically representative of Nature readers or the scientific community at large
I found that the survey seems to have been advertised for with "Has Bluesky replaced X for scientists?" according to this article from Jan 14 [1].
This attracts people who switched more I think.
So the 70% figure is nothing than hot air.
It is still interesting seeing the positive sentiments and reasons for switching analyzed.
You are generalizing. Google and big providers do that, usually (US)services that need to cater to the whole world.
But a huge part of the normal web still uses and _needs_ preferred language. No one wants to be forced to use geolocation.
Just one very common example are info pages for sightseeing, they are usually available in all languages that people commonly visit from and just work if you browse to them. Not to mention that geolocation would be useless anyway in that case.
It would be nice if Google actually used the preferred language. They don't give a shit. I'm still getting maps and other stuff in local language based on IP.
Yep. So much for "built for the web".
While I know that a lot of software is only tested on Chrome and Safari, I would expect different when marketing as being web-based.
Thought the same.
It is clear that this presentation is definetely biased towards showing the problems of standing workers, as there haven't been any negative options about sitting presented.
Unfortunately, while medically known and even legislated (forced breaks), problems of sitting workers are still widely ignored (often by themselves too) until too late or trivialized.
Can anyone explain why there wasn't any BGP activity on the Finland-Germany systems when the cable broke, while for Lithuania there was a massive spike?
Unfortunately it's been a long time since I learned about BGP, if anyone could help out here I'd be grateful.
Each BGP hop represents an ISP so when an ISP reroutes traffic internally there's no need for changes to external BGP announcements. Clearly ISPs in the Baltic region have multiple paths and don't depend on any one cable.
And project specifying "requires python 3.X+" instead of Version X to Y is also a major culprit I often encounter.
Most of the times it will not work with the newest shiny python, which I only notice after already installing it and then having searched search the Github issues.
That happens to me all the time. It helped cement my habit of binding the python version to the project with direnv and a flake.nix so I end up switching to the right version when I cd to the project dir.
My workaround already was using Breeze, since it does the least modification compared to other themes available by default. Glad to see it continue in this direction.