|Development quick access|
[+] Release todos
Many desired features may not be desired or even may not work at all on some users systems. To accommodate all the possible combinations and dependencies (and to have a clean internal structure) a more module based setup would be desired.
Migrate to another lisp system? Edit
Feb 2009 thread Edit
- One viable option could be common lisp. It has Xlib and GTK2 bindings in its own tree, but that may be incomplete.
- Maybe guile, or other variants of Scheme, could be another option. It's actively supported by the FSF and it has already bindings for gtk, cairo, glib, gconf, etc. Also it's simpler and easier to learn (some schools use it to teach basic AI programming).
The above proposal is natural. However, it requires the complete rewritement of the core sawfish, which is not realistic since we're in short of developers. Other todos of higher priority exist. In addition, librep has been stable for years, and it requires little improvements. (Rep-gtk may need more hacks.) - Teika kazura, Feb 2009
May 2009 thread Edit
Read this thread in May 2009.
Break into modules Edit
Separate the current Sawfish into a few different pieces. The idea is to separate out what is necessary and what is optional. Many proposed features and ideas are either not desired or possible on all machines. If a feature is a separate module or option then it would be simpler to accommodate all users. Ideally the rep modules system would be able to "check" if the modules exists and/or works. Such a checking ability would allow for programmatic selection of abilities. Ideally there would be a minimal base sawfish set containing just the X bindings and the event loop and maybe a little blessed lisp code. Optional modules/code could be either straight loaded or register itself (exact mechanism depending).
I'd prefer just a (load 'feature) or (require 'feature) in there .sawfishrc or even (use 'feature-set)
to do this properly I think a change to librep would be needed. (load 'foo) or whatever returning nil on failure instead of erring (I may be wrong on what it is doing though)
A "module", "package","feature" like setup, like how eclipse is done
Core X bindings Edit
All the base X data types and bindings. This would only include the parts of X that can be expected in most if not all X implementations that sawfish will run on. With proper internal separation only minimal bindings would needed to be loaded at any time. This can be reused in other stand alone modules or rep code, say a stand alone Composite Manager or some monitoring app (a pager?). One use of this would be as a basis of a standalone GLX binding. It would need the base X connection objects but would not want any of the extra sawfish baggage but still be able to interact if needed.
Base Event loop Edit
This is the main event loop code, defines the base hooks and event model. Also defines the data structures for windows and window managing that the lisp code can use to implement various ideas. Having this as a separate package means that there is a clearer separation what is needed to manage windows in an extensible manner and the features that are implemented on top. The question that needs to be answered here is, what model is needed? The answer will change as various extension and possibilities are explored.
Custom lisp code Edit
All custom lisp code goes here such as tabs (implementations and logic for them) etc. As a separate code package would allow for clearer separation. For example, with tabs there are many ways of displaying and controlling them: a widget in the decoration, each window on the backside of the others (like in compiz).
Where to but the sawfish and sawfish-client binaries? The sawfish binary can be implemented as a shell script (load configuration info and start the main event loop). What about the client? It may require custom rep bindings and some lisp code to control.