fluxbox-users — This list is for users of Fluxbox Window Manager.

[Fluxbox-users] ToggleDecor, Firefox, Chrome, Zoom, and a lack of amusement

[Swift G. <sw...@ir...>]

I recently read the Bug threads on Firefox/Mozilla concerning the change 
they made to drop window decorations from Firefox. They basically hand 
wave off the terrible decision and implementation with "It's been this way 
on MacOS and Windows forever". Then they trash Fluxbox and act like it's 
the fault of the Window Manager somehow, when in fact, they are simply 
abusing privileged they probably should never have had (getting rid of my 
Decor). If you want to read the thread, I can dig it up. In fact, the last 
entry suggests that Mozilla won't support or change anything unless it's 
for GNOME.

I have had reasonable luck with using "ToggleDecor" bound to a keystroke 
but lately some applications still won't show the Fluxbox titlebar even 
after using this technique.

Can I just throw a suggestion for a new configuration directive/option to 
absolutely disable this functionality/feature from any application? Ie...

AlwaysForceDecor: True

Or something like that? I really really hate this behavior by these 
applications that seem to consider themselves "above" minding my window 
manager. Maybe this is a good idea in some situations, but I can't think 
of what those would be. Even if it resulted in ever "Save As" sub-dialog 
having it's own decor, I'd still find that a lot better than the current 
behavior of "We took your toolbar. Haha. 'Upgrade' to windows, bruh".

Thanks so much for maintaining Fluxbox. I've been a user for ... uhm, 
about 21 years? I switched from Blackbox.

Thanks,
   Swift

Re: [Fluxbox-users] How to run 'tail' command from menu script

[D.T. <ohn...@po...>]

I just noticed that the other user recommended uxterm, not urxvt.

urxvt is notoriously tricky with -e, iirc I always used 

urxvt -hold -e 'sh -c "tail /some/text/file"'

"read x" is literally the command you use instead of "$SHELL"
Effect: <Enter> closes the window

On Mon, 2024-02-12 at 16:49 -0700, Duke Normandin wrote:
> On Mon, 12 Feb 2024 22:51:10 +0000
> "D.T." <ohn...@po...> wrote:
> 
> > 2 additions wrt the trailing ;$SHELL:
> > 
> > - You can replace it with ;read x
> > - Remove it and invoke urxvt with the -hold option to keep the
> > terminal open
> 
> urxvt -hold -fn "xft:Bitstream Vera Sans Mono:pixelsize=15"
> -fullscreen -bg black -fg green -e "tail -20
> ~/notes/leftoff.txt"
> 
>  urxvt: unable to exec child.
> 
> I don't get what you mean by `read x'? x is the filename?

Re: [Fluxbox-users] How to run 'tail' command from menu script

[Duke N. <sid...@gm...>]

On Mon, 12 Feb 2024 22:51:10 +0000
"D.T." <ohn...@po...> wrote:

> 2 additions wrt the trailing ;$SHELL:
> 
> - You can replace it with ;read x
> - Remove it and invoke urxvt with the -hold option to keep the
> terminal open

urxvt -hold -fn "xft:Bitstream Vera Sans Mono:pixelsize=15"
-fullscreen -bg black -fg green -e "tail -20
~/notes/leftoff.txt"

 urxvt: unable to exec child.

I don't get what you mean by `read x'? x is the filename?
-- 
Duke
** Bottom-posting, text-only is the netiquette way! **

Re: [Fluxbox-users] How to run 'tail' command from menu script

[D.T. <ohn...@po...>]

2 additions wrt the trailing ;$SHELL:

- You can replace it with ;read x
- Remove it and invoke urxvt with the -hold option to keep the terminal
open


On Mon, 2024-02-12 at 13:38 -0700, Duke Normandin wrote:
> On Mon, 12 Feb 2024 15:04:46 -0500
> Andrew Nevai <an...@gm...> wrote:
> 
> > # The following doesn't work! I've tried quite a few permutations
> > # & combinations thereof, but I haven't lucked-in on the correct
> > # one.
> > #
> > # urxvt -e tail ~/notes/<filename.txt>
> > #
> > # Any help would be appreciated! TIA ...
> > # --
> > # Duke
> > 
> [snip]
> 
> > Maybe:
> > 
> > {uxterm -e "tail ~/notes/<filename.txt>; $SHELL"}
> 
> That did it! Thx a bunch ..

Re: [Fluxbox-users] How to run 'tail' command from menu script

[Duke N. <sid...@gm...>]

On Mon, 12 Feb 2024 15:04:46 -0500
Andrew Nevai <an...@gm...> wrote:

> # The following doesn't work! I've tried quite a few permutations
> # & combinations thereof, but I haven't lucked-in on the correct
> # one.
> #
> # urxvt -e tail ~/notes/<filename.txt>
> #
> # Any help would be appreciated! TIA ...
> # --
> # Duke
> 
[snip]

> Maybe:
> 
> {uxterm -e "tail ~/notes/<filename.txt>; $SHELL"}

That did it! Thx a bunch ..
-- 
Duke
** Bottom-posting, text-only is the netiquette way! **

Re: [Fluxbox-users] How to run 'tail' command from menu script

[Andrew N. <an...@gm...>]

# The following doesn't work! I've tried quite a few permutations &
# combinations thereof, but I haven't lucked-in on the correct one.
#
# urxvt -e tail ~/notes/<filename.txt>
#
# Any help would be appreciated! TIA ...
# --
# Duke
# ** Bottom-posting, text-only is the netiquette way! **
#
#
# _______________________________________________
# Fluxbox-users mailing list
# Flu...@li...
# https://lists.sourceforge.net/lists/listinfo/fluxbox-users

Maybe:

{uxterm -e "tail ~/notes/<filename.txt>; $SHELL"}

[Fluxbox-users] How to run 'tail' command from menu script

[Duke N. <sid...@gm...>]

The following doesn't work! I've tried quite a few permutations &
combinations thereof, but I haven't lucked-in on the correct one.

urxvt -e tail ~/notes/<filename.txt>

Any help would be appreciated! TIA ...
-- 
Duke
** Bottom-posting, text-only is the netiquette way! **

Re: [Fluxbox-users] Webpages of fluxbox.org

[riveravaldez <riv...@gm...>]

On 11/1/23, Peter <pet...@gm...> wrote:
> Hi,
>
> I have just upgraded to Debian 12, and found that Lyx won't run.  In fact,
> it freezes the system and the only recourse is reboot.  Its definitely
> Fluxbox, because I installed MATE and Lyx seems to run perfectly in it.
> Have there been any significant changes to Fluxbox in Debian 12?  And where
> should I communicate this to? I managed to get a long QT Debug copied, but
> not being a developer it doesn't mean anything to me but I can send it on to
> anyone who would find it useful.
>
> Peter

Hi, Peter, just another user here.

Maybe you can try first reporting to Fluxbox Debian's package
maintainer, check the right column ("Links for fluxbox") there:

https://packages.debian.org/bookworm/fluxbox

Hope it helps.

Best of luck and kind regards!

Re: [Fluxbox-users] Webpages of fluxbox.org

[Peter<pet...@gm...>]

Hi,

I have just upgraded to Debian 12, and found that Lyx won't run.  In fact, it freezes the system and the only recourse is reboot.  Its definitely Fluxbox, because I installed MATE and Lyx seems to run perfectly in it.  Have there been any significant changes to Fluxbox in Debian 12?  And where should I communicate this to? I managed to get a long QT Debug copied, but not being a developer it doesn't mean anything to me but I can send it on to anyone who would find it useful.

Peter

Re: [Fluxbox-users] Fluxbox disimprovements on dual monitors

[Matt B. <mb...@gm...>]

Hi Johnatan,

One possible workaround would be using a keyboard shortcut to move the
maximized window to the other monitor.  Something like the following:

## ~/.fluxbox/keys
# Windows+; -> move current window's to next monitor
Mod4 semicolon :SendToNextHead

Out of curiosity, are you dragging the window by the top window handle /
titlebar, or using an alt+left-mouse drag?  It sounds like you're saying
when your mouse hits the edge between the two monitors the virtual desktop
starts switching (on one monitor or both of them?)

It's possible that there's some difference in your old vs new
configurations, either in how Fluxbox was packaged/built, or how the X
server is configured.  ie xinerama etc, it's possible to have your 2
monitors set up as a single X virtual screen, or two separate screens... or
the relative positions of the monitors might have changed when upgrading.
Any of those might affect the behavior of the bug you're describing.  The
output of `xdpyinfo` might give some clue, but you probably don't have the
old setup available to compare.

Matt

On Fri, Jun 30, 2023 at 3:46 AM Johnatan Hallman via Fluxbox-users <
flu...@li...> wrote:

