Subject: things to be done for 2.6

From: [email-masked]
Date: Sun, 8 Dec 2002 13:10:16 +0100

Here is a list of things that I think have to be done before 2.6
that you may not be aware of.  I write them here specfically
because I will most likely do none of them.  My reasoning is:
nobody is maintaining these features or taking care of them,  and
2.6 is meant to be a *stable* release.  But of course you can do
what you want with them - it's all code under GPL.

 * Remove tear off menus.  Either that or finish the menu rewrite
   (to allow full operation without grabbing pointer or keyboard
   from within menus).  There is still some unfinished code in
   menus.c.
 * Remove Key release bindings.  Does not work reliably.
 * Rename FvwmProxy.
 * Either rewrite the FvwmProxy placement algorithm to give decent
   results (no hangs; all proxy windows visible even on very full
   pages; placement must work with sticky windows and windows on
   other pages too) - or remove FvwmProxy.
 * Rename FvwmWindowLister.  The naming of the window listing
   features is becoming very confusing.
 * Either enhance FvwmWindowLister to replace the built-in
   WindowList command or remove it.
 * Remove the new internal event and command interface.  I suggest
   to back out the code by moving back to the 2.5.3 code base and
   re-apply all patches.  The changes were too big to catch all of
   them.
 * Remove the --disable-ewmh and --disable-gnome-hints configure
   options.

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: Dan Espen <[email-masked]>
Date: Sun, 08 Dec 2002 10:05:35 -0500

>    from within menus).  There is still some unfinished code in

I'd hate to see tear off menus go away.

I use them and they seem to be problem free.

Just as important, tear off menus are one of the comparison points
on the window managers page.  Its an important feature from a
visibility point of view.

If they are causing a problem, I don't see it.  In this case,
I think you are setting your standards too high.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Marcus Lundblad <[email-masked]>
Date: Mon, 9 Dec 2002 00:30:21 +0100 (CET)

> I use them and they seem to be problem free.

Actually one problem is that new windows appear only after leaving the
menu. If a menu item causes a new window to popup.
I haven't looked any at the menu code, but I guess the event loop for
menus don't check for this. With normal menus this is probably not a
problem since the menu gets unposted at the time of the click

//Marcus

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 9 Dec 2002 00:27:27 +0000

>    from within menus).  There is still some unfinished code in

Although I can see potential compromise of stability in the core when
multiple (or even single) tear off menus are open, this feature is not
mandatory. I think we may mark it experimental and/or partial if you want.

If you are strong about removing anything, I suggest to remove the default
key and mouse bindings that revert a menu to a tear off. So only explicit
TearMenuOff will work (and it also adds Backspace hot key). Or maybe,
instead, introduce a command MenuWindow that starts a menu in a window.

As for me, the things as they are now are pretty good. I run with many
complex menus open on the screen for several hours now and it is ok.
Of course some things are pretty unusual regarding what happens when a
pointer leaves a submenu as compared to normal submenus. But it's ok.
The only problem is that no bindings (W or A, key or mouse) seem to work
inside tear off menu windows. Also if you start a window from such menu,
you should leave it to see a window. This is not critical.

>  * Remove Key release bindings.  Does not work reliably.

Here I probably agree. I myself can't use key releases, because they make
some applications unhappy. This is a good feature and I would like to have
it, but it is currently not very usable and I am not sure it is possible
to implement it without conflicts.

>    other pages too) - or remove FvwmProxy.

This is why I don't want to mix modules and the core.
Modules may be buggy (we had really buggy, sometimes crashing FvwmIconMan,
FvwmTaskBar and some others for years), but the core is still stable.
Of course if FvwmProxy makes X hang it is another story...

I don't have an opinion about removing or leaving this module.

My stance is simple. If it is a mandatory extension to the core, I am
against it, if it is a usual module, like FvwmDragWell or FvwmScroll,
and the author is willing to maintain it, it is perfectly fine with me.
I personally can't think yet how it can be useful to me.
(But I also don't see how 15 more modules are useful for me and I don't
want to remove any of them for 2.6.x except for maybe FvwmSave[Desk]).

