[MPlayer-G2-dev] Developing a GTK2 GUI

[Charles Ezell]

Arpi writes:

>Hi,

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

Great.

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

I was hoping you would say something like that.

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

I don't mind hard work as long as there is a point. :)
Creating the preferences was the thing I was dreading above all else
because it is such high maintenance code (in this case).
This will make things much better / easier in the long run.

>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),

Do you mean one for each toolkit that wants to write a UI?  Or just one 
window
builder for all toolkits?

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

The most I think you would need is grouping info.  I do not see being able 
to represent
positions usefully/accurately for different toolkits / GUIs.  I've got a 
couple of ideas for
implementing grouping.  I will send them later.

As for looks, we'll see when we get there.  As long as there are not too 
many
items on a page it should look OK (it will depend on how smart the window 
builder is).

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

Agreed.  I looked at the playtrees in G1 and was wondering why they were not 
used by the GUI.

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

The less X code the better.  Still, I'm sure there is code that can be used 
by everyone
(using X) and it will be handy to have it in one place.  I have to look into 
it more.

-Charles

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail