Introducing SystemdGenie

I would like to introduce my new application SystemdGenie. Some of you may be familiar with systemd-kcm, a KCM module I wrote for managing systemd. SystemdGenie is basically systemd-kcm transformed into a proper application. The KCM module format wasn’t really suitable anymore since systemd-kcm had evolved into more than just a simple “settings” utility. Moving to a proper application enabled e.g. having menus and toolbars, but also necessitated a new name.

systemdgenie-1

Functionality

Currently, SystemdGenie has mostly the same functionality as systemd-kcm. It allows graphical management of systemd units including user units. Control of logind sessions is also provided.

Unit files can be easily edited using a simple integrated text editor, which can be accessed from the context or Unit menu.

systemdgenie-3

The main configuration files of systemd, i.e. those residing in /etc/systemd, can also be viewed and edited in the “Config Files” tab. In contrast to systemd-kcm, these files are now edited with the integrated text editor instead of a GUI with validation etc. The old GUI was dropped as it was constantly outdated due the available options and their possible values changing with almost every systemd release.

systemdgenie-2

How to get it

The first development release (version 0.99.0) was released today and the source can be downloaded here. The git repository is found here. Please provide feedback and report any bugs or wishes at KDE’s bugzilla.

Enjoy!

31 thoughts on “Introducing SystemdGenie

  1. So its not integrated in the systemsettings anymore? 😦 thats would be not good. Usually i manage my systemd stuff with this and the best place to look for this *is* the systemsettings. Maybe you could a an systemsettings icon that still starts systemdGenie? Maybe that would be the best.

    Liked by 1 person

    • I also agree that this should be kept as a KCM if possible; particularly considering that KUser and the network configuration were recently eliminated as standalone applications and/or replaced by KCMs (http://www.jgrulich.cz/2016/11/28/introducing-new-kcm-for-network-configuration/ and https://www.kde.org/announcements/announce-applications-16.12.0.php). However, I also understand your reasoning that you need the freedom of a standalone application. This seems similar to how Windows has Control Panel as well as Microsoft Management Console, if you compare KCMs to Control Panel items and standalone configuration programs to MMC snap-ins. I think a simplified version of that idea could be applied here if SystemdGenie merely added an icon to System Settings, as Fabian suggested.

      I don’t necessarily enjoy making comparisons with Windows, but it does have a very significant userbase of system administrators not simply because of monopolization but because it provides a consistent user experience across all its built-in programs. Consistency is good for UX because if a user learns one program, the user will also feel at home with another similar program.

      Please try to avoid the confusion and fragmentation of breaking this into a completely separate program. Thank you.

      Liked by 1 person

  2. Looks very good.
    Would be nice if the config editor had syntax highlighting and syntax warnings.
    What is the difference between the ‘active state’ column and the icon in front of the unit name?
    Could be nice to have description of the most common units.
    Cheers Pascal

    Liked by 1 person

  3. So with the GUI validation dropped, is it now easy to screw up your config with in the text editor? Or is there a parser that runs after editing that can at least validate the syntax?

    Like

    • Currently, there is no parser/syntax checker, so it’s comparable to just editing the unit files in a normal text editor. The problem with the GUI validation was that it often became outdated with new systemd releases, which could result in invalid config files. Hence, it required a lot of maintenance work.

      I’ll look at implementing some syntax checking…

      Like

      • thanks for the reply. Aren’t changes/updates to software the bane of coding “easy to use” utilities that have to put up with? Doesn’t the systemd project have any already coded syntax checking routines you could import?

        Liked by 1 person

  4. I think it would be better to run the external editor while editing the unit/config files. Or at least use KatePart in the internal editor so we’d have proper syntax highlighting and other useful features.

    Like

    • Previous versions of systemd-kcm actually called an external editor when editing unit files. There was however a security concern with that approach as the editor had to be launched with root permissions to be able to save the file. This was the reason for switching to an internal editor so we could use the KAuth framework for proper access control in systemd-kcm 1.2.1.

      I will investigate adding syntax highlighting in the editor.

      Like

  5. I think that editing services should be done by creating dispatcher file at
    /etc/systemd/system/service_name.service.d/override.conf
    instead of editing service file directly. This is how “systemctl edit” command works and compatibility would be a good thing.

    BTW: Is hidpi supported? The old kcm module looks very messy on high res.

    Liked by 1 person

    • Thanks, I’ll look into the dispatcher files.

      Hmm, I thought it was enough to set the Qt::AA_UseHighDpiPixmaps attribute for hidpi support. Do you have any idea how to fix it? On my 15″ laptop with fullHD resolution it looks good…

      Like

      • I have smaller screen and higher res than you, so dpi is much higher.

        It’s not totally screwed – toolbars, context menus looks good. Only unit list are bad (vertical space for each unit is smaller that fonts and icons used so the whole list is extremely tight.

        However the “Config Files” tab is good, vertical space is bigger in this one than in “System Units”, “User Units”, “Timers”, “Sessions”. Maybe you can look why this one is different and fix other accordingly.

        I’m not programmer so I don’t know technicals but for example ksystemlog works good with hdpi: https://cgit.kde.org/ksystemlog.git/

        Liked by 1 person

      • For the “Config Files” tab I set the minimum row height to larger than in the other tabs, because there is a predictable low number of rows. I could just increase the minimum row height in the other tabs, but ideally the row height should scale automatically so the fonts and icon fit. I’ll try to find a solution… 🙂

        Like

  6. I also think that this should be present in systemsettings, at least as link to the application (i.e., when you click on the icon inside systemsettings, SystemdGenie launches).

    Liked by 1 person

  7. Hi Developer,

    I see that you avoid responding to the suggestions to add an icon inside system settings. What is your view on that?

    Like

      • SystemdGenie is OK, but if this is going to be limited to configuring Systemd, it could be called SystemdConfig. Then the name tells you what to expect instead of open the app in order to see what its for. This will be no problem when one gets used to KDE, but for beginners it might be easier.

        Like

  8. Hi, Does this mean that systemd-kcm will no longer be maintained? If so, I am panicked now, because Debian’s Feature freeze sets in on January 5. I haven’t been able todo packaging for the last month, so I am not sure I can make the release window. 😦

    Like

  9. I like the idea of this program. It does kind of give the illusion of the Windows Services Control Panel object, which is nice for new users and/or users who just want to keep things simple. While I primarily use GTK based desktops (MATE & Xfce) for the most part, I don’t mind crossing the streams and using Qt programs…as long as they don’t require installing the whole kitchen sink of KDE’s dependencies. Personally, I would like to see this program be desktop agnostic, but maybe detect which desktop(s) are installed on the system and set links in their settings panels accordingly.

    But here I am making a request thought in the comments of this blog, which is totally my original next thought.

    Wouldn’t it be easier to manage feature requests by using GitHub’s issue tracker? Most people have GitHub accounts now. 🙂 I would probably get mixed up or forget about requests in a blog post comment section…but if they were on a public facing tracker of some sort, there would be some way to manage/merge/deny requests. I hate to say it, but KDE’s bug tracker isn’t the easiest to use, though I do fumble my way through things eventually.

    Like

Leave a comment