[xmonad] CopyQ clipboard manager: misbehaving window?

[Jean-Baptiste Mestelan]

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>