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

[Raymond Cole]

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 and infobar are fruits of my
recent years' devotion to software freedom, and I hope they can be an
important part of my applications. So I am seeking your opinions in
the hope of proving my works' value.

The README of swm is a little long, but you can skip to the "Layout
Description Language" section and see if that interests you. And don't
overlook infobar.

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 permission from dwm developers. Once given
the permission, I will put the following to source files:

> Based in part on dwm, as developed by Anselm R. Garbe et al. Permission
> to distribute dwm derived code under the GNU General Public License
> has been granted, provided that this notice is retained.

So, dwm developers, how do you like it? Do I need to get permissions
from all of you listed in dwm's LICENSE file, or maybe someone can act
as a representative?

Looking forward to your responses.

Kind regards,
Raymond Cole

[Hiltjo Posthuma]

Please include the LICENSE, also see the part:

"The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software."

The current license _reference_ is insufficient. The license text must be
included.

The licenses suckless use are very permissive already, please satisfy these
small requirements.

Thanks,

--
Kind regards,
Hiltjo

[Raymond Cole]

Hi Hiltjo,

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. Here's another deal: I copy the names from dwm's MIT LICENSE
file to swm's GPL LICENSE file, append my name to it and, in source files,
reference the LICENSE file for copyright details. What do you think?

Kind regards,
Raymond

[Chris Down]

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. Here's another deal: I copy the names from dwm's MIT LICENSE
>file to swm's GPL LICENSE file, append my name to it and, in source files,
>reference the LICENSE file for copyright details. What do you think?

Neither this nor your previous implementation are sufficient. You must maintain
all authoring information in the Git commit history, since:

1. The LICENSE file authors list is not exhaustive;
2. Even if it was, it's not clear which parts are from dwm;
3. In MIT, authors retain copyright over their individual contributions;
4. Erasing Git history conceals authorship, which is a license violation.

The Git history reflects each contributor's authorship, which must remain
intact to honour the MIT license requirements.

Please restore the entire Git changelog history and apply your changes on top.
Only then can you incorporate your GPL additions in a compliant way.

[Andrey Dobrovolsky]

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 consequences for them later
in the future. I'm not a lawyer but want to warn.

Best regards and huge thanks for dwm, st, dmenu and other precise software!

--jazzbiker

пт, 25 жовт. 2024 р. о 16:42 Raymond Cole <r...@wolog.xyz> пише:

[Страхиња Радић]

Дана 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 permission from dwm developers. Once given
> the permission, I will put the following to source files:
>
> > Based in part on dwm, as developed by Anselm R. Garbe et al. Permission
> > to distribute dwm derived code under the GNU General Public License
> > has been granted, provided that this notice is retained.

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 cannot mix and match licenses. All the
licenses of other parts must be "compatible" with the GPL in order for
you to do so. What this means is that they must allow changing the
license to GPL. As Marcus stated:

> bar, Copyright Markus Wichmann, released under the terms of the GPL,
> see file COPYING. Based on foo, Copyright Hiltjo Posthuma, released
> under the terms of the MIT license, see file COPYING.foo.

I have applied this in my programs using termbox library, for example:

https://git.sr.ht/~strahinja/sled/tree/07daabdf9467ae8110f0b6cd2ec3aebc675c65bb/item/termbox.h

> This file is based on the termbox2 TUI library, (c) 2021 termbox
> developers.
>
> License notice from the original termbox2.h from the termbox2
> repository follows:

and then I include the entire text of the Expat ("MIT") license,
fulfilling the terms of that license, while having my program **as a
whole** licensed under GPL.

However, the issue might arise from the term "substantial" and its
interpretation. I believe that in the case of my programs using the
termbox library it is clear that the library is not a substantial part
of my program, and vice versa. In the case of hacked dwm, I'm not so
sure.

[Страхиња Радић]

Дана 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.

[Raymond Cole]

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
relicensing permission, make it clear.)

And since copied dwm's code has been completely refactored and reordered,
even if I could include the git changelog, tracing down the original
authorship of a piece of code wouldn't be made simpler than by comparing
with dwm's code, anyway. By the way, I didn't intentionally conceal
the git history of swm, I simply developed swm without using git.

I suggest considering swm as a new project that borrows code from dwm.
You see, if you exclude drw.c (for which I don't mind retaining the
original dwm license if required), about 50% of the code is completely
original, and another 30% percent was originally based on dwm's code but
modified enough that it could just as well be original. Must a project
that borrows code from dwm include dwm's entire git history?

Anyway. I am not asking dwm developers about how to handle dwm's license
approperiately, my problem is under what condition could you people grant
me the permission to relicense dwm derived code under GPL? What I've
offered was to give you dwm developers not less attributions to swm than
what dwm's MIT license requires. What's your answer to this?

