I wouldn't mind trying out the docked version of MASON--maybe you could post
your code somewhere and let us give it a try. As for my opinion on these
things, I'm not necessarily sold on either side. For smaller simulations
(i.e., those simulations with only a couple of displays) I prefer the
non-docked application, however, for larger simulations with several displays
and lots of graphs, I think a docked interface makes them more manageable and
brings a bit of order to the chaos. Especially on laptops where screen real
estate is a valuable commodity, I believe the docked interface could be of
value. As of right now I have just a simple simulation I am running with a
single display and when I open up a graph on the simulation on my PowerBook, I
already start overlapping my screens. Now as for the added library file, I do
agree that it is a bit of a burden to have one more thing to download, but
nothing that would be too much of a pain to keep me from using MASON. The main
thing that I would try to avoid is adding too much on to MASON that does not
have to do with the core functionality. One of the reasons I went with MASON
in the first place is its clean and efficient API, and I would hate to see that
sullied by the addition of a bunch of bells and whistles that have nothing to do
with creating a fast, effective simulation.
Just my two cents.
Keep up the good work.
Quoting Sean Luke <[log in to unmask]>:
> I attended WCSS this year, did a little tutorial, and talked for a
> while with MASON's competition :-). As many of you may know, RePast
> 3 is out in alpha now, and it sports: a new "docking interface" (a-la
> Eclipse or NetBeans' interfaces); a rewritten model core, which has a
> sort of separability from the main GUI plus a form of model-freeze-
> drying; very heavy use of Java 1.5 Annotations; hooks to R and a few
> other items; Java3D
> It's a nice upgrade from Repast, though I think all the new gizmos
> very significantly complicate the system, and this may cause some
> rancor among the faithful. Time will tell. Given MASON's original
> reason for creation, I was particularly interested in RePast's new
> model separability and Java3D. I can't tell yet about the model
> separability: it appears they're not using serialization at all, but
> have their objects scribble data out to a file manually. Anyone have
> further information?
> Also at WCSS was the demo of GrowLAB, ETH's major fork from RePast to
> expand GeoSim-like models with 3D and other stuff. It too has a
> docking interface and Java3D. One very interesting feature of
> GrowLAB is its "step back" button -- to move backward in time. I
> fooled around with this for a bit in MASON and have an interesting
> way to do it but it is memory hungry. So I dunno.
> Anyway, after talking with the lead coders for both of these
> projects, the subject of their docking interfaces came up. They're
> proud of them, but I'm not the biggest fan of docking interfaces -- I
> think they're complicated and too much of an interface burden --
> though they do handle large numbers of documents reasonably well.
> Anyway, after I argued that docking interfaces weren't that tough to
> throw together, they joked was that I'd show up next conference with
> a docking interface, and my annoyed response was: no, I'll show up
> _tomorrow_ with a docking interface. Which I did. :-) Took all of
> about three hours in the hotel room, and requires about 5 lines of
> code changed in a MASON model.
> That was fun. Chest-beating aside, the quick-and-dirty docker splits
> the console into three regions, one for the main console, one for
> displays, and one for "trackers" (PropertyInspectors like charts,
> streamers, etc.). They've all got splitviews and you can detatch any
> of them into separate windows and reattach them to the main window.
> But to do this right would require that the docked elements can be
> moved relative to one another or joined together into a JTabbedPane.
> For this, an open source toolkit like FlexDock would be the right way
> to go probably -- I imagine that's what RePast is using -- but I'm
> worried that it would place very significant constraints on how GUIs
> in MASON are made. It would also require FlexDock to be included
> with MASON. Opinions? Preferences?
> GROWLab http://www.icr.ethz.ch/research/growlab
> New RePast http://repast.sourceforge.net/
> FlexDock https://flexdock.dev.java.net/
> Last, below is the 3-hour docking interface, showing one detatched
> window. And 3D HeatBugs with both 2D and 3D displays, just for fun.
> And the new histograms.