Investigate a way to allow contrib extensions to use compositing.

[GoogleCodeExporter]

Hooks, or basic, compositing support.

Unsure how hard this is, or how useful. It seems though, with a little
work, a tiling, compositing wm would probably take a big chunk of the
tiling wm market. Drop shadows alone would be very nice. The potential does
need investigating.

Original issue reported on code.google.com by don...@gmail.com on 2 Jun 2007 at 3:12

[GoogleCodeExporter]

Original comment by don...@gmail.com on 14 Jun 2007 at 5:08

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I'd love an extension which allows me to dispense with window borders entirely 
by
automatically setting the currently focused window to 100% opacity and all
non-focused windows to low opacity.

xcompmgr with transset-df are extremely lightweight and have all the 
functionality to
accomplish that (xcompmgr also handles drop shadows and fading transition 
effects
nicely), but unfortunately xcompmgr, being a demo app, seems to have been 
abandoned 3
years ago and remains very buggy (not to mention it's probably full of 
deprecated
compositing API calls).

A more daunting option might be to hook into Compiz Fusion, however it doesn't
currently live happily with xmonad running (if anyone knows how to remedy that 
let me
know!), and anyhow most of its functionality is useless in the xmonad context. 
Seems
like bloat really.

So I believe a good starting goal for basic xmonad compositing support would be 
to
duplicate the functionality of xcompmgr and transset-df directly in Haskell.

Original comment by alextark...@gmail.com on 20 Sep 2007 at 4:14

[GoogleCodeExporter]

This is an old bug that hasn't seen much interest and even less progress.  Let's
close this bug until someone is interested in hacking on it.

Original comment by SpencerJ...@gmail.com on 22 Oct 2007 at 10:18

• Changed state: WontFix

[GoogleCodeExporter]

Alex: you can get part of what you want if an application supports recoloring 
itself
when focus is not on it. For example, Urxvt lets you specify either via the
commandline or through .Xresources something like this:
 URxvt.fading:                                     10
 URxvt.fadeColor:                                  purple
which iirc fades unfocused terminals by 10% (or maybe it was *to* 10%) 
brightness and
darkens it purplish.

Given how many XMonad users are heavy terminal users and how they should  be 
using
Urxvt anyway because it's so good, I think this carries the user a good portion 
of
the way.

Original comment by gwe...@gmail.com on 22 Oct 2007 at 10:42

[GoogleCodeExporter]

> roberth.sjonoy,

xmonad should get optional composite support through use of libxcomposite.
It should be able to make unfocused windows transparent etc, real
transparency for consoles and shadows.

Original comment by don...@gmail.com on 3 Jan 2008 at 7:07

• Changed state: Accepted
• Added labels: Component-Contrib

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

> tiling, compositing wm would probably take a big chunk of the
tiling wm market.

I just want to second this.  I think there is huge potential in having a 
composite
tiled environment, in terms of both special fx *and* usability.

It has been mentioned elsewhere, but some of the possibilities include:
* zoom in/out inactive windows instead of resizing the viewport
* zoom in to maximize or partially maximize a client over the top of other 
clients
* Flip 3D style rotation of clients
* quickly view all workspaces with an expo-style overlay

IMHO drop shadows are superficial when compared to the real enhancements in 
usability
 this could provide.

Original comment by thay...@gmail.com on 3 Jan 2008 at 10:05

[GoogleCodeExporter]

Another possibility:
* window shuffling on layout change (rather than the current instantaneous 
switch).

Original comment by jeremyo...@gmail.com on 23 Jan 2008 at 6:38

[GoogleCodeExporter]

and yet another  - applications like gnome-do use compositing to make their 
overlays
looks nicer.  Right now it's a hideous application in xmonad, even by kicking 
it to
the float layer.

Original comment by csan...@gmail.com on 16 Mar 2008 at 10:20

[GoogleCodeExporter]

I'm with alextarkovsky. "I'd love an extension which allows me to dispense with
window borders entirely by automatically setting the currently focused window 
to 100%
opacity and all non-focused windows to low opacity." +1

Original comment by luizribe...@gmail.com on 24 Mar 2008 at 2:41

[GoogleCodeExporter]

* The best what to add composition would be to switch from xlib to xcb. 
xcb is reported to be faster. Haskell bindings for xcb can be found here:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhb

More info about xcb: http://xcb.freedesktop.org/

I am new to Haskell, thanks xmonad for introducing / making me obsessed.. Other 
wise
I would be tempted to try.

Original comment by nmarshall23 on 25 May 2009 at 1:27

[GoogleCodeExporter]

I'm no hacker but just knows another quite more active compositing manager :
http://cairo-compmgr.tuxfamily.org/

Original comment by pyluy...@gmail.com on 24 Jul 2009 at 10:48

[GoogleCodeExporter]

