Post by Thomas AdamPost by Michael GroÃerDoes anyone know about this behaviour of FvwmIdent?
Is the reason known why FvwmIdent is that much damageable?
It's designed to work this way.
if (is_key_pressed)
{
exit(0);
}
break;
If you press a key, and FvwmIdent is focused, we exit.
if (is_button_pressed)
{
if (is_button_pressed == 2 &&
Event.xbutton.button == 2)
{
/* select a new window when
* button 2 is pressed */
SetMessageMask(
fd, M_CONFIGURE_WINDOW |
M_WINDOW_NAME |
M_ICON_NAME |
M_RES_CLASS |
M_RES_NAME |
M_END_WINDOWLIST |
M_CONFIG_INFO |
M_END_CONFIG_INFO|
M_SENDCONFIG);
SendText(fd, "Send_WindowList", 0);
XDestroyWindow(dpy, main_win);
If button two is pressed, we destroy the top-level window, and prompt for a new window to select.
DestroyList();
fvwmlib_get_target_window(
dpy, screen, module->name,
&(module->window), True);
found = 0;
return 1;
}
else
{
exit(0);
Otherwise, all other button processes close FvwmIdent.
-- Thomas Adam
Hi!
This was very nice that you showed me the right piece of code.
Thank you for this.
If I were the initial author of FvwmIdent, I would have designed it so
that it would ignore all key presses and mouse button presses but
only a few:
- button 2 to destroy the top-level window and prompt for a new one
- button 3 to exit
What exactly is the advantage to exit when the user turns the mouse wheel
(button number something larger than 3) or when the user hits a Shift
key on the keyboard?
Anyway, if you want, then you can introduce a new option "DoNotExit"
to let FvwmIdent stay alive when the user hits another key or button
than mouse button 2 or 3 and "DoNotExit" is true.
Post by Thomas Adamif (is_key_pressed)
{
if (DoNotExit)
{
break; /* or "return" or something else */
}
else
{
exit(0);
}
}
break;
Since now I understand why FvwmIdent disappears, I set a NeverFocus style
to prevent that keyboard events will be passed to FvwmIdent. This makes
FvwmIdent's behaviour acceptable for me for now.
At this point, this e-mail would end.
.
.
.
.
.
.
But another thing caused me to strike out a bit more and change something
more than I originally wanted.
When I additionally I set a StaysOnTop style to bring FvwmIdent on top,
I noticed that this does only work when I apply FvwmIdent on
xterms, but not on nedit, Iceweasel, FvwmIdent or some other instances.
So, I tried a lot of things, until I finally got a working solution:
- I called "DestroyStyle FvwmIdent" before I call "Style FvwmIdent
StaysOnTop, NeverFocus"
- no result
- I wrote a function "raiseFvwmIdent" (see attachments) to bring
FvwmIdent on top
- this only works when:
- I use Schedule
- I make FvwmIdent sticky and unsticky thereafter
The sticky and unsticky solution is a trick I found out in the year 2010.
But all these tricks show: If you look for things that could be improved
on FVWM, here are some:
- examine why a StaysOnTop style is not enough to bring FvwmIdent
on top
- examine why I need a Stick Stick solution to bring any window
on top
Since I found workarounds for all these "problems", the priority
of these things is not so much high. But it shows that there are
at least "some" sites that have to be tackled to make even FVWM
(the best window manager worldwide) perfect.
Attachments:
- 0012_FvwmIdent
- my FvwmIdent code, which successfully makes FvwmIdent
unfocusable and successfully brings it on top
- 0010_task_bar
- my primary "task bar" from wich I call FvwmIdent
- 0011_emergency_tool
- my second "task bar" for emergency purposes from wich
I call FvwmIdent
Environment:
- still my old productive system based on Debian Lenny with
fvwm 2.5.26
Best regards,
Michael