print/scribus: properties dialog broken under CWM

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

print/scribus: properties dialog broken under CWM

Charles A Daniels
Hello list,

There seems to be an issue with the Scribus port when combined with CWM.

Namely, the "properties" window/dialog can only be opened once. After
being closed, it cannot be opened again. Restarting the application does
not fix the problem.

This issue is specific to CWM, I am not able to reproduce under FVWM.

I have reproduced this issue under OpenBSD current on AMD64, and on
OpenBSD 6.4 on macppc (iBook G4). In both cases, using Scribus 1.4.6
installed via pkg_add.

I found a previous issue that affected the way CWM and Qt interact, which was
posted[1] under the subject line "calmwm mouse stuck inside of window" over on
misc@. Okan and I synced up off list and determined it was due to CWM's
implementation of EWMH interacting improperly with Qt.

I am reporting this issue separately, as this particular failure seems specific
to Scribus, as I've not seen this behavior under any other program.

I believe this could reasonably be an issue with Scribus, Qt, and/or CWM.

I have a hunch that this may be related in some way to Scribus issue 9293[2],
as deleting the entire '<context name="PropertiesPalette">' section from
"~/.scribus/prefs140.xml" allows the properties window to be opened. But
closing and re-opening it will fail (presumably since this context has been
re-created).

It may be worth contacting upstream, but since this issue only happens under
CWM, it might be on us, so I wanted to do the due diligence of getting some
more opinions before going upstream with it.

Steps to reproduce:

1. Install Scribus from ports
2. Log in to X with CWM
3. Open Scribus, create a new document
4. Press "t" to create a new text box, place it on the canvas
5. Enter some text in the box.
6. Do any of the following:
        a. Right click on the text box and select "properties"
        b. Press F2
        c. Select Windows->Properties
7. Interact in some way with the properties dialog, maybe change the font, then
   close it.
8. Attempt to repeat step 6. The properties dialog will not appear.

I am happy to try out patches, gather further information, or otherwise assist
any debugging effort to the best of my abilities.

~ Charles

1 - https://marc.info/?l=openbsd-misc&m=154524602418343&w=2
2 - https://bugs.scribus.net/view.php?id=9293

Reply | Threaded
Open this post in threaded view
|

Re: print/scribus: properties dialog broken under CWM

Marcus MERIGHI
Hello,

I can confirm with "OpenBSD 6.5 (GENERIC.MP) #857: Thu Apr 11 08:02:35"
and updated packages.

[hidden email] (Charles), 2019.04.12 (Fri) 04:04 (CEST):
> There seems to be an issue with the Scribus port when combined with CWM.
>
> Namely, the "properties" window/dialog can only be opened once. After
> being closed, it cannot be opened again.

Same here.

> Restarting the application does not fix the problem.

It does for me! After restart of scribus the properties dialog is there
or can be opened, once. I just need to avoid closing it.

Marcus

> This issue is specific to CWM, I am not able to reproduce under FVWM.
>
> I have reproduced this issue under OpenBSD current on AMD64, and on
> OpenBSD 6.4 on macppc (iBook G4). In both cases, using Scribus 1.4.6
> installed via pkg_add.
>
> I found a previous issue that affected the way CWM and Qt interact, which was
> posted[1] under the subject line "calmwm mouse stuck inside of window" over on
> misc@. Okan and I synced up off list and determined it was due to CWM's
> implementation of EWMH interacting improperly with Qt.
>
> I am reporting this issue separately, as this particular failure seems specific
> to Scribus, as I've not seen this behavior under any other program.
>
> I believe this could reasonably be an issue with Scribus, Qt, and/or CWM.
>
> I have a hunch that this may be related in some way to Scribus issue 9293[2],
> as deleting the entire '<context name="PropertiesPalette">' section from
> "~/.scribus/prefs140.xml" allows the properties window to be opened. But
> closing and re-opening it will fail (presumably since this context has been
> re-created).
>
> It may be worth contacting upstream, but since this issue only happens under
> CWM, it might be on us, so I wanted to do the due diligence of getting some
> more opinions before going upstream with it.
>
> Steps to reproduce:
>
> 1. Install Scribus from ports
> 2. Log in to X with CWM
> 3. Open Scribus, create a new document
> 4. Press "t" to create a new text box, place it on the canvas
> 5. Enter some text in the box.
> 6. Do any of the following:
> a. Right click on the text box and select "properties"
> b. Press F2
> c. Select Windows->Properties
> 7. Interact in some way with the properties dialog, maybe change the font, then
>    close it.
> 8. Attempt to repeat step 6. The properties dialog will not appear.
>
> I am happy to try out patches, gather further information, or otherwise assist
> any debugging effort to the best of my abilities.
>
> ~ Charles
>
> 1 - https://marc.info/?l=openbsd-misc&m=154524602418343&w=2
> 2 - https://bugs.scribus.net/view.php?id=9293
>

