[Konsole-devel] [Bug 297224] Command-line options ignored when stdout redirected to /dev/null

[Rogier]

https://bugs.kde.org/show_bug.cgi?id=297224

--- Comment #5 from Rogier <rogier777 at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.