Custom Query (2683 matches)

Can you make the network congestion popup appear as topmost as possible, no arguments there, but without stealing focus?

While I agree I should fix the underlying problem and not see it at all, there are times it interferes with my typing; using "SPACE" will inadvertently activate an action instead of typing it.

Some user experience / story discussion:

So far my experience with them is that "they were not supposed to be triggering" (except the time I tried to stream a shadow server over 3mbps), and I have not felt they have been helping me.

I've set min_quality/min_speed already on the server with some sane limits, but they are arbitrary.

I am not sure what those limits mean visually: I don't have a topmost status screen telling me min_quality:x, min_speed:y. And what does min_speed=30 mean? <130 ms latency? Is it bound to the FPS I am seeing?

Neither can I reliably modify them and see their real-time results analogously to the way I can modify a volume slider on an audio console and see that real-time result on the green/yellow/red leds showing the db output (or hear more/less sound).

Related to the above I don't know how network congestion works (^^^ ... I have not felt they have been helping me), or how/if it recovers (again with that small quality/speed status panel).

Hi,

Client: Windows 7, v4.0-r25796 Server: RHEL 7.7, v3.0.5-r24939

When I launch an X11 application that opens in its own window, sometimes the new window doesn't respond to keyboard input. This seems to happen most often with gitk (around 40% of the time). (I have also seen it with gvim, but very rarely - maybe 1%.)

Steps to reproduce:

• xterm -geometry 200x80 & (the -geometry is not strictly required, but using a larger window than the default seems to increase the repro rate)
• In the new xterm: cd to somewhere in a git workspace
• gitk
• Ctrl-Q

Expected behaviour: gitk exits when you type Ctrl-Q. (If this happens then re-run gitk and try again. In my environment the issue reliably reproduces within 5 attempts)

Actual behavour: gitk doesn't respond to the Ctrl-Q, or any other keyboard input. Mouse input still works. If you switch focus to another window then back to gitk, the keyboard works. (But just clicking on the gitk window isn't enough.)

I was also able to reproduce this issue with client v3.0.8-r25712, but not client v2.4.2-r21077 (still with server v3.0.5-r24939), so it seems to be a regression since v2.4.2.

Let me know if you need more info...

When that list starts getting long, it becomes hard to track the session you are looking for:

$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
	LIVE session at :100
	LIVE session at :2
	LIVE session at :20
	LIVE session at :200
/run/xpra:
	LIVE session at :100
	LIVE session at :2
	LIVE session at :20
	LIVE session at :200

My ideas would be:

• The automatic name
• A custom name (I don't remember; can I do that?)
• CSV all the open window titles (is there an easy way to do that, or do I need to play with window.\d+.title= xpra-info parsing?)