jsynthlib-devel

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

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

Hi folks!

I've got changes in my working copy that clean up the AppConfig class 
and the preferences dialog. 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.

Can I go ahead and commit these changes? They result in an AppConfig 
class that is almost entirely devoid of presentation logic (two methods 
to relocate to a more appropriate place when I get to that class) and a 
simplified abstract base class for the preference panel stuff.

Regards,

Chris

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

[Joe E. <jo...@em...>]

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

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