6
This file is probably out of date. Use bugzilla.eazel.com instead. See
7
the file `BUGS' for instructions on reporting sawfish bugs.
15
Bugs are marked !, things that should be done soon are marked +,
16
and longer-term ideas are marked -
28
! click-to-focus mode; cycle from a shade-hovered window to a normal
29
window, hideous flicker ensues
31
! pavel says that in click-to-focus mode windows may occasionally
32
become unfocusable (i.e. every couple of days or so)
34
[ I added some code with high kludge-quotient, but still need a
37
! uses a really kludgey method of getting command documentation
39
! need better error handling in sawfish-ui (e.g. values that don't
42
! workspace names don't change as workspaces are added/deleted
44
solution: use an alist mapping workspace ids to workspace names,
45
transform-window-workspaces also transforms the alist..?
47
! in xdvi with emulate3buttons, press and hold right, then press
48
left, the wm root menu appears?!
50
! `:type (or ...)' doesn't get serialized (and can't be)
52
! running multiple instances of the wm loses
54
(because they share the same ~/.sawmill/custom file)
56
! keeping unshown windows unmapped isn't so great?
58
the ICCCM says that to go to Withdrawn state a window must send a
59
synthetic UnmapNotify, so this is not a problem. But it also says:
60
`NormalState - the client's top-level window is viewable'
62
one option is to set all hidden windows to IconicState. But this
63
would probably confuse the tasklist applet..
65
[ I have a patch to do this, and it totally breaks the workspace
66
handling of desk-guide and the tasklist ]
68
! play-sample.c doesn't seem to work on solaris (esdplay does)
70
! anim-outline just guesses where windows will be iconified to, so it
73
[ the new GNOME/KDE wm hints have support for this ]
75
! timestamp ordering code falls over with machines that vary their
78
! swapped-out window properties aren't saved with session
80
[ this also means that a window in different viewports in different
81
workspaces will get saved in the single swapped-in viewport ]
83
! I bring up an exmh transient, and place it so it's totally enclosed
84
by the exmh parent window. I put my mouse in the middle of the
85
transient so it has focus (I'm using sloppy focus.) I then move to
86
a different desktop, and back. The transient window has focus still
87
(ie. I can type in it), but the frame is drawn in the unfocused
90
! edge-flipping while interactively placing a window can leave
91
rubber-band traces [this is hard to fix..]
93
! if i press M-button1 (move-window-interactively) but not move the
94
window and _hold_ button1, it gets raised, but the window
95
decoration is not drawn, only if i move the window or release the
98
+ write documentation: workspaces, viewports, window groups, alist
99
frame patterns, frame parts as objects, placement, focus modes,
100
symbolic event structures...
102
+ allow enter/leave-notify events to be suppressed?
104
(use this when switching workspaces, but focus must be preserved)
111
! when drawing into frame parts manually, no way to set shape
113
! should save increment-relative dimensions (not pixel relative)
115
+ allow unused themes to be garbage-collected? (custom options?)
117
+ commands to forward buttons 4&5 (mouse wheel) to the focused
118
window. My first attempt at this doesn't work..
120
+ make command list hierarchical?
124
+ look into tear-off menus
126
need some way of notifying when dynamically generated menus have
131
placement mode to favour some/any of:
133
- near other windows in the same group
135
theme that has visual cues (colours?) for group membership
137
+ look at kde khotkeys for ideas
139
+ support the new GNOME/KDE wm interaction protocols
141
[ I've implemented most of the draft spec now ]
145
+ drag-and-drop to configure window appearance?
147
this could depend on the theme, but it would be good to allow
148
dropping of colors (gradients?) and images for at least some themes
150
add a hook (frame-part-drop-hook?)
152
also allow theme files to be dropped on windows
154
+ add a (destroyed . FUN) attribute to display-message
156
also allow multiple messages to be displayed/managed
158
+ allow transparent backgrounds to frame parts
160
need to use overlays, solaris X server supports two types, what
163
+ add option to prevent workspace switching while cycling
165
+ in interactive placement, allow the window-pointer position to be
168
+ allow configuration of where move/resize display appears
170
allow relative to window, or relative to root, for both x and y
172
+ Handle multiple-screen displays
174
What are the issues? Multiple root windows, and..?
176
[ use `Xnest -scrns N' to simulate multi-heading ]
180
Icons could be handled using a special frame/window type
184
Allow text to be rendered at angles (in multiples of 90 degrees?).
185
This could be useful for the sides of windows
187
[ scp found a library for doing this with Xlib.. ]
191
Is there any way that the gtk theme could support engine-based GTK
192
themes? Probably not without using a subprocess (since the engines
193
are written to GDK, not Xlib), this could get hairy..
195
Also, why do themes with bg_pixmap set use so much memory? Is it
196
just because the images are XPM's..?
198
re: engines, now that frame parts are proper objects, and thus
199
fg/bg specifiers may be functions, it should be possible to spawn a
200
GTK slave to do all redrawing (using the gtk_draw_foo functions)
202
have to be careful to avoid deadlocks though. Maybe avoid using
203
fifos for this reason, perhaps use SYSV shared memory segments and
206
[ I have a patch that does a first approximation of this, the
207
problem however is that GTK doesn't have enough drawing primitives
208
to cleanly handle all buttons etc.. ]
212
The argument is that doing this removes the need for the wm to
213
select ButtonPress events on the root window (which is a point of
214
conflict with, for example, a desktop file manager)
216
The sole need for the wm to manage the root menus (as far as I can
217
see) is so that it can offer window management functions (such as
218
"interactively move the focused window" or whatever), but all
219
these things can be invoked through sawmill-client, i.e.
220
"sawmill-client -c move-window-interactively"
222
With a bit of work the dynamically generated menus (e.g. the window
223
and workspace submenus) could also be generated through the client
227
I have a prototype idl, but it needs rewriting. The idea is to
228
basically reimplement the new GNOME/KDE wm hints using CORBA,
229
perhaps with some other useful features
231
Use rep-orbit to provide the CORBA binding
235
allow applications to inject ``policy'' into the wm to affect their
236
windows. This could either be (sandboxed?) lisp code, or something
237
more declarative (but even then it could be lisp data, c.f. themes
238
created by sawfish-themer)
240
obvious uses for this: focus policy, placement policy, appearance
241
(apps that must (?) theme themself could also control their frames
242
without losing the consistent feel provided by the wm), ...?
244
(didn't NeWS allow this kind of thing, must do research..)
251
see lisp/sawfish/ui/WISHLIST
258
! only the `default' window type may be previewed
260
[ workaround: temporarily change the `default' mapping ]
262
+ rewrite to use sawfish.gtk modules
264
+ allow functional frame part attributes to be defined
266
possibly add an `(extra sexp)' field that is evaluated then added
267
to the end of the frame part definition
269
+ allow dynamic patterns to be defined (e.g. gradients)
273
* highlight the current frame part somehow
275
* clicking/hovering on a frame part selects that definition
277
* auto-update, either after each change, or from the idle-hook?
279
+ support a pseudo-pattern containing the window's icon
added
removed
TODO
