From mestelan at gmail.com  Sat Jul 20 22:04:15 2019
From: mestelan at gmail.com (Jean-Baptiste Mestelan)
Date: Sun, 21 Jul 2019 00:04:15 +0200
Subject: [xmonad] CopyQ clipboard manager: misbehaving window?
Message-ID: <CAHiuU4cWbZigX1bWsgEoO_O6BF0XwHyD8sFRPK0mxjwx0t5Hxw@mail.gmail.com>

Hello,

I have been struggling to integrate the CopyQ clipboard manager into my
configuration, because its main window cannot be closed: killing the window
has no effect, and in the context of a scratchpad, the toggle does not work
(the window appears but does not disappear).
Minimizing the window does work; but then, it can only be maximized from
the same workspace, which is not ideal for this use case.

I have come up with a so-so solution: summon the window from a named
scratchpad, and get rid of it by sending it to a NSP workspace:

*("M-a",                     shiftTo Next (WSIs nsp))*
*...*
*where nsp = return $ ("NSP" ==) . W.tag*
But it is cumbersome to have to manipulate two distinct keybindings (plus
the latter might send an innocent window into a void).

Is there an obvious solution that I am missing?

PS: to be clear, I am only speaking about the window displayed by the CopyQ
command `*copyq toggle*` (or `*copyq show*`). The smaller floating window
displayed by the CopyQ command `*copyq menu*` does not have this issue; but
is is also limited in functionalities and history length.

PPS: I guess an improvement would be to integrate the above `*shiftTo*`
function into a custom kill function, which would have two cases, depending
of the name of the window. I do not know how to write this however, and
would appreciate any pointers or suggestions.

Thank you for attention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20190721/f9cb9806/attachment.html>

From allbery.b at gmail.com  Sun Jul 21 12:28:01 2019
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 21 Jul 2019 08:28:01 -0400
Subject: [xmonad] CopyQ clipboard manager: misbehaving window?
In-Reply-To: <CAHiuU4cWbZigX1bWsgEoO_O6BF0XwHyD8sFRPK0mxjwx0t5Hxw@mail.gmail.com>
References: <CAHiuU4cWbZigX1bWsgEoO_O6BF0XwHyD8sFRPK0mxjwx0t5Hxw@mail.gmail.com>
Message-ID: <CAKFCL4UP=nrdbq=7jNsJMVHpDtX2GD7_7qP25LAAy8yW9+eOtw@mail.gmail.com>

I can't currently install or experiment with it (maybe in a day or so), but
it would help if you could report the output of xwininfo and xprop on this
window. Both programs let you click on a window to select it, so even if
the program is badly behaved you can run them with a "sleep" to pop up the
window during the sleep period and then wait for the cursor to change to a
crosshair.

On Sat, Jul 20, 2019 at 6:04 PM Jean-Baptiste Mestelan <mestelan at gmail.com>
wrote:

> Hello,
>
> I have been struggling to integrate the CopyQ clipboard manager into my
> configuration, because its main window cannot be closed: killing the window
> has no effect, and in the context of a scratchpad, the toggle does not work
> (the window appears but does not disappear).
> Minimizing the window does work; but then, it can only be maximized from
> the same workspace, which is not ideal for this use case.
>
> I have come up with a so-so solution: summon the window from a named
> scratchpad, and get rid of it by sending it to a NSP workspace:
>
> *("M-a",                     shiftTo Next (WSIs nsp))*
> *...*
> *where nsp = return $ ("NSP" ==) . W.tag*
> But it is cumbersome to have to manipulate two distinct keybindings (plus
> the latter might send an innocent window into a void).
>
> Is there an obvious solution that I am missing?
>
> PS: to be clear, I am only speaking about the window displayed by the
> CopyQ command `*copyq toggle*` (or `*copyq show*`). The smaller floating
> window displayed by the CopyQ command `*copyq menu*` does not have this
> issue; but is is also limited in functionalities and history length.
>
> PPS: I guess an improvement would be to integrate the above `*shiftTo*`
> function into a custom kill function, which would have two cases, depending
> of the name of the window. I do not know how to write this however, and
> would appreciate any pointers or suggestions.
>
> Thank you for attention.
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20190721/93d05427/attachment.html>

