[MPlayer-dev-eng] The future of a GUI

[Ingo Brückl]

After the flop with the stream/stream_vcd.c header I hardly dare to write
this, but I'd like to get some feedback on the topic and like to know what
will be permitted to reach the goal concerning the future of a GUI.

Concerning stream_vcd I've learned that there is another way to do it. Ok.
Thanks to Reimar for the patch, I'll test it. But nevertheless a fundamental
question remains.

Is it absolutely taboo to make changes that might be counterproductive but
may help at the moment, although they have to be reverted in future?

The goal is, to state this again, to first clean up the current code and by
doing this to understand how everything works. In this way, it is possible to
fix various bugs besides. After that, the slave mode should be enhanced to
enable the GUI to do its work only as a "master" with slave commands, which
means that the GUI can be separated and all its CONFIG_GUI code can be
removed. The GUI will then automatically be the first one to take full
advantage of the new slave mode. The whole thing is long-term, of course.

To give an example on a counterproductive patch and to return to the topic
of what I didn't dare to ask so far, r31377 patch for example should be
reverted. This patch removed the call to a guiMessageBox() from within
mp_msg(). Clearly, a GUI must be informed about messages issued (and decide
then itself what to do with them).

Although this reversion is ugly and unwanted, it helps, because it simplifies
the question what a future slave mode should accomplish. The answer is
simple. Go through all the CONFIG_GUIs and either remove them without
substitution or by making what is done there a slave response to the master.

This obviously can't be done easily if currently necessary connections
between mplayer and GUI and thus CONFIG_GUI code parts don't exist. In case
of r31377 I could write something strictly within gui/ that filters the GUI
messages passed to mp_msg() and give a message box when needed, but this
would be nonsense, and it still wouldn't enable a GUI to put out fatal
messages coming from mplayer itself.

To make a long story short, what is the view to the taboo question above,
and r31377 as a perfect example for this in particular?

Ingo