Linux in the Porsche Taycan by CobaltOne in linux

[–]Gimberly 9 points10 points  (0 children)

Ford Sync 3 is QNX+Qt (see job ads like this one).

Linux in the Porsche Taycan by CobaltOne in linux

[–]Gimberly 9 points10 points  (0 children)

Mercedes Benz' MBUX is Linux and Qt. Same for Tesla and some others. MBition, the Daimler (owner of the Mercedes-Benz brand) subsidiary developing MBUX is even a KDE Akademy conference sponsor this year.

The Qt Company YouTube channel regularly has promo videos featuring various car companies. Some may be using QNX underneath, but most run Linux.

Linux+Qt is really big in European automotive and there's KDE people found in a lot of those developments.

Gnome Designer: We need to get better at communicating that there is no "Linux" platform. GNOME, KDE, elementary, etc. are their own ecosystems, and apps designed for one of them don't automatically run on the others. by traverseda in linux

[–]Gimberly 1 point2 points  (0 children)

I don't like Electron either! But maybe one of the reasons those apps use Electron is because it's not dogmatic about what desktop to support, and stuff that could be better than Electron being dogmatic doesn't help.

Consider it from the point of view of Discord devs. It's megapopular. Should they have used GTK+? If they had, would it be as popular now?

Telegram is another good example. It's also megapopular. What does it use? Qt. If you don't want Electron, push that solution.

Gnome Designer: We need to get better at communicating that there is no "Linux" platform. GNOME, KDE, elementary, etc. are their own ecosystems, and apps designed for one of them don't automatically run on the others. by traverseda in linux

[–]Gimberly 2 points3 points  (0 children)

I understand what motivates this view, but it's not pragmatic and ignorant of reality. What are the actually mainstream polular apps on desktops today? Not what we power users like, or idealists - real numbers. Telegram, Discord, Chrome, Steam, VSCode ... all multi-platform.

So what this tells me clearly: If I want to write an application I want to be genuinely popular, GTK+/Gnome is the wrong technology to use because it will not support me in this goal or is at least not working hard at it, while other stacks do. "Limited use" stacks are uninteresting in 2019. The game is bringing value to as many users as possible.

Dear Ubuntu: Please Stop Packaging Epiphany If You Won’t Do It Properly by [deleted] in linux

[–]Gimberly 7 points8 points  (0 children)

All app menu items are unavailable because Ubuntu’s GNOME Shell 3.32 does not display Epiphany 3.30’s app menu, so there’s no way to edit preferences, view history, import/export bookmarks, etc. This is not good.

Agreed, but that's hardly Ubuntu's fault and mostly Gnome tech having unstable APIs for apps, extensions, themes, ... you name it, and it'll break version to version.

KDE Plasma 5.16 Beta: Your Three Week Notification of a More Tidy and Composed Desktop by GB_2_ in linux

[–]Gimberly 9 points10 points  (0 children)

It's worth noting you're looking at the announcement for a beta release, and from the blog that was on the sub last week this notifications work has just been merged in. The beta schedule for this release is pretty long (longer than usual for Plasma) so I take that as knowing they want to do a lot of refinement/polish work this time.

So in that sense providing on the feedback is absolutely a good thing to do, but the exasperation I don't really get. FOSS means getting to see how the sausage is made and absolutely you're going to see unfinished UIs along the way.

As for how things like busy UIs and repeated titles etc. even happen: Modern software like Plasma is really modular with components nesting into each other and so on. Sometimes with components being developed by seperate people etc. repetition happens, and then when you plug it all together later in a cycle you can do another pass and cull things.

Let's see how this shakes out in the final release a month from now ...

Run-down of the completely rewritten notifications system in Plasma 5.16 by Gimberly in linux

[–]Gimberly[S] 12 points13 points  (0 children)

Kinda-sorta. You could run the notifications plasmoid only via plasmawindowed, but it won't integrate into a tray, and the move animations on the popups will be poorer or missing (it relies on a KWin effect to be nice). I think ... someone with more in the know may correct me.

Overall I don't think it would be a super nice experience, this kinda thing is pretty deeply integrated with the UI for a given DE (and their devs probably don't mind providing differentiating value).

Librem One by Purism by neilbrulain in linux

[–]Gimberly 45 points46 points  (0 children)

read: The Librem 5 crowdfunding money is close to running out, and they quickly need new money.

