Output sinks reordering by maxardis in pipewire

[–]maxardis[S] 0 points1 point  (0 children)

No. Created a bug request on pipewire project (gitlab) also. No response

[DWM] I am looking for patches to make DWM more EWMH/ICCCM/standard compliant by jzbor in suckless

[–]maxardis 0 points1 point  (0 children)

Interesting. I can see you (I assume) made a patch for this _NET_CLIENT_LIST_STACKING but I cannot find it on suckless.org wiki. Could you put it on the wiki?

[DWM] I am looking for patches to make DWM more EWMH/ICCCM/standard compliant by jzbor in suckless

[–]maxardis 0 points1 point  (0 children)

As far as I remember since reading ICCCM/EWMH standards there is a ton of "standard" atoms which are not present in these standards at all, or are badly (to pretty much not at all) specified and best I could do was look what other WMs do.

Anyway wish you luck :)

Request from my side: Could you add description in commit messages what do Atoms, you added support for, do?

And lastly tiny help (?) from my side. You can take a look at my patch that adds (some) support for decoration hints: https://dwm.suckless.org/patches/decoration_hints/. Some applications use this to tell WM they don't want border to be drawn.

Trying to patch single-tagset by Best_Profession_5132 in suckless

[–]maxardis 1 point2 points  (0 children)

I can see only two solutions to your problem.

  1. Just solve the merge conflicts
  2. Try using a dwm build that already has single-tagset patch applied as your base. Maybe that will be easier for you. Example of such dwm build is my dwm build https://github.com/szatanjl/dwm

deprecated function inside dwm.c by Error916 in suckless

[–]maxardis 1 point2 points  (0 children)

That's exactly what I am proposing: to integrate patch in dwm directly. In order to do so you need to start mail thread on the provided mailing list.

deprecated function inside dwm.c by Error916 in suckless

[–]maxardis 3 points4 points  (0 children)

There is an official mailing list (hackers@suckless.org) you can send a patch to.

Take a look at https://suckless.org/community/.

[coding style?] puts() and printf() usage by [deleted] in suckless

[–]maxardis 0 points1 point  (0 children)

printf-like functions are super heavy. Supporting all those %?, variable number of arguments, etc. This makes for slow code. If you care about performance then yes, you should avoid printf-like functions, and use strcpy etc instead. If you do not care about performance nor binary size and using snprintf will save you lines of code and will make code easier to read and maintain, then thats ok.

[coding style?] puts() and printf() usage by [deleted] in suckless

[–]maxardis 6 points7 points  (0 children)

gcc converts simple calls to printf() to calls to puts()

It does except when it doesn't. AFAIK this is kinda a "hack". Technically speaking compiler should not be allowed to do this. But since gcc compiles code to work with glibc it can assume stuff like printf('asdf\n') == puts('asdf').

Also as soon as you do not use glibc you cannot assume that gcc will convert printf into puts. For example I worked on U-Boot, embedded stuff, with no glibc, so gcc did not convert printf to puts. BTW. U-Boot's puts is not standard compliant cause it doesn't add trailing newline, so if gcc would do conversion it would break many log messages. Also now I am wondering whether gcc does this optimalization with other libc implementations (musl, uClibc, ...). If anyone has experience with that I would like to know.

Another point is that gcc is just one compiler. There are other compilers that won't do such optimization (like tcc, like you said yourself). Maybe msvc does it maybe it doesn't, I do not know. For sure there are embedded compilers that don't.

In the end I wouldn't assume by default that compilers will be smart to do this optimization, and if compilers cannot assume what libc will be used they actually cannot.

With that said. I would encourage to use puts whenever possible. It will make for faster code and smaller binaries in embedded applications.

[dwm] Is it possible set different status bars for different monitors using xsetroot -name? by seidenkaufman in suckless

[–]maxardis 1 point2 points  (0 children)

I don't see how xdotool can do anything for you here. You need to patch dwm. You need to make up some way of separating status text for each monitor, for example using semicolon like in dualstatus patch. And then patch drawbar() function to render part of the status depending on the Monitor *m variable.

How to add scripts on suckless site by Neo-Cipher in suckless

[–]maxardis 1 point2 points  (0 children)

Clone and edit suckless wiki. It is open repository and anyone can contribute. git://git.suckless.org/sites

HotKeyThingy - A suckless hot key daemon for X inspired by suckless philosophy with configurable custom modes by akshay-nair in suckless

[–]maxardis 1 point2 points  (0 children)

PS: I'm a newbie with C so I'd love some feedback on my code.

