Thanks for reporting.

Since you didn't explicitly list the KDE version, I assume you are using konsole 2.7.4 shipped in KDE SC 4.7.4 according to packages.debian.org

The reported problem does exist in that version. It is a little tricky to explain why the problem happens. 

Konsole uses KuniqueApplication internally to try to make all Konsole windows running in the same process. One exception is when Konsole is started from an existing terminal, a new Konsole process is created. However, the way of checking is a bit naive. It just checks whether stdout is a tty.  Clearly, that check fails when Konsole is started like "konsole .... >/dev/null".  So the result is the new Konsole window runs in existing Konsole process. That is why the "--display" option does not work as expected when used together with ">/dev/null". 

The situation is improved a bit in KDE SC 4.8.0, where stdin is checked instead of stdout. That is still naive. The current development branch performs that check by trying to open /dev/tty. Maybe that change should be backported into the 4.8.x branch.

For KDE SC 4.7.4, I don't know whether backporting is worthwhile. But the change between 4.7.4 and 4.8.0 on this issue is trivial: just change "isatty(1)" to "isatty(0)" in main.cpp. You might ask debian KDE team to create and apply a simple patch.

As for the --nofork option and the dbus error, see bug 288200 for more information.

Thanks for the reply.

> The situation is improved a bit in KDE SC 4.8.0, where stdin is checked instead of stdout. That is still naive. The current development branch performs that check by trying to open /dev/tty. Maybe that change should be backported into the 4.8.x branch.

Personally, I don't mind waiting until 4.9 (?).
I also suppose you'd rather spend your time fixing new bugs, or implementing new features than backporting fixes...

The way I understand your explanation, one of my observations is not explained:
    session-on-display 0 $ konsole --display 1:0
new konsole session opens on display 1:0
    session-on-display 1 $ konsole
another new konsole session opens on display 1:0, as expected
    session-on-display 1 $ konsole > /dev/null
a new konsole session opens on display 0, whereas it is obviously expected on display 1.

The way I interpret this, is that the last konsole invocation creates a new window using an existing konsole process, as is to be expected. However, it obviously selects the incorrect process: the invoking process is running on display :1.0. Konsole however, still selects the konsole process on display :0.0 to create the new window.
IMO, a freshly started konsole should open a window on the current display. Even if that display does not already have a konsole process.

As this behavior is not seen when konsole is started from an rsh session, I did some more testing, and it appears that the environment variable DBUS_SESSION_BUS_ADDRESS is 'the culprit' - clearing it causes the new konsole window to open on the correct display. Apparently DBUS_SESSION_BUS_ADDRESS (still) contains the address associated with display :0.0, even though konsole is running on :1.0, and konsole is using that address regardless of the display it is running on.

Kind regards,

Rogier.

Git commit 6b811ec2b6e4fbf459af9765c9ead506c9a0cd3c by Jekyll Wu.
Committed on 18/04/2012 at 10:04.
Pushed by jekyllwu into branch 'master'.

Konsole should use new process when some Qt/KDE options are given

One typical option is "--display", because two konsole windows
belonging to the same process are destined to be shown in the same
display, which defeats the purpose of the "--display" option
Related: bug 179010, bug 297801
FIXED-IN: 4.9.0
REVIEW: 104653

M  +28   -0    src/main.cpp

http://commits.kde.org/konsole/6b811ec2b6e4fbf459af9765c9ead506c9a0cd3c

Thanks for your feedback and sorry for the delay of the reply.

> The way I understand your explanation, one of my observations is not
> explained:
>     session-on-display 0 $ konsole --display 1:0
> new konsole session opens on display 1:0
>     session-on-display 1 $ konsole
> another new konsole session opens on display 1:0, as expected
>     session-on-display 1 $ konsole > /dev/null
> a new konsole session opens on display 0, whereas it is obviously expected
> on display 1.
> 

