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 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 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
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 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 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
> 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: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
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 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
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