Re: [dev] [dwm] New software: swm & infobar

On 24/11/05 10:55AM, Jeremy wrote: > > I had a look at your bar program. So it has background scripts that > > output to files independently and depends on inotify to wait for updates. > > One of my first ideas of infobar is the same in essence, but with > > scripts writing to FIFOs instead of fil

Re: [dev] [dwm] New software: swm & infobar

On 11/05/24 08:34AM, Raymond Cole wrote: > On second thought, I think that's awful in terms of readability so I've > just renamed it "button". I may have been hallucinating, but when I saw "butt...tock" it occured to me that it was clearly the opposite of a tick-tok in a butt/tick duality. I can

Re: [dev] [dwm] New software: swm & infobar

On 24/11/04 12:06AM, Jeremy wrote: > I like this > if [ "$butt" -eq 1 ]; then > My terrible humor LOL. On second thought, I think that's awful in terms of readability so I've just renamed it "button". > I did my bar a similar way, except each widget is a script responsible for > its own formatt

Re: [dev] [dwm] New software: swm & infobar

On 10/25/24 08:11AM, Raymond Cole wrote: > May someone check them out and share opinions? > I like this if [ "$butt" -eq 1 ]; then I did my bar a similar way, except each widget is a script responsible for its own formatting, like: mpc status -f '%artist% ~ %title%' | if read -r song && read -r

Re: [dev] [dwm] New software: swm & infobary

Raymond Cole wrote in : ... |Also look at infobar (nothing to do with Alex Jones, seriously). Read its |README about what it provides, and compare that to the fact that it's |a shell script under 400 lines, isn't it surprisingly small? And its |internal working is all about pipes and corpor

Re: [dev] [dwm] Discuss my new software

On 24/10/27 10:50AM, Страхиња Радић wrote: > Дана 24/10/27 09:21AM, Raymond Cole написа: > > common among you > > Among who? As stated, I am just a user and enthusiast of suckless > software. > I was talking to suckless developers there. Sorry. > > the overall unwelcoming atmosphere that I've

Re: [dev] [dwm] Discuss my new software

Дана 24/10/27 09:21AM, Raymond Cole написа: > common among you Among who? As stated, I am just a user and enthusiast of suckless software. > the overall unwelcoming atmosphere that I've perceived here? If so, > may you reconsider your responses after this clarification? Excuse me for being si

Re: [dev] [dwm] Discuss my new software

On 24/10/27 09:17AM, Страхиња Радић wrote: > Дана 24/10/27 03:07AM, Raymond Cole написа: > > It seems like you get the impression that I want suckless to host my > > projects? I never requested that. > > Apologies, you are correct. The subject of the thread might be > misleading like that; at le

Re: [dev] [dwm] New software: swm & infobary

Дана 24/10/27 03:07AM, Raymond Cole написа: > I see that you linked to Luke Smith's website in another email, so it > looks like you know him. That guy really helped popularize suckless > software, didn't he? In fact, he's the way I knew suckless. Maybe you > have not noticed but the features th

Re: [dev] [dwm] New software: swm & infobary

NRK writes: > Come on, Chris. The conditions dwm's license imposes is "The above > copyright notice and this permission notice shall be included", not > "Exactly what parts are copied and their authorship shall be indicated" > or whatever. (Or if you are giving that as a condition for granting

Re: [dev] [dwm] New software: swm & infobary

On 24/10/26 09:15PM, Страхиња Радић wrote: > The main question that I, as a user, have is: what does a program do, > what is its main function? If it overlaps with some other program, the > second thing I am asking is: what does it do better? And, having in > mind the suckless philosophy, the fo

Re: [dev] [dwm] New software: swm & infobar

On 24/10/25 08:24PM, Страхиња Радић wrote: > This has already been discussed: > > https://lists.suckless.org/dev/2306/35253.html > > and > > https://lists.suckless.org/dev/2306/35258.html > > In other words, when you license a work under GPL, you license **the > whole work** under GPL. You can

Re: [dev] [dwm] New software: swm & infobary

