[xmonad] CopyQ clipboard manager: misbehaving window?

[Brandon Allbery]

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>