Detect if a X11 window has decorations - x11

This C function can be used to disable or enable windows decorations in many window managers. If 'mode' is 'd' the window will hide the decorations, otherwise if the 'mode' is 'D' the window will show them.
void window_tune_decorations(Display *disp, Window win, char mode) {
long hints[5] = { 2, 0, 0, 0, 0};
Atom motif_hints = XInternAtom(disp, "_MOTIF_WM_HINTS", False);
switch (mode) {
case 'D':
hints[2] = 1;
/* fall through */
case 'd':
XChangeProperty(disp, win, motif_hints, motif_hints, 32, PropModeReplace, (unsigned char *)hints, 5);
break;
default:
fputs("Invalid mode.\n", stderr);
}
}
I would like to implement a ``toggle mode''. So my question is, there a way to detect if a windows has the decorations?
I tried using XGetWindowProperty with _MOTIF_WM_HINTS, but I am not sure how to interpret the output.

You interpret the data you get from XGetWindowProperty the same way you interpret data sent to XChangeProperty.
In the case of _MOTIF_WM_HINTS it's an array of 5 longs, or perhaps the struct MwmHints (syn. MotifWmHints). It's a struct of 5 long fields, plus several #defined bit flags. It is inherited from the Motif window manager, but we don't usually keep Motif includes and libraries around nowadays, so the struct gets copied to various places (bad practice but everyonee is doing it). You may find its definition in xprops.h of Gnome and several other places. Look it up on the 'net and copy to your code, or find it in an include file you already depend on, or just look at the definition and keep using the array of 5 longs, your choice.
You need to check the right flags in the right fields. For decorations, check if the window is override-redirect first. If it is, it is undecorated (obviously) and you cannot add any decorations. If the window manager is not running, it's undecorated as well, and you cannot add any decorations in this case too.
Otherwise, if the window does not have the property at all (XGetWindowProperty sets type to None), you may assume it's decorated.
If it does have the property, and MWM_HINTS_DECORATIONS bit is set in flags, then it has exactly the decorations specified in the decorations field by the MWM_DECOR_* bit values. If the field is non-zero, there are some decorations present. AFAIK if MWM_HINTS_DECORATIONS is unset, then the window is (surprisingly) decorated. But please test this yourself, I don't remember and don't have an X11 machine around at the moment so I can't check it.
Naturally, some window managers don't use _MOTIF_WM_HINTS (e.g. ones that were around before Motif). If you have one of those, you cannot check or set decorations with this method.
Don't forget to XFree(hints).

Related

optional vertexbufferobjects in directx11

