Re: [dev] dwm-5.8.1 / dmenu-4.1.1

2010/5/30 Anselm R Garbe <garbeam_AT_gmail.com>:
> On 29 May 2010 22:18, Sylvain Laurent <syllaur_AT_gmail.com> wrote:
>> 2010/5/29 Kris Maglione <maglione.k_AT_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 <garbeam_AT_gmail.com> wrote:
>>>>>
>>>>> On 29 May 2010 18:18, Kris Maglione <maglione.k_AT_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