Subject: Re: CVS olicha: A try for a final clever placement algo

From: Olivier Chapuis <[email-masked]>
Date: Wed, 20 Dec 2000 16:32:15 +0100

CVS wrote:
> 
> CVSROOT:        /home/cvs/fvwm
> Module name:    fvwm
> Changes by:     olicha  00/11/28 05:23:13
> 
> Modified files:
>         fvwm           : placement.c
>         .              : ChangeLog
> 
> Log message:
> A try for a final clever placement algo

Dominik,
Do you like this clever placement algo?
Olivier
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 21 Dec 2000 05:21:05 +0100

> Do you like this clever placement algo?

Sorry, I didn't look at it yet.  Can you explain what's new,
please?

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 22 Dec 2000 06:23:48 +0100

> Sorry, I didn't look at it yet.  Can you explain what's new,

I restore the old code (% is rereplaced by real size), but I add:
1. an "avoidance factor": if a window is almost completely covered
(95%) then its size is multiplied by 6 (this factor will be 
configurable in default.h at compile time as the other clever
placement factor).
2. The algo try more position (a 20x20 grid is added to the old
values).
So, this algo work really as the old algo but try to not cover
small windows. In particular, its work as the old algo for the
situations you mention when you ask for restoring the old algo.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 31 Dec 2000 10:28:56 +0100

> situations you mention when you ask for restoring the old algo.

To be honest I find it even more disturbing now :-)  Before I
could at least understand why my windows were placed in the middle
of the screen.  Now they are placed near the left edge and most of
the time prominently over my button bar which is sticky and should
be avoided if possible.

The new algorithm is certainly valid.  But there are people like
me who don't like the idea behind it:  I *want* my windows to be
completely covered by new windows.  If my screen looks like this:

  +---------------------+  <-- viewport
  |+---------+---------+|
  ||         |         ||
  ||    A    |    B    ||
  ||         |         ||
  |+---------+---------+|
  ||         |         ||
  ||    C    |    D    ||
  ||         |         ||
  |+---------+---------+|
  +---------------------+

with windows A-D which all have the same size, you would like a
new window E (also same size) here:

  +---------------------+  <-- viewport
  |+---------+---------+|
  ||         |         ||
  ||    +---------+    ||
  ||    |         |    ||
  |+----|    E    |----+|
  ||    |         |    ||
  ||    +---------+    ||
  ||         |         ||
  |+---------+---------+|
  +---------------------+

and I want it here:

  +---------------------+  <-- viewport
  |+---------+---------+|
  ||         |         ||
  ||    E    |         ||
  ||         |         ||
  |+---------+---------+|
  ||         |         ||
  ||         |         ||
  ||         |         ||
  |+---------+---------+|
  +---------------------+

So in the end it's not about finding the right tuning of the new
placement algorithm.  What we have to decide is:

 1) Will the new placement code be disabled and taken care of
    after 2.4?
 2) If not, will it be the default and what should the syntax
    to switch between the old and the new method look like so that
    we don't have to change it again after 2.4.

In either case, the old algorithm should still be in the code.
If the new algorithm is not disabled, you can do with it what you
want since I won't use it anyway.

Personally, my answer to 1 depends on if we can find a proper
syntax.  If not, then I'd rather take it out, if yes, then I'd
make the old algorithm the default (not because it's any better
but because if we change it again with the next release, users
will hate us).  At the moment, we have three algorithms coded in
two bits, so there would be room for another one.  I'd rather not
continue this naming scheme "Dumb", "Smart", "Clever" with
"HighlyIntelligent" or so :-)

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 31 Dec 2000 14:53:29 +0100

> the time prominently over my button bar which is sticky and should

The sticky avoid factor is 1 and was always 1 (old, new and current code).
It is not clear that we have to change this factor: for a sticky
"normal" app the factor of 1 is good I think, but for a "dock" app
(in the wm-spec terminology) as your Buttons the factor should be some
thing like 6. Some factors as PLACEMENT_AVOID_STICKY 1, 
PLACEMENT_AVOID_ONTOP 5 and PLACEMENT_AVOID_ICON 10 are defined
as you surely known in libs/default.h

