Re: [dev] [dwm] autoraise floating windows when gaining focus

On 2024-07-25 15:44 Κρακ Άουτ wrote: > On 2024-06-18 14:10 Κρακ Άουτ wrote: > >> On 2024-06-18 13:52 Anthony wrote: >> >>> On 6/18/24 8:25 AM, Κρακ Άουτ wrote: Hello to all, >>> >>> Hi. >>> I'd like to autoraise floating windows when gaining focus. The current behaviour

Re: [dev] [dwm] autoraise floating windows when gaining focus

On 2024-06-18 14:10 Κρακ Άουτ wrote: > On 2024-06-18 13:52 Anthony wrote: > >> On 6/18/24 8:25 AM, Κρακ Άουτ wrote: >>> Hello to all, >> >> Hi. >> >>> I'd like to autoraise floating windows when gaining focus. The >>> current behaviour is, windows gets focus on mouse pointer hover, >>> but

Re: [dev] [dwm][st] why use ints over bools?

On Fri, 21 Jun 2024 23:29:29 +0200 Storkman wrote: > On Fri, Jun 21, 2024 at 10:12:15PM +0200, Mattias Andrée wrote: > > On Fri, 21 Jun 2024 21:14:19 +0200 > > Markus Wichmann wrote: > > > > > Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић: > > > > Given that, why

Re: [dev] [dwm][st] why use ints over bools?

În 22 iunie 2024 00:10:52 EEST, "Страхиња Радић" a scris: >Дана 24/06/21 09:14PM, Markus Wichmann написа: >> Isn't it all about familiarity in the end? Or can you articulate what >> parts of C11 and C23 you find objectionable? > >Just a few examples: > >- C11: bounds checking interfaces (now

Re: [dev] [dwm][st] why use ints over bools?

On Fri, Jun 21, 2024 at 10:12:15PM +0200, Mattias Andrée wrote: > On Fri, 21 Jun 2024 21:14:19 +0200 > Markus Wichmann wrote: > > > Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић: > > > Given that, why complicate code by introducing a separate, superfluous, > > > type? > > >

Re: [dev] [dwm][st] why use ints over bools?

Дана 24/06/21 09:14PM, Markus Wichmann написа: > Let me offer a counterpoint: Expressiveness. If I make a function return > a bool, then everyone from the world's worst junior dev to Ken Thompson > himself will be able to see at the very first glance that the function > is returning a boolean

Re: [dev] [dwm][st] why use ints over bools?

On Fri, 21 Jun 2024 21:14:19 +0200 Markus Wichmann wrote: > Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић: > > Given that, why complicate code by introducing a separate, superfluous, > > type? > > Let me offer a counterpoint: Expressiveness. If I make a function return > a

Re: [dev] [dwm][st] why use ints over bools?

Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић: > Given that, why complicate code by introducing a separate, superfluous, > type? Let me offer a counterpoint: Expressiveness. If I make a function return a bool, then everyone from the world's worst junior dev to Ken Thompson

Re: [dev] [dwm][st] why use ints over bools?

Дана 24/06/20 10:24PM, sewn написа: > Sure, but why? It is part of the suckless coding style. Since st is a suckless project, it follows the suckless coding style. * * * I can't speak for those who wrote the suckless coding standard, but as a bystander, I can give this observation. If the

Re: [dev] [dwm][st] why use ints over bools?

On 2024-06-15 22:06, Страхиња Радић wrote: Дана 24/06/15 11:54AM, Zac написа: I'm curious why you use ints though. Because bools are 31 bits smaller than ints, which is 31 bits of memory saved. Not that 31 bits is very much, but still... https://suckless.org/coding_style/ Tests and

Re: [dev] [dwm] autoraise floating windows when gaining focus

On 2024-06-18 13:52 Anthony wrote: > On 6/18/24 8:25 AM, Κρακ Άουτ wrote: >> Hello to all, > > Hi. > >> I'd like to autoraise floating windows when gaining focus. The >> current behaviour is, windows gets focus on mouse pointer hover, but >> needs modkey press + left button mouse click to

[dev] [dwm] autoraise floating windows when gaining focus