I have some models (geometries) which have some vertexinformation. For example position, normal, color, texcoord each of this information has its own vertexbuffer. But some of these models have texture coordinates some not...
To manage these differences I wrote a vertexshader which is checking, if the flag inside the constantbuffer "hasTextureCoordinates" is == 1. And if so it uses the texcoord parameter or not.
But Directx does not realy like this workaround and prints out:
D3D11 INFO: ID3D11DeviceContext::Draw: Element [3] in the current Input Layout's declaration references input slot 3, but there is no Buffer bound to this slot. This is OK, as reads from an empty slot are defined to return 0. It is also possible the developer knows the data will not be used anyway. This is only a problem if the developer actually intended to bind an input Buffer here. [ EXECUTION INFO #348: DEVICE_DRAW_VERTEX_BUFFER_NOT_SET]
I'm not sure if every hardware handles this correctly, also it's not nice to see inside the output this "warnings" every frame...
I know i could write two shaders, one with and one without texcoods, but the problem is that this is not the only maybe missing parameter... some has color other not, some has color and texturecoordinates and so on. And to write a shader for each combination of vertexbuffer inputs is extremly redundant. this is extremly bad, because if we change one shader, we have to change all other too. There is also the possibility of put parts of the shader to different files and include them, but it's confusing.
Is there a way to say directx that the specific vertexbuffer is optional?
Or does someone knows a better solution for this problem?
You can suppress this specific message programmatically. As it's an INFO rather than an ERROR or CORRUPTION message, it's safe to ignore.
#include <wrl/client.h>
using Microsoft::WRL::ComPtr;
ComPtr<ID3D11Debug> d3dDebug;
if ( SUCCEEDED( device.As(&d3dDebug) ) )
{
ComPtr<ID3D11InfoQueue> d3dInfoQueue;
if ( SUCCEEDED( d3dDebug.As(&d3dInfoQueue) ) )
{
#ifdef _DEBUG
d3dInfoQueue->SetBreakOnSeverity( D3D11_MESSAGE_SEVERITY_CORRUPTION, true );
d3dInfoQueue->SetBreakOnSeverity( D3D11_MESSAGE_SEVERITY_ERROR, true );
#endif
D3D11_MESSAGE_ID hide[] =
{
D3D11_MESSAGE_ID_SETPRIVATEDATA_CHANGINGPARAMS,
D3D11_MESSAGE_ID_DEVICE_DRAW_VERTEX_BUFFER_NOT_SET, // <--- Your message here!
// Add more message IDs here as needed
};
D3D11_INFO_QUEUE_FILTER filter = {};
filter.DenyList.NumIDs = _countof(hide);
filter.DenyList.pIDList = hide;
d3dInfoQueue->AddStorageFilterEntries( &filter );
}
}
In addition to suppressing 'noise' messages, in debug builds this also causes the debug layer to generate a break-point if you do hit a ERROR or CORRUPTION message as those really need to be fixed.
See Direct3D SDK Debug Layer Tricks
Note I'm using ComPtr here to simplify the QueryInterface chain, and I assume you are keeping your device as a ComPtr<ID3D11Device> device as I do in in Anatomy of Direct3D 11 Create Device
I also assume you are using VS 2013 or later so that D3D11_INFO_QUEUE_FILTER filter = {}; is sufficient to zero-fill the structure.

aborting Windows IME composition / clearing composition string

I'm having trouble aborting IME composition on Windows.
I'm handling WM_IME_STARTCOMPOSITION and positioning my candidate window, and WM_IME_COMPOSITION as I press a key to start composing as you'd expect. I'm then handling WM_IME_ENDCOMPOSITION at the end and normal use cases are fine.
However, my problem is when I change focus inside of the application. I don't receive WM_IME_ENDCOMPOSITION so I have to deal with this situation manually. What I am doing is this:
ImmNotifyIME( himc, NI_COMPOSITIONSTR, CPS_CANCEL, 0 );
ImmNotifyIME( himc, NI_CLOSECANDIDATE, 0, 0 );
The candidate list correctly disappears, but the composition string isn't cleared. If I then call ImmGetCompositionString with GCS_COMPSTR, it's still there. Therefore if I give focus back, receive WM_IME_STARTCOMPOSITION and the first WM_IME_COMPOSITION - I end up inheriting the previous composition string, which I don't want. I want to start afresh.
ImmSetCompositionString() looks also like it would work but I can't figure out how to get it to clear the string.
Does anyone have any suggestions? MSDN seems to suggest that the calls to ImmNotifyIME() would do the job, but I must be missing something.
You may clear composition with this:
ImmSetCompositionStringW(himc, SCS_SETSTR, L"", sizeof(wchar_t), L"", sizeof(wchar_t));
In addition, in my application, when input loses focus I release input context:
ImmReleaseContext(hwnd, himc);
And get it again when focus gained:
ImmGetContext(hwnd);

How to I set the default startup window size for an X11 application (such as xmgrace)

