sil's questions

It is easy to set the contents of the normal ctrl-C ctrl-V clipboard in Gtk 3 in a Python 3 app, with something like

clipboard = Gtk.Clipboard.get(Gdk.SELECTION_CLIPBOARD)
clipboard.set_text("It worked!, -1)

It is also easy to monitor the clipboard for changes, using the Clipboard object's owner-change signal.

However, I would like to ignore owner-change in my app if it was my app that set the contents of the clipboard, and I don't know how. The owner-change signal passes an owner parameter which points to a Gdk.Window, but I never explicitly create a window in my app; I assume that Gtk quietly creates one for me because there needs to be some X window around to own the contents of the clipboard. I can get that X window's ID when the clipboard owner changes with something like:

def clipboardChanged(clipboard, owner_change):
    print("New owner is", owner_change.owner.get_xid())

clipboard.connect('owner-change', clipboardChanged)

This new owner window obviously belongs to my app, but how do I find its xid ahead of time? That is: how can I tell from an owner-change signal that the new owner is me?

(Note: if I set the contents of the clipboard twice, I get two owner-change signals, and owner_change.reason is NEW_OWNER every time, so this is not reliable: in particular, NEW_OWNER is also sent for "the same owner set it again", and not just for "a different owner now owns the clipboard".)

I would like to configure Ubuntu 20.04 (with Gnome shell) so that if I click a window which does not have focus, that click raises the window and does nothing else; in particular, that click to raise the window does not actually have an effect on the window (so I can click where a button is without activating that button). In the old days on the Mac this, clicks triggering actions in background windows, was called "click-through"; it's the default in GNOME Shell and I'd like to disable it.

The reason for this is that it is very hard to click on a window to raise it without also clicking on a button inside it!

Almost all the visible areas of that Nautilus window are "active" areas in some way; clicking in that window to focus and raise it will also change the folder that it is currently displaying.

Some clarifications:

1. This is not about the window focus mode (focus-follows-mouse or sloppy focus). Windows are focused by clicking on them; I do not want focus-follows-mouse, and it is not what this question is about.
2. This is about raising a window and giving it the focus by clicking on the window. I can switch to that window in other ways (alt-tab, for example, or by choosing it from the Dock) but I want to be able to click on a window to focus it and raise it, exactly as I currently can, but I don't want to have to be careful to only click on an "inactive" area of that window to focus it.
3. Yes, this problem is exacerbated by how there are not very many "inactive" areas in a window now that the title bar contains buttons. That's not what this question is about, and I am quite happy with the window containing many buttons, as long as I'm not forced to click one of them just in order to give the window focus.

I am informed by Mattias Wernér that Super+Click does exactly this (raises a window without the click being received by the window itself), which is great, and so it is possible that this question should be rephrased as "how do I make click on unfocused windows do what Super+click does?".

I have two audio devices on my Ubuntu 20.04 machine: Built-in Audio and a USB sound device, and I only want to use the USB device; I don't need the Built-in Audio at all, and I'd like to disable it (because then I never have to worry about selecting a sound device in video conferencing apps and the like). I can disable the Built-in Audio device in PulseAudio Volume Control (pavucontrol) by setting "Built-in Audio" to "off", and I can also do this same action from the command line with pactl set-card-profile alsa_card.pci-0000_00_03.0 off and that all works. However, if I lock the screen and then unlock it again, that card gets re-enabled! How can I set it to off so that it stays off?

After I log in to my Ubuntu 14.04 desktop, I see my desktop background for approximately 20 seconds before the actual Unity desktop loads. I installed bootchart and that suggests that the problem is that pactl is being called and taking a long time to do something, and that the main desktop startup is blocked on that:

How can I identify where this pactl call is, and why it might be taking a long time?

Logs from pulseaudio startup are at: http://kryogenix.org/random/pulseverbose/.

I've reached the point where I want to write my own music player (it comes to us all). However, all the things I want to do are UI-based; it would be daft for me to have to reimplement managing a library, reading ID3 tags, creating playlists, and so on. Therefore, what I'm looking for is a music player which doesn't present a UI (or can have that UI hidden) so that I can implement my own entirely custom UI without having to build all the infrastructure as well. This "underlying" music player might be a curses interface with a remote control socket protocol; it might be a library with Python bindings; it might be a Gtk app which takes an option to not present its GUI and can be controlled over D-Bus... I don't know.

Things I non-negotiably want this "back end" to do:

1. Be remote-controllable from a Python program. (As mentioned, I'm open to lots of methods of remote control; a socket, D-Bus, a CLI tool, whatever)
2. maintain a library of music - that is, scan my music for metadata and be able to address music by that metadata (so I can search for "beatles" and find tracks, not just those which match on the filename)
3. monitor a folder for changes and load those changes (new files, altered files, deleted files) into the library without having to be told to do so
4. let me provide my own GUI (hence the need for remote-controllability)

Things I'd really, really, really like but which aren't strictly necessary:

1. Ubuntu sound menu integration
2. Be packaged for Ubuntu already and in Software Centre

I've looked at a few alternatives and rejected them, but I might be wrong: if I'm wrong about any of these, do please correct me.

• cmus: cannot monitor the library for changes (needs to be prodded with update command). Also, AFAICT the remote control is primarily to make the curses interface do things; it's hard-to-impossible to use the remote control to say "give me a list of all songs matching 'beatles'"
• mpd (and some client): cannot monitor the library for changes (needs to be prodded with "update" command)
• moc: cannot monitor the library for changes
• banshee (and banshee's back end, Nereid (?)): as far as I can tell, can't be controlled by a Python program: I'd need to write my new front end in C#
• rhythmbox, guayadeque, audacious, quodlibet, clementine, noise, beatbox, deadbeef, gmusicbrowser, xnoise: can't turn the GUI off and replace it with my own

So, I'm looking either for explanations of how to do what I want with the above, or suggestions for alternative tools that I could use instead of those!

Having just written my perfect screenshot tool, I've been trying to work out how it should set itself up for use by people who are not me. Screenshots are traditionally taken by pressing the PrtSc key. So, I could do the following things:

As soon as the app is installed, make pressing PrtSc invoke the app

Pros:

• works immediately, out of the box, as expected. A user installs the app, hits PrtSc, they get the app they've just installed. Hooray.

Cons:

• unconditionally overrides any existing setup you have for PrtSc, which might be annoying
• if you uninstall the app, it won't reset PrtSc to what it was before, which is also annoying
• problematic for multiple users, because app installation runs under sudo, so how does it know which user's PrtSc setup to override? It's certainly possible to add a gconf key as part of installation, but that may be problematic if two different screenshot apps both try?

On first-run of the app, seize the PrtSc key

Pros:

• avoids the above problem of wrongly seizing other users' PrtSc keys

Cons:

• you have to run the app once manually first, which is annoying (and how do you know how to do that?)
• will still not restore the old setting if the app is uninstalled

Have a configuration dialog in the app where you configure it to seize PrtSc

Pros:

• Only seizes PrtSc for people that really want it to

Cons:

• you have to run the app once manually first, which is annoying (and how do you know how to do that?)
• you have to go into a configuration dialog to make the app actually do what it's intended to do; take screenshots when you press PrtSc. Ubuntu is past that configure-everything stage now, surely? How irritating. Not doing this!

Something else I haven't thought of

A better cleverer approach that just hasn't dawned on me yet.

Suggestions welcomed!