fluxbox-devel — Here the development takes place. Send bugs, patches and related stuff over here

Re: [Fluxbox-devel] Firefox and Thunderbird lose window border and controls (maybe bug #1182)

[Frank L. <fr...@mc...>]

Hi Marc,

So you say, there will be no fix in earlier Versions, even so it is 
broken in amd64 but not in i386. Just so I do understand that right (I'm 
quite a greenhorn in this bug reporting stuff, also in the compile your 
own stuff).

greets
mclien

On 1/11/23 19:40, Mark Tiefenbruck wrote:
> Hi mclien,
> 
> If the issue is already fixed in the fluxbox source, then there's really 
> nothing I can do for you, aside from pushing for a new official release 
> (which we should be doing anyway). We can't tell the Devuan maintainers 
> what packages to build. If you're waiting for the fix to get to debian 
> stable, it will take years.
> 
> If you want the issue fixed on your machine now, then all I can suggest 
> is building fluxbox from the git source. This has the additional benefit 
> that it will test whether the issue is actually fixed or whether we need 
> to investigate further.
> 
>    Cheers,
>       Mark
> 
> 
> On Wed, Jan 11, 2023 at 10:25 AM Frank Lienhard <fr...@mc... 
> <mailto:fr...@mc...>> wrote:
> 
>     Hi Marc,
> 
>     I'm not sure if that is necessary, since bug #1182 describes the exact
>     same problem and the bug report creator states the 1.4.0 from git fixes
>     the problem.
>     https://sourceforge.net/p/fluxbox/bugs/1182/
>     <https://sourceforge.net/p/fluxbox/bugs/1182/>
> 
>     If you think it's necessary that I verify that, I guess I need to test
>     that on an extra machine, since this is my productive PC.
> 
>     Devuan/debian stable has v 1.3.5 (as has the next release).
>     I tested both (amd64 and i386) live Systems of Devuan. i386 works,
>     amd64
>     doesn't (I don't know if that is any help, though).
> 
>     greets
>     mclien
> 

Re: [Fluxbox-devel] Firefox and Thunderbird lose window border and controls (maybe bug #1182)

[Mark T. <ma...@fl...>]

Hi mclien,

If the issue is already fixed in the fluxbox source, then there's really
nothing I can do for you, aside from pushing for a new official release
(which we should be doing anyway). We can't tell the Devuan maintainers
what packages to build. If you're waiting for the fix to get to debian
stable, it will take years.

If you want the issue fixed on your machine now, then all I can suggest is
building fluxbox from the git source. This has the additional benefit that
it will test whether the issue is actually fixed or whether we need to
investigate further.

  Cheers,
     Mark


On Wed, Jan 11, 2023 at 10:25 AM Frank Lienhard <fr...@mc...> wrote:

> Hi Marc,
>
> I'm not sure if that is necessary, since bug #1182 describes the exact
> same problem and the bug report creator states the 1.4.0 from git fixes
> the problem.
> https://sourceforge.net/p/fluxbox/bugs/1182/
>
> If you think it's necessary that I verify that, I guess I need to test
> that on an extra machine, since this is my productive PC.
>
> Devuan/debian stable has v 1.3.5 (as has the next release).
> I tested both (amd64 and i386) live Systems of Devuan. i386 works, amd64
> doesn't (I don't know if that is any help, though).
>
> greets
> mclien
>
> On 1/11/23 18:48, Mark Tiefenbruck wrote:
> > Hi mclien,
> >
> > The latest version of fluxbox is 1.3.7, so I don't know what version
> > 1.4.0 means. Maybe it means that the problem has been fixed in the git
> > repository, but it's not part of an official release yet. Could you try
> > installing fluxbox from the git source to see if it works?
> >
> >    Thanks,
> >       Mark
> >
> >
> > On Wed, Jan 11, 2023 at 12:30 AM Frank Lienhard <fr...@mc...
> > <mailto:fr...@mc...>> wrote:
> >
> >     Hello list,
> >
> >     I hope this is the right place, didn't found much in the bugs list.
> >
> >     problem is as follows: whenever using xrandr (or any tool using it,
> >     arandr, lxrandr) Firefox and Thunderbird are losing all window
> borders
> >     and controls. So you can't move, resize focus those wondows.
> >
> >     This happens with fluxbox only, as the guys in the Devuan forum have
> >     confirmed.
> >
> >     #1182 mentions that it is fixed in fluxbox 1.4.0.
> >     But this version will not make it into bookworm/daedalus
> (Debian/Devuan)
> >
> >     I'm running:
> >     Devuan chimaera (up to date)
> >     problem occurres only on amd64, i386 works fine (tested on an old
> >     thinkpad)
> >
> >     let me know, if I missed information, I schould provide.
> >
> >     greets, mclien
> >
> >
> >     _______________________________________________
> >     Fluxbox-devel mailing list
> >     Flu...@li...
> >     <mailto:Flu...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/fluxbox-devel
> >     <https://lists.sourceforge.net/lists/listinfo/fluxbox-devel>
> >
>

Re: [Fluxbox-devel] Firefox and Thunderbird lose window border and controls (maybe bug #1182)

[Frank L. <fr...@mc...>]

Hi Marc,

I'm not sure if that is necessary, since bug #1182 describes the exact 
same problem and the bug report creator states the 1.4.0 from git fixes 
the problem.
https://sourceforge.net/p/fluxbox/bugs/1182/

If you think it's necessary that I verify that, I guess I need to test 
that on an extra machine, since this is my productive PC.

Devuan/debian stable has v 1.3.5 (as has the next release).
I tested both (amd64 and i386) live Systems of Devuan. i386 works, amd64 
doesn't (I don't know if that is any help, though).

greets
mclien

