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

Re: [Fluxbox-devel] Is Fluxbox officially dead?

[Mathias G. <ak...@fl...>]

Hi,

> BTW I wonder how is fluxbox-wiki github organisation [1] related to fluxbox
> organisation [2]? Is fluxbox-wiki unofficial? I would expect to be under
> fluxbox, which has the source code.

It is historic.

The github.com organisation "fluxbox-wiki" was created when the main
hosting of fluxbox.org itself, the wiki in its previous form etc was
done by supporters, loosely coupled, mainly organised via IRC.

Today, I would also see the wiki to be hosted either under

* github.com/fluxbox/wiki - just to separate it from the source code
of the window manager
* github.com/fluxbox.org as gh-wiki
* github.com/fluxbox - as gh-wiki

The reason for the historic approach was that we saw lots of hosters
come and go (I look at berlios.de, SF experienced some fundamental
changes as well in comparison to where it began).

Since https://github.com/fluxbox-wiki/fluxbox-wiki.github.io is a
git-repository, we can easily transfer it to a different organisation.
The critical point is not so much _where_ its hosted but who spends
time curating the content.

Cheers,
-- 
[uid] mathias gumz [www] http://www.fluxbox.org/
[pgp] 1024D/F6F6B18C [irc] ak|ra at libera.chat

Re: [Fluxbox-devel] Is Fluxbox officially dead?

[Mathias G. <ak...@fl...>]

Hi,

> The fluxbox.org website has been linking to some Indian site for many
> months now. You can't even find a link to the git repository anymore.
> Seems like no one is intended to start using Fluxbox or to contribute
> code.
>
> Is Fluxbox officially dead, meaning there is no maintainer who would
> take 5 minutes to even just remove the Indian links and insert a link
> to the code repository?

It is not your 5 minutes, is it?

Since you stepped up to provide some help to help at least with the website:

* Repo - https://github.com/fluxbox/fluxbox.org
* Rendered site: https://fluxbox.github.io/fluxbox.org/

The goal here is to have a static website, hosted directly on Github
and be done with that.
Once the content matches roughly what we have right now, looks halfway
decent, does not
contain to domains captured by some external pirates to host malware
etc: I want to set this
active.

Thanks for your support, looking forward to some PRs from you.

Best,
-- 
[uid] mathias gumz [www] http://www.fluxbox.org/
[pgp] 1024D/F6F6B18C [irc] ak|ra at libera.chat

Re: [Fluxbox-devel] Is Fluxbox officially dead?

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

You'll have to define "officially dead". Certainly, the people who have
previously contributed the most to Fluxbox don't have much time or
motivation to make big changes. I personally still use Fluxbox both at home
and at work, and if something was giving me trouble, I would fix it. If
somebody else came along who had more time and motivation to make
improvements, we would certainly welcome contributions.

I don't think the sourceforge bug tracker is still monitored, but as you
can see, the e-mail lists do work. The links on the website should
certainly be fixed, but I don't think I am able to do that.

If I had to give Fluxbox a status, I would say "it still works, and the
developers are generally satisfied with it".

  Cheers,
     Mark


On Sun, Nov 24, 2024 at 9:46 AM Petr Vorel <pet...@gm...> wrote:

> Hi all,
>
> > > Go to http://fluxbox.org/download/
>
> > > and try the links in the "GIT DEVELOPMENT VERSION" box.
> > Oh, I see, the actual dead site is fluxbox-wiki.org, not fluxbox.org
> (which should be updated accordingly anyway).
> > Thank you very much for clarification!
>
> > As far as I see, this domain pointed to the actual wiki, then to github
> pages, then something went wrong between 2023-02-02 and 2023-03-23.
> > I did a quick search and found this update:
> https://github.com/fluxbox-wiki/fluxbox-wiki.github.io/commit/62672f703c25967711a19c39253352c3fba7a591
> > I guess they forgot to update links on the main site. I pinged
> developers:
> https://github.com/fluxbox-wiki/fluxbox-wiki.github.io/issues/84
> > Judging from the activity around open issues, I guess maybe IRC or
> direct e-mail will be more effective…
>
> BTW I wonder how is fluxbox-wiki github organisation [1] related to fluxbox
> organisation [2]? Is fluxbox-wiki unofficial? I would expect to be under
> fluxbox, which has the source code.
>
> Kind regards,
> Petr
>
> [1] https://github.com/fluxbox-wiki
> [2] https://github.com/fluxbox
>
> > _______________________________________________
> > Fluxbox-devel mailing list
> > Flu...@li...
> > https://lists.sourceforge.net/lists/listinfo/fluxbox-devel
>
>
> _______________________________________________
> Fluxbox-devel mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-devel
>

Re: [Fluxbox-devel] Is Fluxbox officially dead?

[Petr V. <pet...@gm...>]

Hi all,

> > Go to http://fluxbox.org/download/

> > and try the links in the "GIT DEVELOPMENT VERSION" box.
> Oh, I see, the actual dead site is fluxbox-wiki.org, not fluxbox.org (which should be updated accordingly anyway).
> Thank you very much for clarification!

