Re: FVWM: Controlling initial size of a "gThumb" window

[Michael Großer]

Bob Marcan wrote:
> On Sun, 23 Jun 2019 19:13:19 +0200
> Dr Rainer Woitok  wrote:
>
>> Dan,
>>
>> On Thursday, 2019-06-20 12:12:49 -0400, you wrote:
> ...
>>
>> No.   There are already way too many packages  I install from source be-
>> cause I really need more recent versions than Ubuntu provides or because
>> I have to patch them before compiling.   So as long as I can solve minor
>> anoyances by just adapting  my "fvwm" configuration,  I prefer that over
>> compiling from source.
>>
>> Sincerely,
>>   Rainer
>
> Do you really use the right distribution (Ubuntu) for your need ?
> BR, Bob
>
>

Looks like Gentoo could be the distribution of your choice :-)

Re: FVWM: Is there a way to ignore other windows when placing one?

[Michael Großer]

lee wrote:
> Michael Großer <michael.gros...@gmx.de> writes:
> 
>> Michael Großer wrote:
>>> Dan Espen wrote:
>>>> lee <l...@yagibdah.de> writes:
>>>> 
>>>>> Hi,
>>>>>
>>>>> the subject pretty much says it:
>>>>>
>>>>> Can I somehow make it so that fvwm ignores particular windows when
>>>>> figuring out where to place a new one?
>>>> 
>>>> Not that I know of.
>>>> 
>>>> What are you trying to do?
>>> 
>>> Without awaiting the answer about what is tried to do:
>>> 
>>> If no official way helps, there is always a dirty but "creative"
>>> approach.
>>> 
>>> - Minimize the particular windows that you want to ignore
>>> - Hide their icons
>>> - Place your new window
>>> - Unhide the hidden icons
>>> - Reopen the minimized windows
>>> 
>>> The process would perhaps have an optical effect that is not so good
>>> looking, but the "creative" approach could solve your problem if no other
>>> expert delivers a better solution :-)
>>
>> Another idea:
>>
>> - Move the particular windows to a desktop that solely exists for that 
>> purpose
>> - Place your new window
>> - Move the cleared away windows back to their original place
> 
> Thanks, these are good ideas :)
> 
> I haven't figured out how to use multiple desks, though.  I tried that
> once and apparently got multiple desks just by naming some, but no way
> to switch between them.

In addition to what Dan Espen and Lucio Chiappetti wrote, I could
dig out an old text from me where I described my 7-dimensional approach
of working (how I work until today):
https://www.mail-archive.com/fvwm@fvwm.org/msg02282.html

Then, there is another nice tool apart from FVWM, with wich you can
play around. Try these commands:

# wmctrl -s 0
# xterm -title sun
# wmctrl -s 4
# wmctrl -R sun
# wmctrl -r sun -N moon

Wmctrl is funny, but GotoDesk and GotoDeskAndPage are better, because they
distinguish between viewports (pages) and desks.

> What I'm trying to do is achieving more reasonable window placement.  I
> found that one small window can make it so that a larger window is not
> placed the way I would consider reasonable.  I found that out by
> manually moving the small window around to see what placement I would
> get and concluded that if fvwm would ignore the small window when it
> figures out the placement of the larger one, the larger window would be
> placed well.  So I wondered if I could have fvwm ignore the small
> window.
> 
> Now you suggest to move the small window out of the way automatically
> rather than manually --- something I haven't thought of :)

Can you describe in more detail, which kind of small window is interfering
with what kind of larger window? What is your use case? If there is no
technical approach to solve your wish generally, perhaps another creative
idea could arise to solve your special use cases.

One creative idea could be that you place special windows by yourself
like that:
# xterm -geometry 100x20+0+0 -e "echo \"I'm always top left\";bash"
# xterm -geometry 100x20 -e "echo \"I'm 100x20 and pick my own place\";bash"

