I am currently using a somewhat hacked version of fvwm 2.4.20 and I
would like to move to fvwm 2.5.x (for whatever x is current when I get
all of the pieces working). One of the stumbling blocks is duplicating
one piece of icon placement behavior in my current setup.
I do not have an icon box ('
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
onl
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
| On Tue, Jul 27, 2010 at 01:00:24PM -0400, Chris Siebenmann wrote:
|
| [.. other stuff snipped..]
|
| > So, either I'm missing something about fvwm 2.5.30, or there's a bug
| > here. All things considered, the first is probably more likely -- does
| > anyone have any ideas
| > 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 th
| > 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
tim
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 deicon
| > [...] 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 pat
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 advance.
| 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 mo
| > 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
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 currentl
| On Tue, Feb 07, 2012 at 03:41:22PM -0500, Chris Siebenmann wrote:
| > My current version is:
| > AddToFunc ToWindow
| > + I Current ("XTerm|9term|Gnome-terminal", "$0") Break
| > + I Next ("XTerm|9term|Gnome-terminal", "$0&quo
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
| One important aspect of project life cycles is the ability
| how projects keep in step with general technical development.
|
| It may be the case that five or ten years from now a lot of computers
| will be equipped with touch screens.
|
| It could be a good idea to think about how FVWM would c
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 interf
[Some brief comments now, more considered ones later.]
| > 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,
| > F
| 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 n
| First xorg has three buffers, primary, secondary and clipboard. The
| primary gets used in the select/middle mouse paste, while the
| clipboard gets used by some programs with ctrl-c/ctrl-v is the
| standard. So depending on which buffer you want to paste from adjust
| the following.
The easy r
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:
http://www.darktable.org/usermanual/ch03s03s05.ht
There was a recent change (April 14th) to FvwmIconMan's source code
to, to quote the changelog:
* FvwmIconMan/x.c (change_colorset, recreate_background)
(create_manager_window):
fix bad hilight colour on some systems (64 bit issue?)
Unfortunately on my machine[*] the effe
Thomas Adams:
| I can take a look if you provide me some details.
|
| Thomas
|
| On 16 May 2013 16:46, "Chris Siebenmann" wrote:
| >
| > Darktable (a Linux RAW processor, http://darktable.org/) has some
| > sometimes-appearing widgets that I can't seem to actually
| > [*: 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 th
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 run
| > 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 break
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 Firefox Nig
| 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 F
> 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
> On Thu, Sep 04, 2014 at 08:56:52AM -0400, Tom Horsley wrote:
> > 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 m
> Do you display icons too, or have them just in the icon manager?
> Maybe it waits for the icon window to appear? Try to comment out
> all icon related styles in your configuration file and see if that
> helps (i.e. make fvwm use and display whatever icon pixmap or icon
> window the application p
> On Fri, 05 Sep 2014 11:49:17 +0200
> Bert Geens wrote:
> > However shading and unshading the window after deiconifying returns the
> > application to normal behaviour for me (fvwm 2.6.5).
>
> By golly, it works for me too (once I found the WindowShade function
> and added it to my window operati
> 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);
>
>
> Sigh. Do you use any of the window shading related styles?
>
> WindowShadeSteps
> WindowShadeScrolls or WindowShadeShrinks
> WindowShadeLazy or WindowShadeAlwaysLazy or WindowShadeBusy
>
> Or the obsolete WindowShadeAnimate command?
I don't use any of them. Until this Chrome thing came
> 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 vm
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
> Chris Siebenmann writes:
>
> > 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
> >> 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. Immediat
> 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:
> > > >
> > > > Mouse 1
> > > > 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 ha
> 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?
>
>
> > 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 appl
> > 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 howeve
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 t
> Is there a differnce between a window, that was maximized using
> "Maximize 100 100" and a window that is maximized by "Move 0 0, Resize
> $[vp.width] $[vp.height]" ?
The obvious difference is that a Maximize-based maximization can be
reversed by fvwm, which remembers the previous window size (
> 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 th
> 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 bee
[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 gene
> 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 equival
> 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 edi
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 ("+in
> 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 s
53 matches
Mail list logo