Reply | Threaded
Open this post in threaded view
|

Re: print/scribus: properties dialog broken under CWM

Benjamin Baier
In reply to this post by Charles A Daniels
On Thu, 11 Apr 2019 22:04:07 -0400
Charles <[hidden email]> wrote:

> Hello list,
Hello
 

> There seems to be an issue with the Scribus port when combined with CWM.
> Namely, the "properties" window/dialog can only be opened once. After
> being closed, it cannot be opened again. Restarting the application does
> not fix the problem.
>
> This issue is specific to CWM, I am not able to reproduce under FVWM.
>
> I have reproduced this issue under OpenBSD current on AMD64, and on
> OpenBSD 6.4 on macppc (iBook G4). In both cases, using Scribus 1.4.6
> installed via pkg_add.
>
> I found a previous issue that affected the way CWM and Qt interact, which was
> posted[1] under the subject line "calmwm mouse stuck inside of window" over on
> misc@. Okan and I synced up off list and determined it was due to CWM's
> implementation of EWMH interacting improperly with Qt.
Seen this one before, too.

> I am reporting this issue separately, as this particular failure seems specific
> to Scribus, as I've not seen this behavior under any other program.
VLC also does this. Running VLC in CWM and opening the "Show extended settings" dialog
also has the described behaviour.

> I believe this could reasonably be an issue with Scribus, Qt, and/or CWM.
>
> I have a hunch that this may be related in some way to Scribus issue 9293[2],
> as deleting the entire '<context name="PropertiesPalette">' section from
> "~/.scribus/prefs140.xml" allows the properties window to be opened. But
> closing and re-opening it will fail (presumably since this context has been
> re-created).
>
> It may be worth contacting upstream, but since this issue only happens under
> CWM, it might be on us, so I wanted to do the due diligence of getting some
> more opinions before going upstream with it.
>
> Steps to reproduce:
>
> 1. Install Scribus from ports
> 2. Log in to X with CWM
> 3. Open Scribus, create a new document
> 4. Press "t" to create a new text box, place it on the canvas
> 5. Enter some text in the box.
> 6. Do any of the following:
> a. Right click on the text box and select "properties"
> b. Press F2
> c. Select Windows->Properties
> 7. Interact in some way with the properties dialog, maybe change the font, then
>    close it.
> 8. Attempt to repeat step 6. The properties dialog will not appear.
>
> I am happy to try out patches, gather further information, or otherwise assist
> any debugging effort to the best of my abilities.
>
> ~ Charles
>
> 1 - https://marc.info/?l=openbsd-misc&m=154524602418343&w=2
> 2 - https://bugs.scribus.net/view.php?id=9293
>

Reply | Threaded
Open this post in threaded view
|

Re: print/scribus: properties dialog broken under CWM

Stuart Henderson
In reply to this post by Charles A Daniels
If you're trying to ascertain whether some problem is specific to cwm, you
should compare with another non-reparenting window manager (there's a list
of common ones at
https://en.m.wikipedia.org/wiki/Re-parenting_window_manager - for example
dwm is probably the most common one) as well as a more standard reparenting
wm. This should give you a better idea where the problem lies and give you
more details that you can report upstream if necessary.


--
Sent from a phone, apologies for poor formatting.

On 12 April 2019 03:04:30 Charles <[hidden email]> wrote:

