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

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.

Regards,

-- 
Sylvain `Magicking` Laurent
sylvain.laurent_AT_epita.fr