> Hello,
>
> It took me more than +1 year after Debian 9 being EOLed to finally switch
> to Debian 11 AntiX due to so many custom apps and so many issues.
>
> Regardless the security patches in the new system, when one upgrades
> he/she expects to get a "better" product not something utterly crap with
> bloatware features nobody asked for. Anyway if I wouldn't upgrade none of
> the latest browsers firefox/chrome would support the OS soon.
>
> My new setup is:
>
> Fluxbox 1.3.7 : (c) 2001-2015 Fluxbox
>
> 00:02.0 VGA compatible controller: Intel Corporation Skylake GT2 [HD
> Graphics 520] (rev 07)
>
> xorg-server 2:1.20.11-1.0nosystemd3 (https://www.debian.org/support)
> Current version of pixman: 0.40.0
>
>
> There are some extremely annoying issues compared to running Fluxbox on
> the exact same laptop but with the old system:
>
> With a 2 monitor setup moving maximized windows make it switch like crazy
> in between the virtual desktops, sometimes it ends up positioning the
> window outside the area then you have to kill the process and reopen it.
> This was not happening at all on the old system.
>
> Also this might not be related to Fluxbox but moving video players like
> VLC between the 2 screens makes the running video sluggish, this was also
> not present with the old Debian and old X.
>
>
>
> I wonder if Flux is still being developed... it would be nice to have a
> proper taskbar per monitor option. It can do taskbar on specific heads or
> on ALL but when you select ALL it just makes a huge taskbar and put the
> apps in order when you started. Having 2 taskbars on the 2 monitors would
> be better with each only displaying the corresponding apps.
>
>
>
>
>
>
> _______________________________________________
> Fluxbox-users mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-users
>

[Fluxbox-users] Fluxbox disimprovements on dual monitors

[Johnatan H. <joh...@pr...>]

Hello,

It took me more than +1 year after Debian 9 being EOLed to finally switch to Debian 11 AntiX due to so many custom apps and so many issues.

Regardless the security patches in the new system, when one upgrades he/she expects to get a "better" product not something utterly crap with bloatware features nobody asked for. Anyway if I wouldn't upgrade none of the latest browsers firefox/chrome would support the OS soon.

My new setup is:

Fluxbox 1.3.7 : (c) 2001-2015 Fluxbox 

00:02.0 VGA compatible controller: Intel Corporation Skylake GT2 [HD Graphics 520] (rev 07)

xorg-server 2:1.20.11-1.0nosystemd3 (https://www.debian.org/support) 
Current version of pixman: 0.40.0


There are some extremely annoying issues compared to running Fluxbox on the exact same laptop but with the old system:

With a 2 monitor setup moving maximized windows make it switch like crazy in between the virtual desktops, sometimes it ends up positioning the window outside the area then you have to kill the process and reopen it. This was not happening at all on the old system.

Also this might not be related to Fluxbox but moving video players like VLC between the 2 screens makes the running video sluggish, this was also not present with the old Debian and old X.



I wonder if Flux is still being developed... it would be nice to have a proper taskbar per monitor option. It can do taskbar on specific heads or on ALL but when you select ALL it just makes a huge taskbar and put the apps in order when you started. Having 2 taskbars on the 2 monitors would be better with each only displaying the corresponding apps. 

Re: [Fluxbox-users] keys setting overridden by fluxbox-update_configs

[klu <kl...@gm...>]

The work-around I found out so far, is to "no-op" fluxbox-update_configs:

  ln -sf /usr/bin/true /usr/loca/bin/fluxbox-update_configs

On Sun, Nov 27, 2022 at 10:49 AM klu <kl...@gm...> wrote:
>
> My `~/.fluxbox/keys` file contains the following lines:
>
> [...]
> OnTitlebar Double Mouse1 :Maximize
> [...]
>
>
> However, it seems that fluxbox on startup and on exit, will prepend a
> few lines of configs, including below lines, to the beginning of my
> keys file:
>
> !mouse actions added by fluxbox-update_configs
> OnTitlebar Double Mouse1 :Shade
>
>
> This essentially overwrite my setting. I have no idea what triggered
> fluxbox-update_configs. And there's no mention of this tool in the
> manpage.
>
> Is there a way I can disable auto config saving?
>
>
> ---
>
> Fluxbox version: 1.3.7
> GIT Revision: unknown
> Compiled: Apr  7 2022 11:27:03
> Compiler: CLANG
> Compiler version: FreeBSD Clang 11.0.1
> (gi...@gi...:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
>
> Defaults:
> menu: /usr/local/share/fluxbox/menu
> windowmenu: /usr/local/share/fluxbox/windowmenu
> style: /usr/local/share/fluxbox/styles/bloe
> keys: /usr/local/share/fluxbox/keys
> init: /usr/local/share/fluxbox/init
> nls: /usr/local/share/fluxbox/nls
>
> Compiled options (- => disabled):
> BIDI
> -DEBUG
> EWMH
> -IMLIB2
> NLS
> REMEMBER
> RENDER
> SHAPE
> SLIT
> SYSTEMTRAY
> TOOLBAR
> RANDR
> XFT
> XINERAMA
> XMB
> XPM

[Fluxbox-users] keys setting overridden by fluxbox-update_configs

[klu <kl...@gm...>]

My `~/.fluxbox/keys` file contains the following lines:

[...]
OnTitlebar Double Mouse1 :Maximize
[...]


However, it seems that fluxbox on startup and on exit, will prepend a
few lines of configs, including below lines, to the beginning of my
keys file:

!mouse actions added by fluxbox-update_configs
OnTitlebar Double Mouse1 :Shade


This essentially overwrite my setting. I have no idea what triggered
fluxbox-update_configs. And there's no mention of this tool in the
manpage.

Is there a way I can disable auto config saving?


---

Fluxbox version: 1.3.7
GIT Revision: unknown
Compiled: Apr  7 2022 11:27:03
Compiler: CLANG
Compiler version: FreeBSD Clang 11.0.1
(gi...@gi...:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)

Defaults:
menu: /usr/local/share/fluxbox/menu
windowmenu: /usr/local/share/fluxbox/windowmenu
style: /usr/local/share/fluxbox/styles/bloe
keys: /usr/local/share/fluxbox/keys
init: /usr/local/share/fluxbox/init
nls: /usr/local/share/fluxbox/nls

Compiled options (- => disabled):
BIDI
-DEBUG
EWMH
-IMLIB2
NLS
REMEMBER
RENDER
SHAPE
SLIT
SYSTEMTRAY
TOOLBAR
RANDR
XFT
XINERAMA
XMB
XPM

[Fluxbox-users] building without toolbar, slit, neither tray (with lxqt and picom)

[Javier <je-vv@e.email>]

Hello !

Please CC me, for some weird reason my confirmation mail when subscribing to the ML doesn't work.

Hey, I've been using fluxbox-wm [1] from AUR (Artix/Arch), which is no more than fluxbox built with:

>     --disable-slit \
>     --disable-systray \
>     --disable-toolbar

In addition to the other configuration options stock fluxbox Arch sets...  I have to build fluxbox that way, since plain fluxbox has several issues running with lxqt and picom.

To start with, even while calling plain fluxbox with ** -no-toolbar -no-slit **, it so happens fluxbox starts effectively with no toolbar, but with an empty space as if it has a toolbar.  And one can sort of work around that by restarting fluxbox by calling the fluxbox ** Restart ** command, however it's like if fluxbox was setting a fullscreen wallpaper on the space excluding the lxqt panel, which is really weird to start with, since I set the overlay with background ** unset ** or ** none **.

Those issues are only present if not building fluxbox with ** --disable-slit --disable-systray --disable-toolbar **.  Whereas if building it with them, none of those issues show up.

However, I'm experiencing that after a while of having the screen both locked down, and auto turned off or turned off, when turning the screen back on, and unlocking, although fluxbox is still alive, the windows decorations are lost, so windows have already lost their titlebar for example.  The only way to recover them is to call the fluxbox ** Restart ** command.

So I tried moving from current commit SHA on the fluxbox-wm AUR package (e2cbd179ecb2ef2d76e0ad1fde84b44325305799) to the same commit SHA the Arch fluxbox package is using (1d19662c8975e881b4fa6465a8305be3ea5282ee).  Notice the commit stock Arch is using is just 6 commits behind head of master, while the fluxbox-wm from AUR (again same package, just to build without slit, toolbar and tray), is a bunch of commits behind.  When moving to the newer stock Arch fluxbox commit, the following linking error while building shows up:

> g++ -DHAVE_CONFIG_H -I.  -include ./config.h   -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS  -MT src/defaults.o -MD -MP -MF $depbase.Tpo -c -o src/defaults.o src/defaults.cc &&\
> mv -f $depbase.Tpo $depbase.Po
> g++  -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS   -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -o fluxbox src/fluxbox-AlphaMenu.o src/fluxbox-ArrowButton.o src/fluxbox-AttentionNoticeHandler.o src/fluxbox-CascadePlacement.o src/fluxbox-ClientMenu.o src/fluxbox-ClientPattern.o src/fluxbox-ColSmartPlacement.o src/fluxbox-CommandDialog.o src/fluxbox-ConfigMenu.o src/fluxbox-CurrentWindowCmd.o src/fluxbox-FbAtoms.o src/fluxbox-FbCommands.o src/fluxbox-FbMenu.o src/fluxbox-FbMenuParser.o src/fluxbox-FbRootWindow.o src/fluxbox-FbWinFrame.o src/fluxbox-FbWinFrameTheme.o src/fluxbox-FocusControl.o src/fluxbox-FocusableList.o src/fluxbox-HeadArea.o src/fluxbox-IconButton.o src/fluxbox-IconbarTheme.o src/fluxbox-Keys.o src/fluxbox-LayerMenu.o src/fluxbox-MenuCreator.o src/fluxbox-MinOverlapPlacement.o src/fluxbox-OSDWindow.o src/fluxbox-Resources.o src/fluxbox-RootCmdMenuItem.o src/fluxbox-RootTheme.o src/fluxbox-RowSmartPlacement.o src/fluxbox-Screen.o src/fluxbox-ScreenPlacement.o src/fluxbox-ScreenResource.o src/fluxbox-SendToMenu.o src/fluxbox-ShortcutManager.o src/fluxbox-StyleMenuItem.o src/fluxbox-TextDialog.o src/fluxbox-TooltipWindow.o src/fluxbox-UnderMousePlacement.o src/fluxbox-WinButton.o src/fluxbox-WinButtonTheme.o src/fluxbox-WinClient.o src/fluxbox-Window.o src/fluxbox-WindowCmd.o src/fluxbox-WindowState.o src/fluxbox-Workspace.o src/fluxbox-WorkspaceCmd.o src/fluxbox-WorkspaceMenu.o src/fluxbox-Xutil.o src/fluxbox-fluxbox.o src/fluxbox-main.o src/fluxbox-cli_cfiles.o src/fluxbox-cli_options.o src/fluxbox-cli_info.o src/fluxbox-Ewmh.o src/fluxbox-Remember.o   libFbTk.a src/defaults.o -lfontconfig -lfreetype  -lfreetype  -lfribidi  -lImlib2  -lXrandr  -lXext  -lXft  -lXinerama  -lXpm -lX11  -lXrender -lX11  -lX11   -lrt  -lm
> /usr/bin/ld: src/fluxbox-IconButton.o: warning: relocation against `_ZN11IconbarTool21s_iconifiedDecorationB5cxx11E' in read-only section `.text'
> /usr/bin/ld: src/fluxbox-IconButton.o: in function `IconButton::setupWindow()':
> IconButton.cc:(.text+0x132b): undefined reference to `IconbarTool::s_iconifiedDecoration[abi:cxx11]'
> /usr/bin/ld: IconButton.cc:(.text+0x133f): undefined reference to `IconbarTool::s_iconifiedDecoration[abi:cxx11]'
> /usr/bin/ld: IconButton.cc:(.text+0x1350): undefined reference to `IconbarTool::s_iconifiedDecoration[abi:cxx11]'
> /usr/bin/ld: warning: creating DT_TEXTREL in a PIE
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:2165: fluxbox] Error 1
> make[2]: Leaving directory '/home/general/.pkgs/src/others/fluxbox-wm/src/fluxbox'
> make[1]: *** [Makefile:4901: all-recursive] Error 1
> make[1]: Leaving directory '/home/general/.pkgs/src/others/fluxbox-wm/src/fluxbox'
> make: *** [Makefile:1760: all] Error 2
> ==> ERROR: A failure occurred in build().
>     Aborting...
> 

I then tried building with the head of master commit (9d8202f32338a3f08d3fa39057dc5eec5d97be4e), to see if that was somehow fixed, and I got exactly the same error.  So it seems building with ** --disable-slit --disable-systray --disable-toolbar ** is not working anymore after commit e2cbd179ecb2ef2d76e0ad1fde84b44325305799.  Please notice if I build the same fluxbox commit, but without those options, it builds just fine, but that's not what I'm looking for.  The fluxbox-wm AUR maintainer mentioned e2cbd179ecb2ef2d76e0ad1fde84b44325305799 is sort of the last commit which builds fine with those options [3]...

Has support to build recent fluxbox commits with ** --disable-slit --disable-systray --disable-toolbar ** being dropped?  It seems it's the only way I can get it working with lxqt and picom.

Please let me know, and remember to CC me, :)

Thanks !

-- 
Javier


[1]  https://aur.archlinux.org/packages/fluxbox-wm
[2]  https://archlinux.org/packages/extra/x86_64/fluxbox
[3]  https://aur.archlinux.org/packages/fluxbox-wm#comment-885519

Re: [Fluxbox-users] Windows created have weird dimensions on Debian with Fluxbox

[Peter P. <pet...@fa...>]

Matt,

* Matt Banack <mb...@gm...> [2022-06-14 23:12]:
> Hi Peter,
> 
> You can look into ~/.fluxbox/apps (`man fluxbox-apps`) to set default
> dimensions for a certain window.  Matching is done with xprop properties,
> ie name= and class=... run `xprop` from a terminal and point it at the
> window in question to confirm the prop values.  You'll want something like:
> 
> [app] (name=scide)
>   [Dimensions] {400 400}
>   [Position] (CENTER) {0% 0%}
> [end]

Thank you, If I tell the odd window to remeber its dimensions I get the
following entry
	[app] (name=SuperCollider) (class=SuperCollider)
  	  [Dimensions]  {0% 2%}
	[end]
created.
 
> It's possible scide is doing something odd to try to change its own window
> dimensions after it opens the window, in which case the apps solution may
> or may not work.  Best of luck :)

