[dev] dwm tip changes

[Anselm R Garbe]

Hi there,

I pushed some xinerama/updategeom() changes and some fullscreen
handling changes into hg tip today.

The xinerama changes consist of a simplification when new screens are
added/removed -- all clients are simply re-attached to the first
screen found and the whole monitor structure is re-created freshly.
This sucks in some cases, but introduces predictability, whereas the
old code was rather unpredictive and cumbersome.

Also, dwm now disallows resizing/moving/float fullscreen windows, as
this doesn't seem very useful anyways.

Please test hg tip and let me know any issues you encounter.


Thanks,
Anselm

[Arian Kuschki]

On 23 June 2012 20:06, Anselm R Garbe <gar...@gmail.com> wrote:
> Also, dwm now disallows resizing/moving/float fullscreen windows, as
> this doesn't seem very useful anyways.

I haven't tested the changes yet, I just want to say that I find
resizing full screen windows useful sometimes. For some apps (e.g.
Evince) going full screen seems to be the only way to hide menu bars
etc. This means when you want to efficiently use your screen (e.g.
half/half editor/pdf file), it makes sense to put an app into full
screen and then make it smaller again.

I know there are probably apps in every category that allow one to do
this without going full screen. So, just my 2 cents.

Cheers,
Arian

[sta...@cs.tu-berlin.de]

* Arian Kuschki <arian....@googlemail.com> [2012-06-23 23:52]:

> half/half editor/pdf file), it makes sense to put an app into full
> screen and then make it smaller again.

+1

fullscreen often just happens to be the window mode which provides the
best view. It is helpful to be able to tile the window in this mode just
as in any other.

fullscreen windows *are* floating, aren't they? so the question is
whether you allow to tile/monocle them, right?

--s_

[Anselm R Garbe]

On 23 June 2012 23:51, Arian Kuschki <arian....@googlemail.com> wrote:
> On 23 June 2012 20:06, Anselm R Garbe <gar...@gmail.com> wrote:
>> Also, dwm now disallows resizing/moving/float fullscreen windows, as
>> this doesn't seem very useful anyways.
>
> I haven't tested the changes yet, I just want to say that I find
> resizing full screen windows useful sometimes. For some apps (e.g.
> Evince) going full screen seems to be the only way to hide menu bars
> etc. This means when you want to efficiently use your screen (e.g.
> half/half editor/pdf file), it makes sense to put an app into full
> screen and then make it smaller again.
>
> I know there are probably apps in every category that allow one to do
> this without going full screen. So, just my 2 cents.

I understand your remark. The newly introduced limitation addresses
the moving/resizing by mouse only.
Usually clients will exit fullscreen mode when they are resized/moved.
Some won't.

The issue here is really that we are dealing with broken concepts.
Apps that provide a better UI in fullscreen mode should be fixed to do
so in normal screen mode imho.

The new approach seems conceptually clearer, as it makes no compromise
for the category of clients that destroy the window on re-adjustment.

But if there are many such use cases I might reconsider this decision.

Best regards,
Anselm

[Anselm R Garbe]

The problem with floating is that it toggles the client state. If
initially treated as floating window, it will toggle to the
tiled/monocle/.. layout. If then toggled back to floating, it won't be
resized to fullscreen mode. This sucks more imho.

For such clients you could introduce a rule that forces fullscreen
clients into tiled mode to get the behavior you are after.
Probably a small adjustment to the fullscreen handling needs to be
done to achieve this.

Best regards,
Anselm

[sta...@cs.tu-berlin.de]

* Anselm R Garbe <gar...@gmail.com> [2012-06-24 11:06]:

> The problem with floating is that it toggles the client state. If
> initially treated as floating window, it will toggle to the
> tiled/monocle/.. layout. If then toggled back to floating, it won't be
> resized to fullscreen mode. This sucks more imho.

I see your point. Thanks for clarifying.

From your answer to Arian I see you mean mouse resize only. This doesn't
bother me at all. I just want to be able to tile/monocle fullscreen
windows, ant that seems to stay as is.

thanks
--s_

[Arian Kuschki]

On 24 June 2012 11:01, Anselm R Garbe <gar...@gmail.com> wrote:
> I understand your remark. The newly introduced limitation addresses
> the moving/resizing by mouse only.

Ah, I see. I don't use the mouse for what I described, so as long as
full screen windows can still be tiled my use case is covered. Great!

> The issue here is really that we are dealing with broken concepts.
> Apps that provide a better UI in fullscreen mode should be fixed to do
> so in normal screen mode imho.
>
> The new approach seems conceptually clearer, as it makes no compromise
> for the category of clients that destroy the window on re-adjustment.

I cannot judge the cost of additional complexity to dwm's source. But
I think being able to use certain sucky apps in 'full-screen-tiling'
mode actually makes the world suck a little bit less. I don't believe
e.g. evince or chromium will be 'fixed' anytime soon in this regard.