Finally, has anyone actually looked at things of my projects other than
the license?

[Chris Down]

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
>relicensing permission, make it clear.)

Please learn how MIT licensing works.

>I suggest considering swm as a new project that borrows code from dwm.
>You see, if you exclude drw.c (for which I don't mind retaining the
>original dwm license if required), about 50% of the code is completely
>original, and another 30% percent was originally based on dwm's code but
>modified enough that it could just as well be original. Must a project
>that borrows code from dwm include dwm's entire git history?

This isn't a negotiation. License compliance isn't a matter of "sufficiency" by
your terms. Restore the Git history, or violate the license: it's as simple as
that.

[Raymond Cole]

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.

[NRK]

> > 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
> > relicensing permission, make it clear.)
>
> Please learn how MIT licensing works.

> [...]

> Restore the Git history, or violate the license: it's as
> simple as that.

I am of course open to being corrected, but AFAIK there's no requirement
to keep git history. Only requirement is to keep the license
file/notice.

Indeed there are still open source projects which do not even use git
(or any version control for that matter). And if git history was
required then the tarballs distributed in suckless.org would also
violate the license.

As for not every contributors being listed in the license file, that's
on the upstream authors. The license imposes no legal requirement for
someone who's copying it to hunt down and correct/list missing author
notices.

- NRK

[Andrey Dobrovolsky]

пт, 25 жовт. 2024 р. о 21:40 Страхиња Радић <s...@strahinja.org> пише:

Hi Страхиња Радић,

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 maintainers list. Linux is
developed under GPL 2.0 and here we can observe the case of applying
the restrictions not mentioned in the license itself. GPL itself looks
like acknowledged and running under US jurisdictions, and the fact
raise concerns that any GPL-licensed software may one fine day be
affected in some way with this or another politically-driven
restrictions.

Regards!
--jazzbiker

[Страхиња Радић]

Дана 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 maintainers list. Linux is
> developed under GPL 2.0 and here we can observe the case of applying
> the restrictions not mentioned in the license itself. GPL itself looks
> like acknowledged and running under US jurisdictions, and the fact
> raise concerns that any GPL-licensed software may one fine day be
> affected in some way with this or another politically-driven
> restrictions.

Like you said, that is not something that is the consequence of the
terms of GNU GPL. The idea of GNU GPL is to ensure the four freedoms
for all the users of software.

See here, for example:

https://www.gnu.org/philosophy/free-sw.en.html#exportcontrol

> Sometimes government export control regulations and trade sanctions
> can constrain your freedom to distribute copies of programs
> internationally. Software developers do not have the power to
> eliminate or override these restrictions, but what they can and must
> do is refuse to impose them as conditions of use of the program.

and thus GPL was exempt from such clauses.

I think the issue is with the laws of a particular country the primary
copyright holder is physically in (I believe Mr. Torvalds is living in
the USA). This is the reason Theo de Raadt, primary developer of
OpenBSD, lives in Canada, which has more lax restrictions on the export
regulations, allowing OpenBSD to include more sophisticated security
mechanisms than it would be possible were he a resident of USA.

[Страхиња Радић]

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 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 following questions:

- Is it more minimal?
- Does it follow Unix philosophy:
- Is it focused in what it does?
- Is it fulfilling its purpose well?
- Does it work well with other programs?

By taking a brief look at swm, I find that it is more complicated than
dwm. If we forget all the details, just the rudimentary

$ cd swm
$ wc -l *.[ch] | tail -1
4450 total
$ cd ../dwm
$ wc -l *.[ch] | tail -1
2871 total

shows that dwm beats swm in SLoC count. Less is more.

"Layout description language", while interesting academically, as a
research project at the university, doesn't have much practical value
to me as a user. The way I'm using dwm is such that perhaps 80% of the
time I'm using the "tile" layout, and 20% of the time I switch to
"monocle" layout, and that's enough to be efficient. I don't feel the
need to even use the "rules" array in stock dwm, I am arranging windows
in tags manually, using the MODKEY+Shift+<N> keys and switching to tags
using MODKEY+<N>.

In particular, I don't see the need to have multiple programs with
overlapping functionality as part of the official suckless software
"suite". I'm fine using dwm and slstatus, thanks. I apply patches I
choose and set my config.h the way it suits me.

What I would like to suggest to you in particular, and to others who
would like to help the suckless project, is to look at the

https://suckless.org/project_ideas/

for ideas about areas to focus on, which are currently lacking and
for which programming efforts would help the most.

[Jeffrey Picard]

I've been less than casually following this thread, but I feel moved to
jump in here and say simply Fuck GPL, fuck censorship in all it's forms,
and fuck no the license doesn't cover mandating keeping git history
intact. Put anything you want attributed in the LICENSE file, that's it.


