Read X window property of non client area
How to read property of X window non-client area (window manager's window)? I set X property by XChangeProperty in my C program. When using xprop and selecting non client area (I mean: titlebar of the window) by mouse, properties of window created by my application aren't displayed.
I tested both cases. When using xprop 8s name_of_non_registered_property and xprop 8s name_of_registered_property message is different, so I correctry create XAtom.
I test xprop only on Plasma5.15 (KWin working under X.org)
I'm mixing GTK+2 and XCB (or XLib) code. When using XListProperty, XGetAtomName on elements from previous call to previous function and result of XGetAtomName put to puts (C stdlib), name of my atom is visible. Maybe GTK mess, when invoking main loop first time? I realize the window before add my property to it.
I think, that rather programming problem than system.
> xwininfo -all -root
....
0xba00001 "program": ("program" "Program") 10x10+10+10 +10+10
1 child:
0xba00002 (has no name): () 1x1+-1+-1 +9+9
...
>xprop -id 0xba00001
WM_CLASS(STRING) = "program", "Program"
WM_COMMAND(STRING) = { "program" }
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0xba00002
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 29562975
WM_CLIENT_LEADER(WINDOW): window id # 0xba00001
_NET_WM_PID(CARDINAL) = 25223
WM_LOCALE_NAME(STRING) = "pl_PL.UTF-8"
WM_CLIENT_MACHINE(STRING) = "linux-rvnb"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified size: 10 by 10
>xprop -id 0xba00002
>
window-manager x
edited Mar 6 at 16:37
Rui F Ribeiro
41.8k1483142
asked Mar 5 at 7:43
nintyfannintyfan
33
|
show 6 more comments
How to read property of X window non-client area (window manager's window)? I set X property by XChangeProperty in my C program. When using xprop and selecting non client area (I mean: titlebar of the window) by mouse, properties of window created by my application aren't displayed.
I tested both cases. When using xprop 8s name_of_non_registered_property and xprop 8s name_of_registered_property message is different, so I correctry create XAtom.
I test xprop only on Plasma5.15 (KWin working under X.org)
I'm mixing GTK+2 and XCB (or XLib) code. When using XListProperty, XGetAtomName on elements from previous call to previous function and result of XGetAtomName put to puts (C stdlib), name of my atom is visible. Maybe GTK mess, when invoking main loop first time? I realize the window before add my property to it.
I think, that rather programming problem than system.
> xwininfo -all -root
....
0xba00001 "program": ("program" "Program") 10x10+10+10 +10+10
1 child:
0xba00002 (has no name): () 1x1+-1+-1 +9+9
...
>xprop -id 0xba00001
WM_CLASS(STRING) = "program", "Program"
WM_COMMAND(STRING) = { "program" }
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0xba00002
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 29562975
WM_CLIENT_LEADER(WINDOW): window id # 0xba00001
_NET_WM_PID(CARDINAL) = 25223
WM_LOCALE_NAME(STRING) = "pl_PL.UTF-8"
WM_CLIENT_MACHINE(STRING) = "linux-rvnb"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified size: 10 by 10
>xprop -id 0xba00002
>
window-manager x
edited Mar 6 at 16:37
Rui F Ribeiro
41.8k1483142
asked Mar 5 at 7:43
nintyfannintyfan
33
maybe you're not selecting the right window -- wm decorations like titlebars may themselves be subwindows of the the frame window you set your properties on. Anyways, post something reproducible; your question is not clear.
– mosvy
Mar 5 at 9:11
Should I attach C code? That's not stack overflow.
– nintyfan
Mar 5 at 9:29
You should add the output of the two xprop commands.
– ctx
Mar 5 at 10:39
This sounds suspiciously like an XY problem. The non-client parts (e.g. title bar) are managed by the WM, they will be different for different WMs, so relying in any properties there will break as soon as the WM changes. Therefore I'm not surprised trying to get and set them runs into trouble (but what exactly happens probably also depends on the WM). What exactly are you trying to achieve by using properties on non-client areas? I'm pretty sure that whatever it is, there's a correct alternative way to do it.
– dirkt
Mar 5 at 13:02
I will write app-integrated macro recorder. Possible a new design of such programs :-) . App register to window manager it's supports recording macro by setting atom on window and window manager will display dropdown menu with macro-related functions. User could click on first window, select start recording a new macro, set name. I next step he click on other window's titlebar and select attach to macro. Window manager will send XID or other information to daemon, which next asks app for window data (strings representing the state of window).
– nintyfan
Mar 5 at 13:46
|
show 6 more comments
How to read property of X window non-client area (window manager's window)? I set X property by XChangeProperty in my C program. When using xprop and selecting non client area (I mean: titlebar of the window) by mouse, properties of window created by my application aren't displayed.
I tested both cases. When using xprop 8s name_of_non_registered_property and xprop 8s name_of_registered_property message is different, so I correctry create XAtom.
I test xprop only on Plasma5.15 (KWin working under X.org)
I'm mixing GTK+2 and XCB (or XLib) code. When using XListProperty, XGetAtomName on elements from previous call to previous function and result of XGetAtomName put to puts (C stdlib), name of my atom is visible. Maybe GTK mess, when invoking main loop first time? I realize the window before add my property to it.
I think, that rather programming problem than system.
> xwininfo -all -root
....
0xba00001 "program": ("program" "Program") 10x10+10+10 +10+10
1 child:
0xba00002 (has no name): () 1x1+-1+-1 +9+9
...
>xprop -id 0xba00001
WM_CLASS(STRING) = "program", "Program"
WM_COMMAND(STRING) = { "program" }
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0xba00002
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 29562975
WM_CLIENT_LEADER(WINDOW): window id # 0xba00001
_NET_WM_PID(CARDINAL) = 25223
WM_LOCALE_NAME(STRING) = "pl_PL.UTF-8"
WM_CLIENT_MACHINE(STRING) = "linux-rvnb"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified size: 10 by 10
>xprop -id 0xba00002
>
window-manager x
edited Mar 6 at 16:37
Rui F Ribeiro
41.8k1483142
asked Mar 5 at 7:43
nintyfannintyfan
33
How to read property of X window non-client area (window manager's window)? I set X property by XChangeProperty in my C program. When using xprop and selecting non client area (I mean: titlebar of the window) by mouse, properties of window created by my application aren't displayed.
I tested both cases. When using xprop 8s name_of_non_registered_property and xprop 8s name_of_registered_property message is different, so I correctry create XAtom.
I test xprop only on Plasma5.15 (KWin working under X.org)
I'm mixing GTK+2 and XCB (or XLib) code. When using XListProperty, XGetAtomName on elements from previous call to previous function and result of XGetAtomName put to puts (C stdlib), name of my atom is visible. Maybe GTK mess, when invoking main loop first time? I realize the window before add my property to it.
I think, that rather programming problem than system.
> xwininfo -all -root
....
0xba00001 "program": ("program" "Program") 10x10+10+10 +10+10
1 child:
0xba00002 (has no name): () 1x1+-1+-1 +9+9
...
>xprop -id 0xba00001
WM_CLASS(STRING) = "program", "Program"
WM_COMMAND(STRING) = { "program" }
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0xba00002
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 29562975
WM_CLIENT_LEADER(WINDOW): window id # 0xba00001
_NET_WM_PID(CARDINAL) = 25223
WM_LOCALE_NAME(STRING) = "pl_PL.UTF-8"
WM_CLIENT_MACHINE(STRING) = "linux-rvnb"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified size: 10 by 10
>xprop -id 0xba00002
>
window-manager x
window-manager x
edited Mar 6 at 16:37
Rui F Ribeiro
41.8k1483142
asked Mar 5 at 7:43
nintyfannintyfan
33
edited Mar 6 at 16:37
Rui F Ribeiro
41.8k1483142
asked Mar 5 at 7:43
nintyfannintyfan
33
edited Mar 6 at 16:37
Rui F Ribeiro
41.8k1483142
edited Mar 6 at 16:37
Rui F Ribeiro
41.8k1483142
edited Mar 6 at 16:37
Rui F Ribeiro
41.8k1483142
41.8k1483142
asked Mar 5 at 7:43
nintyfannintyfan
33
asked Mar 5 at 7:43
nintyfannintyfan
33
asked Mar 5 at 7:43
nintyfannintyfan
33
33
maybe you're not selecting the right window -- wm decorations like titlebars may themselves be subwindows of the the frame window you set your properties on. Anyways, post something reproducible; your question is not clear.
– mosvy
Mar 5 at 9:11
Should I attach C code? That's not stack overflow.
– nintyfan
Mar 5 at 9:29
You should add the output of the two xprop commands.
– ctx
Mar 5 at 10:39
This sounds suspiciously like an XY problem. The non-client parts (e.g. title bar) are managed by the WM, they will be different for different WMs, so relying in any properties there will break as soon as the WM changes. Therefore I'm not surprised trying to get and set them runs into trouble (but what exactly happens probably also depends on the WM). What exactly are you trying to achieve by using properties on non-client areas? I'm pretty sure that whatever it is, there's a correct alternative way to do it.
– dirkt
Mar 5 at 13:02
I will write app-integrated macro recorder. Possible a new design of such programs :-) . App register to window manager it's supports recording macro by setting atom on window and window manager will display dropdown menu with macro-related functions. User could click on first window, select start recording a new macro, set name. I next step he click on other window's titlebar and select attach to macro. Window manager will send XID or other information to daemon, which next asks app for window data (strings representing the state of window).
– nintyfan
Mar 5 at 13:46
|
show 6 more comments
maybe you're not selecting the right window -- wm decorations like titlebars may themselves be subwindows of the the frame window you set your properties on. Anyways, post something reproducible; your question is not clear.
– mosvy
Mar 5 at 9:11
Should I attach C code? That's not stack overflow.
– nintyfan
Mar 5 at 9:29
You should add the output of the two xprop commands.
– ctx
Mar 5 at 10:39
This sounds suspiciously like an XY problem. The non-client parts (e.g. title bar) are managed by the WM, they will be different for different WMs, so relying in any properties there will break as soon as the WM changes. Therefore I'm not surprised trying to get and set them runs into trouble (but what exactly happens probably also depends on the WM). What exactly are you trying to achieve by using properties on non-client areas? I'm pretty sure that whatever it is, there's a correct alternative way to do it.
– dirkt
Mar 5 at 13:02
I will write app-integrated macro recorder. Possible a new design of such programs :-) . App register to window manager it's supports recording macro by setting atom on window and window manager will display dropdown menu with macro-related functions. User could click on first window, select start recording a new macro, set name. I next step he click on other window's titlebar and select attach to macro. Window manager will send XID or other information to daemon, which next asks app for window data (strings representing the state of window).
– nintyfan
Mar 5 at 13:46
maybe you're not selecting the right window -- wm decorations like titlebars may themselves be subwindows of the the frame window you set your properties on. Anyways, post something reproducible; your question is not clear.
– mosvy
Mar 5 at 9:11
maybe you're not selecting the right window -- wm decorations like titlebars may themselves be subwindows of the the frame window you set your properties on. Anyways, post something reproducible; your question is not clear.
– mosvy
Mar 5 at 9:11
Should I attach C code? That's not stack overflow.
– nintyfan
Mar 5 at 9:29
Should I attach C code? That's not stack overflow.
– nintyfan
Mar 5 at 9:29
You should add the output of the two xprop commands.
– ctx
Mar 5 at 10:39
You should add the output of the two xprop commands.
– ctx
Mar 5 at 10:39
This sounds suspiciously like an XY problem. The non-client parts (e.g. title bar) are managed by the WM, they will be different for different WMs, so relying in any properties there will break as soon as the WM changes. Therefore I'm not surprised trying to get and set them runs into trouble (but what exactly happens probably also depends on the WM). What exactly are you trying to achieve by using properties on non-client areas? I'm pretty sure that whatever it is, there's a correct alternative way to do it.
– dirkt
Mar 5 at 13:02
This sounds suspiciously like an XY problem. The non-client parts (e.g. title bar) are managed by the WM, they will be different for different WMs, so relying in any properties there will break as soon as the WM changes. Therefore I'm not surprised trying to get and set them runs into trouble (but what exactly happens probably also depends on the WM). What exactly are you trying to achieve by using properties on non-client areas? I'm pretty sure that whatever it is, there's a correct alternative way to do it.
– dirkt
Mar 5 at 13:02
I will write app-integrated macro recorder. Possible a new design of such programs :-) . App register to window manager it's supports recording macro by setting atom on window and window manager will display dropdown menu with macro-related functions. User could click on first window, select start recording a new macro, set name. I next step he click on other window's titlebar and select attach to macro. Window manager will send XID or other information to daemon, which next asks app for window data (strings representing the state of window).
– nintyfan
Mar 5 at 13:46
I will write app-integrated macro recorder. Possible a new design of such programs :-) . App register to window manager it's supports recording macro by setting atom on window and window manager will display dropdown menu with macro-related functions. User could click on first window, select start recording a new macro, set name. I next step he click on other window's titlebar and select attach to macro. Window manager will send XID or other information to daemon, which next asks app for window data (strings representing the state of window).
– nintyfan
Mar 5 at 13:46
|
show 6 more comments
1 Answer
1
active
oldest
votes
This command prints all childrens:
xwininfo -all -root
Not all windowmanagers use the root window to show the backround. Clicking on a non client area will show infos about the window that displays the background. To show infos about the root window use:
xprop -root
If you correctly set an atom, xprop can read it. The format part in your xprop command is not necessary:
xprop name_of_registered_property
You might have to traverse all children to find the window with your atom.
If you're not coding the wm, you should ignore the titlebars. They are wm internals, not a client and they are probably not registered for events.
answered Mar 5 at 10:37
ctxctx
1,749515
Thanks. By writing non-client area I mean titlebar.
– nintyfan
Mar 5 at 10:55
1
Please add this information to your question. Since the titlebar is createt by your windowmanager, you should add which wm/de you use too.
– ctx
Mar 5 at 11:02
I will add some info: Use xwininfo -all -root, read the id of child of window using parent's window title. Use xprop -id hexadecimal number present in xwininfo output
– nintyfan
Mar 7 at 10:39
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504415%2fread-x-window-property-of-non-client-area%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
This command prints all childrens:
xwininfo -all -root
Not all windowmanagers use the root window to show the backround. Clicking on a non client area will show infos about the window that displays the background. To show infos about the root window use:
xprop -root
If you correctly set an atom, xprop can read it. The format part in your xprop command is not necessary:
xprop name_of_registered_property
You might have to traverse all children to find the window with your atom.
If you're not coding the wm, you should ignore the titlebars. They are wm internals, not a client and they are probably not registered for events.
answered Mar 5 at 10:37
ctxctx
1,749515
Thanks. By writing non-client area I mean titlebar.
– nintyfan
Mar 5 at 10:55
1
Please add this information to your question. Since the titlebar is createt by your windowmanager, you should add which wm/de you use too.
– ctx
Mar 5 at 11:02
I will add some info: Use xwininfo -all -root, read the id of child of window using parent's window title. Use xprop -id hexadecimal number present in xwininfo output
– nintyfan
Mar 7 at 10:39
add a comment |
This command prints all childrens:
xwininfo -all -root
Not all windowmanagers use the root window to show the backround. Clicking on a non client area will show infos about the window that displays the background. To show infos about the root window use:
xprop -root
If you correctly set an atom, xprop can read it. The format part in your xprop command is not necessary:
xprop name_of_registered_property
You might have to traverse all children to find the window with your atom.
If you're not coding the wm, you should ignore the titlebars. They are wm internals, not a client and they are probably not registered for events.
answered Mar 5 at 10:37
ctxctx
1,749515
Thanks. By writing non-client area I mean titlebar.
– nintyfan
Mar 5 at 10:55
1
Please add this information to your question. Since the titlebar is createt by your windowmanager, you should add which wm/de you use too.
– ctx
Mar 5 at 11:02
I will add some info: Use xwininfo -all -root, read the id of child of window using parent's window title. Use xprop -id hexadecimal number present in xwininfo output
– nintyfan
Mar 7 at 10:39
add a comment |
This command prints all childrens:
xwininfo -all -root
Not all windowmanagers use the root window to show the backround. Clicking on a non client area will show infos about the window that displays the background. To show infos about the root window use:
xprop -root
If you correctly set an atom, xprop can read it. The format part in your xprop command is not necessary:
xprop name_of_registered_property
You might have to traverse all children to find the window with your atom.
If you're not coding the wm, you should ignore the titlebars. They are wm internals, not a client and they are probably not registered for events.
answered Mar 5 at 10:37
ctxctx
1,749515
This command prints all childrens:
xwininfo -all -root
Not all windowmanagers use the root window to show the backround. Clicking on a non client area will show infos about the window that displays the background. To show infos about the root window use:
xprop -root
If you correctly set an atom, xprop can read it. The format part in your xprop command is not necessary:
xprop name_of_registered_property
You might have to traverse all children to find the window with your atom.
If you're not coding the wm, you should ignore the titlebars. They are wm internals, not a client and they are probably not registered for events.
answered Mar 5 at 10:37
ctxctx
1,749515
edited Mar 6 at 10:28
answered Mar 5 at 10:37
ctxctx
1,749515
answered Mar 5 at 10:37
ctxctx
1,749515
answered Mar 5 at 10:37
ctxctx
1,749515
1,749515
Thanks. By writing non-client area I mean titlebar.
– nintyfan
Mar 5 at 10:55
1
Please add this information to your question. Since the titlebar is createt by your windowmanager, you should add which wm/de you use too.
– ctx
Mar 5 at 11:02
I will add some info: Use xwininfo -all -root, read the id of child of window using parent's window title. Use xprop -id hexadecimal number present in xwininfo output
– nintyfan
Mar 7 at 10:39
add a comment |
Thanks. By writing non-client area I mean titlebar.
– nintyfan
Mar 5 at 10:55
1
Please add this information to your question. Since the titlebar is createt by your windowmanager, you should add which wm/de you use too.
– ctx
Mar 5 at 11:02
I will add some info: Use xwininfo -all -root, read the id of child of window using parent's window title. Use xprop -id hexadecimal number present in xwininfo output
– nintyfan
Mar 7 at 10:39
Thanks. By writing non-client area I mean titlebar.
– nintyfan
Mar 5 at 10:55
Thanks. By writing non-client area I mean titlebar.
– nintyfan
Mar 5 at 10:55
1
1
Please add this information to your question. Since the titlebar is createt by your windowmanager, you should add which wm/de you use too.
– ctx
Mar 5 at 11:02
Please add this information to your question. Since the titlebar is createt by your windowmanager, you should add which wm/de you use too.
– ctx
Mar 5 at 11:02
I will add some info: Use xwininfo -all -root, read the id of child of window using parent's window title. Use xprop -id hexadecimal number present in xwininfo output
– nintyfan
Mar 7 at 10:39
I will add some info: Use xwininfo -all -root, read the id of child of window using parent's window title. Use xprop -id hexadecimal number present in xwininfo output
– nintyfan
Mar 7 at 10:39
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504415%2fread-x-window-property-of-non-client-area%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
maybe you're not selecting the right window -- wm decorations like titlebars may themselves be subwindows of the the frame window you set your properties on. Anyways, post something reproducible; your question is not clear.
– mosvy
Mar 5 at 9:11
Should I attach C code? That's not stack overflow.
– nintyfan
Mar 5 at 9:29
You should add the output of the two xprop commands.
– ctx
Mar 5 at 10:39
This sounds suspiciously like an XY problem. The non-client parts (e.g. title bar) are managed by the WM, they will be different for different WMs, so relying in any properties there will break as soon as the WM changes. Therefore I'm not surprised trying to get and set them runs into trouble (but what exactly happens probably also depends on the WM). What exactly are you trying to achieve by using properties on non-client areas? I'm pretty sure that whatever it is, there's a correct alternative way to do it.
– dirkt
Mar 5 at 13:02
I will write app-integrated macro recorder. Possible a new design of such programs :-) . App register to window manager it's supports recording macro by setting atom on window and window manager will display dropdown menu with macro-related functions. User could click on first window, select start recording a new macro, set name. I next step he click on other window's titlebar and select attach to macro. Window manager will send XID or other information to daemon, which next asks app for window data (strings representing the state of window).
– nintyfan
Mar 5 at 13:46