Feature request: Add the ability for Run or Raise to be trigger by terminal scripts
Closed this issue · 5 comments
Run or raise is one of the first extensions or apps that I've seen in gnome-wayland that gives the user the ability to raise windows. I can't even get gedit to raise when new tabs are opened at the moment, so the fact that an extension has the feature is pretty amazing.
I was wondering if it would be possible to add additional ways of triggering the run or raise behavior than hotkeys. It would be nice if we can set it up so that it can be trigger by scripts. For example, the extension can maybe poll for the existence of a certain file that the script can create and inside the file, there would be a raise command of some sort that the extension would execute.
Wow, I've never thought about replacing something like wmctrl!
Could you describe a usecase so that I grasp it better, please? :)
Sure no problem.
The basic idea:
figure out some kind of way of having scripts communicate with extension and do lowering or raising on their behalf. Use some kind of permission list where user can list the windows they want to allow raising via scripts to avoid any vulnerabilities. The best mechanism I could think of is this:
script writes a command in /tmp/run_or_raise
Run or Raise polls this file. Reads command, checks command against permission list already provided by user. Executes command: raises or lowers windows. User can use sudo chattr +i -R on permissions.conf and the run or raise dir to avoid tampering with permissions or run or raise.
I'm not familiar with gnome-shell, so the idea of write a temp file that run or raise would poll was the best thing I could come up with. Maybe you have some better ideas, I don't know.
This could also be done for lowering windows and optionally, if there's a way to flag/unflag windows as always on top, you would pretty much have the most important functionalities wmctrl covered.
Here is an example/application of these new functionalities:
right now, if you use gedit. when you initially open a text file and gedit opens for the first time, the window is put in the foreground (but that's only because the app just opened). Say you have gedit already open, and you click on more files in nautilus. The new tabs open in the background and users have to always switch to gedit. the user also gets no feedback or notification that the click was recognized and the file was opened in gedit.
If I had a way of communicating with run or raise via scripts, the first thing I would do, is make a script that would check if gedit is opened already (using ps ax). If it's not open, no need for raising, it would just execute: gedit "/path/to/file.txt" and close. If gedit's already opened, it would still execute the open command: gedit /path/to/file.txt but it would also initiate a raise action via the mechanism I've described above.
I would call the script gedit-raise and in the gnome-shell Open with menus, I would replace gedit as the default app to open text files with gedit-raise.
Concerning gedit, on my system it gets focus every time a new file is open. Independent if being opened from Nautilus, Krusader od a terminal.
I had an idea once to expose the functionality through a port to localhost so that other applications could do what they need. But unfortunately, I'm little familiar with the gnome-shell too and I haven't studied enough to decide if that wouldn't be against a Wayland security principles or if that should be a completely different plugin than run-or-raise. Either way, it's a lot of work to do and since the development is extensivelly challenging – logout after each change makes you a tough time – I fear not to be able to schedule this feature.
I can totally understand your desire to want to understand Wayland's security principles further before implementing any new functions. Not necessarilly related to my idea but just as a general advice, if you have an idea but are not sure what it's security implications are going to be, you can always get on the gnome and wayland mailing lists and bounce your ideas off of them.
I'm not very well versed in JS synthax. I'll be learning it in the next few months and maybe I'll take up my idea, code it and propose it as commit or maybe I'll just do a fork. It seems to me that you've already done the most difficult thing - extension iniated raising. I personally wouldn't have been able to figure out that part as a beginner extension writer but the rest of my idea, it's just standard js. It involves modifying your extension a little: instead of hotkeys, do a loop that checks for the existence of a certain temp file every 0.5 secs in a preset dir, see if the file has any commands that extension recognizes, compare commands against an user generated list of permissions that's either put in a root owned dir or the user has set it as read only (chattr +i, which can only be undone/done as root).
It's very interesting that you're not running into my issues on your system. Maybe it's some kind of bug that I've induced. Just so we're not getting our wires crossed here: I'm not talking about gedit not focusing when a new gedit window is created. That works just fine on my machine. My problem is that gedit won't focus when the window already exists and a new tab is created or opened. Does that work ok on your machine? Also, I've not been able to get any non-gtk native app to run native wayland in gnome-shell wayland. For example, even though I have all the plasma wayland files installed, dolphin/kdiff/kate/kwrite will only run in native x mode on my gnome-shell wayland (even though all these have native wayland support when running kde plasma wayland). Are you able to get krusader to run natively in wayland (are you sure it's not running in a X11 emulation layer and launching gedit in x11)? you can test if an app is running native wayland by going to terminal and entering: xeyes. It's a little X11 widget which puts a pair of eyes on your monitor that follow your cursor. This widget only works in X11 and not in wayland. Meaning, eyes will follow your mouse when you mouse over a X11 native app (like firefox or gimp) but will no longer be able to track your mouse when you mouse over a wayland native app: like gnome-terminal in a wayland sessions. It would be fun to know if your Krusader is running under X and whether the gedit instance it launches is running under wayland or X.
Hello, sorry for late reply.
- I run Ubuntu 19.04
- Program
xeyesworks and this return x11.
$ loginctl show-session $(loginctl|grep $(whoami) |awk '{print $1}') -p Type
Type=x11- It seems to me a better idea to investigate why raising does not work for you instead of setting up a whole file checking & grammar language that would simulate similar behaviour. But maybe I got you wrong.
- Maybe your obstacles could be solved by Focus my window extension (I'm just guessing.)
Please let me know if you still experiencing the issues or if have it disappeared with the new Ubuntu release and we may re-open this issue.