Some Linux/Unix programs take arguments like "-geometry", and if your
small and large windows are software like xterm, nedit or the like,
your issues were quickly solved just by giving them "-geometry" arguments
to automatically place them in harmony with each other.

> Is there some way to make it so that a function which moves the small
> window out of the way is always called when fvwm is about to figure out
> where to place a window?

Probably, there is a way, but it is hidden. Thomas Adam made a nice man
page especially for me years ago. I don't know, why that man page was
never published.

Look at the attachments of this e-mail message, and you will find two
documents that officially only exist on my very own computer systems
(at home and at work).

Call this:
# cd your_dir_where_you_saved_my_stuff
# man ./FvwmEvent.1.in

According to that old man page, you should try the 'add_window' event:
--> Runs when a window is initially mapped.

If it does not fit, read the table and evaluate each event in your own
way to find a possibly better one.

How can you use events?

This is how I do it:

> DestroyFunc FvwmEvent_destroy_window
> DestroyFunc FvwmEvent_new_page
> DestroyFunc FvwmEvent_new_desk
> DestroyFunc FvwmEvent_focus_change
>
> *FvwmEvent: destroy_window "Function 'FvwmEvent_destroy_window'"
> *FvwmEvent: new_page   "Function 'FvwmEvent_new_page'"
> *FvwmEvent: n

Re: FVWM: Is there a way to ignore other windows when placing one?

[Michael Großer]

Dan Espen wrote:
> lee  writes:
> 
>> Hi,
>>
>> the subject pretty much says it:
>>
>> Can I somehow make it so that fvwm ignores particular windows when
>> figuring out where to place a new one?
> 
> Not that I know of.
> 
> What are you trying to do?

Without awaiting the answer about what is tried to do:

If no official way helps, there is always a dirty but "creative"
approach.

- Minimize the particular windows that you want to ignore
- Hide their icons
- Place you new window
- Unhide the hidden icons
- Reopen the minimized windows

The process would perhaps have an optical effect that is not so good
looking, but the "creative" approach could solve your problem if no other
expert delivers a better solution :-)

Re: FVWM: Is there a way to ignore other windows when placing one?

[Michael Großer]

Michael Großer wrote:
> Dan Espen wrote:
>> lee <l...@yagibdah.de> writes:
>> 
>>> Hi,
>>>
>>> the subject pretty much says it:
>>>
>>> Can I somehow make it so that fvwm ignores particular windows when
>>> figuring out where to place a new one?
>> 
>> Not that I know of.
>> 
>> What are you trying to do?
> 
> Without awaiting the answer about what is tried to do:
> 
> If no official way helps, there is always a dirty but "creative"
> approach.
> 
> - Minimize the particular windows that you want to ignore
> - Hide their icons
> - Place your new window
> - Unhide the hidden icons
> - Reopen the minimized windows
> 
> The process would perhaps have an optical effect that is not so good
> looking, but the "creative" approach could solve your problem if no other
> expert delivers a better solution :-)

Another idea:

- Move the particular windows to a desktop that solely exists for that purpose
- Place your new window
- Move the cleared away windows back to their original place

Re: FVWM: Force restore of titles and borders on Gnome applications

[Michael Großer]

Dov Grobgeld wrote:
 Hello,
 
 In recent Gnome applications, e.g. gthumb, evince, eog, there has been
 a trend to remove the window manager border and title and do these
 internally in the application. I have been looking for a gnome way
 of turning off this behavior as it seriously destroys my work flow,
 and after failing to do so, I tried to make my prefered window manager
 the last twenty years, fvwm, block these requests, but so far without
 any success.
 
 I have tried the following configuration parameters:
 
 Style *   GNOMEIgnoreHints
 Style *   Title,Handles
 
 But unfortunately these are ignored for the gnome windows that still
 end up with the following properties as can be seen by fvwm identify:
 
 Boundary Width: 0
 NoTitle: Yes
 
 Why are these requests ignored? Is there any other property that can
 be used to force the title and the handles? If not, could someone
 point me to the sources where this request is received and how it is
 handled, and where I could block it?
 
 Thanks!
 Dov
 
 

