View Bug Activity | Format For Printing
X-startup-scripts-1.0.11-1 included a /usr/bin/startx which had been modified to add -multiwindow -clipboard to the default server args. This change (like #9864) never went upstream, so the xinit package, which now contains startx, does't have this. There have been various mentions on the mailing list noting that this default behaviour has changed.
Created an attachment (id=3947) Patch to startx source to set default server args as they previously have been
I'm not so sure about this one. My view has been that startx is for starting X desktops, which would NOT be in multiwindow mode; starting in multiwindow mode should be left to startxwin.{bat,sh}. What would one use a desktop, e.g. Xfce4, in Cygwin if startx launched multiwindow by default?
Well, irrespective of the rights or wrongs of it, it's a change since R6.9, and so violates the principle of least surprise. There are are multiple people who have asked "how do I get multiwindow back"
Hmm... on reflection I'm not so sure about this change. Let's park it for the moment and I'll put some words in the FAQ. > My view has been that startx is for starting X desktops, which would NOT be in > multiwindow mode; starting in multiwindow mode should be left to startxwin. > {bat,sh}. Part of the problem is that other systems don't have this desktop/multiwindow choice, so we have to invent something. Encouraging people to modify startxwin.(bat|sh) to set X server options or clients to be launched at startup, when it gets overwritten when the xinit package is updated is not good, though.
(In reply to comment #4) > Hmm... on reflection I'm not so sure about this change. Let's park it for the > moment and I'll put some words in the FAQ. Agreed. startx == xsessions, startxwin == multiwindow. > Part of the problem is that other systems don't have this desktop/multiwindow > choice, so we have to invent something. MacOS X? > Encouraging people to modify startxwin.(bat|sh) to set X server options or > clients to be launched at startup, when it gets overwritten when the xinit > package is updated is not good, though. If they modify startxwin.*, they need to put it in /usr/local/bin or ~/bin and use that.
On the gripping hand: not providing '-clipboard' in desktop mode is not very helpful. But I think this probably means that it should be on by default in the X server.
Created an attachment (id=4021) Add -noclipboard option (In reply to comment #6) > On the gripping hand: not providing '-clipboard' in desktop mode is not very > helpful. But I think this probably means that it should be on by default in > the X server. True. '-clipboard' not being the default probably dates back to when there used to be an external clipboard handler (xwinclip). Is there any reason why -clipboard shouldn't be the default? If not, the question is if we should continue accepting '-clipboard' (as a no-op) for compatibility or WJM and kill it. Here's a patch that adds a '-noclipboard' arg but keeps '-clipboard'. (I still try to NOT be WJM as much as possible. :-)) Did I miss anything? Even if we go this route, we can't commit this change without checking with Xming, as he may have different views on this.
Created an attachment (id=4022) Add -[no]clipboard option Revised patch per discussion in IRC. We accept and document both -clipboard and -noclipboard, default is on, and if both are passed, the last one is accepted (as is done with other options). Look good?
Patch in the queue for 1.6.1.901.
-noclipboard patch shipped in 1.6.1.902. Closing, as we have other ways of dealing with -multiwindow.