> Hello list,
>
>
> There seems to be an issue with the Scribus port when combined with CWM.
>
>
> Namely, the "properties" window/dialog can only be opened once. After
> being closed, it cannot be opened again. Restarting the application does
> not fix the problem.
>
>
> This issue is specific to CWM, I am not able to reproduce under FVWM.
>
>
> I have reproduced this issue under OpenBSD current on AMD64, and on
> OpenBSD 6.4 on macppc (iBook G4). In both cases, using Scribus 1.4.6
> installed via pkg_add.
>
>
> I found a previous issue that affected the way CWM and Qt interact, which was
> posted[1] under the subject line "calmwm mouse stuck inside of window" over on
> misc@. Okan and I synced up off list and determined it was due to CWM's
> implementation of EWMH interacting improperly with Qt.
>
>
> I am reporting this issue separately, as this particular failure seems specific
> to Scribus, as I've not seen this behavior under any other program.
>
>
> I believe this could reasonably be an issue with Scribus, Qt, and/or CWM.
>
>
> I have a hunch that this may be related in some way to Scribus issue 9293[2],
> as deleting the entire '<context name="PropertiesPalette">' section from
> "~/.scribus/prefs140.xml" allows the properties window to be opened. But
> closing and re-opening it will fail (presumably since this context has been
> re-created).
>
>
> It may be worth contacting upstream, but since this issue only happens under
> CWM, it might be on us, so I wanted to do the due diligence of getting some
> more opinions before going upstream with it.
>
>
> Steps to reproduce:
>
>
> 1. Install Scribus from ports
> 2. Log in to X with CWM
> 3. Open Scribus, create a new document
> 4. Press "t" to create a new text box, place it on the canvas
> 5. Enter some text in the box.
> 6. Do any of the following:
> a. Right click on the text box and select "properties"
> b. Press F2
> c. Select Windows->Properties
> 7. Interact in some way with the properties dialog, maybe change the font, then
>   close it.
> 8. Attempt to repeat step 6. The properties dialog will not appear.
>
>
> I am happy to try out patches, gather further information, or otherwise assist
> any debugging effort to the best of my abilities.
>
>
> ~ Charles
>
>
> 1 - https://marc.info/?l=openbsd-misc&m=154524602418343&w=2
> 2 - https://bugs.scribus.net/view.php?id=9293



Reply | Threaded
Open this post in threaded view
|

Re: print/scribus: properties dialog broken under CWM

Charles A Daniels
In reply to this post by Charles A Daniels
On Fri, Apr 12, 2019 at 09:26:36AM +0200, Benjamin Baier wrote:

> On Thu, 11 Apr 2019 22:04:07 -0400
> Charles <[hidden email]> wrote:
>
> > Hello list,
> Hello
>
> > There seems to be an issue with the Scribus port when combined with CWM.
> > Namely, the "properties" window/dialog can only be opened once. After
> > being closed, it cannot be opened again. Restarting the application does
> > not fix the problem.
> >
> > This issue is specific to CWM, I am not able to reproduce under FVWM.
> >
> > I have reproduced this issue under OpenBSD current on AMD64, and on
> > OpenBSD 6.4 on macppc (iBook G4). In both cases, using Scribus 1.4.6
> > installed via pkg_add.
> >
> > I found a previous issue that affected the way CWM and Qt interact, which was
> > posted[1] under the subject line "calmwm mouse stuck inside of window" over on
> > misc@. Okan and I synced up off list and determined it was due to CWM's
> > implementation of EWMH interacting improperly with Qt.
> Seen this one before, too.
>
> > I am reporting this issue separately, as this particular failure seems specific
> > to Scribus, as I've not seen this behavior under any other program.
> VLC also does this. Running VLC in CWM and opening the "Show extended settings" dialog
> also has the described behaviour.

I believe that VLC uses qt also... probably a correlation there. Can you
reproduce this issue under other WMs on OpenBSD besides CWM?

> > I believe this could reasonably be an issue with Scribus, Qt, and/or CWM.
> >
> > I have a hunch that this may be related in some way to Scribus issue 9293[2],
> > as deleting the entire '<context name="PropertiesPalette">' section from
> > "~/.scribus/prefs140.xml" allows the properties window to be opened. But
> > closing and re-opening it will fail (presumably since this context has been
> > re-created).
> >
> > It may be worth contacting upstream, but since this issue only happens under
> > CWM, it might be on us, so I wanted to do the due diligence of getting some
> > more opinions before going upstream with it.
> >
> > Steps to reproduce:
> >
> > 1. Install Scribus from ports
> > 2. Log in to X with CWM
> > 3. Open Scribus, create a new document
> > 4. Press "t" to create a new text box, place it on the canvas
> > 5. Enter some text in the box.
> > 6. Do any of the following:
> > a. Right click on the text box and select "properties"
> > b. Press F2
> > c. Select Windows->Properties
> > 7. Interact in some way with the properties dialog, maybe change the font, then
> >    close it.
> > 8. Attempt to repeat step 6. The properties dialog will not appear.
> >
> > I am happy to try out patches, gather further information, or otherwise assist
> > any debugging effort to the best of my abilities.
> >
> > ~ Charles
> >
> > 1 - https://marc.info/?l=openbsd-misc&m=154524602418343&w=2
> > 2 - https://bugs.scribus.net/view.php?id=9293
> >

