What's the difference between a graphical shell and a desktop environment?
I keep hearing how
GNOME 3, KDE Plasma Shell and Unity are shells.
and how GNOME 2, XFCE and LXDE are desktop environments.
Is it that the interface is the Shell and all the rest of the software is the desktop environment, if this where true wouldn't that make GNOME Panel a shell?
"Desktop environment" (DE) is the whole shebang. The "desktop shell", on the other hand, is just the bit that provides the background, task-bar, desktop icons, desktop context menus: generally the "home" interface for a particular DE. (The functionality/scope of the shell can vary greatly as well as include and/or overlap the roles of a Window Manager, especially in an X-based system.) The "shell" for Windows is "explorer.exe" but Windows itself is the "desktop environment".
Generally file managers, like Nautilus, are not [desktop] shells: e.g. they can [often] be run without the standard "shell" (or with a different shell). However, it is quite possible that a file-manager acted as a shell. In the case of [modern] Windows the same executable is used for both the shell and the file-manager, but perhaps hosted in a different process, and yet it serves a different purpose in both roles. (Windows 3.1 had a separate FileMan program.)
Happy exploring.
Desktop environments, such as Explorer, ARE graphical shells because they provide an interface for users to access the services of the kernel.
Related
Recently switched to new windows terminal, and after hours of searching on internet I was not able to find anything helpful, all what I want is to set up cmd inside new windows terminal to show git branches just like it's achievable for powershell.
eg like this
I have been very comfortable with cmd especially with its ability to use additional linux commands and don't wanna switch to powershell only because of nice displays of git branches. this is a source where everything is nicely explained for powershell, all I want is to do the same for CMD.
thanks in advance
In order to use Oh My Posh for shell-prompt customization from cmd.exe, the legacy Windows shell (citing from the docs (tab cmd)):
There's no out of the box support for Windows CMD when it comes to custom prompts. There is however a way to do it using Clink, which at the same time supercharges your cmd experience. Follow the installation instructions and make sure you select autostart.
As you later discovered, this issue on GitHub has background information on why native cmd.exe support isn't possible (even though Oh My Posh is generally shell-agnostic) and why third-party software is needed to make it work.
As for your comments re preferring cmd.exe:
I have been very comfortable with cmd
Migrating from the shell one is used to a new one is undoubtedly a painful transition, but well worth considering in this case:
While not without its quirks, PowerShell is vastly superior in just about every respect to cmd.exe, and enables you to do things you simply cannot do in cmd.exe
its ability to use additional linux commands
Linux (WSL) commands called from the Windows side are all mediated via executables (notably wsl.exe and bash.exe), which you can equally call from PowerShell.
What's the difference between using an Ubuntu tab on Windows Terminal vs using the Ubuntu app for Windows (ubuntu.exe)?
I've only noticed that each start at a different directory:
WT: :/mnt/c/Users/username
Ubuntu: /home/username
There are many differences between using an Ubuntu tab on Windows Terminal vs using ubuntu.exe on it's own:
Both are terminal applications that use 'Console Windows Host' (conhost.exe) however Windows Terminal is superior in features, is open source, has many improvements over 'ubuntu.exe' (and wsl.exe) and Windows Terminal utilizes two additional programs when it is run, OpenConsole.exe and windowsTerminal.exe.
These two programs OpenConsole.exe and windowsTerminal.exe are what makes all the new features in Window Terminal possible such as configurable starting locations, custom color schemes, full color support and much much more. There is a little history as to the origins of Windows Terminal and what I am talking about here.
ubuntu.exe and wsl.exe on their own (with plain old conhost.exe) are really just here for backwards compatibility at this point.
Before I knew about the remote WSL extension for vscode, I had been using bash in it by selecting it as the default shell from the terminal option. What is the advantage of using remote WSL if all I wanted was to just use bash as the default terminal?
Hi Rohan and welcome to SO!
I'll have a shot at answering this, though someone more knowledgeable might have better insight.
When you load VSCode in windows, it accesses your various PC resources as windows resources. For example your files will be from the windows folder structure. Even if you use WSL bash as your terminal, VSCode is still acting on a windows basis.
If you use the remote WSL extension, it leverages VSCodes separation of UI and Backend by remotely starting a VSCode backend in the WSL layer, and connecting the windows UI to that backend ('remotely' although on the same PC). Due to running the backend in a linux environment, the files are loaded as linux files and handled via the WSL system, rather than normal windows access.
With regard to the question 'What is the advantage?' I would suggest the advantage is that now instead of having a split between VSCode in windows and command line in WSL, you now have both acting in harmony through WSL. It should provide some benefits (especially when WSL2 hits properly and performance increases) around things not messing in a windows manner on files you are trying to use in a linux way, and just make things feel a bit more connected.
However if you're using WSL bash just as a command line replacement and not using it for it's linux goodness (though I don't know if this would be the case), there may be less of an advantage.
It's a stepping stone to switching to devcontainers, which are really neat.
This page might help more, but that's my understanding! https://code.visualstudio.com/docs/remote/wsl
I'm trying to use a custom font in a Tcl/Tk GUI, running on Windows.
I don't really want to install the font system-wide (as this would require admin privileges), so it seems that I need to somehow use the AddFontResourceEx function, to register the font (temporarily)
Now there are a few complications:
needs to be able to run with Tcl/Tk 8.5
must run (at least) on W7 to W10
pure Tcl/Tk solution (no binary extension; any solution must be self-contained with a Tcl/Tk interpreter and with whatever interpreters a pristine W32 installation comes with)
no admin privileges on the deployment machines
no user interaction
So I was thinking on using a VBS script that would do some magical incantations to call AddFontResourceEx. (Originally I though of using a Powershell script, only to discover that Powershell scripting seems to be disabled by default for security reasons)
I'm not much of a Windows person (less so a VBS person), so I wonder, whether it is even possible to register a font with VBS in the way I envision it.
If so, how?
Or are there easier way to register a font from within Tcl/Tk (or a shell).
You can try the extrafont package:
https://wiki.tcl.tk/48903
This package will load external fonts without requiring them to
be installed on the system.
I am developing a cross platform application that needs to auto start upon user login (not system start). What are the common locations/methods in invoking auto start for Windows/Linux.
For example, are the Windows registry locations for auto start compatible across all versions of windows (XP, Vista, Windows 7, etc).
And what about Gnome, KDE?
I am looking for the most general method which will work across many versions of Windows as possible.
For Windows, the easiest way is to put a shortcut in the Startup folder in the Start menu. Not very sophisticated but you have no worries about compatability.
For gnome, ".desktop" files can be placed in ~/.config/autostart/
here's a sample, ~/.config/autostart/glista.desktop:
[Desktop Entry]
Type=Application
Name=GLista - Simple todo list manager
Exec=glista
Icon=system-run
Comment=
Name[en_US]=GLista
Comment[en_US]=Super-simple to-do list manager
X-GNOME-Autostart-enabled=true
By the way, the interface for managing startup applications can be found on the "System - Preferences - Startup Applications".