It would be nice to hear an explanation, why swm? What are its advantages over dwm? What are its flaws? Why should we try it? Why making patches to dwm wasn't enough and you decided to fork it? On 25/10/2024 13:41, Raymond Cole wrote: > On 24/10/25 12:55PM, Hiltjo Posthuma wrote: > > On Fri, Oc

Re: [dev] [dwm] New software: swm & infobary

Дана 24/10/26 04:07PM, Jeffrey Picard написа: > Fuck GPL That is a political opinion. My own opinion re: GPL vs [insert "lax" license here], while irrelevant to this thread, is that a stricter (in a way) license is better in making sure the freedom is not taken away by malicious proprietary compan

Re: [dev] [dwm] New software: swm & infobary

On 10/25/24 14:39, Andrey Dobrovolsky wrote: пт, 25 жовт. 2024 р. о 21:40 Страхиња Радић пише: Дана 24/10/25 04:40PM, Andrey Dobrovolsky написа: Soon 14701 act by US government will be applied to all GPL licensed software. Any references to whatever that is? Web search doesn't seem to retur

Re: [dev] [dwm] New software: swm & infobary

Disclaimer: I am just a suckless software user and enthusiast. Дана 24/10/26 05:57AM, Raymond Cole написа: > I suggest considering swm as a new project that borrows code from > dwm. [...] > Finally, has anyone actually looked at things of my projects other than > the license? The main question t

Re: [dev] [dwm] New software: swm & infobary

Дана 24/10/25 09:39PM, Andrey Dobrovolsky написа: > First of all I need to apologize for mentioning the wrong number > (sorry!), the right is Executive Order 14071 (oops) and describes > sanctions against Russian Federation. The use case was banning of 11 > developers from RF from Linux Kernel main

Re: [dev] [dwm] New software: swm & infobary

пт, 25 жовт. 2024 р. о 21:40 Страхиња Радић пише: > > Дана 24/10/25 04:40PM, Andrey Dobrovolsky написа: > > Soon 14701 act by US government will be applied to all GPL licensed > > software. > > Any references to whatever that is? Web search doesn't seem to return > anything relevant here. > Hi Стр

Re: [dev] [dwm] New software: swm & infobary

On 24/10/26 12:56PM, Chris Down wrote: > Restore the Git history, or violate the license: it's as simple as that. > Prove it.

Re: [dev] [dwm] New software: swm & infobary

> > Come on, Chris. The conditions dwm's license imposes is "The above > > copyright notice and this permission notice shall be included", not > > "Exactly what parts are copied and their authorship shall be indicated" > > or whatever. (Or if you are giving that as a condition for granting > > re

Re: [dev] [dwm] New software: swm & infobary

Raymond Cole writes: Come on, Chris. The conditions dwm's license imposes is "The above copyright notice and this permission notice shall be included", not "Exactly what parts are copied and their authorship shall be indicated" or whatever. (Or if you are giving that as a condition for granting

Re: [dev] [dwm] New software: swm & infobary

On 24/10/25 05:03PM, Chris Down wrote: > Raymond Cole writes: > > My bad. I thought of that notice as transitional so didn't treat it > > very rigorously. I've updated swm to meet the requirement. > > > > I realize that the previous deal of including that piece of notice > > in exchange of relic

Re: [dev] [dwm] New software: swm & infobary

Дана 24/10/25 04:40PM, Andrey Dobrovolsky написа: > Soon 14701 act by US government will be applied to all GPL licensed > software. Any references to whatever that is? Web search doesn't seem to return anything relevant here.

Re: [dev] [dwm] New software: swm & infobar

Дана 24/10/25 08:11AM, Raymond Cole написа: > By the way, I license swm under GPL, and clarify in source files that > portions of code that come from dwm are still licensed the same as dwm. > I think it would be neater if I could relicense dwm derived code under > GPL, but for that I need permissio

Re: [dev] [dwm] New software: swm & infobary

Greetings for team and all the developers! It is my first message and I'm sorry it carries a kind of warning. Soon 14701 act by US government will be applied to all GPL licensed software. Appending all dwm developers to the list of authors of some GPL licensed software may have unattended conseque

Re: [dev] [dwm] New software: swm & infobary