Stuart mentioned it may be an issue relating to re-parenting  or lack
thereof interacting adversely with qt (or Scribus). I will test under a
couple of other WMs to see if there is any pattern, and also try to
reproduce under Linux (if other non-reparenting WMs on Linux exhibit the
same problem, then this is an issue for upstream).

~ Charles

Reply | Threaded
Open this post in threaded view
|

Re: print/scribus: properties dialog broken under CWM

Okan Demirmen
On Fri 2019.04.12 at 10:15 -0400, Charles wrote:

> On Fri, Apr 12, 2019 at 09:26:36AM +0200, Benjamin Baier wrote:
> > On Thu, 11 Apr 2019 22:04:07 -0400
> > Charles <[hidden email]> wrote:
> >
> > > Hello list,
> > Hello
> >
> > > There seems to be an issue with the Scribus port when combined with CWM.
> > > Namely, the "properties" window/dialog can only be opened once. After
> > > being closed, it cannot be opened again. Restarting the application does
> > > not fix the problem.
> > >
> > > This issue is specific to CWM, I am not able to reproduce under FVWM.
> > >
> > > I have reproduced this issue under OpenBSD current on AMD64, and on
> > > OpenBSD 6.4 on macppc (iBook G4). In both cases, using Scribus 1.4.6
> > > installed via pkg_add.
> > >
> > > I found a previous issue that affected the way CWM and Qt interact, which was
> > > posted[1] under the subject line "calmwm mouse stuck inside of window" over on
> > > misc@. Okan and I synced up off list and determined it was due to CWM's
> > > implementation of EWMH interacting improperly with Qt.
> > Seen this one before, too.

Yes, in fact this has to do with cwm's insistence of warp'ing the mouse;
a lot of cwm's behaviours get in the way of ewmh - or maybe one could
say the other way around. Changing cwm various behaviours are
challenging because wm's are super personal and no one ends up happy
(including me); as this is my experience at least. /end mini-rant. One
might also say Qt behaves differently as well...anyway.

> > > I am reporting this issue separately, as this particular failure seems specific
> > > to Scribus, as I've not seen this behavior under any other program.
> > VLC also does this. Running VLC in CWM and opening the "Show extended settings" dialog
> > also has the described behaviour.
>
> I believe that VLC uses qt also... probably a correlation there. Can you
> reproduce this issue under other WMs on OpenBSD besides CWM?
>
> > > I believe this could reasonably be an issue with Scribus, Qt, and/or CWM.
> > >
> > > I have a hunch that this may be related in some way to Scribus issue 9293[2],
> > > as deleting the entire '<context name="PropertiesPalette">' section from
> > > "~/.scribus/prefs140.xml" allows the properties window to be opened. But
> > > closing and re-opening it will fail (presumably since this context has been
> > > re-created).
> > >
> > > It may be worth contacting upstream, but since this issue only happens under
> > > CWM, it might be on us, so I wanted to do the due diligence of getting some
> > > more opinions before going upstream with it.
> > >
> > > Steps to reproduce:
> > >
> > > 1. Install Scribus from ports
> > > 2. Log in to X with CWM
> > > 3. Open Scribus, create a new document
> > > 4. Press "t" to create a new text box, place it on the canvas
> > > 5. Enter some text in the box.
> > > 6. Do any of the following:
> > > a. Right click on the text box and select "properties"
> > > b. Press F2
> > > c. Select Windows->Properties
> > > 7. Interact in some way with the properties dialog, maybe change the font, then
> > >    close it.
> > > 8. Attempt to repeat step 6. The properties dialog will not appear.
> > >
> > > I am happy to try out patches, gather further information, or otherwise assist
> > > any debugging effort to the best of my abilities.
> > >
> > > ~ Charles
> > >
> > > 1 - https://marc.info/?l=openbsd-misc&m=154524602418343&w=2
> > > 2 - https://bugs.scribus.net/view.php?id=9293
> > >
>
> Stuart mentioned it may be an issue relating to re-parenting  or lack
> thereof interacting adversely with qt (or Scribus). I will test under a
> couple of other WMs to see if there is any pattern, and also try to
> reproduce under Linux (if other non-reparenting WMs on Linux exhibit the
> same problem, then this is an issue for upstream).
>
> ~ Charles
>