If I change this in this textfile to 
	[app] (name=SuperCollider) (class=SuperCollider)
  	  [Dimensions]  {100% 100%}
	[end]

the window is created the same (above, wrong) dimensions. What is important to
know that the problematic window is a subwindow of scide, namely "Show node tree"
and not the main scide IDE window.

What is puzzlig is that this is not a problem on openbox.

Thanks for your help Matt!
Peter

Re: [Fluxbox-users] Windows created have weird dimensions on Debian with Fluxbox

[Matt B. <mb...@gm...>]

Hi Peter,

You can look into ~/.fluxbox/apps (`man fluxbox-apps`) to set default
dimensions for a certain window.  Matching is done with xprop properties,
ie name= and class=... run `xprop` from a terminal and point it at the
window in question to confirm the prop values.  You'll want something like:

[app] (name=scide)
  [Dimensions] {400 400}
  [Position] (CENTER) {0% 0%}
[end]

It's possible scide is doing something odd to try to change its own window
dimensions after it opens the window, in which case the apps solution may
or may not work.  Best of luck :)

Matt

On Sat, Jun 11, 2022 at 12:36 AM Peter P. <pet...@fa...> wrote:

> Hi list,
>
> Windows created in the program "Supercollider" (Debian package
> supercollider, binary scide) are displayed only with their title bar, and
> this
> bar has very large horizontal dimensions, reaching beyond my desktop
> borders. The wmctl utility reports the dimensions 65535x65535 for this
> window:
>  $ wmctl -l -G
>  [...]
>  0x0100001d  0 60   100  65535 65535 zoot localhost Node Tree
> This happens to other windows of the same program too.
>
> I can only get to see this window's contents by maximizing it,
> which does not allow me to work at this programs main window at the same
> time.
>
> This does not happen with, say, openbox. There the window has the
> correct geometry of 400x400 there.
>  $ wmctl -l -G
>  [...]
>  0x00a00025  0 5    40   400  400  zoot localhost Node Tree
>
> I can resize the weird window in fluxbox with the same wmctl command
>  $ wmctrl -r localhost -e 0,0,0,400,400
> which makes it display normally. However, if I close and open it again
> it is back at 65535x65535.
>
> I'd be happy to learn about all possible sources for this problem,
> thank you so much!
> Peter
>
>
> _______________________________________________
> Fluxbox-users mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-users
>