Hi!

I don't know if this helps you or other FVWM users, and I don't
know how sustainable my solution really is, but...

... some weeks ago, I set up a new productive environment based
on Debian Wheezy (Jessie was not stable yet back then).

I too use some tools from KDE and Gnome such as 'konqueror',
'ksnapshot' or 'gedit'.

When using 'gedit' on my FVWM based desktop, I noticed strange
behavior: The current tab looks exactly like all other tabs
(so I cannot optically find out wich one is active) and the
title bar is not updated correctly by 'gedit'.

My solution is:
- I strictly do not use tools from KDE4 and Gnome.
- Instead, I installed Trinity (the fork of KDE3)
  and MATE (the fork of Gnome 2)

So my tools are now 'konqueror' / 'ksnapshot' from Trinity
and the name of my 2nd editor is 'pluma' now instead of 'gedit'.

The result: Everything works fine (insofar as one can expect from
a thoroughly tailored VNC environment - working with xvnc4viewer).

I don't know which nasty surprises I will expect when I will
setup my first Debian Jessie environment with the
same strategy, but with Wheezy, I just got away with that,
particularly also because I do not need some really new
features of the tools I use from Trinity and MATE and
because I can be sure that the forks are maintained to some
degree (regarding security aspects and so on) by their
respective maintainers.

So, try looking whether MATE provides all you need from
Gnome, and perhaps you will be happy for the next few years.

Greetings from Germany,
Michael

System clock in FVWM: A new discovery!

[Michael Großer]

Hi!

This is not a question but a report about a new discovery.

Back in 2010, when I discovered FVWM as a useful window manager, I needed
a digital clock, which simply shows date, time and weekday. I searched and
filtered quite long and found xclock.

This week, nearly 5 years later, I discovered conky, a system monitor. What
do I need a system monitor for, when I mainly work in VirtualBoxes or Xen
based VNC sessions, I thought, and put it aside. Today, I again thought
about for what a conky could be useful. Then I noticed a lousy configured
xclock with a way too large lettering on a 24 inches 16:10 display, which
was initially designed for a 19 inches 5:4 display and then it dawned
on me: I DISCOVERED A NEW CLOCK FOR MY WINDOW MANAGER!!!

In the next weeks, when I continue setting up new Debian based
productive systems, I will try to replace this combersomly
configurable xclock by conky.

Why do I post this via the FVWM list?

Simply, because:

- I needed 5 years to discover that conky could be used
  as a system clock (nobody told me that before)

- If you are searching for a clock, it is not obvious to
  have a system monitor in mind

So, if somebody asks you for a digital system clock, then
don't forget to mention 'conky' to save him/her five years
of struggling with xclock ;-)

- Michael -

Re: FVWM: Another Shell for PipeRead?

[Michael Großer]

 Gesendet: Montag, 20. April 2015 um 12:52 Uhr
 Von: Thomas Adam tho...@fvwm.org
 An: Michael Großer michael.gros...@gmx.de
 Cc: fvwm f...@fvwm.org
 Betreff: Re: FVWM: Another Shell for PipeRead?

 On 20 April 2015 at 10:22,  michael.gros...@gmx.de wrote:
  Hi!
 
  The man page of FVWM says regarding the PipeRead command:
 
  This command is executed by /bin/sh as if you typed it on the command line.
 
 Yes, because we use popen() to do this.  Re-designing this to use
 fork()/execle() is not worth it just because Debian use /bin/dash.
 
  Has anybody an Idea how to change the standard shell for PipeRead?
 
 Use container scripts.
 
 -- Thomas Adam

Hm. OK.

I will do it.

Thank you for your answer and the explanation.


- Michael -

Re: FVWM: ImageMagick display style option?

[Michael Großer]

