чување adf8d2a8f7a926ed248fcd15e8bd764daab7513e
родитељ 962f7b852ac9c1b01fbdd8c6edee0dc14e75a73a
Аутор: Страхиња Радић <contact@strahinja.org>
Датум: Sun, 17 Dec 2023 13:57:20 +0100
WMNewApp.1: Add bugs from README to manpage
Signed-off-by: Страхиња Радић <contact@strahinja.org>
Diffstat:
| M | WMNewApp.1 | | | 36 | ++++++++++++++++++++++++++++++++++++ |
измењених датотека: 1, додавања: 36(+), брисања: 0(-)
diff --git a/WMNewApp.1 b/WMNewApp.1
@@ -30,3 +30,39 @@ Prints usage information.
.Sh AUTHORS
.An "Yourname Here" Aq address@example.com ,
2020-2023
+.Sh BUGS
+.Bl -dash -width "-" -offset indent
+.It
+WINGs bug: when
+.Dq Shared application icon
+is selected for an application generated with
+.Nm,
+one of the two things happen, depending on whether
+.Fn WMMapSubwidgets
+and
+.Fn WMMapWidget
+for the main window is called before (A) or after (B) creating the main menu:
+.Bl -tag -width "A)" -offset indent
+.It A)
+Every instance of that application will generate a
+.Dq phantom copy
+of the application menu, which persists after closing the application, can't be
+closed with
+.Sy xkill ,
+apparently isn't associated with any process, and for which
+.Sy xprop
+doesn't detect any properties.
+Interestingly, when the main application is closed, and relaunched, the extra
+copies of menus work in the new instance.
+.It B)
+The menu is not shown at all.
+This is the same behavior/known bug as in
+.Sy FSViewer .
+.El
+.Pp
+I chose to follow option (B), same behavior as in
+.Sy FSViewer .
+I believe that having no menu at all, and behaving consistently with known
+application is better than having leftover uncloseable copies of menus around.
+[SR]
+.El
