-/*
-The profiles need the following:
-
- - The name of the controller
- - A unique human readable ID
- - The key definitions for that controller (keyboard keys can be mixed in)
-
-So there can be more than one profile for each unique controller; the
-relationship is many-to-one. So basically, how it works it like this: SDL
-reports all connected controllers. If there are none connected, the default
-controller is the keyboard (which can have multiple profiles). The UI only
-presents those profiles which are usuable with the controllers that are plugged
-in, all else is ignored. The user can pick the profile for the controller and
-configure the keys for it; the UI automagically saves everything.
-
-How to handle the case of identical controllers being plugged in? How does the
-UI know which is which? Each controller will have a mapping to a default
-Jaguar controller (#1 or #2). Still doesn't prevent confusion though. Actually,
-it can: The profile can have a field that maps it to a preferred Jaguar
-controller, which can also be both (#1 AND #2--in this case we can set it to
-zero which means no preference). If the UI detects two of the same controller
-and each can be mapped to the same profile, it assigns them in order since it
-doesn't matter, the profiles are identical.
-
-The default profile is always available and is the keyboard (hey, we're PC
-centric here). The default profile is usually #0.
-
-Can there be more than one keyboard profile? Why not? You will need separate
-ones for controller #1 and controller #2.
-
-A profile might look like this:
-
-Field 1: Nostomo N45 Analog
-Field 2: Dad's #1
-Field 3: Jaguar controller #1
-Field 4: The button/stick mapping
-
-Profile # would be implicit in the order that they are stored in the internal
-data structure.
-
-When a new controller is plugged in with no profiles attached, it defaults to
-a set keyboard layout which the user can change. So every new controller will
-always have at least one profile.
-
-Data structures:
-The Gamepad class has the name of the controller (except for Keyboard)
-The profile list is just a list
-The controller name index + profile index makes a unique key
-Probably the best way to deal with it is to stuff the name/profile indices
-into the key definition structure.
-
-#define CONTROLLER1 0x01
-#define CONTROLLER2 0x02
-
-struct Profile
-{
- int device; // Host device number
- char mapName[32]; // Human readable map name
- int preferredController; // CONTROLLER1 and/or CONTROLLER2
- int map[21]; // Keys/buttons/axes
-};
-
-NOTE that device is an int, and the list is maintained elsewhere. It is
-*not* the same as what you see in GetJoystickName(); the device names have
-to be able to persist even when not available.
-
-Where to store the master profile list? It has to be accessible to this class.
-vjs.profile[x] would be good, but it's not really a concern for the Jaguar core.
-So it shouldn't go there. There should be a separate global setting place for
-GUI stuff...
-*/
+ if (retVal == QMessageBox::No)
+ return;
+
+ int index = mapNameList->currentIndex();
+ int profileToRemove = profileNum;
+ mapNameList->removeItem(index);
+ DeleteProfile(profileToRemove);
+ // We need to reload the profile that we move to after deleting the current
+ // one...
+ ChangeMapName(mapNameList->currentIndex());
+ // If we get down to one profile left for the device, we need to make sure
+ // that the user can't delete it!
+ deleteMapName->setDisabled(mapNameList->count() == 1 ? true : false);
+}