Re: [hackers] [dwm][PATCH] Remove BUGS and TODO

From: Christopher Drelich <cd_AT_cdrakka.com>
Date: Sat, 5 May 2018 17:21:21 -0400

Perhaps a solution would be to remove the outdated ones, and for
future ones put a date in the TODO file to correspond to when they
were requested?
Chris

On Fri, May 4, 2018 at 5:47 AM, Hiltjo Posthuma <hiltjo_AT_codemadness.org> wrote:
> On Thu, May 03, 2018 at 11:34:08PM -0400, Christopher Drelich wrote:
>> Hiltjo,
>> I submitted this particular patch because in an off-list discussion I
>> asked and you replied:
>>
>> >> (a) Is the TODO up to date, and if so could you clarify what you want a little.
>>
>> >In my opinion the items in the dwm TODO could be empty/removed.
>>
>> Maybe I misunderstood, but I got the impression this meant that the
>> TODO file was not accurate/up-to-date. If the TODO file is in fact
>> up-to-date and an accurate list of what is wanted for the mainstream
>> dwm project, then I will look into implementing them.
>>
>> In terms of bugs in dwm, there seems to be some listed in BUGS and
>> some in dwm.1, is this desired behavior or would it be better to have
>> them all in one place?
>>
>
> I responded to your comment about issue trackers, but some of the items in the
> TODO are outdated indeed.
>
>> On Thu, May 3, 2018 at 12:06 PM, Hiltjo Posthuma <hiltjo_AT_codemadness.org> wrote:
>> > On Wed, May 02, 2018 at 07:40:54PM -0400, Christopher Drelich wrote:
>> >> It is not clear if BUGS and TODO are up-to-date, and if people are
>> >> already working on (or have solved these issues.) We also don't know
>> >> much about an individuals setup. There are much better methods of
>> >> keeping track of this information besides textfiles in the source
>> >> tree. Issue trackers, wikis, etc.. are all viable options.
>> >>
>> >> It seems best to remove these files and discuss further options. It
>> >> might even be useful to find a place to talk about wanted patches
>> >> (Both thsoe that would and would not be included in the main code
>> >> base.)
>> >>
>> >
>> > Thats your opinion, I think textfiles are fine and better than most
>> > issue trackers.
>> >
>> >> ---
>> >>
>> >> 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
>> >> -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/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
>> >>
>> >
>> > --
>> > Kind regards,
>> > Hiltjo
>> >
>>
>
> --
> Kind regards,
> Hiltjo
>
Received on Sat May 05 2018 - 23:21:21 CEST