[ I hope the Subject: is arcane enough to reduce readership to a handful :) ]
Running the default window manager in the Linux distribution I am running,
multiple 'windows' of the same program are usually aggregated under one icon.
I typically have numerous (gnome) terminals, several top-level emacs windows,
likely more than brower window (even with tabs) and so on. They all aggregate
under the top-level icon
R plots however all have one each. Needless to say I may also have more than
one plot device open... Would anyone know how we can force these to
aggregate under just one? I had some digital fingerprints on the .desktop
file that ships with simply because someone first sent it to me as a patch
for the Debian package. But I know nuttin' about the XDG desktop
specification and all that. I had one idea regarding window titles, but those
are different for the terminals and emacs windows too. Anybody have an idea?
Dirk
Confession: haven't done this in decades.
Isn't the usual way to use 'xwininfo' to figure out the information
about any X window and set a specific resource in the .X11defaults or
equivalent?? Also doing the same with windows that aggregate could yield
a common resource, perhaps?
-Naras
On 3/20/21 9:51 AM, Dirk Eddelbuettel wrote:
[ I hope the Subject: is arcane enough to reduce readership to a handful :) ]
Running the default window manager in the Linux distribution I am running,
multiple 'windows' of the same program are usually aggregated under one icon.
I typically have numerous (gnome) terminals, several top-level emacs windows,
likely more than brower window (even with tabs) and so on. They all aggregate
under the top-level icon
R plots however all have one each. Needless to say I may also have more than
one plot device open... Would anyone know how we can force these to
aggregate under just one? I had some digital fingerprints on the .desktop
file that ships with simply because someone first sent it to me as a patch
for the Debian package. But I know nuttin' about the XDG desktop
specification and all that. I had one idea regarding window titles, but those
are different for the terminals and emacs windows too. Anybody have an idea?
Dirk
R plots however all have one each. Needless to say I may also have
more than one plot device open... Would anyone know how we can force
these to aggregate under just one?
Grouping seems to be achieved by setting the window_group component of
the WM_HINTS property of the window:
https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#wm_hints_property
ICCCM goes on to say that "The window group leader may be a window that
exists only for that purpose <...> [not] mapped either by the client or
by the window manager".
Is that enough of a direction? I have only ever written X11 code using
xcb, not Xlib, but I could try to help further if needed.
On Sat, 20 Mar 2021 11:51:41 -0500
Dirk Eddelbuettel <edd at debian.org> wrote:
R plots however all have one each. Needless to say I may also have
more than one plot device open... Would anyone know how we can force
these to aggregate under just one?
Grouping seems to be achieved by setting the window_group component of
the WM_HINTS property of the window:
https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#wm_hints_property
ICCCM goes on to say that "The window group leader may be a window that
exists only for that purpose <...> [not] mapped either by the client or
by the window manager".
Is that enough of a direction? I have only ever written X11 code using
xcb, not Xlib, but I could try to help further if needed.
I just did a quick grep of the R-devel sources, and don't see WM_HINTS
used there at all. (This is after searching rgl sources, with the same
result.) I'd be happy to add something to rgl if you could point me to
an example: it also uses Xlib like R, so once that works I could
propose a patch to R.
Duncan Murdoch
On 22 March 2021 at 10:27, Balasubramanian Narasimhan wrote:
| Confession: haven't done this in decades.
Equally green here.
| Isn't the usual way to use 'xwininfo' to figure out the information
| about any X window and set a specific resource in the .X11defaults or
| equivalent?? Also doing the same with windows that aggregate could yield
| a common resource, perhaps?
Could be.
On 22 March 2021 at 22:32, Ivan Krylov wrote:
| Grouping seems to be achieved by setting the window_group component of
| the WM_HINTS property of the window:
|
| https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#wm_hints_property
|
| ICCCM goes on to say that "The window group leader may be a window that
| exists only for that purpose <...> [not] mapped either by the client or
| by the window manager".
|
| Is that enough of a direction? I have only ever written X11 code using
| xcb, not Xlib, but I could try to help further if needed.
That is quite promising. Just like Duncan I see now WM_HINTS yet, so maybe by
just giving them we can improve?
On 22 March 2021 at 15:42, Duncan Murdoch wrote:
| I just did a quick grep of the R-devel sources, and don't see WM_HINTS
| used there at all. (This is after searching rgl sources, with the same
| result.) I'd be happy to add something to rgl if you could point me to
| an example: it also uses Xlib like R, so once that works I could
| propose a patch to R.
I'd love for us to put the focus back to src/modules/X11/devX11.{c,h} :)
The original email I got for the Debian patch that then made it into R's
sources is still here:
https://sources.debian.org/src/r-base/4.0.4-1/debian/icon-class-patch/
And I think we somehow need to aggregate all three strands: the Xtoolkit
-based info Naras alluded to, and possibly adding hints as identified by
Ivan. It might help to spy on "any" other better-behaving X11 client.
Dirk
| The surrounding code and
| <https://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-hints.html>
| proved to be enough of an example. The following patch makes it
| possible to group x11() windows on my PC with Xfce running:
[...]
| Some very limited testing didn't seem to uncover any problems.
Woot woot -- works here too under Ubuntu 20.10 / Gnome / Unity.
I applied the adorably small patch to the usual checkout I keep of r-devel
(as an incremental build is faster than a full package build of r-release).
You are my hero. Next round of hot or cold beverages is on me. Already looks
so much better. I may put this into the next 4.0.5 (or 4.1.0 at the latest)
for Debian and Ubuntu (but will instrument a proper new r-base package and
hit it for a few days first).
Do you want to send a proper patch to bugzilla?
Dirk
On 22 March 2021 at 16:57, Dirk Eddelbuettel wrote:
|
| On 23 March 2021 at 00:01, Ivan Krylov wrote:
| | The surrounding code and
| | <https://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-hints.html>
| | proved to be enough of an example. The following patch makes it
| | possible to group x11() windows on my PC with Xfce running:
|
| [...]
|
| | Some very limited testing didn't seem to uncover any problems.
|
| Woot woot -- works here too under Ubuntu 20.10 / Gnome / Unity.
|
| I applied the adorably small patch to the usual checkout I keep of r-devel
| (as an incremental build is faster than a full package build of r-release).
|
| You are my hero. Next round of hot or cold beverages is on me. Already looks
| so much better. I may put this into the next 4.0.5 (or 4.1.0 at the latest)
| for Debian and Ubuntu (but will instrument a proper new r-base package and
| hit it for a few days first).
Close, close, close but no cigar yet: For a given R process, x11() windows
group for a that process. But we often run multiple R processes. Have you
seen anything for grouping under the "program" (in some sense) but not the
concrete process from it?
( If someone wants to play, Ubuntu binaries for groovy == 20.10 are at
https://launchpad.net/~edd/+archive/ubuntu/misc/?field.series_filter=groovy )
Dirk
Dirk Eddelbuettel
on Mon, 22 Mar 2021 22:23:47 -0500 writes:
> On 22 March 2021 at 16:57, Dirk Eddelbuettel wrote:
> |
> | On 23 March 2021 at 00:01, Ivan Krylov wrote:
> | | The surrounding code and
> | | <https://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-hints.html>
> | | proved to be enough of an example. The following patch makes it
> | | possible to group x11() windows on my PC with Xfce running:
> |
> | [...]
> |
> | | Some very limited testing didn't seem to uncover any problems.
> |
> | Woot woot -- works here too under Ubuntu 20.10 / Gnome / Unity.
> |
> | I applied the adorably small patch to the usual checkout I keep of r-devel
> | (as an incremental build is faster than a full package build of r-release).
> |
> | You are my hero. Next round of hot or cold beverages is on me. Already looks
> | so much better. I may put this into the next 4.0.5 (or 4.1.0 at the latest)
> | for Debian and Ubuntu (but will instrument a proper new r-base package and
> | hit it for a few days first).
> Close, close, close but no cigar yet: For a given R process, x11() windows
> group for a that process. But we often run multiple R processes. Have you
> seen anything for grouping under the "program" (in some sense) but not the
> concrete process from it?
Hmm.. while I've been very happy with your (DE) original proposal and
the thread (with Ivan's nice small patch), I'm not sure I'd agree here.
Yes, you and I and a few handful more of people on the globe run
more than one *interactive* R process simultaneously. But even
there, e.g., when I run R-patched and R-devel, I'd sometimes rather keep
the two processes "separated", including their graphics windows,
because one important side condition of the workflow is to be
careful in comparing the two R versions.
And R is not firefox (where I really typically only want one
firefox running, already being a crazy process generator and
sometimes memory hog).
The two (or more) different R processes are entirely autonomous
(in > 99.5% of cases), and I would rather have the current
proposal than a possibly quite a bit more complicated one which
I personally often would not even prefer...
With many thanks to Dirk, Naras, Ivan and Duncan for dealing
with the issue so nicely,
Martin
> ( If someone wants to play, Ubuntu binaries for groovy == 20.10 are at
> https://launchpad.net/~edd/+archive/ubuntu/misc/?field.series_filter=groovy )
> Dirk
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
Would be glad to, especially if we manage to solve that problem you
uncovered while I was asleep.
On Mon, 22 Mar 2021 22:23:47 -0500
Dirk Eddelbuettel <edd at debian.org> wrote:
Close, close, close but no cigar yet: For a given R process, x11()
windows group for a that process. But we often run multiple R
processes. Have you seen anything for grouping under the
"program" (in some sense) but not the concrete process from it?
Do windows from different Emacs processes group together the way you
want them to group? What other applications group together for you
despite running from different processes? Do they have the same window
id # of group leader in `xprop WM_HINTS`? I checked Firefox, but its
windows all seem to have the same _NET_WM_PID.
I decided to copy the way GVim sets its group leader ID (because I know
the windows are different processes _and_ that they group in Xfce) and
spent a while chasing this red herring before realising that (1) on my
PC, different x11() windows are still grouped together, even from
different R processes, even without the patch (I never used the "group
windows" option in xfce4-panel before) and (2) different GVim windows
actually have different group leader XIDs in their WM_HINTS properties.
Oops.
Apparently Xfce uses libwnck [*] which groups windows by WM_CLASS in
addition to WM_HINTS (as far as understand the code).
Here is what GNOME Shell does [**] besides looking at
WM_HINTS.window_group:
- looks up the window's WM_CLASS in .desktop files known to it
- looks up the window's _NET_WM_PID among running applications (?)
- looks for an XDG startup notification matching the window
- checks other things not likely applicable to R, such as sandbox IDs
and GApplication IDs
Adding StartupWMClass=R_x11 to R.desktop (not part of R sources, but
part of the .deb package, I believe) should help GNOME Shell match all
x11() windows to a single application without any changes to devX11.c,
but I don't have GNOME installed to check it.
Alternatively, we can also add a _NET_WM_PID property to x11() windows
(in the hope that GNOME Shell matches the PIDs to the same binary), but
then we'd have to add the WM_CLIENT_MACHINE property too [***], which
is way more hacky than I would prefer it to be:
-----------------------------------8<-----------------------------------
Index: src/modules/X11/devX11.c
===================================================================
--- src/modules/X11/devX11.c (revision 80104)
+++ src/modules/X11/devX11.c (working copy)
@@ -52,6 +52,8 @@
#endif
#include <X11/keysymdef.h>
+#include <sys/utsname.h> /* for uname -> WM_CLIENT_MACHINE -> _NET_WM_PID */
+#include <unistd.h> /* getpid -> _NET_WM_PID */
#define R_USE_PROTOTYPES 1
#include <R_ext/GraphicsEngine.h>
@@ -105,7 +107,7 @@
static Display *display; /* Display */
static char dspname[101]="";
static int screen; /* Screen */
-static Window rootwin; /* Root Window */
+static Window rootwin, group_leader; /* Root Window */
static Visual *visual; /* Visual */
static int depth; /* Pixmap depth */
static int Vclass; /* Visual class */
@@ -1617,6 +1619,39 @@
PropModeReplace,
(const unsigned char*) rlogo_icon, 2 + 99*77);
+ /* set the window group leader */
+ XWMHints * hints;
+ hints = XAllocWMHints();
+ if (hints) {
+ hints->window_group = group_leader;
+ hints->flags |= WindowGroupHint;
+ XSetWMHints(display, xd->window, hints);
+ XFree(hints);
+ }
+
+ /* Provide WM_CLIENT_MACHINE to set a valid _NET_WM_PID */
+ struct utsname unm;
+ if (uname(&unm)) goto no_wm_pid;
+ char * nodename = &unm.nodename[0];
+ XTextProperty hostname = {0}; /* initialise the value pointer */
+ if (Success != XmbTextListToTextProperty(
+ display, &nodename, 1, XStringStyle, &hostname
+ )) {
+ if (hostname.value) XFree(hostname.value);
+ goto no_wm_pid;
+ }
+ XSetWMClientMachine(display, xd->window, &hostname);
+ XFree(hostname.value);
+
+ /* set _NET_WM_PID */
+ uint32_t mypid = (uint32_t)getpid(); /* must be CARDINAL(32) */
+ XChangeProperty(display, xd->window,
+ XInternAtom(display, "_NET_WM_PID", False),
+ XInternAtom(display, "CARDINAL", False), 32,
+ PropModeReplace,
+ (const unsigned char*) &mypid, 1);
+ no_wm_pid:
+
/* set up protocols so that window manager sends */
/* me an event when user "destroys" window */
_XA_WM_PROTOCOLS = XInternAtom(display, "WM_PROTOCOLS", 0);
@@ -2109,6 +2144,7 @@
if (numX11Devices == 0) {
int fd = ConnectionNumber(display);
/* Free Resources Here */
+ XDestroyWindow(display, group_leader);
while (nfonts--)
R_XFreeFont(display, fontcache[nfonts].font);
nfonts = 0;
@@ -3133,6 +3169,9 @@
#endif
screen = DefaultScreen(display);
rootwin = DefaultRootWindow(display);
+ group_leader = XCreateSimpleWindow(
+ display, rootwin, 0, 0, 1, 1, 0, 0, 0
+ );
depth = DefaultDepth(display, screen);
visual = DefaultVisual(display, screen);
colormap = DefaultColormap(display, screen);
-----------------------------------8<-----------------------------------
|
| > Do you want to send a proper patch to bugzilla?
|
| Would be glad to, especially if we manage to solve that problem you
| uncovered while I was asleep.
|
| On Mon, 22 Mar 2021 22:23:47 -0500
| Dirk Eddelbuettel <edd at debian.org> wrote:
|
| > Close, close, close but no cigar yet: For a given R process, x11()
| > windows group for a that process. But we often run multiple R
| > processes. Have you seen anything for grouping under the
| > "program" (in some sense) but not the concrete process from it?
|
| Do windows from different Emacs processes group together the way you
| want them to group? What other applications group together for you
| despite running from different processes? Do they have the same window
| id # of group leader in `xprop WM_HINTS`? I checked Firefox, but its
| windows all seem to have the same _NET_WM_PID.
"All of them, but R".
Right now (under unity) I have four for Gnome Terminal (clearly distinct
processes), two for Chrome (plus more temporarily), and two for emacs (two
windows from same process, I checked that launching a new one clearly
aggregates within).
But R is different, and I see this as a bug. How "grave" it is is open for
debate, but the application behaves differently under the window manager.
The overall behaviour is consistent, yet R sticks out. I think it shouldn't.
| I decided to copy the way GVim sets its group leader ID (because I know
| the windows are different processes _and_ that they group in Xfce) and
| spent a while chasing this red herring before realising that (1) on my
| PC, different x11() windows are still grouped together, even from
| different R processes, even without the patch (I never used the "group
| windows" option in xfce4-panel before) and (2) different GVim windows
| actually have different group leader XIDs in their WM_HINTS properties.
| Oops.
Hah!
| Apparently Xfce uses libwnck [*] which groups windows by WM_CLASS in
| addition to WM_HINTS (as far as understand the code).
|
| Here is what GNOME Shell does [**] besides looking at
| WM_HINTS.window_group:
|
| - looks up the window's WM_CLASS in .desktop files known to it
| - looks up the window's _NET_WM_PID among running applications (?)
| - looks for an XDG startup notification matching the window
| - checks other things not likely applicable to R, such as sandbox IDs
| and GApplication IDs
|
| Adding StartupWMClass=R_x11 to R.desktop (not part of R sources, but
| part of the .deb package, I believe) should help GNOME Shell match all
| x11() windows to a single application without any changes to devX11.c,
| but I don't have GNOME installed to check it.
Easy enough for me to check, but I won't get to it for a bit.
| Alternatively, we can also add a _NET_WM_PID property to x11() windows
| (in the hope that GNOME Shell matches the PIDs to the same binary), but
| then we'd have to add the WM_CLIENT_MACHINE property too [***], which
| is way more hacky than I would prefer it to be:
[proposed change set omitted]
Ok. You did amazing. I had poked around a little in one or two apps but not
made any progress.
Dirk
On 23 March 2021 at 07:44, Dirk Eddelbuettel wrote:
| On 23 March 2021 at 13:18, Ivan Krylov wrote:
| | Apparently Xfce uses libwnck [*] which groups windows by WM_CLASS in
| | addition to WM_HINTS (as far as understand the code).
| |
| | Here is what GNOME Shell does [**] besides looking at
| | WM_HINTS.window_group:
| |
| | - looks up the window's WM_CLASS in .desktop files known to it
| | - looks up the window's _NET_WM_PID among running applications (?)
| | - looks for an XDG startup notification matching the window
| | - checks other things not likely applicable to R, such as sandbox IDs
| | and GApplication IDs
| |
| | Adding StartupWMClass=R_x11 to R.desktop (not part of R sources, but
| | part of the .deb package, I believe) should help GNOME Shell match all
| | x11() windows to a single application without any changes to devX11.c,
| | but I don't have GNOME installed to check it.
|
| Easy enough for me to check, but I won't get to it for a bit.
Ok, I tried. And amazingly that worked (with a small "but")!
Added the line to the (installed) /usr/share/applications/R.desktop,
asked Gnome Shell to restart (Alt-F2, then r [where r standards for restart,
not littler ;-) ]) and the (existing) two windows (from two distinct 'live'
and long-running plot/monitor sessions) are now regrouped in the 'dock',
which would for the first time be correct behaviour under Gnome (as I
understand it).
Only one small downside: the regrouped icon switches to the old R icon (which
is probably the one we bitmapped). Would you know how we could force the new
one?
Dirk
On 23 March 2021 at 08:15, Dirk Eddelbuettel wrote:
| Only one small downside: the regrouped icon switches to the old R icon (which
| is probably the one we bitmapped). Would you know how we could force the new
| one?
Could well be my fault. =:-)
I still ship /usr/share/icons/hicolor/48x48/apps/rlogo_icon.png which is from
the 2012 patch, and I vaguely recall the .desktop file being unhappy without it.
Re-creating a 48x48 from the svg may do.
Dirk
? Tue, 23 Mar 2021 08:58:49 -0500
Dirk Eddelbuettel <edd at debian.org> ?????:
I still ship /usr/share/icons/hicolor/48x48/apps/rlogo_icon.png which
is from the 2012 patch, and I vaguely recall the .desktop file being
unhappy without it. Re-creating a 48x48 from the svg may do.
| ? Tue, 23 Mar 2021 08:58:49 -0500
| Dirk Eddelbuettel <edd at debian.org> ?????:
|
| > I still ship /usr/share/icons/hicolor/48x48/apps/rlogo_icon.png which
| > is from the 2012 patch, and I vaguely recall the .desktop file being
| > unhappy without it. Re-creating a 48x48 from the svg may do.
|
| I think you could even link /usr/share/R/doc/html/Rlogo.svg
| into /usr/share/icons/hicolor/scalable/apps/rlogo_icon.svg to let GNOME
| and others draw an arbitrarily high-resolution icon if the display
| permits that, but a 48x48 bitmap is still required:
|
| https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#install_icons
Yes, had the same idea earlier and tried it, with the original Rlogo.svg
copied in there under that name -- but I got an 'empty' icon displayed :-/
(I had also removed the png "to be sure", your more careful suggests it is
needed as a fallback.)
When I follow your suggestion to use both it works with new logo (yay) with
the only minor drawback ... that the white background shows whereas all other
logos are using transparent background.
Dirk
On 23 March 2021 at 09:38, Dirk Eddelbuettel wrote:
|
| On 23 March 2021 at 17:13, Ivan Krylov wrote:
| | ? Tue, 23 Mar 2021 08:58:49 -0500
| | Dirk Eddelbuettel <edd at debian.org> ?????:
| |
| | > I still ship /usr/share/icons/hicolor/48x48/apps/rlogo_icon.png which
| | > is from the 2012 patch, and I vaguely recall the .desktop file being
| | > unhappy without it. Re-creating a 48x48 from the svg may do.
| |
| | I think you could even link /usr/share/R/doc/html/Rlogo.svg
| | into /usr/share/icons/hicolor/scalable/apps/rlogo_icon.svg to let GNOME
| | and others draw an arbitrarily high-resolution icon if the display
| | permits that, but a 48x48 bitmap is still required:
| |
| | https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#install_icons
|
| Yes, had the same idea earlier and tried it, with the original Rlogo.svg
| copied in there under that name -- but I got an 'empty' icon displayed :-/
| (I had also removed the png "to be sure", your more careful suggests it is
| needed as a fallback.)
|
| When I follow your suggestion to use both it works with new logo (yay) with
| the only minor drawback ... that the white background shows whereas all other
| logos are using transparent background.
Sorry, that was wrong: a leftover from manually installing a new png based on
the svg. So when I have both, the png wins and the svg is seemingly ignored.
So first task would be to create a new (and square !!) 48x48 png from the svg
or higher-res png.
But on a lark, I just went into setting and toggled the icon size from 48
(default) to 36 ... and _voila_ I get a new (no background !!) one drawn
seemingly from the svg. So the solution appears to be to remove the png.
Will try that later.
Dirk
On Mon, 22 Mar 2021 16:57:48 -0500
Dirk Eddelbuettel <edd at debian.org> wrote:
Do you want to send a proper patch to bugzilla?
Would be glad to, especially if we manage to solve that problem you
uncovered while I was asleep.
On Mon, 22 Mar 2021 22:23:47 -0500
Dirk Eddelbuettel <edd at debian.org> wrote:
Close, close, close but no cigar yet: For a given R process, x11()
windows group for a that process. But we often run multiple R
processes. Have you seen anything for grouping under the
"program" (in some sense) but not the concrete process from it?
Do windows from different Emacs processes group together the way you
want them to group? What other applications group together for you
despite running from different processes? Do they have the same window
id # of group leader in `xprop WM_HINTS`? I checked Firefox, but its
windows all seem to have the same _NET_WM_PID.
In Ubuntu 18.04, all terminal windows display the same _NET_WM_PID, and
that PID corresponds to gnome-terminal-server. So I think it's not
going to be possible to do what Dirk wants without really major changes
to the way different R processes create graphics windows.
On the other hand, R doesn't set the _NET_WM_PID value.
I've put a version of your code into rgl, and it does what you'd expect:
it groups all rgl windows from the same R process together, but
different R processes get different groups. It would probably be nice
to have rgl windows and other R graphics windows in the same group, but
I don't see a way for rgl to know the group_leader that R is using (and
it's probably not worth adding this to the API to be able to request it).
Am I missing an easier solution?
Duncan Murdoch
I decided to copy the way GVim sets its group leader ID (because I know
the windows are different processes _and_ that they group in Xfce) and
spent a while chasing this red herring before realising that (1) on my
PC, different x11() windows are still grouped together, even from
different R processes, even without the patch (I never used the "group
windows" option in xfce4-panel before) and (2) different GVim windows
actually have different group leader XIDs in their WM_HINTS properties.
Oops.
Apparently Xfce uses libwnck [*] which groups windows by WM_CLASS in
addition to WM_HINTS (as far as understand the code).
Here is what GNOME Shell does [**] besides looking at
WM_HINTS.window_group:
- looks up the window's WM_CLASS in .desktop files known to it
- looks up the window's _NET_WM_PID among running applications (?)
- looks for an XDG startup notification matching the window
- checks other things not likely applicable to R, such as sandbox IDs
and GApplication IDs
Adding StartupWMClass=R_x11 to R.desktop (not part of R sources, but
part of the .deb package, I believe) should help GNOME Shell match all
x11() windows to a single application without any changes to devX11.c,
but I don't have GNOME installed to check it.
Alternatively, we can also add a _NET_WM_PID property to x11() windows
(in the hope that GNOME Shell matches the PIDs to the same binary), but
then we'd have to add the WM_CLIENT_MACHINE property too [***], which
is way more hacky than I would prefer it to be:
-----------------------------------8<-----------------------------------
Index: src/modules/X11/devX11.c
===================================================================
--- src/modules/X11/devX11.c (revision 80104)
+++ src/modules/X11/devX11.c (working copy)
@@ -52,6 +52,8 @@
#endif
#include <X11/keysymdef.h>
+#include <sys/utsname.h> /* for uname -> WM_CLIENT_MACHINE -> _NET_WM_PID */
+#include <unistd.h> /* getpid -> _NET_WM_PID */
#define R_USE_PROTOTYPES 1
#include <R_ext/GraphicsEngine.h>
@@ -105,7 +107,7 @@
static Display *display; /* Display */
static char dspname[101]="";
static int screen; /* Screen */
-static Window rootwin; /* Root Window */
+static Window rootwin, group_leader; /* Root Window */
static Visual *visual; /* Visual */
static int depth; /* Pixmap depth */
static int Vclass; /* Visual class */
@@ -1617,6 +1619,39 @@
PropModeReplace,
(const unsigned char*) rlogo_icon, 2 + 99*77);
+ /* set the window group leader */
+ XWMHints * hints;
+ hints = XAllocWMHints();
+ if (hints) {
+ hints->window_group = group_leader;
+ hints->flags |= WindowGroupHint;
+ XSetWMHints(display, xd->window, hints);
+ XFree(hints);
+ }
+
+ /* Provide WM_CLIENT_MACHINE to set a valid _NET_WM_PID */
+ struct utsname unm;
+ if (uname(&unm)) goto no_wm_pid;
+ char * nodename = &unm.nodename[0];
+ XTextProperty hostname = {0}; /* initialise the value pointer */
+ if (Success != XmbTextListToTextProperty(
+ display, &nodename, 1, XStringStyle, &hostname
+ )) {
+ if (hostname.value) XFree(hostname.value);
+ goto no_wm_pid;
+ }
+ XSetWMClientMachine(display, xd->window, &hostname);
+ XFree(hostname.value);
+
+ /* set _NET_WM_PID */
+ uint32_t mypid = (uint32_t)getpid(); /* must be CARDINAL(32) */
+ XChangeProperty(display, xd->window,
+ XInternAtom(display, "_NET_WM_PID", False),
+ XInternAtom(display, "CARDINAL", False), 32,
+ PropModeReplace,
+ (const unsigned char*) &mypid, 1);
+ no_wm_pid:
+
/* set up protocols so that window manager sends */
/* me an event when user "destroys" window */
_XA_WM_PROTOCOLS = XInternAtom(display, "WM_PROTOCOLS", 0);
@@ -2109,6 +2144,7 @@
if (numX11Devices == 0) {
int fd = ConnectionNumber(display);
/* Free Resources Here */
+ XDestroyWindow(display, group_leader);
while (nfonts--)
R_XFreeFont(display, fontcache[nfonts].font);
nfonts = 0;
@@ -3133,6 +3169,9 @@
#endif
screen = DefaultScreen(display);
rootwin = DefaultRootWindow(display);
+ group_leader = XCreateSimpleWindow(
+ display, rootwin, 0, 0, 1, 1, 0, 0, 0
+ );
depth = DefaultDepth(display, screen);
visual = DefaultVisual(display, screen);
colormap = DefaultColormap(display, screen);
-----------------------------------8<-----------------------------------
Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
It would probably be nice to have rgl windows and other R graphics
windows in the same group, but I don't see a way for rgl to know the
group_leader that R is using (and it's probably not worth adding this
to the API to be able to request it).
Am I missing an easier solution?
Do you envision any problems stemming from setting the same WM_CLASS
("r_x11", "R_x11") for rgl windows as used by x11() windows? I think
that most DEs are able to group windows by WM_CLASS in addition to
WM_HINTS.window_group (Xfce does that by default, GNOME turned out to
just need a hint in the .application file).
On Tue, 23 Mar 2021 11:41:39 -0400
Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
It would probably be nice to have rgl windows and other R graphics
windows in the same group, but I don't see a way for rgl to know the
group_leader that R is using (and it's probably not worth adding this
to the API to be able to request it).
Am I missing an easier solution?
Do you envision any problems stemming from setting the same WM_CLASS
("r_x11", "R_x11") for rgl windows as used by x11() windows?
Since early 2013, rgl has set the WM_CLASS to ("rgl", "R_x11"). So I
think with your suggested change to R.desktop the problem is solved,
assuming the first component (res_name) doesn't matter as long as the
second one (res_class) matches.
Duncan Murdoch
It all works now, thanks mostly to some very detailed reading of the specs by
Ivan. In short, I made the following changes:
- add the missing WM hint to the .desktop file we install
- add the svg logo as 'scalable'
- create a new (square) 48x48 default png logo from the new one
- deactivate yesterday's patch
and it is all good now. Duncan's rgl windows aggregate under the item, as do
the standard R x11 devices. I will try to attach a small screenshot, we'll
see how mailman likes it. Martin should still be able to get the old (and to
me, buggy) behaviour back by removing the one key line from the .desktop
file, if his Fedora environment ever updates as I plan.
For anyone on Ubuntu 20.10, updated binaries are in my PPA, see
https://launchpad.net/~edd/+archive/ubuntu/misc/+packages?field.name_filter=r-base&field.status_filter=published&field.series_filter=groovy
Changelog entries below, these have not been committed to Debian's git yet
but I think I will activate this for R 4.0.5 next week (and test it til
then). Screenshot attached below too.
------ changelog for these three test builds follows -----------------------
r-base (4.0.4-1.2010.3) groovy; urgency=medium
* debian/r-base-core.dirs: Also create the directory
usr/share/icons/hicolor/scalable/apps for the svg logo
-- Dirk Eddelbuettel <edd at debian.org> Tue, 23 Mar 2021 11:05:17 -0500
r-base (4.0.4-1.2010.2) groovy; urgency=medium
* icon-class-patch/R.desktop: Add 'StartupWMClass=R_x11'
* icon-class-patch/rlogo_icon.OLD.png.mpack: Renamed old icon
* icon-class-patch/rlogo_icon.png.mpack: New 48x48 png from svg
* icon-class-patch/Rlogo.svg: Copy of official logo
* debian/rules: Also install Rlogo.svg in 'scalable' icons dir
* debian/patches/series: Deactivate unneeded grouping patch
-- Dirk Eddelbuettel <edd at debian.org> Tue, 23 Mar 2021 10:27:43 -0500
r-base (4.0.4-1.2010.1) groovy; urgency=medium
* PPA build on Ubuntu 20.10 "groovy"
* src/modules/X11/devX11.c: Apply patch by Ivan Krylov (posted to r-devel
on 2021-03-22) enabling grouping of x11 plot device windows
-- Dirk Eddelbuettel <edd at debian.org> Mon, 22 Mar 2021 21:33:09 -0500
-----------------------------------------------------------------------------
Dirk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2021-03-23 12-30-06.png
Type: image/png
Size: 10924 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20210323/24c0e633/attachment.png>
-------------- next part --------------
With that change to the .desktop file, both the existing rgl and the rgl
with a group_leader set behave the same: all x11() and rgl windows are
collected together into the same R icon.
If I don't make that change, then setting the group_leader causes all
rgl windows from one process to group together (with a bad icon).
I think I'll leave the group_leader in place. I'll think about setting
an icon, but I don't see it as urgent.
Duncan Murdoch
On 23/03/2021 1:36 p.m., Dirk Eddelbuettel wrote:
It all works now, thanks mostly to some very detailed reading of the specs by
Ivan. In short, I made the following changes:
- add the missing WM hint to the .desktop file we install
- add the svg logo as 'scalable'
- create a new (square) 48x48 default png logo from the new one
- deactivate yesterday's patch
and it is all good now. Duncan's rgl windows aggregate under the item, as do
the standard R x11 devices. I will try to attach a small screenshot, we'll
see how mailman likes it. Martin should still be able to get the old (and to
me, buggy) behaviour back by removing the one key line from the .desktop
file, if his Fedora environment ever updates as I plan.
For anyone on Ubuntu 20.10, updated binaries are in my PPA, see
https://launchpad.net/~edd/+archive/ubuntu/misc/+packages?field.name_filter=r-base&field.status_filter=published&field.series_filter=groovy
Changelog entries below, these have not been committed to Debian's git yet
but I think I will activate this for R 4.0.5 next week (and test it til
then). Screenshot attached below too.
------ changelog for these three test builds follows -----------------------
r-base (4.0.4-1.2010.3) groovy; urgency=medium
* debian/r-base-core.dirs: Also create the directory
usr/share/icons/hicolor/scalable/apps for the svg logo
-- Dirk Eddelbuettel <edd at debian.org> Tue, 23 Mar 2021 11:05:17 -0500
r-base (4.0.4-1.2010.2) groovy; urgency=medium
* icon-class-patch/R.desktop: Add 'StartupWMClass=R_x11'
* icon-class-patch/rlogo_icon.OLD.png.mpack: Renamed old icon
* icon-class-patch/rlogo_icon.png.mpack: New 48x48 png from svg
* icon-class-patch/Rlogo.svg: Copy of official logo
* debian/rules: Also install Rlogo.svg in 'scalable' icons dir
* debian/patches/series: Deactivate unneeded grouping patch
-- Dirk Eddelbuettel <edd at debian.org> Tue, 23 Mar 2021 10:27:43 -0500
r-base (4.0.4-1.2010.1) groovy; urgency=medium
* PPA build on Ubuntu 20.10 "groovy"
* src/modules/X11/devX11.c: Apply patch by Ivan Krylov (posted to r-devel
on 2021-03-22) enabling grouping of x11 plot device windows
-- Dirk Eddelbuettel <edd at debian.org> Mon, 22 Mar 2021 21:33:09 -0500
-----------------------------------------------------------------------------
Dirk
Dirk Eddelbuettel
on Tue, 23 Mar 2021 12:36:47 -0500 writes:
> It all works now, thanks mostly to some very detailed reading of the specs by
> Ivan. In short, I made the following changes:
> - add the missing WM hint to the .desktop file we install
> - add the svg logo as 'scalable'
> - create a new (square) 48x48 default png logo from the new one
> - deactivate yesterday's patch
> and it is all good now. Duncan's rgl windows aggregate under the item, as do
> the standard R x11 devices. I will try to attach a small screenshot, we'll
> see how mailman likes it. Martin should still be able to get the old (and to
> me, buggy) behaviour back by removing the one key line from the .desktop
> file, if his Fedora environment ever updates as I plan.
> For anyone on Ubuntu 20.10, updated binaries are in my PPA, see
> https://launchpad.net/~edd/+archive/ubuntu/misc/+packages?field.name_filter=r-base&field.status_filter=published&field.series_filter=groovy
> Changelog entries below, these have not been committed to Debian's git yet
> but I think I will activate this for R 4.0.5 next week (and test it til
> then). Screenshot attached below too.
> ------ changelog for these three test builds follows -----------------------
> r-base (4.0.4-1.2010.3) groovy; urgency=medium
> * debian/r-base-core.dirs: Also create the directory
> usr/share/icons/hicolor/scalable/apps for the svg logo
> -- Dirk Eddelbuettel <edd at debian.org> Tue, 23 Mar 2021 11:05:17 -0500
> r-base (4.0.4-1.2010.2) groovy; urgency=medium
> * icon-class-patch/R.desktop: Add 'StartupWMClass=R_x11'
> * icon-class-patch/rlogo_icon.OLD.png.mpack: Renamed old icon
> * icon-class-patch/rlogo_icon.png.mpack: New 48x48 png from svg
> * icon-class-patch/Rlogo.svg: Copy of official logo
> * debian/rules: Also install Rlogo.svg in 'scalable' icons dir
> * debian/patches/series: Deactivate unneeded grouping patch
> -- Dirk Eddelbuettel <edd at debian.org> Tue, 23 Mar 2021 10:27:43 -0500
> r-base (4.0.4-1.2010.1) groovy; urgency=medium
> * PPA build on Ubuntu 20.10 "groovy"
> * src/modules/X11/devX11.c: Apply patch by Ivan Krylov (posted to r-devel
> on 2021-03-22) enabling grouping of x11 plot device windows
> -- Dirk Eddelbuettel <edd at debian.org> Mon, 22 Mar 2021 21:33:09 -0500
Thank you, Dirk for raising the issue, providing the nice summary,
and again to Ivan for his patches and Duncan for testing and comments
I've checked the first of Ivan's patches -- IIRC the one Dirk
now also is going to patch the Debian/Ubuntu/... R-base packages with.
The code is nice, short (but not too short), partly self explainable,
and it also works fine under the Fedora_32--current version of
Gnome.
For this reason I've committed to R (the trunk, i.e., R-devel,
for R 4.1.0 in a month or so) in svn rev 80110.
However we definitely want a stable R 4.0.5 with basically only
a bug fix of the character/UTF-8/.. problem so R 4.0.x itself
will surely not get such a patch.
Best regards,
Martin
| For this reason I've committed to R (the trunk, i.e., R-devel,
| for R 4.1.0 in a month or so) in svn rev 80110.
I just saw that via the (still extremely helpful) RSS feed of SVN changes and
then pulled.
You may have missed that Ivan concluded, and I followed, that the _patch is
not needed_. All one needs is to adjust the .desktop file. I posted my full
changelog from the Debian package (of which I currently run a test build on
two Ubuntu machines using the binaries from Launchpad I pointed to).
So in that sense I think r80110 may wants to be reverted.
Dirk
On 24 March 2021 at 10:30, Martin Maechler wrote:
| For this reason I've committed to R (the trunk, i.e., R-devel,
| for R 4.1.0 in a month or so) in svn rev 80110.
I just saw that via the (still extremely helpful) RSS feed of SVN changes and
then pulled.
You may have missed that Ivan concluded, and I followed, that the _patch is
not needed_. All one needs is to adjust the .desktop file. I posted my full
changelog from the Debian package (of which I currently run a test build on
two Ubuntu machines using the binaries from Launchpad I pointed to).
So in that sense I think r80110 may wants to be reverted.
I'm not sure either if Martin saw your conclusion.
I haven't tested R-devel with r80110 yet, but I did make the equivalent
change in rgl, and have been working with that.
In Ubuntu, it makes no difference if the .desktop file is changed as you
describe, but I think it's an improvement if you don't make that change
for the usual case. You don't get a ton of icons, you get one rgl icon
per process.
In macOS, it does affect the behaviour of windows. During rgl testing,
I sometimes create 100+ windows. Before the change, the window manager
put them all over the screen, trying to make the newest one visible.
After the change (now it knows they're all in the same group), it just
cascades them down the screen until it hits the bottom, then keeps
creating tiny windows crammed against the bottom of the screen. I think
this is negative (the usual reason I create them all is to hope to spot
bad changes).
So for a reasonable number of windows the change is an improvement: the
windows appear grouped. For a very large number of windows it's a negative.
Duncan Murdoch
Duncan Murdoch
on Thu, 25 Mar 2021 10:41:46 -0400 writes:
> On 25/03/2021 9:18 a.m., Dirk Eddelbuettel wrote:
>>
>> On 24 March 2021 at 10:30, Martin Maechler wrote:
>> | For this reason I've committed to R (the trunk, i.e., R-devel,
>> | for R 4.1.0 in a month or so) in svn rev 80110.
>>
>> I just saw that via the (still extremely helpful) RSS feed of SVN changes and
>> then pulled.
>>
>> You may have missed that Ivan concluded, and I followed, that the _patch is
>> not needed_. All one needs is to adjust the .desktop file. I posted my full
>> changelog from the Debian package (of which I currently run a test build on
>> two Ubuntu machines using the binaries from Launchpad I pointed to).
>>
>> So in that sense I think r80110 may wants to be reverted.
> I'm not sure either if Martin saw your conclusion.
I saw it, but as there were two patches of Ivan, I understood
that the 2nd one (which would even group X11 windows of
unrelated R instances) was unneeded.
I concluded I liked the first one because it would achieve
what's considered "uniformly better" in the sense that it makes
R graphics behave like "all other" desktop applications *and* it
would do so for all possible window manager scheme without any
need of some desktop setting (which a typical user would not
know about, nor know that s?he should/could change).
> I haven't tested R-devel with r80110 yet, but I did make the equivalent
> change in rgl, and have been working with that.
> In Ubuntu, it makes no difference if the .desktop file is changed as you
> describe,
a big "iff" at least conceptually, when in the present case,
Dirk as Debian maintainer of the 'R debian pkg' can make it happen.
What about Redhat/Fedora etc, what about the next cool window manager
on Linux distribution Z? They may change to do what .desktop
does in a different way, etc, or more typically not package R
that way and hence not have a *.desktop equivalent.
> but I think it's an improvement if you don't make that change
> for the usual case. You don't get a ton of icons, you get one rgl icon
> per process.
> In macOS, it does affect the behaviour of windows. During rgl testing,
> I sometimes create 100+ windows. Before the change, the window manager
> put them all over the screen, trying to make the newest one visible.
> After the change (now it knows they're all in the same group), it just
> cascades them down the screen until it hits the bottom, then keeps
> creating tiny windows crammed against the bottom of the screen. I think
> this is negative (the usual reason I create them all is to hope to spot
> bad changes).
> So for a reasonable number of windows the change is an improvement: the
> windows appear grouped. For a very large number of
> windows it's a negative..
> Duncan Murdoch
which probably also depends on your screen size and the
configuration of several tuning parameters of your window
manager etc..
This all started with Dirk saying the R behaves differently than
"all" other applications in this respect, and Ivan found compact
way to change that .. window-manager -- independently which I
still think is a pro.
Given Duncan's use case, may this should become an argument for
x11() and X11.options(), say grouping = c("process", "none", "all")
with match.arg(grouping) used, so the default was "process"
i.e. group things together that belong to the same "process"
(current R-devel), "none" would correspond to the previous
default and "all" would correspond to what the 2nd patch of Ivan
aimed for.
?