Hello to all, I'd like to autoraise floating windows when gaining focus. The current behaviour is, windows gets focus on mouse pointer hover, but needs modkey press + left button mouse click to raise. I searched but did not locate any such patch. Is there perhaps, or could you give me any

Re: [dev] [dwm][st] why use ints over bools?

Am Sat, Jun 15, 2024 at 06:10:50PM +0200 schrieb Vincent Lefevre: > IMHO, this has been poorly designed. There should have been a macro > taking a parameter N (an integer constant expression), where the > type would have been valid for any N up to the maximum width (thus > at least 64). For

Re: [dev] [dwm][st] why use ints over bools?

> There should have been a macro taking a parameter N (an integer > constant expression), where the type would have been valid for any N > up to the maximum width (thus at least 64). For portability, the > existence of the macro could have also been tested with #ifdef, > allowing a fallback. I

Re: [dev] [dwm][st] why use ints over bools?

On Sat, 15 Jun 2024 16:16:14 +0200 Mattias Andrée wrote: > You will save between 0 and 3 bytes on common platforms, > and those 3− bytes will probably be allocated and wasted anyway. > Is it worth it? > > It's absolutely better than _Bool, but I don't think there > is any point in using char

Re: [dev] [dwm][st] why use ints over bools?

Дана 24/06/15 11:54AM, Zac написа: > I'm curious why you use ints though. Because bools are 31 bits smaller than > ints, which is 31 bits of memory saved. Not that 31 bits is very much, but >still... https://suckless.org/coding_style/ > Tests and Boolean Values > > * Do not use C99 bool types

Re: [dev] [dwm][st] why use ints over bools?

On 2024-06-15 16:24:38 +0200, Mattias Andrée wrote: > No, you should use [u]int_least1_t, except that probably doesn't > exist, So, you must not use it. :) On the opposite, int_least8_t is a *required* type in ISO C99+. That's why I've proposed it. > I think C actually should add some what to

Re: [dev] [dwm][st] why use ints over bools?

No, you should use [u]int_least1_t, except that probably doesn't exist, so char is best as it is per definition the most narrow type, and if the signness is important you can specify it. I think C actually should add some what to specify [u]int_{least,fast}N_t for arbitrary N. It could be simple

Re: [dev] [dwm][st] why use ints over bools?

You will save between 0 and 3 bytes on common platforms, and those 3− bytes will probably be allocated and wasted anyway. Is it worth it? It's absolutely better than _Bool, but I don't think there is any point in using char over int. All common operations (this may exclude division and modulo)

Re: [dev] [dwm][st] why use ints over bools?

On 2024-06-15 17:05:27 +0300, stefan1 wrote: > What about using char's then? char may be signed or unsigned. I would suggest unsigned char or signed char, or better, (u)int_least8_t. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Re: [dev] [dwm][st] why use ints over bools?

What about using char's then? În 15 iunie 2024 15:36:16 EEST, "Mattias Andrée" a scris: >I have some general issues with _Bool: > >Arithmetic or bitwise operations on _Bool is subject to type promotion >making them rather pointless. > >With also be a problem if they were not, as you than

Re: [dev] [dwm][st] why use ints over bools?

