tilix ignores $DISPLAY env

[532910]

$ Xephyr :3 -ac -screen 1024x768

in another terminal

$ export DISPLAY=:3
$ tilix

it will run on DISPLAY=:0

[gnunn1]

Does it work with other gnome apps like gedit, I'm not doing anything special on that front as far as I know.

[532910]

gedit runs on DISPLAY=:3 it's due to "sever mode" for tilix, but it MUST handle $DISPLAY

[gnunn1]

What thing you could try is to modify the tilix desktop file and set DBusActivatable to false instead of true. That's one thing that's pretty significantly different between gedit and tilix.

Is DBusActivatable what you meant by "server mode"?

[gnunn1]

Actually ignore that last, if you are running tilix from the command line it should not be using dbus activation. When you start tilix this way is it the only instance of tilix that is running? Tilix is a single process so you if you run it and it's already running it will simply pass the command line parameters to that instance and execute it there, your DISPLAY environment variable will be ignored AFAIK.

[gnunn1]

Any update on this, did my last comment make sense?

[532910]

your DISPLAY environment variable will be ignored AFAIK

YES! It's exactly why I've opened this bug.

[gnunn1]

Someone who knows more then I do about GTK and the DISPLAY variable would need to look into this one.

[gbl]

Tested this on my recently installed Ubuntu 18.04 box, together with Tilix 1.7.7 from the Ubuntu repository. Running a desktop login on that machine (call it A). DISPLAY is :0 in this session. From a different machine (call it B), ssh into A using "ssh -X A". This gives me a shell that has DISPLAY set to localhost:12, which points to the SSH tunnel that redirects X output to B's display.

Make sure no tilix processes are running. In this case, starting tilix works as intended; if I start it on A, the tilix window opens on A (no matter if command line or desktop start). If I start it on B, the tilix window opens on B.

However, if I start tilix on one of those hosts while a process is already running, the new window starts on the old host, not the new one:

• start first tilix on A (DISPLAY is :0), get a window on A
• start second tilix on B (DISPLAY is localhost:12), get another window on A. That's because the newly started tilix (which is running with localhost:12) tells the old tilix (on :0) to open a new window and exits.
• start tilix --new-process on B, get a window on B

So the workaround is: if you're in an environment where you ssh between machines, or have other reasons to use different DISPLAYs, use tilix --new-process to make sure you get the window where you want it.

I don't think there's a way to have one process serve different displays with gtk. So the best (only?) way to fix this is have the new tilix process query the old one for it's DISPLAY variable, and only pass the request to the old process if they match. And as this could create more than one process, every new instance would have to iterate over all of the old ones, hand over to one that has the same DISPLAY if it finds one, and keep itself active if it doesn't.

BTW, this seems to be what firefox does as well: when I have a firefox running on A, and start another one, it hands off to the first instance; but when I start it via the ssh connection from B (so it runs on A and displays on B), it creates a new instance.

[gnunn1]

I'm going to close this, I think @gbl summarized this well and in the context of a single process there's mot much I can do about it.

[532910]

You MUST start new-process if DISPLAY changes. This is a bug, please reopen.

[gnunn1]

This is not a bug, it works as expected. If I do not have any tilix instances running then tilix respects the display variable as per the screenshot below:

When tilix is already running this doesn't work because tilix is single process and AFAIK it's not possible for GTK applications to span displays across processes, see screenshot as per below:

I tested this with gedit and it has the exact same behavior.

[532910]

I don't ask you to span displays across processes! You MUST start new-process if DISPLAY changes. This is a bug, please reopen.

point zero, no tilix runed on the host

step two, start two tilix: $ DISPLAY=:0 tilix --new-process $ DISPLAY=:1 tilix --new-process

now I like to open new tilix window on DISPLAY=:1 $ DISPLAY=:1 tilix but this will open new tilix window on DISPLAY=:0

[gnunn1]

Sorry but new-process is not something I'm supporting, it's just there for debugging. There's lot's of issues with regards to running multiple processes of tilix (can't drag and drop terminals between them, certain global changes don't go across windows, etc) so I don't have any plans to adopt a single process rather then shared model formally.

Also, unfortunately I do not have any control over which process the third tilix invocation gets attached to, that's all at the GTK level.

Unfortunately if you really need this feature I'd suggest looking at terminal emulators that operate in the single process model.

[532910]

FUCK!

