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: new_desk "Function 'FvwmEvent_new_desk'"
> *FvwmEvent: focus_change "Function 'FvwmEvent_focus_change'"
I attach empty functions to these events that I need and fill
the functions with contents later in my scripts.
> And how do I prevent this function from being
> called when the window that is moved out of the way is placed?
You could solve this like a programmer would solve it:
- When you initialize your event handler, set a variable 'i_am_listening'
to TRUE or 1 or whatever
- When the handler comes to action:
- Quit the handler without action if 'i_am_listening' is FALSE
- Set 'i_am_listening' to FALSE or 0 or whatever
- Place the window
- Set 'i_am_listening' back to TRUE
I hope that helps :-)
> (In most cases, I probably won't need that because I'm using starter
> functions to start applications which create windows, but applications
> can create windows by themselves ...)
>
>
.\" t
.\" @(#)@PACKAGE@-@VERSION@ @RELDATELONG@
.TH FvwmEvent 1 "@RELDATELONG@ (@VERSION@)" Fvwm "Fvwm Modules"
.UC
.SH NAME
\fIFvwmEvent\fP \- the fvwm event module
.SH SYNOPSIS
\fIFvwmEvent\fP is a more versatile replacement for \fIFvwmAudio\fP.
It can in general be used to hook any \fIfvwm\fP function or program to any
window manager event. E.g: Delete unwanted Netscape Pop ups or
application error pop ups as they appear, play sounds, log events to a
file and the like. Be creative, you'll find a use for it.
\fIFvwmEvent\fP is spawned by \fIfvwm\fP, so no command line invocation will
work. From within the \fI.fvwm2rc\fP file, \fIFvwmEvent\fP is spawned as
follows:
.nf
.sp
Module FvwmEvent
.sp
.fi
or from within an \fIfvwm\fP pop-up menu:
.nf
.sp
DestroyMenu Module-Popup
AddToMenu Module-Popup "Modules" Title
+ "Event" Module FvwmEvent
+ "Auto" Module FvwmAuto 200
+ "Buttons" Module FvwmButtons
+ "Console" Module FvwmConsole
+ "Ident" Module FvwmIdent
+ "Banner" Module FvwmBanner
+ "Pager" Module FvwmPager 0 3
.sp
.fi
.SH DESCRIPTION
The \fIFvwmEvent\fP module communicates with the \fIfvwm\fP window manager
to bind \fIactions\fP to window manager \fIevents\fP. Different actions
may be assigned to distinct window manager events.
\fIFvwmEvent\fP can be used to bind sound files to events like
\fIFvwmAudio\fP (RiP) did. It can be used for logging event traces to
a log file, while debugging \fIfvwm\fP.
\fIFvwmEvent\fP can also have builtin support for the rplay library.
(heritage of FvwmAudio)
.SH INVOCATION
The invocation method was shown in the synopsis section. No command
line invocation is possible. \fIFvwmEvent\fP must be invoked by the
\fIfvwm\fP window manager. \fIFvwmEvent\fP accepts a single
argument:
.IP \-audio
Enables FvwmAudio compatibility mode.
.IP alias
Makes FvwmEvent use \fIalias\fP as its name. This affects which lines
from the user's configuration file are used.
Invoking FvwmEvent as \fIFvwmAudio\fP (either by using an alias or
creating a symlink) enables FvwmAudio compatibility mode.
.sp
.SH CONFIGURATION OPTIONS
\fIFvwmEvent\fP gets config info from \fBfvwm\fP's module configuration
database (see
.IR fvwm (1),
section
.BR "MODULE COMMANDS" ),
and looks for certain configuration options:
.IP "*FvwmEvent: Cmd \fIcommand\fP"
This determines the \fIfvwm\fP function that is to be called with the
event parameters. You might want to do one of the following (details below):
.nf
.sp
# play sounds
*FvwmEvent: Cmd \fIbuiltin-rplay\fP
# execute distinct fvwm functions
*FvwmEvent: Cmd
# execute distinct external programs
*FvwmEvent: Cmd exec
.sp
.fi
This version of \fIFvwmEvent\fP has builtin \fIrplay\fP support which does not
need to invoke an external audio player to play sounds. The rplay
support is enabled when \fIFvwmEvent\fP is compiled with \fIHAVE_RPLAY\fP
defined and when \fIFvwmEvent: Cmd\fP is set to \fIbuiltin-rplay\fP. See
remarks below if \fIFvwmEvent\fP is invoked in FvwmAudio compatibility mode.
For example:
.nf
.sp
*FvwmEvent: Cmd \fIbuiltin-rplay\fP
*FvwmEvent: add_window drip.au
.sp
.fi
rplay can be obtained via anonymous ftp at
.nf
.sp
<URL:ftp://ftp.sdsu.edu/pub/rplay> or
<URL:ftp://ftp.x.org/contrib/Event/audio/rplay>
.sp
.fi
\fIFvwmEvent\fP also has support for any other external program.
e.g: the rsynth 'say' command:
.nf
.sp
*FvwmEvent: Cmd "Exec /rsynth/say"
*FvwmEvent: destroy_window "window closed"
.sp
.fi
You can also use \fIfvwm\fP's builtin \fIEcho\fP command as
\fIFvwmEvent: Cmd\fP to obtain debug output for \fIfvwm\fP events quietly.
I used this setup to debug FvwmAuto:
.nf
.sp
*FvwmEvent: Cmd \fIEcho\fP
*FvwmEvent: focus_change "focus change"
*FvwmEvent: raise_window "raise window"
.sp
.fi
You can even call different shell commands for each event just by setting
.nf
.sp
*FvwmEvent: Cmd exec
*FvwmEvent: add_window 'killname "APPL ERROR"'
.sp
.fi
.IP "*FvwmEvent: PassId"
Specifies that the event action will have an ID parameter added to the end
of the command line. Most events will have the windowID of the window that the
event refers to, new_desk will have the new desk number. The windowID is a
hexadecimal string preceded by 0x, desk numbers are decimal.
.IP "*FvwmEvent: \fIwindow-manager-event action-or-filename\fP"
Binds particular actions to window manager events.
The window related event handlers are executed within a window
context. Previously PassId was used for this purpose, but now using
PassId is not needed.
Note: The enter_window event is generated when the pointer enters
a window. With the -passid option, that window's id is passed to
fvwm. An enter_window event is generated too when the pointer
leaves a window and moves into the root window. In this case, the
id passed is 0.
Note: When the shutdown event arrives, FvwmEvent may be killed
before it can trigger the associated action.
.sp
.fi
Provided \fIfvwm\fP supports it (not yet), there's an additional event to
replace all \fIfvwm\fP beeps with a sound:
.nf
.sp
*FvwmEvent: beep beep.au
.sp
.fi
The toggle_paging event will be supported, as soon, as it's
resurrected by \fIfvwm\fP:
.nf
.sp
*FvwmEvent: toggle_paging fwop.au
.sp
.fi
.IP "*FvwmEvent: Delay \fI5\fP"
Specifies that an event-action will only be executed if it occurs at
least 5 seconds after the previous event. Events that occur during
the delay period are ignored. This option is useful if you don't want
several sounds playing at the same time. The default delay is 0 which
disables the Event delay.
.IP "*FvwmEvent: StartDelay \fIdelay\fP"
Specifies that an event-action will only be executed if it occurs at
least \fIdelay\fP seconds after the startup event. Events that occur during
the delay period are ignored. This option is useful when \fIfvwm\fP
starts and restarts using an audio player. The default delay is 0.
.SH EVENT TYPES
The following table shows the events supported by FvwmEvent and when they
are triggered.
.TS
tab(@), left, box;
c | c
l | l.
Event@Trigger
_
T{
startup
T}
@T{
Runs when fvwm is started/restarted.
T}
_
T{
shutdown
T}
@T{
Runs when fvwm is exited.
T}
_
T{
new_page
T}
@T{
Runs when fvwm is switched to a page.
T}
_
T{
new_desk
T}
@T{
Runs when fvwm is switched to a desk.
T}
_
T{
old_add_window
T}
@T{
Deprecated. See \fIadd_window\fP.
T}
_
T{
raise_window
T}
@T{
Runs when a window is raised.
T}
_
T{
lower_window
T}
@T{
Runs when a window is lowered.
T}
_
T{
old_configure_window
T}
@T{
Deprecated. See \fIconfigure_window\fP.
T}
_
T{
focus_change
T}
@T{
Runs when a window loses/gains focus. The event is triggered on the window
which receives the focus.
T}
_
T{
enter_window
T}
@T{
Runs when the pointer enters into a window, regardless of whether the window
receives focus or not. See \fIfocus_change\fP.
T}
_
T{
leave_window
T}
@T{
Runs when the pointer leaves a window, reardless of whether the window loses
focus or not. See \fIenter_window\fP.
T}
_
T{
destroy_window
T}
@T{
Runs when a window is closed.
T}
_
T{
iconify
T}
@T{
Runs when a window is iconified.
T}
_
T{
deiconify
T}
@T{
Runs when a window transitions from the iconic state to the normal state.
T}
_
T{
window_name
T}
@T{
Runs when WM_NAME of the window changes.
T}
_
T{
icon_name
T}
@T{
Runs when the WM_ICON_TITLE property of a window changes.
T}
_
T{
visible_icon_name
T}
@T{
Runs when the visible icon name changes. See \fIicon_name\fP.
T}
_
T{
res_class
T}
@T{
Runs when the WM_CLASS property of a window changes.
T}
_
T{
res_name
T}
@T{
Runs when the WM_CLASS property of a window changes (for the resource).
T}
_
T{
end_windowlist
T}
@T{
Runs when a module requests a window list. Generally not useful as an end-user
event.
T}
_
T{
icon_location
T}
@T{
Runs when the position of the icon changes.
T}
_
T{
map
T}
@T{
Deprecated. Runs when a window is mapped. See \fIadd_window\fP.
T}
_
T{
icon_file
T}
@T{
Runs when the location of the icon changes.
T}
_
T{
default_icon
T}
@T{
Runs if the default icon for a given window changes.
T}
_
T{
string
T}
@T{
Deprecated. See \fIvisible_name\fP.
T}
_
T{
mini_icon
T}
@T{
Runs when the mini icon of a window is changed.
T}
_
T{
windowshade
T}
@T{
Runs if a window is shaded.
T}
_
T{
dewindowshade
T}
@T{
Runs if a window is unshaded.
T}
_
T{
visible_name
T}
@T{
Runs when the title of the window (typically what appears in the titlebar of a
window) has changed.
T}
_
T{
restack
T}
@T{
Runs if the stacking order of the window is changed, typically through changing
layers, etc., although this cannot be used for layer change events specifically.
T}
_
T{
add_window
T}
@T{
Runs when a window is initially mapped.
T}
_
T{
configure_window
T}
@T{
Runs when the window receives a ConfigureNotify request -- typically this
happens when a window is moved, or resized, or the window changes layer.
T}
_
T{
visible_icon_name
T}
@T{
Runs when the text for the icon title changes.
T}
_
T{
property_change
T}
@T{
Runs when the window receives a PropertyNotify event, which typically involves
updating different window properties such as WM_TITLE, etc.
T}
.TE
.SH RPLAY OPTIONS
The following options are only valid with builtin rplay support.
i.e: when \fIFvwmEvent\fP was compiled with \fIHAVE_RPLAY\fP defined.
They are used only if \fIFvwmEvent: Cmd\fP is set
to \fIbuiltin-rplay\fP.
.IP "*FvwmEvent: RplayHost \fIhostname\fP"
Specifies what host the rplay sounds will play on. The \fIhostname\fP
can also be an environment variable such as $HOSTDISPLAY.
.IP "*FvwmEvent: RplayPriority \fI0\fP"
Specifies what priority will be assigned to the rplay sounds when they
are played.
.IP "*FvwmEvent: RplayVolume \fI127\fP"
Specifies what volume will be assigned to the sounds when they are
played.
.SH FvwmAudio Compatibility Mode
When invoked in FvwmAudio compatibility mode (see above), FvwmEvent
accepts the following options to provide backwards compatibility
for FvwmAudio:
.IP "*FvwmEvent: PlayCmd \fIcommand\fP"
This is equivalent to using *FvwmEvent: Cmd to Exec commands. This
determines the independent audio player program that will actually
play the sounds. If the play command is set to \fIbuiltin-rplay\fP
then the builtin rplay support will be used.
.IP "*FvwmAudio: Dir \fIdirectory\fP"
Specifies the directory to look for the audio files. This option is
ignored when rplay is used.
.SH BUGS
It's REALLY noisy when \fIfvwm\fP starts and restarts using an audio player.
You can use FvwmEvent: StartDelay to fix this problem.
.SH COPYRIGHTS
This module has evolved of \fIFvwmAudio\fP, which in term is heavily based
on a similar Fvwm module called \fIFvwmSound\fP by Mark
Boyns. \fIFvwmAudio\fP simply took Mark's original program and
extended it to make it generic enough to work with any audio
player. Due to different requests to do specific things on specific events,
\fIFvwmEvent\fP took this one step further and now calls any
\fIfvwm\fP function, or builtin-rplay. If \fIfvwm\fP's Exec function
is used, any external program can be called with any parameter.
The concept for interfacing this module to the Window Manager, is
original work by Robert Nation.
Copyright 1998 Albrecht Kadlec.
Copyright 1994, Mark Boyns and Mark Scott. No guarantees or
warranties or anything are provided or implied in any way whatsoever.
Use this program at your own risk. Permission to use and modify this
program for any purpose is given, as long as the copyright is kept intact.
.sp
.SH AUTHORS
.nf
1994 FvwmSound Mark Boyns (\fibo...@sdsu.edu\fP)
1994 FvwmAudio Mark Scott (\fimsc...@mcd.mot.com\fP)
1996 FvwmAudio Albrecht Kadlec
1998 FvwmEvent Albrecht Kadlec (\fialbre...@auto.tuwien.ac.at\fP)
Diese man-Page ist eine Abwandlung zur damals aktuellen Version '2.5.31', extra
für mich.
Es fehlt zwar die Versionsnummer, aber es müsste dann logischerweise die
'2.5.32' sein.
Neu ist der Abschnitt 'EVENT TYPES'. Die Tabelle enthält alle Events, die es im
FVWM gibt.
In einer späteren Version (2.6.5) fehlt diese Tabelle wieder.
Die E-Mail-Nachricht, in der ich den Download 'github'
dokumentiert hatte, ist von '12.08.2010 17:38'.
Quelle:
http://github.com/ThomasAdam/fvwm/raw/49a53ee408cba26f7649fc4b56df0d309b485cfd/modules/FvwmEvent/FvwmEvent.1.in
