summaryrefslogtreecommitdiffstats
path: root/desktop/wmcliphist/BUG.txt
diff options
context:
space:
mode:
Diffstat (limited to 'desktop/wmcliphist/BUG.txt')
-rw-r--r--desktop/wmcliphist/BUG.txt35
1 files changed, 35 insertions, 0 deletions
diff --git a/desktop/wmcliphist/BUG.txt b/desktop/wmcliphist/BUG.txt
new file mode 100644
index 0000000000..b8334858d7
--- /dev/null
+++ b/desktop/wmcliphist/BUG.txt
@@ -0,0 +1,35 @@
+FIXME: There is a really annoying bug, seems to be an interaction
+between gtk and windowmaker's docking mechanism. To reproduce:
+
+- Start wmcliphist normally
+- Place wmcliphist in the dock (if not already there)
+- Right-click wmcliphist dock icon, select "Exit"
+- From a terminal, run "wmcliphist -c notacolor" (any unknown color
+ string), or "wmcliphist -b nosuchbuffer". Basically anything that
+ causes wmcliphist to pop up a warning dialog on startup.
+- Click "OK" in the warning dialog.
+- Now, wmcliphist is running, but it has failed dock. It's
+ running in an icon (like an un-docked dockapp)... and in the dock,
+ there is a blank icon where wmcliphist should be. Attempting to
+ drag the wmcliphist icon to the blank icon won't work (though you
+ can dock it in another empty dock position).
+
+I tried various things to fix this (rewrote show_message() to use
+gtk_dialog_new_with_buttons(), added a sleep(1) before showing the
+dialog, call gtk_main_iteration() before popping up the dialog), but
+none of it helped. Fixing this might require a patch to WindowMaker
+itself...? Anyone interested in fixing this should have a look at
+foo_create_main_icon_window() in wmcliphist.c. If you don't understand
+what's going on there (and I admit I don't), you probably have little
+chance of fixing this bug...
+
+One approach I can think of: The trouble seems to be caused by calling
+show_message() before gtk_main() has been called. If show_message()
+gets called later (after the app has been docked), all is well. So for
+startup warnings, we could use g_timeout_add() to display the warnings
+later. Unfortunately one of these ("Some items from history will be
+lost") isn't a warning with just an OK button, it's a Yes/No question,
+and by the time gtk_main() is running, it's too late for the No answer.
+Turning that into a "Some items from history were lost. [OK]" kinda
+violates the author's intent (he wanted to make sure no data was lost
+by accident).