This can happen since the StartupWMClass can have any value (e.g. if an app has multiple launchers for some reason). Also the command in Exec= can be non-unique if the same app has multiple launchers or uses an interpreter that is not parsed by us (e.g. python).
To handle this, we only assume that the app-id (as reported by the WM) and the .desktop file ID are unique (if multiple apps use the same app-id, we cannot do much to distinguish them, although there is already some special casing under X11 where a separate "name" might also be provided).
Desktop file ID should be always unique and this is checked strictly. However, the alternate ID extracted from either the Exec= or StartupWMClass= key can be non-unique (and also match another .desktop file), so handle this case better: we include these cases as well and just leave out the non-unique key.
These are already removed in some, but not all cases, and can be potentially problematic when matching icons or desktop files.
Specific example: winecfg.exe with no .desktop file and winecfg.png as icon.
This can cause issues if two apps use IDs that only differ in their suffix, but this is unlikely.
This seems to be feasible without issues.
On X11, continue using GLX by default (EGL can be enabled by a command line option, but this should eventually be made a configuration option)
cairo_dock_show_tips() calls _cairo_dock_get_next_tip(pTips) ,
which uses pTips->pCategoryCombo , so this must be properly
created (initialized) before calling _cairo_dock_get_next_tip(pTips).
Previously, when loading a launcher or separator, if it was part of a nonexistent container, it was created as a new root dock. If later encountered as a subdock, the type was changed to a subdock. This does not work with the new positioning and Wayland, since subdocks need to be created as popup windows with a correct parent set. This is not easy to achieve later, so instead, ensure that all subdocks are loaded first, before loading launchers and separators.
