[hackers] [dwm] remove old TODO and BUGS entries || Hiltjo Posthuma

From: <git_AT_suckless.org>
Date: Sat, 12 May 2018 19:16:21 +0200 (CEST)

commit 10dfa65860d770cbce2cdaf67618f44f726a27c3
Author: Hiltjo Posthuma <hiltjo_AT_codemadness.org>
AuthorDate: Sat May 12 19:14:19 2018 +0200
Commit: Hiltjo Posthuma <hiltjo_AT_codemadness.org>
CommitDate: Sat May 12 19:14:19 2018 +0200

    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!

diff --git a/BUGS b/BUGS
deleted file mode 100644
index 6c9574a..0000000
--- a/BUGS
+++ /dev/null
_AT_@ -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
-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
_AT_@ -35,7 +35,7 @@ clean:
 dist: clean
 	_AT_echo creating dist tarball
 	_AT_mkdir -p dwm-${VERSION}
-	_AT_cp -R LICENSE TODO BUGS Makefile README config.def.h config.mk \
+	_AT_cp -R LICENSE Makefile README config.def.h config.mk \
 		dwm.1 drw.h util.h ${SRC} dwm.png transient.c dwm-${VERSION}
 	_AT_tar -cf dwm-${VERSION}.tar dwm-${VERSION}
 	_AT_gzip dwm-${VERSION}.tar
diff --git a/TODO b/TODO
deleted file mode 100644
index b33a08d..0000000
--- a/TODO
+++ /dev/null
_AT_@ -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
_AT_@ -158,7 +158,7 @@ code. This keeps it fast, secure and simple.
 .BR dmenu (1),
 .BR st (1)
 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
_AT_@ -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
-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.
+Send all bug reports with a patch to hackers_AT_suckless.org.
Received on Sat May 12 2018 - 19:16:21 CEST

This archive was generated by hypermail 2.3.0 : Sat May 12 2018 - 19:24:30 CEST