I don't have or use that two display enviroment, so I can only do some guessing. 

This line "session-on-display 0 $ konsole --display 1:0" is important. Is it executed in an existing Konsole window opened through icon/menu/shortcut, or is it executed in a xterm and no konsole is running at all?. If it is the first case, then the last invocation can be explained. The selection of reusable konsole process is dbus-based(That is how KUniqueApplication works), so display does not make difference here. If the first reusable konsole process shows on display 0, then all following reusing attempt will open konsole window on display 0.

And I think that DBUS_SESSION_BUS_ADDRESS is the right behavior. You are using two displays in the same user session, right? Then DBUS_SESSION_BUS_ADDRESS should be same regardless of display if I understand it correctly.

Hi Jekyll

> > The way I understand your explanation, one of my observations is
> > not
> > 
> > explained:
> >     session-on-display 0 $ konsole --display 1:0
> > 
> > new konsole session opens on display 1:0
> > 
> >     session-on-display 1 $ konsole
> > 
> > another new konsole session opens on display 1:0, as expected
> > 
> >     session-on-display 1 $ konsole > /dev/null
> > 
> > a new konsole session opens on display 0, whereas it is obviously
> > expected on display 1.
> 
> I don't have or use that two display enviroment, so I can only do
> some guessing.

I am using a nested Xephyr session as other display.

I use it when I want to isolate a graphical application (typically, 
but not always running on a VM) from my regular desktop environment, 
e.g. when testing. The nested display runs as little of a windowing 
environment as possible, to save resources, not even a window manager 
if not needed, and certainly no full KDE session.
Some applications I need (e.g. konsole), I then start from an existing 
shell, specifying the other display as target.

> This line "session-on-display 0 $ konsole --display 1:0" is
> important. Is it executed in an existing Konsole window opened
> through icon/menu/shortcut, or is it executed in a xterm and no
> konsole is running at all?.

It is started from an existing konsole session.

> If it is the first case, then the last
> invocation can be explained. The selection of reusable konsole
> process is dbus-based(That is how KUniqueApplication works), so
> display does not make difference here. If the first reusable
> konsole process shows on display 0, then all following reusing
> attempt will open konsole window on display 0.

> And I think that DBUS_SESSION_BUS_ADDRESS is the right behavior.
> You are using two displays in the same user session, right?

Actually, no.
I don't know how multi-display works these days, as I also have just a 
single display. IIRC, plain old X uses display addresses :0.0, :0.1 
etc. for multiple displays in a single session, whereas it uses :0.x, 
:1.x, etc. for multiple sessions.

> Then DBUS_SESSION_BUS_ADDRESS should be same regardless of
> display if I understand it correctly.

Shouldn't DBUS_SESSION_BUS_ADDRESS reflect the address of the *current* 
konsole session, instead of any 'random' address that happens to be 
lingering in the environment ?
I.e., if konsole decides that a new process must be used, instead of 
creating a new window in an existing process (e.g. because --display 
was used), then shouldn't it set DBUS_SESSION_BUS_ADDRESS (and 
presumably KONSOLE_DBUS_SERVICE as well ?) to the address of its own 
session, regardless of any previous value it had ?

Also, if it leaves the address of the other session, then any 
application (if any ?) that uses that dbus address to try and 
manipulate the current konsole process, will be in for a surprise, 
when an entirely different process ends up being affected.

Regards,

Rogier.

I'm not a dbus expert, but I think DBUS_SESSION_BUS_ADDRESS is a per-user-session thing. All dbus-awared applications in the same user session should inherit and see the same value. I don't think it should be touched by konsole or any dbus-awared application in normal case. 

On the other hand,  KONSOLE_DBUS_SERVICE  is really a konsole thing, and it is different for each konsole process.