I've been trying to run through the .Xresources method, with no success (see comment here from a related question)
So what do I need to modify to make sure my Xmgrace window is of a particular size? When I run xmgrace myplot.agr it always ends up as a 680x700 window. I would like to set it to something different, as I always end up having to resize and click-scroll (Xmgrace does not like scroll-wheels).
Any thoughts or ideas most welcome.
Per comments (and source), you could set the size and position of xmgrace in your $HOME/.Xdefaults file:
XMgrace*geometry: 1050x750
or (more specific)
XMgrace*mainWin.geometry: 1050x750
depending on how it uses the geometry resource during initialization.
The FAQ does not give more than a hint of the available resources, but is pretty clear that the classname is XMgrace. To get a complete list of resources, you'd have to read the source-code, which (for instance) in /src/xmgrace.c has
String fallbackResourcesHighRes[] = {
"XMgrace*mainWin.width: 680",
"XMgrace*mainWin.height: 700",
"XMgrace*fontList:-*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*",
"XMgrace.consoleDialog*text.fontList:-*-courier-medium-r-normal-*-12-*-*-*->
"XMgrace*HContainer.marginHeight: 3",
"XMgrace*VContainer.marginHeight: 3",
NULL
};
It decides to use that based on the screensize:
screen = DefaultScreenOfDisplay(disp);
if (HeightOfScreen(screen) < 740) {
lowres = TRUE;
}
and (seeing no command-line arguments in the source) is configurable only using X resources. The -geometry option is a standard X toolkit option, used by other programs such as xterm.

What is the maximum length of a window title passed to SetWindowText?

The SetWindowText function's documentation does not set a limit on the length of the string that may be used as a window title.
In the documentation for WM_SETTEXT (the message sent by calling SetWindowText), it is noted that the return value of this message's processing may be:
FALSE (for an edit control), LB_ERRSPACE (for a list box), or CB_ERRSPACE (for a combo box) if insufficient space is available to set the text in the edit control.
However, it says nothing about the case when a window's title is being set. Is a strict limit set, or is it up to the programmer to use common sense to provide their own title length limit?
I have posted this because I am developing a graphics engine which allows the user to supply their own title for the main window. The idea is that I would define a constant such as
const static int MAX_APP_TITLE_LENGTH = /* ??? */;
within my application class, and check the length of the user-provided title string against this.
If the title string is too long, I can throw a warning message and truncate it, rather than passing it straight into SetWindowText with unintended consequences.
EDIT: After some discussion in the comments, it seems that Windows will not complain even if a string of length 100,000 is used as a window title, so this issue is not worth worrying about (beyond the basic sanitization of input, of course)!
There is technically no limit to the title size, but the lpClassName field has a strict limit of 256 chars (i didnt want you to think you could have an infinite class name and your code crash.)
SOURCE: https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-wndclassexw

Predefined Windows icons: Unicode

I am assigning to the lpszIcon member of the MSGBOXPARAMSW structure(notice the W). I want to use one of the predefined icons like IDI_APPLICATION or IDI_WARNING but they are all ASCII (defined as MAKEINTRESOURCE). I tried doing this:
MSGBOXPARAMSW mbp = { 0 };
mbp.lpszIcon = (LPCWSTR) IDI_ERROR;
but then no icon displayed at all. So how can I use the unicode versions of the IDI_ icons?
There is no ANSI or Unicode variant of a numeric resource ID. The code that you use to set lpszIcon is correct. It is idiomatic to use the MAKEINTRESOURCE macro rather than a cast, but the cast has identical meaning. Your problem lies in the other code, the code that we cannot see.
Reading between the lines, I think that you are targeting ANSI or MBCS. You tried to use MAKEINTRESOURCE but that expands to MAKEINTRESOURCEA. That's what led you to cast. You should have used MAKEINTRESOURCEW to match MSGBOXPARAMSW. That would have resolved the compilation error you encountered. You could equally have changed the project to target UNICODE.
But none of that explains why the icon does not appear in the dialog. There has to be a problem elsewhere. If the dialog appears then the most likely explanation is that you have set hInstance to a value other than NULL. But the code to set lpszIcon is correct, albeit not idiomatic.

Resources