Re: [dev] Problem with windows name

2023-07-09 Thread Страхиња Радић
I debugged dwm, adding to drw.c:

static void
log_msg(const char* fmt, ...)
{
char buf[4096];
va_list args;
va_start(args, fmt);
vsnprintf(buf, sizeof(buf), fmt, args);
va_end(args);
fprintf(logfile, "%s\n", buf);
}

and calls to utf8decodebyte:

static long
utf8decodebyte(const char c, size_t *i)
{
   for (*i = 0; *i < (UTF_SIZ + 1); ++(*i))
   if (((unsigned char)c & utfmask[*i]) == utfbyte[*i])
   {
   log_msg("*i = %lu, for '%c' returning '%c'",
   *i, c, (unsigned char)c & ~utfmask[*i]);
   return (unsigned char)c & ~utfmask[*i];
   }
   return 0;
}

and drw_text:
utf8str = text;
nextfont = NULL;
while (*text) {
   log_msg("*text == '0x%X' == '%c'",
   *text, *text);
   utf8charlen = utf8decode(text, , 
UTF_SIZ);
   for (curfont = drw->fonts; curfont; curfont = 
curfont->next) {
   charexists = charexists || 
XftCharExists(drw->dpy, curfont->xfont, utf8codepoint);

I got the following output from "thisátest.odt"

// á
*text == '0xFFE1' == ''
*i = 3, for '' returning '^A'
*i = 1, for 't' returning 't'
*text == '0x74' == 't'
*i = 1, for 't' returning 't'

and the following from "thisátestњ.odt":

// á
*text == '0xFFC3' == ''
*i = 2, for '' returning '^C'
*i = 0, for '' returning '!'
[...]
// њ
*text == '0xFFD1' == ''
*i = 2, for '' returning '^Q'
*i = 0, for '<9A>' returning '^Z'

From here, it seems that dwm is receiving correct UTF-8 representations of "á"
(0xC3 0xA1) and "њ" (0xD1 0x9A) for "thisátestњ.odt", but it receives
ISO 8859-1 representation of "á" (no wonder, given it is passed a STRING 
instead 
of UTF8_STRING or COMPOUND_TEXT), 0xE1, followed by the next ASCII character, 
0x74 ("t"), still interpreting the two as UTF-8 sequence, when those two bytes 
form an invalid UTF-8. That invalid UTF-8 is further passed to libfreetype or 
whatever, which just interrupts output at that point.


signature.asc
Description: PGP signature


Re: [dev] Problem with windows name

2023-07-09 Thread Страхиња Радић
On 23/07/09 08:43AM, Dr. André Desgualdo Pereira wrote:
> # xprop
> xprop shows the correct name, but it doesn't has the _NET_WM_NAME defined as 
> it used to have on Debian 11 and before (I guess it is because missing 
> library 
> tkinter for python2.7).
> Example: WM_NAME(STRING) = "André Desgualdo.odt - OpenOffice Writer"

I have made two files, one with á and ASCII characters and another with added 
њ. The results from xprop are:

WM_NAME(STRING) = "thisátest.odt - LibreOffice Writer"
^^
WM_NAME(COMPOUND_TEXT) = "thisátestњ.odt - LibreOffice Writer"
^

This implies that this is a X.Org issue. Strings having only ISO 8859-1 
characters are silently degraded to STRINGs when they should really be 
COMPOUND_TEXT.


signature.asc
Description: PGP signature


Re: [dev] Suckless paint/graphic editor program

2023-07-09 Thread LM
On Thu, Jul 6, 2023 at 3:36 PM  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.



[dev] Problem with windows name

2023-07-09 Thread Dr . André Desgualdo Pereira
# The Problem:
dwm status bar fails to display the name of Libreoffice and OpenOffice windows

# Conditions (when it happens):
1) Debian 12 (previous Debian worked fine)
2) The file name must contain a latin character (one of these: 
áâãéíóôúç) and NOT contain other glyphs characters (for example Japanese 你)

# Examples:

name of the filename displayed on dwm status 

"André Desgualdo.odt"   ->  "Andr Desgualdo.odt - OpenOffice 
Writer" (wrong, it miss the é)
"Andre Desgualdo.odt"   ->  "Andre Desgualdo.odt - OpenOffice 
Writer" (right)
"你 André Desgualdo.odt"->  "你 André Desgualdo.odt - OpenOffice 
Writer" (right)
"André Desgualdo 你.odt"->  "André Desgualdo 你.odt - OpenOffice 
Writer" (right)

# xprop
xprop shows the correct name, but it doesn't has the _NET_WM_NAME defined as it 
used to have on Debian 11 and before (I guess it is because missing library 
tkinter for python2.7).
Example: WM_NAME(STRING) = "André Desgualdo.odt - OpenOffice Writer"

# xwininfo
But xwininfo also fails to show the name properly.
Example: xwininfo: Window id: 0xe031bd "Andr Desgualdo.odt - OpenOffice Writer"

# Other window managers
Other window managers show the window's name correctly. Tested: xfce4wm and 
i3wm. 

# Other programs that are not Libreoffice or OpenOffice
When opening the same file with other program (for example opening "André 
Desgualdo.odt" with file-roller), the name is displayed correctly and xprop 
shows the following info: _NET_WM_NAME(STRING) = "Andr\303\251 Desgualdo.odt - 
OpenOffice"). 

# Workaround
Any suggestion to further investigate or possible workarounds or fix would be 
really appreciated. 
(Currently I made a script to use xdotool to rename the window as soon as it is 
opened by OpenOffice).