--Jeff

[Страхиња Радић]

Дана 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 companies. All users as a whole are more
important than the companies.

BTW I don't use cuck licenses, thanks:

https://lukesmith.xyz/articles/why-i-use-the-gpl-and-not-cuck-licenses/

[Dr. André Desgualdo Pereira]

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?

--
Dr. André Desgualdo Pereira
Psiquiatra - CRM/SP: 120218 - RQE: 61032
WhatsApp: (11) 985-847-809 - email: des...@gmail.com
Consultório: Rua Clélia, 2208 - sala 307

[Raymond Cole]

Thank you for sharing the information. But what I can see from the mail
thread you shared is that people still disagreed at the end of the day.

I think Richard Stallman has closed that issue:

> In the combined program, the parts that came in under lax licenses still
> carry them, and the combined program as a whole carries the copyleft
> license.

Source: https://www.gnu.org/licenses/license-compatibility.en.html

As for your words:

> In other words, when you license a work under GPL, you license **the
> whole work** under GPL. You cannot mix and match licenses. All the
> licenses of other parts must be "compatible" with the GPL in order for
> you to do so.

I do license swm as a whole under GPL, but GPL doesn't prevent me from
making exceptions, so I can state that parts of the code are licensed
differently. (It's better if I don't have to, though, especially when
it's hard to make clear which parts are the exceptions.)

By the way, what I proposed at first was basing on some examples in
busybox. For instance, in include/libbbb.h in its source tree, there
is this comment:

> * Based in part on code from sash, Copyright (c) 1999 by David I. Bell
> * Permission has been granted to redistribute this code under GPL.

So I supposed it was simple to ask for permission of redistribution
under GPL. dwm developers appear to be quite unprepared for this
request, though. dwm copyright owners grant me the permission and I
keep a brief notice, shouldn't it just be like that? And I am open to
discussion about what to write in the notice.

> However, the issue might arise from the term "substantial" and its
> interpretation. I believe that in the case of my programs using the
> termbox library it is clear that the library is not a substantial part
> of my program, and vice versa. In the case of hacked dwm, I'm not so
> sure.

I don't quite understand what the concern is here?

Anyway, now what I am asking for is a different thing, which is putting
dwm's copyright list to the copyright list of GPL licensed swm, as if
swm has been jointly developed with them (which is true in a sense).
That will simplify the situation for possible future works basing on it
as only one license and no special notice is carried around.

That's not technically allowed by the Expat license, obviously, but I
am not asking permission from the license. If some dwm developers are
unhappy about that, I truly would like to learn the reason and see what
I could do differently.

[Raymond Cole]

Good questions.

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 that swm implements are chosen or
designed basing on the features his heavily patched dwm has, so I expect
at least someone like him wouldn't be very resistent to these features.

By the way, they do work, right? I don't even know if people have no
problem cloning my projects (basing on the way you count the lines it
seems that you do), sigh.

Is it more minimal? It's minimal I would say, but dwm's minimality is an
extreme so let's compare with others: `wc -l src/*.[ch]` for bspwm shows
over 14,000, and `wc -l src/*.c` for i3 shows over 28,000. You can see,
in terms of source code minimality swm is still in dwm's tier.

dwm's encouragement for users to modify the source naturally attracts
proficient hackers that will dive much deeper than config.h, and
this means that the programming interface does matter to end users.
I claim that swm's programming interface is more minimal than dwm:
There are 91 function declarations in dwm.c, ordered alphebtically in a
monolithic list, versus 71 in swm.h, grouped by compilation units that
defines them. Also, the Client struct has 33 fields in dwm and 31 in swm.
And remember that's already the result of swm being a more sophisticated
window manager.

The layout description language might look somewhat a bloat, but it's
implemented in lyt.c alone and exposes only 4 global functions. What's
inside lyt.c is like code in a libray that users rarely need to care.
Inside lyt.c it isn't bad either if you compare with the vanitygaps patch
(which Luke uses). vanitygaps.c, which provides a number of layouts with
gaps, has 809 lines, while lyt.c, which allows a hacker to create a layout
(with gaps as well) by just a string instead of writing a tiling function,
has 770 lines. It's minimal with respect to its functionality, isn't it?
And I am not hardwiring such a thing into swm. It's a compilation
unit that has minimal interface and therefore can be easily replaced by
hackers who have better ideas.

Regarding working with other programs, swm's dmenu integration certainly
makes better use of dmenu than dwm does. swm uses dmenu, a separate
program, to provide menus that works like built-in, and communicates
with it using pipes. And swm works with the status program similarly,
the status program only needs to be a program that processes input and
produces output. Quite Unixy, right?

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 corporation with other programs.

Does swm fulfill its purpose? Initially I attempted to hack dwm to an
extent of rewriting when I realized that under scrutiny Luke's dwm fork
looked like pieces of woods and plastics nailed and ducktaped together.
Patches are of varying quality, and when simply added together the
overall quality is often worse than the average. Then I began to see
dwm's state of being a bare-boned program plus various available patches
as a transitional phase that awaits the emergence of certain powerful
combination. So one of swm's main purpose is to find this combination
and make it organically. Yes not everyone is going to find all about
swm useful, but that's because it aims to be the least common multiple
rather than the greatest common divisor. You can tell how well it serves
this purpose.

What about infobar's purpose? I was at first unsatisfied with how most
others status program updates their results and that realtime updates
and clickability are often achieved hackishly. If you look at infobar's
solution to these problems I think you will agree that it's a good one.

> In particular, I don't see the need to have multiple programs with
> overlapping functionality as part of the official suckless software
> "suite". I'm fine using dwm and slstatus, thanks. I apply patches I
> choose and set my config.h the way it suits me.
>

It seems like you get the impression that I want suckless to host my
projects? I never requested that. It would be nice if swm and infobar
could be referenced in the website just like numerous others have been
but that's about it. What I want is for you guys to actually inspect
and judge them. My primary interest at this point is to get opinions
about, like, what level of talent is demonstrated? Do they stand out
among similar works? Complaints? Suggestions?

> What I would like to suggest to you in particular, and to others who
> would like to help the suckless project, is to look at the
>
> https://suckless.org/project_ideas/
>
> for ideas about areas to focus on, which are currently lacking and
> for which programming efforts would help the most.
>

Well, maybe later. It's just my first step.

[Chris Down]

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
>> > relicensing permission, make it clear.)
>>
>> Please learn how MIT licensing works.
>> [...]
>> Restore the Git history, or violate the license: it's as
>> simple as that.
>
>I am of course open to being corrected, but AFAIK there's no requirement
>to keep git history. Only requirement is to keep the license
>file/notice.

