| View previous topic :: View next topic |
| Author |
Message |
nurali
Tux's lil' helper
Joined: 17 Nov 2022
Posts: 146
Location: Somewhere,Earth
|
 Posted: Sun Mar 10, 2024 6:45 am Post subject: [SOLVED]mupdf has no WM_CLASS? |
 |
|
Hello all:
When I was configuring window rules on DWM,I found that I can not get a WM_CLASS(String) property of mupdf by using xprop
Window rules in DWM need WM_CLASS to identify the client
Is this a bug?
If not,is it hidden?
What is the WM_CLASS of it?
I tried to put this in /usr/share/applications/mupdf.desktop:
| Code: | | StartupWMClass=MuPDF |
But did not work
Plz somebody teach me something
SOLVED BY THIS:
https://bugs.ghostscript.com/show_bug.cgi?id=702438
Last edited by nurali on Sun Mar 10, 2024 9:50 am; edited 1 time in total |
|
| Back to top |
|
 |
flexibeast
Guru
Joined: 04 Apr 2022
Posts: 324
Location: Naarm/Melbourne, Australia
|
| Posted: Sun Mar 10, 2024 8:39 am Post subject: |
|
|
WM_CLASS is specified in section 4.1.2.5 of the Inter-Client Communication Conventions Manual (ICCCM):
| Quote: | The WM_CLASS property (of type STRING without control characters) contains two consecutive null-terminated strings. These specify the Instance and Class names to be used by both the client and the window manager for looking up resources for the application or as identifying information. This property must be present when the window leaves the Withdrawn state and may be changed only while the window is in the Withdrawn state. Window managers may examine the property only when they start up and when the window leaves the Withdrawn state, but there should be no need for a client to change its state dynamically.
The two strings, respectively, are:
[snip discussion of WM_NAME]
• A string that names the general class of applications to which the client that owns this window belongs. Resources that are specified by class apply to all applications that have the same class name. Class names are specified by the application writer. Examples of commonly used class names include: ‘‘Emacs’’, ‘‘XTerm’’, ‘‘XClock’’, ‘‘XLoad’’, and so on. Note that WM_CLASS strings are null-terminated and, thus, differ from the general conventions that STRING properties are null-separated. This inconsistency is necessary for backwards compatibility. |
WM_CLASS does not appear to be mentioned in x11_main.c in the MuPDF sources, which might or might not be a 'bug', depending on the extent to which MuPDF claims to follow the ICCCM, and also on the interpretation of the first quoted paragraph (which i can't interpret myself, as i'm not sufficiently familiar with X internals). |
|
| Back to top |
|
|
nurali
Tux's lil' helper
Joined: 17 Nov 2022
Posts: 146
Location: Somewhere,Earth
|
| Posted: Sun Mar 10, 2024 9:08 am Post subject: |
|
|
| flexibeast wrote: | WM_CLASS is specified in section 4.1.2.5 of the Inter-Client Communication Conventions Manual (ICCCM):
| Quote: | The WM_CLASS property (of type STRING without control characters) contains two consecutive null-terminated strings. These specify the Instance and Class names to be used by both the client and the window manager for looking up resources for the application or as identifying information. This property must be present when the window leaves the Withdrawn state and may be changed only while the window is in the Withdrawn state. Window managers may examine the property only when they start up and when the window leaves the Withdrawn state, but there should be no need for a client to change its state dynamically.
The two strings, respectively, are:
[snip discussion of WM_NAME]
• A string that names the general class of applications to which the client that owns this window belongs. Resources that are specified by class apply to all applications that have the same class name. Class names are specified by the application writer. Examples of commonly used class names include: ‘‘Emacs’’, ‘‘XTerm’’, ‘‘XClock’’, ‘‘XLoad’’, and so on. Note that WM_CLASS strings are null-terminated and, thus, differ from the general conventions that STRING properties are null-separated. This inconsistency is necessary for backwards compatibility. |
WM_CLASS does not appear to be mentioned in x11_main.c in the MuPDF sources, which might or might not be a 'bug', depending on the extent to which MuPDF claims to follow the ICCCM, and also on the interpretation of the first quoted paragraph (which i can't interpret myself, as i'm not sufficiently familiar with X internals). |
Thank you for replying
Someone(actually two) reported bug about this on mupdfs' bugzilla,but it seems like that nobody care about this
Someone posted a patched source file,may be I should try to compile it.or make a patch to patch current mupdf |
|
| Back to top |
|
|
nurali
Tux's lil' helper
Joined: 17 Nov 2022
Posts: 146
Location: Somewhere,Earth
|
| Posted: Sun Mar 10, 2024 9:49 am Post subject: |
|
|
| flexibeast wrote: | WM_CLASS is specified in section 4.1.2.5 of the Inter-Client Communication Conventions Manual (ICCCM):
| Quote: | The WM_CLASS property (of type STRING without control characters) contains two consecutive null-terminated strings. These specify the Instance and Class names to be used by both the client and the window manager for looking up resources for the application or as identifying information. This property must be present when the window leaves the Withdrawn state and may be changed only while the window is in the Withdrawn state. Window managers may examine the property only when they start up and when the window leaves the Withdrawn state, but there should be no need for a client to change its state dynamically.
The two strings, respectively, are:
[snip discussion of WM_NAME]
• A string that names the general class of applications to which the client that owns this window belongs. Resources that are specified by class apply to all applications that have the same class name. Class names are specified by the application writer. Examples of commonly used class names include: ‘‘Emacs’’, ‘‘XTerm’’, ‘‘XClock’’, ‘‘XLoad’’, and so on. Note that WM_CLASS strings are null-terminated and, thus, differ from the general conventions that STRING properties are null-separated. This inconsistency is necessary for backwards compatibility. |
WM_CLASS does not appear to be mentioned in x11_main.c in the MuPDF sources, which might or might not be a 'bug', depending on the extent to which MuPDF claims to follow the ICCCM, and also on the interpretation of the first quoted paragraph (which i can't interpret myself, as i'm not sufficiently familiar with X internals). |
It worked,I made a patch and put it in /etc/portage/patches now it has a WM_CLASS |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