On 1/11/23 18:48, Mark Tiefenbruck wrote:
> Hi mclien,
> 
> The latest version of fluxbox is 1.3.7, so I don't know what version 
> 1.4.0 means. Maybe it means that the problem has been fixed in the git 
> repository, but it's not part of an official release yet. Could you try 
> installing fluxbox from the git source to see if it works?
> 
>    Thanks,
>       Mark
> 
> 
> On Wed, Jan 11, 2023 at 12:30 AM Frank Lienhard <fr...@mc... 
> <mailto:fr...@mc...>> wrote:
> 
>     Hello list,
> 
>     I hope this is the right place, didn't found much in the bugs list.
> 
>     problem is as follows: whenever using xrandr (or any tool using it,
>     arandr, lxrandr) Firefox and Thunderbird are losing all window borders
>     and controls. So you can't move, resize focus those wondows.
> 
>     This happens with fluxbox only, as the guys in the Devuan forum have
>     confirmed.
> 
>     #1182 mentions that it is fixed in fluxbox 1.4.0.
>     But this version will not make it into bookworm/daedalus (Debian/Devuan)
> 
>     I'm running:
>     Devuan chimaera (up to date)
>     problem occurres only on amd64, i386 works fine (tested on an old
>     thinkpad)
> 
>     let me know, if I missed information, I schould provide.
> 
>     greets, mclien
> 
> 
>     _______________________________________________
>     Fluxbox-devel mailing list
>     Flu...@li...
>     <mailto:Flu...@li...>
>     https://lists.sourceforge.net/lists/listinfo/fluxbox-devel
>     <https://lists.sourceforge.net/lists/listinfo/fluxbox-devel>
> 

