Re: [dev] dwm: Maybe a combination of columns and grids?

On January 26, 2024 1:57:07 PM GMT+03:00, Greg Reagle wrote: >On Thu, Jan 25, 2024, at 8:16 PM, lain. wrote: >> On 2024年01月25日 14:48, the silly Greg Reagle claimed to have said: >>> Salutations. Is there already a dwm layout patch for what I describe below? >>> >>> I love the way that the

Re: [dev] dwm: Maybe a combination of columns and grids?

On Thu, Jan 25, 2024, at 8:16 PM, lain. wrote: > On 2024年01月25日 14:48, the silly Greg Reagle claimed to have said: >> Salutations. Is there already a dwm layout patch for what I describe below? >> >> I love the way that the columns patch handles the master area, i.e. the >> ability to control

Re: [dev] dwm: Maybe a combination of columns and grids?

On 2024年01月25日 14:48, the silly Greg Reagle claimed to have said: > Salutations. Is there already a dwm layout patch for what I describe below? > > I love the way that the columns patch handles the master area, i.e. the > ability to control its width and number of windows, and that the windows

Re: [dev] [dwm][PATCH] Add function to exec into another executable

On Sat, Jul 15, 2023 at 08:48:29PM +0600, NRK wrote: > Hi Dmitry, > > > but I don't need to restart X, which is much more annoying. > > There's no need to patch anything to achieve this. You can do something > like this in your xinitrc: > > while :; do dwm; done > > This will re-run dwm

Re: [dev] [dwm][PATCH] Add function to exec into another executable

Hi Dmitry, > but I don't need to restart X, which is much more annoying. There's no need to patch anything to achieve this. You can do something like this in your xinitrc: while :; do dwm; done This will re-run dwm after it quits. And if you want to quit for real, then you can just

Re: [dev] [dwm] swallow without patching dwm -- or losing focus

On 23/05/26 11:07AM, v4hn wrote: > On Fri, May 26, 2023 at 02:50:20AM -0300, Spenser Truex wrote: > > I just want my windows to open where I opened > > them. There is no kitchen sink included. > > I would like that too, but the linked project doesn't do it. > It doesn't even work when ran through

Re: [dev] [dwm] swallow without patching dwm -- or losing focus

On 26.5.2023 9.19, NRK wrote:> `system` is a function that should never be used unless the person is aware of all the shell shenanigans that can bite back. The above is an extreme example, but *any* character that has special meaning to shell can cause problems. You should instead look into

Re: [dev] [dwm] swallow without patching dwm -- or losing focus

On Fri, May 26, 2023 at 02:50:20AM -0300, Spenser Truex wrote: > I just want my windows to open where I opened > them. There is no kitchen sink included. I would like that too, but the linked project doesn't do it. It doesn't even work when ran through `dmenu`, but instead hides/unhides whatever

Re: [dev] [dwm] swallow without patching dwm -- or losing focus

On Thu, May 25, 2023 at 07:42:04PM -0300, Spenser Truex wrote: > I converted this swallow program to C, not that it makes any difference > at this code size. It's just a couple of malloc'd strings. > > https://github.com/equwal/swallow-c-- $ ./swallow '$(rm -fr $HOME)' `system` is a

Re: [dev] [dwm] swallow without patching dwm -- or losing focus

On 23/05/26 07:24AM, Sagar Acharya wrote: > Beautiful code. As a rookie user, how will this code be used? Can this be a > complete Xenocara/Xorg alternative? > Thanking you A very humourous response. I just want my windows to open where I opened them. There is no kitchen sink included. It is

Re: [dev] [dwm] swallow without patching dwm -- or losing focus

Beautiful code. As a rookie user, how will this code be used? Can this be a complete Xenocara/Xorg alternative? Thanking you Sagar Acharya http://humaaraartha.in 26 May 2023, 05:45 by tr...@equwal.com: > Greetings, > > I converted this swallow program to C, not that

Re: [dev] [dwm] DWM Multihead Missing Cursor

Hi. I think you 2nd monitor ate the cursor, you should keep it on a leash. I know it's off-topic, but cmon, humor is healthy

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

