[Notes 1-2 all good stuff IMHO ]
> 3: Tabbed pane support - a tabbed pane for each unique
> machinename/app combination. I thought about allowing the
> user to pick which fields are used to build the unique tabbed
> panes, but I'm not sure how useful it would be. I could see
> using the NDC or MDC on separate tabbed panes in some situations.
What about a Multiple Doc Interface? Ideally from my point of view with the
current app we are working on would be to allow the server to broadcast all
log events as current, but have multiple windows all listening to the same
stream, but with different filters. Each of our modules in our app all have
Logger/Categories per module rather than 1 Logger/Category per class, so 1
window per interested module is the idea, but all coming from the same
stream.
For example, I would love to see thee current ChainSaw main panel (which
contains the Filter, Event Log List, and Detail panel) as a single Document
(JInternalFrame) so we can have more than 1 instance. Then also have the
ability to "snap"-hide the filter/detail window to watch just the Event log
list within the internal frame (Hotkeys would be cool here). Having
multiple doc windows would remove the need for us to have multiple
cygwin/ssh windows open to tail & grep a log file for each interested
module.
Together with this Multiple window would be to add the concept of a window
"Profile", which would contain the interested columns, in a particular
order, configured to size. Each internal frame could then be configured
with a chosen Profile. Perhaps each profile contains where the source of
the Log events come from (i.e listening on a Socket, or connecting to some
socket somewhere else, or some other Appender source).
Lastly to extend this concept even further is to copy the Opera browsers
Session concept, which is purely a saved set of open windows with their
chosen profile.
> 4: Jakarta RegExp used to build display and colorizing
> filters. The DisplayFilter associates columns with regular
> expressions. If the value in that column passes the regexp,
> then the row is added to the display. ColorFilters work the
> same way except they map columns and regular expressions to a
> Color. For example, colorFilter.addFilter("Level",
> "WARN|INFO", Color.RED) will do the obvious. If a
> DisplayFilter exists, the row must pass at least one filter
> to be displayed. If there are no display filters, all rows pass.
This is brilliant.
>> 6: Handy multi-line tooltip text - see Logger/Msg/Level/Exception
information as you move the mouse over the table's rows - no more scrolling
to the right to read the exception!
This would even replace or defer the need to view the detail message pane.
Another Brilliant concept. I also liked your idea of defining some sort of
Pattern to define what appears in the tooltip. This could fit into the
Profile concept above.
cheers,
_________________________
Paul Smith
Lawlex Compliance Solutions
phone: +61 3 9278 1511
email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