Re: [Fluxbox-devel] Firefox and Thunderbird lose window border and controls (maybe bug #1182)

[Mark T. <ma...@fl...>]

Hi mclien,

The latest version of fluxbox is 1.3.7, so I don't know what version 1.4.0
means. Maybe it means that the problem has been fixed in the git
repository, but it's not part of an official release yet. Could you try
installing fluxbox from the git source to see if it works?

  Thanks,
     Mark


On Wed, Jan 11, 2023 at 12:30 AM Frank Lienhard <fr...@mc...> wrote:

> Hello list,
>
> I hope this is the right place, didn't found much in the bugs list.
>
> problem is as follows: whenever using xrandr (or any tool using it,
> arandr, lxrandr) Firefox and Thunderbird are losing all window borders
> and controls. So you can't move, resize focus those wondows.
>
> This happens with fluxbox only, as the guys in the Devuan forum have
> confirmed.
>
> #1182 mentions that it is fixed in fluxbox 1.4.0.
> But this version will not make it into bookworm/daedalus (Debian/Devuan)
>
> I'm running:
> Devuan chimaera (up to date)
> problem occurres only on amd64, i386 works fine (tested on an old thinkpad)
>
> let me know, if I missed information, I schould provide.
>
> greets, mclien
>
>
> _______________________________________________
> Fluxbox-devel mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-devel
>

[Fluxbox-devel] Firefox and Thunderbird lose window border and controls (maybe bug #1182)

[Frank L. <fr...@mc...>]

Hello list,

I hope this is the right place, didn't found much in the bugs list.

problem is as follows: whenever using xrandr (or any tool using it, 
arandr, lxrandr) Firefox and Thunderbird are losing all window borders 
and controls. So you can't move, resize focus those wondows.

This happens with fluxbox only, as the guys in the Devuan forum have 
confirmed.

#1182 mentions that it is fixed in fluxbox 1.4.0.
But this version will not make it into bookworm/daedalus (Debian/Devuan)

I'm running:
Devuan chimaera (up to date)
problem occurres only on amd64, i386 works fine (tested on an old thinkpad)

let me know, if I missed information, I schould provide.

greets, mclien

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

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

On 10/24/22 10:49, Javier via Fluxbox-devel wrote:
> On 10/24/22 10:39, Mark Tiefenbruck wrote:
>> I'll look at the code eventually, but it might help if you ran `xprop' and clicked on that "desktop background" window for me.
> 
> Attached goes the 11th xprop output, corresponding to the lxqt background/wallpaper.  I was suspecting it was managed by pcmanfm-qt, and it actually is...
> 
> Thanks !

BTW, that xprop last output corresponds to a version of fluxbox prior to the one with the weird behavior, if you need one with it, let me know.  Thanks !

-- 
Javier

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

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

On 10/24/22 10:39, Mark Tiefenbruck wrote:
> I'll look at the code eventually, but it might help if you ran `xprop' and clicked on that "desktop background" window for me.

Attached goes the 11th xprop output, corresponding to the lxqt background/wallpaper.  I was suspecting it was managed by pcmanfm-qt, and it actually is...

Thanks !

-- 
Javier

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

[Mark T. <ma...@fl...>]

Hi Javier,

Here's what that code does. Suppose some application opens a window that is
as big as the screen (or bigger), but it's not a fullscreen window (which
would go on top of everything, like a video). Then we'll just maximize the
window and set some default size (2/3 of the screen width/height) for it to
return to if the user unmaximizes it.

Based on that, it looks like LXQt is "setting the wallpaper" by opening a
window that's the same size as the screen. Then fluxbox sees it and says,
"well, let's just call it maximized". However, presumably LXQt objects to
that window being maximized and says, "hey fluxbox, don't maximize that
window" (or maybe it already told us that). Then, fluxbox helpfully
unmaximizes the window and shrinks it to 2/3 the screen size.

It certainly wouldn't hurt anything if you removed that code from your own
copy of fluxbox, and then you could move along happily. Probably the right
thing to do here is to add some more conditions. We don't want this code to
apply to "desktop background" windows. Presumably LXQt has given fluxbox
enough information to deduce that, like telling us not to give it any
window decorations and to keep it below all the other windows. It might
even say, "this window can't be maximized", but I don't remember if that's
something a program can tell fluxbox. I'm not looking at the code right
now, but all this stuff must be available in that init() function.

I'll look at the code eventually, but it might help if you ran `xprop' and
clicked on that "desktop background" window for me.

  Cheers,
     Mark


On Sat, Oct 22, 2022 at 4:55 PM Javier via Fluxbox-devel <
flu...@li...> wrote:

> Found the culprit:
>
> > % git bisect good
> > 299e098f5f6fc6d33684b3d4e80185c8a7899664 is the first bad commit
> > commit 299e098f5f6fc6d33684b3d4e80185c8a7899664
> > Author: Thomas Lübking <tho...@gm...>
> > Date:   Mon Aug 1 10:26:48 2016 +0200
> >
> >     handle oversized windows
> >
> >     Clients can still be stupid (feh constrains itself to the root window
> >     ...) or lazy (llpp uses the last size - if that was in pivot mode
> ...)
> >     and create windows which exceed the workspace dimensions, resulting
> in
> >     both opposing edges being off-screen (for all tested placements)
> >
> >     This applies partial maximization instead and resizes the (restored)
> >     window to soem sane size (size constraints applied)
> >
> >     CCBUG: 688
> >     CCBUG: 984
> >
> >  src/Window.cc | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
>
> And the commit itself:
>
> > commit 299e098f5f6fc6d33684b3d4e80185c8a7899664
> > Author: Thomas Lübking <tho...@gm...>
> > Date:   Mon Aug 1 10:26:48 2016 +0200
> >
> >     handle oversized windows
> >
> >     Clients can still be stupid (feh constrains itself to the root window
> >     ...) or lazy (llpp uses the last size - if that was in pivot mode
> ...)
> >     and create windows which exceed the workspace dimensions, resulting
> in
> >     both opposing edges being off-screen (for all tested placements)
> >
> >     This applies partial maximization instead and resizes the (restored)
> >     window to soem sane size (size constraints applied)
> >
> >     CCBUG: 688
> >     CCBUG: 984
> >
> > diff --git a/src/Window.cc b/src/Window.cc
> > index 3ad5088f..f1bf1e9a 100644
> > --- a/src/Window.cc
> > +++ b/src/Window.cc
> > @@ -506,6 +506,25 @@ void FluxboxWindow::init() {
> >
> >      fluxbox.attachSignals(*this);
> >
> > +    if (!m_state.fullscreen) {
> > +        unsigned int new_width = 0, new_height = 0;
> > +        if (m_client->width() >= screen().width()) {
> > +            m_state.maximized |= WindowState::MAX_HORZ;
> > +            new_width = 2 * screen().width() / 3;
> > +        }
> > +        if (m_client->height() >= screen().height()) {
> > +            m_state.maximized |= WindowState::MAX_VERT;
> > +            new_height = 2 * screen().height() / 3;
> > +        }
> > +        if (new_width || new_height) {
> > +            const int maximized = m_state.maximized;
> > +            m_state.maximized = WindowState::MAX_NONE;
> > +            resize(new_width ? new_width : width(), new_height ?
> new_height : height());
> > +            m_placed = false;
> > +            m_state.maximized = maximized;
> > +        }
> > +    }
> > +
> >      // this window is managed, we are now allowed to modify actual state
> >      m_initialized = true;
>
> "partial maximization"indicates the commit message?  Or "2/3" in the
> code?  I don't quite follow the change, but that's the one breaking
> functionality.  Please notice in my case the wallpaper is set by LXQt, and
> fluxbox doesn't even set the wallpaper, so not sure why it's doing the
> weird resize of the screen.  But the resizing explains the weird behavior.
> See, what I noticed is like if the desktop was shrinked, hehe...
>
> What next, can there be a commmit reverting that, or an attempt to fix it?
>
> Thanks a lot @mark !
>
> --
> Javier
> _______________________________________________
> Fluxbox-devel mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-devel
>

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

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

Found the culprit:

> % git bisect good
> 299e098f5f6fc6d33684b3d4e80185c8a7899664 is the first bad commit
> commit 299e098f5f6fc6d33684b3d4e80185c8a7899664
> Author: Thomas Lübking <tho...@gm...>
> Date:   Mon Aug 1 10:26:48 2016 +0200
> 
>     handle oversized windows
>     
>     Clients can still be stupid (feh constrains itself to the root window
>     ...) or lazy (llpp uses the last size - if that was in pivot mode ...)
>     and create windows which exceed the workspace dimensions, resulting in
>     both opposing edges being off-screen (for all tested placements)
>     
>     This applies partial maximization instead and resizes the (restored)
>     window to soem sane size (size constraints applied)
>     
>     CCBUG: 688
>     CCBUG: 984
> 
>  src/Window.cc | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)

And the commit itself:

> commit 299e098f5f6fc6d33684b3d4e80185c8a7899664
> Author: Thomas Lübking <tho...@gm...>
> Date:   Mon Aug 1 10:26:48 2016 +0200
> 
>     handle oversized windows
>     
>     Clients can still be stupid (feh constrains itself to the root window
>     ...) or lazy (llpp uses the last size - if that was in pivot mode ...)
>     and create windows which exceed the workspace dimensions, resulting in
>     both opposing edges being off-screen (for all tested placements)
>     
>     This applies partial maximization instead and resizes the (restored)
>     window to soem sane size (size constraints applied)
>     
>     CCBUG: 688
>     CCBUG: 984
> 
> diff --git a/src/Window.cc b/src/Window.cc
> index 3ad5088f..f1bf1e9a 100644
> --- a/src/Window.cc
> +++ b/src/Window.cc
> @@ -506,6 +506,25 @@ void FluxboxWindow::init() {
>  
>      fluxbox.attachSignals(*this);
>  
> +    if (!m_state.fullscreen) {
> +        unsigned int new_width = 0, new_height = 0;
> +        if (m_client->width() >= screen().width()) {
> +            m_state.maximized |= WindowState::MAX_HORZ;
> +            new_width = 2 * screen().width() / 3;
> +        }
> +        if (m_client->height() >= screen().height()) {
> +            m_state.maximized |= WindowState::MAX_VERT;
> +            new_height = 2 * screen().height() / 3;
> +        }
> +        if (new_width || new_height) {
> +            const int maximized = m_state.maximized;
> +            m_state.maximized = WindowState::MAX_NONE;
> +            resize(new_width ? new_width : width(), new_height ? new_height : height());
> +            m_placed = false;
> +            m_state.maximized = maximized;
> +        }
> +    }
> +
>      // this window is managed, we are now allowed to modify actual state
>      m_initialized = true;

"partial maximization"indicates the commit message?  Or "2/3" in the code?  I don't quite follow the change, but that's the one breaking functionality.  Please notice in my case the wallpaper is set by LXQt, and fluxbox doesn't even set the wallpaper, so not sure why it's doing the weird resize of the screen.  But the resizing explains the weird behavior.  See, what I noticed is like if the desktop was shrinked, hehe...

What next, can there be a commmit reverting that, or an attempt to fix it?

Thanks a lot @mark !

-- 
Javier

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

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

On 10/21/22 13:00, Mark Tiefenbruck wrote:
> In that case, "git bisect" can help you figure out which commit changed the behavior. You just need to find a version far enough in the past where it worked. After that, it will probably take an hour of your time, just compiling different versions and checking whether they work or not, but it's much more likely to end in success than what we're doing now.

In theory this one:  `88a74ff1cde22be3e894498ffd88934dc92dfef0`, since that is working fine when building without toolbar, slit, neither systray.  I'll try to find out, there are so many commits after that one, :(

-- 
Javier

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

[Mark T. <ma...@fl...>]

In that case, "git bisect" can help you figure out which commit changed the
behavior. You just need to find a version far enough in the past where it
worked. After that, it will probably take an hour of your time, just
compiling different versions and checking whether they work or not, but
it's much more likely to end in success than what we're doing now.

  Cheers,
     Mark



On Thu, Oct 20, 2022 at 11:19 PM Javier via Fluxbox-devel <
flu...@li...> wrote:

> On 10/20/22 23:37, Javier via Fluxbox-devel wrote:
> > On 10/20/22 15:30, Mark Tiefenbruck wrote:
> >> I meant the panel at the bottom-left of your screenshots. Run `xprop'
> and click on it. If fluxbox is reserving space at the bottom of the screen
> for it, then it should have a _NET_WM_STRUT property on it. (The
> _NET_WM_STRUT in the _NET_SUPPORTED list is just how fluxbox tells other
> programs that it can do that. It's not important for us.)
> >>
> >> You should be able to run fluxbox without lxqt. It would be nice to see
> the output of `xprop -root' in that case.
> >
> > OK, attached the xprops 05, for what's below the lxqt panel, and 06 for
> the lxqt panel itself.  Below the lxqt panel, there's no _NET_SUPPORTED
> set, but for the lxqt panel:
> >
> >> _NET_WM_STRUT(CARDINAL) = 0, 0, 0, 34
> >
> > Now, that's before restarting fluxbox, and it's like the desktop area
> was shrinked, since everything is smaller...  After restarting fluxbox, the
> xprop 07 attached corresponds to the lxqt panel as well, and I see no
> difference with respect to the one prior to fluxbox restart.  Still, the
> non lxqt panel area wallpapaer remains like shrinked, above the lxqt panel.
>
> OK, when running fluxbox stand alone, with fluxbox toolbar, the "xprop
> -root" output is attached as output 08.  And if interested on the fluxbox
> toolbar xprop output, 09 is also attached, for which there's no
> _NET_WM_STRUT set at all, just:
>
> > _NET_WM_WINDOW_OPACITY(CARDINAL) = 3452816845
> > WM_WINDOW_ROLE(STRING) = "fluxbox-toolbar"
>
> I think with these, I don't owe any requested output, :).  If there's
> additional logs or command outputs, please let me know.  As you mentioned
> at some point I hadn't shared my fluxbox init, here it goes:
>
> > % cat .fluxbox/init
> > session.screen0.slit.placement: RightBottom
> > session.screen0.slit.direction: Vertical
> > session.screen0.tabs.usePixmap: false
> > session.screen0.iconbar.mode:   {static groups} (workspace)
> > session.screen0.toolbar.visible:        false
> > session.screen0.toolbar.widthPercent:   100
> > session.screen0.toolbar.tools:  workspacename, prevworkspace,
> nextworkspace, iconbar, prevwindow, nextwindow, clock
> > session.screen0.strftimeFormat: %a  %d/%m/%Y  %I:%M %p
> > session.screen0.workspaces:     4
> > session.screen0.workspaceNames: 01,02,03,04,05,06,07,08,09,10,
> > session.configVersion:  13
> > session.keyFile:        ~/.fluxbox/keys
> > session.styleFile:      /usr/share/fluxbox/styles/bora_black
> > session.styleOverlay:   ~/.fluxbox/overlay
> > session.menuFile:       ~/.fluxbox/menu
> > session.appsFile: ~/.fluxbox/apps
>
> I've removed the slit options, and also set toolbar.widthPercent to 0, and
> I've experimented several crazy things, but nothing had helped...
>
> BTW, in the past this was working, just by calling fluxbox -no-toolbar
> -no-slit (not sure which fluxbox commit started this weird misbehavior).
> Of course it's been a while that stopped working...
>
> --
> Javier
> _______________________________________________
> Fluxbox-devel mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-devel
>

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

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

On 10/20/22 23:37, Javier via Fluxbox-devel wrote:
> On 10/20/22 15:30, Mark Tiefenbruck wrote:
>> I meant the panel at the bottom-left of your screenshots. Run `xprop' and click on it. If fluxbox is reserving space at the bottom of the screen for it, then it should have a _NET_WM_STRUT property on it. (The _NET_WM_STRUT in the _NET_SUPPORTED list is just how fluxbox tells other programs that it can do that. It's not important for us.)
>>
>> You should be able to run fluxbox without lxqt. It would be nice to see the output of `xprop -root' in that case.
> 
> OK, attached the xprops 05, for what's below the lxqt panel, and 06 for the lxqt panel itself.  Below the lxqt panel, there's no _NET_SUPPORTED set, but for the lxqt panel:
> 
>> _NET_WM_STRUT(CARDINAL) = 0, 0, 0, 34
> 
> Now, that's before restarting fluxbox, and it's like the desktop area was shrinked, since everything is smaller...  After restarting fluxbox, the xprop 07 attached corresponds to the lxqt panel as well, and I see no difference with respect to the one prior to fluxbox restart.  Still, the non lxqt panel area wallpapaer remains like shrinked, above the lxqt panel.

OK, when running fluxbox stand alone, with fluxbox toolbar, the "xprop -root" output is attached as output 08.  And if interested on the fluxbox toolbar xprop output, 09 is also attached, for which there's no _NET_WM_STRUT set at all, just:

> _NET_WM_WINDOW_OPACITY(CARDINAL) = 3452816845
> WM_WINDOW_ROLE(STRING) = "fluxbox-toolbar"

I think with these, I don't owe any requested output, :).  If there's additional logs or command outputs, please let me know.  As you mentioned at some point I hadn't shared my fluxbox init, here it goes:

> % cat .fluxbox/init
> session.screen0.slit.placement: RightBottom
> session.screen0.slit.direction: Vertical
> session.screen0.tabs.usePixmap: false
> session.screen0.iconbar.mode:   {static groups} (workspace)
> session.screen0.toolbar.visible:        false
> session.screen0.toolbar.widthPercent:   100
> session.screen0.toolbar.tools:  workspacename, prevworkspace, nextworkspace, iconbar, prevwindow, nextwindow, clock
> session.screen0.strftimeFormat: %a  %d/%m/%Y  %I:%M %p
> session.screen0.workspaces:     4
> session.screen0.workspaceNames: 01,02,03,04,05,06,07,08,09,10,
> session.configVersion:  13
> session.keyFile:        ~/.fluxbox/keys
> session.styleFile:      /usr/share/fluxbox/styles/bora_black
> session.styleOverlay:   ~/.fluxbox/overlay
> session.menuFile:       ~/.fluxbox/menu
> session.appsFile: ~/.fluxbox/apps

I've removed the slit options, and also set toolbar.widthPercent to 0, and I've experimented several crazy things, but nothing had helped...

BTW, in the past this was working, just by calling fluxbox -no-toolbar -no-slit (not sure which fluxbox commit started this weird misbehavior).  Of course it's been a while that stopped working...

-- 
Javier

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

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

On 10/20/22 15:30, Mark Tiefenbruck wrote:
> I meant the panel at the bottom-left of your screenshots. Run `xprop' and click on it. If fluxbox is reserving space at the bottom of the screen for it, then it should have a _NET_WM_STRUT property on it. (The _NET_WM_STRUT in the _NET_SUPPORTED list is just how fluxbox tells other programs that it can do that. It's not important for us.)
> 
> You should be able to run fluxbox without lxqt. It would be nice to see the output of `xprop -root' in that case.

OK, attached the xprops 05, for what's below the lxqt panel, and 06 for the lxqt panel itself.  Below the lxqt panel, there's no _NET_SUPPORTED set, but for the lxqt panel:

> _NET_WM_STRUT(CARDINAL) = 0, 0, 0, 34

Now, that's before restarting fluxbox, and it's like the desktop area was shrinked, since everything is smaller...  After restarting fluxbox, the xprop 07 attached corresponds to the lxqt panel as well, and I see no difference with respect to the one prior to fluxbox restart.  Still, the non lxqt panel area wallpapaer remains like shrinked, above the lxqt panel.

That said, I'll be getting the plain fluxbox (no lxqt) "xprop --root" in a few minutes...

-- 
Javier

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

[Mark T. <ma...@fl...>]

I meant the panel at the bottom-left of your screenshots. Run `xprop' and
click on it. If fluxbox is reserving space at the bottom of the screen for
it, then it should have a _NET_WM_STRUT property on it. (The _NET_WM_STRUT
in the _NET_SUPPORTED list is just how fluxbox tells other programs that it
can do that. It's not important for us.)

You should be able to run fluxbox without lxqt. It would be nice to see the
output of `xprop -root' in that case.

  Cheers,
     Mark


On Thu, Oct 20, 2022 at 10:18 AM Javier via Fluxbox-devel <
flu...@li...> wrote:

> On 10/19/22 21:46, Mark Tiefenbruck wrote:
> >>> If we're waiting a few days, then I'll tell you a few more things to
> report. Try running fluxbox without the dock, and see what the output of
> `xprop -root' is before and after starting the dock. Also, run just `xprop'
> and click on the dock. I particularly want to see its _NET_WM_STRUT
> property.
> >>
> >> I already commented on the _NET_WM_STRUT values, which I can't really
> tell on the prior outputs.  Now, what do you mean by the dock?  Are you
> talking about the lxqt panel (sort of the equivalent to the fluxbox
> toolbar)?  If that is the case, unfortunately I really don't know how to
> make lxqt not to load its panel, and then if I were to succeed on that, how
> to make it show up later on.  It's part of the lxqt DE...
> >
> >
> > BTW, in case useful, I got the xprop output for the older fluxbox, built
> without slit, toolbar and systray.  It's attached now, the output 03.  I
> don't have the right eyes to identify meaningful differences between the
> outputs.  But I hope the case without the weird behavior helps...
>
> Ohh, in case what you meant by dock, is before lxqt starts, then attached
> is the xprop output, 04.  There are several things not defined before the
> lxqt starts, :)  Still, same thing about _NET_WM_STRUT...
>
> --
> Javier
> _______________________________________________
> Fluxbox-devel mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-devel
>

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

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

On 10/19/22 21:46, Mark Tiefenbruck wrote:
>>> If we're waiting a few days, then I'll tell you a few more things to report. Try running fluxbox without the dock, and see what the output of `xprop -root' is before and after starting the dock. Also, run just `xprop' and click on the dock. I particularly want to see its _NET_WM_STRUT property.
>>
>> I already commented on the _NET_WM_STRUT values, which I can't really tell on the prior outputs.  Now, what do you mean by the dock?  Are you talking about the lxqt panel (sort of the equivalent to the fluxbox toolbar)?  If that is the case, unfortunately I really don't know how to make lxqt not to load its panel, and then if I were to succeed on that, how to make it show up later on.  It's part of the lxqt DE...
> 
> 
> BTW, in case useful, I got the xprop output for the older fluxbox, built without slit, toolbar and systray.  It's attached now, the output 03.  I don't have the right eyes to identify meaningful differences between the outputs.  But I hope the case without the weird behavior helps...

Ohh, in case what you meant by dock, is before lxqt starts, then attached is the xprop output, 04.  There are several things not defined before the lxqt starts, :)  Still, same thing about _NET_WM_STRUT...