[Fluxbox-users] Windows created have weird dimensions on Debian with Fluxbox

[Peter P. <pet...@fa...>]

Hi list,

Windows created in the program "Supercollider" (Debian package
supercollider, binary scide) are displayed only with their title bar, and this
bar has very large horizontal dimensions, reaching beyond my desktop
borders. The wmctl utility reports the dimensions 65535x65535 for this
window:
 $ wmctl -l -G 
 [...]
 0x0100001d  0 60   100  65535 65535 zoot localhost Node Tree
This happens to other windows of the same program too.

I can only get to see this window's contents by maximizing it,
which does not allow me to work at this programs main window at the same time. 

This does not happen with, say, openbox. There the window has the
correct geometry of 400x400 there.
 $ wmctl -l -G 
 [...]
 0x00a00025  0 5    40   400  400  zoot localhost Node Tree

I can resize the weird window in fluxbox with the same wmctl command
 $ wmctrl -r localhost -e 0,0,0,400,400
which makes it display normally. However, if I close and open it again
it is back at 65535x65535.

I'd be happy to learn about all possible sources for this problem,
thank you so much!
Peter

[Fluxbox-users] losing window focus when switching desktops

[Peter P. <pet...@fa...>]

Hi list,

when I am using FB on my laptop with an external display mirroring the
internal one, and with the external display being slighly smaller,
window focus is lost when switching desktop.

Steps to reproduce:
Laptop display at 1366x768 
HDMI display at 1280x720
create a window (focussed)
switch to another desktop
switch back
window no longer focused.

or:
[...]
create two windows (one focussed)
switch to another desktop
switch back
the other one is focussed now.

This does not appear when the two display have identical display
resolution.

Is this a FB problem or about X?

Thank you for all hints!
Peter

Re: [Fluxbox-users] What can we not compile into fluxbox?

[M. M. <azn...@gm...>]

Woah! That was much more detailed answer than I would have ever expected.
Thank you for your answer, you convinced me that it is not worth the
effort. Also I lack the knowledge to do so.

niedz., 1 maj 2022 o 17:56 Matt Banack <mb...@gm...> napisał(a):