Walter Alejandro Iglesias wrote:
 Hi Michael,
 
 On Mon, Mar 25, 2013 at 08:45:36PM +0100, michael.gros...@gmx.de wrote:
  Hello everybody,
  
  I've noted that when I open with (ImageMagick) display command
  an image larger than the screen the window geometry doesn't take
  in care borders and title, then right and bottom window borders
  are hidden outside the limit of the screen.  Somebody knows a
  style option or another workaround for this?
  
  
  Thanks in advance
  
 Walter
  
  
 
 
 
 I have this with XV too, but I like this behavior, because this is
 exactly what I want: Seeing an unscaled image
 
 By default the display command doesn't scale the image but
 resizes the frame and open the little window with a thumbnail
 where you click and scroll.  The problem is Imagemagick
 considers the size of the physical screen without resting the
 width of the window frame and title.
 
 For example if you remove borders and title:
 
 Style display   !Title, !Handles, !Borders
 
 and open an image larger than the screen you can scroll the
 whole image using the thumbnail mini-window.  With the borders
 and title you can't (unless you scroll along the screen with the
 pager).
 


Hi Walter,

in both of your messages, you described what you get, but you
didn't describe what you want instead.

Please describe in detail which behavior you exactly want.
Tastes of people are very different, and it is hard to guess
your taste in your case.

- Michael -

Re: FVWM: Unhide a hidden taskbar

[Michael Großer]

Thomas Adam wrote:
 On Wed, Jan 04, 2012 at 11:00:49PM +0100, Michael Großer wrote:
 After adding this tool to your config, you can press
 MOD5 + MOD4 + F12 (or any other keyboard binding of your choice),
 and a second task bar appears. I chose FvwmWinList to act as a
 second task bar without any form of skip list.
 
 Given you already use FvwmIconMan, why are you then using FvwmWinList?  Why
 not just use FvwmIconMan?  FvwmWinList is going bye-bye very very soon, and
 the alternative will be FvwmWindowList, WindowList, or FvwmIconMan.  There
 will be no migration path away from this module.
 
 Your emergency thing, is easily reduced to:
 
 WindowList (Iconic) ...
 
 But do not use FvwmWinList.
 
 -- Thomas Adam
 

This choice dates from a time before the discontinuation of FvwmWinList
was discussed over this list. I have to migrate it to FvwmIconMan
(by using two different instances of this class). I just have to
migrate and test this approach. I will do it for sure anytime.
Yesterday I only had one hour to piece together this solution
(and used old code that already existed).

Re: FVWM: Unhide a hidden taskbar

[Michael Großer]

Thomas Adam wrote:
 On Wed, Jan 04, 2012 at 03:56:00AM -0800, Leo Simon wrote:
 Tried to post this on the forum but it wouldn't let me log on.
 
 Right -- and you forget/entered incorrectly which piece of information?
 
 I accidently Iconified my task bar and don't see any way to get it back.
 Could you please advise if there is one?
 
 There is no such thing as my task bar -- either you're using FvwmButtons
 or FvwmTaskBar, in which case if you really mean iconified, then see:
 
 Next (SomeName) Iconify Off
 
 Amongst many other ways of doing the same thing.
 
 More specific answers will come with more specific information from you, if
 the above doesn't help you.
 
 -- Thomas Adam
 



As Thomas correctly wrote: Your question lacks in details.
Which FVWM module do you use as a task bar?

I use FvwmIconMan as task bar.

I used your question as an opportunity to let another wish
from my wish list become real: I finally wrote me an emergency tool,
which can solve emergencies like this one in your question.

After adding this tool to your config, you can press
MOD5 + MOD4 + F12 (or any other keyboard binding of your choice),
and a second task bar appears. I chose FvwmWinList to act as a
second task bar without any form of skip list.

Use the middle mouse button to iconify or deiconify any window
that you want to.

Please leave feedback whether this solved your problem.


Michael

# .
# .
# .
# Your usual FVWM config stuff
# .
# .
# .

Read 0011_emergency_tool

