2009/6/24 Aidan Skinner <aidan.skin...@gmail.com> There is still some layout work to do on it, and as yet the result of > > operations is not explicitly reported (but in several cases, is > immediately > > visible), mainly because i havent decided on the format: the traditional > > info/error dialog with ok button works, but a status bar report area > might > > be a less intrusive/clicky solution. > > > I like the status bar approach and visible updates. I'd only raise a > dialouge if there's been an error. It's probably worth documenting UI > conventions as you go so that it remains consistent. >
Will do, its fairly simple so far though: Most 'viewing' operations are performed implicitly in the UI to present the initial info, eg loggers, user, message lists, which are sortable. Additional operations are grouped according to relevance, either linked to the tables or seperately. If there is only one operation on a set of presented data, users can either use the provided button or double click an entry in the table. If there are multiple operations on presented data, only the buttons will initiate the invocation. Any operation that modify visible data cause all the currently presented data to be updated following execution. So far, the only operations that doesnt apply for are 'View Selected Message' after selecting a message in the table, and 'Set Password' for a selected user password. Also, once implemented, all presented info will be updated automatically at a desired interval regardless of additional method invocation. All non-viewing operations present an ok/cancel opportunity, whether there is need to request input(which it does at the time) or not. Robbie
