-*- indented-text -*-
This file is probably out of date. Use bugzilla.gnome.org instead. See
the file `BUGS' for instructions on reporting sawfish bugs.
TODO list for sawmill
Bugs are marked !, things that should be done soon are marked +,
and longer-term ideas are marked -
Before next release
! click-to-focus mode; cycle from a shade-hovered window to a normal
window, hideous flicker ensues
! pavel says that in click-to-focus mode windows may occasionally
become unfocusable (i.e. every couple of days or so)
[ I added some code with high kludge-quotient, but still need a
real solution ]
! uses a really kludgey method of getting command documentation
! need better error handling in sawfish-ui (e.g. values that don't
match widget types)
! workspace names don't change as workspaces are added/deleted
solution: use an alist mapping workspace ids to workspace names,
transform-window-workspaces also transforms the alist..?
! in xdvi with emulate3buttons, press and hold right, then press
left, the wm root menu appears?!
! `:type (or ...)' doesn't get serialized (and can't be)
! running multiple instances of the wm loses
(because they share the same ~/.sawmill/custom file)
! keeping unshown windows unmapped isn't so great?
the ICCCM says that to go to Withdrawn state a window must send a
synthetic UnmapNotify, so this is not a problem. But it also says:
`NormalState - the client's top-level window is viewable'
one option is to set all hidden windows to IconicState. But this
would probably confuse the tasklist applet..
[ I have a patch to do this, and it totally breaks the workspace
handling of desk-guide and the tasklist ]
! play-sample.c doesn't seem to work on solaris (esdplay does)
! anim-outline just guesses where windows will be iconified to, so it
usually gets it wrong
[ the new GNOME/KDE wm hints have support for this ]
! timestamp ordering code falls over with machines that vary their
! swapped-out window properties aren't saved with session
[ this also means that a window in different viewports in different
workspaces will get saved in the single swapped-in viewport ]
! I bring up an exmh transient, and place it so it's totally enclosed
by the exmh parent window. I put my mouse in the middle of the
transient so it has focus (I'm using sloppy focus.) I then move to
a different desktop, and back. The transient window has focus still
(ie. I can type in it), but the frame is drawn in the unfocused
! edge-flipping while interactively placing a window can leave
rubber-band traces [this is hard to fix..]
! if i press M-button1 (move-window-interactively) but not move the
window and _hold_ button1, it gets raised, but the window
decoration is not drawn, only if i move the window or release the
+ write documentation: workspaces, viewports, window groups, alist
frame patterns, frame parts as objects, placement, focus modes,
symbolic event structures...
+ allow enter/leave-notify events to be suppressed?
(use this when switching workspaces, but focus must be preserved)
Window manager tasks
! when drawing into frame parts manually, no way to set shape
! should save increment-relative dimensions (not pixel relative)
+ allow unused themes to be garbage-collected? (custom options?)
+ commands to forward buttons 4&5 (mouse wheel) to the focused
window. My first attempt at this doesn't work..
+ make command list hierarchical?
+ aspect ratio hints
+ look into tear-off menus
need some way of notifying when dynamically generated menus have
+ some hci ideas:
placement mode to favour some/any of:
- near other windows in the same group
theme that has visual cues (colours?) for group membership
+ look at kde khotkeys for ideas
+ support the new GNOME/KDE wm interaction protocols
[ I've implemented most of the draft spec now ]
+ sound themes
+ drag-and-drop to configure window appearance?
this could depend on the theme, but it would be good to allow
dropping of colors (gradients?) and images for at least some themes
add a hook (frame-part-drop-hook?)
also allow theme files to be dropped on windows
+ add a (destroyed . FUN) attribute to display-message
also allow multiple messages to be displayed/managed
+ allow transparent backgrounds to frame parts
need to use overlays, solaris X server supports two types, what
+ add option to prevent workspace switching while cycling
+ in interactive placement, allow the window-pointer position to be
+ allow configuration of where move/resize display appears
allow relative to window, or relative to root, for both x and y
+ Handle multiple-screen displays
What are the issues? Multiple root windows, and..?
[ use `Xnest -scrns N' to simulate multi-heading ]
+ Icons (?)
Icons could be handled using a special frame/window type
- Rotated text
Allow text to be rendered at angles (in multiples of 90 degrees?).
This could be useful for the sides of windows
[ scp found a library for doing this with Xlib.. ]
- GTK theme
Is there any way that the gtk theme could support engine-based GTK
themes? Probably not without using a subprocess (since the engines
are written to GDK, not Xlib), this could get hairy..
Also, why do themes with bg_pixmap set use so much memory? Is it
just because the images are XPM's..?
re: engines, now that frame parts are proper objects, and thus
fg/bg specifiers may be functions, it should be possible to spawn a
GTK slave to do all redrawing (using the gtk_draw_foo functions)
have to be careful to avoid deadlocks though. Maybe avoid using
fifos for this reason, perhaps use SYSV shared memory segments and
[ I have a patch that does a first approximation of this, the
problem however is that GTK doesn't have enough drawing primitives
to cleanly handle all buttons etc.. ]
- Remove root menu?
The argument is that doing this removes the need for the wm to
select ButtonPress events on the root window (which is a point of
conflict with, for example, a desktop file manager)
The sole need for the wm to manage the root menus (as far as I can
see) is so that it can offer window management functions (such as
"interactively move the focused window" or whatever), but all
these things can be invoked through sawmill-client, i.e.
"sawmill-client -c move-window-interactively"
With a bit of work the dynamically generated menus (e.g. the window
and workspace submenus) could also be generated through the client
- CORBA interface
I have a prototype idl, but it needs rewriting. The idea is to
basically reimplement the new GNOME/KDE wm hints using CORBA,
perhaps with some other useful features
Use rep-orbit to provide the CORBA binding
allow applications to inject ``policy'' into the wm to affect their
windows. This could either be (sandboxed?) lisp code, or something
more declarative (but even then it could be lisp data)
obvious uses for this: focus policy, placement policy, appearance
(apps that must (?) theme themself could also control their frames
without losing the consistent feel provided by the wm), ...?
(didn't NeWS allow this kind of thing, must do research..)