# .
# .
# .
# Your usual FVWM config stuff
# .
# .
# .
# Use this tool when you have an emergency
# 
# When you have an emergency: Press Alt Gr + Win + F12  (MOD5 + MOD4 
+ F12)
# - an FvwmWinList will appear
# 
# When emergency is over: Press Alt Gr + Win + F11  (MOD5 + MOD4 + 
F11)
# - the FvwmWinList will disappear
# 
# Sometimes, Firefox crashes, and after the previous session is stored, 
sometimes some windows
# hide on an invisible viewport.
# 
# - Solution: Click with mouse button 1 on this window, and it will be moved to 
page 0 0.
# 
# Sometimes, OpenOffice hides dialog boxes on an invisible viewport forever 
(even after OpenOffice
# was exited and newly started.
# 
# - Solution 1: Click with mouse button 1 on this dialog box, and it will be 
moved to page 0 0.
# - Solution 2: If solution 1 still does not work, try to maximize the dialog 
box
# 
# When some of your windows is iconified, and you dannot deiconify it, because 
a WindowListSkip
# style is assigned to it, then you can try this:
# 
# - Click with mouse button 2 on this window to iconify or deiconify it.



Key F12 A 45 start_emergency_tool
Key F11 A 45 kill_emergency_tool


# start the emergency tool
DestroyFunc start_emergency_tool
AddToFunc start_emergency_tool
+ I Module FvwmWinList


# kill the emergency tool
DestroyFunc kill_emergency_tool
AddToFunc kill_emergency_tool
+ I KillModule FvwmWinList





# window lister
*FvwmWinList: Back rgb:40/40/40
*FvwmWinList: Fore rgb:ff/ff/ff
*FvwmWinList: FocusBack rgb:ff/ff/ff
*FvwmWinList: FocusFore rgb:40/40/40
#*FvwmWinList: Font -*-new century schoolbook-bold-r-*-*-*-120-*-*-*-*-*-*
*FvwmWinList: Action Click1 Function DeiconifyRaiseAndFocus
*FvwmWinList: Action Click2 Iconify
*FvwmWinList: Action Click3 Module FvwmIdent
#*FvwmWinList: UseSkipList
*FvwmWinList: UseIconNames
*FvwmWinList: Geometry +502-0
*FvwmWinList: MinWidth 473
*FvwmWinList: MaxWidth 473
*FvwmWinList: ButtonFrameWidth 1
#*FvwmWinList: ShowCurrentDesk

# makes the text left-aligned
*FvwmWinList: LeftJustify

# I don't know yet what this does. I simply let it be like this.
# *FvwmWinList: NoAnchor

# I don't know yet what this does. I simply let it be like this.
# *FvwmWinList: FollowWindowList

# I don't know yet what this does. I simply let it be like this.
*FvwmWinList: BorderReliefWidth 0

#pretend to be a taskbar
*FvwmWinList: NoIconAction SendToModule FvwmAnimate animate





# The emergency tool is supposed to get styles!
Style FvwmWinList Sticky, NoTitle, HandleWidth 0, NeverFocus, StaysOnBottom





# for the click 1 action
AddToFunc DeiconifyRaiseAndFocus
+ I Iconify off
+ I Raise
+ I Focus
+ I MoveToPage 0 0

Focus snapshot [Re: FVWM: disallowing the transfer of focus while a key is pressed]

[Michael Großer]

f...@stefan-klinger.de wrote:
 On Sat, Dec 31, 2011 at 01:32:05AM +, Thomas Adam wrote:
 On Sat, Dec 31, 2011 at 02:27:25PM +1300, f...@stefan-klinger.de wrote:
  On Sat, Dec 31, 2011 at 01:14:38AM +, Thomas Adam wrote:
   So set a reasonable delay for you binding:
   
   Schedule 700 Close
  
  Sorry, that won't help in general. Maybe you want to read my initial mail?
 
 It will if you use a function.
 
 How exactly? Just
 
 key d A 4 Schedule 1000 Close
 
 won't help, since, according to the FVWM doc: The command is executed
 in the same context window as the Schedule command.  It simply means
 that the wrong window is killed later.  I've tried this.

What do you think of my invention of a focus snapshot?
I invented it 15 minutes ago after I come out of the bathtube :-)

Define a key binding Win + Space, which makes a mental
snapshot of the window that currently has the focus.

When you press Win + Space, and something unforeseen happens,
then just go back to the original window and press Win + Space
again.

After pressing Win + Space, you could perform any action
you want and bind it the mental focus snapshot. This is not
exactly the workflow you want, but it is a possible workflow,
a tradeoff. And I'm rather sure that I were able to code this.

Do you understand my approach?

Michael

fragile approaches [Re: FVWM: disallowing the transfer of focus while a key is pressed]

[Michael Großer]

Thomas Adam wrote:
 On Sat, Dec 31, 2011 at 02:03:25PM +1300, f...@stefan-klinger.de wrote:
 On Fri, Dec 30, 2011 at 09:48:02AM +, Thomas Adam wrote:
  On 29 December 2011 23:02,  f...@stefan-klinger.de wrote:
   I'm looking for a way to prevent focus to shift from one window to
   another, as long as a key is held down.
  
  It's possible, but impractical.  Why are you thinking you need this?
 
 Another example: I use the key combination mod4-d to delete a window,
 where mod4 is produced by the window key. Imagine focus is in an xterm
 I want to get rid of, so I hold down the window key, and hit
 D. Unfortunately, just a fraction of a second before I pressed D, the
 application that took ages to start mapped its first window right
 beneath the mouse pointer, gets the focus (which follows the mouse),
 and is therefore deleted.
 
 What do you mean wich impractical?
 
 I'm reading this thread in bewilderment.
 
 Your entire problem is centered around windows receiving focus which you
 think shouldn't, and then deciding that how you want to fix it involves a
 key which, when pressed, disallows focus?
 
 Sorry -- but that's never going to work with applications.
 
 All these fanciful ideas using WarpToWindow inside functions is just as
 fragile as your original idea, Stefan, of a key press.
 
 FVWM is doing the right thing with respect to your problem of windows
 getting in the way, and I do sympathise only slightly about that
 potentially being annoying when deleting windows.
 
 If you _really_ think you need this still use:
 
 NoWindow Pick SomeFunctionNameOrCommandOfYourChoice
 
 Bind the above to a key/mouse binding however you like -- the whole point of
 this is to always make FVWM force the user to choose which window to run the
 corresponding binding's action.
 
 The above might not be so useful for moving windows around interactively,
 but it will help with your other problems.
 
 -- Thomas Adam

I too use fragile approaches to enforce a certain focus behaviour to my 
computer.
Yes, it is fragile sometimes, but for me this construction brings the most
possible benefit to me. I do not like it when the computer interactively
asks me to choose a window. This too often unnecessarily forces me to grab
the mouse, to shove it around and to press mouse buttons (when I have both
hands on the keyboard). It's a matter of taste. Fragile approaches always
implicate the risk of misconduct, which a user may purposely accept when
his workflow as a whole goes ahead much faster than with an ultra stable
but inconvenient system behaviour. And the effects of focus related
misconducts are negligible in contrast to the benefits.

Well: Stefan has the option to choose. Thomas gives very stable ideas.
My ideas may solve Stefan's problems more unconventional and MIGHT bear
the risk of fragility. If someone always knows what he does, fragility
in the grade I described above shouldn't be that bad. Or is it?

Michael

WarpToWindow [Re: FVWM: disallowing the transfer of focus while a key is pressed]

[Michael Großer]

[We have some kind of split brain problem. You will
see some days later why.]