> https://bugs.kde.org/show_bug.cgi?id=297224
> 
> --- Comment #6 from Jekyll Wu <adaptee@gmail.com> ---
> I'm not a dbus expert, but I think DBUS_SESSION_BUS_ADDRESS is a
> per-user-session thing. All dbus-awared applications in the same
> user session should inherit and see the same value. I don't think
> it should be touched by konsole or any dbus-awared application in
> normal case.

Obviously.
I should have realized that myself ...

I guess this is more a problem with the integration between the X 
server session and the dbus session, and dbus not verifying whether 
the the dbus session matches the X session (i.e., the X server) .

I suppose, as a workaround, I should clear DBUS_SESSION_BUS_ADDRESS 
when starting konsole (or any dbus application, for that matter...) on 
another display.

Nevertheless...:

> On the other hand,  KONSOLE_DBUS_SERVICE  is really a konsole
> thing, and it is different for each konsole process.

...would it be an option for konsole to use KONSOLE_DBUS_SERVICE and 
KONSOLE_DBUS_SESSION if available to determine which konsole session 
to use when creating a new window, instead of using the 'random' 
konsole session that managed to grab the generic dbus name ?
If a new konsole tab (or a new window), is created from a shell prompt 
in a konsole tab, then the user would expect the new tab to open in 
the current window, or a new window to be created in the same konsole 
process as the invoking window.  Using these two variables would 
ensure this, and make the behavior predictable. I assume it would also 
ensure that the new window appears on the same screen as the konsole 
window it was started from.

(Granted, if you remember which happened to be the first konsole 
session, and which happened to be its first window, then the current 
behavior is predicatble as well :-)

Kind Regards,

Rogier.

I think I understand your point of KONSOLE_DBUS_SERVICE, but that sounds impossible according to the current implementation detail. The decision is mostly done inside class KUniqueApplication, while Konsole can only force it to use new process under some special and sane conditions(like this --display option).

Actually, I keep thinking about this "single process" model and KuniqueApplication ever since I started contributing to Konsole in last year.  I myself never expect terminal emulator to be single process, especially when it is the default behavior. Maybe an explicit daemon/client combination like urxvtd/urxvtc is a better way to achieve the "single process" model. 

But whatever, this "single process" model and its implementation is unlikely to change in the near future. The current focus of konsole development is to fix various small issues of KDE4 konsole and make it look like a finished product instead of a half-finished product.

Hi Jekyll,

> --- Comment #8 from Jekyll Wu <adaptee@gmail.com> ---
> I think I understand your point of KONSOLE_DBUS_SERVICE, but that
> sounds impossible according to the current implementation detail.
> The decision is mostly done inside class KUniqueApplication, while
> Konsole can only force it to use new process under some special
> and sane conditions(like this --display option).

I suppose then, what's really needed, is for KUniqueApplication to 
become aware of applications having multiple instantiations. After 
all, it does allow a non-unique instance, so IMHO, it naturally 
follows that it should be aware of the mulitple instances that it 
created (itself!), and be able to allow a specific one to be selected, 
if desired.

That would probably be outside of your scope as Konsole contributor...

> Actually, I keep thinking about this "single process" model and
> KuniqueApplication ever since I started contributing to Konsole in
> last year. I myself never expect terminal emulator to be single
> process, especially when it is the default behavior.

One advantage of a single-process model, is that tabs can be moved 
between windows...

> Maybe an
> explicit daemon/client combination like urxvtd/urxvtc is a better
> way to achieve the "single process" model.

> But whatever, this "single process" model and its implementation is
> unlikely to change in the near future. The current focus of
> konsole development is to fix various small issues of KDE4 konsole
> and make it look like a finished product instead of a
> half-finished product.

That does sound more important to me, especially since I suspect that 
most users would not be interested in how many konsole processes there 
are anyway.

Kind regards & thanks again for replying to my bug report, and thanks 
for your work on improving Konsole.

Rogier.

OK, close this bug report as FIXED since both the tty detection and the --display option have been fixed in development version( the upcoming KDE SC 4.9).