On Mon, Dec 09, 2002 at 12:27:27AM +0000, Mikhael Goikhman wrote: > 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.
Well, these are only suggestions. I don't know if and which parts will be removed. > 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. 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, > you should leave it to see a window. This is not critical. [snip] > > * 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... Nobody suggested to mix FvwmProxy and the core. > 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. 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. > 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. FvwmWinList - WindowList - FvwmWindowLister That is confusing. Perhaps FvwmWindowMenu. (I prefer FvwmCodeDuplicator, though ;-) > > * 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. 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] > > * 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? 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. > > * Remove the --disable-ewmh and --disable-gnome-hints configure > > options. > > 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 > 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. 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 ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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]