I am not a lawyer, so I'll simply leave it at that having no clarity about
which parts are from dwm (and thus are authored under MIT) and which are not is
problematic. Having the git authorship removes this problem. In vendored or
tarballed code, it is not ambiguous.

[Страхиња Радић]

Дана 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 that swm implements are chosen or
> designed basing on the features his heavily patched dwm has, so I expect
> at least someone like him wouldn't be very resistent to these features.

I know of Luke Smith, I don't know him personally. He is not a mainline
suckless developer, and his views don't always align with the suckless
movement (his choice of license being just the most visible difference).

> By the way, they do work, right? I don't even know if people have no
> problem cloning my projects (basing on the way you count the lines it
> seems that you do), sigh.

No, I had no problem git cloning your project's repository. Like I
said, the line count is a rough estimate, but still roughly indicative
of greater complexity.

> There are 91 function declarations in dwm.c, ordered alphebtically in a
> monolithic list, versus 71 in swm.h, grouped by compilation units that
> defines them. Also, the Client struct has 33 fields in dwm and 31 in swm.

Whether the number of functions means anything, and how far, is
debatable. Hypothetical example: which of the programs is better and in
what way--the one which has a greater number of focused, easily
understandable, reusable functions, or the one which has a smaller
number of large, specialized, functions spanning over several 25-line
screens?

> The layout description language might look somewhat a bloat, but it's
> implemented in lyt.c alone and exposes only 4 global functions. What's
> inside lyt.c is like code in a libray that users rarely need to care.

Windows has a lot of programs and services running in the background
that are "just some code" which "users rarely need to care". I prefer
to at least choose the features that the programs I run will have.
Suckless software solves this ingeniously--the core program is as
simple as it gets, and the users are free to add functionality through
third-party source code patches.


> [...] Then I began to see dwm's state of being a bare-boned program

> plus various available patches as a transitional phase that awaits
> the emergence of certain powerful combination.

Ah, but it only might seem that way. It is not transitional, it is
intentional. It is the design choice, and like I said, an ingenious
one. It gives the user the full control.


> clickability

Is not needed in a program which should display status information.
Literally what a status bar program should do is collect and display
information, full stop.

Furthermore, to anyone working in Unix CLI, mouse interface is clumsy
and unnatural. It requires lifting a hand from the keyboard to grab and
control the mouse, and then use the mouse to navigate the pointer and
click, and then likely return the hand to the keyboard. All of that is
an unnecessary waste of time.

> 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 least in my case it was. I thought that you
requested peer review for a new *suckless* software.

[Raymond Cole]

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 least in my case it was. I thought that you
> requested peer review for a new *suckless* software.
>

Okay...I thought my initial email has stated my intention quite clearly.
I am not a suckless developer, let alone a prominent one, so it doesn't
make sense at all for me to announce new software to be included in
suckless.

Does that false impression, if somehow common among you, account for
the overall unwelcoming atmosphere that I've perceived here? If so,
may you reconsider your responses after this clarification?

Suckless developers, if it were not out of respect I wouldn't have been
here asking you to judge my works.

[Страхиња Радић]

Дана 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 sincere and voicing my opinion. I find value in the
core principles behind the suckless movement, and would prefer to not
see them diluted.

[Raymond Cole]

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 perceived here? If so,
> > may you reconsider your responses after this clarification?
>
> Excuse me for being sincere and voicing my opinion. I find value in the
> core principles behind the suckless movement, and would prefer to not
> see them diluted.
>

I know emails in this list can be received by everyone subscribing to
it so, although I quoted you, I wasn't necessarily talking only to you.
I apologize if some of my previous emails that mainly but not completely
talks to you appear strange to you.

I think quoting some person in this email list doesn't necessarily mean
specifically talking to that person. Maybe someone can either confirm
or correct me?

Strahinja, I have to say your voice is among the kindest to me, but
you can probably agree that most other responses I've received were not
very welcoming.

Kind regards

[Steffen Nurpmeso]

Raymond Cole wrote in
<stie6dk3objhzijnahbcsuaavxerov3rfc4qel5tbichotqtgn@cyljpygbpqe3>:
...

|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 corporation with other programs.

...

|What about infobar's purpose? I was at first unsatisfied with how most
|others status program updates their results and that realtime updates
|and clickability are often achieved hackishly. If you look at infobar's
|solution to these problems I think you will agree that it's a good one.

...

P.S.: my linux.status-line.sh is 671 lines.
I start it in ~/.xinitrc:

#command -v xclock >/dev/null 2>&1 && xclock &
if command -v status-line.sh >/dev/null 2>&1; then
status-line.sh xsetroot &
fi
${S_TERM} ${S_TERM_TITLE} ed 2>/dev/null &
command -v dwm >/dev/null 2>&1 && exec dwm
command -v cwm >/dev/null 2>&1 && exec cwm
command -v ahwm >/dev/null 2>&1 && exec ahwm
exec ${S_TERM} ${S_TERM_TITLE} ROOT

but eventually "kill -HUP" it so it (until next sig) updates the
tmux status line instead. (I hide dwms status line, but not by
default. I am too stupid for tags, all monocle.) Currently i see

