-*- indented-text -*-


IMPORTANT:

This file is probably out of date. Use bugzilla.eazel.com 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
===================



Outstanding bugs
================

  ! 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
    clock rate..

  ! 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
    style.

  ! 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
    button

  + 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
    changed

  + 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
    about XFree?

  + add option to prevent workspace switching while cycling

  + in interactive placement, allow the window-pointer position to be
    configurable 

  + 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
    semaphores?

    [ 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

  - `wmlets'

    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, c.f. themes
    created by sawfish-themer)

    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..)



ui tasks
========

see lisp/sawfish/ui/WISHLIST



themer tasks
============

  ! only the `default' window type may be previewed

    [ workaround: temporarily change the `default' mapping ]

  + rewrite to use sawfish.gtk modules

  + allow functional frame part attributes to be defined

    possibly add an `(extra sexp)' field that is evaluated then added
    to the end of the frame part definition 

  + allow dynamic patterns to be defined (e.g. gradients)

  + better previewing:

    * highlight the current frame part somehow

    * clicking/hovering on a frame part selects that definition

    * auto-update, either after each change, or from the idle-hook?

  + support a pseudo-pattern containing the window's icon