1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
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).
|
