Preferences - wait until JavaFX?

[oscargus]

I've spent some time replacing the deprecated DefaultFormBuilder with FormBuilder. The preferences may be next, but some questions related to that:

Would it make more sense to completely restructure the preferences interface? Smaller dialog? Tree-structured subjects? (I quickly tried to look for a generic class to provide a preference GUI, but no luck.)

If restructuring, should one go for a JavaFX solution (through that panel which I forgot the name of...)?

In general: Is there really any point in replacing DefaultFormBuilder if we are moving to JavaFX anyway?

[simonharrer]

The migration to JavaFX may take a while. Hence, I would propose to not stop working on the UI completely.

But I propose to work on logical (structural) changes instead of cosmetic ones at the moment, for instance, removing preferences (using the default values as constants instead) or re-grouping the preferences (more groups but they should describe more precisely which preferences they group). I do not

In JavaFX we should make the preferences a searchable tree. Hopefully, there is a framework for this available. I would not use JavaFX for now as I do not want to introduce the dependency to JavaFX right now - this could be a good solution but we first need to migration plan towards JavaFX to consider this.

Removing deprecation warnings is worth doing from my point of view, especially as they are an opportunity to improve the classes even further when reading the code.

[lenhard]

I fully support @simonharrer

There is definitely value in replacing DefaultFormBuilder

Related #203

[koppor]

Although I second removal of deprecated APIs, I'm not sure whether that's the right way in the case of DefaultFormBulider. The old code seems to be more readable and one can more easily add elements inbetween without changed all subsequent calls. See stackoverflow for a discussion on this.

Maybe, we should a @SuppressWarnings("deprecation") at DefaultFormBuilder?

[matthiasgeiger]

Yeah, using the FormBuilder instead of DefaultFormBuilder is quite timeconsuming with questionable code improvements. I would tend to agree with @koppor and leave the code as it is.

[lenhard]

Let's assume the designers of jgoodies deprecated DefaultFormBuilder for a reason. If we really depend on a functional version of that class, maybe we should revert our dependencies to a version where DefaultFormBuilder was still fully functional?

[oscargus]

From my perspective, the benefit of replacing DefaultFormBuilder is if a new (and better) version of JGoodies comes out where it is not just deprecated, but also removed. However, I have limited insight into the future of JGoodies. Apart from the easiness/laziness of the append/nextline design flow, the new approach is much more convenient if you want to have tight control of the UI. On the other hand, one may question if a FormBuilder is really needed for most of the preference tabs. Regarding the reason to deprecate it, I think that FormBuilder was part of the commercial version of JGoodies and when it was included in the free version it made little sense to maintain the simpler version.

[simonharrer]

Hmmm, when thinking about it I like the solution of just using an older JGoodies version more and more as we can focus on more important things and not have deprecation warnings.

[koppor]

👍 for downgrading. Reason: When switching to JavaFX (see #113), JGoodies will be obsolete. I would propose to close this issue (and downgrade JGoodies)