On Sat, Apr 08, 2023 at 11:02:56PM +0200, Storkman wrote: > On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote: > > Hello everyone, > > > > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works > > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD > >

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

Voila, one single line of change make dmenu_extended_run launch again! git diff dwm.c diff --git a/dwm.c b/dwm.c index c2bd871..f8f83f8 100644 --- a/dwm.c +++ b/dwm.c @@ -1653,6 +1653,7 @@ spawn(const Arg *arg) if (dpy)

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote: > Hello everyone, > > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD > handling` [1] commit, since dmenu_extended does not change anything

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

On 23/04/08 07:24PM, p...@mailbox.org wrote: > static const char *dmenu_extend[] = { "dmenu_extended_run", NULL }; How about: > > (Try changing your > > dmenu_extended keybind to something else and see if that works or not). 1. What happens if you use: static const char

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

I built dwm based on https://aur.archlinux.org/packages/dwm-git > diff config.h src/dwm/config.def.h > 62d61 > < static const char *dmenu_extend[] = { "dmenu_extended_run", NULL }; > 67d65 > < { MODKEY, XK_o, spawn, {.v = > dmenu_extend } }, in config.h

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

On Sat, Apr 08, 2023 at 07:24:07PM +0200, p...@mailbox.org wrote: > - patch is disabled > - `dwm 2> ~/dwm.log` shows nothing > > define command as > > static const char *dmenu_extend[] = { "dmenu_extended_run", NULL }; > > bind the command to a keyboard shortcut > > static Key keys[] =

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

- patch is disabled - `dwm 2> ~/dwm.log` shows nothing define command as static const char *dmenu_extend[] = { "dmenu_extended_run", NULL }; bind the command to a keyboard shortcut static Key keys[] = { MODKEY, XK_o, spawn, {.v =

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

Hi, On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote: > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD > handling` [1] commit, since dmenu_extended does not change anything here, > is this a

Re: [dev] dwm 6.4 compilation error on FreeBsd

On Thu, 16 Feb 2023 12:23:00 +0600 NRK wrote: > > I think we might need to define `_XOPEN_SOURCE=700L`. Does this fix > the issue: > > diff --git a/config.mk b/config.mk ># flags > -CPPFLAGS = -D_DEFAULT_SOURCE -D_BSD_SOURCE > -D_POSIX_C_SOURCE=200809L

Re: [dev] dwm 6.4 compilation error on FreeBsd

On Thu, Feb 16, 2023 at 06:07:02PM +1300, beastie wrote: > Hello I am experiencing an error when trying to compile the latest > version of dwm from https://git.suckless.org/dwm, > > Here is the commit that I think is causing the issue: >

Re: [dev] dwm 6.4 compilation error on FreeBsd

> dwm.c:1549:31: error: use of undeclared identifier 'SA_NOCLDWAIT' > sa.sa_flags = SA_NOCLDSTOP | SA_NOCLDWAIT | SA_RESTART; > ^ > dwm.c:1549:46: error: use of undeclared identifier 'SA_RESTART' > sa.sa_flags = SA_NOCLDSTOP | SA_NOCLDWAIT |

Re: [dev] [dwm] [st] benefits (or not) of -march=x86-64-v3 and gcc optimizations

On Tue, 7 Feb 2023 10:30:24 +0200 Κρακ Άουτ wrote: Dear Κρακ, > I have compiled dwm & st using -march=x86-64-v3 (tried > -march=x86-64-v2 also). To be honest they are both (dwm & st) fast > and snappy with their default configuration and I cannot spot any > difference when compiled with

Re: [dev] [dwm] [st] benefits (or not) of -march=x86-64-v3 and gcc optimizations

It's extremely unlikely you could observe any difference using these tools on any remotely modern hardware. In practical terms it doesn't matter. But if you want to satisfy your curiosity, you could do some profiling, I guess; or decompile the binaries and eyeball the generated instructions. I'd

Re: [dev] [dwm] [st] benefits (or not) of -march=x86-64-v3 and gcc optimizations

Hi, On Tue, Feb 07, 2023 at 10:30:24AM +0200, Κρακ Άουτ wrote: > As I mentioned, in practice I don't see any differences. I'm wondering if > theoretically there could be some positive effect. People who know how > exactly the code works are better suited to supply a definitive answer than >