> Hi Maciej,
>
> With the caveat that I'm a passionate user and haven't contributed
> anything to the codebase (yet).  The short answer is no, unless you're
> willing to dive into the source and change things.
>
> > Just curious, are the any other things we can not compile into fluxbox
> besides what is shown after "./configure --help"?
> If you're interested in the internals, you can look at the autoconf file
> configure.ac and see how those configure options get mapped to #defines.
> Then you can look through the code for things like #ifdef XINERAMA, #ifdef
> USE_TOOLBAR.  If you *really* want to slim down your binary as much as
> possible, you could look at the config.h defines starting with HAVE_ and
> evaluate them individually... if you override the detection for which
> things you have available, some of those will compile out code, but some of
> them will just take alternate paths.  You will likely be sacrificing
> features and/or performance by doing this, but it's up to you to evaluate
> them individually.  There is an implicit assumption that no one would ever
> want to turn those off, but YMMV.
>
> As far as window managers go, fluxbox is already on the extremely lean
> side.  I think you will find that the benefit of not compiling something
> like tab support (if you're not using tabs) doesn't get you any real
> performance win.
>
> #ifdef can work well for some things that are relatively
> self-contained, but usually comes at a cost in code readability.  Tabbing
> is central enough to the design of FB that it would be invasive to try to
> take it out at compilation -- of course if someone was motivated, it's
> possible to go do on a local tree to test the final binary size and compare
> performance.  You would end up with a slightly smaller binary, but the
> amount of work involved would probably not pay off (and getting it
> upstreamed is a separate question).
>
> Matt
>
> On Wed, Apr 20, 2022 at 6:25 AM Maciej M. <azn...@gm...> wrote:
>
>> Just curious, are the any other things we can not compile into fluxbox
>> besides what is shown after "./configure --help"?
>>
>> For me personally this flexibility is strong attribute of Fluxbox as I do
>> not compile in parts I do not need.
>>
>> Would love not to compile in window tabbing but as far as I know it is
>> not possible. Or maybe I am wrong and there is a way? Anyone?
>> _______________________________________________
>> Fluxbox-users mailing list
>> Flu...@li...
>> https://lists.sourceforge.net/lists/listinfo/fluxbox-users
>>
>

Re: [Fluxbox-users] Strange problem when using the "F" keys in key shortcuts, what is wrong?

[M. M. <azn...@gm...>]

Hello Matt and thanks for the tips!

Of course adding None before the F key did not change anything but it was
nice to at least give it a go. Do not want to dig so deep into it to play
with keymode stuff as it does not bother me much. Of course I was curious
how to bypass it but to be honest I was also curious if that's normal
behaviour - not as I know that it is absolutely normal I am cool with it.

niedz., 1 maj 2022 o 17:07 Matt Banack <mb...@gm...> napisał(a):

> Hi MM,
>
> Try prefacing each line with "None".
>
> None F1 Escape :RootMenu
>
> But you will still probably have problems using F1-F4 for their normal
> function, as after pressing ie F4, Fluxbox is waiting to see if you
> complete any of the defined chains.  If you press some other key that
> doesn't complete a chain, I believe it would then press the original F-key
> and then the new key.  Also note the line from the fluxbox-keys manpage:
> "To abort a chained command part-way through typing it, press the <ESC>
> key."
>
> You should also look into KeyMode, you can do something like this:
> None F1 :KeyMode fone
> fone: None h :Exec whatever
> fone: None a :Exec somethingelse
> # actually send an F1 key ... note that I didn't actually test this... I'm
> pretty sure if you're in keymode "fone", just pressing F1 again would send
> the key through as normal
> fone: None space :Exec xdotool key F1
> # return to normal mode
> fone: None Esc :KeyMode default
>
> Then pressing F1 puts you into a special mode where the other bindings are
> active, so F1, a, h, a, ESC would enter the mode, exec 3 things, and then
> return to normal mode.  You could also use MacroCmd to Exec something and
> then automatically do KeyMode default.
>
> I'm not aware of any built-in way to send keystrokes that specifically
> bypass the shortcut system.  If anyone else knows I'd be interested,
> otherwise maybe that's something to consider as a new command?  That would
> make it a lot easier to reason about something like this, ie use "None F1"
> as a leader key for shortcuts, but if you actually want to type F1 then
> bind "Mod4 F1" to send a raw F1.
>
> Matt
>
> On Sat, Apr 23, 2022 at 3:47 PM M. M. <azn...@gm...> wrote:
>
>> Hello, I have rather unusual problem with keybindings in Fluxbox that
>> started since I decided to use more F keys on my desktop. It is related as
>> after removing these bindings things go back to normal - yet, I think it
>> shouldn't happen.
>>
>> Using stable 1.3.7 Fluxbox version and keyboard layout is set to "pl, pl".
>>
>> Here are my F keys related bindings:
>>
>> F1 Escape :RootMenu
>> F1 Return :Exec urxvt
>> F1 H :Exec xmessage -fn -*-fixed-*-*-*-*-18-*-*-*-*-*-*-* -bg gray15 -fg
>> gray -center -file ~/.fluxbox/keys
>>
>> F2 Left :PrevWorkspace
>> F2 Right :NextWorkspace
>> F2 Escape Left :SendToWorkspace 1
>> F2 Escape Right :SendToWorkspace 2
>> F2 Shift Left :TakeToPrevWorkspace
>> F2 Shift Right :TakeToNextWorkspace
>>
>> F3 C :Close
>> F3 M :Maximize
>> F3 N :Minimize
>> F3 F11 :Fullscreen
>> F3 Up             :MacroCmd {SetDecor NORMAL} {ShadeOn}
>> F3 Down           :MacroCmd {ShadeOff} {SetDecor BORDER}
>>
>> F4 Right :MacroCmd {ResizeTo 50% 100%} {MoveTo 00 00 Right}
>> F4 Left :MacroCmd {ResizeTo 50% 100%} {MoveTo 00 00 Left}
>> F4 Up :MacroCmd {ResizeTo 100% 50%} {MoveTo 00 00 Top}
>> F4 Down :MacroCmd {ResizeTo 100% 50%} {MoveTo 00 00 Bottom}
>>
>> F4 Prior :MacroCmd {ResizeTo 50% 50%} {MoveTo 00 00 TopRight}
>> F4 Insert :MacroCmd {ResizeTo 50% 50%} {MoveTo 00 00 TopLeft}
>> F4 Next :MacroCmd {ResizeTo 50% 50%} {MoveTo 00 00 BottomRight}
>> F4 Delete :MacroCmd {ResizeTo 50% 50%} {MoveTo 00 00 BottomLeft}
>>
>> Now, what is wrong: when I press F1-F4 keys on my desktop with no windows
>> open and after that I try to for example use right mouse button to open the
>> root menu it does not open - there is no reaction. When I press the F1-F4
>> key again(does not matter, I can press F1 to make it happen and later F3 to
>> fix it) - all works. It seems like because of these keys are being in key
>> bindings they got some kind of "function"? Cannot explain it better, they
>> just put desktop in some kind of "state" when pressed and release that
>> "state" when pressed again. Like some kind of layer is being put on top of
>> the desktop, I dunno how to properly explain it.
>>
>> I was totally surprised when I found out that these keys being used in
>> keys file are the reason for my desktop strange behaviour and I am very
>> curious where is the problem. Hope someone will be able to help me
>> understand what is actually going on.
>> _______________________________________________
>> Fluxbox-users mailing list
>> Flu...@li...
>> https://lists.sourceforge.net/lists/listinfo/fluxbox-users
>>
>

Re: [Fluxbox-users] Uses 100% Cpu after resuming from suspend

[Peter P. <pet...@fa...>]

* D.T. <ohn...@po...> [2022-04-21 08:13]:
> On Tue, 2022-04-19 at 22:20 +0200, Peter P. wrote:
> > Hi list,
> > 
> > occasionaly at resuming my laptop from suspend, fluxbox will not
> > react
> > and shows 100% CPU at one of my four cores. I have to force-reboot
> > the
> > computer with its power button. This happens once every 20 or so
> > times
> > when resuming.  How can I go about debugging this further? Keeping a
> > fluxbox log per its startup file in -log "/home/me/.fluxbox/log" does
> > not produce any output when the above condition is triggered.
> > 
> 
> First of all, are you sure it is fluxbox itself using 100%, or just
> something?
> Assuming your system is still usable, make first sure of that.
Thanks D.T. 
htop and top tell me it is fluxbox itself.

> Then look at various logs, Xorg but also also system logs and dmesg.
xorg.log does not give any warnings or errors.
dmesg does not give anything suspicious to me.
journalctl contains a lot, nothing abnormal, perhaps:
 systemd-xdg-autostart-generator[734470]: Exec binary '/usr/bin/gnome-keyring-daemon' does not exist: No such file or directory
but this seems unrelated to fluxbox...

> Which distro is this?
This is Debian stable with FB 1.3.5-2+b2

Thanks again!

Re: [Fluxbox-users] What can we not compile into fluxbox?

[Matt B. <mb...@gm...>]

Hi Maciej,

With the caveat that I'm a passionate user and haven't contributed anything
to the codebase (yet).  The short answer is no, unless you're willing to
dive into the source and change things.

> Just curious, are the any other things we can not compile into fluxbox
besides what is shown after "./configure --help"?
If you're interested in the internals, you can look at the autoconf file
configure.ac and see how those configure options get mapped to #defines.
Then you can look through the code for things like #ifdef XINERAMA, #ifdef
USE_TOOLBAR.  If you *really* want to slim down your binary as much as
possible, you could look at the config.h defines starting with HAVE_ and
evaluate them individually... if you override the detection for which
things you have available, some of those will compile out code, but some of
them will just take alternate paths.  You will likely be sacrificing
features and/or performance by doing this, but it's up to you to evaluate
them individually.  There is an implicit assumption that no one would ever
want to turn those off, but YMMV.

As far as window managers go, fluxbox is already on the extremely lean
side.  I think you will find that the benefit of not compiling something
like tab support (if you're not using tabs) doesn't get you any real
performance win.

#ifdef can work well for some things that are relatively
self-contained, but usually comes at a cost in code readability.  Tabbing
is central enough to the design of FB that it would be invasive to try to
take it out at compilation -- of course if someone was motivated, it's
possible to go do on a local tree to test the final binary size and compare
performance.  You would end up with a slightly smaller binary, but the
amount of work involved would probably not pay off (and getting it
upstreamed is a separate question).

Matt

On Wed, Apr 20, 2022 at 6:25 AM Maciej M. <azn...@gm...> wrote:

> Just curious, are the any other things we can not compile into fluxbox
> besides what is shown after "./configure --help"?
>
> For me personally this flexibility is strong attribute of Fluxbox as I do
> not compile in parts I do not need.
>
> Would love not to compile in window tabbing but as far as I know it is not
> possible. Or maybe I am wrong and there is a way? Anyone?
> _______________________________________________
> Fluxbox-users mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-users
>

Re: [Fluxbox-users] Strange problem when using the "F" keys in key shortcuts, what is wrong?

[Matt B. <mb...@gm...>]

Hi MM,

Try prefacing each line with "None".

None F1 Escape :RootMenu

But you will still probably have problems using F1-F4 for their normal
function, as after pressing ie F4, Fluxbox is waiting to see if you
complete any of the defined chains.  If you press some other key that
doesn't complete a chain, I believe it would then press the original F-key
and then the new key.  Also note the line from the fluxbox-keys manpage:
"To abort a chained command part-way through typing it, press the <ESC>
key."

You should also look into KeyMode, you can do something like this:
None F1 :KeyMode fone
fone: None h :Exec whatever
fone: None a :Exec somethingelse
# actually send an F1 key ... note that I didn't actually test this... I'm
pretty sure if you're in keymode "fone", just pressing F1 again would send
the key through as normal
fone: None space :Exec xdotool key F1
# return to normal mode
fone: None Esc :KeyMode default

Then pressing F1 puts you into a special mode where the other bindings are
active, so F1, a, h, a, ESC would enter the mode, exec 3 things, and then
return to normal mode.  You could also use MacroCmd to Exec something and
then automatically do KeyMode default.

I'm not aware of any built-in way to send keystrokes that specifically
bypass the shortcut system.  If anyone else knows I'd be interested,
otherwise maybe that's something to consider as a new command?  That would
make it a lot easier to reason about something like this, ie use "None F1"
as a leader key for shortcuts, but if you actually want to type F1 then
bind "Mod4 F1" to send a raw F1.

Matt

On Sat, Apr 23, 2022 at 3:47 PM M. M. <azn...@gm...> wrote:

> Hello, I have rather unusual problem with keybindings in Fluxbox that
> started since I decided to use more F keys on my desktop. It is related as
> after removing these bindings things go back to normal - yet, I think it
> shouldn't happen.
>
> Using stable 1.3.7 Fluxbox version and keyboard layout is set to "pl, pl".
>
> Here are my F keys related bindings:
>
> F1 Escape :RootMenu
> F1 Return :Exec urxvt
> F1 H :Exec xmessage -fn -*-fixed-*-*-*-*-18-*-*-*-*-*-*-* -bg gray15 -fg
> gray -center -file ~/.fluxbox/keys
>
> F2 Left :PrevWorkspace
> F2 Right :NextWorkspace
> F2 Escape Left :SendToWorkspace 1
> F2 Escape Right :SendToWorkspace 2
> F2 Shift Left :TakeToPrevWorkspace
> F2 Shift Right :TakeToNextWorkspace
>
> F3 C :Close
> F3 M :Maximize
> F3 N :Minimize
> F3 F11 :Fullscreen
> F3 Up             :MacroCmd {SetDecor NORMAL} {ShadeOn}
> F3 Down           :MacroCmd {ShadeOff} {SetDecor BORDER}
>
> F4 Right :MacroCmd {ResizeTo 50% 100%} {MoveTo 00 00 Right}
> F4 Left :MacroCmd {ResizeTo 50% 100%} {MoveTo 00 00 Left}
> F4 Up :MacroCmd {ResizeTo 100% 50%} {MoveTo 00 00 Top}
> F4 Down :MacroCmd {ResizeTo 100% 50%} {MoveTo 00 00 Bottom}
>
> F4 Prior :MacroCmd {ResizeTo 50% 50%} {MoveTo 00 00 TopRight}
> F4 Insert :MacroCmd {ResizeTo 50% 50%} {MoveTo 00 00 TopLeft}
> F4 Next :MacroCmd {ResizeTo 50% 50%} {MoveTo 00 00 BottomRight}
> F4 Delete :MacroCmd {ResizeTo 50% 50%} {MoveTo 00 00 BottomLeft}
>
> Now, what is wrong: when I press F1-F4 keys on my desktop with no windows
> open and after that I try to for example use right mouse button to open the
> root menu it does not open - there is no reaction. When I press the F1-F4
> key again(does not matter, I can press F1 to make it happen and later F3 to
> fix it) - all works. It seems like because of these keys are being in key
> bindings they got some kind of "function"? Cannot explain it better, they
> just put desktop in some kind of "state" when pressed and release that
> "state" when pressed again. Like some kind of layer is being put on top of
> the desktop, I dunno how to properly explain it.
>
> I was totally surprised when I found out that these keys being used in
> keys file are the reason for my desktop strange behaviour and I am very
> curious where is the problem. Hope someone will be able to help me
> understand what is actually going on.
> _______________________________________________
> Fluxbox-users mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-users
>

[Fluxbox-users] Strange problem when using the "F" keys in key shortcuts, what is wrong?

[M. M. <azn...@gm...>]

Hello, I have rather unusual problem with keybindings in Fluxbox that
started since I decided to use more F keys on my desktop. It is related as
after removing these bindings things go back to normal - yet, I think it
shouldn't happen.

Using stable 1.3.7 Fluxbox version and keyboard layout is set to "pl, pl".

Here are my F keys related bindings:

F1 Escape :RootMenu
F1 Return :Exec urxvt
F1 H :Exec xmessage -fn -*-fixed-*-*-*-*-18-*-*-*-*-*-*-* -bg gray15 -fg
gray -center -file ~/.fluxbox/keys

F2 Left :PrevWorkspace
F2 Right :NextWorkspace
F2 Escape Left :SendToWorkspace 1
F2 Escape Right :SendToWorkspace 2
F2 Shift Left :TakeToPrevWorkspace
F2 Shift Right :TakeToNextWorkspace

F3 C :Close
F3 M :Maximize
F3 N :Minimize
F3 F11 :Fullscreen
F3 Up             :MacroCmd {SetDecor NORMAL} {ShadeOn}
F3 Down           :MacroCmd {ShadeOff} {SetDecor BORDER}

F4 Right :MacroCmd {ResizeTo 50% 100%} {MoveTo 00 00 Right}
F4 Left :MacroCmd {ResizeTo 50% 100%} {MoveTo 00 00 Left}
F4 Up :MacroCmd {ResizeTo 100% 50%} {MoveTo 00 00 Top}
F4 Down :MacroCmd {ResizeTo 100% 50%} {MoveTo 00 00 Bottom}

F4 Prior :MacroCmd {ResizeTo 50% 50%} {MoveTo 00 00 TopRight}
F4 Insert :MacroCmd {ResizeTo 50% 50%} {MoveTo 00 00 TopLeft}
F4 Next :MacroCmd {ResizeTo 50% 50%} {MoveTo 00 00 BottomRight}
F4 Delete :MacroCmd {ResizeTo 50% 50%} {MoveTo 00 00 BottomLeft}

Now, what is wrong: when I press F1-F4 keys on my desktop with no windows
open and after that I try to for example use right mouse button to open the
root menu it does not open - there is no reaction. When I press the F1-F4
key again(does not matter, I can press F1 to make it happen and later F3 to
fix it) - all works. It seems like because of these keys are being in key
bindings they got some kind of "function"? Cannot explain it better, they
just put desktop in some kind of "state" when pressed and release that
"state" when pressed again. Like some kind of layer is being put on top of
the desktop, I dunno how to properly explain it.

I was totally surprised when I found out that these keys being used in keys
file are the reason for my desktop strange behaviour and I am very curious
where is the problem. Hope someone will be able to help me understand what
is actually going on.

Re: [Fluxbox-users] Uses 100% Cpu after resuming from suspend

[D.T. <ohn...@po...>]

On Tue, 2022-04-19 at 22:20 +0200, Peter P. wrote:
> Hi list,
> 
> occasionaly at resuming my laptop from suspend, fluxbox will not
> react
> and shows 100% CPU at one of my four cores. I have to force-reboot
> the
> computer with its power button. This happens once every 20 or so
> times
> when resuming.  How can I go about debugging this further? Keeping a
> fluxbox log per its startup file in -log "/home/me/.fluxbox/log" does
> not produce any output when the above condition is triggered.
> 

First of all, are you sure it is fluxbox itself using 100%, or just
something?
Assuming your system is still usable, make first sure of that.
Then look at various logs, Xorg but also also system logs and dmesg.
Which distro is this?

> Thank you in advance for any help, this is a super annoying problem
> and
> I am happy for any advice here!
> 
> cheers, P
> 
> 
> _______________________________________________
> Fluxbox-users mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-users

___

Vaccines for everyone!
Donate to the COVAX alliance:
https://gogiveone.org/ (WHO)
https://www.gavi.org/donate (Gavi)