Re: [dev] suckless indicators?

From: Nikita Zlobin <nick87720z_AT_gmail.com>
Date: Thu, 8 Jul 2021 12:30:33 +0500

In Wed, 7 Jul 2021 22:27:33 +0200
Страхиња Радић <contact_AT_strahinja.org> wrote:

> But... why? There is already slstatus, which does an excellent job.
> One can make a shell script which fetches information from wttr.in
> (for example), add the call to that script to crontab, and have
> slstatus pick up that information.

As far as I understand, slstatus writes to panel (or it's panel).
Nothing related to ncurses/terminal status line, controlled by tput.

> Even dwmblocks adds unnecessary functionality - why would a status
> indicator need to support mouse clicks at all? Its job is to display
> a minimum of information, not lead to windows with more information.

Perhaps because user wants :P
NOTE: user is not one without coding/admining skills, it's who uses
(thus, coders are users of their workspace, dev tool, etc).

What's better way to open app, logically related to some applet: click
applet, which is here and now, or again open dialog/menu/term,
select/type command...

Main advantage of proposed approach - window always exists in memory, so
comparing with other applets implementation show/hide is instant.
No window - no indicator. Of course, such windows may be better
minimized on start.

>
> You have to understand that for a program to be considered suckless,
> it needs to be straight to the point and minimal. Extra functionality
> is added through patches.

Hm, for now I shared only idea, programs were only to demonstrate idea,
they are incomplete. Also programs are shell scripts, which may be just
sourced aka libs.

Writing to window title is primary function of my approach. It could be
done by main app (best), but this time it's dedicated script, designed
to run parallel and write to window title, while main app displays it
content. How can it be more minimal?

(ah, forgot another example - mc and even shell, printing cwd to
statusline)

Each has own understanding of suckless.
- Some people have it rather limited: only certain functions are
  considered ok.
- My is more flexible: it's not about functions list, it's about their
  reusability and impact.

About patches: I'm not sure, what it's about.
- If about my specific implementations, using scripts, then there's
nothing to be simplified.
- Main app, doing it themselves? Better of has. Or find better point to
  add this feature for app, that doesn't support that.
Received on Thu Jul 08 2021 - 09:30:33 CEST