On Sat, 2007-06-23 at 20:58 +0000, Alex F wrote:
> Still, it seems to me that even with the current architecture, the
> application itself does not need to be aware of multiple screens: X11
> of
> course is, therefore the window manager can be, therefore the window
> manager ought to be able to handle the gymnastics of keeping track of
> application/notification/displayscreen linkages without troubling the
> application at all, and (it seems to me) without even bothering the
> GTK+
> rendering system with it. GTK+ just has to render GUI elements at
> whatever coordinates of whatever device the window manager dictates.
>
> A window titlebar already has send-to-workspace functions that (I
> assume) are handled by the window manager, and notification icons must
> already have some linkage to the application process which controls
> the
> window associated with the icon. Therefore, the window manager ought
> to
> be able to display the same notification-icon-list on each display,
> and
> when one is clicked, ought to be able to figure out which display the
> associated window is already on and move it to the display where the
> click happened, if necessary.
Workspaces are a Window Manager concept, not so much an X11 concept. It
depends on what level the thing takes place at... applications connect
to a $DISPLAY, and the window manager running on $DISPLAY then decorates
the window for the application, at its most basic.
You can even have different WMs on :0.0 and :0.1 if you want—it gives
people room to really customize things, which is why I like the layout.
Even so, there are some issues; like this bug, like the fact that
Epiphany and Firefox cannot be run on both displays at the same time,
and so forth. (Then again, for at least Firefox, anyway, the same
applies to different X11 sessions entirely; if you have :0.0 and :1.0
running for the same user, at least FF will error telling you that an
instance is already running somewhere else.)
> Granted, I don't really know much about the guts of this system, so
> maybe there's some big architectural obstacle I'm not accounting for,
> but what I'm describing seems totally doable given what I understand
> to
> be the GUI hierarchy.
>
> Maybe the problem is that separate X11 display-screens (:0.0 vs :0.1
> as
> you mentioned) have thus far been designed to be TOO autonomous? I
> can
> see situations where it would make sense to make them separate (you
> could have a different user logged in to each, in a different room
> even,
> without them interfering with eachother, etc).
This autonomousity lends itself to being quite flexible. Of course, the
flexibility comes at the cost of the application-layer logic having to
do slightly more to deal with it. I think that the way it works
currently (at least in this respect) is a good thing, and besides, one
distribution of the GNU/Linux system wouldn't dare change that—it would
break compatibility with everything else, and take away some of the
wonderful features of X11, like the ability to remote it without using
something like VNC.
> But clearly there is also a need for slightly less independent
> alternate
> displays; maybe a new abstraction level needs to be established that
> allows for only one user session among several displays (the standard
> desktop dual-monitor setup), but in return allows for more interaction
> between the two (like shared notification, etc)?
That's why I think it should probably be done in the GTK+ layer. The
more I think about it, the more that I think that a different bug should
be opened with the goal of doing this. Then again, IANAD, at least not
for this project, and so my opinion matters quite little. :-)
--
Michael B. Trausch
[EMAIL PROTECTED]
Phone: (404) 592-5746
Jabber IM:
[EMAIL PROTECTED]
Demand Freedom! Use open and free protocols, standards, and software!
Support free speech---it is the most valuable freedom we have!
--
Notification area does not work with dual head
https://bugs.launchpad.net/bugs/12696
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