Re: [dev] [dwm] Bluetooth XF86 keys not working

On 1/16/23 22:23, Storkman wrote: On January 17, 2023 3:03:52 AM UTC, Anskrevy wrote: I've got XF86XK_AudioPlay bound in my config.h with the necessary include file, and this hotkey works when I use my keyboard. However, when sent from a pair of bluetooth headphones the hotkey isn't

Re: [dev] [dwm] Bluetooth XF86 keys not working

On January 17, 2023 3:03:52 AM UTC, Anskrevy wrote: >I've got XF86XK_AudioPlay bound in my config.h with the necessary >include file, and this hotkey works when I use my keyboard. However, >when sent from a pair of bluetooth headphones the hotkey isn't >triggered. I've got the following xev

Re: [dev] [dwm] view() and toggleview() functions

On Mon, Jan 16, 2023 at 08:21:57PM +0900, A Farzat wrote: > Btw, on the email subject it says [SPAM Warning!]. Is it anything I need > to be concerned with? No, you're good. It was just a false positive on my end and I forgot to remove that before replying. - NRK

Re: [dev] [dwm] Obtain focused monitor

On 23/01/12 11:35am, Gauthier Östervall wrote: > On Sun, 8 Jan 2023 at 11:21, A Farzat wrote: > > > > Is there a way to obtain the currently focused monitor in dwm? I want to > > use it in my script to control which monitor gets its brightness > > modified. > > Do you mean obtain from outside

Re: [dev] [dwm] Obtain focused monitor

On Sun, 8 Jan 2023 at 11:21, A Farzat wrote: > > Is there a way to obtain the currently focused monitor in dwm? I want to > use it in my script to control which monitor gets its brightness > modified. Do you mean obtain from outside the dwm process? Not directly, that I am aware of. But you

Re: [dev] [dwm] Obtain focused monitor

Hi, On Sun Jan 8, 2023 at 11:40 AM CET, A Farzat wrote: > On 23/01/08 11:32am, Hiltjo Posthuma wrote: > > On Sun, Jan 08, 2023 at 07:19:10PM +0900, A Farzat wrote: > > > Is there a way to obtain the currently focused monitor in dwm? I want to > > > use it in my script to control which monitor

Re: [dev] [dwm] Obtain focused monitor

On Sun, Jan 08, 2023 at 07:40:21PM +0900, A Farzat wrote: > On 23/01/08 11:32am, Hiltjo Posthuma wrote: > > On Sun, Jan 08, 2023 at 07:19:10PM +0900, A Farzat wrote: > > > Is there a way to obtain the currently focused monitor in dwm? I want to > > > use it in my script to control which monitor

Re: [dev] [dwm] Obtain focused monitor

On 23/01/08 11:32am, Hiltjo Posthuma wrote: > On Sun, Jan 08, 2023 at 07:19:10PM +0900, A Farzat wrote: > > Is there a way to obtain the currently focused monitor in dwm? I want to > > use it in my script to control which monitor gets its brightness > > modified. > > > > Regards, > > Farzat > >

Re: [dev] [dwm] Obtain focused monitor

On Sun, Jan 08, 2023 at 07:19:10PM +0900, A Farzat wrote: > Is there a way to obtain the currently focused monitor in dwm? I want to > use it in my script to control which monitor gets its brightness > modified. > > Regards, > Farzat selmon -- Kind regards, Hiltjo

Re: [dev] [dwm] dmenu dwm wrong screen

On Fri, Oct 28, 2022 at 11:07:44AM +0200, Yan Doroshenko wrote: > Helo, > > > I have a strange behavior of dmenu inside dwm with two monitors. dmenu is > displayed on the screen with the mouse cursor (instead of the active one) if > there are no windows open on any screen. Otherwise it works

Re: [dev] dwm 6.4 bug

NRK writes: > I had bought up this issue in the past and the conclusion was that there > should just be a comment added [0] as users are treated as programmers. > > [0]: https://lists.suckless.org/hackers/2208/18484.html > > - NRK > I should have read the archives before emailing. Thanks for the