From mestelan at gmail.com  Sun Jul 21 14:04:50 2019
From: mestelan at gmail.com (Jean-Baptiste Mestelan)
Date: Sun, 21 Jul 2019 16:04:50 +0200
Subject: [xmonad] CopyQ clipboard manager: misbehaving window?
In-Reply-To: <CAKFCL4UP=nrdbq=7jNsJMVHpDtX2GD7_7qP25LAAy8yW9+eOtw@mail.gmail.com>
References: <CAHiuU4cWbZigX1bWsgEoO_O6BF0XwHyD8sFRPK0mxjwx0t5Hxw@mail.gmail.com>
 <CAKFCL4UP=nrdbq=7jNsJMVHpDtX2GD7_7qP25LAAy8yW9+eOtw@mail.gmail.com>
Message-ID: <CAHiuU4eh6S2v+TiowoEdCDrCdaBzA+fymigG2Q+HYL-edrfwMw@mail.gmail.com>

Thank you Brandon; here is:

xwininfo: Window id: 0xa00006 "xwininfo - CopyQ"

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1918
  Height: 538
  Depth: 24
  Visual: 0xde
  Visual Class: TrueColor
  Border width: 1
  Class: InputOutput
  Colormap: 0xa00005 (not installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+0  -0+0  -0-540  +0-540
  -geometry 1918x538+0+0


xprop
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_NET_WM_USER_TIME(CARDINAL) = 875255286
_NET_WM_ICON(CARDINAL) = Icon (16 x 16): <edited>
Icon (32 x 32): <edited>
Icon (64 x 64):<edited>
Icon (128 x 128): <edited>

_NET_WM_ICON_NAME(UTF8_STRING) =
XdndAware(ATOM) = BITMAP
WM_NAME(STRING) = "xprop - CopyQ"
_NET_WM_NAME(UTF8_STRING) = "xprop - CopyQ"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
WM_CLIENT_LEADER(WINDOW): window id # 0xa00008
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
_NET_WM_PID(CARDINAL) = 16725
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 10485767
WM_CLASS(STRING) = "copyq", "copyq"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS,
_NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 0, 0
user specified size: 958 by 1078
program specified minimum size: 108 by 88
window gravity: NorthWest


On Sun, 21 Jul 2019 at 14:28, Brandon Allbery <allbery.b at gmail.com> wrote:

> I can't currently install or experiment with it (maybe in a day or so),
> but it would help if you could report the output of xwininfo and xprop on
> this window. Both programs let you click on a window to select it, so even
> if the program is badly behaved you can run them with a "sleep" to pop up
> the window during the sleep period and then wait for the cursor to change
> to a crosshair.
>
> On Sat, Jul 20, 2019 at 6:04 PM Jean-Baptiste Mestelan <mestelan at gmail.com>
> wrote:
>
>> Hello,
>>
>> I have been struggling to integrate the CopyQ clipboard manager into my
>> configuration, because its main window cannot be closed: killing the window
>> has no effect, and in the context of a scratchpad, the toggle does not work
>> (the window appears but does not disappear).
>> Minimizing the window does work; but then, it can only be maximized from
>> the same workspace, which is not ideal for this use case.
>>
>> I have come up with a so-so solution: summon the window from a named
>> scratchpad, and get rid of it by sending it to a NSP workspace:
>>
>> *("M-a",                     shiftTo Next (WSIs nsp))*
>> *...*
>> *where nsp = return $ ("NSP" ==) . W.tag*
>> But it is cumbersome to have to manipulate two distinct keybindings (plus
>> the latter might send an innocent window into a void).
>>
>> Is there an obvious solution that I am missing?
>>
>> PS: to be clear, I am only speaking about the window displayed by the
>> CopyQ command `*copyq toggle*` (or `*copyq show*`). The smaller floating
>> window displayed by the CopyQ command `*copyq menu*` does not have this
>> issue; but is is also limited in functionalities and history length.
>>
>> PPS: I guess an improvement would be to integrate the above `*shiftTo*`
>> function into a custom kill function, which would have two cases, depending
>> of the name of the window. I do not know how to write this however, and
>> would appreciate any pointers or suggestions.
>>
>> Thank you for attention.
>> _______________________________________________
>> xmonad mailing list
>> xmonad at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
>>
>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20190721/b1957181/attachment.html>

From allbery.b at gmail.com  Sun Jul 21 16:47:49 2019
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 21 Jul 2019 12:47:49 -0400
Subject: [xmonad] CopyQ clipboard manager: misbehaving window?
In-Reply-To: <CAKFCL4UP=nrdbq=7jNsJMVHpDtX2GD7_7qP25LAAy8yW9+eOtw@mail.gmail.com>
References: <CAHiuU4cWbZigX1bWsgEoO_O6BF0XwHyD8sFRPK0mxjwx0t5Hxw@mail.gmail.com>
 <CAKFCL4UP=nrdbq=7jNsJMVHpDtX2GD7_7qP25LAAy8yW9+eOtw@mail.gmail.com>
Message-ID: <CAKFCL4WNzVX_03FRjWCpRc=xrwKcYhu1CYONC_QAZFC1dRhQ1w@mail.gmail.com>

So it turns out I got a chance to iron out (hopefully) my own recent issue
(Mint changed how it launches Mate's window manager, which left me without
one until I hacked up the new program they run that isn't properly
extensible, sigh), and poked at this.

Which is going to be a problem, because it's managed by a systray program
and gets annoyed if the window manager actually manages it, but fails to
set any of the ICCCM or EWMH flags that tells the window manager this. You
probably need to explicitly doIgnore it. (What they do will "just work" in
non-tiling window managers, /usually/. Until it doesn't, and they'll have
lots of weird bugs against any window manager that in any way actually
manages a window. Which may include compiz's fancy 3D stuff.)

You might be able to get it to behave semi-normally by disabling "close
when unfocused" and "open on current screen" in general options, then
manage it with NamedScratchpads. I wouldn't get my hopes too up, though.

On Sun, Jul 21, 2019 at 8:28 AM Brandon Allbery <allbery.b at gmail.com> wrote:

> I can't currently install or experiment with it (maybe in a day or so),
> but it would help if you could report the output of xwininfo and xprop on
> this window. Both programs let you click on a window to select it, so even
> if the program is badly behaved you can run them with a "sleep" to pop up
> the window during the sleep period and then wait for the cursor to change
> to a crosshair.
>
> On Sat, Jul 20, 2019 at 6:04 PM Jean-Baptiste Mestelan <mestelan at gmail.com>
> wrote:
>
>> Hello,
>>
>> I have been struggling to integrate the CopyQ clipboard manager into my
>> configuration, because its main window cannot be closed: killing the window
>> has no effect, and in the context of a scratchpad, the toggle does not work
>> (the window appears but does not disappear).
>> Minimizing the window does work; but then, it can only be maximized from
>> the same workspace, which is not ideal for this use case.
>>
>> I have come up with a so-so solution: summon the window from a named
>> scratchpad, and get rid of it by sending it to a NSP workspace:
>>
>> *("M-a",                     shiftTo Next (WSIs nsp))*
>> *...*
>> *where nsp = return $ ("NSP" ==) . W.tag*
>> But it is cumbersome to have to manipulate two distinct keybindings (plus
>> the latter might send an innocent window into a void).
>>
>> Is there an obvious solution that I am missing?
>>
>> PS: to be clear, I am only speaking about the window displayed by the
>> CopyQ command `*copyq toggle*` (or `*copyq show*`). The smaller floating
>> window displayed by the CopyQ command `*copyq menu*` does not have this
>> issue; but is is also limited in functionalities and history length.
>>
>> PPS: I guess an improvement would be to integrate the above `*shiftTo*`
>> function into a custom kill function, which would have two cases, depending
>> of the name of the window. I do not know how to write this however, and
>> would appreciate any pointers or suggestions.
>>
>> Thank you for attention.
>> _______________________________________________
>> xmonad mailing list
>> xmonad at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
>>
>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20190721/129dc069/attachment.html>

From allbery.b at gmail.com  Sun Jul 21 17:19:31 2019
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 21 Jul 2019 13:19:31 -0400
Subject: [xmonad] CopyQ clipboard manager: misbehaving window?
In-Reply-To: <CAKFCL4WNzVX_03FRjWCpRc=xrwKcYhu1CYONC_QAZFC1dRhQ1w@mail.gmail.com>
References: <CAHiuU4cWbZigX1bWsgEoO_O6BF0XwHyD8sFRPK0mxjwx0t5Hxw@mail.gmail.com>
 <CAKFCL4UP=nrdbq=7jNsJMVHpDtX2GD7_7qP25LAAy8yW9+eOtw@mail.gmail.com>
 <CAKFCL4WNzVX_03FRjWCpRc=xrwKcYhu1CYONC_QAZFC1dRhQ1w@mail.gmail.com>
Message-ID: <CAKFCL4WF0UQ3GOcKvr92bKJRUKHmjfEdmObzcXn1dqD6euvAwQ@mail.gmail.com>

You probably also have to turn off "always on top". The bit where it
relocates on clicks that I just got bit by, not sure if it can be worked
around; I suspect you'll need to work with the author to manage the window
properly or (sadly, rather more likely) get it to implement what you want
directly instead of using xmonad to do it, because it's one of those
programs that doesn't obey any rules but its own, and hopes window managers
don't implement any rules (and thereby needs to read ICCCM and EWMH,
because the window manager decides unless the program sets an override
flag).

On Sun, Jul 21, 2019 at 12:47 PM Brandon Allbery <allbery.b at gmail.com>
wrote:

> So it turns out I got a chance to iron out (hopefully) my own recent issue
> (Mint changed how it launches Mate's window manager, which left me without
> one until I hacked up the new program they run that isn't properly
> extensible, sigh), and poked at this.
>
> Which is going to be a problem, because it's managed by a systray program
> and gets annoyed if the window manager actually manages it, but fails to
> set any of the ICCCM or EWMH flags that tells the window manager this. You
> probably need to explicitly doIgnore it. (What they do will "just work" in
> non-tiling window managers, /usually/. Until it doesn't, and they'll have
> lots of weird bugs against any window manager that in any way actually
> manages a window. Which may include compiz's fancy 3D stuff.)
>
> You might be able to get it to behave semi-normally by disabling "close
> when unfocused" and "open on current screen" in general options, then
> manage it with NamedScratchpads. I wouldn't get my hopes too up, though.
>
> On Sun, Jul 21, 2019 at 8:28 AM Brandon Allbery <allbery.b at gmail.com>
> wrote:
>
>> I can't currently install or experiment with it (maybe in a day or so),
>> but it would help if you could report the output of xwininfo and xprop on
>> this window. Both programs let you click on a window to select it, so even
>> if the program is badly behaved you can run them with a "sleep" to pop up
>> the window during the sleep period and then wait for the cursor to change
>> to a crosshair.
>>
>> On Sat, Jul 20, 2019 at 6:04 PM Jean-Baptiste Mestelan <
>> mestelan at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I have been struggling to integrate the CopyQ clipboard manager into my
>>> configuration, because its main window cannot be closed: killing the window
>>> has no effect, and in the context of a scratchpad, the toggle does not work
>>> (the window appears but does not disappear).
>>> Minimizing the window does work; but then, it can only be maximized from
>>> the same workspace, which is not ideal for this use case.
>>>
>>> I have come up with a so-so solution: summon the window from a named
>>> scratchpad, and get rid of it by sending it to a NSP workspace:
>>>
>>> *("M-a",                     shiftTo Next (WSIs nsp))*
>>> *...*
>>> *where nsp = return $ ("NSP" ==) . W.tag*
>>> But it is cumbersome to have to manipulate two distinct keybindings
>>> (plus the latter might send an innocent window into a void).
>>>
>>> Is there an obvious solution that I am missing?
>>>
>>> PS: to be clear, I am only speaking about the window displayed by the
>>> CopyQ command `*copyq toggle*` (or `*copyq show*`). The smaller
>>> floating window displayed by the CopyQ command `*copyq menu*` does not
>>> have this issue; but is is also limited in functionalities and history
>>> length.
>>>
>>> PPS: I guess an improvement would be to integrate the above `*shiftTo*`
>>> function into a custom kill function, which would have two cases, depending
>>> of the name of the window. I do not know how to write this however, and
>>> would appreciate any pointers or suggestions.
>>>
>>> Thank you for attention.
>>> _______________________________________________
>>> xmonad mailing list
>>> xmonad at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
>>>
>>
>>
>> --
>> brandon s allbery kf8nh
>> allbery.b at gmail.com
>>
>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20190721/74e81bd1/attachment-0001.html>

From mestelan at gmail.com  Sun Jul 21 18:00:12 2019
From: mestelan at gmail.com (Jean-Baptiste Mestelan)
Date: Sun, 21 Jul 2019 20:00:12 +0200
Subject: [xmonad] CopyQ clipboard manager: misbehaving window?
In-Reply-To: <CAKFCL4WF0UQ3GOcKvr92bKJRUKHmjfEdmObzcXn1dqD6euvAwQ@mail.gmail.com>
References: <CAHiuU4cWbZigX1bWsgEoO_O6BF0XwHyD8sFRPK0mxjwx0t5Hxw@mail.gmail.com>
 <CAKFCL4UP=nrdbq=7jNsJMVHpDtX2GD7_7qP25LAAy8yW9+eOtw@mail.gmail.com>
 <CAKFCL4WNzVX_03FRjWCpRc=xrwKcYhu1CYONC_QAZFC1dRhQ1w@mail.gmail.com>
 <CAKFCL4WF0UQ3GOcKvr92bKJRUKHmjfEdmObzcXn1dqD6euvAwQ@mail.gmail.com>
Message-ID: <CAHiuU4dAvcxQpD7yTsx2jbxK8irOrx9h7u9JcRZJX0GvWRp=TA@mail.gmail.com>

Thank you for all the hints, Brandon.

Following your suggestions, I have tried to modify any display option
available, AND... it turns out that clicking "Layout->Hide main window"
removes the annoying behaviour!

So that is the problem worked around for this time. Of course, I would
prefer to use a more compliant program; I quite liked Glipper, but it has
been removed from Debian Buster.

Many thanks.





On Sun, 21 Jul 2019 at 19:19, Brandon Allbery <allbery.b at gmail.com> wrote:

> You probably also have to turn off "always on top". The bit where it
> relocates on clicks that I just got bit by, not sure if it can be worked
> around; I suspect you'll need to work with the author to manage the window
> properly or (sadly, rather more likely) get it to implement what you want
> directly instead of using xmonad to do it, because it's one of those
> programs that doesn't obey any rules but its own, and hopes window managers
> don't implement any rules (and thereby needs to read ICCCM and EWMH,
> because the window manager decides unless the program sets an override
> flag).
>
> On Sun, Jul 21, 2019 at 12:47 PM Brandon Allbery <allbery.b at gmail.com>
> wrote:
>
>> So it turns out I got a chance to iron out (hopefully) my own recent
>> issue (Mint changed how it launches Mate's window manager, which left me
>> without one until I hacked up the new program they run that isn't properly
>> extensible, sigh), and poked at this.
>>
>> Which is going to be a problem, because it's managed by a systray program
>> and gets annoyed if the window manager actually manages it, but fails to
>> set any of the ICCCM or EWMH flags that tells the window manager this. You
>> probably need to explicitly doIgnore it. (What they do will "just work" in
>> non-tiling window managers, /usually/. Until it doesn't, and they'll have
>> lots of weird bugs against any window manager that in any way actually
>> manages a window. Which may include compiz's fancy 3D stuff.)
>>
>> You might be able to get it to behave semi-normally by disabling "close
>> when unfocused" and "open on current screen" in general options, then
>> manage it with NamedScratchpads. I wouldn't get my hopes too up, though.
>>
>> On Sun, Jul 21, 2019 at 8:28 AM Brandon Allbery <allbery.b at gmail.com>
>> wrote:
>>
>>> I can't currently install or experiment with it (maybe in a day or so),
>>> but it would help if you could report the output of xwininfo and xprop on
>>> this window. Both programs let you click on a window to select it, so even
>>> if the program is badly behaved you can run them with a "sleep" to pop up
>>> the window during the sleep period and then wait for the cursor to change
>>> to a crosshair.
>>>
>>> On Sat, Jul 20, 2019 at 6:04 PM Jean-Baptiste Mestelan <
>>> mestelan at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I have been struggling to integrate the CopyQ clipboard manager into my
>>>> configuration, because its main window cannot be closed: killing the window
>>>> has no effect, and in the context of a scratchpad, the toggle does not work
>>>> (the window appears but does not disappear).
>>>> Minimizing the window does work; but then, it can only be maximized
>>>> from the same workspace, which is not ideal for this use case.
>>>>
>>>> I have come up with a so-so solution: summon the window from a named
>>>> scratchpad, and get rid of it by sending it to a NSP workspace:
>>>>
>>>> *("M-a",                     shiftTo Next (WSIs nsp))*
>>>> *...*
>>>> *where nsp = return $ ("NSP" ==) . W.tag*
>>>> But it is cumbersome to have to manipulate two distinct keybindings
>>>> (plus the latter might send an innocent window into a void).
>>>>
>>>> Is there an obvious solution that I am missing?
>>>>
>>>> PS: to be clear, I am only speaking about the window displayed by the
>>>> CopyQ command `*copyq toggle*` (or `*copyq show*`). The smaller
>>>> floating window displayed by the CopyQ command `*copyq menu*` does not
>>>> have this issue; but is is also limited in functionalities and history
>>>> length.
>>>>
>>>> PPS: I guess an improvement would be to integrate the above `*shiftTo*`
>>>> function into a custom kill function, which would have two cases, depending
>>>> of the name of the window. I do not know how to write this however, and
>>>> would appreciate any pointers or suggestions.
>>>>
>>>> Thank you for attention.
>>>> _______________________________________________
>>>> xmonad mailing list
>>>> xmonad at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
>>>>
>>>
>>>
>>> --
>>> brandon s allbery kf8nh
>>> allbery.b at gmail.com
>>>
>>
>>
>> --
>> brandon s allbery kf8nh
>> allbery.b at gmail.com
>>
>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20190721/62e89e74/attachment.html>

From allbery.b at gmail.com  Sun Jul 21 18:02:11 2019
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 21 Jul 2019 14:02:11 -0400
Subject: [xmonad] CopyQ clipboard manager: misbehaving window?
In-Reply-To: <CAHiuU4dAvcxQpD7yTsx2jbxK8irOrx9h7u9JcRZJX0GvWRp=TA@mail.gmail.com>
References: <CAHiuU4cWbZigX1bWsgEoO_O6BF0XwHyD8sFRPK0mxjwx0t5Hxw@mail.gmail.com>
 <CAKFCL4UP=nrdbq=7jNsJMVHpDtX2GD7_7qP25LAAy8yW9+eOtw@mail.gmail.com>
 <CAKFCL4WNzVX_03FRjWCpRc=xrwKcYhu1CYONC_QAZFC1dRhQ1w@mail.gmail.com>
 <CAKFCL4WF0UQ3GOcKvr92bKJRUKHmjfEdmObzcXn1dqD6euvAwQ@mail.gmail.com>
 <CAHiuU4dAvcxQpD7yTsx2jbxK8irOrx9h7u9JcRZJX0GvWRp=TA@mail.gmail.com>
Message-ID: <CAKFCL4WXitAPxxRmhzhrYt-68xKG81vK-F_8VHwhE7oCL7GNjg@mail.gmail.com>

I've been using clipit, myself, and will probably go back to it after
removing this one. (Hadn't set it up on this machine yet, which is another
part of why I'd thought I'd need to do more setup work to poke at this.)

On Sun, Jul 21, 2019 at 2:00 PM Jean-Baptiste Mestelan <mestelan at gmail.com>
wrote:

> Thank you for all the hints, Brandon.
>
> Following your suggestions, I have tried to modify any display option
> available, AND... it turns out that clicking "Layout->Hide main window"
> removes the annoying behaviour!
>
> So that is the problem worked around for this time. Of course, I would
> prefer to use a more compliant program; I quite liked Glipper, but it has
> been removed from Debian Buster.
>
> Many thanks.
>
>
>
>
>
> On Sun, 21 Jul 2019 at 19:19, Brandon Allbery <allbery.b at gmail.com> wrote:
>
>> You probably also have to turn off "always on top". The bit where it
>> relocates on clicks that I just got bit by, not sure if it can be worked
>> around; I suspect you'll need to work with the author to manage the window
>> properly or (sadly, rather more likely) get it to implement what you want
>> directly instead of using xmonad to do it, because it's one of those
>> programs that doesn't obey any rules but its own, and hopes window managers
>> don't implement any rules (and thereby needs to read ICCCM and EWMH,
>> because the window manager decides unless the program sets an override
>> flag).
>>
>> On Sun, Jul 21, 2019 at 12:47 PM Brandon Allbery <allbery.b at gmail.com>
>> wrote:
>>
>>> So it turns out I got a chance to iron out (hopefully) my own recent
>>> issue (Mint changed how it launches Mate's window manager, which left me
>>> without one until I hacked up the new program they run that isn't properly
>>> extensible, sigh), and poked at this.
>>>
>>> Which is going to be a problem, because it's managed by a systray
>>> program and gets annoyed if the window manager actually manages it, but
>>> fails to set any of the ICCCM or EWMH flags that tells the window manager
>>> this. You probably need to explicitly doIgnore it. (What they do will "just
>>> work" in non-tiling window managers, /usually/. Until it doesn't, and
>>> they'll have lots of weird bugs against any window manager that in any way
>>> actually manages a window. Which may include compiz's fancy 3D stuff.)
>>>
>>> You might be able to get it to behave semi-normally by disabling "close
>>> when unfocused" and "open on current screen" in general options, then
>>> manage it with NamedScratchpads. I wouldn't get my hopes too up, though.
>>>
>>> On Sun, Jul 21, 2019 at 8:28 AM Brandon Allbery <allbery.b at gmail.com>
>>> wrote:
>>>
>>>> I can't currently install or experiment with it (maybe in a day or so),
>>>> but it would help if you could report the output of xwininfo and xprop on
>>>> this window. Both programs let you click on a window to select it, so even
>>>> if the program is badly behaved you can run them with a "sleep" to pop up
>>>> the window during the sleep period and then wait for the cursor to change
>>>> to a crosshair.
>>>>
>>>> On Sat, Jul 20, 2019 at 6:04 PM Jean-Baptiste Mestelan <
>>>> mestelan at gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I have been struggling to integrate the CopyQ clipboard manager into
>>>>> my configuration, because its main window cannot be closed: killing the
>>>>> window has no effect, and in the context of a scratchpad, the toggle does
>>>>> not work (the window appears but does not disappear).
>>>>> Minimizing the window does work; but then, it can only be maximized
>>>>> from the same workspace, which is not ideal for this use case.
>>>>>
>>>>> I have come up with a so-so solution: summon the window from a named
>>>>> scratchpad, and get rid of it by sending it to a NSP workspace:
>>>>>
>>>>> *("M-a",                     shiftTo Next (WSIs nsp))*
>>>>> *...*
>>>>> *where nsp = return $ ("NSP" ==) . W.tag*
>>>>> But it is cumbersome to have to manipulate two distinct keybindings
>>>>> (plus the latter might send an innocent window into a void).
>>>>>
>>>>> Is there an obvious solution that I am missing?
>>>>>
>>>>> PS: to be clear, I am only speaking about the window displayed by the
>>>>> CopyQ command `*copyq toggle*` (or `*copyq show*`). The smaller
>>>>> floating window displayed by the CopyQ command `*copyq menu*` does
>>>>> not have this issue; but is is also limited in functionalities and history
>>>>> length.
>>>>>
>>>>> PPS: I guess an improvement would be to integrate the above `*shiftTo*`
>>>>> function into a custom kill function, which would have two cases, depending
>>>>> of the name of the window. I do not know how to write this however, and
>>>>> would appreciate any pointers or suggestions.
>>>>>
>>>>> Thank you for attention.
>>>>> _______________________________________________
>>>>> xmonad mailing list
>>>>> xmonad at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
>>>>>
>>>>
>>>>
>>>> --
>>>> brandon s allbery kf8nh
>>>> allbery.b at gmail.com
>>>>
>>>
>>>
>>> --
>>> brandon s allbery kf8nh
>>> allbery.b at gmail.com
>>>
>>
>>
>> --
>> brandon s allbery kf8nh
>> allbery.b at gmail.com
>>
>

-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20190721/e8811928/attachment-0001.html>