My GUI Goals

[Harbinger]

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!...

[jmkz]

Support ++ !!  Well, is there a way to implement, at least, the ability of change color to the window OpenMPT as in CoolEdit / Audition? I don't kwow if it's easy but it's another step for the GUI.

And, I have another question about the translations into other languages:

(Taken from MPT 1.16 MPTRACK.HLP)

International Versions

Modplug Tracker is written with a default page code of 0409 (English - US)
You can freely edit the resources to make a localized version of Modplug Tracker, although some strings are hardcoded in the code (not as resources).
I am trying to improve the support for easier localization, but it is a lot of work.
However, starting from v1.15.0154, MPT supports localized strings in the file MPT_INTL.INI
This file contains string sections for a specific language id. For example, in Australia, MPT will look for strings in the [Strings.0C09] (0C09=Australian English language id). If it isn't found, then it will look in the [Strings.0009] section (generic english), if not found, it will look in the [Strings] section (no language id), and if still not found, it will use the default value for the string.
For example, to set the option names in the setup general tab, the strings would be
Setup.Gen.Opt1.Name=Play new notes while recording
Setup.Gen.Opt1.Desc=When this option is enabled, notes entered in the pattern editor will always be played (If not checked, notes won't be played in record mode).
Feel free to email me if you have specific questions about this.

Does this actually works in OpenMPT 1.17 ~ 1.18 ?

[residentgrey]

What on linux is closest to OMPT as it stands?

[Rakib]

The MPT's GUI is written with MFC, JoJo was mentioning that there is plan to change it to QT for linux compability, but it's lots of work and something that is not very high on the to-do list. MFC is now very, meaning MS won't update it anymore and they have mote to another GUI-engine called WPF. I've seen buzz has getting a lot of new GUI improvements using WPF but it's only available for windows and but skinning and doing GUI is very much simpler than with MFC, people are making skins very easily using xaml for buzz now.

But for the main points of this discussion, I don't want a slick GUI like FL/reason or other DAW. MPT is clean and easy to use because of it's simple GUI and recognizable icons and stuff. But as it's own branch it might be possible but please consider the facts that is will need a lot of work. Specially separating everything.

Also don't forget that you can do color skinning on mpt today, you can even load and save presets. If you have one that you like very much, please don't hesitate to make it available for other.

And though I don't see the need for different language settings, I would make one for norwegian if it ever will be a option to do so. And if recall correctly, I think there was at one time a japanese version of modplug tracker.

[Sam_Zen]

I don't want a slick GUI like FL/reason or other DAW. MPT is clean and easy to use because of it's simple GUI and recognizable icons and stuff.

I agree on that.

[Saga Musix]

mpt_intl.ini should still work. I dunno which string it can exactly substitute, though.

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.

as people say: "good luck have fun" :lol:
if it was all that easy, it would already have been done.
Before starting to do big hacks with the MFC code, I'd rather change to Qt first. The MFC code cannot be kept as it is anyway, since it is so wrong that controls are simply disappearing on Vista and Seven, it's even worse in Seven than it's in Vista. Good that I know where everything is placed...

Let me also say that much the "skinning" effort might be completely useless then, because GTK for example comes with its own skinning system of course (just install f.e. X-Chat on Windows and you will get the GTK skin selector), and I think Qt also offers such a feature.

I think there was at one time a japanese version of modplug tracker.

People have been translating MPT to Czech and French I think - mostly by exchanging resource texts and also some strings in the code. I don't really know if that's an important goal to keep in mind, because as Relabs has already said years ago: Do you even come up with a satisfactory word for "pattern" in your own language?

[Relabsoluness]

(moved the thread to Development corner)

This surely is a grand plan -- almost makes replacing MFC with QT look like child's play.

About translations:

I reckon that currently the majority of strings are hard coded and  scattered in the source code making translation difficult and, more importantly, effectively prevents including translations in the official OpenMPT releases. But I think it would be nice if this was improved.

What comes to mpt_intl.ini, it can be used to translate only some strings in the options dialog.

Do you even come up with a satisfactory word for "pattern" in your own language?

It could be considered as a challenge rather than as an obstacle.

[Harbinger]

Thanks for the support and reminders. Yes, i know it'll be a lot of work, especially since i'm trying to learn C++ just for this app. But i do have the time and (for now) the interest.

To those, who do like the current GUI, so do i. It IS simple, and uncluttered, unlike Renoise and some other trackers i've seen. When i'm done, the GUI will actually be less "noisy" because the controls will be simplified. Plus, if i don't have to do a separate build that has to be maintained, "customizable GUI" will be an option, either as a preference in General options or as a command line affix.

My first goal is to copy all the control bounding box coordinates to an outside file that MPT can draw from. If the customization option is  enabled and ALL the controls are present in the list, MPT uses those coordinates, and draws everything where it's supposed to be (if not, the original controls are used). If this can be done, then a future "skin" can place those controls anywhere.

Then i will have to write a method that creates a "mouse slider" that i described above. I'll do a separate post on that.

We're still many months away from such a realization, but i'll keep you abreast of how i'm coming along with this...

[Harbinger]

Here are my plans for the mouse slider control, assuming one doesn't exist. I've seen it in other applications so a method may already be out there...

The mouse slider is activated by clicking in another control, in our case, an editable textbox, but the input focus only occurs if the mouse button is released while the mouse is in the textbox boundaries. When the mouseclick is held and dragged over the screen, the textbox is denied input focus, and the value in the textbox is changed up or down, either by strings in a list, or by numeric value. (A perfected version will allow the user a global option to use an up-or-down drag (+/-y) or horizontal drag (+/-x) when using  mouse sliders.) When holding the SHIFT key when dragging, the increase/decrease is much finer. The non-SHIFT range matches the screen size and accounts for the user's mouse speed settings with Windows.

When the mousebutton is released, the current value is assigned to the textbox and its variable. If the control key is down at the release of the mousebutton, the operation is canceled, and the variable is returned back to its original value. If some other change in the display happens (like switching pages or using another keypress), this also cancels the operation.

If the text is neither numeric nor list-based, there is no effect.

[Saga Musix]

that sounds a bit like something i had in mind before, so nothing new. you get similar controls in programs like photo impact, and AFAIK they are easy to do with Qt - so in any way, don't even try to understand MFC if you want to do something like this - it is most likely not worth the effort.

[Harbinger]

BTW what is "Qt"? Is it the next step up from MFC? Is MFC obsolete?

[Saga Musix]

Well, it's a bit like comparing apples and oranges but anyway... MFC is a proprietary GUI framework developed by Microsoft, to help developers with creating Windows applications easily in C++. Qt, on the other hand, is a cross-platform, free (as in free software) toolkit developed by Nokia, offering platform-independent Window creation, OpenGL support, and other great things. ModPlug's MFC code is wrong in many places, meaning that it does not work properly (most notably under Vista/Seven).
MFC is obsolete in many ways, most notably that it's only available for Windows. Qt is not a follow-up to MFC, since it was created by completely different people with a completely different goal.

[Rakib]

MFC is obsolete, meaning MS is currently is not developing it anymore. MS have moved on with WPF.WPF is also much easier than MFC to work with, where you have a xml-based language to work with. The downside with this is it only works with windows.

[jmkz]

That's right. For me it is an honor to continue using OpenMPT because it's free, and even with bugs, I will continue using it for its simple interface. With respect to MFC I think it's outdated, but works well in Windows than Qt, as I have tested Qt applications designed for Windows. Maybe I isn't correct but it's my feel under Windows but not for Linux like ubuntu (I like for OpenMPT in ubuntu, that's will happen one day) , where Qt works incredible IMHO.

[Relabsoluness]

MFC is obsolete, meaning MS is currently is not developing it anymore.

Is there an official announcement about this you can refer to?