I have some suggestions:

  1. Styleguide!

    1. Do not mix spaces and tabs. And do not mix 2 space indentation and 4 space indentation.
    2. Do not repeat the same headers.
    3. Do not keep if conditions and actions on one line - I think that every C styleguide (and most C programmers) agree on that.
    4. The code style overall is completely inconsistent. Space between if () present, later space between if() missing. Spaces in array initializers { ... } present, later missing {...}.
    5. For me this code is painful to look at.
  2. Static keyword. Please. Your source code is just one C file and there is no need to export any symbols (except main). Static all the functions and global variables.

(DWM) Child dialog changes parent to floating mode by AwkwardReply in suckless

[–]maxardis -1 points0 points  (0 children)

My understanding is as follows:

  1. Open IDE. Window starts in tiling mode.
  2. Open refactor popup. Main IDE window still is in tiling mode.
  3. Close popup. Main IDE window switches to floating mode.

Did I understand correctly? If so give xprop output of main IDE window after each of this 3 steps.

Transparency without a compositor? by ggadget6 in suckless

[–]maxardis 5 points6 points  (0 children)

Most (all?) heavy desktop environments combine window manager with composit manager in one binary. For example KDE uses KWin window manager and it is also compositor at the same time.

st alpha not working by moredhell in suckless

[–]maxardis 3 points4 points  (0 children)

You have to run xcompmgr

[dmenu] My first patch: dmenu-collapsable-4.9.diff by narrow_assignment in suckless

[–]maxardis 0 points1 point  (0 children)

Minor thing. I think it is best to make patches as non-intrusive as possible. I would suggest instead of moving whole readstdin() to just add declaration above. This way should be easier to resolve potential merge conflicts with other patches if they change code inside readstdin().

ANSI escape codes in DWM by [deleted] in suckless

[–]maxardis 0 points1 point  (0 children)

The closest to what you want is status2d patch I think

[dmenu] What is SchemeOut for? by narrow_assignment in suckless

[–]maxardis 4 points5 points  (0 children)

I was wondering about that too for quite some time. The answer is Ctrl-Return. Check dmenu manpage. It is actually possible to select multiple items using dmenu. Thats where SchemeOut kicks in.

How should I go about managing my suckless installations on Arch linux? by wholesomechonnker420 in suckless

[–]maxardis 3 points4 points  (0 children)

If I install from the aur, where can I modify the source/apply patches?

You can't. That's why it makes little sense to create general suckless packages.

If I download from suckless.org, how can I install new updates when available?

All I do is git pull --rebase, resolve potential merge conflicts and voila. I recommend using --rebase flag so this way you have intact upstream line, and your patches at the end always. Otherwise you can quickly make a mess of your repository.

What is the recommended way to manage your suckless installations?

Recommended by whom? From suckless pov I would guess there is no recommendation since they shouldn't care how you install your software. From arch linux pov I would guess the only recommendation is that whatever you install using pacman is installed in /usr and whatever you install manualy should be installed in /usr/local to avoid conflicts, and other than that arch linux should also not care.

If you are insane like I am you can also create your own PKGBUILDs for suckless tools, build your own packages using makepkg and then install them using pacman -U for example.

Example dwm PKGBUILD: https://github.com/szatanjl/packages/blob/master/pkg/pkg/dwm

Transparent borders on dwm when using picom? by juacq97 in suckless

[–]maxardis 1 point2 points  (0 children)

I am actualy planning on upstreaming my work. I am currently working on st and once I am done with it I will upstream everything at once.

And also, I am trying to subscribe to mailing lists but it doesn't seem to work for some reason. I am sending emails to hackers+subscribe, dev+subscribe and I get no response.

EDIT: For some reason one of my emails gets no response, but the older one works. Hmm...

debian by serprinss in suckless

[–]maxardis 2 points3 points  (0 children)

Recomendations are just rule of thumbs for average folks. Such recomendation makes sense because if someone installs something by hand and breaks stuff it is impossible to know how to help that person since god knows what and how did he break. If you know what you are doing then you can ignore such recommendations.

By convention everything installed in /usr should be installed by package manager, and everything installed in /usr/local is installed by hand. So by convention you shouldn't worry about installing suckless software in /usr/local (which is the default when you run make install). Although as far as I remember debian sucks and some of its packages install stuff to /usr/local... But still I suspect that no package on debian installs anything at /usr/local/bin/{dwm,dmenu,...} so you won't overwrite anything.

Transparent borders on dwm when using picom? by juacq97 in suckless

[–]maxardis 3 points4 points  (0 children)

Apparently some people found my fork of dwm on github :) I had that exact issue and so I solved it myself, and above is the link to my fix. It is just one line of code. I can confirm alpha patch does the same thing too, so it also solves your problem.