From 10dfa65860d770cbce2cdaf67618f44f726a27c3 Mon Sep 17 00:00:00 2001 From: Hiltjo Posthuma Date: Sat, 12 May 2018 19:14:19 +0200 Subject: 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! --- BUGS | 44 -------------------------------------------- Makefile | 2 +- TODO | 4 ---- dwm.1 | 12 +++--------- 4 files changed, 4 insertions(+), 58 deletions(-) delete mode 100644 BUGS delete mode 100644 TODO diff --git a/BUGS b/BUGS deleted file mode 100644 index 6c9574a1..00000000 --- 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 1ea40b76..d7acc016 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 b33a08d9..00000000 --- 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 e3b2c388..13b37299 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. -- cgit v1.2.3