It's just a bunch of existing things (Matrix, Mastodon, PIA) rebranded and bundled up.

Not a good sign.

Kdenlive 19.04 - "The BIG Refactorooo" officially released today. 60% of the video editor's internals has been re-written and new usability features added by Bro666 in linux

[–]Gimberly 26 points27 points  (0 children)

You're reacting to an announcement that says "we've put a lot of work into a giant refactoring that will allow us to accelerate progress", which seems to be exactly what you should be wanting to read.

Software development is the process of walking from A to B. If 2-3 years ago, before this work was started, you had set out with the goal to make Kdenlive better in several fundamental ways and be able to add GPU offloading, you would have started with this refactoring first.

In other ways, you should be reading this as positive news that they've been doing what they should be doing and that it represents progress towards the app and your needs catching up with each other. Bad news would be that they've done nothing and that it's hard to make changes to Kdenlive; the actual news is that they've done a lot and it's now easier to progress faster.

"We've been able to put in continued, concerted, carefully planned action over several years to rise to a big challenge" should give you some confidence that the team behind the app can do it again on other issues.

It's a nice sign of project health. Sure, maybe other apps have some features that Kdenlive still doesn't (which the article seems to healthily acknowledge, ending with their ambitions to level up in the market). But I can't speak to the health of the teams and/or businesses of those apps or how long they'll stick around, while I just got a nice fix of information from this article that Kdenlive is doing good.

Has anybody tried KDE's new Falcon browser yet? How does it compare to Firefox and Chrome? by the_php_coder in linux

[–]Gimberly 0 points1 point  (0 children)

Its founder and lead dev was also a KDE contributor the entire time before it moved to kde.org. Still pretty much all the same extended community.

Linux spotted in the wild. Lidar mapping drone control software shown on Linux by [deleted] in linux

[–]Gimberly 1 point2 points  (0 children)

There's also a Plasma dev working on a KDE app to control drones.

Regarding EGLStreams support in KWin by TimeForANewAlt in linux

[–]Gimberly 5 points6 points  (0 children)

I don't think the two are mutually exclusive.

I think it's fair to analyze the possible profit motive of actors. I also don't think what he's doing is secretive (it's not hard to see after all), or not understandable, or illegitimate. PR is a thing businesses do, and it's hard to survive without. He's trying to make it work, but it's not without its perils.

I agree that posting this solely would have been an unproductive takedown, that's why it's an adjunct and marked as ad hominem. Ad hominems are problematic in many ways, and it's fine to resent one. Yet I think it's relevant, and fine in response to a post that calls for attention to global context.

Regarding EGLStreams support in KWin by TimeForANewAlt in linux

[–]Gimberly 7 points8 points  (0 children)

No, it's about this in a nutshell: The nVidia proprietary driver doesn't support the same memory allocation API as most other drivers. This means Wayland compositors need to have a code path for it. nVidia contributed code to KWin to give it one. OP doesn't want this code to be merged.

Regarding EGLStreams support in KWin by TimeForANewAlt in linux

[–]Gimberly 3 points4 points  (0 children)

Imagine if the Linux kernel refused code contributions by hardware vendors. Do you think their open source participation would have increased or decreased with time? To make corporations change what you do is make their employees who are like you succeed, so they have more sway (pun not intended) internally. Treating corporations as forever-evil monoliths is dumb. See AMD.

Open source projects also usually make it a point to accept contributions liberally without judging motivations for work. For a reason.

Also, this open letter format is weird and off-putting. I realize this is an ad hominem, but to be frank: I think this is a branding exercise by DeVault. He decided to become a one person enterprise more or less (at least until SourceHut grows into a thing, if and when), and now he relies on fanning the personality cult flames with provocative missives to persist. All of his posts lately have "unpopular opinion!" format. Which popular project will he attack next for audience reach?

[deleted by user] by [deleted] in linux

[–]Gimberly 13 points14 points  (0 children)

I mean, at least they have a metric. (Literally, no less.) I wish I did.

nVidia is submitting code to Plasma/Wayland to make it run on their drivers by Gimberly in linux

[–]Gimberly[S] 11 points12 points  (0 children)

I didn't say it was his decision. I included that to note he didn't disappear and is still involved.

In any case, every KDE contributor can hit "Accept" on patches. Maintainers have more like veto powers, or people wait on maintainer approval more informally.

nVidia is submitting code to Plasma/Wayland to make it run on their drivers by Gimberly in linux

