Re: [Jsynthlib-devel] Switch to JTree for the device list?

[Rib R. <ri...@gm...>]

That sounds like a great idea.  Much better than the hack I put in for
the XML driver (since all XML drivers are instaces of the same class).


On Mon, 28 Feb 2005 14:51:46 -0800, Joe Emenaker <jo...@em...> wrote:
> Now that (I *think*) my JTree changes were reverted, I'll mention some
> of the other changes I thought of when I was implementing it.
> 
> ------------
> Cleaning up DeviceListWriter and DevicesConfig
> 
> Right now, DeviceListWriter *writes* the synthdrivers.properties file
> while DevicesConfig *reads* it. This isn't very good encapsulation. One
> class should handle all management of the file. This should be either
> DevicesConfig or a new class. DeviceListWriter is only needed for it's
> static main() class so that users can force a scan of the synthdriver
> directories to generate a new synthdriver.properties file, so that's all
> it should really do: scan directories and then request that
> DevicesConfig save the new settings to a file.
> 
> ------------
> Further cleaning of DevicesConfig
> 
> DevicesConfig currently tracks the classname, drivername, IDstring, etc.
> all in separate hashtables mapping each string to the classname. So, to
> find the IDstring by drivername (like "AccessVirus"), it has to go to
> the drivername hashtable, look up the classname for that driver. Then,
> go to the IDstring hashtable and find the key that points to that class
> in *that* hashtable.
> 
> This has two problems. First, it's a little disorganized and
> inefficient. Secondly (and more importantly) is that this will lead to
> problems if we ever have a single class that drives multiple devices
> (like a V-Amp, a Bass V-Amp, and a V-Amp 2). In a case like that,
> multiple keys in the IDstring/drivername hashtables would have the same
> class... and trying to look up a key based upon a value in the hashtable
> will yield unpredictable results.
> 
> The remedy I propose is to make a class called something like
> "DeviceDescriptor" which would house all of the important info about a
> device (name, classname, manufacturer, type, IDstring, etc.) and then
> have DevicesConfig maintain an array or vector of these descriptor objects.
> 
> Provided that I *wait* until the 0.2 release is branched/tagged before
> doing this, does anybody have any other objections to this?
> 
> - Joe
> 
> 
>