| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Need to think a bit more about locking,
but overall it's a working devdraw.
Multiclient mode may not be working
but nothing is using it yet.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Remote whitespace at the ends of lines.
Remove blank lines from the ends of files.
Change modes on source files so that they
are not executable.
Signed-off-by: Dan Cross <cross@gajendra.net>
|
| |
|
|
|
|
|
|
|
|
| |
See https://plan9port-review.googlesource.com/c/plan9/+/1470
for discussion of the approach, especially Michael Stapleberg's comment:
Note that chromium, firefox and others have tried this and then switched to using the Xft.dpi X resource, see e.g. https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/libgtk2ui/gtk2_ui.cc and especially http://sources.debian.net/src/gnome-settings-daemon/3.18.2-1/plugins/xsettings/gsd-xsettings-manager.c/?hl=824#L80 for some anecdata about why this approach doesn’t work out.
The Xft.dpi resource is being set accurately by desktop environments (GNOME, KDE, …) and can easily be changed by users of niche window managers by editing ~/.Xresources.
I suggest we check only Xft.dpi, without considering the DPI environment variable or the monitor width/height.
|
| | |
|
| |
|
|
|
|
|
| |
Fixes remote X11 use via XQuartz 2.7.4.
R=rsc
http://codereview.appspot.com/6624058
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
distinguish between "cannot receive without blocking"
and "EOF on connection".
In libmux, do not elect async guys muxers, so that
synchronous RPC calls run in the main event loop
(e.g., in eresized) do not get stuck.
Fixes problem reported by Lu Xuxiao, namely that
jpg etc. would spin at 100% cpu usage.
|
| | |
|
| |
|
