Entering bash command does not work about applications-menu HOT 27 OPEN

to clarify, I installed AppEditor to check if this option was checked by default.

from applications-menu.

I installed another terminal, xterm, to test if I could launch xterm with a program as an argument. then I tested to see if the "launch in terminal" option worked, and it did. so I guess the problem is that xterm should be installed by default? or should pantheon terminal support command arguments?

from applications-menu.

perhaps the menu could give you a warning when a problem like this occurs? telling them that they can launch the program without the terminal, or to install xterm?

from applications-menu.

Perhaps this is related: elementary/terminal#158

from applications-menu.

from applications-menu.

Terminal does need to be launched with fairly strict requirements for the --execute flag at the moment. The app menu needs to be checked that it is complying.

from applications-menu.

Any news? I hate this bug. I Can't use Super key+space and keyboard to start some terminal commands.

Just in case I will put this here:mate-desktop/mate-panel#57

from applications-menu.

Sorry this does not seem to have attracted any attention. I'll try and look into it soon.

from applications-menu.

I can confirm that UCK does not launch unless an alternative terminal is installed.

At the moment the appmenu launches the app using a Gtk.AppInfo with a NEEDS_TERMINAL flag so it looks like that is not compatible with the elementary terminal.

from applications-menu.

Part of the problem seems to be that the environment variable "TERM" is set to "xterm" not "io.elementary.terminal"

from applications-menu.

Unfortunately making sure that TERM=io.elementary.terminal in the environment with which appinfo.launch () is called makes no difference - Gtk still tries to launch in "xterm" - which fails if that is not installed. Not sure yet why this is.

from applications-menu.

Installing other terminals which are not named "xterm" (e.g. Mate terminal or Konsole) also causes this problem. May be an upstream issue - the terminal set in the environment is not being used by Gtk.

from applications-menu.

It may be possible for the application menu to work around this by reading the settings itself and constructing the correct commandline. Whether this is the correct approach rather than fixing upstream is open to question.

from applications-menu.

A workround for this particular case is to create a custom shortcut using the keyboard settings plug.

This command works: io.elementary.terminal -e uck-gui --wait-before-exit

That way you can launch the app with e.g. <Alt>U or whatever shortcut you would like that does not clash with an existing one.

from applications-menu.

Yes It's not looking very attractive but It gives a lot of power to app menu. And make it fast app launches.

You mean modify applications .desktop files "Exec=" key manually? There must be a better way :(

from applications-menu.

@queeup What I mean is

• open the System Settings app from the dock
• click on the "Keyboard" icon
• click on the "Shortcuts" button
• click on "Custom" in the sidebar on the left
• click on "+" on the toolbar at the bottom
• Enter the command io.elementary.terminal -e uck-gui --wait-before-exit and press enter.
• select the new command and click on the "Disabled" button on the right
• Press the key combination you want to use as the shortcut.
• thats it - you can close System Settings. Pressing the chosen key combination will execute uck-gui in the terminal.

from applications-menu.

Ooo boy. Please don't make me do this. :(

I hope this powerful feature of app menu can be fixed someday.

from applications-menu.

OK just to be sure we are talking about same things and two different problems:

I want to point out .desktop files with Terminal=true key applications (Htop for example) not working unless xterm installed or fake it like you have installed with ln -s /usr/bin/io.elementary.terminal /usr/bin/xterm.

"Launch in terminal" is looking like the same thing but code base different thing. That is why symbolic link trick not working on this.

Two different problem for doing almost same job. Do I need to open another issue for "Terminal=true" apps?

from applications-menu.

For the Terminal=true thing need gnome patch like mate team did:
- https://gitlab.gnome.org/GNOME/glib/merge_requests/795

Problem is this lines:
- https://gitlab.gnome.org/GNOME/glib/blob/master/gio/gdesktopappinfo.c#L2520

Strange but "Launch in terminal" accualy works but printing commands result to the to DEBUG log
instead open terminal and pring on it.

python3 --version command from app menu::

** (wingpanel:6568): DEBUG: 00:35:23.362: relevancy-service.vala:72: application launched
Python 3.6.8

uname -a command from app menu:

** (wingpanel:6568): DEBUG: 00:49:48.198: relevancy-service.vala:72: application launched
Linux sony-desktop 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

from applications-menu.

Not sure whether elementary/terminal#397 might help with this.

from applications-menu.

@queeup I think that if the issues are due to bugs in different parts of the code and require separate solutions (as appears to be the case) then two issue need to be opened.

from applications-menu.

@queeup Just to clarify - when you say "Launch in Terminal" ticked, which app is supplying this option?

from applications-menu.

Sorry for confusing. I mixed up things. When I say "Launch in Terminal" I was trying to say "Run command". Write terminal command (ls -ll or cat .bashrc etc.) to app menu and expected to see terminal window opening and print out commands results on terminal. I think I am wrong about that right? There is no such a thing.

I guess my #232 issue is duplicate of this issue. I am confused. Sorry. You can tag it as duplicate.

from applications-menu.

In that case I think #232 may well be a duplicate, however I think the problem is more clearly state in that report as it mentions the problem is fundamentally linked to the "Terminal" key in the desktop file.

from applications-menu.

I have changed the description of this to distinguish it from #232. I am looking into the related code and it may have a different cause in the case of bash commands as opposed to apps requiring a terminal.

from applications-menu.

It seems that if wingpanel is launched from a terminal (it needs to be removed from cerbere monitor list
and killed first), the entering a bash command produces output in that terminal rather than launching a new terminal which would explain why it is not normally seen.

from applications-menu.

After further investigation, I think that the root cause of all these problems is gdesktopappinfo only supporting specific named terminal programs before falling back to xterm (not including io.elementary.terminal). So until that problem is fixed we can only try and find a work around.

from applications-menu.