-- 
Javier

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

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

On 10/19/22 22:56, Javier via Fluxbox-devel wrote:
> On 10/19/22 21:10, Mark Tiefenbruck wrote:
>>> Anyway, your screenshots are interesting. I guess the first step is to look at the output of `xprop -root' both before and after the restart. The _NET_WORKAREA and _NET_DESKTOP_GEOMETRY fields might tell us something.
> 
> Well, I just tried these 2 things...  Attached the outputs requested, 01 corresponds to the output after just loading lxqt, but prior to restarting fluxbox, and 02 corresponds to the output after restarting fluxbox.  _NET_WORKAREA is the same for both:
> 
>> _NET_WORKAREA(CARDINAL) = 0, 0, 1920, 1046, 0, 0, 1920, 1046, 0, 0, 1920, 1046, 0, 0, 1920, 1046
> 
> And _NET_DESKTOP_GEOMETRY as well:
> 
>> _NET_DESKTOP_GEOMETRY(CARDINAL) = 1920, 1080
> 
> Now, on these trials although _NET_WM_STRUT is part of the definition of _NET_SUPPORTED, I don't really see how it's assigned:
> 
>> _NET_SUPPORTED(ATOM) = _NET_WM_STRUT, ...
> 
> On 10/19/22 21:46, Mark Tiefenbruck wrote:
>> If we're waiting a few days, then I'll tell you a few more things to report. Try running fluxbox without the dock, and see what the output of `xprop -root' is before and after starting the dock. Also, run just `xprop' and click on the dock. I particularly want to see its _NET_WM_STRUT property.
> 
> I already commented on the _NET_WM_STRUT values, which I can't really tell on the prior outputs.  Now, what do you mean by the dock?  Are you talking about the lxqt panel (sort of the equivalent to the fluxbox toolbar)?  If that is the case, unfortunately I really don't know how to make lxqt not to load its panel, and then if I were to succeed on that, how to make it show up later on.  It's part of the lxqt DE...


