File: winmanager.html

package info (click to toggle)
wily 0.13.41-7.3
  • links: PTS
  • area: main
  • in suites: buster
  • size: 2,560 kB
  • ctags: 3,426
  • sloc: ansic: 25,364; perl: 580; makefile: 448; sh: 415; python: 30; exp: 17
file content (35 lines) | stat: -rw-r--r-- 1,472 bytes parent folder | download | duplicates (9)
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
<H2>The Wily Window Manager?</H2>

<P>Window management is probably the biggest open problem with Wily,
probably because there's no real <I>solution</I>, only heuristics.

<P>The first iteration of Wily creatied a bunch of separate X windows
and let the window manager handle arranging them.  This seems a more
modular, tool-based approach.  However, bitter experience showed that
most existing window managers just don't cut it when you're quickly
creating and deleting lots of windows.  Acme's window management,was
much better.

<P>The logical solution then would be to write an X window manager that
works like the window management in Acme.  However:

<UL>
<LI>Writing a window manager requires knowing a _lot_ more about X than
I ever want to know

<LI> Either the wily windows would need to be separate processes,
communicating probably via some sort of X IPC (more arcane X'ery), or
libXg would need to be modified to allow multiple windows (O who will
save me from this plague of X?)

<LI> This sort of window manager would probably _not_ be appropriate
for managing the other windows normally on the desktop.
</UL>

<P>So Wily is designed to be run in one big window, and it does its own
window management within that.  It's a bit of a hack, but probably the
best solution for the moment.

<P>Still, I hope it shouldn't be too hard to remove the "Wily is managing
all the windows" assumption from the code if some brave soul solves the
problems mentioned above.