benedikt.meurer at unix-ag.uni-siegen.de
Sun May 30 00:07:55 CEST 2004
>>So, here's my 2cents: I'm really against the "take less care about multihead"
>>option. It causes way too much trouble. I just want to point out the trouble
>>with the mcs manager. Sure it works just nice in single screen mode, but its
>>current design does not allow any easy solution to make it multihead safe, I'm
>>trying to work out a backward compatible solution for this problem for about
>>three weeks now and its really non-trivial. I think taking care of multihead
>>issues the first time is way easier than having the trouble to fix it later
>>(this counts for everything, not just multihead, of course).
> My plan was to modify the save/load channel fns to automatically append
> the screen number if higher than 0.
> Like .xfce4/settings/gtk.xml on screen 0
> and .xfce4/settings/gtk-1.xml on screen 1 for example.
That was my first idea as well, since its very easy, one would only need to
modify libxfce4mcs, but it has several problems. Most notably there are some
plugins which aren't per-screen (like the session plugin, the sound plugin,
the panel plugin [which should be per panel instance], the desktop plugin, the
file manager plugin, the calendar plugin and the iconbox plugin [which should
also be per iconbox instance]). So after all this solution isn't worth to
think about. What we need is a way to support all kinds of plugins (atleast
the ones we currently have). I already worked out a nice solution, but as
mentioned above, the problem is backward-compibitility. And here we come to
problem I tried to explain.
>>And speaking of xfdesktop, and the probably addition of desktop icons one day,
>>it'll be easier to e.g. handle DnD of icons between screens within one
>>instance, than having to care about IPC (though DnD is always tricky). And
>>while being at it, I would really like to be able to move windows between
>>screens, which is currently not possible because each screens has its own
>>xfwm4 instance (this is no feature request, just a point to think about, esp.
>>when speaking about usability).
> Having an single instance of xfwm4 managing all screen would not be
> enough to allow dragging windows from one screeen to another.
> Plus AFAICT, only GTK is able of screen migration. That means that other
> apps won't benefit from that feature.
> At last, making xfwm4 able to manage several screens is a lot more
> complex than making any other app multiscreen aware (multiple windows
> stacks, etc.)
I know that this is difficult to implement in a window manager, thats why I
added "no feature request". Anyway, from the usability POW, it would be a
really helpful feature.
>>Don't get me wrong. I'm really a friend of simple solutions, but not if that
>>means that it'll require non-trivial work-arounds to get things done at a
> I'm no friend of any solution, I just like code to be simple,
> maintainable and software to be reliable.
The problem is that code/software is not selfcontained. You write code because
you want to _solve_ a problem, and here we come to the term solution. A simple
code, that does not solve a/the problem is nice, but useless. Code that solves
a part of a problem, but without looking at the whole problem, is only usefull
for a short amont of time (until the real problem occurs to happen).
A short look at our problem: We want to provide a desktop environment. Ok, one
part of them problem is to support single screen displays, which we do quite
well. But our problem - the desktop environment - is not, and should never,
force the user to use single screen mode (of course, you can replace the
single/multiscreen problem in here with any other two/three/four/... parts
problem). So we open our eyes a bit more and see that we need to care about
multiple screens as well. We do not need to make multihead support our primary
goal, but we should also neither limit ourself nor the userbase to single
screen mode. And so on... I stop here, cause I think its clear what I want to say.
NetBSD Operating system: http://www.NetBSD.org/
pkgsrc "Work in progress": http://pkgsrc-wip.sf.net/
XFce desktop environment: http://www.xfce.org/
German Unix-AG Association: http://www.unix-ag.org/
OpenPGP Key: http://www.home.unix-ag.org/bmeurer/#gpg
More information about the Xfce4-dev