>    features is becoming very confusing.

What would be a better name for you?
We have modules with different functionality, IMHO it is good.

FvwmIconBox - pretty unique, shows normal icons, I think it is ok as is.

FvwmIconMan, FvwmTaskBar, FvwmWinList - persisting graphical modules.
They may be replaced in the future by one module, FvwmWindowBar (?).

FvwmProxy - transient non table list, it may be called FvwmWindowProxies.

FvwmWindowLister - transient table list, may be called FvwmWindowListing.

All these modules do different things, and I think there may be more
modules that work with the window list (think FvwmPager).

If we have these names in the future, is it less confusing?

  FvwmWindowBar
  FvwmWindowProxies
  FvwmWindowListing

>    WindowList command or remove it.

WindowList simply can't be removed in 2.6.x, because all user
configurations use it. But this does not mean that FvwmWindowLister
that answers some user requests should be removed. It is possible
to implement all the current WindowList functionality, but I don't
think this is urgent, because WindowList is not going to be removed.
I also don't think WindowList should be replaced with a call to
FvwmWindowLister (effectivelly making it a mandatory extension).

I think we should freeze WindowList features. Then to discuss after
2.6.0 whether to do something about WindowList depending on what
FvwmWindowLister may offer to that time.

Really, I don't see a problem to have both, one internal and one external
for some fancy features. Personally I need FvwmWindowLister for several
reasons, first - to answer all requests that want some fancy WindowList,
second is to have a regular module to test new perllib features on it.
I also have some unfinished patch to FvwmWindowLister that shows a window
list horizontally using GTK+ (if available and if requested) instead of
fvwm menus. I don't know yet whether I will include it or not.

>    re-apply all patches.  The changes were too big to catch all of

I would like to find another solution than to go back to the 2.5.3.

What are the problems with a new interface except maybe that it is not
finished?

>  * Remove the --disable-ewmh and --disable-gnome-hints configure

I am not sure it is bad to have these. But since you seem to have a
strong willing to remove them, they may be removed.
Olivier said he may do this. If not, I may do this later.

I will post my todo list for 2.6.x later in December.
I will also try to find a time to report some bugs.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Sun, 08 Dec 2002 19:35:03 -0500

> problem since the menu gets unposted at the time of the click

I stand corrected.
I've only been using it for my window operations menu.
That does seem like a problem.

---

From: [email-masked]
Date: Mon, 9 Dec 2002 03:02:31 +0100

> instead, introduce a command MenuWindow that starts a menu in a window.

Well, these are only suggestions.  I don't know if and which parts
will be removed.

> inside tear off menu windows.

Hardly - with the whole keyboard grabbed ...  The menu code simply
does not belong into the core.

> Also if you start a window from such menu,

[snip]

> Of course if FvwmProxy makes X hang it is another story...

Nobody suggested to mix FvwmProxy and the core.

> and the author is willing to maintain it, it is perfectly fine with me.

As a module in a stable release, it should not have known problems
that make it useless in certain situation.  At least it can hang
the module interface for 30 seconds and eat a lot of cpu before
being killed.  The proxy placement algorithms is a loop that seems
to have some potential for looping eternally.  It's fine as a
module, but it does not belong in a stable release if it isn't
stable.

> We have modules with different functionality, IMHO it is good.

  FvwmWinList - WindowList - FvwmWindowLister

That is confusing.  Perhaps FvwmWindowMenu.  (I prefer
FvwmCodeDuplicator, though ;-)

> configurations use it.

Well, then let it suffice to say that I believe the current path
of generating module and code duplication will bite future
developers.  Maintenance is already a nightmare and getting worse
with every line that duplicates what another already does.

[snip]

> What are the problems with a new interface except maybe that it is not

It is finished, and I know of no problems.  As nobody except me
knows how it works and nobody maintains it, it's not a good
candidate for a stable release.  The patches were extremely
disruptive, perhaps even more than the style flag rewrite a couple
of years ago.  Removing it manually would probably cause even more
problems.  But anyway - since it is very unlikely someone
volunteers to do the hard work to remove it, I would not be
surprised if it stays in the code forever.  When that happens,
just don't expect me to fix it.

