Scott and Paul, Thanks for responding to these issues and helping clarify some of them.
> > 11) Clicking the Show/Hide Details Pane toolbar button hides the > > details pane. Clicking it again restores the pane, kinda. It returns > > minimized at the bottom and you need to resize it in order to see any > > details. > > You won't believe how much time I have spent trying to fix > this one. I have no idea why. I am at the point where I > think it is actually a problem with the JSplitPane. If you > have experience with this one, HELP, it drives me nuts too. I'm not a Java GUI coder, so I have no experience, but my co-worker is :). He's produced an example of how to do this. Where should I send it? > > 16) Clicking on an event shows its details, but focus is almost > > instantly removed and placed on the latest event to arrive. This is > > very off-putting when you're trying to read what happened. If I > > explicitly select an event (by clicking or find) focus > should remain > > on that event until I select another event. I think this > just requires > > Find and click-select to turn off "scroll to bottom". I can then > > simply select "Scroll to bottom" to get back to the default mode. > > > > If you have Scroll to bottom turned on, you are indicating > that you want to follow new events. We should discuss a > clean way for a user to indicate a fast way of turning that > off, as I don't think simply selecting a row should > automatically turn ScrollToBottom off, that would be just, if > not more annoying (maybe some KEY + mouse click modifier) I disagree. If I click on something I'm explicitly indicating I want that item. If you went with my approach you could put a message in the status bar saying scroll to bottom has been turned off. The real issue right now is that it's selected by the click and then quickly auto deselected. By selecting it at all you teasing the user ;) I'd prefer to see "click means select and disable scroll", but if that's really disagreeable to user's in general I'd vote instead for disabling click-selection completely when scroll to bottom is on (perhaps with a warning bell, status message, or tool tip error if I do try clicking). > > Perhaps a "selected" event should be highlighted in blue as now, but > > in scroll-to-bottom mode the last event should be outlined in a dotted > > blue box to distinguish it from the selected state (c.f. Windows > > Explorer). > > > > Mmm, have to think about that one. > > > 18) Clicking on a logger in the tree should focus on it. Having to > > enable the "focus on" mode is an unnecessary additional step. > > > > Disagree, what if you accidently click? We can enable a > double-click default action though, that would make sense I think. I think you need to ask if the design approach is to make it easy for the user to access a feature they do want, or to make it hard for them to inadvertently access something they don't want. Typically I'd expect the answer to be dependent on the consequences of the action. You want to make it easy for them to do things of little consequence that are easy to reverse, but hard for them to do something destructive. I think this case falls into the former camp. If they click on a logger and it focuses on it, what's the harm done? They can easily turn the focus off again, or focus on something different. Provided the GUI makes it clear that focus has been enabled there's no harm or problem in a single click selection approach. As a comparison,, would you like to double click web browser links to avoid people accidentally clicking them? User's need to control their trigger finger ;) > > 20) I don't know what the information in the status bar is telling me. > > The message area, or the other number values? (Would tooltips help > there?) The numbers. Tool tips would be good. Also a short section in the doc would round it out. > > 27) I've had two NPEs: > > > > java.lang.NullPointerException > > at javax.swing.ImageIcon.<init>(ImageIcon.java:161) > > at javax.swing.ImageIcon.<init>(ImageIcon.java:147) > > at > > com.sun.java.swing.plaf.windows.WindowsFileChooserUI$ShortCutPanel.<in > > it > > >(WindowsFileChooserUI.java:603) > > at > > com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installComponents > > (W > > indowsFileChooserUI.java:361) > > at > > javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserUI.j > > ava:130) > > at > > com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installUI(WindowsFi > > leChooserUI.java:176) > > > <snip/> > > Bizzare, haven't seen that one. Happen very often? Only once. > Now my next question, interested in helping out any? :) You can > always start with a patch or 2 with the things that really bug you. > That's usually how things get done here by Scott and I, the > features/issues that we really need. That might not always > be inline with what other people wish for though. I think you mentioned that annoying paying job in one of your emails - I have one of those too, plus a boat load of outside interests and commitments. I've already said, I've not done Java GUI coding to date (my work is in distributed, backed server technology and web, plus native code required by our products), so I'd need to carefully pick areas to work on. I'm looking at how we can do some log4j work as part of our next product release (in planning now). If this works out we should be able to contribute something back that way :) Regards, Olli --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