Raymond Cole writes: My bad. I thought of that notice as transitional so didn't treat it very rigorously. I've updated swm to meet the requirement. I realize that the previous deal of including that piece of notice in exchange of relicensing might be considered quite insufficient by you guys.

Re: [dev] [dwm] New software: swm & infobary

On 24/10/25 12:55PM, Hiltjo Posthuma wrote: > On Fri, Oct 25, 2024 at 08:11:28AM +, Raymond Cole wrote: > > Hello developers, > > > > I made a new window manager and an accompanying status program: > > > > https://wolog.xyz/repos/swm > > https://wolog.xyz/repos/infobar > > > > May someone ch

Re: [dev] [dwm] New software: swm & infobary

On Fri, Oct 25, 2024 at 08:11:28AM +, Raymond Cole wrote: > Hello developers, > > I made a new window manager and an accompanying status program: > > https://wolog.xyz/repos/swm > https://wolog.xyz/repos/infobar > > May someone check them out and share opinions? > > I am an undergraduate ma

[dev] [dwm] New software: swm & infobar

Hello developers, I made a new window manager and an accompanying status program: https://wolog.xyz/repos/swm https://wolog.xyz/repos/infobar May someone check them out and share opinions? I am an undergraduate majoring in math and I am about to apply to computer-related graduate programs. swm

Re: [dev] [dwm/dmenu] question on dmenu

Hiltjo Posthuma wrote in : |On Thu, Sep 12, 2024 at 05:44:22AM +0200, Steffen Nurpmeso wrote: |> Ok, sorry, but one final (hopefully) question. |> |> dmenu_run does "xy | /bin/sh &". |> Like this the thing then is owned by PID 1. |> I use (instead of dmenu_run) ... |> exec ${SHELL:-"/bi

Re: [dev] [dwm/dmenu] question on dmenu

On Thu, Sep 12, 2024 at 05:44:22AM +0200, Steffen Nurpmeso wrote: > Ok, sorry, but one final (hopefully) question. > > dmenu_run does "xy | /bin/sh &". > Like this the thing then is owned by PID 1. > I use (instead of dmenu_run) > > : ${LINES:=30} > cmd=$(<< '_EOT' dmenu -l $((LINES - LINES/1

[dev] [dwm/dmenu] question on dmenu

Ok, sorry, but one final (hopefully) question. dmenu_run does "xy | /bin/sh &". Like this the thing then is owned by PID 1. I use (instead of dmenu_run) : ${LINES:=30} cmd=$(<< '_EOT' dmenu -l $((LINES - LINES/10)) "$@" # Browse /bin/sh -c 'touch /run/user/$(id -u)/box-browse/root/#' do

[dev] [dwm] X11/XF86keysym.h is not available

Hello. ..and isn't that mysterious, do you all live without any accessibility to these media keys in dwm? I have written XF86 media key spawn hook.. This will invoke xf86cmd with the name of the key, for example XF86AudioMute, as an argument, for any key that adheres to * XFre

Re: [dev] [dwm] execwm(), ie, self?

Andy Gozas wrote in : |On 2024-09-10 10:32 AM, Jakub Bystron wrote: |> On Tuesday, September 10th, 2024 at 00:51, Steffen Nurpmeso |> wrote: |>> |>> But, hey, one thing. I go totally insane with how the terminal |>> window is shown in the "fullscreen" layouts. It is so that the st |>> in

Re: [dev] [dwm] execwm(), ie, self?

On 2024-09-10 10:32 AM, Jakub Bystron wrote: On Tuesday, September 10th, 2024 at 00:51, Steffen Nurpmeso wrote: But, hey, one thing. I go totally insane with how the terminal window is shown in the "fullscreen" layouts. It is so that the st instance has 55 lines and 191 columns here, then, b

Re: [dev] [dwm] execwm(), ie, self?

On Tuesday, September 10th, 2024 at 00:51, Steffen Nurpmeso wrote: > > But, hey, one thing. I go totally insane with how the terminal > window is shown in the "fullscreen" layouts. It is so that the st > instance has 55 lines and 191 columns here, then, but this does > not suffice to be really

Re: [dev] [dwm] execwm(), ie, self?

Steffen Nurpmeso wrote in <20240908015543._UGvRyF0@steffen%sdaoden.eu>: ... |Btw despite possible misunderstandings and total lack of |experience i have | | {MODKEY|ControlMask,XK_numbersign,incnmaster,{.i=+1}}, | {MODKEY|ControlMask|ShiftMask,XK_numbersign,incnmaster,{.i=-1}}, | |and fi

Re: [dev] [dwm] execwm(), ie, self?

Steffen Nurpmeso wrote in <20240907014632.jhrnO-iG@steffen%sdaoden.eu>: ... |What do you think of another accessible function, like (draft) ... |+execwm(const Arg *arg) |+{ |+ setsid(); |+ execvp(((char **)arg->v)[0], (char **)arg->v); |+ fprintf(stderr, "dwm: execvp wm '%s' fa

[dev] [dwm] execwm(), ie, self?

Hello, i am in the process of switching to dwm+dmenu after many years of cwm, it is hard, thank you, because of sxmo that i am looking forward for, some day. What do you think of another accessible function, like (draft) diff --git a/dwm.c b/dwm.c index 67c6b2bc6d..ca21a89098 100644 --- a/dwm.c +

Re: [dev] [DWM] Executing command from keybindings

When i put "export TERMINAL=alacritty" to .profile file it worked. Thanks for helping. Bu ileti Proton Mail güvenli e-posta hizmetiyle gönderilmiştir. Burak , 5 Eylül 2024 Perşembe saat 21:03 tarihinde şunu yazdı: > I just testing it, didn't think "i must export variable before dwm start". I

Re: [dev] [DWM] Executing command from keybindings

I just testing it, didn't think "i must export variable before dwm start". I just build dwm, launch it and then export variable. I have no reason for putting export to .profile file. I will try that, thanks for helping. Bu ileti Proton Mail güvenli e-posta hizmetiyle gönderilmiştir. Robert

Re: [dev] [DWM] Executing command from keybindings

Is there any reason you don't include that in your .profile? For dwm to see that variable it'd need to be set before dwm is started. Setting the variable in the terminal does not affect dwm's environment, even if you use export. -- Robert Bilski

Re: [dev] [DWM] Executing command from keybindings

I just open the terminal and write "TERMINAL=alacritty", that's it. Nothing added to .xinitrc or shell's profile file. I export the variable just like you said but it still doesn't work. Does "SHCMD ("$TERMINAL -e btop")" command is right command for that thing, maybe the problem is that code.

Re: [dev] [DWM] Executing command from keybindings

Hello, On Thu Sep 5, 2024 at 3:15 PM CEST, Burak wrote: > i set TERMINAL=alacritty by-hand What do you mean exactly? Where are you setting exactly, and how? If you are setting it in your .profile, make sure to source that. If yoy are setting it in your .xinitrc, do so also, etc. Basically: you mu

[dev] [DWM] Executing command from keybindings

Hi, i want to execute TUI programs from keybinding but they work on background instead of showing on terminal. I tried putting "SHCMD ("$TERMINAL -e btop")" to keybinding, i set TERMINAL=alacritty by-hand, but terminal nor btop did not work. How can i launch TUI apps from terminal?

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 is

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 complicat

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 e

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 value

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 bo

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 himsel

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 que

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 Boole

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 rais

[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 advic

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 portabi

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 don

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 ove

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 sp

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 a

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) sup

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 couldn't

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 set)

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 boo

[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 co

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 it

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 i

[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 stackin

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 inv

[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 exec

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 w

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 func

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 use

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 i

[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 v

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 > > h

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) close

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

On 08.04.23 23:43, Страхиња Радић wrote: > 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). > I tried t

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 her

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 *dmenu_exten

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 in

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 = dmenu_extend

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 r

[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 dmenu_extended

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 -DVERSION=\"${VERSION}

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: > https://git.suckless.org/dwm/commit/712d6639ff8e863560328131

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 | SA_R

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 -march=x

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 s

  1   2   3   4   5   6   7   8   9   10   >