On Sun, Aug 15, 2004 at 12:23:51AM -0400, Jeremy Maitin-Shepard wrote:
> Sure, it probably would be better for the status bar to be implemented
> in a separate program, but since the WM can do it reasonably well, it
> doesn't seem to be a problem right now.
I'm just talking of a separate status daemon that reports monitored
things to ext_statusbar, not a wholly separate program. That might be
the Proper way, but it's too much work if you want to integrate it
well with Ion.
> I suppose it is true that you use that pattern consistently throughout
> ion, and it is really just a matter of preference. I am just more fond
> of letting the user define the structure and naming of his own
> configuration files, particularly since in this case, the configuration
> file is what is actually invoking the library (ext_statusbar.create).
There's no reason why you couldn't use that kind of scheme; just use
a different name for the configuration files and remove the cfg_* files
so they're not loaded.
> Okay -- in the sense that they are designed to function like comments, I
> think they are useful (although a standard comment would be just as
> suitable).
> I figured given the syntax used that they were designed to
> be read by some future built-in help feature or configuration utility --
Currently the documentation is used to build the manual pages, but
eventually there might also be a partially built-in (script to generate
HTML to display in lynx, for example) feature to display documentation
for the active binding set.
> I believe that the problem of needing separate bindable commands can be
> avoided. Right now, I believe that most of the standard key bindings
> are single function calls -- a builtin help feature could check the
> bindings, and if it is a simple function call, it could display the
> documentation for the function being called.
Yes, I actually wrote such a kludge once. The problem is that the
documentation available for the functions themselves is not suitable
for simply binding listings. For example, ioncore.exec('xterm')
Run an xterm
vs.
Make the call ioncore.exec('xterm'):
Synopsis: bool ioncore.exec(cmd)
Description:
Run \var{cmd} with the environment variable DISPLAY set to point to the
X display the WM is running on. No specific screen is set unlike with
\fnref{WRootWin.exec_on}.
--
Tuomo
