-*- indented-text -*-

TODO list for sawmill
*********************

Bugs are marked !, things that should be done soon are marked +,
and longer-term ideas are marked -



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

  ! problem with the timestamp sanity checking, if you turn the
    system clock backwards, it discards all events..!

  ! maximizing a window when the pointer is outside it loses focus?

  ! Snap to edge does not work if I'm switching viewport while dragging
    the window around.

  ! set auto-raise and Panel ``keep panel below'' option, then start a
    GTK app (e.g. gnomecal), activating an app-menu can get obscured by
    the window being auto-raised

  ! loading a session shifts window positions by the frame offset

  ! swapped-out window properties aren't saved with session

  ! menus appear too high in java/swing apps until window is moved

    [ works okay for me with SUN Java on Solaris.. ]

  ! * Open Netscape
    * Click the botton on the status-bar that brings the little
      browser/mail/news/editor toolbar into its own window.
    * Now iconify this window - instead of being iconfied on its own, it
      goes back onto main netscape browser window as if it was closed
    * Now open it again - SLAM!
    * Suddenly the window opens and closes like mad causing the window to
      flicker on the desktop so fast you can't click on anything to get
      rid of it, and you have to 'kill' it (sometimes it eventually dies
      on its own in a minute or two).

  ! xv/java-apps get weird placement [apps being non-ICCCM compliant?]

  ! the gnome _WIN_MAXIMIZED_ hints are ignored when the window is
    mapped, since it's not possible to maximize the window at that
    point (until the frame has been created)

  ! turn off mouse warping options, put cursor in window in center of
    screen (under message window), M-TAB, and the pointer leaving the
    message window will refocus the original window

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

  ! when you switch viewports, sawmill will sometimes get confused as
    to which windows were where, and leave windows on seemingly random
    viewports [I'm not convinced, could this be the desk-guide thing?]

  ! 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

  + features can't be both enabled via customization and demand-loaded

  + write documentation: workspaces, viewports, window groups, alist
    frame patterns, frame parts as objects...

  + allow enter/leave-notify events to be suppressed?

    (use this when switching workspaces, but focus must be preserved)

  + update to build foo.la not libfoo.la when rep 0.11 is sure to be used



Window manager tasks
====================

  + Colormap handling (WM_COLORMAP_WINDOWS etc)

  + Support other visuals

  + revamp the autoload system, and handle both customizations and
    functions

    scan all lisp files in directories outside of lisp-lib-directory
    and sawmill-lisp-lib-directory for autoload decls

    make sawmill-ui extract defcustom decls straight from lisp files
    somehow?

  + add property take-focus (focus when window appears)

  + handle language codes better in gnome-menu

  + add a function to turn icons into lisp images

  + add a (destroyed . FUN) attribute to display-message

    also allow multiple messages to be displayed/managed

  + allow transparent backgrounds to frame parts

  + add option to generate rendered images on demand (can we defeat
    imlib's caching?)

  + add option to prevent workspace switching while cycling

  + option: when switching workspace, display the workspace name

  + add option send-window-to-workspace won't select workspace

  + support for synthesizing events

  + threshold options to control window-move sensitivity?

  + wrap-around option for moving viewports

  + allow workspaces to be named?

    this is done, set the workspace-names variable to a list of
    strings; but it's not yet customizable through the ui

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

  + change edge snapping to use resistance instead of magnetism?

    perhaps allow mode to be set as an option; it would be nice to
    differentiate between screen edges and window edges

  + allow configuration of where move/resize display appears

    allow relative to window, or relative to root, for both x and y

  + windows appear above xscreensaver?

    there's no way around this, xscreensaver maps its virtual root
    window with override_redirect set, so the wm never even sees it
    (otherwise it could be moved to an upper layer)

  + Handle multiple-screen displays

    What are the issues? Multiple root windows, and..?

    [ use `Xnest -scrns N' to simulate mulit-heading ]

  + Add checked and radio menu item support

  + Smart placement

    How can the best-fit cost function be improved/optimised?

  + Icons (?)

    Icons could be handled using a special frame/window type

  + Support the KDE hints

    [ Apparently there's no definition of kde-wm interaction except for
    the kwm sources, which are supposed to be ``heavily commented'' ]

  + clone some ctwm functions:

       f.pack string
               Where string is either : "right", "left", "top" or
               "bottom" The current window is moved in the speci
               fied  direction  until  it  reaches  an   obstacle
               (either another window, or the screen border). The
               pointer follows the window.

       f.bottomzoom
               This function is similar to the  f.fullzoom  func
               tion, but resizes the window to fill only the bot
               tom half of the screen.

       f.leftzoom
               This variable is similar to the f.bottomzoom func
               tion  but  causes  the  selected  window  is  only
               resized to the left half of the display.

       etc.

  - 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.. imlib2 will
    support rotated text? ]

  - 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

  - Target guile instead of rep

    In theory this is a good idea, probably a lot of work, but still.
    These are some of the arguments/justifications for sticking with
    rep:

	1. The single-threadedness is not a problem for a window
	   manager, where the flow of control pretty much follows the X
	   event queue

	2. It's lighter-weight than guile (though the effects of sharing
	   libraries probably negates this a bit)

	3. I have some half-cooked ideas about using the built-in
	   remote-file handling to access a theme repository somewhere

	4. It has lots of support (i.e. hooks, input handling) for
	   being used as an extension language

    And these are some reasons for using guile:

	1. Scheme's a cleaner and more modern language than rep's Lisp
	   dialect (one namespace, lexical scope, continuations, ...)

	   [ first two are now done by rep also ]

	2. More people know scheme than lisp (though the closeness to
	   Emacs-lisp offsets this)

	3. Sawmill would depend on fewer "weird" libraries (librep,
	   rep-gtk), that someone (i.e. me) has to maintain

    The main things counting against guile are that I've never used it,
    and that I'm lazy

    [ despite the above paragraphs I have no plans to move to guile
    anymore, they're just left FYI ]

  - CORBA interface

    First write CORBA support for rep (does guile support CORBA?), then
    what? Would this be useful?



sawmill-ui tasks
================

  + do i18n on choices from `:type symbol' options

  + add a `Program Launchers' group, that allows commands to be defined
    for launching programs

  + split theme menu by first letter, if many themes to show

  + rewrite sawmill-ui to use ``items'' as in sawmill-themer (complex
    widgets represented by functional data types). This would allow
    more complex custom types, i.e. `(or number string)' etc...

    also, add provisions for extensibility (i.e. adding new item types
    at run-time)

    also, add simple dependences (i.e. widgets can be activated by a
    separate boolean option)

    another idea: textual search for options/commands

  + Allow text-entry commands in bindings dialog?

  + use panes to separate areas in bindings widget

  + add capplet desktop entries to share/gnome/apps/Settings as well as
    the control center tree

    then again.. there's a problem with this -- gnome menus are
    _static_, whereas sawmill's customization groups are _dynamic_

    i.e. the `customization' root sub-menu wouldn't match the menu in
    the gnome `settings' tree. this would be bad since the user may not
    discover the dynamic menu and thus miss many of the options..

    [ apparently, this is an issue which may be addressed in future
      versions of the control center ]



sawmill-themer tasks
====================

  ! only the `default' window type may be previewed

    [ workaround: temporarily change the `default' mapping ]

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