BTW, in case useful, I got the xprop output for the older fluxbox, built without slit, toolbar and systray.  It's attached now, the output 03.  I don't have the right to identify meaningful differences between the outputs.  But I hope the case without the weird behavior helps...

-- 
Javier

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

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

On 10/19/22 21:10, Mark Tiefenbruck wrote:
>> Anyway, your screenshots are interesting. I guess the first step is to look at the output of `xprop -root' both before and after the restart. The _NET_WORKAREA and _NET_DESKTOP_GEOMETRY fields might tell us something.

Well, I just tried these 2 things...  Attached the outputs requested, 01 corresponds to the output after just loading lxqt, but prior to restarting fluxbox, and 02 corresponds to the output after restarting fluxbox.  _NET_WORKAREA is the same for both:

> _NET_WORKAREA(CARDINAL) = 0, 0, 1920, 1046, 0, 0, 1920, 1046, 0, 0, 1920, 1046, 0, 0, 1920, 1046

And _NET_DESKTOP_GEOMETRY as well:

> _NET_DESKTOP_GEOMETRY(CARDINAL) = 1920, 1080

Now, on these trials although _NET_WM_STRUT is part of the definition of _NET_SUPPORTED, I don't really see how it's assigned:

> _NET_SUPPORTED(ATOM) = _NET_WM_STRUT, ...

On 10/19/22 21:46, Mark Tiefenbruck wrote:
> If we're waiting a few days, then I'll tell you a few more things to report. Try running fluxbox without the dock, and see what the output of `xprop -root' is before and after starting the dock. Also, run just `xprop' and click on the dock. I particularly want to see its _NET_WM_STRUT property.

