Re: FVWM: initialmapcommand with restart
On Tue, Mar 16, 2010 at 08:46:35PM +, David Chanters wrote: > hi. > > i see in the cvs changelog for fvwm that the initialmapcommand doesnt > now run on restart of fvwm. > > i liked this feature to remind me a restart had happened and that some > windows got "hidden" for free > > can i have the old feature back? No, I am afraid not. Before I fixed it, it was broken. I can't even think of what you mean when you say "hidden". I suppose you can use something like this: DestroyFunc ExitFunction AddToFunc ExitFunction + I Test (ToRestart) All (SomeApp) Iconify But that's a really specific use-case, and may well just prove more silly when the iconified window is recaptured by FVWM on restart anyway (due to the window potentially receiving an icon, etc.) -- depending on what you mean by "hidden" in this case though, as it's anyone's guess. Mind if I ask you something? Either you seem to be singling out the work I am doing on FVWM, or you've got some extremely borderline, and *coincidental* use-cases for the fixes I've been implementing over the last year. Somehow this isn't tallying with me. -- Thomas Adam "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci.
Re: FVWM: initialmapcommand with restart
On 16 March 2010 21:15, Thomas Adam wrote: > No, I am afraid not. Before I fixed it, it was broken. I can't even think i dont like this - can you add an option to keep the old behavior? thanks David
Re: FVWM: initialmapcommand with restart
On 16 March 2010 21:36, David Chanters wrote: > On 16 March 2010 21:15, Thomas Adam wrote: >> No, I am afraid not. Before I fixed it, it was broken. I can't even think > > i dont like this - can you add an option to keep the old behavior? Sorry, but to revert this would just be wrong -- so the answer is "no". I suggest you restate what it is you thought you had with the old (and *broken*) behaviour, and then I will suggest to you: * Ultimately why you were wrong to make that assumption. * An alternative solution. Although I suspect, given my previous reply to you, it's going to go unheeded. -- Thomas Adam
Re: FVWM: initialmapcommand with restart
On 17 March 2010 15:53, Thomas Adam wrote: > On 16 March 2010 21:36, David Chanters wrote: >> On 16 March 2010 21:15, Thomas Adam wrote: >>> No, I am afraid not. Before I fixed it, it was broken. I can't even think >> >> i dont like this - can you add an option to keep the old behavior? > > Sorry, but to revert this would just be wrong -- so the answer is "no". i find this unreasonable. i liked the old behavior because if i had put the window minimized when fvwm restarted it wouldnt be minimized anymore. so please revert this - or get someone else to do it if you cant David
Re: FVWM: initialmapcommand with restart
David Chanters writes: > On 17 March 2010 15:53, Thomas Adam wrote: >> On 16 March 2010 21:36, David Chanters wrote: >>> On 16 March 2010 21:15, Thomas Adam wrote: No, I am afraid not. Before I fixed it, it was broken. I can't even think >>> >>> i dont like this - can you add an option to keep the old behavior? >> >> Sorry, but to revert this would just be wrong -- so the answer is "no". > > i find this unreasonable. i liked the old behavior because if i had > put the window minimized when fvwm restarted it wouldnt be minimized > anymore. > > so please revert this - or get someone else to do it if you cant Maybe you should describe what you want again. The way I understand your request, you are asking for Fvwm to un-minimize windows on a restart. Fvwm is supposed to restore windows to their previous state and position on a restart. Doing anything else is a bug.
Re: FVWM: initialmapcommand with restart
On 17 March 2010 22:00, wrote: > The way I understand your request, you are asking for Fvwm to > un-minimize windows on a restart. or any window that id used initialmapcommand on - it was useful if id done something to these windows to put them in their original state when restarting fvwm > Fvwm is supposed to restore windows to their previous state and position > on a restart. Doing anything else is a bug. so i keep being told but i think thats unacceptable David
Re: FVWM: initialmapcommand with restart
> The way I understand your request, you are asking for Fvwm > to un-minimize windows on a restart. That's the impression I got, also. > Fvwm is supposed to restore windows to their previous state > and position on a restart. Doing anything else is a bug. Perhaps the OP needs to put a command in RestartFunction to DeIconify all windows?
Re: FVWM: initialmapcommand with restart
On 17 March 2010 22:10, David Chanters wrote: > On 17 March 2010 22:00, wrote: >> The way I understand your request, you are asking for Fvwm to >> un-minimize windows on a restart. > > or any window that id used initialmapcommand on - it was useful if id > done something to these windows to put them in their original state > when restarting fvwm > >> Fvwm is supposed to restore windows to their previous state and position >> on a restart. Doing anything else is a bug. > > so i keep being told but i think thats unacceptable also - why isnt anyone peer-reviewing these changes? these decisions need discussion - no one seems to do that - why is any idiot allowed to commit changes like this without discussion? David
Re: FVWM: initialmapcommand with restart
On Wed, Mar 17, 2010 at 03:14:43PM -0700, Perry Hutchison wrote: > Perhaps the OP needs to put a command in RestartFunction to > DeIconify all windows? No! Not RestartFunction. Please. Use: AddToFunc StartFunction I Test (Restart) Foo You *only* need RestartFunction if you're using FVWM 2.4.X -- which for most people is unlikely. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci.
Re: FVWM: initialmapcommand with restart
On Wed, Mar 17, 2010 at 10:10:35PM +, David Chanters wrote: > On 17 March 2010 22:00, wrote: > > The way I understand your request, you are asking for Fvwm to > > un-minimize windows on a restart. > > or any window that id used initialmapcommand on - it was useful if id > done something to these windows to put them in their original state > when restarting fvwm Well, you could cheat. If you knew you had groups of windows which you had toggleable actions on, such as Iconify and Maximize, then you could make use of State to assign those actions, such as: Style foo State 1, InitialMapCommand Iconify Style bar State 2, InitialMapCommand Maximize AddToFunc StartFunction + I Test (Init) Exec exec foo + I Test (Init) Exec exec bar + I Test (Init) Break + I All (State 2) Iconify + I All (State 3) Maximize So, any windows with State 1, will be uniconified on restart, otherwise they start iconic. Likewise for State 2, for unmaximizing windows on restart. There are timing issues here in terms of foo and bar starting up before the "Break" statement runs -- see the wiki on FunctionSynchronisation on how to potentially solve this. But ought not to be too much of a problem. Ideally, a more stateful approach using WindowStyle might be appropriate, but it won't work since when the window is recaptured by FVWM on restart, the same windowid is used, as the window is already mapped. Obviously. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci.
Re: FVWM: initialmapcommand with restart
On Wed, Mar 17, 2010 at 10:15:00PM +, David Chanters wrote: > also - why isnt anyone peer-reviewing these changes? these decisions > need discussion - no one seems to do that - why is any idiot allowed > to commit changes like this without discussion? Because this idiot knew it was the right thing to do? Getting defensive and potentially hostile over something isn't going to really motivate people to help you -- although see my previous reply to you anyway -- call it a good-will gesture on my part to help you resolve your previous reliance on broken behaviour. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci.
Re: FVWM: initialmapcommand with restart
David Chanters writes: > On 17 March 2010 22:10, David Chanters wrote: >> On 17 March 2010 22:00, wrote: >>> The way I understand your request, you are asking for Fvwm to >>> un-minimize windows on a restart. >> >> or any window that id used initialmapcommand on - it was useful if id >> done something to these windows to put them in their original state >> when restarting fvwm >> >>> Fvwm is supposed to restore windows to their previous state and position >>> on a restart. Doing anything else is a bug. >> >> so i keep being told but i think thats unacceptable > > also - why isnt anyone peer-reviewing these changes? these decisions > need discussion - no one seems to do that - why is any idiot allowed > to commit changes like this without discussion? As I said, that was not a change, that was a fix. Your comments about the Fvwm development process are incorrect. Your use of the term "any idiot" is bad manners.
Re: FVWM: initialmapcommand with restart
On 17 March 2010 23:16, Thomas Adam wrote: > On Wed, Mar 17, 2010 at 10:10:35PM +, David Chanters wrote: >> On 17 March 2010 22:00, wrote: >> > The way I understand your request, you are asking for Fvwm to >> > un-minimize windows on a restart. >> >> or any window that id used initialmapcommand on - it was useful if id >> done something to these windows to put them in their original state >> when restarting fvwm > > Well, you could cheat. If you knew you had groups of windows which you had > toggleable actions on, such as Iconify and Maximize, then you could make use > of State to assign those actions, such as: this works but is a lot of effort for me to do. can you provide an alternative? or just revert to the old behavior? i prefer the old behavior David
Re: FVWM: initialmapcommand with restart
David Chanters writes: > On 17 March 2010 23:16, Thomas Adam wrote: >> On Wed, Mar 17, 2010 at 10:10:35PM +, David Chanters wrote: >>> On 17 March 2010 22:00, wrote: >>> > The way I understand your request, you are asking for Fvwm to >>> > un-minimize windows on a restart. >>> >>> or any window that id used initialmapcommand on - it was useful if id >>> done something to these windows to put them in their original state >>> when restarting fvwm >> >> Well, you could cheat. If you knew you had groups of windows which you had >> toggleable actions on, such as Iconify and Maximize, then you could make use >> of State to assign those actions, such as: > > this works but is a lot of effort for me to do. > > can you provide an alternative? or just revert to the old behavior? > > i prefer the old behavior Well in that case why not start a fork?! Call it fvwmBP (bug-preserver) Go back to the last release which contained your preferred behaviour and go from there - the source is available after all, this is open-source software. For Thomas to revert just to preserve your favourite bug would be silly - but YOU can do it if you like - isn't freedom wonderful? :-) atb Glyn
Re: FVWM: initialmapcommand with restart
On Wed, Mar 17, 2010 at 11:16:09PM +, Thomas Adam wrote: > On Wed, Mar 17, 2010 at 10:10:35PM +, David Chanters wrote: > > On 17 March 2010 22:00, wrote: > > > The way I understand your request, you are asking for Fvwm to > > > un-minimize windows on a restart. > > > > or any window that id used initialmapcommand on - it was useful if id > > done something to these windows to put them in their original state > > when restarting fvwm > > Well, you could cheat. If you knew you had groups of windows which you had > toggleable actions on, such as Iconify and Maximize, then you could make use > of State to assign those actions, such as: > > Style foo State 1, InitialMapCommand Iconify > Style bar State 2, InitialMapCommand Maximize > > AddToFunc StartFunction > + I Test (Init) Exec exec foo > + I Test (Init) Exec exec bar > + I Test (Init) Break > + I All (State 2) Iconify > + I All (State 3) Maximize s/State 2/State 1/ s/State 3/State 2/ Sorry about that, I got ahead of myself. :P > So, any windows with State 1, will be uniconified on restart, otherwise they > start iconic. Likewise for State 2, for unmaximizing windows on restart. > > There are timing issues here in terms of foo and bar starting up before the > "Break" statement runs -- see the wiki on FunctionSynchronisation on how to > potentially solve this. But ought not to be too much of a problem. > > Ideally, a more stateful approach using WindowStyle might be appropriate, > but it won't work since when the window is recaptured by FVWM on restart, > the same windowid is used, as the window is already mapped. Obviously. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci.
Re: FVWM: initialmapcommand with restart
David Chanters writes: > On 18 March 2010 07:10, Glyn Millington wrote: >> Well in that case why not start a fork?! Call it fvwmBP (bug-preserver) >> Go back to the last release which contained your preferred behaviour and >> go from there - the source is available after all, this is open-source >> software. For Thomas to revert just to preserve your favourite bug would >> be silly - but YOU can do it if you like - isn't freedom wonderful? :-) > > what steps in cvs would i need to do this please? where do i host it as well? Instructions for cvs are here http://www.fvwm.org/documentation/dev_cvs.php Hosting is up to you :-) atb Glyn
Re: FVWM: initialmapcommand with restart
David Chanters writes: > On 18 March 2010 22:47, Glyn Millington wrote: >> David Chanters writes: >> >>> On 18 March 2010 07:10, Glyn Millington wrote: Well in that case why not start a fork?! Call it fvwmBP (bug-preserver) Go back to the last release which contained your preferred behaviour and go from there - the source is available after all, this is open-source software. For Thomas to revert just to preserve your favourite bug would be silly - but YOU can do it if you like - isn't freedom wonderful? :-) >>> >>> what steps in cvs would i need to do this please? where do i host it as >>> well? >> >> Instructions for cvs are here >> >> http://www.fvwm.org/documentation/dev_cvs.php > > i meant how do i use cvs to revert this silly fix to get the behavior i want? You work it out yourself. Or you go to ftp://ftp.fvwm.org/pub/fvwm/version-2/ and you go back a release or two, before this bug was fixed. Simple. You are asking (rudely) for a reversion which no-one else seemingly wants. The maintainer has given his reasons for not wishing to revert the bugfix. Seems to me you either put up (code) or just put up with it. atb Glyn