[P+36°<38° | 0>1#4 | MS:4.7/9.2 | RF:W~B~ wlp1s0~~111 | P,96%~~ | B:2% V:13% | 10-30 01:22]

Nothing to click though. Am not root anyway.
But i can also run it like so (need to fake COLUMNS)

$ COLUMNS=241 ~/sec.arena/configs.git/misc/linux.status-line.sh a
= STYLE<> CUT<> SMALL=0 MODS<battery_status brivol loadavg mem model net xdate>
. PowerPlug:
+ ADP0 P 1730243904
. Battery:
+ BAT0 96% 96% 37840000 36630000 "Normal" "Not charging" 1730243904
. Power and Battery: would *not* examine state directly
+ PowerPlug 0 online: 1
+ Battery 0 capacity at 100%, capacity_level=Full, status=Full
. Brightness: 2%, Volume: 13%
. loadavg 0>3/244#4
. Mem: total=7866 free=4764 available=7234 Swap: total=9215 free=9215
. Memory/Swap 4.7[7.2]<7.8/9.2<9.2
. CPU 1 temperature 38/100
. CPU 2 temperature 38/100
. CPU 3 temperature 38/100
. CPU 4 temperature 37/100
. CPU 5 temperature 36/100
. P+5:36°<1:38°
. rfkill state: WLAN=~ Bluetooth=~
. Netdev lo up/down/x=- addr 127.0.0.1, rec 72 MiB, snd 72 MiB loopback
. Netdev wlp1s0 up/down/x=~~ addr \o/, rec 98 MiB, snd 13 MiB ether
. Netdev wgppp up/down/x=- addr 192.0.2.2, rec 4 MiB, snd 1 MiB none wireguard
. Netdev vm up/down/x=- addr 203.0.113.1, rec 0 MiB, snd 0 MiB ether veth
. Netdev browse up/down/x=- addr 203.0.113.64, rec 2 MiB, snd 51 MiB ether veth
. Netdev priwse up/down/x=- addr 203.0.113.66, rec 0 MiB, snd 0 MiB ether veth
. Netdev secweb up/down/x=- addr 203.0.113.68, rec 0 MiB, snd 0 MiB ether veth
. Date 2024-10-30 00:59 (epoch 1730246398, interval 2/30)
@P,100%== | B:2% V:13% | 0>3/244#4 | MS:4.7[7.2]<7.8/9.2<9.2 | P+5:36°<1:38° | RF:W~B~ lo-72/72,wlp1s0~~98/13,wgppp-4/1,vm-0/0,browse-2/51,priwse-0/0,secweb-0/0 | 2024-10-30 00:59

It may colourize the tmux status line in green, yellow or red if
it finds things problematic. For some time, until the condition
disappears, it has a concurrent child and talks via pipe, which
controls that.

But other than that, i let acpid2 and udev driven scripts perform
adjustments and place status in files in /run/:

/run/.sys-backlight /run/.sys-battery /run/.sys-cpu
/run/.sys-power /run/.sys-volume

and also user scrips can use read(1) to fetch prepared data.
(There is also more stuff like that.)
This is better than pipes and running amixer and sed to dig that
mess. (Sometimes we do nonetheless, ie, if the battery loads;
this is because events seem pretty unreliable.)
Ie also run all=$(ip -json -details -statistics address show) for
network data, and i hope pattern matching is not so slow.

Btw i have also a super simple ignfocus patch, the last chunk of
which is i think useless, and i generally wonder.
I need it because i use xmessage to announce volume etc changes
also, and i hate that takes the focus.

Other than that your swm looks pretty clean from a fast glance.
You could also have used cwm as a base and throw some things off.
I must say i now like doing dwm with its dmenu, but it is not much
smaller than cwm and CPU time could even be more, but that i had
to check. Key bindings via config file is definitely a good
thing and such, and the code doing that is not much heavier than
dwm's array loop. But well. Two seconds CPU since Monday
evening.


ignfocus
---
config.def.h | 6 +++---
dwm.c | 15 +++++++++++----
2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/config.def.h b/config.def.h
index 9efa7744b3..941b787234 100644
--- a/config.def.h
+++ b/config.def.h
@@ -26,9 +26,9 @@ static const Rule rules[] = {
* WM_CLASS(STRING) = instance, class
* WM_NAME(STRING) = title
*/
- /* class instance title tags mask isfloating monitor */
- { "Gimp", NULL, NULL, 0, 1, -1 },
- { "Firefox", NULL, NULL, 1 << 8, 0, -1 },
+ /* class instance title tags mask isfloating monitor ignfocus */
+ { "Gimp", NULL, NULL, 0, 1, -1, 0},
+ { "firefox", NULL, NULL, 1 << 8, 0, -1, 0},
};

/* layout(s) */
diff --git a/dwm.c b/dwm.c
index 5ce3f3c0fa..891a7ed93f 100644
--- a/dwm.c
+++ b/dwm.c
@@ -92,7 +92,7 @@ struct Client {
int basew, baseh, incw, inch, maxw, maxh, minw, minh, hintsvalid;
int bw, oldbw;
unsigned int tags;
- int isfixed, isfloating, isurgent, neverfocus, oldstate, isfullscreen;
+ int isfixed, isfloating, isurgent, neverfocus, oldstate, isfullscreen, ignfocus;
Client *next;
Client *snext;
Monitor *mon;
@@ -139,6 +139,7 @@ typedef struct {
unsigned int tags;
int isfloating;
int monitor;
+ int ignfocus;
} Rule;

/* function declarations */
@@ -299,6 +300,7 @@ applyrules(Client *c)
&& (!r->instance || strstr(instance, r->instance)))
{
c->isfloating = r->isfloating;
+ c->ignfocus = r->ignfocus;
c->tags |= r->tags;
for (m = mons; m && m->num != r->monitor; m = m->next);
if (m)
@@ -803,7 +805,11 @@ focus(Client *c)
attachstack(c);
grabbuttons(c, 1);
XSetWindowBorder(dpy, c->win, scheme[SchemeSel][ColBorder].pixel);
- setfocus(c);
+ if (c->ignfocus <= 0) {
+ if (!c->ignfocus)
+ setfocus(c);
+ c->ignfocus = 0;
+ }
} else {
XSetInputFocus(dpy, root, RevertToPointerRoot, CurrentTime);
XDeleteProperty(dpy, root, netatom[NetActiveWindow]);
@@ -1234,8 +1240,9 @@ propertynotify(XEvent *e)
switch(ev->atom) {
default: break;
case XA_WM_TRANSIENT_FOR:
- if (!c->isfloating && (XGetTransientForHint(dpy, c->win, &trans)) &&
- (c->isfloating = (wintoclient(trans)) != NULL))
+ if (!c->ignfocus && !c->isfloating &&
+ (XGetTransientForHint(dpy, c->win, &trans)) &&
+ (c->isfloating = (wintoclient(trans)) != NULL))
arrange(c->mon);
break;
case XA_WM_NORMAL_HINTS:

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself fore'er and e'er
|
|Farewell, dear collar bear

[Raymond Cole]

Hi developers,

Lately I brought up a discussion about my new software, but I never got
responses that I originally expected. Sure, to you I was some rando on
the internet, so why would I expect anyone to care? What has changed
since last time is that I've made some small contributions to suckless
software, and I could contribute further, so I suppose I am more relevant
to this community now.

To be fair, some did pay some attention to my works, but there were
misunderstandings. So this time, to be perfectly clear:

* No, I am not requesting suckless to host my projects.
* No, I am not here to show off.
* No, I am not here to ask any of you to switch to my software.

What I want is just your words about my works to help with my application
for a master's degree, specifically about:

* How original are they?
* How non-trivial are they?
* Do you find something interesting about them?

Could you please do me a favor?

Thank you very much!


Links to my works:

https://wolog.xyz/repos/swm
https://wolog.xyz/repos/infobar

[Steffen Nurpmeso]

Raymond Cole wrote in
<4ekvrybfu7v3gpv7lcme5h2iwjb4svuueh635wk374xlbf7f3z@f2udkyaqbgkd>:
...

|What I want is just your words about my works to help with my application
|for a master's degree, specifically about:
|
|* How original are they?
|* How non-trivial are they?

Honestly, the syntax to define the layout is -- in my opinion --
horrible. I am too old and to stupid to have masturbation
replacements via cryptical configuration syntax, or even entire
languages, think brainfuck. Yes, when i was younger i sometimes
had similar approaches, and when i came back later, and did not
know at a glance, it only took a short sprint to get back and
"ride that wave" again. But in general i was even more stupid by
then, and today i am nothing but annoyed by such things.

(Now you might say "dude your status line *is* cryptical", and it
is true that ASCII subsets do not get you far, and to "virtualize"
"blocked", "unblocked", "data flows" and "data can always flow
here" in the shortest possible number of columns you must suck.
So to say.)

|* Do you find something interesting about them?
|
|Could you please do me a favor?
|
|Thank you very much!
|
|Links to my works:
|
|https://wolog.xyz/repos/swm
|https://wolog.xyz/repos/infobar

Other than that i would really have to look more thoroughly.
It looked pretty clean, though quite under-commented.
Because you talked thesis. In FreeBSD, for example, today
a Google Summer of Code project was committed, which diversified
a massive script into a library, and there one could read eg

+ -- Parse it into key, value pairs.
+ local key, value = nextline:match(line_expr)

and i was thankful because i would not have recognized it
otherwise what was happening there. (You are however out for
a master, and as that is beyond me anyhow, it could be ok.)

Other than that i am silent now because *i* am not a suckless
developer.

--End of <4ekvrybfu7v3gpv7lcme5h2iwjb4svuueh635wk374xlbf7f3z@f2udkyaqbgkd>

(But i hate totally random message ids.)

[Jeremy]

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 state rest; then
case "$state" in
'[playing]') echo "$song ►";;
*) echo "$song ◼";;
esac
else
echo "◼"
fi; mpc idle >/dev/null

And then the main bar program loops each script. Only problem is when
I fuck myself & create 900000 processes for no reason then my bar stops
working.

I did a shorter version of fifolog(conccat) without line-delimiting a
little while back - see below.

Jeremy

---

#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <sys/select.h>

int
main(int argc, char **argv)
{
int i, j, n, w, eof;
fd_set rs;
char buf[BUFSIZ];
for (i = 1; i < argc; i++) {
// close any "accidently" open file descriptors
close((i+2)+(argc-1));

if ((n = open(argv[i], O_RDONLY)) == -1) {
fprintf(stderr, "pselect: %s\n", strerror(errno));
return 1;
}
}

for (eof = 0; !eof;) {
FD_ZERO(&rs);
for (i = 3; i < argc+2; i++) {
FD_SET(i+(argc-1), &rs);
}

if ((n = select(i+argc, &rs, NULL, NULL, NULL)) == -1) {
fprintf(stderr, "pselect: %s\n", strerror(errno));
return 1;
}

for (i = 3; i < argc+2; i++) {
if (!FD_ISSET(i+(argc-1), &rs)) {
continue;
}

if ((n = read(i+(argc-1), &buf[0], sizeof(buf))) == -1) {
fprintf(stderr, "failed reading from fd %d: %s\n", i+(argc-1), strerror(errno));
return 1;
} else if (n == 0) {
eof = 1;
}

for (j = 0; j < n; j += w) {
if ((w = write(i, &buf[j], n-j)) == -1 || w == 0) {
fprintf(stderr, "failed: %s\n", strerror(errno));
return -1;
}
}
}
}
}

[Raymond Cole]

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 formatting, like:
> mpc status -f '%artist% ~ %title%' | if read -r song && read -r state rest; then
> case "$state" in
> '[playing]') echo "$song ►";;
> *) echo "$song ◼";;
> esac
> else
> echo "◼"
> fi; mpc idle >/dev/null
>
> And then the main bar program loops each script. Only problem is when
> I fuck myself & create 900000 processes for no reason then my bar stops
> working.
>

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 essense, but with
scripts writing to FIFOs instead of files and without use of inotify.
But with that approach, if multiple scripts update per minute or per
second independently, the moment they output won't be aligned, resulting
in more updates of the bar. I took a different approach also for reducing
the number of processes and making it easier to respond to input.

