HACKING


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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

Words of wisdom

1. Make sure all changed work on both KDE and Gnome

2. The System tray protocol specification can be found at
	http://freedesktop.org/Standards/systemtray-spec/systemtray-spec-0.1.html

3. The KDE System tray Docking Protocol can be found at
	http://developer.kde.org/documentation/library/kdetqt/kde3arch/protocols-docking.html

4. The site i use for Xlib reference
	http://tronche.com/gui/x/xlib/function-index.html

5. Qt Documentation at http://doc.trolltech.com

6. There's do or no do. There's no try.

TDEDocker Window Docking Strategy and a little bit of history
-----------------------------------------------------------
Couple of things that will help you if you are looking through the code.
I wanted a single instance of TDEDocker to be running all the time. So,
whenever a new instance of TDEDocker was created it would ask the previous
instance take over.

Two things to know about
1. Mapping from the PID (process id) to WID (window id)
2. How to let the previous instance know about app_to_launch

Lets deal with them one by one.
1. PID to WID mapping is easy if people followed rules. Just read _NET_WM_PID
for a window. If it matches the one app's PID we just created, that window is
the one we want to dock. Its not as simple as that. Programs have "splash"
screens. A nice thing is that these "splash" screen have the _WM_TRANSIENT_FOR
property set. So, we can skip those windows. There are these bunch of programs
(like gaim, xmms) that create windows and dont put this property on them. Arrgh.
What we do to counter these applications is to look for interesting windows
possibly created by the process until the process dies. Have a look at the code
for a better understanding.

2. Sending ClientMessages to previous instances with the program name and
arguments is painful and makes the code more complex. Before 1.0, I used to dump
all the program arguments in ~/tdedocker.<pid> and send the pid in a 
ClientMessage. The file is then deleted after processing. As of 1.0, I set a
property _KDOCKER_<pid> on the TDEDocker initial instance's window which holds
the program arguments. (The correct way to transfer information is using
XSelections)

TRACING
-------
Add the following line in tdedocker.pro (in fact just uncomment it)
DEFINES += ENABLE_TRACING

Now do a "make clean" and "then make".

Launch TDEDocker. Try recreating the problem.
- Right Click on the tray icon.
- Choose "About TDEDocker"
- You should see a button called "Show Trace". Please note that this button
  will appear only when compiled with tracing
- Try debugging yourself or send it to me
- If you send SIGUSR1 to the TDEDocker process, it will dump all the trace to
  ~/tdedocker.trace