Miscellaneous module mockup (PulseAudio settings should be moved to the separate module ideally but it’s just a mockup after all)
Feature Request
On the left side, add an item to execute the Desktop Settings (i.e., xfce4-settings-manager), so the user can always start with MSM and get to all settings without revisiting the main menu to find and open the Desktop Settings. This would go along with your tight integration philosophy.
GUI component speaking-wise, how do you refer to the left side? Is it a panel and “Hello” is an item or link?
MSM modules will be integrated to DE settings (for now only for XFCE and KDE, GNOME later).
Panel (or side menu) and item, yes.
Cool! Thanks.
Hi!!
I would like to suggest, if it’s possible, including a tool similar to gnome-firmware:
It could be really useful…
Regards.
Linux Driver Management module is still in planning state but I think it should perfectly fit there.
Disabling pcspkr feature added to git
@Ste74 I think this seems something we could throw into the gnome edition?
Why not… this function is also provided by gnome-software but in our case we mimic gnome-software with pamac… i have look at this app some time ago when the project started and i was interested on it already. The only negative note is: not support for all manufactured but this is the problem of fwupd …
https://www.archlinux.org/packages/kde-unstable/x86_64/qt6-wayland/
It looks like QT6 will soon be a thing. Will you recode the frontend in QT6 in the future?
There are not to much things to do in order to get it working. API changes between 5 and 6 are not so big. But I will do it only after Qt6 release.
Ok I know it’s been a while but I’m back to this project and plan to finish KDE/Qt version in the beginning of 2022.
Here are screenshots for drafts of new MHWD and Dashboard modules:
And a draft for changelog in Kernel module:
Also as you might noticed application is renamed to Manjaro Control Panel (MCP) and also will support loading of legacy pages for some time during the transitional period so these modules will still be available for those who needs them.
Hello LordTermor, could you give more detail about the target for Manjaro Control Panel?
Looks like you are redesigning the Info Center, don’t know if this is a GUI just to give user information, or if it can be integrated with maintenance tools as you were suggesting.
As information, would be nice to have an indication for the main parts of Linux, not only restricted to Sound server or display server, but also:
- Init Software
- Based on Linux Arch/Debian/Suse (it helps new users to find help)
- GPU driver version / Mesa (maybe more gamers are coming to linux)
- Others
I think your focus is more oriented to the OS Manjaro but also like a lot to use the software CPU-X, it gives user very good and useful information about the hardware, I think it became standard to use this kind of software, so it could be part of standard installation, don’t think it will bloat the installation and why not integrate it to MCP?
MCP is a tool to replace old Manjaro Settings Manager so will allow to do tasks such as Kernel/LanguagePack/etc management.
Dashboard module is new to MCP and overlaps with KInfoCenter a bit but is aimed to provide more system basic information and some help notifications.
Yes, I plan to support/work only on Manjaro as it’s in core depends on pamac
library and our repository’s kernels and other things.
Is not easily integratable into MCP and I honestly don’t see any reason for such in-depth information to be in system settings rather than a separate application.
So, the ability to set things related to maintenance perfectly fits the target once it replaces the Manjaro Settings Manager.
I would enjoy a lot if you can add as many options as possible.
It’s very wise for a developer to define were any information needs to be set up. Central place? fragment places? redundant places?
Due to the modular philosophy for linux I see the tendency of fragmentation and command lines, but if a system like Manjaro can do something for integration like central places and GUI, it will benefit a lot of users, mainly the ones that don’t know or don’t care how linux works, they only needs easy way to use their personal computer. I’m using Manjaro/Linux, less than 1 year and I can’t differentiate the Job Manjaro does from the Job Plama team does in terms of system integration. I think from users perspective all the requests will come to Manjaro, and Manjaro team manage with other teams.
Let me use car for instance, if you have a car from specific Brand and if you have problem or suggestion, you will contact the dealer for that Brand, because that Brand integrate the whole system (CAR), think about going in the dealer and they saying to you:
The audio is not our responsibility, please, contact Siemens
The tire is not our responsibility, please contact Goodyear
The driveline is not our responsibility, please contact Dana
Customers expects that who integrates the system will response for all the system, and manage things internally. I added this because someone already asked me to open thread to KDE.
Regarding basic information, you maybe could do a survey to identify for different users what they understand as basic information. Sometimes people buy pre build PC and want to know/confirm what hardware they are made, ordinary people may don’t need too much detail about the hardware but CPU model, motherboard model and others are basic. Additionally, if my Ethernet/wireless works with 4 different speeds, what is the current speed of my network? if I mouse-over at the network icon in the system tray I can’t see my current speed, I need to click on it, click to drop the menu and then click in details. It may worth to have this information redundant in the MPC.
Why not use the KDE Notification area in the system tray for notifications? fragmenting notifications to the MCP will benefit the user experience?
They are not notifications but a list of potential issues. Notifications could be sent when there is something new in that list for example.
Hey Artyom how about implementing a regular automatical check for the presence of EOL kernels and notifying user if found any? Something that would decrease a number of reported issues related to old dependencies and so on? Similar to what MSM does now when it sees a custom kernel built by user (that’s what I personally have seen before).
I’m not sure how kernel version update notification can decrease dependencies issues, kernels are not quite related to the userspace system. But of course, support for EOL check will be there for sure as well as custom kernels detection.
I mean to notify people about EOL kernels they need to delete to prevent such “issues” from occurring:
It should be shown somehow during the update and I’m not 100% sure how it could be implemented better…