Hi.
I have installed mupdf. It has two binaries - mupdf-x11 and mupdf-gl. When I use mupdf-x11 the window is identified as Class: mupdf
and Resource: MuPDF
. I identified the icon for mupdf in the config Style mupdf EWMHMiniIconOverride, MiniIcon $[fvwm_icon]/mupdf.png
. When I use mupdf-gl the window is not identified Class: Noclass
and Resource: Noresource
. Nothing is changed when I use Style mupdf-gl EWMHMiniIconOverride, MiniIcon $[fvwm_icon]/mupdf.png
. The question - How to define window for mupdf-gl and icon for it?
You can also use the window name or icon name. But if a window doesn’t define a class/resource, that is a bug in the app, and not much fvwm can do afiak. So hopefully the IconName or WindowName can be used in this case.
I found a discussion about mupdf here. Indeed, mupdf-x11 has WM_CLASS(STRING) = “mupdf”, “MuPDF”, but mupdf-gl has no. A solution suggested there does not work. Could you please explain a little bit more about how could I use IconName or WindowName instead?
You use them the same way you use the class/resource, Style WindowName ....
, (you can also use wildcards like *
). You can use FvwmIdent
to list the window name/iconname/class/resource, so you have more than just class and resource to match.
Thanks. But I do not understand what is WindowsName for mupdf-gl? Could you write the string Style WindowsName for this specific case? If I understood you right I have to define this by using FvwmIdent?
I don’t know what the window name is either. Hence why I gave you a tool that you can use to find it.
Hi @JoePass. @somiaj point you to the right direction, but seems you need a step-by-step guide. So… here we go:
- Run mupdf
- Open FvwnComsole (or FvwmPrompt)
- Type
FvwmIdent
. Then hit enter. - Click mupdf
- Take a look at the information provided by
FvwmIdent
. Check whatWindowName
reports. - Create the desired style using the WindowName reported by
FvwmIdent
. As @somiaj points out you can use wildcards in case you need them.
I understand how to take info. In fact no need for FvwmConsole. It is faster to find it in the left upper corner of the opened window. My question was that there is no WindowName in this info.
There is Name, only, but it is simply the name of the file.
The Name is the Window Name, though it appears that it uses the filename, so this maybe a bit hard to match, maybe do *.pdf*
and it will match any window that has .pdf
in its Name. The problem could be matching other windows depending on your use case.
You might also be able to do "*.pdf - *"
to match the dash in the name.
In fact, there is no correct solution to this problem. The only way is to ask the maintainers of mupdf. In the URL above, the user asked him 3 years ago and they did not make any corrections. They suggested changing the code before compilation. I tried, but it does not work. In any case, I will use mupdf-gl but without an icon.
My friend programmer helped me and we found a solution by changing the source code of mupdf before compilation. In the file thirdparty/freeglut/src/x11/fg_menu_x11.c
two changing are made
- After definition the function
fgPlatformOpenWindow
we includedXClassHint *classhint;
. This block now read
void fgPlatformOpenWindow( SFG_Window* window, const char* title,
GLboolean positionUse, int x, int y,
GLboolean sizeUse, int w, int h,
GLboolean gameMode, GLboolean isSubWindow )
{
XClassHint *classhint;
- After
XSetWMProtocols
:
classhint = XAllocClassHint();
if (classhint)
{
classhint->res_name = "mupdf";
classhint->res_class = "MuPDF";
XSetClassHint(fgDisplay.pDisplay.Display, window->Window.Handle, classhint);
XFree(classhint);
}
After compilation, the window of mupdf-gl is identified as WM_CLASS(STRING) = "mupdf", "MuPDF"
By using this method it is possible to make a different class for mupdf-x11 and mupdf-gl simply changing the class in above code for what you want. Maybe it will help for somebody.
You should send a patch to upstream.
Sorry, I did not make this at once. I do not know how to do this