> completely covered by new windows.  

So, you must not use CleverPlacement. The *original* idea of
CleverPlacement was to not cover old window by new windows. I
change the code because the original code fail with small
windows and I found that using % in place pixels size was really
better. I still think that "new" code (not the current one)
was not so bad and that the "old" one was unusable because it
always cover small apps (as a pager or a "dock" app).
Of course the above it just an opinion ...

> If my screen looks like this:
> 

Seems clever for me, the placement code do not know with which
old windows you want to work with and do its best.

>   +---------------------+  <-- viewport

Yes, why not, the old code will gives this if your 4 windows really
cover all the screen.
 
> "HighlyIntelligent" or so :-)

Ok, I am for the 2) solution, we just have to add an optional
argument to Clever, without argument we will have the old
placement code, with argument "A" we will also have the old code,
with argument "P" we will have the new code (and the current
code which is bastard will be removed). In the future we may
add others clever placement algorithm, the "D" algorithm, the
"H" algorithm ... A letter is not so bad for naming an algo as
it is difficult to determine which algo is the best. Moreover,
when FVWM will have its own interpretation/implementation of 
the wm-spec a better turning of these algorithms will be possible
(as currently a "fine" turning can be done at compile time by
editing libs/default.h). 

Of course I am ready to do the code before 2.4.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 31 Dec 2000 17:26:41 +0100

> CleverPlacement was to not cover old window by new windows.

I don't know what the idea behind CleverPlacement was, but
if SmartPlacement can't place a window without overlapping other
windows, it falls back to ActivePlacement or RandomPlacement which
is unusable for me.  One thing I like about the original
CleverPlacement is that it tries hard to use up all free
desktop space first.

> I change the code because the original code fail with small

I didn't say the code was bad.  I said the code does not match my
needs.  I don't have small windows, so this isn't a problem for
me.

> >   +---------------------+  <-- viewport

1)

> old windows you want to work with and do its best.

2)

> Yes, why not, the old code will gives this if your 4 windows really

I prefer to cover as few windows as possible.  With (1) I have to
raise 4 of the 5 windows to work with them, with (2) I can work
with 4 of the 5 windows right away and would shade window E to get
to window A.  I rarely work with partially covered windows.

Of course I'd prefer if the currently focused window is never
covered by a new window.

> it is difficult to determine which algo is the best.

Hm, I'd rather not start a new syntax that may be thrown away
again soon.  I thought we will make all these explicit avoidance
factors configurable, and then this add-a-letter approach will not
work anyway.  A proper name for the new algorithm should be
enough.  The whole idea of naming placement algrithms after their
'cleverness' is braindead anyway.  Right now we have these
possible combinations:

  Dumb + Random
  Dumb + Active
  Smart + Random
  Smart + Active
  Clever + Random
  Clever + Active

plus the new style:

  New + Random
  New + Active

which is idiotic because only 6 of them are different:

  a) Random = Dumb + Random
  b) Active = Dumb + Active
  c) Smart with fallback to Random = Smart + Random
  d) Smart with fallback to Active = Smart + Active
  e) Clever = Clever + Random = Clever + Active
  f) New = New + Random = New + Active

I would rename all of these so that they say something about what
they actually do:

  a) Cascade
  b) Manual
  c) TileCascade
  d) TileManual
  e) MinOverlap (feel free to find a better name)
  f) MinOverlapPercent (dito)

Perhaps, if we agree that this is a good thing, we should do it
before 2.4 since we already started modifying the placement
options with CleverPlacement.  The code chages will be fairly
simple.

> Moreover,

What is the connection between the wm-spec and placement?

> Of course I am ready to do the code before 2.4.

Whoa, rather not open this can of worms now.

Bye

Dominik ^_^  ^_^