Reply | Threaded
Open this post in threaded view
|

Re: print/scribus: properties dialog broken under CWM

Charles A Daniels
On Fri, Apr 12, 2019 at 10:50:54AM -0400, Okan Demirmen wrote:

> On Fri 2019.04.12 at 10:15 -0400, Charles wrote:
> > On Fri, Apr 12, 2019 at 09:26:36AM +0200, Benjamin Baier wrote:
> > > On Thu, 11 Apr 2019 22:04:07 -0400
> > > Charles <[hidden email]> wrote:
> > >
> > > > Hello list,
> > > Hello
> > >
> > > > There seems to be an issue with the Scribus port when combined with CWM.
> > > > Namely, the "properties" window/dialog can only be opened once. After
> > > > being closed, it cannot be opened again. Restarting the application does
> > > > not fix the problem.
> > > >
> > > > This issue is specific to CWM, I am not able to reproduce under FVWM.
> > > >
> > > > I have reproduced this issue under OpenBSD current on AMD64, and on
> > > > OpenBSD 6.4 on macppc (iBook G4). In both cases, using Scribus 1.4.6
> > > > installed via pkg_add.
> > > >
> > > > I found a previous issue that affected the way CWM and Qt interact, which was
> > > > posted[1] under the subject line "calmwm mouse stuck inside of window" over on
> > > > misc@. Okan and I synced up off list and determined it was due to CWM's
> > > > implementation of EWMH interacting improperly with Qt.
> > > Seen this one before, too.
>
> Yes, in fact this has to do with cwm's insistence of warp'ing the mouse;
> a lot of cwm's behaviours get in the way of ewmh - or maybe one could
> say the other way around. Changing cwm various behaviours are
> challenging because wm's are super personal and no one ends up happy
> (including me); as this is my experience at least. /end mini-rant. One
> might also say Qt behaves differently as well...anyway.

<rant>

It is unfortunate that this type of thinking (referring to the general
philosophy of OpenBSD / CWM / suckless.org / et. al.) seem to swim so
hard against the current. I think it is not so unreasonable to expect my
WM to act on my behalf and not yank windows around without my say so,
and so on... unfortunately it would seem that I/we are in a minority on
that point.

</rant>

Do you think there is a strong possibility this is EWMH related? If the
EWMH event handler is disabled can the issue be reproduced still? I plan
to spend some time testing this more rigorously over the weeknd; I can
add CWM w/ EWMH patched out to my matrix of test configurations,
assuming I can figure out how to switch it off easily. As I recall it
had a pretty well defined entry point, but I haven't read the code in a
while.

