Situation. I log in from a remote server via ssh. Using ssh tunnelling I can run mcs-manager for the remote display. The remote display has many xrandr modes. I select (via mcs display plugin) xrand -s 18 (real big virtual screen). So I log off and go to the office where the local server is. I try to log in but xfce-mcs-manager crashes on startup. After scratching my head I figure out that there is no equivalent setting for "xrandr -s 18" at the local host, hence crash. I delete .xfce4/settings/display.xml and thus am able to start xfce-mcs-manager. See additional information in bug tracker for more info.
Additional information: Proposed solution: have display plugin save values specifying the display to which it is applied. Thus there would be configuration for each different display that the same user might run xfce-mcs-manager on. Also noted, if XF86Configuration is changed with respect to resolution modes, the display plugin for mcs manager loads the previous set xrandr mode, say number 9, even though it does not exist or has a crappy resolution with the XF86Config changes, like 300x320. Proposed solution: save in display.xml the modification date of XF86Config file. If file is changed, then revert display setting to best value.
This is wrong usage IMHO. Since the xfce-mcs-manager stores settings per display, it should be run on (or atleast for) the current Xserver machine. That says you should run your local xfce-mcs-manager with your local configuration when working at home and use the remote xfce-mcs-manager with the remove configuration when working in office. Nevertheless the display plugin should prevent such usage. I'd suggest to test whether xfce-mcs-manager is running for a local display or a remote display.
Reducing severity to enhancement. We're not going to fix this before 4.2.
Is this bug/feature request still present in Xfce 4.4? If not, please close it...
"We're not going to fix this before 4.2." Assuming that this is fixed in the 4.4 release, I'm closing this bug. Please reopen it if not...