Tried Pulse Audio Again--No Good For A11y

[Les Mikesell]

Lennart Poettering wrote:
> 
>>> For example: you configure your gnome panel to include a clock
>>> applet. Then you open another session and add a network monitor applet
>>> to it. What do you expect from this? That both panels will always stay
>>> perfectly in sync and the network monitor applet is transparently
>>> added to the first session as well? When you log out from both, what
>>> happens when you log in again, do you get the panel layout from the
>>> first session or from the second session?
>> How is this different than running 2 instances of vi?  If you edit the same 
>> file at the same time you'll have a conflict.  That doesn't mean you should 
>> cripple the system to the point where it can't run 2 instances of
>> vi.
> 
> vi has static config files. They are only read on vi's startup. 
> 
> OTOH GNOME usually does instant-apply. I.e. what you configure is
> immediately executed and saved for later.

I've always hated that.  I've had horrible things happen when I change 
layouts on a large screen and the next login is on a small one.  Things 
in general seem to resize better now so maybe it isn't as much of a 
problem. Can you still make apps open with the borders you need to 
resize them off the screen completely?

> You did not respond to my question what you'd think the proper
> behaviour would be for gnome-panel. I'll take that as an
> acknowledgment that you understand that the problem exists.

My idea of proper behavior is to not change defaults unless I specify 
that I want defaults changed.  I suppose that doesn't mesh very well 
with gnome concepts but just because I try something once on one monitor 
does not mean I'll want it always or ever again.  And in the context of 
multiple sessions for the same user, that would mean the last save wins 
as you expect for other files.

>>> The question is: is it worth bothering at all with questions like the
>>> panel question above? Since the feature is redundant we might simply
>>> say: forget it, let's disable multiple logins and the problem is
>>> gone. 
>> Windows terminal services has gotten this more or less right since at least 
>> windows 2000 server that included 2 licenses for administrative use.  If 
>> they can do it with an interface that wasn't designed to be remote or 
>> multiuser, it can't be that hard.
> 
> Are you sure you can log in twice on Win2k as exactly the same user id?

Yes, and you can be running the same apps in different-sized windows in 
each.  You only get terminal services in the server products but it is 
done surprisingly well - current versions take sound along for the ride too.

>> But, if it can't be done right, the WM should enforce it and give you a 
>> choice of killing the old session when you attempt a new login instead of 
>> just letting random things fail.
> 
> Nah, if at all that's the job of the dm or the sm, not the wm.

Which has the restriction of not understanding multiple concurrent sessions?

-- 
   Les Mikesell
    lesmikesell at gmail.com