Re: [dev] Suckless paint/graphic editor program
On Mon, Jul 10, 2023 at 3:24 PM wrote: > I'd love if we could use the GPU directly like pixel changes, etc, without > all > the 100 fancy APIs, managers, etc. I ran across this and it might be of interest. https://github.com/uobikiemukot/yafblib It lists the BSD console as an option. I definitely like the BSD systems. If they had better device driver support for all my peripherals, I'd be using a BSD system. As to using the GPU directly for graphics, OpenGL and Vulkan can do that. However, they require a shading language. So, you need another programming language involved. You couldn't just write your program in C. The shader languages are supposed to be C like. Haven't experimented with them yet, but I would have preferred to stick with one language for development. SDL 3.x is going to include its own shader language. Haven't decided whether I'm going to upgrade the SDL programs I use to work with it, leave them as SDL 1.x and 2.x or try to find another graphics library to work with. I keep searching for useful C GUI libraries and graphics libraries (possibly something besides SDL). It's surprising how few there are that I would consider good solutions. > Will check out this stuff in future, if my eyes get better Hoping your eyes get better soon.
Re: [dev] Suckless paint/graphic editor program
> On Thu, Jul 6, 2023 at 3:36PM wrote: > > That's too much options to check out for me, but a console-based option > > (to me > > that sounds like not needing X11? Because ideally that's what I'd want.. I > > want > > to get rid of a Window manager and in the future use something like dvtm) > > I've been investigating options that don't require X11 as well. I've > only seen two Linux distributions that were able to pull off running > in framebuffer without X, nanolinux which uses nanoX and Rogue Class > Linux. There are more distributions like GRML and INX but they're > mainly console mode only and don't do much with graphics or the > framebuffer. Unfortunately, development on both nanolinux and Rogue > Class Linux systems are no longer active. However, they have some > interesting choices for applications. SDL applications will run in > framebuffer or kmsdrm mode. So you can read documents using bard or > sdlbook without X. If you haven't checked it out, > http://litcave.rudi.ir/ has some great framebuffer programs. I use a > fork of pdftxt (command line program) from there. Also, I've been > experimenting with using netbsd-curses from Sabotage Linux instead of > ncurses. > > Last I checked, framebuffer applications ran great from the command > line, but I don't think they played nice with console window managers. > Was rather disappointed in that and I keep looking for other > alternatives. I even investigated some unusual ideas like using sixel > (there's a fork of SDL to output sixel) with a sixel aware console. > Then you could probably use a console window manager like dvtm or mtm. > However, I think it's too slow to be practical. I have a small and > slowly growing list of console and command line programs that I can > use to replace some of the common tasks I do. Always in search of > other interesting and useful alternatives. This mailing list has had > some great program suggestions posted to it. Sites like K.Mandla's > Inconsolation blog are nice resources too. I believe there are some > tty screen capture programs listed there too if you need one. > I use *BSD systems as much as possible. FreeBSD has a framebuffer thing, and just running `mpv video.fuck` in a TTY, X11 down, immediately plays in the TTY, which in my opinion is even easier than it was on GNU/Linux last time I tried it! Really, SDL can do that? NEAT! I dream of a FPS multiplayer game alike CS:GO that can be played in a console! A buddy of mine 'drummyfish' made a game called 'Anarch', it has a few grapical settings such as 'SDL', 'terminal', etc.. it's more suckless than Doom (the old old one using a few kb of ram). So one could steal that (he's okay with it) technology (it's reaally low SLOC) and make such a game. This game would ideally be I2P-only :) So yeah.. not sure how much FPS one could get lmao, but my thinking is basically this: X11 windows and shit draws pixls, right? Terminal does the same thing, just with a lot less mess, a lot less things to do, so in theory it should be even more performant?? Not sure about the direct graphics thing, but like text-output, that should be quite easy, although not sure how great for a FPS.. but who knows? One could make it function say on a 1920x1080 screen, but what about lower-res? not sure.. I am in no way, shape or form knowledgable about any of this enough, so perhaps someone has some insight? I'd love if we could use the GPU directly like pixel changes, etc, without all the 100 fancy APIs, managers, etc. What also amazes me is how one can change console/TTY brightness only (to my knowledge) trough xrandr beforehands in X11 lol.. but xrandr says no display otherwise.. funny. Will check out this stuff in future, if my eyes get better :( I can barely write this fucking e-mail.. You never realize how much things you want to do, to achieve, until it's long gone, until you cannot possibly do them anymore... for the time being. I'm glad there are folks around like you :)
Re: [dev] Problem with windows name
Thank you so much Страхиња Радић!
This works perfectly.
André.
On 10/07/2023 9:35, Страхиња Радић wrote:
> I managed to fix root window title being shown incorrectly by skipping
> conversion only for root window. I attached a patch with this message. Feel
> free to review it, I will make any necessary corrections.
> From c5b399e138f6873e2eb9a292d55c5382e654f074 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?=D0=A1=D1=82=D1=80=D0=B0=D1=85=D0=B8=D1=9A=D0=B0=20=D0=A0?=
> =?UTF-8?q?=D0=B0=D0=B4=D0=B8=D1=9B?=
> Date: Mon, 10 Jul 2023 09:25:30 +0200
> Subject: [PATCH] dwm.c: Always convert title to UTF-8, except for root window
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Window names containing only ISO 8859-1 were broken on the location of
> non-ASCII ISO 8859-1 character, for example áâãéíóôúç, because they were
> treated as UTF-8. When commenting out the if-branch testing for XA_STRING,
> root
> window title, usually set by status programs such as slstatus to UTF-8 text,
> was not shown correctly, so this patch adds an exception for root window
> instead, skipping conversion in that case.
>
> Reported by Dr. André Desgualdo Pereira.
>
> Signed-off-by: Страхиња Радић
> ---
> dwm.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/dwm.c b/dwm.c
> index f1d86b2..c896325 100644
> --- a/dwm.c
> +++ b/dwm.c
> @@ -917,7 +917,10 @@ gettextprop(Window w, Atom atom, char *text, unsigned
> int size)
> text[0] = '\0';
> if (!XGetTextProperty(dpy, w, , atom) || !name.nitems)
> return 0;
> - if (name.encoding == XA_STRING) {
> + /*if (name.encoding == XA_STRING) {
> + strncpy(text, (char *)name.value, size - 1);
> + } else */
> + if (w == DefaultRootWindow(dpy)) {
> strncpy(text, (char *)name.value, size - 1);
> } else if (XmbTextPropertyToTextList(dpy, , , ) >= Success
> && n > 0 && *list) {
> strncpy(text, *list, size - 1);
> --
> 2.38.5
>
--
Dr. André Desgualdo Pereira
Psiquiatra - CRM/SP: 120218 - RQE: 61032
WhatsApp: (11) 985-847-809 - email: des...@gmail.com
Consultório Lapa: Rua Clélia, 2208 - sala 307
Consultório Santana: Av. Gen. Ataliba Leonel, 93 - sala 61
Re: [dev] Minimalist software. Should I care?
On Wed, Jul 05, 2023 at 09:59:27AM -0500, Dave Blanchard wrote: > On Wed, 5 Jul 2023 11:56:58 +0300 > Sergey Matveev wrote: > > > >I did manage to open you article, although I had to use a VPN. For some > > >reason website doesn't load without it. Greetings from Russia! > > > > It is available only through IPv6. I use https://ipv6.ip4market.ru/ > > tunnel broker here to reach that non-legacy modern Internet world. > > LOL! And here we have yet another example of the absolute nuttery of this > community. > > "Non-legacy modern internet world." Last I checked, the "modern" internet > still runs on IPV4, not IPV6! It's only a few eggheads wearing pocket > protectors who--in their frequent hitting of the crack pipe-- insist that > IPV6 is any kind of widespread, ubiquitous standard and the "few people" > still using IPV4 are somehow antiquated and backwards. > > You really think I want every single atom in my house to be individually > addressible and reachable by the outside world? IPV4 is one of the few > reasons why my local computing resources can still have ANY privacy! > > What if I told you the entire internet in general is garbage and all of you > are fools for thinking it's anything special? > > KILL THE NET. > > Dude, we ran out of IPv4 addresses, there is no way to maintain IPv4 internet any further and it was late to switch years ago. Besides, nobody forces you to allow traffic from outside to your local computing resources even on IPv6. I admit I'm not sure if all my services at plch.xyz are IPv6, but there should be more push for that standard in general. -- # Marcel Plch () ascii ribbon campaign - against html e-mail /\- against proprietary attachments ## What is that .asc attachment on my e-mails? * https://gnupg.org/ ## Contact: * Website: https://plch.xyz * Gitea: https://gitea.plch.xyz/dormouse * Matrix: @dormouse:matrix.org signature.asc Description: PGP signature
Re: [dev] Problem with windows name
I managed to fix root window title being shown incorrectly by skipping
conversion only for root window. I attached a patch with this message. Feel
free to review it, I will make any necessary corrections.
From c5b399e138f6873e2eb9a292d55c5382e654f074 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A1=D1=82=D1=80=D0=B0=D1=85=D0=B8=D1=9A=D0=B0=20=D0=A0?=
=?UTF-8?q?=D0=B0=D0=B4=D0=B8=D1=9B?=
Date: Mon, 10 Jul 2023 09:25:30 +0200
Subject: [PATCH] dwm.c: Always convert title to UTF-8, except for root window
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Window names containing only ISO 8859-1 were broken on the location of
non-ASCII ISO 8859-1 character, for example áâãéíóôúç, because they were
treated as UTF-8. When commenting out the if-branch testing for XA_STRING, root
window title, usually set by status programs such as slstatus to UTF-8 text,
was not shown correctly, so this patch adds an exception for root window
instead, skipping conversion in that case.
Reported by Dr. André Desgualdo Pereira.
Signed-off-by: Страхиња Радић
---
dwm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/dwm.c b/dwm.c
index f1d86b2..c896325 100644
--- a/dwm.c
+++ b/dwm.c
@@ -917,7 +917,10 @@ gettextprop(Window w, Atom atom, char *text, unsigned int size)
text[0] = '\0';
if (!XGetTextProperty(dpy, w, , atom) || !name.nitems)
return 0;
- if (name.encoding == XA_STRING) {
+ /*if (name.encoding == XA_STRING) {
+ strncpy(text, (char *)name.value, size - 1);
+ } else */
+ if (w == DefaultRootWindow(dpy)) {
strncpy(text, (char *)name.value, size - 1);
} else if (XmbTextPropertyToTextList(dpy, , , ) >= Success && n > 0 && *list) {
strncpy(text, *list, size - 1);
--
2.38.5
signature.asc
Description: PGP signature
Re: [dev] Problem with windows name
Adding to gettextprop in dwm.c:
// ...
if (!XGetTextProperty(dpy, w, , atom) || !name.nitems)
return 0;
FILE* log = fopen("/home/user/dwm.log", "at");
fprintf(log, "---\n");
fprintf(log, "atom = {%lu}\n", atom);
fprintf(log, "text = {%s}\n", text);
fprintf(log, "value= {%s}\n", name.value);
fprintf(log, "encoding = {%lu}\n", name.encoding);
fprintf(log, "format = {%d}\n", name.format);
fprintf(log, "nitems = {%lu}\n", name.nitems);
fclose(log);
if (name.encoding == XA_STRING) {
// ...
I got:
---
atom = {39}
text = {}
value= {thistest.odt - LibreOffice Writer}
encoding = {31}
format = {8}
nitems = {34}
---
atom = {39}
text = {}
value= {thistestL.odt - LibreOffice Writer}
encoding = {385}
format = {8}
nitems = {38}
So COMPOUND_TEXT sets the encoding field of XTextProperty to 385, a value not
listed in Xatom.h, while STRING sets it to 31 (XA_STRING). The code:
if (name.encoding == XA_STRING) {
strncpy(text, (char *)name.value, size - 1);
} else if (XmbTextPropertyToTextList(dpy, , , ) >= Success
&& n > 0 && *list) {
strncpy(text, *list, size - 1);
XFreeStringList(list);
}
converts any string not having XA_STRING as encoding with
XmbTextPropertyToTextList[1].
The issue is that ISO 8859-1-encoded text, marked as XA_STRING, is copied with
strncpy, and treated as UTF-8 later on in drw_text in drw.c. It probably should
be converted to UTF-8 from the current locale, even when encoding field is set
to XA_STRING. However, when I commented out the first branch like this:
/*if (name.encoding == XA_STRING) {
strncpy(text, (char *)name.value, size - 1);
} else*/ if (XmbTextPropertyToTextList(dpy, , , ) >= Success
&& n > 0 && *list) {
strncpy(text, *list, size - 1);
XFreeStringList(list);
}
The document title in LibreOffice was shown correctly. *However*, the output
from slstatus, containing UTF-8 while having the encoding field also set to
XA_STRING, was *not* shown correctly, even though the description of
XmbTextPropertyToTextList states that
> The input text strings must be given in the current locale encoding (for
> XmbTextListToTextProperty and XwcTextListToTextProperty), or in UTF-8
> encoding
> (for Xutf8TextListToTextProperty).
and my LANG is set to sr_RS.UTF-8 (so my "current locale encoding" should be
UTF-8).
So, this would be a workaround, but one with further potential issues.
[1]: https://linux.die.net/man/3/xmbtextpropertytotextlist
