File: WISHLIST

package info (click to toggle)
sawfish 1%3A1.3.5.2-2
  • links: PTS, VCS
  • area: main
  • in suites: squeeze
  • size: 11,636 kB
  • ctags: 1,327
  • sloc: lisp: 22,765; ansic: 15,810; sh: 10,203; makefile: 675; perl: 19
file content (78 lines) | stat: -rw-r--r-- 1,946 bytes parent folder | download | duplicates (7)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

IMPORTANT:

This file is probably now out of date. Use bugzilla.eazel.com instead.

--

  + reversed dependences? i.e. `:depends (not foo)'

  + more widgets:

	(table ("NAME" ...) (WIDGET ...))	[doable]

	(directory-name),

  + maybe use CORBA for wm communication instead of client program? (or
    perhaps support both somehow?)

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

    also, strings embedded in types, e.g. list titles

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

  + another idea: textual search for options/commands

--

Items that have been committed:

  + refresh groups after committing changes

    (since this may cause slots to be added)

  + decide whether to use GNOME widgets or not

    [ all GNOME-specific code must either be in nokogiri-gnome or in
      separate files in nokogiri-widgets, with Gtk+ equivalents in
      nokogiri-no-gnome ]

  + support arguments to commands in keymaps

  + support for loading groups on demand

    only fetch the current group's information
    (which may have been cached from the previous time)

  + method of autoloading group details when demanded

  + more widgets:

	(alist ("KEY" WIDGET)
	       ("VALUE" WIDGET))

	(list "NAME" WIDGET)

	(file)
	(progam)

  + proper revert

  + choice of `apply/revert/cancel/ok', `revert/cancel/ok', or just `ok'

  + autoload widget definitions (e.g. if requesting widget type `foo'
    that is unavailable, look for a module nokogiri-widget-foo)

  + nautilus-like ``user levels'' controlling when options get enabled

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