On 08 Dec 2002 13:10:16 +0100, [EMAIL PROTECTED] wrote: > > 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.
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. > * 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. 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]). > * Rename FvwmWindowLister. The naming of the window listing > 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 > * Either enhance FvwmWindowLister to replace the built-in > 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. > * 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. 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 > options. 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. -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