I have some general issues with _Bool: Arithmetic or bitwise operations on _Bool is subject to type promotion making them rather pointless. With also be a problem if they were not, as you than couldn't sum of _Bool's to find how many were set (commonly this we be to detect if more than 1 was

Re: [dev] [dwm][st] why use ints over bools?

On Sat 15 Jun 2024, Zac wrote: > > In a number of spots in dwm and st I've seen the use of integers as booleans. > e.g. > - dwm.c line 95, 140, 1870 > - drw.c line 252 > - st.c line 44, 48 > > That's not an extensive list; just some examples. > > I'm curious why you use ints though. Because

[dev] [dwm][st] why use ints over bools?

In a number of spots in dwm and st I've seen the use of integers as booleans. e.g. - dwm.c line 95, 140, 1870 - drw.c line 252 - st.c line 44, 48 That's not an extensive list; just some examples. I'm curious why you use ints though. Because bools are 31 bits smaller than ints, which is 31 bits

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

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

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 in the master area take up the full height of the display. In the

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

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

Hello. I want to share my patch that I have been using for couple months that simplifies reconfiguring of the dwm. It adds function to execute into another executable, be it another build of dwm or another window manager. I have following lines in `dwm.h': static const char *dwmcmd[] =

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

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

Greetings, 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-- I'd like to make it actually transfer the terminal's focus rather than async open and hide itself. That way you get

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

[dev] [dwm] DWM Multihead Missing Cursor

Hello, I have a strange thing going on with the mouse cursor in DWM. When I move the cursor to another screen right after DWM starts, the cursor just disappears. It comes back if a window is created on that screen. Does anyone know what might be the cause? Ways to reproduce on the master

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

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

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 here, is this a regression or bug introduced with this commit or

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 >

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

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 -march=x86-64-v3 or v2. Is there any point adding them? Related, would -O2

[dev] [dwm] Set input focus to barwin on empty monitors

I sent this email two weeks ago over the weekend to no reply. I'm sending it again now (just in case the timing was bad last time). Stein wrote in the commit message of commit c2b748e: > The edge case scenario that dmenu does not handle on its own, and the > effect of removing this mechanism, is

[dev] [dwm] Set input focus to barwin on empty monitors

Stein wrote in the commit message of commit c2b748e: > The edge case scenario that dmenu does not handle on its own, and the > effect of removing this mechanism, is that if the user trigger > focusmon via keybindings to change focus to another monitor that has > no clients, then dmenu will open on

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

[dev] [dwm] Bluetooth XF86 keys not working

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 output which shows the two keys are slightly different

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

On January 16, 2023 11:21:57 AM UTC, A Farzat wrote: >Btw, on the email subject it says [SPAM Warning!]. Is it anything I need >to be concerned with? Spam filters hate the .xyz TLD because it's supposedly "frequently used by spammers". I don't know why single out that one in particular, but

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: [SPAM Warning!][dev] [dwm] view() and toggleview() functions

On 23/01/16 12:10pm, NRK wrote: > On Sun, Jan 15, 2023 at 06:28:55PM +0900, A Farzat wrote: > > 2- In the view() function, there is this line: > > ```c > > selmon->seltags ^= 1; /* toggle sel tagset */ > > ``` > > What is the purpose of this line? In fact, what is the purpose of having > > two

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

On Sun, Jan 15, 2023 at 06:28:55PM +0900, A Farzat wrote: > 2- In the view() function, there is this line: > ```c > selmon->seltags ^= 1; /* toggle sel tagset */ > ``` > What is the purpose of this line? In fact, what is the purpose of having > two tagsets in the first place? From what I see, all

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

I am trying to modify dwm so that the tags on all monitors are synced. Basically something like the [switch all monitor tags patch](http://dwm.suckless.org/patches/switch_all_monitor_tags/) but more extreme. It is simple to implement but I wanted to make sure of two things first: 1- In the view()

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

[dev] [dwm] Obtain focused monitor

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 signature.asc Description: PGP signature

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

[dev] [dwm] dmenu dwm wrong screen

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 fine. Is this expected behavior? Thanks, Yan OpenPGP_signature

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

[dev] dwm 6.4 bug

Hi, While compiling dwm on slackware 15 I get the following (with _FORTIFY_SOURCE=3): In file included from /usr/include/string.h:519, from dwm.c:29: In function 'strncpy', inlined from 'arrangemon' at dwm.c:400:2, inlined from 'arrange' at dwm.c:394:3, inlined from

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

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

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 it does it, might have missed one though there are so many now :)

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

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

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 not receive input. The "Two independent outputs" section of the multi monitor

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 >

[dev] [dwm] Multihead Issues Autostart

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 displays it as active and in correct position, feh sets the background on it),

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

[dev] [dwm] Window mapping

Hello, I'd like to submit the following patch to the list of dwm patches, but before that I thought I could gather some comments and see if it could be improved in any way. The basic goal is, instead of moving windows out of sight, to do proper window (un)mapping in order for some external

  1   2   3   4   5   6   7   8   9   10   >