Desktop name (GNOME/KDE) lazarus / 32-Linux ---------------------------------------------------------------------- kareka · 2020-12-07 02:58 Hai, How to get desktop name in Linux (GNOME/KDE) programatically? Thx. ---------------------------------------------------------------------- Slyde · 2020-12-07 03:46 Try this: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ShowMessage(SysUtils.GetEnvironmentVariable('DESKTOP_SESSION')); You can view the necessary ENVIRONMENT VARIABLES from your Lazarus Menubar. View --> IDE Internals --> About IDE ---------------------------------------------------------------------- kareka · 2020-12-07 06:57 Thank you. On Kubuntu I get 'plasma' On Ubuntu I get 'ubuntu' ---------------------------------------------------------------------- MarkMLl · 2020-12-07 09:04 Quote from: kareka on December 07, 2020, 07:57:57 amOn Kubuntu I get 'plasma' On Ubuntu I get 'ubuntu' Is that what you were expecting, or were you expecting something like the hostname of the desktop computer you're using? MarkMLl ---------------------------------------------------------------------- JuhaManninen · 2020-12-07 10:43 Quote from: kareka on December 07, 2020, 07:57:57 amOn Kubuntu I get 'plasma' On Ubuntu I get 'ubuntu' That is unexpected because 'ubuntu' is a name of a Linux distribution, not a desktop system. Does it use Gnome or the Unity thing? On the other hand 'plasma' correctly refers to KDE Plasma desktop. My Manjaro + KDE has :  DESKTOP_SESSION=/usr/share/xsessions/plasma ---------------------------------------------------------------------- lucamar · 2020-12-07 11:36 Quote from: JuhaManninen on December 07, 2020, 11:43:11 amThat is unexpected because 'ubuntu' is a name of a Linux distribution, not a desktop system. That variable refers to the desktop session name, so it can be almost anything. Ubuntu's of all description (K|X|L|Ubuntu) almost always will have that base name: e.g. in my Xubuntu boxes the session is always called "xubuntu". AFAICT, there is no reliable way to use the environment even to guess what DE you're on. ---------------------------------------------------------------------- MarkMLl · 2020-12-07 13:54 Quote from: lucamar on December 07, 2020, 12:36:22 pmThat variable refers to the desktop session name, so it can be almost anything. Ubuntu's of all description (K|X|L|Ubuntu) almost always will have that base name: e.g. in my Xubuntu boxes the session is always called "xubuntu". On the system in front of me (Debian Buster/stable) I see DESKTOP_SESSION=lightdm-xsession i.e. it's the name of the display manager software associated with the current desktop system. I also see XDG_CURRENT_DESKTOP=KDE and suggest that since XDG behaviour is fairly well standardised it might be a better thing to refer to. Google has quote a lot to say about this, in particular "$XDG_CURRENT_DESKTOP should have been set by the login manager, according to the value of the DesktopNames found in the session file. The entry in the session file has multiple values separated in the usual way: with a semicolon." from the XDG/Portland documentation. The login manager is, of course, what the user authenticated zimself with, which generally speaking includes selecting the desktop software. Apropos the issue of trusting environment variables, one thing I think worth trying is following the PPID chain and finding out which process has defined a particular value by referring to /proc/nnnn/environ. In the case of the system I'm looking at XDG_CURRENT_DESKTOP is defined in the plasmashell process, its parent's environment block is zeroed (but not empty, so it's intentionally wiped it) and its grandparent's is owned by root hence inaccessible to unprivileged users. That technique would be safe even on a multiuser system with multiple active displays, with logged-in users having selected different window managers (AKA desktop environments). MarkMLl ---------------------------------------------------------------------- lucamar · 2020-12-07 14:16 Quote from: MarkMLl on December 07, 2020, 02:54:49 pmI also see XDG_CURRENT_DESKTOP=KDE and suggest that since XDG behaviour is fairly well standardised it might be a better thing to refer to. Google has quote a lot to say about this, in particular Yes, but it's not always there (this Xubuntu 18.04 system, for example, doesn't have it). That's--among other things--why I said trusting the environment isn't reliable. If you google, say, "which desktop environment is running" you'll see lots of answers ... which are almost always full of caveats and problems: they aren't reliable for all distros/DEs, or depend on an external tool which might or might not be there (ex. wmctrl), etc. ---------------------------------------------------------------------- MarkMLl · 2020-12-07 15:04 Quote from: lucamar on December 07, 2020, 03:16:54 pmIf you google, say, "which desktop environment is running" you'll see lots of answers ... which are almost always full of caveats and problems: they aren't reliable for all distros/DEs, or depend on an external tool which might or might not be there (ex. wmctrl), etc. Let's face it, that applies to at least half of the X11-related stuff. I had a brush with wmctrl a few months ago: using it appeared to be the only way of getting a list of what windows are being displayed, which appears to be the only way of checking whether anything (unrelated to the current process) has barfed with an exception or is waiting for a dialog(ue) to be closed. But even though I have a bit of a "thing" about supporting older OSes etc., I feel that by now the XDG stuff is sufficiently pervasive to be required as a prerequisite. MarkMLl ---------------------------------------------------------------------- lucamar · 2020-12-07 16:19 Quote from: MarkMLl on December 07, 2020, 04:04:16 pmBut even though I have a bit of a "thing" about supporting older OSes etc., I feel that by now the XDG stuff is sufficiently pervasive to be required as a prerequisite. I wouldn't call "Xubuntu 18.04" an old OS; it's less than three years old The problem with the "XDG stuff" is that, yes, it's rather pervasive by now but it's not fully agreed on which parts are "mandatory" and which are optional, so you can't really depend on it being fully implemented in any and all distros, whether new or old. Some parts, yes (like .desktop files and "Programs" menus--more or less) but others ... Which is why I feel it's not dependable yet, as Ubuntu (and derivatives) demonstrate. But, of course, that is just MHO ---------------------------------------------------------------------- dbannon · 2020-12-08 00:06 Quote from: lucamar on December 07, 2020, 05:19:44 pmI wouldn't call "Xubuntu 18.04" an old OS; it's less than three years old And, of course, its still officially a supported OS, will be, one way or another for several years. My 18.04 Mate reports nicely - Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i XDG_CURRENT_DESKTOP=MATE Some time ago I researched very many different desktops and did not find any that failed to report XDG_CURRENT_DESKTOP so, IMHO, XUbuntu is an rare exception.  The only xfce VMs I have at present, Debian bullseye and Fedora 31 both report XDG_CURRENT_DESKTOP correctly. Davo ---------------------------------------------------------------------- MarkMLl · 2020-12-08 07:48 Quote from: lucamar on December 07, 2020, 05:19:44 pmQuote from: MarkMLl on December 07, 2020, 04:04:16 pmBut even though I have a bit of a "thing" about supporting older OSes etc., I feel that by now the XDG stuff is sufficiently pervasive to be required as a prerequisite. I wouldn't call "Xubuntu 18.04" an old OS; it's less than three years old I wasn't accusing any specific version of being old... certainly by comparison with some of the stuff I look at on occasion. But by now the XDG stuff is sufficiently widely-supported to be a viable first choice, even if there is some sort of fallback position. And whatever the risks of referring to shell/environment variables, in conjunction with pid/ppid checking they're probably the safest option particularly where a system might be multiuser. MarkMLl