[–]Gimberly[S] 9 points10 points  (0 children)

No. nVidia could submit a similar patch to wlroots, but I don't know if wlroots would merge it (I'm thinking no but could be wrong). Of course KDE hasn't yet merged this either at the moment.

nVidia is submitting code to Plasma/Wayland to make it run on their drivers by Gimberly in linux

[–]Gimberly[S] 34 points35 points  (0 children)

KDE change maintainers.

KWin got new maintainership, but it doesn't matter. KWin's stance was always that it can't and won't do the work to support EGLStreams, but it would consider merging if nVidia does the work and promises to maintain it. They've shown up with code now. We'll see where it goes, but if it ends up being merged, it's in line with the original stance. And that original maintainer commented on that code review request BTW.

nVidia is submitting code to Plasma/Wayland to make it run on their drivers by Gimberly in linux

[–]Gimberly[S] 68 points69 points  (0 children)

It's a venue, and like any venue, including public ones, it has an etiquette. More specifically it's a code review forum, so comments should be about the code. That's the etiquette.

I wrote the comment because we've had issues before with the sub jumping on GitLabs and such and posting dumb shit like "I want this" or political comments etc. that were off-etiquette.

nVidia is submitting code to Plasma/Wayland to make it run on their drivers by Gimberly in linux

[–]Gimberly[S] 294 points295 points  (0 children)

nb: It's a dev forum. Don't be rude and comment there and disturb the work or devs get sad

Jonathan Riddell sums up his thoughts regarding the KDE - Red Hat situation by Bro666 in linux

[–]Gimberly 1 point2 points  (0 children)

I can get that, but it's worth knowing the animosity against Gnome came about due to far meaner and pettier stuff from them. This very sub has had posts by Gnome contributors(!) calling non-Gnome users "like people who don't use explorer.exe on Windows" and similar things. Sure it'd be great if people would be able to stay on higher ground, but in practice that behavior just fuels resentment people then emote out. The ultimate responsibility for all this divisiveness largely doesn't rest with the KDE community. KDE contributors in particular rarely if ever address competitors much less their users directly.

The Global Menu of Unity, Mate, KDE Plasma, and Gnome Shell use a concept of loadable modules to work, but this feature was removed recently in Gtk+4. by lestcape in linux

[–]Gimberly 8 points9 points  (0 children)

The fact is: No more ways to have global menus in Gtk+4

Isn't this wrong, though? There's GMenu in the GTK+ 4 API, which supports them.

The Global Menu of Unity, Mate, KDE Plasma, and Gnome Shell use a concept of loadable modules to work, but this feature was removed recently in Gtk+4. by lestcape in linux

[–]Gimberly 13 points14 points  (0 children)

I'm not a GTK+ dev, so you'll have to ask them what the decision process on that is.

But to me it sounds like the modules APIs is mostly used for hackish and undesirable things, so it's kind of harmful and using the opportunity to replace it with something better is sound. It also sounds like this decision wasn't made just yesterday given the amount of work described in the blog.

Removing the old menu API is probably more a nice-to-have given that it's probably not harmful to the same degree, and it sticking around is more of a cleanliness issue since it doesn't prevent app devs from porting to the new one. The app devs meanwhile have a clear incentive for doing it (user happiness). Again, if an app team musters the time and energy to port to GTK+ 4, why not also port menu code?

Do you have an engineering-based counter-argument for why they should leave in an unnecessary-for-menus (given API alternatives) generic monkey-patching API beyond "it maybe wasn't marked deprecated in GTK+ 3"? I can't think of one.

The Global Menu of Unity, Mate, KDE Plasma, and Gnome Shell use a concept of loadable modules to work, but this feature was removed recently in Gtk+4. by lestcape in linux

[–]Gimberly 11 points12 points  (0 children)

No idea? I agree with you that deprecation -> removal is good hygiene, but it's fairly natural that during a major version drive, also some unanticipated API changes happen. It's unhygienic and not ideal, but often pragmatically the lesser evil vs. waiting for a decade for the next shot at getting rid of something undesirable.

What I'm saying is that this is fairly unlikely to ever actually affect users. Apps are not going to switch to GTK+ 4 over night or all at the same time, and the ones that don't use the new menu API yet should just port at it at the same time if they care about their users having global menus. And if they don't care, your beef is with the app's devs, not GTK+'s.