ccsm and "title=^MPlayer" in Place plugin

[KJ44]

I'm using the Place plugin to put windows on different faces of my (8 sided) cube. I can do this with most applications, but not MPlayer.

I'm sure I've done the "xprop" business properly, "title=^MPlayer", but the window stubbornly stays on whatever face is current when I invoke MPlayer.

Now, if I have the "title=^MPlayer" wrong, I'd understand. Yet if I use the same expression to set the window opacity, it works - that's really confusing.

What am I doing wrong?


PS This forum is a fine resource, I've been running Compiz on openSUSE 10.3 for a week or so, and learned a lot.

[coz]

hey KJ44,
If you are using gnome the title for mplayer will be gmplayer.
Let me know if that works for you :)
coz

[KJ44]

I'm using KDE. The KDE backend is a nice idea.

Indeed, I sometimes use gmplayer, but often I invoke MPlayer from a terminal. Interestingly, the GUI widget for gmplayer is being mapped to the correct cube face by "title=^MPlayer", but the video window is not.

FYI, I'm pretty sure that under gnome the window title for gmplayer would be MPlayer. The g stands for GUI, not gnome. Certainly using xprop on gmplayer gives the title MPlayer. Thanks for replying though, I appreciate it. :)

gmplayer GUI widget:
WM_NAME(STRING) = "MPlayer"
gmplayer video window:
WM_NAME(STRING) = "MPlayer - Video"

http://forum.compiz-fusion.org/showthread.php?t=1768

# title - What is written in the window's title bar?
* Command: xprop | grep "WM_NAME(STRING)"

[maniac]

As far as I know, mplayer remembers the position of its video window and restores that on open, overriding the initial placement done by the place plugin.

[KJ44]

As far as I know, mplayer remembers the position of its video window and restores that on open, overriding the initial placement done by the place plugin.

Strictly speaking, gmplayer (the version with the gui) does that. I also have my problem with the command line version, mplayer. Looking at the config files confirms you are right :), but there is no equivalent config file for command line mplayer, yet I still have the problem.

Not only that, I see nothing that forces the virtual desktop or the viewport. :(

This really is a mystery. I'm hoping some other Compiz gurus will notice ...

[maniac]

Strictly speaking, gmplayer (the version with the gui) does that. I also have my problem with the command line version, mplayer. Looking at the config files confirms you are right :), but there is no equivalent config file for command line mplayer, yet I still have the problem.

Not only that, I see nothing that forces the virtual desktop or the viewport. :(

This really is a mystery. I'm hoping some other Compiz gurus will notice ...
Viewports are a large desktop implementation, meaning that all your windows are placed on one huge desktop. That means that moving a window between viewports is essentially is the same as moving it by a multiple of the screen size, which should explain why the viewport placement is overridden by mplayer's own positioning.

[KJ44]

Viewports are a large desktop implementation, meaning that all your windows are placed on one huge desktop. That means that moving a window between viewports is essentially is the same as moving it by a multiple of the screen size, which should explain why the viewport placement is overridden by mplayer's own positioning.

I like that thinking! Sorry, but MPlayer from the command line doesn't (AFAIK) cache its window position. However, I'll go away and check to be 100% sure. :) .... nope, didn't work.

[KJ44]

The MPlayer video window won't map to another viewport even if I use "type=any" as the match! :confused:

[maniac]

The MPlayer video window won't map to another viewport even if I use "type=any" as the match! :confused:
That's clear, because your problem is not the match, your problem is that mplayer remembers its position.
I just checked with the command line mplayer, and it really positions itself.

[KJ44]

That's clear, because your problem is not the match, your problem is that mplayer remembers its position.
I just checked with the command line mplayer, and it really positions itself.

Thanks for your patience, I now understand it isn't the match.

I'm not convinced command line mplayer _remembers_ the window position (if you can tell me what file is modified, much appreciated) - but it's clear that it _forces_ it (from reading the xprop output). I can use the -geometry option to mplayer to move the window position - but I can't move the blasted window to another cube face, the window co-ordinates are relative to the current cube face - too big an X geometry value (2,000) and the window clamps to the left.

I don't give up easily, so don't feel as if you have to answer my rambling posts, and thanks for the clues ...

I thought I could do this

urxvt --title MPlayer -e mplayer ....

to sneakily map the terminal to the desired cube face and invoke mplayer from over there - the terminal appeared on the desired cube face, but the mplayer window appears on the original cube face. Aaargh!

I wouldn't mind but I'm becoming obsessed with the problem - it's a good way to learn stuff.

[maniac]

I'm not convinced command line mplayer _remembers_ the window position (if you can tell me what file is modified, much appreciated) - but it's clear that it _forces_ it (from reading the xprop output). I can use the -geometry option to mplayer to move the window position - but I can't move the blasted window to another cube face, the window co-ordinates are relative to the current cube face - too big an X geometry value (2,000) and the window clamps to the left.

If you're not convinced, add a printf line in the moveResizeWindow function (src/window.c) which is called everytime a window requests to be repositioned - that's what I did ;)
I didn't lookup the mplayer sources as I'm not familiar with them, but mplayer clearly requests to be positioned (by either calling XConfigureWindow, which causes a ConfigureRequest event sent to Compiz, or by sending a _NET_MOVERESIZE_WINDOW client message to the root window - I didn't look up which of the two happens).


I thought I could do this

urxvt --title MPlayer -e mplayer ....

to sneakily map the terminal to the desired cube face and invoke mplayer from over there - the terminal appeared on the desired cube face, but the mplayer window appears on the original cube face. Aaargh!

That's clear ... if mplayer places itself to e.g. position 200, 200, it will always be on the current cube face. Positions aren't viewport 0,0 based, but the upper left corner of the current viewport is always 0,0.