Apart from my generic Win + Alt approach from yesterday,
here is yet another idea, which has very high chances of solving
SOME of your specific wishes without compromise. (Focus related
logics are a topic I'm interested in a lot.)



f...@stefan-klinger.de wrote:
 Another example is the following setup, which allows me to jump to
 another page on the desktop, and take the current window with me:
 
 destroyfunc gotomovetopage
 addtofunc gotomovetopage
 + I movetopage $0 $1
 + I gotopage $0 $1
 
 key right A C4 gotomovetopage 1p 0p
 key left A C4 gotomovetopage -1p 0p
 key up A C4 gotomovetopage 0p -1p
 key down A C4 gotomovetopage 0p 1p
 
 When jumping over multiple pages, I loose the window on the first
 occasion where the mouse pointer accidentally catches another window.

This code fragment below will work, especially when you DO NOT use the
FPLeaveToUnfocus policy, where such kind of approach would make more sense
than with:

destroyfunc gotomovetopage
addtofunc gotomovetopage
+ I SetEnv BOOKMARKED_WINDOW $[w.id]
+ I movetopage $0 $1
+ I gotopage $0 $1
+ I WindowId $[BOOKMARKED_WINDOW] WarpToWindow 50 50

WarpToWindow moves the mouse pointer, wich prevents that the
wrong window gets the focus.

My own config also uses such kind of bookmark and WarpToWindow
approach (in similar contextes).



 Excerpt from my .fvwm/config, which allows me to move a window to one
 of the 9 positions with a single keystroke.

 Style * FPEnterToFocus, FPLeaveToUnfocus

 key 1 a 4 animatedmove 0 0 warp
 key 2 a 4 animatedmove 50-50w 0 warp
 key 3 a 4 animatedmove -0 0 warp
 # ... and so on, think of a keypad, 1=top-left, 5=center,
 9=bottom-right

Similar here: Build a function, bookmark the window ID, use WarpToWindow,
use Raise, and your window should keep the focus (not tested, but it should
work).

Now, choose between this and the generic Win + Alt approach from
yesterday :-)

Michael





Have to withdraw now for a while. It was great, but holidays are over :-(

Re: WarpToWindow [Re: FVWM: disallowing the transfer of focus while a key is pressed]

[Michael Großer]

Michael Großer wrote:
 Apart from my generic Win + Alt approach from yesterday,

should read Win + Space...

Re: FVWM: disallowing the transfer of focus while a key is pressed

[Michael Großer]

f...@stefan-klinger.de wrote:
 On Sat, Dec 31, 2011 at 01:32:05AM +, Thomas Adam wrote:
 On Sat, Dec 31, 2011 at 02:27:25PM +1300, f...@stefan-klinger.de wrote:
  On Sat, Dec 31, 2011 at 01:14:38AM +, Thomas Adam wrote:
   So set a reasonable delay for you binding:
   
   Schedule 700 Close
  
  Sorry, that won't help in general. Maybe you want to read my initial mail?
 
 It will if you use a function.
 
 How exactly? Just
 
 key d A 4 Schedule 1000 Close
 
 won't help, since, according to the FVWM doc: The command is executed
 in the same context window as the Schedule command.  It simply means
 that the wrong window is killed later.  I've tried this.

Try to define a function. Then let your key binding call this function.
Let the function change the focus and then let it fire the close command.
Please report the result after you coded and tested this.


 I did read your initial email and you did not give me any reason for
 me to help you. Your question is asking for a solution to a problem
 you've not yet stated; confer an XY problem.
 
 Problem: I want to configure FVWM to not take away the focus from a
 window, while I hold down any modifier key.  No reason why, I just
 want to.
 
 I wonder whether I have said anything worng, or unfriendly, or whether
 I have a reason not to like your attitude.

@Stefan:
Be patient. Some people are just uncompromisingly straight and their
boundary related to social skills is shifted slightly away from kindness,
slightly in the direction of precision. As long as these people do not
pass over that boundary in a really unacceptable way, it could be smarter
to play along that game and to learn how to deal with this kind of people.
The world is full of them. If you are a person with a high level of
standards according to the ability to solve sophisticated, challenging
problems, then your chances to reach your ambitious goals increase with
your ability to deal with difficult people, because these people may be
the persons who may give you the deciding ideas that people who are nicer
than precise wouldn't be able to give you. When YOU increase your level
of social skills significantly, then you can become one of the few people
who are equipped with the interface to be able to involve these difficult
people into your goals. A lot of people do not have such kind of interface,
they run away, they look for less sophisticated, less challenging problems
to solve, and will become losers for the rest of their lowbrow lives.

http://catb.org/~esr/faqs/smart-questions.html
http://www.tty1.net/smart-questions_de.html

 Maybe one of the fellow
 readers would be so kind as to set me straight.

As I can realize, you unmistakably made clear what you really
want: A generic approach. I even helped you making that clear.
It seems that this generic approach is not that easy to reach.
When this happens, Thomas usually tries to find out your concrete
reasons that led you to want your rather generic approach. This
means: When generic approaches are not possible, then individual
approaches for each concrete reason would be better than nothing.
This is one of the implicit rules that people with a high level
of social skills should know (or learn (by making mistakes (people
who do not make mistakes do not work at all))).

:-)
Michael