I already commented on the _NET_WM_STRUT values, which I can't really tell on the prior outputs.  Now, what do you mean by the dock?  Are you talking about the lxqt panel (sort of the equivalent to the fluxbox toolbar)?  If that is the case, unfortunately I really don't know how to make lxqt not to load its panel, and then if I were to succeed on that, how to make it show up later on.  It's part of the lxqt DE...

-- 
Javier

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

[Mark T. <ma...@fl...>]

If we're waiting a few days, then I'll tell you a few more things to
report. Try running fluxbox without the dock, and see what the output of
`xprop -root' is before and after starting the dock. Also, run just `xprop'
and click on the dock. I particularly want to see its _NET_WM_STRUT
property.

  Cheers,
     Mark


On Wed, Oct 19, 2022 at 8:21 PM Javier via Fluxbox-devel <
flu...@li...> wrote:

> On 10/19/22 21:10, Mark Tiefenbruck wrote:
> > That's not exactly the right way to fix it, but if you're happy with
> that behavior, then it won't hurt. It looks like those couple lines are
> meant to decorate the title of the window when it's minimized, maybe
> putting square brackets around it or something. It depends on some
> resources in the init file that I don't have, so who knows.
>
> I see, then lets not apply the patch, :).  If you find out a better way,
> please let me know.  In the end, I just realized I don't need to disable
> stuff at build time with later fluxbox.  The reason I was not hitting the
> extra weird behavior with AUR fluxbox-wm was that it was old enough not to
> hit the issue...
>
> > Anyway, your screenshots are interesting. I guess the first step is to
> look at the output of `xprop -root' both before and after the restart. The
> _NET_WORKAREA and _NET_DESKTOP_GEOMETRY fields might tell us something.
>
> OK, I'll try later this week if possible.  This is super weird.  and if we
> ever get to work around those issues when not using fluxbox toolbar,
> perhaps we still hit the other one, about losing windows decorations, which
> I guessed might have been overcome with some later fixes, :)  We'll see.
>
> Thanks !
>
> --
> Javier
> _______________________________________________
> Fluxbox-devel mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-devel
>

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

[Mark T. <ma...@fl...>]

That's not exactly the right way to fix it, but if you're happy with that
behavior, then it won't hurt. It looks like those couple lines are meant to
decorate the title of the window when it's minimized, maybe putting square
brackets around it or something. It depends on some resources in the init
file that I don't have, so who knows.

It's peculiar that the code to do that appears in the window class instead
of the toolbar class. It's not like the titlebar is showing when the window
is minimized. I guess the reason might be for people like you who are using
some external toolbar, but your toolbar should be able to tell when the
window is minimized, so I don't see why that's our job.

Anyway, your screenshots are interesting. I guess the first step is to look
at the output of `xprop -root' both before and after the restart. The
_NET_WORKAREA and _NET_DESKTOP_GEOMETRY fields might tell us something.

  Cheers,
     Mark


