[MPlayer-G2-dev] Developing a GTK2 GUI

[Arpi]

Hi,

> I'm interested in writing a GTK2 GUI for mplayer-G2.  Tell me how I can 
> help.
> 
> -Charles

As a start, d/l the last G2 snapshot.
Actually I need some help to finalize the core libs <-> GUI interface.

As you probably noticed, in G1 the GUI was a mess, with #ifdef'ed if(Gui)
hooks everywhere in the source, even in the low-level drivers.

The G2 'design' is about complete separation of core libraries from the UI
code (be it commandline or Gui or browser plugin or whatever).

As the playback core (which controls codec selection, A-V syncro, connection
of decodres, filters and output devices) is under design/development.

In G2, teh new config layer (see cfg.h) exports some usefull info, like the
short name/description of options, and a more controlled, limited set of
values (like using drop-down lists, min/max limited numbers etc, can be
mapped to Gui's combo boxes, bars etc). I think, a runtime 'window builder'
should be developed, which gets a module_info_t* as parameter and produces a
window with controls of the module's (and its submodules if exists) options.
This code then could be used to generate the control window for filters,
codecs, output drivers etc. (all kinds of plugins/modules in libs)
Yes, I know it's a big work. It has lots of advantages (the core, libraries
are (G)UI independent, they export as many info about the controllable
options as they can, in a well-defined simple struct. the plugin coders
don't have to know Gui programming, and can use any (g)ui (be it gtk, qt,
win32, aqua, osd menu or anything) immediatelly to control it.
also it have to be written only once, and every new code can use it without
the needs to extending gui), but it has some disadvantages too, especially
may look worse, than a well-designed control window (although we could
extend the config struct with gui-helper data, like position inside the
window or grouping of options, if really required).

About the video window:

In G1, it was a big ugly mesys hack: i nteh Gui mode, the gui did control
all the window management, instead of the vo drivers.
It meant that gui receives events from X, processes them and then resizes,
moves etc the actual vo window by X calls with that window's ID.
There were several hacks to get it work. And it resulted many
duplicated/redundant code, around X functions (liek xinerama, fullscreen
switching etc, mostly all teh window management stuff)

To workaround this problem, I took Xine's idea: let the (G)UI control all
the windows, and vo (video-out, see libvo2/) drivers only do the minimal
thing: allocating and configuring drawable surfaces.
To help non-GUI UIs, i've added fallback code in x11_util.c, which is used
for x11 drivers when no GUI to do that job. For a GUI it should not be used.
(there are 2 callback functions in vo struct: event_callback and get_events,
see libvo2.txt for details on them)

So, what a GUI should do (imho):
- handle file selection (open) and playlists (or even better: playtrees,
  i mean some playlist formats (including reference .mov files etc)
  support tree of files, and multiple (different bitrate, language etc)
  alternatives os same contents. it would be nice if the gui could display
  this and let the user to select from such tree.
  (note the metadata export from stream layer is not yet coded, it's required
  to export cdda/cddb tracklists, dvd title/chapter structure etc)
- be able to generate plugin/module config windows on-the-fly (see above)
- do window management for video window too, including fullscreen switching,
  setting title, always-on-top and such attributes... you should knoe better.
  (it can be done in x11-util.c too, but i was told that in gui 'mode' it
  must be done by the gui, to be able to swap gui and video windows
  overlapping or so.)



A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu