Manjaro Control Panel (ex-MSM-ng)

It should be shown somehow during the update and I’m not 100% sure how it could be implemented better…

Yeah it is shown during the update, correct. The problem is people usually ignore long walls of text or fail to notice one tiny string or warning among other many strings of “updating XXX” and “running hook YYY”.
What MSM does now, for example, it uses Plasma notification system to show a notification if I boot to, say, non-existing Linux kernel v 5.16 (like “You are running unsupported kernel”). I think the same thing should be shown for EOL kernels as well. A GUI thing, not a text in a terminal output. That’s what I’m trying to explain.

1 Like

Yeah.
I think MSM has this feature but it seems it’s semi-broken… Sure this thing will be in MCP with no doubts

4 Likes

Having linux-latest would remove this issue without the need to code it.

1 Like

@LordTermor How far is development on this tool?

Is it possible to test it or still to early?

1 Like

“Kernels” is done more or less but without actual changelogs (needs to be checked how/where from to pull them easier). “Language Packs” is done as well. Other modules need tweaking and MHWD is still in concept only.

1 Like

That would be comical to have Manjaro team bring that back after all the arguing about the need for it to be removed because it was a problematic package for users (from Manjaro Team perspective, not the users, who didn’t want that package as well as linux-lts metapackage to be dropped).

I never understood why it was droped, I was using it and never had issues, as for users that don’t want that package simple don’t install it and let others have that option.

Maybe you can point me out to that discussion, seems I miss it.

3 Likes

If someone spins a package I will happily open any issues I find. :upside_down_face:

I don’t find specific discussion but by searching for linux-latest and/or for linux-lts you could find Manjaro Team members who talk, after the fact, about why they dropped it. I can’t find discussion where I chimed in either on that topic, but I’m pretty sure I talked in favor of keeping these packages back then.

I don’t know, but I think there was posts from philm about it too, and myself too, but google or forum search doesn’t bring anything.

It’s still in stage when I can find issues easily by myself. Will roll out something usable "soon :tm: "

One of the two reasons I switched from Arch to Manjaro - and the primary reason I stay - is the fact that when you use a kernel - you stay on the kernel - you are not rolled from 5.14 to 5.15 to 5.16.

When you use Arch - you are forced to sync your kernel to the next release - there is no let’s see how this pan out and wait the storm out.

When you use linux515 on Manjaro you stay on linux515 until it dies of old age.

You can test linux516 or linux517 but you are not doomed if they fail.

10 Likes

This is also the primary reason why I changed from arch to manjaro. As an example, I use kernel 5.10 on my laptop, but my desktop works better with 5.4.

1 Like

That was what I said, if a static kernel works better for you stick with that, however others having the option of a rolling kernel does not affect people that don’t use it in any way, saying that we don’t need it is just taking the option way from others that do.

Anyway this is more about the control panel and not a kernel dicussion, but adding extra code for something that can be fixed in the source for me is no-sense, but is always up to @LordTermor if he wants to listen to what I have to say or not.

4 Likes

Sorry, my reply regarded reinforcing linux-aarhus argument. It was out of the context of the whole topic. I agree with you. Having a linux-latest package doesn’t affect the choice to keep an older kernel, and it’s easier to implement.

Yep, I agree, but in my post I was presuming that there’s no such option as a matter of fact. Having it back of course would have simplified things, but it’s gone for some I-don’t-remember-what reason.

@LordTermor is magical. The Qt version running on GNOME 42 respecting the “Legacy Applications” (aka Gtk 3) theme:

Please ignore the aardvark icon for Kernels

4 Likes

More screenshots from KDE’s System Settings integration:



Now some minor code clean and MSM’s translation adoption is needed and we will have something to test soon :tm:

10 Likes

Segfault when trying to access ManjaroKernels in the KDE System Settings.

Click to view error messages and segfault
file:///usr/lib/qt/qml/org/kde/kirigami.2/PlaceholderMessage.qml:235:5: QML Heading: Binding loop detected for property "verticalAlignment"
QQmlEngine::setContextForObject(): Object already has a QQmlContext

(process:1915): GLib-GObject-WARNING **: 13:11:43.932: cannot register existing type 'PamacSnapPlugin'

(process:1915): GLib-GObject-CRITICAL **: 13:11:43.932: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed

(process:1915): GLib-CRITICAL **: 13:11:43.932: g_once_init_leave: assertion 'result != 0' failed

(process:1915): GLib-GObject-CRITICAL **: 13:11:43.932: g_type_add_interface_static: assertion 'g_type_parent (interface_type) == G_TYPE_INTERFACE' failed

(process:1915): GLib-GObject-WARNING **: 13:11:43.934: cannot register existing type 'PamacFlatpakPlugin'

(process:1915): GLib-GObject-CRITICAL **: 13:11:43.934: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed

(process:1915): GLib-CRITICAL **: 13:11:43.934: g_once_init_leave: assertion 'result != 0' failed

(process:1915): GLib-GObject-CRITICAL **: 13:11:43.934: g_type_add_interface_static: assertion 'g_type_parent (interface_type) == G_TYPE_INTERFACE' failed
zsh: segmentation fault (core dumped)  systemsettings

And here is what happens if I try to access ManjaroLanguage Packages. It doesn’t crash, but it spits this out:


I have mcp-kcm installed, while manjaro-settings-manager-knotifier was removed.

Zero difference whether or not manjaro-settings-manager is installed.

Please see: