[Pogamut-list] Standalone visualizer

[mpkorstanje]

Re: Standalone visualizer

Author: mpkorstanje

> If so, would it be possible to share the code? Or at least create a webpage where one can download the code from you svn so we can link it from our webpage?
> 
> Cheers!
> Jimmy

Hey,

I've removed all the hacks and most dependencies so it's presentable now. Unfortunatly the SVN I'm working on is not publiclly accesible. So I've taken the Liberty to setup a web page for it.

http://195.64.67.86/projects/

I'll try to put a new version up when one is made. Though since I have this working now and will have to move on to other things I don't think there will be many.

> Not really. It wasn't designed to be used by other apps, but visualizer needs some refactoring (at least to decouple it from PogamutNbUT2004 module), so If you specify what you need, I will try to incorporate the changes.
> 
> Honza

Now I can finally awnser this question too. 

There is a whole set of classes associated with the PureMap visualisation (a full list is contained in the download), these are probebly better of in their own project. Though the PureMapTopLevelComponent and other subclasses of NetBeans components shouldn't be in that project. 

The Interface IRenderableUTAgent has a method List getMapEvents() which  couples it tightly to allot of timeline related classes. However ProxyRenderableAgent just returns an empty list here. So it would be good to split the Interface so ProxyRenderableAgent is not related to DataSources. 

The SelectableMapGLPanel uses a service lookup to handle the selection of agents. Currently is does by looking for a PogamutEnvironment interface. But the interface itself is rather small. So I reckon a more specific interface, a SelectionService would be better. I'd allow me to insert my own service here. Though I haven't had time to work on those parts yet.

In the MapRenderer NbPreferences are used for colours and a selection of items to be rendered. Replacing this with a service lookup would also make it more generic.

All together this would leave a single depency on openide-util.jar.

-- 
Reply Link: <http://diana.ms.mff.cuni.cz/main/tiki-view_forum_thread.php?forumId=2&comments_reply_threadId=2&comments_parentId=356&post_reply=1#form>