Allow Bind Directories dialog to associate existing profile or create a new one

[xizar]

Initial caveat: This is pie-in-the-sky kind of thing.

I do not know if this is the only SoD/Citybinder out there anymore, but it would be cool if people transitioning over from other bind managers could kind of drop BC directly as a replacement with minimal friction.

It should be possible to parse the billions of text files in a bind directory to figure out what the profile that generated it would look like. Not so much the character name or alignment, but travel powers, Mastermind stuff, custom binds, etc.

I'm going to suspect that the answer to the question "should it do this" is "no".

I'll note that the addition of the "bind directory" menu selection recently added in .21 will help with migrating, and unless someone has 1000 characters per server, they shouldn't have too hard a time making the new profiles.

[emersonrp]

I'm confident it would be incredibly difficult to backport a Profile from a binds directory; at best it would be functionally impossible for -me- to code that. Trying to decide the state of each checkbox in the Movement Powers panel in particular from clues hidden among the zillions of files sounds... excruciating. And generating custom bind configurations / objects / panels from what end up being fairly free-form bind strings generated by a different application... I'm not sure there's adequate information to reconstruct how we got there. I'm not sure there's NOT enough information, mind you, but I'm not sure it's at all worth the trouble.

What I have considered in the past is trying to parse and load old CityBinder profiles, which would be a bit tedious but possible. As BindControl continues to diverge from CityBinder, the applicability of a CB profile/save file also becomes less and less, but I suspect there's enough overlap there, still, to make this worth examining. "Import CityBinder Profile..." might well be possible, with some UI to fill in the blanks. Hmm.

[xizar]

I've had a different thought for what might be done that should probably be more doable than reverse engineering from the files.

How about letting the software use the already present "Bind Directories" page to associate existing directories with .BCP files?

Currently you can click on "managing profiles" that are maanged, but the "-unmanaged-" ones sit there... waiting... watching... judging.

What if clicking on that would open the option to associate it with a BCP or create a BCP file based on the directory name?

[emersonrp]

I like this line of thinking. I'll tinker with it at some point soon (family stuff happening, hence me being a bit more quiet than usual). Making a new profile based on the directory name seems like an easy win.

[emersonrp]

A few notes here, as I'm tinkering with this. There are some UI/UX gotchas doing either of these things.

In either case, new profile, or assign an existing one, we need to load the profile in order to set its ProfileBindsDir attribute. And loading a profile is a non-trivial undertaking. It miiiight be possible to instantiate a profile without gluing it into the UI, but I've never actually tried that and it is probably fraught with peril. Issue #86, now fixed, was one example of how BindControl had made, and probably still does make, assumptions that there's one Profile going on globally for the app.

So anyway, we'll probably have to load the Profile being created / assigned, meaning unloading the current one, triggering "do you want to save" if it's modified, and sanely handling Cancel etc etc.

Edit to add: actually we do instantiate profiles without gluing them into the ui every time we New Profile or Load, but we then immediately glue them in. Still, they get created in memory and are usable, and so forth, before the gluing step, so it might be possible to instantiate one, twiddle its ProfileBindsDir, save it, and then Destroy() it without affecting the existing UI.

[emersonrp]

Current "gotcha" is that saving a Profile then re-loads it as the current one just to make sure we're all set up correctly. This probably doesn't need to happen but I need to make 100% sure of that before I go ripping that out of there. If that can be fixed, then I think we're able to do this by instantiating Profile.Profile(), twiddling its innards, and then saving it and destroying the object. I think.