Cheers,
Arian

[Bjartur Thorlacius]

On Sun, Jun 24, 2012 at 02:34:06PM +0200, Arian Kuschki wrote:
> I cannot judge the cost of additional complexity to dwm's source. But
> I think being able to use certain sucky apps in 'full-screen-tiling'
> mode actually makes the world suck a little bit less. I don't believe
> e.g. evince or chromium will be 'fixed' anytime soon in this regard.
>

We could patch it and/or file a bug report. In fact I fetched the Debian source package yesterday, but I haven't installed all of the build chain and dependencies. Deleting a few lines of NetWM code should be trivial, even from a huge program. Compilation, OTOH, will be a pain.

[Manolo Martínez]

On 06/24/12 at 11:01am, Anselm R Garbe wrote:
> > On 23 June 2012 20:06, Anselm R Garbe <gar...@gmail.com> wrote:
> >> Also, dwm now disallows resizing/moving/float fullscreen windows, as
> >> this doesn't seem very useful anyways.

> But if there are many such use cases I might reconsider this decision.
>

I used to use LyX exactly like this = fullscreen + tiled. I don't use
LyX anymore, though.

Manolo

[Hannes Blut]

> Also, dwm now disallows resizing/moving/float fullscreen windows, as
> this doesn't seem very useful anyways.

I enjoy letting a video play in the corner using mplayer. I don't like
to tile the vo of mplayer because that tends to mess up the aspect
ratio.

--
Hannes Blut
available via
Mail: blut....@googlemail.com
IRC: #blut on irc.freenode.net

[Bjartur Thorlacius]

On 6/24/12, Hannes Blut <blut....@googlemail.com> wrote:
> I enjoy letting a video play in the corner using mplayer. I don't like
> to tile the vo of mplayer because that tends to mess up the aspect
> ratio.
>

You can fix that by making dwm respect size hints. See config.h.

Tiling mplayer vo is actually the coolest feature of dwm, but you do
instead have to live with the possibility of your windows not filling
the screen completely. Render the output of your shells as lines of
variable-width characters instead of fixed-width character grids and
you'll be fine. As an additional benefit, you'll be able to fit more
characters in each line (assuming you use any thin characters). You'll
have to use proper tables (read: tabs) instead of abusing spaces,
though.

[Uli Armbruster]

* Hannes Blut <blut....@googlemail.com> [24.06.2012 16:08]:

> > Also, dwm now disallows resizing/moving/float fullscreen windows, as
> > this doesn't seem very useful anyways.
>
> I enjoy letting a video play in the corner using mplayer. I don't like
> to tile the vo of mplayer because that tends to mess up the aspect
> ratio.

This is something that's fixed in mplayer2. Maybe you want to give it a try!

[Uli Armbruster]

* Anselm R Garbe <gar...@gmail.com> [23.06.2012 20:06]:
> Hi there,
>
> I pushed [..] some fullscreen handling changes into hg tip today.
>
> [...]

>
> Also, dwm now disallows resizing/moving/float fullscreen windows, as this doesn't seem very useful anyways.
>
> Please test hg tip and let me know any issues you encounter.
>
>
> Thanks,
> Anselm

I definitely like this fullscreen change, makes a lot of sense and I vote for them to stay in the code!

[Robert Figura]

As it happens i recently found and just fixed a simple two pass
algorithm to keep the waste space quite minimal[*] and distribute the
remaining space to the earliest clients in the heap. See the
stackclients() function in teslawm's latest tip:

http://spuerwerk.dyndns.org/~rfigura/teslawm/cgi-bin/hgweb.cgi/file/19f41ca1e6a9/teslawm.c#l2208

I hope the relevant code is not too far away from dwm's so you don't
have to look at other sins i left there for your amusement ;-p

Have fun,
Robert Figura

[*] Usually there should be less than min(HINT_INCREMENTAL of all
clients) waste space but i think one can construct an example where
it would be max(...) instead. If you construct such an example let
me know.

--
http://teslawm.org/

[Bjartur Thorlacius]

Sounds promising. Doing this optimally seems fairly hard. Are you certain your repo is consistent, or is my ISP now not only blocking but also fiddling with source code I want?

On Sun, Jun 24, 2012 at 10:58:10PM +0200, Robert Figura wrote:
% hg clone http://spuerwerk.dyndns.org/~rfigura/teslawm/cgi-bin/hgweb.cgi
destination directory: hgweb.cgi
requesting all changes
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: consistency error in delta!

[Robert Figura]

Bjartur Thorlacius <svart...@gmail.com> schrieb:

ouch. it should work by now. thanks for your quick reply.

Kind Regards
- Robert Figura

--
http://teslawm.org/

[Anselm R Garbe]

Unfortunately it had too many issues and I will rework it again, thus
I reverted hg tip to the previous behavior some weeks ago.

Cheers,
Anselm