I have two same user Xorg sessions on one host. I have started tilix on both. I CAN'T "drag and drop" nothing, as I see only ONE session at time. One session is at Ctrl-Alt-F7, and the second at Ctrl-Alt-F8. How should I open new window from the command line on Ctrl-Alt-F8?

[gnunn1]

Tone down the language please. I'm not following what you are saying, are you responding to my comment about not being able to drag windows between processes?

If so keep in mind your use case is not the only one, I have to take into account everyone's needs and I have limited time to write code and support tilix. No one is paying me to work on tilix.

In short changing to a single process model would require a large amount of work and testing, it would also break a number of features that other people rely on like dragging windows between instances. I just don't have the time or the desire to invest in it.

If you feel passionate about it, which you obviously do, feel free to fork tilix and make the changes to support your use case.

Alterbatively If you know of another gtk application that uses the gtk single process model and works the way you want let me know and I'm happy to look at and see how they achieve it. Unfortunately as far as I know none do.

[532910]

I don't ask you to changing to a single process model!

[532910]

I'm not following what you are saying

I have two same user Xorg sessions on one host. The one session is at Ctrl-Alt-F7, and the second is at Ctrl-Alt-F8.

Is it clear?

[gnunn1]

Well I'm not sure what you are asking for then. Like I said I have no ability to influence how gtk works. Let's look at your example:

Start two tilix:
$ DISPLAY=:0 tilix --new-process
$ DISPLAY=:1 tilix --new-process

now I like to open new tilix window on DISPLAY=:1
$ DISPLAY=:1 tilix
but this will open new tilix window on DISPLAY=:0

So in the last case gtk manges the inter-process communication, I have no control it. If you want the third tilix window in display 1 then you need to use the --new-process switch again.

now I like to open new tilix window on DISPLAY=:1
$ DISPLAY=:1 tilix --new-process

[gnunn1]

I think I can actually make this work, essentially GTK allows you to assign a specific application id so you can essentially "group" instances using the application id. Assigning different app id means that when you start tilix with a specific app id it will be grouped into that process.

Thus you could have one process running on display 0 and another process on display 1 each with their own id. If you start a new instance of tilix with the id being used on display 1 it will end up there, if you start it with the app id of what is running on display 0 it will end up there.

Now the question is whether to adjust the app id automatically based on the display or force users to manage the application id themselves. I just don't know enough about displays to understand if there are any situations where two displays would be able to interact with each other in terms of moving windows between them or in a way that I shouldn't do it automatically.

Forcing a user to assign an app id works but if you are launching them from a gui on different displays you would need two different desktop files to assign the id appropriately.

How are you using your setup, is gnome-shell or other launcher running in each session and launching windows into the right session automatically? Or is the launcher running in one window and to explicitly send windows to the other display you have to do it from the command line with the DISPLAY variable?

[532910]

displays not able to interact with each other only "screens" --- the second (optional) number after dot:

DISPLAY=:0 --- display 0, screen 0 DISPLAY=:0.0 --- display 0, screen 0 DISPLAY=:0.1 --- display 0, screen 1 DISPLAY=:1 --- display 1, screen 0 DISPLAY=:1.0 --- display 1, screen 0 DISPLAY=:1.2 --- display 1, screen 2

[gnunn1]

OK for now I have added in the ability to specify the group manually with a new --group flag. So if you run tilix with something like this:

tilix --group=display3 --display=:3

and

tilix --group=display0 --display=:0

They will each go the proper display. Please build and install from master and test it out.

[gnunn1]

I'll look into automatically group based on display in a bit, but if you can test that group flag first just to ensure the validity of the approach I would appreciate it.

[532910]

solution: DISPLAY=:3 DBUS_SESSION_BUS_ADDRESS= tilix will start tilix on :3

[532910]

Thank you, and sorry!

[532910]

Unfortunately no, $ DISPLAY=:3 DBUS_SESSION_BUS_ADDRESS= tilix is the same as $ DISPLAY=:3 tilix --new-process

[532910]

look like the only way to open new tilix window on display 3 is to set proper BUS_SESSION_BUS_ADDRESS

[gnunn1]

Please try my change in master, it should do what you want.

[MrChromebox]

seems like this issue is related to the following bug: https://bugs.launchpad.net/ubuntubudgie/+bug/1758444

I ran into this on my Ubuntu Budgie 18.04 install as well after a software update -- tilix would launch from another terminal, but not from the menu or dock, even on display 0. Setting DBusActivatable to false in the desktop file resolves the issue.