On Wed, Oct 19, 2022 at 7:45 PM Javier via Fluxbox-devel <
flu...@li...> wrote:

> On 10/19/22 19:25, Javier via Fluxbox-devel wrote:
> >>   256 void IconButton::setupWindow() {
> >>   257     m_icon_window.clear();
> >>   258     FbTk::FbString title = m_win.title().logical();
> >>   259 #ifdef USE_TOOLBAR
> >>   260     if (m_win.fbwindow() && m_win.fbwindow()->isIconic())
> >>   261         title = IconbarTool::iconifiedPrefix() + title +
> IconbarTool::iconifiedSuffix();
> >>   262 #endif // USE_TOOLBAR
> >>   263     setText(title);
> >>   264     FbTk::TextButton::clear();
> >>   265 }
> >
> > fluxbox builds fine, is that the right thing to do?  It's weird, because
> the the window can still be iconified, just that on a different toolbar
> (like the lxqt one, or any other one), so it's not like if asking for being
> iconified were invalid just because of not using the fluxbox toolbar, but
> perhaps there's no way to find out if not using the fluxbox toolbar.
> >
> > Do you think that's the way to fix it, or at least a good workaround
> @mark?  I'm attaching the corresponding patch, in case it makes sense...
>
> I tested it, and it seems not to break anything...
>
> Now, I was hoping to upgrade fluxbox, with "--disable-slit
> --disable-toolbar --disable-systray" would lead to something more stable,
> but it leads to same issue I was facing with Arch stock fluxbox, trying to
> disable stuff at run time and not at build time, so it was of no help, :(
> At any rate, perhaps the patch makes sense...
>
> To explain better the behavior see:
>
> https://gist.github.com/je-vv/6ee2791e17e65886cb79be46ede98136
>
> The 1st image is what I get when lxqt loads.  Then the 2nd image is what I
> get when running the fluxbox "Restart" command.  So it seems the weird
> behavior happens whether disabling stuff at run time or at build time.
>
> Good thing, with the patch, which might not be the right solution, at
> least we get disabling stuff at build time working back again...
>
> So I can't really try newer fluxbox commits after all, since that weird
> behavior barks at me, :(
>
> --
> Javier
> _______________________________________________
> Fluxbox-devel mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-devel
>

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

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

On 10/19/22 21:10, Mark Tiefenbruck wrote:
> That's not exactly the right way to fix it, but if you're happy with that behavior, then it won't hurt. It looks like those couple lines are meant to decorate the title of the window when it's minimized, maybe putting square brackets around it or something. It depends on some resources in the init file that I don't have, so who knows.

I see, then lets not apply the patch, :).  If you find out a better way, please let me know.  In the end, I just realized I don't need to disable stuff at build time with later fluxbox.  The reason I was not hitting the extra weird behavior with AUR fluxbox-wm was that it was old enough not to hit the issue...

> Anyway, your screenshots are interesting. I guess the first step is to look at the output of `xprop -root' both before and after the restart. The _NET_WORKAREA and _NET_DESKTOP_GEOMETRY fields might tell us something.

OK, I'll try later this week if possible.  This is super weird.  and if we ever get to work around those issues when not using fluxbox toolbar, perhaps we still hit the other one, about losing windows decorations, which I guessed might have been overcome with some later fixes, :)  We'll see.

Thanks !

-- 
Javier

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

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

On 10/19/22 19:25, Javier via Fluxbox-devel wrote:
>>   256 void IconButton::setupWindow() {
>>   257     m_icon_window.clear();
>>   258     FbTk::FbString title = m_win.title().logical();
>>   259 #ifdef USE_TOOLBAR
>>   260     if (m_win.fbwindow() && m_win.fbwindow()->isIconic())
>>   261         title = IconbarTool::iconifiedPrefix() + title + IconbarTool::iconifiedSuffix();
>>   262 #endif // USE_TOOLBAR
>>   263     setText(title);
>>   264     FbTk::TextButton::clear();
>>   265 }
> 
> fluxbox builds fine, is that the right thing to do?  It's weird, because the the window can still be iconified, just that on a different toolbar (like the lxqt one, or any other one), so it's not like if asking for being iconified were invalid just because of not using the fluxbox toolbar, but perhaps there's no way to find out if not using the fluxbox toolbar.
> 
> Do you think that's the way to fix it, or at least a good workaround @mark?  I'm attaching the corresponding patch, in case it makes sense...

I tested it, and it seems not to break anything...

Now, I was hoping to upgrade fluxbox, with "--disable-slit --disable-toolbar --disable-systray" would lead to something more stable, but it leads to same issue I was facing with Arch stock fluxbox, trying to disable stuff at run time and not at build time, so it was of no help, :(  At any rate, perhaps the patch makes sense...

To explain better the behavior see:

https://gist.github.com/je-vv/6ee2791e17e65886cb79be46ede98136

The 1st image is what I get when lxqt loads.  Then the 2nd image is what I get when running the fluxbox "Restart" command.  So it seems the weird behavior happens whether disabling stuff at run time or at build time.

Good thing, with the patch, which might not be the right solution, at least we get disabling stuff at build time working back again...

So I can't really try newer fluxbox commits after all, since that weird behavior barks at me, :(

-- 
Javier

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

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

On 10/18/22 12:16, Mark Tiefenbruck wrote:

> We certainly haven't intended to lose support for those configuration options, but they probably haven't been tested well. Based on the linker errors, I'm guessing the issue is just with --disable-toolbar. It looks like some of the toolbar code is getting referenced from IconButton (which I think is used for both toolbar buttons and titlebar buttons, but I haven't really looked at the code in ten years), so it probably just needs some IFDEFs.

I believe the issue is that, on old SHA, 88a74ff1cde22be3e894498ffd88934dc92dfef0, this code snippet doesn't make a reference to anything from the toolbar:

>   246 void IconButton::setupWindow() {
>   247     m_icon_window.clear();
>   248     setText(m_win.title());
>   249     FbTk::TextButton::clear();
>   250 }

Whereas on head of master, that same snippet is:

>   256 void IconButton::setupWindow() {
>   257     m_icon_window.clear();
>   258     FbTk::FbString title = m_win.title().logical();
>   259     if (m_win.fbwindow() && m_win.fbwindow()->isIconic())
>   260         title = IconbarTool::iconifiedPrefix() + title + IconbarTool::iconifiedSuffix();
>   261     setText(title);
>   262     FbTk::TextButton::clear();
>   263 }

If you notice, there's a reference to IconbarTool.  If I change the new snippet into:

>   256 void IconButton::setupWindow() {
>   257     m_icon_window.clear();
>   258     FbTk::FbString title = m_win.title().logical();
>   259 #ifdef USE_TOOLBAR
>   260     if (m_win.fbwindow() && m_win.fbwindow()->isIconic())
>   261         title = IconbarTool::iconifiedPrefix() + title + IconbarTool::iconifiedSuffix();
>   262 #endif // USE_TOOLBAR
>   263     setText(title);
>   264     FbTk::TextButton::clear();
>   265 }

fluxbox builds fine, is that the right thing to do?  It's weird, because the the window can still be iconified, just that on a different toolbar (like the lxqt one, or any other one), so it's not like if asking for being iconified were invalid just because of not using the fluxbox toolbar, but perhaps there's no way to find out if not using the fluxbox toolbar.

Do you think that's the way to fix it, or at least a good workaround @mark?  I'm attaching the corresponding patch, in case it makes sense...

-- 
Javier

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

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

On 10/18/22 13:41, Javier wrote:
>> The issue with losing window decorations is certainly puzzling. Your X server should be storing those. I'm afraid I don't have any practical advice on that. What happens if you minimize the window and restore it, or change workspaces and back?
> 
> I can change workspaces with no issue.  As I lost the titlebars on applications without client side decorations (CSD), then I didn't try minimizing.  Perhaps some combinations with picom settings and lower end boxes...  I'll keep investigating.  Remember, this is the one issue I prefer to live with, than battling the runtime disabling of features, :)

BTW, yes, windows can be minimized and restored as well, besides being able to change workspaces...  So, as mentioned, fluxbox doesn't die, just losing the title bars and decorations...

-- 
Javier

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

[Mark T. <ma...@fl...>]

Hi Javier,

We certainly haven't intended to lose support for those configuration
options, but they probably haven't been tested well. Based on the linker
errors, I'm guessing the issue is just with --disable-toolbar. It looks
like some of the toolbar code is getting referenced from IconButton (which
I think is used for both toolbar buttons and titlebar buttons, but I
haven't really looked at the code in ten years), so it probably just needs
some IFDEFs.

Have you tried running fluxbox with a toolbar and
"session.screen0.toolbar.visible: False" in your init file? That's more
likely to have been tested than the -no-toolbar command line option.

Fluxbox itself doesn't set any wallpapers. If you have "background: none"
in your overlay file, then it shouldn't change when you restart fluxbox. In
any case, the wallpaper is handled by a shell script called fbsetbg. Most
problems with wallpapers can be solved by installing feh, but if that
doesn't work for you, you are welcome to inspect and do whatever you want
to that shell script.

The issue with losing window decorations is certainly puzzling. Your X
server should be storing those. I'm afraid I don't have any practical
advice on that. What happens if you minimize the window and restore it, or
change workspaces and back?

  Cheers,
     Mark


On Tue, Oct 18, 2022 at 10:33 AM Javier via Fluxbox-devel <
flu...@li...> wrote:

> Hello !
>
> 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**, and removing
> **lastwallpaper** doesn't help either.  What's worse, even after restarting
> fluxbox, it's like there were 2 wallpapers, one shrinked on top of the
> other non shrinked, and it really looks ugly.
>
> 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.  This happens more frequently on lower end boxes.
>
> 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.
>
> 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
> _______________________________________________
> Fluxbox-devel mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-devel
>

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

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

On 10/18/22 12:16, Mark Tiefenbruck wrote:
> We certainly haven't intended to lose support for those configuration options, but they probably haven't been tested well. Based on the linker errors, I'm guessing the issue is just with --disable-toolbar. It looks like some of the toolbar code is getting referenced from IconButton (which I think is used for both toolbar buttons and titlebar buttons, but I haven't really looked at the code in ten years), so it probably just needs some IFDEFs.

I hope this might be something not that hard, :).  I can point to a newer head of master and test.  With more time, I'd look deeper as well.  If I do so, I'll let you know...

> Have you tried running fluxbox with a toolbar and "session.screen0.toolbar.visible: False" in your init file? That's more likely to have been tested than the -no-toolbar command line option.

That's always been there, :), see:

> % grep 'toolbar\.visible' .fluxbox/init
> 10:session.screen0.toolbar.visible:     false

> Fluxbox itself doesn't set any wallpapers. If you have "background: none" in your overlay file, then it shouldn't change when you restart fluxbox. In any case, the wallpaper is handled by a shell script called fbsetbg. Most problems with wallpapers can be solved by installing feh, but if that doesn't work for you, you are welcome to inspect and do whatever you want to that shell script.

I suspect it's something else, because at the same time, it's like fluxbox doesn't recognize the whole screen, just what should be above its toolbar, and it shrinks the wallpaper on that smaller space.  I mean, it's kind of both, like the toolbar still being there, and also populating the wallpaper although instructed not to...

I prefer the build time disabling than the run time one.  It does work, :).  There's just that issue about losing windows decorations.  But I prefer to deal with that one, than trying to disable the toolbar (with its tray) and slit on runtime...

> The issue with losing window decorations is certainly puzzling. Your X server should be storing those. I'm afraid I don't have any practical advice on that. What happens if you minimize the window and restore it, or change workspaces and back?

I can change workspaces with no issue.  As I lost the titlebars on applications without client side decorations (CSD), then I didn't try minimizing.  Perhaps some combinations with picom settings and lower end boxes...  I'll keep investigating.  Remember, this is the one issue I prefer to live with, than battling the runtime disabling of features, :)

Thanks a lot !

-- 
Javier