Regarding cairo-compmgr, I've been tinkering with using Cairo from within 
xmonad and
it works quite well.  It seems like a good option for drawing once the basic
compositing machinery is in place.

I've done very little actual implementation of compositing itself, but it seems 
like
things based on "automatic redirection" would be fairly easy to do in xmonad's
architecture, though they could benefit from easier access to X events (only the
current layout can receive X events) and better timer support for animations 
(threads
perhaps?).  However, automatic redirection only lets you access window 
contents.  In
order to change the way windows are drawn, we need manual redirection, which 
places
the onus of drawing the entire screen on xmonad and, thus, is a much bigger 
challenge
and would probably require core changes.

Original comment by amdragon@gmail.com on 25 Jul 2009 at 7:26

[GoogleCodeExporter]

> though they could benefit from easier access to X events (only the
> current layout can receive X events) 

Did you take a look at handleEventHook in Core? (only in darcs)

Original comment by daniel.s...@googlemail.com on 25 Jul 2009 at 9:47

[GoogleCodeExporter]

I was not aware of handleEventHook.  It's interesting, though I don't see how 
it's
much better than wrapping the layoutHook with a faux layout modifier.  In my 
mind,
layouts already have a fine way to receive X events; it's actions that don't. 
However, for actions that need to receive events, both handleEventHook and 
layoutHook
require (approximately equivalent) user configuration effort beyond simply 
binding
the action.  The faux layout modifier approach at least makes it easy for an 
action
to maintain state; something that seems like it would be particularly difficult 
with
handleEventHook.

To relate this back to the bug report at hand, the types of compositing tricks 
that
should be possible with xmonad today--those that use window contents but don't 
modify
the way windows are usually rendered--seem like the realm of xmonad actions. 
However, doing such things generally requires creating new windows and handling
events from them (as well as the windows being composited), which seems 
difficult to
do from actions, even with handleEventHook.

Original comment by amdragon@gmail.com on 26 Jul 2009 at 6:12

[GoogleCodeExporter]

The advantage of handleEventHook is that you also receive events that would 
otherwise
be handled by xmonad. Layouts only receive unhandled events. State could be 
done by
using an IORef.
I also submitted a patch a while ago that adds arbitrary other state to XState 
that
can be used by extension, to avoid this abuse of the layoutHook, which might be
suitable for this.

I don't know what you mean by actions not having a way to receive Events: If 
you mean
something like a callback on a specific event that can be done with 
handleEventHook
or a layout modifier(by passing around an IORef these actions can also maintain 
state
between calls).

Original comment by daniel.s...@googlemail.com on 26 Jul 2009 at 10:25

[GoogleCodeExporter]

> The advantage of handleEventHook is that you also receive events that would 
otherwise
> be handled by xmonad.

Ah, that makes sense.  I suppose it doesn't help much in the compositing case 
because
I don't think those messages are caught by xmonad, but I can see it being 
useful for
other things.

> I don't know what you mean by actions not having a way to receive Events

I didn't mean to say it was impossible to receive Events from actions, just
difficult.  From a user's perspective, all you want to do is bind the action to 
a key
and be done with it.  But this doesn't work.

1) Instead of implementing your action as an action, you can implement it as a 
layout
modifier (ala XMonad.Hooks.EventHook).  Now your action is a layout, which is 
weird,
and the user has to both bind the action to a key and, for some mysterious 
reason,
wrap their layout hook.

2) Using handleEventHook, you can implement your action as an action, plus an 
event
hook.  If you're handling events you almost certainly also need state, which 
means
you also need something to create the IORef.  Now the user has to "create" the
action, bind it to a key, /and/ modify their handleEventHook.

3) You can have your own event loop (ala XMonad.Prompt).  Now your action is 
just an
action and the user can just bind it to a key like they wanted, but you don't 
play
well with others.  At best, you delay messages, which could be bad if its a 
damage or
timer event aimed at another event handler trying to do compositing or 
animation.  At
worst you eat them.  Ever noticed what happens to XMonad.Layout.Decoration's 
that are
under an XMonad.Prompt or its completions window?  The prompt eats expose 
events, so
the title bars get wiped out and stay wiped out after the prompt closes.  Again,
imagine if you were eating damage or timer events.

Anyways.  This is mostly intended as food for thought: things that are going to 
come
up if/when someone starts working on compositing.

Original comment by amdragon@gmail.com on 27 Jul 2009 at 6:12

[GoogleCodeExporter]

I would like to continue the discussion in this thread because I think that 
composite in XMonad can be interesting.        

There is compiz branch without window manager at 
http://git.compiz.org/~tuxmarkv/zcomp/ that can be used with XMonad. That is a 
good idea but for some reason I can't see any kind of progress since 2010. The 
compiz project is completely modular except for the window manager part.

Said that, I don't know if compiz or projects like that are the solution.

Original comment by pastorel...@gmail.com on 10 Aug 2011 at 11:47