Re: [Jsynthlib-devel] Modifications to the AppConfig class and preferences GUI

[Chris W. <chr...@ch...>]

Joe Emenaker said on 06/12/11 16:17:
> On 12/5/2011 12:36 PM, Chris Wareham wrote:
>> It looks like there was an intention at some
>> point to make the preferences panels embeddable in other dialogs, but
>> this doesn't seem to have come to pass, and the result is a lot of dead
>> code paths.
>
> That was possibly my doing. I think the point was that there would
> sometimes be the desire to take the user directly to the settings for
> something if they needed fixing immediately (for example, if none of the
> available MIDI interfaces were selected, we could pop up the MIDI config
> page).
>
> I recall the code for the individual panels being modular (ie, an "init"
> method and maybe a "show" method or whatnot), but I'm not sure what dead
> code paths you're speaking of...
>
> - Joe
>

Hi Joe!

I'm taking a "top down" journey through the code, and one of the first 
things I hit was in the PrefsDialog class where there's different code 
paths depending on whether zero, one or many preferences panels would be 
available. In my working copy I've removed that chunk of code and all 
the preference panels are added to a tabbed pane (the "many panels" code 
path in the original).

I've been tinkering with more of the other code this evening, and was 
wondering about some of the XML related device stuff. It appears to be 
incomplete, and spread across both the core package and sub-packages of 
the org.jsynthlib package. If I'm reading it right, it seems to be much 
more complicated than the properties based approach that the rest of the 
code uses.

There are also a number of classes in the core package that are unused:

core/Storable.java
core/Storage.java
core/SysexMatcher.java
core/VertScrollBarLookupWidget.java

Adding generics to a few places also highlighted an issue with the 
SceneListModel in the SceneFrame class. It extends PatchTableModel from 
the AbstractLibraryFrame, but is actually a table model for scene 
objects rather than patch ones. I have worked around this, but I'd be 
keen to restructure this code a little better.

Regards,

Chris