> On Wed, Mar 6, 2024 at 10:45 AM Chris Siebenmann
> wrote:
> > Is this intended behavior? I can't spot a strong statement either way in
> > the current documentation for Move, although some of the wording sounds
> > a bit odd if explicit Move positions are suppos
I've recently written an fvwm3 function to move and place my Emacs
mail reading windows:
DestroyFunc MHEEmacsPosition
AddToFunc MHEEmacsPosition
+ I Next ("+inbox", "Emacs") Iconify False
+ I Next ("+inbox", "Emacs") Resize 80c 46c
+ I Next
> Does wayland have an X11 compatibility feature?
Wayland has an 'XWayland' layer that allows regular X clients to talk to
a Wayland server. However, this does not support special X clients like
window managers or (as I understand it) automation tools like 'xdotool'.
So you can run an X-based
> On Tue, Jan 30, 2024 at 1:25 PM hw wrote:
> > so is there finally a version that works for wayland?
> >
> No, fvwm only works with xorg and most likely won't be ported.
To add some information, a 'port' would be more difficult than it
sounds. The architecture of Wayland does not have an
[reviving an old thread that I lost track of]
> On Sun, 14 May 2023, Thomas Adam wrote:
> > On Sun, 14 May 2023 at 22:12, Lucio Chiappetti wrote:
> >> So the problem is an incompatibility between xterm and fvwm syntethic
> >> events (or a syntax problem with PointerKey ?)
>
> > No. By default
> I've googled and FAQd and experimented without success.
>
> When I have the vim editor open in an xterm window, in insert mode,
> and move my mouse (and focus) into another window, the vim in the
> original window receives some sort of escape sequence that causes
> it to leave insert mode and
> Greetings,
>
> is there a way in Fvwm to bind some command to just pressing and
> immediately releasing the Ctrl-key without pressing any other key?
>
> Holding down Ctrl any pressing A should NOT trigger this command.
On Linux, you can use the 'xcape' program to put together something to
do
Here is a fvwm puzzle that I suspect is solvable but I don't know how
to solve. When a window is iconified or starts out iconified, I'd like
its icon location to go as follows:
1) if it's not being iconified for the first time, its icon goes wherever
it did last time (whether I moved it from
> > If you click on the link, it's supposed to print something like:
> >
> > link
> > http://gtk.org
> > In a configuration with a Mouse 1 binding that includes the Window
> > context (so W or A), the link can't be activated by clicking mouse-1
> > and link.py prints nothing. You can
> > Unless I have a simple test application and a configuration
> > that exhibits that behaviour I cannot do much about it.
> > Would you be able to fvwm in Xnest and debug through
> > events.c:__handle_bpress_on_managed() to see what actually happens?
>
> By the way, have you tried to get the
> The only other reason fvwm grabs a button is for focus handling in
> focus.c:__focus_grab_one_button(). The only possible reason I
> could think of is that the application does not accept focus so
> that grab never gets removed. Have you tried
>
> Style * Lenience
>
> as Dan suggested?
>
> > > > then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
> > > > in xev
>
> Forget about these; that's just how X works.
I dusted off old memories about the patches that I'm carrying in my
home fvwm binary and not my work one, and I think that this has come
up before and
> On Tue, Feb 28, 2017 at 08:42:38PM -0500, Chris Siebenmann wrote:
> >
> > > > If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
> > > > file (from the URL) *except* either:
> > > >
> > > >
> >> When you click a mouse it should generate 2 X11 events:
> >>
> >> ButtonPress
> >> ButtonRelease
> >
> > I've just used xev to confirm that I see ButtonPress and ButtonRelease
> > events. However, what I have discovered is that I see additional events
> > with my FVWM configuration.
Corebird is a Linux/GTK Twitter client:
https://corebird.baedert.org/
In attempting to use the current version on Fedora 25, I have uncovered
a weird oddity where I cannot click links with the left mouse button when
using my FVWM configuration. Corebird recognizes that I have clicked and
> During immediate function execution fvwm tries to get exclusive
> control of the pointer (a "grab"). This failed in the given case
> because some other program held the grab. Fvwm retries grabbing
> for a second before giving up (the function is aborted). It seems
> that for whatever reason
Could one of you please try what happens if you add the following
lines at the end of the function fvwm/icons.c:CMD_Iconify(), right
before the final return:
FlushAllMessageQueues();
XFlush(dpy);
EWMH_SetWMState(fw, False);
GNOME_SetHints(fw);
GNOME_SetWinArea(fw);
(Even if
Just wondering if this strikes a familiar note? The newest
google-chrome running on my fedora 20 system utterly fails
to redraw anything at all (not only no web content, but
no menu bar, navigation buttons, etc) when I minimize it,
then later restore it from the window list. I get nothing
If you don't configure a setting for IconAndSelectButton,
modules/FvwmIconMan/x.c's X_init_manager() will wind up trying to
use contextDefaults[7] (down in load_default_context_[fore|back]()).
Unfortunately, per globals.c, the contextDefaults array only has six
entries. This can result in a
| I'm seeing a weird problem with trying to use current Firefox Nightly
| builds under my FVWM configuration, where some of Firefox's menus won't
| appear (or won't appear consistently). This seems specific to using
| Firefox under FVWM; under another window manager (Cinnamon) things work.
| Old
| There was a recent change (April 14th) to FvwmIconMan's source code
| to, to quote the changelog:
| [...]
|
| This should be fixed now. I backed out the patch and now use
| a routine from libs/Colorset.c to draw the button background, and
| that works for me with hopefully no risk of
| [*: my machine is 64-bit Fedora 18 with an ATI graphics card and the
| normal Fedora 18 open source drivers. These particular screenshots
| are from an Xephyr session, but I first saw the effect on the real
| display.]
|
| So, you have a 64-bit CPU with a 64-bit version of the
Here is a relatively minimal fvwm configuration file that shows the
problem for me (inside an Xephyr server):
# Relatively minimal FVWM configuration for reproducing FvwmIconMan
# button rendering/colour issues.
#
# USAGE: use the right button on the root window to call up the main menu
# and
Darktable (a Linux RAW processor, http://darktable.org/) has some
sometimes-appearing widgets that I can't seem to actually select when I
run it under FVWM. An example is the buttons it adds to its histogram,
visible in the screenshot here:
Thomas Adams:
| I can take a look if you provide me some details.
|
| Thomas
|
| On 16 May 2013 16:46, Chris Siebenmann c...@cs.toronto.edu wrote:
|
| Darktable (a Linux RAW processor, http://darktable.org/) has some
| sometimes-appearing widgets that I can't seem to actually select when I
| Second it is not firefox that 'pastes' when you click the middle mouse
| button. It is xorg that intercepts the middle mouse click and then
| sends the resulting paste to the window. So sending the middle mouse
| button click to the root window or the firefox window (or any other
| window) will
Here are two thoughts on relatively self-contained potential FVWM GSoC
projects:
* a module that is the inverse of FvwmCommand; call it FvwmQuery.
Where FvwmCommand allows shell scripts to send commands to FVWM,
FvwmQuery would allow them to get information from it.
The FVWM module
As a followup to asking about how to do this a while back on the
mailing list (and then asking a related question more recently), I'm
sharing with the list how I have put this together.
The goal: allow me to select terminal windows from the keyboard in a
manner similar to searching for text in a
I feel like I'm missing some important bits about how fvwm handles
functions.
I'm trying to write a function that's fed a window name and has
following goals. First, it only operates on terminal windows.
Then:
- if no (terminal) window by that name exists, it should do nothing.
- if the
| what patches do you write which you maintain then?
At the moment the only meaningful patch I've made to fvwm is one to
position new icons at the mouse cursor instead of where they normally go
(I think the window's top left if you don't have an iconbox set up, but
I forget). In the past I had
| At the moment the only meaningful patch I've made to fvwm is one to
| position new icons at the mouse cursor instead of where they normally go
| (I think the window's top left if you don't have an iconbox set up, but
| I forget). [...]
[...]
| Mouseplacement for an icon sounds unpleasant.
| [...] There are several reasons as of why certain patches aren't
| accepted. Some of the patches affect areas of fvwm which in the long
| term goal should be replaced by modules. Others are unclean, and no
| one has been willing to clean up the code and write documentation for
| the
Does anyone know if there exists a good command line tool for listing
either the window IDs or the window names of all windows of a specific
class (or better yet, set of classes)? Or is this something that's
better done with an fvwm module written in Perl with fvwm-perllib[*]?
Thanks in
What I would like to be able to do is select a window from the keyboard
in a way very similar to searching for text in a browser: hit a key
combination, start typing the name of a window (maybe with some sort of
tab completion), and then when enough of the name has been typed, hit
return to
Harry portobello:
| would i be able for commit rights for this? I am hoping to reimplement
| some features you've removed.
|
| For as long as I still have commit privs, I will never vouch you get
| them. Sorry, but you've demonstrated a fundamental lack of competence
| which makes me very
| Is there a complete list of deprecated(ing) or dead modules?
| I don't want to play with a dead module, with issues
| unsolvable.
|
| Not as such, but in my mind:
[...]
| * FvwmWinList (it's FvwmIconMan with tweaks?)
This might need some modifications to FvwmIconMan, because the last
time
+++ ChangeLog 6 Aug 2010 18:40:50 -
@@ -1,3 +1,13 @@
+2010-08-06 Chris Siebenmann cks-f...@cs.toronto.edu
+ * modules/FvwmIconMan/fvwm.c (count_nonsticky_in_hashtab):
+ * NEWS:
+ Correctly handle iconified windows with sticky icons.
+
+ When counting how many windows we expect
| Committed a fix to CVS for this.
|
| Really, this time. Bloody CVS! Of course, this isn't helped by the
| fact that the email announcements from CVS are taking up to 9 hours to
| get sent out for some stupid reason.
|
| Chris -- please cvs up -- does this fix things for you?
I've done this
There's a small file descriptor leak in CMD_Exec() in fvwm/builtins.c;
it opens /dev/null, dup2()s it to standard input, and then never closes
the original file descriptor before exec'ing the command.
The neurotically correct fix for this (in what I think is the right
fvwm coding style) is:
I have the Mouse configuration setup of (among other things):
# move window with mouse 2 on an icon or a titlebar
Mouse 2 IT NMove
In fvwm 2.4.20, the window move is initiated immediately when button 2
is pressed. In fvwm 2.5.30 (and CVS) for me, the move is delayed and
I can't seem to turn off a user state for a specific window in a
function in fvwm 2.5.30. Here is an exerpt from my current testing
fvwm-2.5.30 configuration file:
Style * State 1
*FvwmEvent: iconify ZapIconPlacement
*FvwmEvent: deiconify ZapState
I wrote:
| This doesn't happen for other buttons, eg I also have 'Mouse 1
| T N Move' and if I use mouse button 1 on window titles they move
| immediately without waiting for button-up.
I was mistaken about what I had button 1 bound to, which has led me
to a workaround. If you have the Move in
42 matches
Mail list logo
