Qt应用程序“内部”应用程序

Question

Qt 4.8.2, windows 7 x64 (But I should be thinking about this as a generic implementation, not OS dependant -if possible-)

This is a conceptual question and also about implementation.

I have a (Very) simple QApplication. It reads an XML with "button" tags, for each "button", add a new QPushButton to the layout. This allows me to dynamically generate a gui based on a config file (The XML). My issue is taking it to the "next level".

I want to start associating those buttons with other modules (for example: QDialog), which would then do whatever it is they have to do.

My final objective is to have an application that "reads a configuration file" (xml) and based on its info, it generates as many buttons as modules were read. After that, "connect" the buttons "launch commands" (I don't have a better wording for it right now) which would run as a normal module would... until you close it, then you would return to the menu.

I basically want to have a menu that is dynamically generated (by reading the XML file) and then connects those buttons to execute/start my modules. I also want it to be flexible, so if tomorrow I add a new module to my XML and the module into the app folder, I want it to be able to launch it.

My questions are:

1. Was I clear enough?

2. How do games normally go about executing processes? For example; A "Menu" from a videogame (in most AAAs) is usually made in Action Script or something similar, and then, when you select "new game" or "load game", etc, it executes certain other Modules (for lack of a better word), particularly the transition between the New Game button and loading the DirectX application and stuff.

3. How would one go about developing such projects? Should I make multiple projects inside a common solution?

As you can see, I don't have that much knowledge about software design, so if you think my questions are too basic and you have some book you'd suggest I am willing to read on the subject, I do admit I am more than a bit lost and any sort of advice is welcome.

As always, if I am not clear enough or I can expand on something, do let me know. I appreciate any and all kinds of help on this topic.

Also: if anybody thinks I should change the current tags, tell me so. I figured those were the most appropiate.

Answer 1

You probably don't need to visualize this as an "application within an application". When you break it down, what it really is, is an application that can launch processes, and is configured via xml files.

After that, "connect" the buttons to DLLs? other .exe files? which would run as a normal application.

I am not sure what you mean specifically, when you say connecting to DLLs... But all this really needs to do is launch a subprocess from your app. If I click button A, then it can launch Application A in a QProcess . Your app is the parent process and knows when it will stop running.

If what you mean when you refer to DLLs is that you want to develop other widgets compiled separately, and be able to dynamically load them in from a button click, then I would think it is still not another application. You only have one QApplication running at a time. If you import new modules containing widgets, they can be shown running under the same existing event loop.

Answer 2

How do games normally go about executing processes? For example; A "Menu" from a videogame (in most AAAs) is usually made in Action Script or something similar, and then, when you select "new game" or "load game", etc, it executes certain other Modules (for lack of a better word), particularly the transition between the New Game button and loading the DirectX application and stuff.

This is incorrect.

"most AAAs" are a single application. Whether they use Action Script or any particular scripting language to build their GUI is irrelevant. The game is usually a single application; you're always in the game. It always has DirectX or OpenGL or whatever running, whether you're in gameplay or sitting at a menu screen. When you start a game, all that happens is that the game runs a series of functions within the application.

They are not necessarily arranged in "modules" or some other construct that the outside world can access or even knows about. They do not usually "load" other code; it's simply calling other functions in an application.

At it's core, it's no different than a command-line application that waits for the user to type some input, then does something with that input.

"most AAA" games cannot do what you're asking. You can't just add something to an XML file and have them load another game within the current one. They aren't built that way, and that's not their purpose.

If you want to have a flexible menu application that launches other games, then each game must be a separate application, and the menu app should be separate from all of them. At which point, launching a game is just launching a process. This is how Steam and similar tools work.