In daily usage people only glance at the status once in a while and most
information is needed only very occassionally, so I think it's ideal
that the status monitor runs highly economically by default, while more
frequently updated information is handily available with a click.

> I did a shorter version of fifolog(conccat) without line-delimiting a
> little while back - see below.
>

> [...]

Nice. I will see if I can borrow some ideas.

Thank you for responding, Jeremy. Your further comments will be
appreciated.

Raymond

[Jeremy]

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't speak for anyone else, but for me, it helped with readability.

> 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 essense, but with
> scripts writing to FIFOs instead of files and without use of inotify.

Thanks for checking it out. I think I used inotify because I didn't know
how to write concurrent programs effectively.

> But with that approach, if multiple scripts update per minute or per
> second independently, the moment they output won't be aligned, resulting
> in more updates of the bar. I took a different approach also for reducing
> the number of processes and making it easier to respond to input.
>

I envy the format string in the single-script approach, because the
bar-widgets-as-scripts necessitates:
50-memory.sh, 51-music.sh, 2-date.sh, 1-time.sh

I do not like the "_" prefixes in function variables, and do not care too
much about extra processes running or bar-updates.

The update alignment brings up an interesting topic which I've been thinking about:
Should X clients dispose of graphical updates if they're overwritten
shortly after?

Right now, in st, before writing updates to the screen, it waits for a
very brief period of time, to see if there are more updates from the TTY,
and then sends the draw commands.

Though there are some understandable constraints(the X client library)
that prevent different approachs, I've been thinking that this has been
the cause of flickering & other race conditions.

I'd curious as to your thoughts on this if it is a topic of interest for you.

Jeremy

[Raymond Cole]

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 files and without use of inotify.
>
> Thanks for checking it out. I think I used inotify because I didn't know
> how to write concurrent programs effectively.
>
> > But with that approach, if multiple scripts update per minute or per
> > second independently, the moment they output won't be aligned, resulting
> > in more updates of the bar. I took a different approach also for reducing
> > the number of processes and making it easier to respond to input.
> >
>
> I envy the format string in the single-script approach, because the
> bar-widgets-as-scripts necessitates:
> 50-memory.sh, 51-music.sh, 2-date.sh, 1-time.sh
>

Thank you for your appreciation and timely reply! I apologize for my
late response.

> I do not like the "_" prefixes in function variables, and do not care too
> much about extra processes running or bar-updates.
>

I would rather not have those prefixes if shell variables were scoped
(there is a "local" keyword in many shells but it isn't standardized).
The prefixes are there to avoid name collisions which could cause very
subtle bugs. The approach I took is to prefix variables within functions
with an underscore, avoid calling functions with its own variables inside
a function, and utilize positional variables in functions.

But this is obviously not the only scheme to prevent the problem, so
maybe you have better suggestions.

> The update alignment brings up an interesting topic which I've been thinking about:
> Should X clients dispose of graphical updates if they're overwritten
> shortly after?
>
> Right now, in st, before writing updates to the screen, it waits for a
> very brief period of time, to see if there are more updates from the TTY,
> and then sends the draw commands.
>
> Though there are some understandable constraints(the X client library)

> that prevent different approaches, I've been thinking that this has been

> the cause of flickering & other race conditions.
>
> I'd curious as to your thoughts on this if it is a topic of interest for you.
>

swm/dwm redraws the whole bar every time any part in the bar changes, and,
at least in my experience, unchanged parts don't flicker, so I think X
server handles graphical updates smoothly. Given that, the only source
of flickering would be a program that does something like clearing a
region right before drawing on it. Curse programs typically do that,
so virtual terminals have a very specific need for handling flickers.
Other than that, say in the case of dwm status bar, if there's flickering
I would suspect the bar program is doing something weird and wouldn't
consider it dwm's responsibility to make up for it.

That said, there are still cases where this idea is worth exploring,
but you need to be more specific about the cases of flickering & race
conditions.

Raymond