[PATCH] wmaker: restore atom indices broken by _WINDOWMAKER_MARK_KEY insertion

[david.m...@gmail.com]

The vim-like window marking change inserted "_WINDOWMAKER_MARK_KEY" at
atomNames[17] and appended wmaker.mark_key = atom[22], but did not shift
the existing atom[17..21] assignments. Since then gnustep.wm_attr,
gnustep.wm_miniaturize_window, gnustep.titlebar_state,
desktop.gtk_object_path, wm.ignore_focus_events and wmaker.mark_key have
each held the atom for the next name in the table, breaking GNUstep
window-level/titlebar/miniaturize handling, the GTK object-path skip,
WM_IGNORE_FOCUS_EVENTS and the mark feature itself.

Move the new name to the end of atomNames[] so positions 17..22 line up
with their assignments again.
---
 src/startup.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/startup.c b/src/startup.c
index b0e676b2..85830971 100644
--- a/src/startup.c
+++ b/src/startup.c
@@ -387,7 +387,6 @@ static char *atomNames[] = {
  "_WINDOWMAKER_COMMAND",
  "_WINDOWMAKER_ICON_SIZE",
  "_WINDOWMAKER_ICON_TILE",
- "_WINDOWMAKER_MARK_KEY",
 
  GNUSTEP_WM_ATTR_NAME,
  GNUSTEP_WM_MINIATURIZE_WINDOW,
@@ -395,7 +394,9 @@ static char *atomNames[] = {
 
  "_GTK_APPLICATION_OBJECT_PATH",
 
- "WM_IGNORE_FOCUS_EVENTS"
+ "WM_IGNORE_FOCUS_EVENTS",
+
+ "_WINDOWMAKER_MARK_KEY"
 };
 
 /*
--
2.43.0

[Yury]

I'm not sure how this is supposed to work. I
have here an instance of Palemoon browser with
DownThemAll addon, and those two pieces of
software have two separate window specifications
per Wmaker, 'Navigator.Pale moon' and 'DTA.Pale
moon'.

Once upon a time the addon had been appearing
with its own icon in the Wmaker's window list.
Somewhen recently the addon started to appear
with the Palemoon's main program icon, and
changing the addon's icon would change the main
program's icon as well.

With the wmaker code WITH today's patch I can
change the icon for the addon (meaning set a
file and check 'Ignore client supplied icon'),
but then the main program's icon changes to that
icon as well, and I have to go into the main
program's 'Icon and initial workspace' dialog
and change ITS icon to something custom, and
then to clear its 'Ignore client supplied icon'
checkbox.

Only after these convolutions do I get a
separate icons for the main Palemon browser
program (its in-built one) and the DownThemAll
addon window (my custom set one).

I cannot get the addon's in-built icon to appear
at all.

> --
> You received this message because you are
> subscribed to the Google Groups "Window Maker
> Development" group.
> To unsubscribe from this group and stop
> receiving emails from it, send an email to
> wmaker-dev+...@googlegroups.com
> <mailto:wmaker-dev+...@googlegroups.com>.
> To view this discussion visit https://
> groups.google.com/d/msgid/wmaker-
> dev/6ba6b87b-3921-4925-817d-1080e47df33an%40googlegroups.com <https://groups.google.com/d/msgid/wmaker-dev/6ba6b87b-3921-4925-817d-1080e47df33an%40googlegroups.com?utm_medium=email&utm_source=footer>.

[david.m...@gmail.com]

hi Yury,

I don't think what you mention is related to that fix.
I will try to reproduce the behavior to see if its expected.

regards,
david

[Yury]

On 13/06/2026 15:50, david.m...@gmail.com wrote:
>
> On Thursday, 11 June 2026 at 12:02:27 UTC-4 Yury
> wrote:

...

> I don't think what you mention is related to
> that fix.

I disagree. The patch in question actually
*affects* the Wmaker's behaviour w/r to apps
icons attributes, and *in a good way* at that.
But it doesn't fix it completely.

Before the patch, that functionality was
definitely broken, i.e. making no distinction
between a window class and its subclasses at all.

Unfortunately I don't remember whether this EVER
worked 'ideally' and so can't help find the
milestone at which it got really bad. Maybe it
was partially disfunctional all the time. But it
definitely got worse some time ago, maybe in
2023? I rarely touch this functionality.

-Yury

[david.m...@gmail.com]

Can you test the patch enclosed "wmaker: stop the inspector overwriting the group leader's attributes" to see if that helps ?

 

[Yury]

On 14/06/2026 18:04, david.m...@gmail.com wrote:
> Can you test the patch enclosed "wmaker: stop
> the inspector overwriting the group leader's
> attributes" to see if that helps ?

Thanks for looking into the matter. Just tested
this.

I'm working with the previous example, an

instance of Palemoon browser with DownThemAll

addon. Nothing else on the system seems to have
different window classes accessible in it,
neither AOO/LibO, nor new Firefox.

Now Wmaker seems to treat the first access of
icons after the setting the icon explicitly
(checking 'Ignore client supplied icon', apply,
save, close the dialog) differently from the
second one (and all the subsequent ones).

On the first access (I'm using Alt-Tab dialog
panel) the newly set icon propagates from
'DTA.Pale moon' to 'Navigator.Pale moon' IF the
other subclass window had NO explicit icon set
for it (no check on 'Ignore client supplied icon').

But the second access (release Alt-Tab, switch
input focus to some other window -- this or its
equivalent IS needed, call up Alt-Tab dialog
again) shows the icons on that pair set properly.

If the other subclass window has its icon set
explicitly by the moment of change, the
propagation does not happen even for the first
access.

***
Reverting to the client supplied icon
(UNchecking 'Ignore client supplied icon', etc.)
seems to work properly, but I didn't look into
it as closely.

***
The client supplied icon in the DownThemAll
addon (which I know for a fact IS there) still
does not show anywhere.

-Yury

[david.m...@gmail.com]

hi Yury,

can you test the patch enclosed ?

thanks,

david

[Yury]

I think WMaker works 99% correctly now in that
scenario, in the sense there is no "false
propagation" of icon property.

The remaining percent pertains to the situation
where I change the window's icon (set it to
custom, ignoring the app-provided one) but there
are more than one instances of that window class
(Navigator.Palemoon). Only one instance gets the
new icon, others don't, until the app's restart.

I remind that (for me) the discriminated icon
setting makes sense only with the Palemoon +
GetEmAll installation.
Librewolf, Apache OO, LibreOffice all stamp
their main window's class over all their subwindows.
If there are other applications with
semantically discriminated subwindows, please
let me know, I'll be happy to test.

Thank you very much for your work!

> --
> You received this message because you are
> subscribed to the Google Groups "Window Maker
> Development" group.
> To unsubscribe from this group and stop
> receiving emails from it, send an email to
> wmaker-dev+...@googlegroups.com
> <mailto:wmaker-dev+...@googlegroups.com>.
> To view this discussion visit https://
> groups.google.com/d/msgid/wmaker-dev/

> b8cd66f9-8518-4e9d-819b-1fed0ec85eebn%40googlegroups.com <https://groups.google.com/d/msgid/wmaker-dev/b8cd66f9-8518-4e9d-819b-1fed0ec85eebn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[david.m...@gmail.com]

Thanks for the feedback Yury.

Carlos I believe  0001-wmaker-prefer-per-window-_NET_WM_ICON-in-the-switch-.patch is good to commit.

[Yury]

Could you enhance it a little, to make the fix
complete?
What I mean is other running instances of the
SAME window class do not get the updated icon.
Only the instances newly started after the change.
Is there an internal message or a signal to
propagate the setting?

> <http://groups.google.com/d/msgid/wmaker-dev/>
> >
> b8cd66f9-8518-4e9d-819b-1fed0ec85eebn%40googlegroups.com <http://40googlegroups.com> <https://groups.google.com/d/msgid/wmaker-dev/b8cd66f9-8518-4e9d-819b-1fed0ec85eebn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/wmaker-dev/b8cd66f9-8518-4e9d-819b-1fed0ec85eebn%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> You received this message because you are
> subscribed to the Google Groups "Window Maker
> Development" group.
> To unsubscribe from this group and stop
> receiving emails from it, send an email to
> wmaker-dev+...@googlegroups.com
> <mailto:wmaker-dev+...@googlegroups.com>.
> To view this discussion visit https://
> groups.google.com/d/msgid/wmaker-

> dev/70faa215-8889-4c5a-
> ab8d-32a0d0f554fcn%40googlegroups.com <https://
> groups.google.com/d/msgid/wmaker-
> dev/70faa215-8889-4c5a-
> ab8d-32a0d0f554fcn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[david.m...@gmail.com]

On Friday, 17 July 2026 at 03:37:08 UTC-4 Yury wrote:

Could you enhance it a little, to make the fix
complete?
What I mean is other running instances of the
SAME window class do not get the updated icon.
Only the instances newly started after the change.
Is there an internal message or a signal to
propagate the setting?

I will have to check, I fixed it quite some time ago on my local instance.

You have to propagate the change event.