Re: [dev] dwm 6.4 bug

> I had bought up this issue in the past and the conclusion was that there > should just be a comment added [0] as users are treated as programmers. > > [0]: https://lists.suckless.org/hackers/2208/18484.html > So be it! :-) A user report is a good reason for adding the comment. -- Best Regards,

Re: [dev] dwm 6.4 bug

On Wed, Oct 26, 2022 at 02:10:19PM +, Tom Schwindl wrote: > However, a length check & truncation > of the last char doesn't seem harmful at all. Thoughts? I had bought up this issue in the past and the conclusion was that there should just be a comment added [0] as users are treated as

Re: [dev] dwm 6.4 bug

Hi, On Tue Oct 25, 2022 at 5:03 PM CEST, spaceman wrote: > Hi, > > While compiling dwm on slackware 15 I get the following (with > _FORTIFY_SOURCE=3): And therein lies the catch. The call to strncpy(3) copies the symbol of the currently selected layout to the layout symbol (ltsymbol) which will

Re: [dev] [dwm]: something like the xfce scale all windows feature

On Thu, Jun 30, 2022 at 01:09:04PM -0800, Britton Kerin wrote: > I've got one of the high-res monitors and everything looks really > tiny. I notec xfce4 has this > "scale everything by 2" feature that addresses this, what's the > easiest way to get this in dwm? > > I didn't see any patch saying

Re: [dev] [dwm]: something like the xfce scale all windows feature

Quoth Britton Kerin: > I've got one of the high-res monitors and everything looks really > tiny. I notec xfce4 has this > "scale everything by 2" feature that addresses this, what's the > easiest way to get this in dwm? You can just make the font bigger in dwm's config.h, and the border size if

Re: [dev] [dwm] Xorg crashed if I ran Pale Moon in dwm

Hi, just don't use version 31, it's just broken IIRC. Compile 29.4.6

Re: [dev] [dwm] Xorg crashed if I ran Pale Moon in dwm

On 22/06/22 01:04, p...@mailbox.org wrote: > > the discussion https://forum.palemoon.org/viewtopic.php?f=3=28505 [ 140.237] Failed to compile FS: 0:1(10): error: GLSL 1.30 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES ^ This is most probably caused by

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

On Tue, May 24, 2022 at 10:06:21PM -0400, Christopher Brown wrote: > I am using the latest git version, so I reverted the commit. However, > I am still experiencing the issue after doing that. > > Christopher > > On Sat, May 7, 2022 at 12:15 PM Hiltjo Posthuma > wrote: > > > > On Fri, May 06,

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

I am using the latest git version, so I reverted the commit. However, I am still experiencing the issue after doing that. Christopher On Sat, May 7, 2022 at 12:15 PM Hiltjo Posthuma wrote: > > On Fri, May 06, 2022 at 10:27:32PM -0400, Christopher Brown wrote: > > Hello, > > > > I have been

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

On Sat 07 May 2022, Yan Doroshenko wrote: > > Not sure if this is of any help, but I was having troubles with DWM on > two monitors as well, one screen was not recognized by DWM. > > A 1 second delay before running my screen layout script was enough to > fix it, here's an explanation: > >

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

On 07.05.22 18:13, Hiltjo Posthuma wrote: On Fri, May 06, 2022 at 10:27:32PM -0400, Christopher Brown wrote: Hello, I have been intermittently encountering an issue where dwm messes up my monitor resolutions when powering on my two monitors. Frequently, both screens will be combined on one

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

On Fri, May 06, 2022 at 10:27:32PM -0400, Christopher Brown wrote: > Hello, > > I have been intermittently encountering an issue where dwm messes up > my monitor resolutions when powering on my two monitors. Frequently, > both screens will be combined on one monitor while the other monitor > does

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

On Fri, May 06, 2022 at 10:27:32PM -0400, Christopher Brown wrote: > Hello, > > I have been intermittently encountering an issue where dwm messes up > my monitor resolutions when powering on my two monitors. Frequently, > both screens will be combined on one monitor while the other monitor > does

Re: [dev] [dwm] Multihead Issues Autostart