> As far as I see, this domain pointed to the actual wiki, then to github pages, then something went wrong between 2023-02-02 and 2023-03-23.
> I did a quick search and found this update: https://github.com/fluxbox-wiki/fluxbox-wiki.github.io/commit/62672f703c25967711a19c39253352c3fba7a591
> I guess they forgot to update links on the main site. I pinged developers: https://github.com/fluxbox-wiki/fluxbox-wiki.github.io/issues/84
> Judging from the activity around open issues, I guess maybe IRC or direct e-mail will be more effective…

BTW I wonder how is fluxbox-wiki github organisation [1] related to fluxbox
organisation [2]? Is fluxbox-wiki unofficial? I would expect to be under
fluxbox, which has the source code.

Kind regards,
Petr

[1] https://github.com/fluxbox-wiki
[2] https://github.com/fluxbox

> _______________________________________________
> Fluxbox-devel mailing list
> Flu...@li...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-devel

Re: [Fluxbox-devel] Is Fluxbox officially dead?

[Matthias B. <msb...@wi...>]

On Sun, 24 Nov 2024 18:31:32 +0300
Nable via Fluxbox-devel <flu...@li...> wrote:

> As far as I see, this domain pointed to the actual wiki, then to
> github pages, then something went wrong between 2023-02-02 and
> 2023-03-23. I did a quick search and found this update:
> https://github.com/fluxbox-wiki/fluxbox-wiki.github.io/commit/62672f703c25967711a19c39253352c3fba7a591
> I guess they forgot to update links on the main site. I pinged
> developers:
> https://github.com/fluxbox-wiki/fluxbox-wiki.github.io/issues/84
> Judging from the activity around open issues, I guess maybe IRC or
> direct e-mail will be more effective…

When I wanted to report the issue in the SF bug tracker I noticed that
someone had already done so long ago. That's why I'm wondering if there
even is a maintainer left. 

MSB

-- 
Less code => fewer bugs.

Re: [Fluxbox-devel] Is Fluxbox officially dead?

[Nable <nab...@go...>]

> Go to http://fluxbox.org/download/
>
> and try the links in the "GIT DEVELOPMENT VERSION" box.
Oh, I see, the actual dead site is fluxbox-wiki.org, not fluxbox.org (which should be updated accordingly anyway).
Thank you very much for clarification!

As far as I see, this domain pointed to the actual wiki, then to github pages, then something went wrong between 2023-02-02 and 2023-03-23.
I did a quick search and found this update: https://github.com/fluxbox-wiki/fluxbox-wiki.github.io/commit/62672f703c25967711a19c39253352c3fba7a591
I guess they forgot to update links on the main site. I pinged developers: https://github.com/fluxbox-wiki/fluxbox-wiki.github.io/issues/84
Judging from the activity around open issues, I guess maybe IRC or direct e-mail will be more effective…

Re: [Fluxbox-devel] Is Fluxbox officially dead?

[Matthias B. <msb...@wi...>]

On Sun, 24 Nov 2024 14:22:52 +0300
Nable via Fluxbox-devel <flu...@li...> wrote:

> Hi,
> > The fluxbox.org website has been linking to some Indian site for
> > many months now. You can't even find a link to the git repository
> > anymore. Seems like no one is intended to start using Fluxbox or to
> > contribute code.
> >
> > Is Fluxbox officially dead, meaning there is no maintainer who would
> > take 5 minutes to even just remove the Indian links and insert a
> > link to the code repository?
> I have just checked the site (both fluxbox.org and git.fluxbox.org)
> and it looks the same as I remember it.

Go to http://fluxbox.org/download/

and try the links in the "GIT DEVELOPMENT VERSION" box.

MSB

--
College is a place where a professor's lecture notes
go straight to the students' lecture notes,
without passing through the brains of either.
- Mark Twain

Re: [Fluxbox-devel] Is Fluxbox officially dead?

[Nable <nab...@go...>]

Hi,
> The fluxbox.org website has been linking to some Indian site for many
> months now. You can't even find a link to the git repository anymore.
> Seems like no one is intended to start using Fluxbox or to contribute
> code.
>
> Is Fluxbox officially dead, meaning there is no maintainer who would
> take 5 minutes to even just remove the Indian links and insert a link
> to the code repository?
I have just checked the site (both fluxbox.org and git.fluxbox.org) and it looks the same as I remember it.
Either it was fixed by maintainers today or there's something wrong on your side: the site lacks HTTPS support, so some providers and routers in the middle may insert unwanted content (they do it not just for fluxbox.org, actually for all sites).
I checked saved page versions on archive.org and still can't see anything suspicious. Can you check it from a different location, please?

[Fluxbox-devel] Is Fluxbox officially dead?

[Matthias B. <msb...@wi...>]

The fluxbox.org website has been linking to some Indian site for many
months now. You can't even find a link to the git repository anymore.
Seems like no one is intended to start using Fluxbox or to contribute
code.

Is Fluxbox officially dead, meaning there is no maintainer who would
take 5 minutes to even just remove the Indian links and insert a link
to the code repository?

MSB

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