On Sun, Mar 18, 2007 at 11:05:55AM +0000, Tuomo Valkonen wrote: > On 2007-03-18, Ted Zlatanov <[EMAIL PROTECTED]> wrote: > > I think this kind of help should actually live in the scratchpad, it's > > exactly the right pop-up model. > > As already mentioned, this has the problem that the user has to be > able to toggle it on, _and_ also has to toggle it off to do anything. > The statusbar would provide a constantly visible help or instruction > area. > > > Also, it should automatically discover the current key bindings for > > commands. So if I rebind "delete split" to key X, I want to see X > > there. that's how `mutt' dynamically adjusts it's help pages. I think that is good, but even better would be augmenting this by parenthesis a la "(changed from default definition xxx)" so that one could incrementally restore default bindings easily if need be. > > There are no identifiable commands, only arbitrary function calls. > (The closest Ion comes to commands, is the context menu...) However, > by overriding `defbindings`, it is possible to store this information > and the `bdoc` documentation -- which may, however, be too long for > a simple statusbar help display. > > > blank screen = first start (determined by Ion, e.g. by missing ~/.ion3 > > directory) > > Ion already has first start detection, for the welcome xmessage -- > that many seem to ignore. > > > Does this seem like the right way to go, a linear tutorial that > > introduces simple concepts one by one? > > Perhaps, but as already mentioned, in the scratchpad, it has the > problem of the user having to constantly toggle it. > I agree: scratchpad as the sole location is no good for this. but why not make it available instead of the ion3-manpage with MOD1-F1? the manpage everyone will be able to access otherwisei -- be it via F1 (where it is the default anyway), be it via some xterm.
having the tutorial come up with MOD1-F1 (and an initial xmessage at first startup that it is there to find) would be a good thing. It could even still be in `man' format. (or some more flexible troff macro package, such as `ms'. one then could even use the troff preprocessors such as `tbl', 'eqn', `pic', but keep the ability to get a reasonable ascii/latin1 approximation of the formatted document in the terminal). I recently convinced some colleague to dump GNOME and try out `ion3' (hey! and just for the record: he at that point tried to compare `ion3' to `wmii' and immediately dropped the latter due to it's inability to manage his second monitor). what I noticed, then, were two things: 1. the list of default keybindings and available actions is somehow there in the manpage but people have difficulties at first to understand the terminology (workspaces, clients, objects, frames etc.) and thus difficulties to understand what the commands do. conclusion: the tutorial should try to make this easier to grasp. 2. more important is to tell the users, where to configure what and how: in other words, each explanation of an action/keybinding should be augmented by the name of the config-file where I can change the binding. suggesting a strategy how to do customization in such a way that it survives with minimal damage any update would be helpful, too (if you simply copies over everything to ~/.ion3 and edits this heavily you've to start over from scratch the next time, if the default config-scripts have changed due to update. probably some kind of `dopath' strategy would be the best thing to suggest?). joerg
