aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorHiltjo Posthuma2018-05-12 19:14:19 +0200
committerHiltjo Posthuma2018-05-12 19:14:19 +0200
commit10dfa65860d770cbce2cdaf67618f44f726a27c3 (patch)
tree4784f5ec39b0b6478e92520025c42f10ccdbf5f8
parent3bd8466e93b2c81be86e67c6ecdda4e1d240fe4b (diff)
remove old TODO and BUGS entries
the bug in the dwm man page is an (ancient) Java issue. Thanks David and quinq for the patches and feedback!
-rw-r--r--BUGS44
-rw-r--r--Makefile2
-rw-r--r--TODO4
-rw-r--r--dwm.112
4 files changed, 4 insertions, 58 deletions
diff --git a/BUGS b/BUGS
deleted file mode 100644
index 6c9574a..0000000
--- a/BUGS
+++ /dev/null
@@ -1,44 +0,0 @@
----
-
-18:17 < Biolunar> when i change my resolution in dwm (to a smaller one) and then back to the native, the top bar is not repainted. that's since 5.7.2, in 5.6 it worked fine
-18:19 < Biolunar> is it just happening to me or a (known) bug?
-18:24 < Biolunar> and in addition, mplayers fullscreen is limited to the small resolution after i changed it back to the native
-
-reproducible with xrandr -s but not with --output and --mode, strange
-
----
-
-yet another corner case:
-open a terminal, focus another monitor, but without moving the mouse
-pointer there
-if there is no client on the other monitor to get the focus, then the
-terminal will be unfocused but it will accept input
-
----
-
-Donald Allen reported this:
-
-starting emacs from dmenu in archlinux results in missing configure of emacs, but mod1-space or mod1-shift-space fix this problem. this problem is new and did not happen in 1.6 xorg servers
-
----
-
-voltaic reports this:
-
-When I use two monitors, one larger in resolution than the other, the
-bar is drawn using the smaller x-dimension on both screens. I think
-what's happening is that there are two bars drawn, but the short bar
-is always on top of the long bar such that I can't see the information
-under the short bar. If I switch to the small screen, hide the short
-bar, and then switch to the large screen, the long bar is drawn
-correctly.
-
-A similar problem occurs when I have started dwm on a small resolution
-monitor (laptop screen) and then I switch to a large external display.
-When I do this, the bar itself is drawn for the original smaller
-resolution, but the information to be printed on the bar is
-right-aligned for a longer bar. So what I see is a bar that has the
-right hand side of it cut-off. See attached screenshot.
-
-I am using standard options for xrandr such as --output VGA1 --auto, etc.
-
----
diff --git a/Makefile b/Makefile
index 1ea40b7..d7acc01 100644
--- a/Makefile
+++ b/Makefile
@@ -35,7 +35,7 @@ clean:
dist: clean
@echo creating dist tarball
@mkdir -p dwm-${VERSION}
- @cp -R LICENSE TODO BUGS Makefile README config.def.h config.mk \
+ @cp -R LICENSE Makefile README config.def.h config.mk \
dwm.1 drw.h util.h ${SRC} dwm.png transient.c dwm-${VERSION}
@tar -cf dwm-${VERSION}.tar dwm-${VERSION}
@gzip dwm-${VERSION}.tar
diff --git a/TODO b/TODO
deleted file mode 100644
index b33a08d..0000000
--- a/TODO
+++ /dev/null
@@ -1,4 +0,0 @@
-- add a flag to Key to execute the command on release (needed for commands
- affecting the keyboard grab, see scrot -s for example)
-- add updategeom() hook for external tools like dzen
-- consider onscreenkeyboard hooks for tablet deployment
diff --git a/dwm.1 b/dwm.1
index e3b2c38..13b3729 100644
--- a/dwm.1
+++ b/dwm.1
@@ -158,7 +158,7 @@ code. This keeps it fast, secure and simple.
.SH SEE ALSO
.BR dmenu (1),
.BR st (1)
-.SH BUGS
+.SH ISSUES
Java applications which use the XToolkit/XAWT backend may draw grey windows
only. The XToolkit/XAWT backend breaks ICCCM-compliance in recent JDK 1.5 and early
JDK 1.6 versions, because it assumes a reparenting window manager. Possible workarounds
@@ -172,11 +172,5 @@ or
(to pretend that a non-reparenting window manager is running that the
XToolkit/XAWT backend can recognize) or when using OpenJDK setting the environment variable
.BR _JAVA_AWT_WM_NONREPARENTING=1 .
-.P
-GTK 2.10.9+ versions contain a broken
-.BR Save\-As
-file dialog implementation,
-which requests to reconfigure its window size in an endless loop. However, its
-window is still respondable during this state, so you can simply ignore the flicker
-until a new GTK version appears, which will fix this bug, approximately
-GTK 2.10.12+ versions.
+.SH BUGS
+Send all bug reports with a patch to hackers@suckless.org.