[Solved and learned something] Re: FVWM: How to bring FvwmIdent onto layer 6 [Was: FvwmIdent disappears very often]
Michael Großer wrote: > When I only set "*FvwmIdent: MinimalLayer 6" without > the Style commands, though the FvwmIdent window > appears on layer 6, but the vector buttons in the window > decorations, wich I draw with ButtonStyle in my > "0001_window_decorations" config file, do not > get refreshed. They will get refreshed when I focus > another window. Setting the styles I need anyway > (StaysOnTop + NeverFocus) prevents this sort of laziness > of the vector buttons. This is a bug I know for months, > and I use "Stick" "Stick" to work around this. > Since I have a workaround, I would classify this > bug as "it would be nice if someone would fix it". I discovered the "Refresh" function today :-) My "Stick Stick" workaround seems to be obsolet from now on. http://www.fvwm.org/doc/unstable/fvwm/fvwm.man.html#delayed_execution_of_commands > 27.2. Delayed Execution of Commands > > Note: There are many commands that affect look and > feel of specific, some or all windows, like Style, > Mouse, Colorset, TitleStyle and many others. For > performance reasons such changes are not applied > immediately but only when fvwm is idle, i.e. no user > interaction or module input is pending. Specifically, > new Style options that are set in a function are not > applied until after the function has completed. This > can sometimes lead to unwanted effects. > > To force that all pending changes are applied > immediately, use the UpdateStyles, Refresh or > RefreshWindow commands. Nice Feature :-)
Re: FVWM: Want an alt-tab behaviour like KDE3
hi, 2012/1/19 Jason Weber : > Perhaps if you are open minded to tools that might be more effective > at navigating > windows than KDE or others do, I would also suggest taking a look at the > FvwmProxy. It is a bit of a departure from the uncorrelated > box-in-the-middle paradigm. > It can handle your (1) and (2), but for (3), the tab order is > generally spatial, not historical. > For me, this is far more intuitive, but I can not assert that the same > would be true for anyone else. would you mind giving an overview of how you use fvwmproxy? ive read the man page but its not clear other than how to get it show the proxy windows how you could use as an effective alt-tab replacement... im sure ive seen people use it as a fvwmtabs replacement? is that possible? Harry
Re: [Solved and learned something] Re: FVWM: How to bring FvwmIdent onto layer 6 [Was: FvwmIdent disappears very often]
On Fri, Jan 20, 2012 at 09:37:07PM +0100, Michael Großer wrote:
> Michael Großer wrote:
> > When I only set "*FvwmIdent: MinimalLayer 6" without
> > the Style commands, though the FvwmIdent window
> > appears on layer 6, but the vector buttons in the window
> > decorations, wich I draw with ButtonStyle in my
> > "0001_window_decorations" config file, do not
> > get refreshed. They will get refreshed when I focus
> > another window. Setting the styles I need anyway
> > (StaysOnTop + NeverFocus) prevents this sort of laziness
> > of the vector buttons. This is a bug I know for months,
> > and I use "Stick" "Stick" to work around this.
> > Since I have a workaround, I would classify this
> > bug as "it would be nice if someone would fix it".
>
> I discovered the "Refresh" function today :-)
No, you still didn't answer my question. I still don't understand why you
need Refresh here,
> > Note: There are many commands that affect look and
> > feel of specific, some or all windows, like Style,
> > Mouse, Colorset, TitleStyle and many others. For
> > performance reasons such changes are not applied
> > immediately but only when fvwm is idle, i.e. no user
> > interaction or module input is pending. Specifically,
> > new Style options that are set in a function are not
> > applied until after the function has completed. This
> > can sometimes lead to unwanted effects.
> >
> > To force that all pending changes are applied
> > immediately, use the UpdateStyles, Refresh or
> > RefreshWindow commands.
>
> Nice Feature :-)
But not needed anymore. I wouldn't confuse the two.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
[no question - only progress] Re: FVWM: Want an alt-tab behaviour like KDE3
Jason Weber wrote: > 2012/1/19 Thomas Adam : >> On Wed, Jan 18, 2012 at 10:31:25PM +0100, Michael Großer wrote: >>> I want an alt-tab behaviour like KDE3: >> >> Great. >> >> [...] >> >>> At first glance, I see these modules: >>> - WindowList >>> - FvwmIconMan >>> - FvwmWinList >>> - FvwmWindowMenu >>> >>> Are there more like them that could be worth of thinking about using >>> or abusing them? >> >> Absolutely not. >> >> What you're asking for is so specific it would have to be its own module. >> >> -- Thomas Adam > > Michael, > > Perhaps if you are open minded to tools that might be more effective > at navigating > windows than KDE or others do, I would also suggest taking a look at the > FvwmProxy. It is a bit of a departure from the uncorrelated > box-in-the-middle paradigm. > It can handle your (1) and (2), but for (3), the tab order is > generally spatial, not historical. > For me, this is far more intuitive, but I can not assert that the same > would be true for anyone else. > > -- Jason Weber > > You extended my collection of options. Thank you for that! I don't know if I want a spatial approach when I use Alt-Tab (or Win-Tab). Probably not, because I already use a spatial approach by using 12*12*3 = 432 viewports (pages, desktops - call it how you want). Usually, I have few windows on one page. Mostly one or two. Sometimes three. When I go somewhere more deeply into detail than planned, then a page can contain considerably more windows. Some windows can contain some or a lot of tabs if they are web-browser windows. In the cases when a page has more (or considerably more) than one window, I prefer a historical approach. But, I will inspect FvwmProxy during the next years, because the concept looks interesting. Perhaps I could use it for an unknown purpose when I gathered experiences with it. Today I digged out an old idea from Tue, 23 Mar 2004 09:00:54 -0800 from Piotr Zielinski to get an FvwmIconMan when I press Win+Tab and kill it when I release the Win key: http://www.mail-archive.com/fvwm@hpc.uh.edu/msg06089.html The chances increase that I indeed could get an KDE3 behaviour during the next days. - Michael -
Re: [Solved and learned something] Re: FVWM: How to bring FvwmIdent onto layer 6 [Was: FvwmIdent disappears very often]
Thomas Adam wrote: > On Fri, Jan 20, 2012 at 09:37:07PM +0100, Michael Großer wrote: >> Michael Großer wrote: >> > When I only set "*FvwmIdent: MinimalLayer 6" without >> > the Style commands, though the FvwmIdent window >> > appears on layer 6, but the vector buttons in the window >> > decorations, wich I draw with ButtonStyle in my >> > "0001_window_decorations" config file, do not >> > get refreshed. They will get refreshed when I focus >> > another window. Setting the styles I need anyway >> > (StaysOnTop + NeverFocus) prevents this sort of laziness >> > of the vector buttons. This is a bug I know for months, >> > and I use "Stick" "Stick" to work around this. >> > Since I have a workaround, I would classify this >> > bug as "it would be nice if someone would fix it". >> >> I discovered the "Refresh" function today :-) > > No, you still didn't answer my question. I still don't understand why you > need Refresh here, I have these 9 title-bar buttons: # Bind some decors to the buttons at the left side ButtonStyle 1 - Clear MwmDecorMenu ButtonStyle 3 - Clear MwmDecorStick ButtonStyle 5 - Clear MwmDecorLayer 6 ButtonStyle 7 - Clear MwmDecorLayer 4 ButtonStyle 9 - Clear MwmDecorLayer 2 # Bind some decors to the buttons at the right side ButtonStyle 2 - Clear ButtonStyle 4 - Clear MwmDecorMax ButtonStyle 6 - Clear MwmDecorMin ButtonStyle 8 - Clear MwmDecorShade I made a screenshot to show them in real live. Button 5, 7 and 9 show me the layer of a respective window (and I can change the layer by klicking one of the buttons). When I write > *FvwmIdent: MinimalLayer 6 into my config, then FVWM brings FvwmIdent onto layer 6, but the buttons do not always indicate that FvwmIdent is on layer 6. Sometimes, layer 4 or both layer 4 and layer 6 are optically latched. The reality may be OK, but the visual effect is not OK. When I use StaysOnTop and NeverFocus, then also the visual effect is Ok. I suppose that the "Refresh" function was invented for this kind of trouble. I don't know how a current FVWM version reacts, I'm still too impatient and use FVWM 2.5.26 instead of using a new version, because the other to-do list is long and using a current version of FVWM is somewhere in the middle of the other to-do list, where I go a clean way and take one thing at a time. Question answered? >> > Note: There are many commands that affect look and >> > feel of specific, some or all windows, like Style, >> > Mouse, Colorset, TitleStyle and many others. For >> > performance reasons such changes are not applied >> > immediately but only when fvwm is idle, i.e. no user >> > interaction or module input is pending. Specifically, >> > new Style options that are set in a function are not >> > applied until after the function has completed. This >> > can sometimes lead to unwanted effects. >> > >> > To force that all pending changes are applied >> > immediately, use the UpdateStyles, Refresh or >> > RefreshWindow commands. >> >> Nice Feature :-) > > But not needed anymore. I wouldn't confuse the two. Which "two" do you meam? Today, I solved a problem using "Refresh" during my attempts to build a KDE3 like alt-tab behaviour. If it is superfluous in later FVWM versions, I can still omit it in the future, but today, I needed it. <>
Context [Re: [Solved and learned something] Re: FVWM: How to bring [...]]
Michael Großer wrote: > Thomas Adam wrote: >> On Fri, Jan 20, 2012 at 09:37:07PM +0100, Michael Großer wrote: >>> Michael Großer wrote: >>> > Note: There are many commands that affect look and >>> > feel of specific, some or all windows, like Style, >>> > Mouse, Colorset, TitleStyle and many others. For >>> > performance reasons such changes are not applied >>> > immediately but only when fvwm is idle, i.e. no user >>> > interaction or module input is pending. Specifically, >>> > new Style options that are set in a function are not >>> > applied until after the function has completed. This >>> > can sometimes lead to unwanted effects. >>> > >>> > To force that all pending changes are applied >>> > immediately, use the UpdateStyles, Refresh or >>> > RefreshWindow commands. >>> >>> Nice Feature :-) >> >> But not needed anymore. I wouldn't confuse the two. > > Which "two" do you meam? I understood: Right! For each purpose you have to choose the right tool. Either UpdateStyles or Refresh. It depends on the context.
Re: [Solved and learned something] Re: FVWM: How to bring FvwmIdent onto layer 6 [Was: FvwmIdent disappears very often]
On Fri, Jan 20, 2012 at 10:42:41PM +0100, Michael Großer wrote:
> # Bind some decors to the buttons at the left side
> ButtonStyle 1 - Clear MwmDecorMenu
> ButtonStyle 3 - Clear MwmDecorStick
> ButtonStyle 5 - Clear MwmDecorLayer 6
> ButtonStyle 7 - Clear MwmDecorLayer 4
> ButtonStyle 9 - Clear MwmDecorLayer 2
>
> # Bind some decors to the buttons at the right side
> ButtonStyle 2 - Clear
> ButtonStyle 4 - Clear MwmDecorMax
> ButtonStyle 6 - Clear MwmDecorMin
> ButtonStyle 8 - Clear MwmDecorShade
>
> I made a screenshot to show them in real live.
>
> Button 5, 7 and 9 show me the layer of a respective window
> (and I can change the layer by klicking one of the buttons).
Right. Can you provide a more minimal configuration for this including any
mouse bindings and style lines affecting how the decor is rendered. I note
here you're not using a decor which might explain some of your problems.
But again I can't reproduce this.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: [no question - only progress] Re: FVWM: Want an alt-tab behaviour like KDE3
2012/1/20 Michael Großer : > Jason Weber wrote: >> 2012/1/19 Thomas Adam : >>> On Wed, Jan 18, 2012 at 10:31:25PM +0100, Michael Großer wrote: I want an alt-tab behaviour like KDE3: >>> >>> Great. >>> >>> [...] >>> At first glance, I see these modules: - WindowList - FvwmIconMan - FvwmWinList - FvwmWindowMenu Are there more like them that could be worth of thinking about using or abusing them? >>> >>> Absolutely not. >>> >>> What you're asking for is so specific it would have to be its own module. >>> >>> -- Thomas Adam >> >> Michael, >> >> Perhaps if you are open minded to tools that might be more effective >> at navigating >> windows than KDE or others do, I would also suggest taking a look at the >> FvwmProxy. It is a bit of a departure from the uncorrelated >> box-in-the-middle paradigm. >> It can handle your (1) and (2), but for (3), the tab order is >> generally spatial, not historical. >> For me, this is far more intuitive, but I can not assert that the same >> would be true for anyone else. >> >> -- Jason Weber >> >> > > You extended my collection of options. Thank you for that! > > I don't know if I want a spatial approach when I use Alt-Tab > (or Win-Tab). Probably not, because I already use a spatial approach > by using 12*12*3 = 432 viewports (pages, desktops - call it how you > want). > > Usually, I have few windows on one page. Mostly one or two. > Sometimes three. When I go somewhere more deeply into detail > than planned, then a page can contain considerably more windows. > Some windows can contain some or a lot of tabs if they are > web-browser windows. In the cases when a page has more (or > considerably more) than one window, I prefer a historical > approach. > > But, I will inspect FvwmProxy during the next years, because > the concept looks interesting. Perhaps I could use it > for an unknown purpose when I gathered experiences with it. > > Today I digged out an old idea from > Tue, 23 Mar 2004 09:00:54 -0800 > from Piotr Zielinski to get an FvwmIconMan when I press Win+Tab > and kill it when I release the Win key: > http://www.mail-archive.com/fvwm@hpc.uh.edu/msg06089.html > > The chances increase that I indeed could get an KDE3 behaviour > during the next days. > > > - Michael - > You can see illustrated examples of specific features of FvwmProxy at http://www.munra.com/fvwm/fvwmproxy.html If you have a 400x virtual desktop area, perhaps you never need to worry about windows overlapping, but I would be lost in all that space. I couldn't stand any sliding screen edges and just stick to dancing between 6-10 desks with quick-switch key bindings. I could continue on about where I've gone, but the link above might clarify my approach. I follow your logic of the historical approach and suspect that it would have real advantage over an arbitrarily ordered list. But with how well a solid tightly-correlated spatial approach has served me, I don't think historical data would improve my navigation. It would introduce dependencies on state that is longer true versus giving me an optimized view of everything in current state.. -- Jason Weber