On Sun, May 01, 2022 at 06:57:33PM +0200, Yan Doroshenko wrote: > (stupid qustion alert) > > But how can I try, whether my xrandr in autostart works, if I run version > with no autostart patch? > Hi Yan, You don't need a patch to execute something at startup. If you're using startx directly,

Re: [dev] [dwm] Multihead Issues Autostart

On 01.05.22 15:10, Hiltjo Posthuma wrote: On Sun, May 01, 2022 at 12:56:50PM +0200, Yan Doroshenko wrote: Hello, I'm using DWM on two monitors with cool_autostart patch and in the autostart array I'm running xrandr to set the monitor layout. Quite often a situation happens when the second

Re: [dev] [dwm] Multihead Issues Autostart

On Sun, May 01, 2022 at 12:56:50PM +0200, Yan Doroshenko wrote: > Hello, > > > I'm using DWM on two monitors with cool_autostart patch and in the autostart > array I'm running xrandr to set the monitor layout. > > Quite often a situation happens when the second monitor is enabled (arandr >

Re: [dev] [dwm] possible regression in 8806b6e

On Mon, Apr 25, 2022 at 05:38:35PM +0100, Chris Down wrote: > Hiltjo Posthuma writes: > > Whats the similar issue exactly? Does this issue also happen when bisecting > > the > > same commit (so its a also regression)? > > For 8806b6e23793 ("manage: propertynotify: Reduce cost of unused size >

Re: [dev] [dwm] possible regression in 8806b6e

Ethan Marshall writes: Completely fixed. All affected windows now behave as they did before the patch - so, problem solved on my end. Thanks for all your help Chris. Excellent, thanks for getting back. I've submitted it as a proper patch.

Re: [dev] [dwm] possible regression in 8806b6e

Completely fixed. All affected windows now behave as they did before the patch - so, problem solved on my end. Thanks for all your help Chris. Ethan

Re: [dev] [dwm] possible regression in 8806b6e

Hiltjo Posthuma writes: Whats the similar issue exactly? Does this issue also happen when bisecting the same commit (so its a also regression)? For 8806b6e23793 ("manage: propertynotify: Reduce cost of unused size hints"), the issue is that c->isfixed may not be set early, which might affect

Re: [dev] [dwm] possible regression in 8806b6e

* Hiltjo Posthuma [2022-04-25 18:13]: On Mon, Apr 25, 2022 at 04:00:21PM +0200, Jochen Sprickerhof wrote: Hi Chris, * Chris Down [2022-04-25 14:47]: > I'm still unable to reproduce the issue, but I am curious, does this fix > things? :-) > > diff --git a/dwm.c b/dwm.c > index

Re: [dev] [dwm] possible regression in 8806b6e

On Mon, Apr 25, 2022 at 04:00:21PM +0200, Jochen Sprickerhof wrote: > Hi Chris, > > * Chris Down [2022-04-25 14:47]: > > I'm still unable to reproduce the issue, but I am curious, does this fix > > things? :-) > > > > diff --git a/dwm.c b/dwm.c > > index 0fc328a..f2a10c0 100644 > > --- a/dwm.c

Re: [dev] [dwm] possible regression in 8806b6e

Hi Chris, * Chris Down [2022-04-25 14:47]: I'm still unable to reproduce the issue, but I am curious, does this fix things? :-) diff --git a/dwm.c b/dwm.c index 0fc328a..f2a10c0 100644 --- a/dwm.c +++ b/dwm.c @@ -1061,6 +1061,7 @@ manage(Window w, XWindowAttributes *wa)

Re: [dev] [dwm] possible regression in 8806b6e

Hi Ethan, I'm still unable to reproduce the issue, but I am curious, does this fix things? :-) diff --git a/dwm.c b/dwm.c index 0fc328a..f2a10c0 100644 --- a/dwm.c +++ b/dwm.c @@ -1061,6 +1061,7 @@ manage(Window w, XWindowAttributes *wa) XSetWindowBorder(dpy, w,

Re: [dev] [dwm] possible regression in 8806b6e

Just re-ran the bisection and got 8806b6e on both stock dwm and my build. Reverting this commit fixes this change in both. Reverting bece862 has no change in either, so I would assume we can eliminate that commit as the issue. Could this be related to the handling of fixed-size windows? I was

Re: [dev] [dwm] possible regression in 8806b6e

On Sat Apr 23, 2022 at 4:28 AM EDT, Chris Down wrote: > Sebastian LaVine writes: > >I believe this is known unintended behavior from the patch. I reverted it on > >my personal branch. > > It looks like you reverted commit bece862a0fc4 ("manage: For > isfloating/oldstate check/set, ensure trans

Re: [dev] [dwm] possible regression in 8806b6e

Sebastian LaVine writes: I believe this is known unintended behavior from the patch. I reverted it on my personal branch. It looks like you reverted commit bece862a0fc4 ("manage: For isfloating/oldstate check/set, ensure trans client actually exists"), not this commit, right?[0] In which

Re: [dev] [dwm] possible regression in 8806b6e

Hi Ethan, Just checking, are you sure this bisects to 8806b6e23793 ("manage: propertynotify: Reduce cost of unused size hints")? I saw this issue prior to making this patch and bisected to bece862a0fc4 ("manage: For isfloating/oldstate check/set, ensure trans client actually exists"). I

Re: [dev] [dwm] possible regression in 8806b6e

On Sat, Apr 23, 2022 at 12:39:28AM +0100, Ethan Marshall wrote: > Hi all, > > I recently noticed that certain dialog windows (such as the Chromium > system printing dialog and gpg-askpass popups) were being managed as > tiled windows, rather than floating. This changed recently, so I > bisected

Re: [dev] [dwm] possible regression in 8806b6e

I believe this is known unintended behavior from the patch. I reverted it on my personal branch. Original Message From: Ethan Marshall Sent: April 22, 2022 11:39:28 PM UTC To: dev@suckless.org Subject: [dev] [dwm] possible regression in 8806b6e Hi all, I recently noticed

Re: [dev] dwm oddity

Greg and N, thanks. in fact, adding focusonclick, i no longer see the problem (well, so far, but long enough to make me think it is resolved). cheers, Greg

Re: [dev] dwm oddity

On Sun, Apr 03, 2022 at 03:10:48PM -0700, Greg Minshall wrote: > likely, the heel of my palm is making some (light?) contact with the > touch pad. Hi Greg, You could probably try the "focusonclick" patch[0] to confirm your suspicion. I personally use it because I find that feature annoying. But

Re: [dev] dwm oddity

I have not experienced this. On Sun, Apr 3, 2022, at 6:10 PM, Greg Minshall wrote: > hi. i'm using dwm v6.2 under Arch linux. my own source build. i'm > using the "taggrid" patch. my laptop has a touch pad. > > when i am in monocle mode (which i mostly am), every now and then when i > type a

Re: [dev] [dwm] hardcoded dmenucmd && dmenumon

> I agree, some advantage I can think of is it would support on a multi-monitor > support with 10 or more monitors. Otherwise I prefer the current code. I would suggest that the support of 10 or more monitors is not worth the added complexity, given how small the proportion of people will be with

Re: [dev] [dwm] hardcoded dmenucmd && dmenumon

On Thu, Feb 17, 2022 at 11:12:23AM +0100, Страхиња Радић wrote: > On 22/02/17 01:08, NRK wrote: > > Assuming there isn't, one alternative could be just using env vars. > > Why would an environment variable be preferable here to a command line > parameter? > > Environment variables are clunky,

Re: [dev] [dwm] hardcoded dmenucmd && dmenumon

On 22/02/17 01:08, NRK wrote: > Assuming there isn't, one alternative could be just using env vars. Why would an environment variable be preferable here to a command line parameter? Environment variables are clunky, messy, insecure, prone to errors, race conditions and the whims of a particular

Re: [dev] [dwm] hardcoded dmenucmd && dmenumon

On Wed, Feb 16, 2022 at 05:39:14PM +0100, Hiltjo Posthuma wrote: > whats the solution/patch? If there is a "standard" (or at least conventional) way of communicating the active monitor between wm and other X clients then it's probably best to follow that. Assuming there isn't, one alternative

Re: [dev] [dwm] hardcoded dmenucmd && dmenumon

On Wed, Feb 16, 2022 at 05:52:48PM +0600, NRK wrote: > Hi, > > Currently dmenumon and dmenucmd are hardcoded into spawn(), I noticed > this after I removed `dmenumon` (as I don't use multimonitor) from > config.h and saw that the compilation failed. > > if (arg->v == dmenucmd) >

Re: [dev] [dwm] Version bump to 6.3

> Hi, Hello, > Out of curiosity, why the version bump of dwm to 6.3? I haven't seen any > major changes in logs or news. I suppose this depends by what you expect as being a major change. There still have been several changes since the last release from three years ago. Version bumps (as in

Re: [dev] [dwm] default window attaching behaviour

On Wed, Dec 01, 2021 at 12:26:22AM +1000, dther wrote: > and only launch new "temporary" terminals when I need to run and see > the output of a command. If I need an TUI volume mixer or something, > I'd launch it as a tmux window or in floating mode to avoid disturbing > my layout. Hi, You

Re: [dev] [dwm] default window attaching behaviour

Hi, > My tendency is to launch a few "big" programs, most of which can't > easily run in a terminal (a browser, a terminal running tmux and/or an > image editor), and only launch new "temporary" terminals when I need > to run and see the output of a command. If I need an TUI volume mixer > or

Re: [dev] [dwm] default window attaching behaviour

On 21/11/29 01:23PM, Mateusz Okulus wrote: > On 21/11/29 06:25PM, dther wrote: > > I've been thinking about dwm's default behaviours, ,,, > > As you say you launch new programs as you need them. This means the > launched program should have highest priority because you want to use it > right now.

Re: [dev] [dwm] default window attaching behaviour

On 21/11/29 06:25PM, dther wrote: > I've been thinking about dwm's default behaviours, and one of them > that's always confused me is how newly attached windows, by default, > launch as the "master". Why is this the case? Intuitively, when I begin > working, I launch the most important program

Re: [dev] [dwm] dwm breaks on synchronized screens

Hi again, In terms of reproducing this behaviour, all that it seems to take for me is to 'mirror' the screens, optionally with some windows already open, and then try to open/move some more windows. It was relatively consistent so far in that strange things happened pretty quickly. I use lxrandr

Re: [dev] [dwm] dwm breaks on synchronized screens

Hey everyone, I can verify issues with multi-monitor setups when screens are overlapping/mirrored. I usually avoid this by working with independent screens as well. With XINERAMA support in dwm you can dynamically configure monitors via xrandr. If you configure them to coincide, e.g., `xrandr

Re: [dev] [dwm] dwm breaks on synchronized screens

On Thu, 11 Nov 2021 19:34:08 +0100 Thomas Oltmann wrote: Dear Thomas, > What do I do about this? > Is it even a bug or just me using dwm for stuff it's not intended to > do? One way or another, how can I do my presentations without > fighting the WM all the time? do you have a way so we can

Re: [dev] [dwm] Possible bug in resizemouse function

On Sat, Oct 16, 2021 at 10:18:18PM +0800, Xu Lu wrote: > The related code is in line 1326-1332 in dwm.c (current git HEAD): > > if (c->mon->wx + nw >= selmon->wx && c->mon->wx + nw <= selmon->wx + > selmon->ww > && c->mon->wy + nh >= selmon->wy && c->mon->wy + nh <= selmon->wy + >

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

On 21/06/29 03:38PM, Hadrien Lacour wrote: > The point of sxhkd isn't really itself, but having your daemon I/O completely > available through IPC. This is a big advantage, as it allows the most > power/freedom when interacting with it; especially through scripting. But scripting what exactly?

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

By definition, window managers manage windows. So, if I had not tried dwm yet, I would guess that it would not take care of spawning windows. > sxhkd complicates the setup with little additional benefit. That's a fair point. Without noticing it I was assuming that other people also relied on a

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

Splitting of code into separate programs in a lot of cases can create more bloat. Unix philosophy is not the be all end all; you have to weigh the benefits and drawbacks to see where it makes sense. In this case using dwm for all your shortkeys is less bloat than using sxhkd which does a lot more

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

I appreciate the discussion. Jun 29, 2021, 07:04 by quinq@fifth.space: > You are mistaken there, I don't think a software can take pride in > something (here dwm), and the more closer community taking care of it > (suckless) doesn't believe in "keeping its userbase small and elitist". > > On the

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

On Tue, Jun 29, 2021 at 01:48:51PM +0200, Mateusz Okulus wrote: > sxhkd complicates the setup with little additional benefit. The point of sxhkd isn't really itself, but having your daemon I/O completely available through IPC. This is a big advantage, as it allows the most power/freedom when

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

On Tue Jun 29, 2021 at 10:46 AM EDT, wrote: > By definition, window managers manage windows. So, if I had not tried > dwm yet, > I would guess that it would not take care of spawning windows. What world do you live in where the behavior of window managers is to not take care of spawning windows?

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

On 21/06/29 01:16AM, qsm...@tutanota.com wrote: > The existence of the spawn function in dwm surprises me. Wouldn't it > be more consistent with Suckless' values (simplicity, minimalism, > modularity) if the job of spawning commands were relegated to a hotkey > daemon, such as xbindkeys or sxhkd?

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

On 21/06/29 02:04, qsm...@tutanota.com wrote: > However, worded at it is now, I think we will agree that for someone on the > outside it will come out as proud or warding off, whereas something like "we > have no interest in being very popular or trendy; our software will not be > expanded to

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

> […] but dwm takes pride in "keeping its userbase small and elitist, > withoutnovices asking stupid questions". You are mistaken there, I don't think a software can take pride in something (here dwm), and the more closer community taking care of it (suckless) doesn't believe in "keeping its

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

Hi, > The existence of the spawn function in dwm surprises me. Wouldn't it be > more consistent with Suckless' values (simplicity, minimalism, > modularity) if the job of spawning commands were relegated to a hotkey > daemon, such as xbindkeys or sxhkd? The way it is now, the job of handling

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

On 21/06/29 10:03, Martin Tournoij wrote: > > It is true that some people could be driven away after being greeted > > with a black screen without any preconfigured keybinding to open a > > terminal or dmenu, but dwm takes pride in "keeping its userbase small > > and elitist, withoutnovices

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

On Tue, Jun 29, 2021, at 07:16, qsm...@tutanota.com wrote: > The existence of the spawn function in dwm surprises me. Wouldn't it be > more consistent with Suckless' values (simplicity, minimalism, > modularity) if the job of spawning commands were relegated to a hotkey > daemon, such as

Re: [dev] [dwm] Hide window content when moving/resizing windows

On 21/02/10 08:09, Κράκ Άουτ wrote: > resources. So if the if-block is removed you get the opposite of 0/sec. > The if block includes not only the condition "if (/*...*/)", but also the line or a block of code following it, whose execution is controlled by the condition. signature.asc

Re: [dev] [dwm] Hide window content when moving/resizing windows

Στις 10/2/21 4:46 μ.μ., ο/η Страхиња Радић έγραψε: On 21/02/10 01:10, Κράκ Άουτ wrote: So, looking at your code, can I limit updates to 1/sec instead of 60/sec? Changing this line, `if ((ev.xmotion.time - lasttime) <= (1000 / 60))` to `if ((ev.xmotion.time - lasttime) <= (1000 / 1))` would be

Re: [dev] [dwm] Hide window content when moving/resizing windows

On 21/02/10 03:46, Страхиња Радић wrote: > time. The check succeeds if the difference is 1000/60 ~ 17 in the first case > and > 1000 in the second case. As the divisor gets closer to zero, the threshold *is lesser than or equal to signature.asc Description: PGP signature

Re: [dev] [dwm] Hide window content when moving/resizing windows

On 21/02/10 01:10, Κράκ Άουτ wrote: > So, looking at your code, can I limit updates to 1/sec instead of > 60/sec? Changing this line, > `if ((ev.xmotion.time - lasttime) <= (1000 / 60))` > to > `if ((ev.xmotion.time - lasttime) <= (1000 / 1))` > would be enough? > > Can I also achieve 0/sec

  1   2   3   4   5   6   7   8   9   10   >