Re: FVWM: disallowing the transfer of focus while a key is pressed

[Michael Großer]

I have no concrete idea that you could directly transform
into source code, but, perhaps my question and a general
idea could help to find a direction.

Question:
What do you mean with while a key is pressed?
Only the mod4 (Win) key? And perhaps a Control key?

When I see your lines of code, I think it should be enough
when the mod4 (Win) key is kept down?

Idea:
If so: Is it possible to recognize a currently pressed
mod4 key, and set another focus policy until the key is up again?

Michael





f...@stefan-klinger.de wrote:
 Hello,
 
 I've been using FVWM for several years now, and I'm quite happy about
 it. There's one focus-related thing however, I coud not manage to
 figure out, even though there are a lot of focus-policy settings
 around:
 
 
 === Problem
 
 I'm looking for a way to prevent focus to shift from one window to
 another, as long as a key is held down.
 
 
 === Reason
 
 I'm using a focus-follows-mouse policy and I frequently use keys to
 move windows around.  While doing so, sometimes (often) a second
 window gets between the mouse cursor, and the window I want to move.
 Instantly focus jumps to the second window, which is then moved
 instead of the one I wanted to.
 
 
 === Try this yourself
 
 Excerpt from my .fvwm/config, which allows me to move a window to one
 of the 9 positions with a single keystroke.
 
 Style * FPEnterToFocus, FPLeaveToUnfocus
 
 key 1 a 4 animatedmove 0 0 warp
 key 2 a 4 animatedmove 50-50w 0 warp
 key 3 a 4 animatedmove -0 0 warp
 # ... and so on, think of a keypad, 1=top-left, 5=center,
 9=bottom-right
 
 Now open two terminals, put the upper one in the top-left corner, the
 lower one somewhere else.  Move mouse to lower terminal, which gets
 the focus. Hold down mod4 and press 1, then 3, then release mod4.  The
 lower window moves to the top left, where it instantly looses its
 focus to the upper window, which then moves to the top-right.
 
 
 Another example is the following setup, which allows me to jump to
 another page on the desktop, and take the current window with me:
 
 destroyfunc gotomovetopage
 addtofunc gotomovetopage
 + I movetopage $0 $1
 + I gotopage $0 $1
 
 key right A C4 gotomovetopage 1p 0p
 key left A C4 gotomovetopage -1p 0p
 key up A C4 gotomovetopage 0p -1p
 key down A C4 gotomovetopage 0p 1p
 
 When jumping over multiple pages, I loose the window on the first
 occasion where the mouse pointer accidentally catches another window.
 
 
 === Proposed Solution
 
 IMHO, disallowing the transfer of focus while a key is pressed, would
 remedy the situation.
 
 Is this doable with current FVWM configuration options?
 
 
 === Version
 
 sk@verne:~ fvwm --version
 fvwm 2.5.30 compiled on Oct 16 2010 at 07:00:26
 with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm,
 SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS
 
 
 
 Thank you!
 Stefan