According to announcements you need to add the corresponding Plasma Widget or the menu button from "Window Decorations" settings.
Global Menus have returned. KDE's pioneering feature to separate the menu bar from the application window allows for a new user interface paradigm, with either a Plasma Widget showing the menu, or with the menu neatly tucked away in the window title bar. Setting it up has been greatly simplified in Plasma 5.12: as soon as you add the Global Menu widget or title bar button, the required background service gets started automatically. No need to reload the desktop or click any confirmation buttons!
Step by step instructions:
From the Application Dashboard/Launcher/Menu, select "Settings" (in the Launcher: under "Applications") → "System Settings" → "Application Style" → "Window Decorations" → "Titlebar Buttons"; then drag and drop the "Application menu" icon to the titlebar.
I hope I have understood your question correctly. I assume the icons you are talking of are those of the tabs in the "Task Manager" widget of KDE Plasma's Panel.
It looks like your question has an answer on askubuntu. There, the question mentions Ubuntu and Gnome, but the answer does not make use of any specific feature of a desktop environment or Linux distribution. I tested it on Arch Linux with KDE Plasma 5.14.4, Firefox 63.0.3, X.Org X Server 1.20.3.
It boils down to a couple of edits to your .desktop
files:
1) Add the --class
option to the Exec
key. It is briefly documented on MDN:
--class=WM_CLASS
Set the WM_CLASS resource class of the X11 windows created by the application.
2) Add the StartupWMClass
key. It is briefly documented in the Desktop Entry Specification by freedesktop.org:
StartupWMClass
If specified, it is known that the application will map at least one window with the given string as its WM class or WM name hint (see the Startup Notification Protocol Specification for more details).
With these two options, each instance of Firefox is given its own WMCLASS
, so that instances are not grouped together in the "Task Manager". The StartupWMClass
sets a link between open Firefox windows and the desktop entries that launched them, letting them keep their custom icons.
To provide an example, assuming your two .desktop
files as the starting point and omitting the lines that are not relevant here:
[Desktop Entry]
Comment=First Profile
...
Exec=firefox --no-remote -P test1 --class=firstclass %u
...
StartupWMClass=firstclass
[Desktop Entry]
Comment=Second Profile
...
Exec=firefox --no-remote -P test1 --class=secondclass %u
...
StartupWMClass=secondclass
Best Answer
My personal opinion, based on some reverse engineering I've just finished on this subject, is that, with all due respect, KDE developers did a big mess here.
In a fit of oversimplification, the option you mention is no longer available. The global menu is now automatically enabled when you place a global menu applet in a panel or add the menu button to the window decoration in Buttons tab of the Window Decorations module.
Otherwise the global menu should be automatically disabled, and the classic "In Application" Menu Bar used instead.
With some exceptions.
But other applications, such as Ark, KMenuEdit, Muon, Okteta, KHelpCenter, just to mention a few, when you use the application menu button or the global menu applet at least one time, remain in this state even after you remove the application menu button or the global menu applet, with no access to the menu whatsoever. It seems a bug to me. For such kind of application, you have to manually edit their configuration file (when the application itself is closed, of course). You'll find them in the ~/.config folder. Search by the application name. For Ark, the configuration file is:
~/.config/arkrc
There change
with
This restores "in application" menu (but remember to remove any global menu applet and the application menu button from the window decoration before!)
In addition to the rules above, other applications implement a further mechanism to switch on and off "in app" application menu, using CTRL+M hotkey (given that you have restored the "in application" menu as described in the point 1). For example Dolphin and Gwenview support CTRL+M as described. Kate supports CTRL+M but kindly emits a warning before hiding the menu. Konsole terminal instead, which acts it's too cool for all the other applications, wants CTRL+SHIFT+M to switch the menu on and off. The selected state is persistent after system reboot.
And it's not over. Other plasmoids designed as a replacement of the global application menu, such as "Active Window Control" will disable your "in application" menu, despite any other contrary directive you may have set. So, I suggest you to make your tests in a clean KDE plasma environment.