> I am not sure it is bad to have these.

configure option = conditional compilation = hell to maintain
In my eyes, configure options are a valid choice only for
libraries (include and library path).

> But since you seem to have a

Personally, I plan to stabilize the features I wrote since 2.4.0,
remove the ones that are too unstable, and then think about
whether I see any future in developing fvwm for me or not.  At
least I recognize the possibility that I am overreacting at the
moment.  But as it is now with everybody doing some things without
thinking about the big picture there is little sense in flogging
the dead horse even further.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 9 Dec 2002 03:42:49 +0000

On 09 Dec 2002 03:02:31 +0100, [email-masked] wrote:
> That is confusing.  Perhaps FvwmWindowMenu.

FvwmWindowMenu is good with me, I am just not sure whether it sounds ok:

  SendToModule FvwmWindowMenu Menu

If there are no other suggestions, I will probably rename it later.

> (I prefer FvwmCodeDuplicator, though ;-)

Too long, but maybe to shorten it to FvwmCoder or FvwmCat? :)

> the dead horse even further.

The problem is human resources and it will not be any better if a new
project is started. Anyway, I believe you will make the right decision
and we will see you here, maybe after a good half year vacation.

Also don't forget about the 10 year celebration. :)

Regards,
Mikhael.

---

From: Richard Lister <[email-masked]>
Date: Mon, 09 Dec 2002 16:20:21 -0500 (EST)

Mikhael Goikhman <[email-masked]> wrote on Mon, 9 Dec 2002 00:27:27 +0000:
>
> Subject: Re: things to be done for 2.6
>

I think FvwmABitLikeWindowListButWithSomeFeaturesOfFvwmIconMan :-)

Or FvwmWindowMenu is good too.

> They may be replaced in the future by one module, FvwmWindowBar (?).

I agree that it makes more sense to merge the persistent modules
into a very capable FvwmIconMan.

> FvwmWindowLister - transient table list, may be called FvwmWindowListing.

By its very simplistic design FvwmWindowLister is not easily made
persistent. I wrote it to scratch an itch of mine, but hoped
that by virtue of its simplicity it would remain as a useful
example for power users to adapt to their own specific needs
(as Elliot has already done).

This kind of scripting ability provided by perllib is a major
selling point of fvwm for some people.

To this end I think it would be useful to maintain an archive
of modules (CFAN?), some working but esoteric and some experimental,
separate from the main distribution, which will only contain
well-maintained code.

When I've perpetrated hack-jobs such as FvwmWindowLister and
FvwmPlaceTransient I haven't necessarily intended them to
go into the distribution, but would like others to be able to
find them easily, play with them, and adapt them.

(On a side note, I still think configurable transient placement
would be a great addition to the core, but there are design issues
to discuss.)

> fvwm menus. I don't know yet whether I will include it or not.

Should that be an extension to FvwmWindowLister or a separate
module in an online archive?

Just my 2 cents.
Ric

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 14 Dec 2002 07:33:55 +0100

>    from within menus).  There is still some unfinished code in

Humm ..., you start to write this code. If you do not want to finish
it during the freeze, I think it will be more safe that _you_ disable
this code by using "#ifdef" (as you know it). Using "#ifdef" will
allow to finish this code after 2.6.

>    re-apply all patches.  The changes were too big to catch all of

If this code is ok and finished I do not think we should move back to
2.5.3.  If a bug is found in this code at some point, then the
fvwm-workers will try to fix it.

>  * Remove the --disable-ewmh and --disable-gnome-hints configure

I will do this (beginning of 2003).

Olivier

---

From: Dan Espen <[email-masked]>
Date: Sat, 14 Dec 2002 08:51:44 -0500

> allow to finish this code after 2.6.

I don't think we need Dominik to disable it,
its pretty clear where the #ifdef would go.
(Around line 4663 in menus.c.)