The Plan
My goal is to create a more customizable GUI for every tab and dialog in MPT. Here are some features i'll be looking to incorporate.
>> All strings loaded from an external .txt, which can have translations from various languages. These strings are kept in an array for page refreshing.
>> Complete substitution of controls and fonts. See below for details. Color schemes can still be used but become part of the "skin" package, which does not have to use new graphics.
>> A standard package structure that will make "skins" shareable, with a verification process by MPT itself.
>> Idle-time page refresh, or element refresh (for those elements changed by FX commands). If this can be easily coded in MPT's structure, GUI elements can be animated. At the very least, windows in Multiview are changed when values to controls are altered, even during playback.
THIS IS ALL HIGHLY SPECULATIVE!! I know very little about C++, and what i do know is only from a BASIC perspective (i was big into programming -- in BASIC -- back in the 80s). Object-oriented programming is as foreign to me as Chinese, and it looks like C++ is very broad and therefore a little more complex than just "function-variable-operator" that i had grown up with. I'm a composer FIRST, and programmer ... well, not even 2nd thru 10th. But i'll give it a shot if i can get done what i wish to do without devoting hours upon hours to learning the language. As a matter of fact, my ONLY reason for learning C++ is to make composition with MPT more intuitive and efficient. Let's just say i will be the young apprentice lad to the elder wizards Jojo and Relabsoluness! Full of questions and impudent too!
New GUI Details
After looking at the code (but with very superficial comprehension admittedly), it may be possible to call an alternate set of controls that MPT will apply. However, as expected, the program still expects certain controls to be of a certain type and to contain certain values for certain variables. Here is how i propose to handle a customized GUI:
1. GUI elements are to be divided into 3 types (at least initially): statics, toggles, and textboxes. This can simplify the usability of MPT by requiring very little different types of input from the user.
A. Statics are planted within the window/page at given locations, but they neither receive input nor change their appearance (except for screen refresh or changing windows/pages). These include static textboxes and background graphics.
B. Toggles are controls that are either set or unset (on or off, TRUE or FALSE). These are necessary for all simple settings, such as Loop Song, Record Enable, or Show Amplify dialog. These will replace checkboxes, radio buttons ("solo'd" checkbox), and regular buttons (used for showing dialogs, executing functions, or applying/ignoring options). Toggles are standard Windows controls (only invisible) that use a graphic overlay for each setting.
C. Textboxes are controls that allow for text to be entered or chosen, but use a graphic overlay in which to show where text is entered. They can have their own font and coloring, and input handling. When clicking on them, they become open to text-editing services. When clicking-and-dragging (up and down), if the text values are part of a list, the list is scrolled up or down to the previous or next entry. This element replaces the editable textbox, listbox, and popup menus, but may require its own handling code.
If properly done, all GUI elements on a page will be able to be customized graphically (but perhaps not functionally). That is, you may apply your own image to the control, but you can't change HOW to control it (unless you code for the control). If all goes as planned, user controls will be functionally confined but graphically customizable -- no more sliders, arrow controls, popup menus, or "combo" boxes.
You may wonder why i would want to get rid of so many GUI types, such as menus and "spin" arrows. My reasoning is this: by reducing to a few types of elements, "average" users (those who don't know programming) can more easily customize their copy of OpenMPT. Also the code can be made more efficient at least in syntax, and perhaps in processing. However, future expansion will allow for more controls of different types, and with a standardized suite of controls, future programmers will be able to code new controls more easily.
With all this, all parts of the code (that deals with user input) will need to be visited so that the new elements can be introduced, and since it will be done piecemeal, it will NOT be part of the official builds until COMPLETELY ready for testing. IOW, i don't want the official build to be altered unless all parts of the new GUI are ready, not just, say, the General tab, or a few of the dialog boxes.
2. GUI elements are kept in external files which can be loaded and applied (hopefully without having to restart). A folder or some type of archive can contain all the images that will be used, the language file for the given text, and the .ini or .cfg file which shows, for example, where the control is found on its page, the font it uses, and the image it applies. This externalization will make it easy to share GUI "skins." (However, fonts may need to be included in the shared archive to be transferred to the System folder.)
3. When loading a skin, MPT will check for basically two things: that all required elements that the program will access are indeed within the external package, and that if certain elements/controls are "hidden" (located outside of the page's dimensions). If the first test shows that not all elements are accounted for, MPT uses its default (what we see now) and alerts the user as to what's missing in the skin. If the latter test shows certain elements "hidden", the user is warned (this warning can be optioned off).
With all this, the changes may be too radical for the average or classic user of MPT; i may have to branch off to "ModPlug the Harbinger Build" or something like that. While my goal is give users more choices in the interface, the code may be too "tight" to accomodate major changes. I know these are grandiose dreams, but i consider this something of an art project -- just more intellectual in its medium.
You are free to critique my philosophy and approach, but try not to dissuade me from this venture. Try to be constructive and helpful in your remarks ("You can do x, but you'll hafta do y; consider trying z..."). Remember i do have both a logician's mentality (good for math and programming), but i'm primarily an artist, always creating...
Now to get started before i lose interest!...
