2010/5/30 Anselm R Garbe <garb...@gmail.com>: > On 29 May 2010 22:18, Sylvain Laurent <syll...@gmail.com> wrote: >> 2010/5/29 Kris Maglione <maglion...@gmail.com>: >>> On Sat, May 29, 2010 at 07:59:39PM +0100, Anselm R Garbe wrote: >>>> >>>> On 29 May 2010 19:17, Anselm R Garbe <garb...@gmail.com> wrote: >>>>> >>>>> On 29 May 2010 18:18, Kris Maglione <maglion...@gmail.com> wrote: >>>>>> >>>>>> On Sat, May 29, 2010 at 01:12:15PM +0100, Anselm R Garbe wrote: >>>>>> The getfullscreen bit is probably not necessary in most cases. The rest >>>>>> of the clientmessage function is a hack, because I don't know the dwm >>>>>> sourcecode well enough to do it properly. It's just to show what's >>>>>> required. >>>>> >>>>> I got a similar impression when reverting the changeset that the EWMH >>>>> fullscreen handling was incomplete. >>>>> >>>>> Overall my aim is trying to prevent using too much EWMH magic, though as >>>>> things look more clients seem to fully depend on EWMH nowadays for >>>>> fullscreen handling, like chromium. >>> >>> I think the intention of the patch wasn't to support EWMH fullscreen so much >>> as to tell apps that they were in fullscreen mode. Without it, chromium went >>> fullscreen fine, but it still showed its tab bar, etc. A lot of apps (when >>> the WM supports EWMH) only show their fullscreen UI when they have the EWMH >>> fullscreen hint set on their window. It's actually a good thing in a lot of >>> cases, because if you manually force the apps to fullscreen from the WM side >>> they tend to hide their decorations properly. >> >> Yes, that's what I was thinking about EWMH, there is already monocle >> mode to set full screen on the user's end, by not maximizing windows >> when sending hint to the window it allows users to play with >> monocle/floating/tiles mode. > > I spend some time on the fullscreen issues and came up with a version > that works for all cases I tested so far. It is committed into hg tip. > It is a simplification of Kris' patch (basically I got rid of > superflous checks that don't seem to be necessary), but with a more > complicated clientmessage(). I also extended Client a bit to keep > state and changed resize(). The changes I did are backwards compliant > for any layout algorithms however. > > Please test hg tip and let me know any issues. >
Do you remember the mplayer scaling issue that we talked about on IRC? The issue is still here even in hg tip. Cheers. -- Demelier David