> > > > I am reporting this issue separately, as this particular failure seems specific
> > > > to Scribus, as I've not seen this behavior under any other program.
> > > VLC also does this. Running VLC in CWM and opening the "Show extended settings" dialog
> > > also has the described behaviour.
> >
> > I believe that VLC uses qt also... probably a correlation there. Can you
> > reproduce this issue under other WMs on OpenBSD besides CWM?
> >
> > > > I believe this could reasonably be an issue with Scribus, Qt, and/or CWM.
> > > >
> > > > I have a hunch that this may be related in some way to Scribus issue 9293[2],
> > > > as deleting the entire '<context name="PropertiesPalette">' section from
> > > > "~/.scribus/prefs140.xml" allows the properties window to be opened. But
> > > > closing and re-opening it will fail (presumably since this context has been
> > > > re-created).
> > > >
> > > > It may be worth contacting upstream, but since this issue only happens under
> > > > CWM, it might be on us, so I wanted to do the due diligence of getting some
> > > > more opinions before going upstream with it.
> > > >
> > > > Steps to reproduce:
> > > >
> > > > 1. Install Scribus from ports
> > > > 2. Log in to X with CWM
> > > > 3. Open Scribus, create a new document
> > > > 4. Press "t" to create a new text box, place it on the canvas
> > > > 5. Enter some text in the box.
> > > > 6. Do any of the following:
> > > > a. Right click on the text box and select "properties"
> > > > b. Press F2
> > > > c. Select Windows->Properties
> > > > 7. Interact in some way with the properties dialog, maybe change the font, then
> > > >    close it.
> > > > 8. Attempt to repeat step 6. The properties dialog will not appear.
> > > >
> > > > I am happy to try out patches, gather further information, or otherwise assist
> > > > any debugging effort to the best of my abilities.
> > > >
> > > > ~ Charles
> > > >
> > > > 1 - https://marc.info/?l=openbsd-misc&m=154524602418343&w=2
> > > > 2 - https://bugs.scribus.net/view.php?id=9293
> > > >
> >
> > Stuart mentioned it may be an issue relating to re-parenting  or lack
> > thereof interacting adversely with qt (or Scribus). I will test under a
> > couple of other WMs to see if there is any pattern, and also try to
> > reproduce under Linux (if other non-reparenting WMs on Linux exhibit the
> > same problem, then this is an issue for upstream).
> >
> > ~ Charles
> >

Reply | Threaded
Open this post in threaded view
|

Re: print/scribus: properties dialog broken under CWM

Okan Demirmen
On Fri 2019.04.12 at 11:32 -0400, Charles wrote:

> On Fri, Apr 12, 2019 at 10:50:54AM -0400, Okan Demirmen wrote:
> > On Fri 2019.04.12 at 10:15 -0400, Charles wrote:
> > > On Fri, Apr 12, 2019 at 09:26:36AM +0200, Benjamin Baier wrote:
> > > > On Thu, 11 Apr 2019 22:04:07 -0400
> > > > Charles <[hidden email]> wrote:
> > > >
> > > > > Hello list,
> > > > Hello
> > > >
> > > > > There seems to be an issue with the Scribus port when combined with CWM.
> > > > > Namely, the "properties" window/dialog can only be opened once. After
> > > > > being closed, it cannot be opened again. Restarting the application does
> > > > > not fix the problem.
> > > > >
> > > > > This issue is specific to CWM, I am not able to reproduce under FVWM.
> > > > >
> > > > > I have reproduced this issue under OpenBSD current on AMD64, and on
> > > > > OpenBSD 6.4 on macppc (iBook G4). In both cases, using Scribus 1.4.6
> > > > > installed via pkg_add.
> > > > >
> > > > > I found a previous issue that affected the way CWM and Qt interact, which was
> > > > > posted[1] under the subject line "calmwm mouse stuck inside of window" over on
> > > > > misc@. Okan and I synced up off list and determined it was due to CWM's
> > > > > implementation of EWMH interacting improperly with Qt.
> > > > Seen this one before, too.
> >
> > Yes, in fact this has to do with cwm's insistence of warp'ing the mouse;
> > a lot of cwm's behaviours get in the way of ewmh - or maybe one could
> > say the other way around. Changing cwm various behaviours are
> > challenging because wm's are super personal and no one ends up happy
> > (including me); as this is my experience at least. /end mini-rant. One
> > might also say Qt behaves differently as well...anyway.
>
> <rant>
>
> It is unfortunate that this type of thinking (referring to the general
> philosophy of OpenBSD / CWM / suckless.org / et. al.) seem to swim so
> hard against the current. I think it is not so unreasonable to expect my
> WM to act on my behalf and not yank windows around without my say so,
> and so on... unfortunately it would seem that I/we are in a minority on
> that point.
>
> </rant>
>
> Do you think there is a strong possibility this is EWMH related? If the
> EWMH event handler is disabled can the issue be reproduced still? I plan
> to spend some time testing this more rigorously over the weeknd; I can
> add CWM w/ EWMH patched out to my matrix of test configurations,
> assuming I can figure out how to switch it off easily. As I recall it
> had a pretty well defined entry point, but I haven't read the code in a
> while.

Disable all the pointer warp'ing, or EWMH (active window hint) - either
will "fix" your issue in the short term.

Reply | Threaded
Open this post in threaded view
|

Re: print/scribus: properties dialog broken under CWM

Charles A Daniels
On Fri, Apr 12, 2019 at 12:23:33PM -0400, Okan Demirmen wrote:

