[Uncleunc-developers] release 0.24.2

[<da...@cr...>]

Hi all,

A new release of Uncle Unc is up on the site in source code form. New features are listed in the changelog, but, in brief:
- methods invoked from the GUI now run in their own thread, easing the burden on the AWT event thread and allowing larger, more complex activity to be invoked. This arose from trying to run a simulation model with 6000-odd variables through the Unc harness, and watching it freeze up badly when it tried to open a new view and wrap each variable in an unc item. 
- better interaction between filters and pagers, which now behave almost intuitively in the sirius gui, apart from the fact that the gui list will sort items independently of the order in which the underlying View object stores them. 
- added log view filters for apache logs, and tested out on some fairly big ones (and one very huge one at 16M, which it couldn't handle. My fault for running up a 16M log file in the first place, rather than using a database to log it!)
- a few beginning scratches at parcelling up bits of the gui as javabeans, allowing unc components to be embedded in other applications.

So, there's been a fair bit of work going on under the hood during the last month or so, and I foresee a couple more big changes to do before I consider moving unc out of alpha and declaring it useful.
- currently, bespoke views such as jini, databases, log files etc. are implemented as subclasses of View. It struck me as more sensible in many ways to have only one View, and implement the bespoke types as objects that manipulate the View, automatically populating it, creating subviews etc. etc.
- the dog gui toolkit uses a 'DItem' object as a placeholder for lists etc. I wrap my Item objects in DItems, and there may be performance gains in flattening this out and rewiring dog to use Items directly.

These will both entail pulling everything apart so that it stops working, then putting it together again. There's a danger that I keep chasing my tail if I do that.

Now that I'm looking at beans too, my plan is to release roughly once a month, and to alternate between producing a useful bean from the current functionality, and doing some of the heavy rewiring work. So I'm aiming at having a drop-in bean for reading log files by end of November, then pick some grunt work for December.

Regarding beans, I can see that there's an advantage here to having a Swing-based version of the controls. Dog interacts with swing OK, but won't respond to PLAF, for example. As a quick straw poll, would anyone here be influenced in whether to use a javabean by whether it is swing or not?

(I'm not planning on ditching dog, but on possibly supporting two sets of GUI components, following the same design patterns. A lot of the architeture of sirius can translate fairly straight to a swing version. Dog is too useful not to have: smaller, faster, stands a good chance of running under personaljava, has the list component ready-rolled, etc. etc.).

While I'm on this line, anyone had any good or bad experience of eclipse as a gui framework?

Regards,

Dave Crane