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

[Clément Bœsch]

On Sat, Mar 12, 2011 at 09:38:46PM +0100, Ingo Brückl wrote:
> 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?
> 

You know, there is no urge on making the GUI working fine. GUI has been
dropped from default and we repeated to users not to use it and look for
solutions like gnome-mplayer or smplayer. If users see massive commits on
the GUI, they will think it's going to be better, while in fact, it's
purely cosmetics; and this is not good. And it also pollute the history
(not that important thought in this case).

> The goal is, to state this again, to first clean up the current code and by
> doing this to understand how everything works.

You can easily do it locally with Git. Also, rewriting stuff from scratch
doing the same/better is also a good way to learn how a project works.
Adapting your eyes to this kind of ugly code may help you later btw, and
you will gain time.

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

There is imo a lot of work on this, and you'll certainly drop a lot of
code you reindented/prettified/fixed…

> 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?
> 

I don't know how you're supposed to get "events" in slave mode. But
remember one thing: the GUI you're working on must be an example for the
others. This means the GUI must not support things other front-ends won't
be able to support. So I guess you have to find/create a way to send
message strings to various apps (and then your GUI).

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110312/f04455bf/attachment.pgp>