> On Fri 2019.04.12 at 11:32 -0400, Charles wrote:
> > On Fri, Apr 12, 2019 at 10:50:54AM -0400, Okan Demirmen wrote:
> > > On Fri 2019.04.12 at 10:15 -0400, Charles wrote:
> > > > On Fri, Apr 12, 2019 at 09:26:36AM +0200, Benjamin Baier wrote:
> > > > > On Thu, 11 Apr 2019 22:04:07 -0400
> > > > > Charles <[hidden email]> wrote:
> > > > >
> > > > > > Hello list,
> > > > > Hello
> > > > >
> > > > > > There seems to be an issue with the Scribus port when combined with CWM.
> > > > > > Namely, the "properties" window/dialog can only be opened once. After
> > > > > > being closed, it cannot be opened again. Restarting the application does
> > > > > > not fix the problem.
> > > > > >
> > > > > > This issue is specific to CWM, I am not able to reproduce under FVWM.
> > > > > >
> > > > > > I have reproduced this issue under OpenBSD current on AMD64, and on
> > > > > > OpenBSD 6.4 on macppc (iBook G4). In both cases, using Scribus 1.4.6
> > > > > > installed via pkg_add.
> > > > > >
> > > > > > I found a previous issue that affected the way CWM and Qt interact, which was
> > > > > > posted[1] under the subject line "calmwm mouse stuck inside of window" over on
> > > > > > misc@. Okan and I synced up off list and determined it was due to CWM's
> > > > > > implementation of EWMH interacting improperly with Qt.
> > > > > Seen this one before, too.
> > >
> > > Yes, in fact this has to do with cwm's insistence of warp'ing the mouse;
> > > a lot of cwm's behaviours get in the way of ewmh - or maybe one could
> > > say the other way around. Changing cwm various behaviours are
> > > challenging because wm's are super personal and no one ends up happy
> > > (including me); as this is my experience at least. /end mini-rant. One
> > > might also say Qt behaves differently as well...anyway.
> >
> > <rant>
> >
> > It is unfortunate that this type of thinking (referring to the general
> > philosophy of OpenBSD / CWM / suckless.org / et. al.) seem to swim so
> > hard against the current. I think it is not so unreasonable to expect my
> > WM to act on my behalf and not yank windows around without my say so,
> > and so on... unfortunately it would seem that I/we are in a minority on
> > that point.
> >
> > </rant>
> >
> > Do you think there is a strong possibility this is EWMH related? If the
> > EWMH event handler is disabled can the issue be reproduced still? I plan
> > to spend some time testing this more rigorously over the weeknd; I can
> > add CWM w/ EWMH patched out to my matrix of test configurations,
> > assuming I can figure out how to switch it off easily. As I recall it
> > had a pretty well defined entry point, but I haven't read the code in a
> > while.
>
> Disable all the pointer warp'ing, or EWMH (active window hint) - either
> will "fix" your issue in the short term.

@Okan

It turns out that this actually did not fix the issue. I may have done
it wrong though...

In 'xev_handle_clientmessage(XEvent *ee)' in xevents.c I commented out
everything that called any xu_ewmh. I also commented out
'xu_ewmh_net_desktop_names(sc);' from xev_handle_propertynotify(XEvent
*ee).  Finally, I commented out the body of 'client_ptrwarp(struct
client_ctx *cc)' in client.c. I will still able to reproduce the issue
as discussed previously.

@Stuart

>  If you're trying to ascertain whether some problem is specific to
>  cwm, you should compare with another non-reparenting window manager
>  (there's a list of common ones at
>  https://en.m.wikipedia.org/wiki/Re-parenting_window_manager - for
>  example dwm is probably the most common one) as well as a more
>  standard reparenting wm. This should give you a better idea where the
>  problem lies and give you more details that you can report upstream
>  if necessary.

I tested under dwm on OpenBSD 6.4 on macppc and was not able to
re-produce the issue. Unfortunately it would appear that this is cwm
specific.

I have yet to test this under cwm on Linux (or any WMs aside from fvwm,
cwm, and dwm).

I will report back once I have tested more configurations, but I think
this runs deeper than just EWMH weirdness.

Maybe someone with some qt experience can chime in?

I would also be happy to be point-of-contact for upstream if we want to
see if they have any insight.

~ Charles