[MPlayer-G2-dev] Developing a GTK2 GUI

[Arpi]

Hi,

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

Great!

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

I meant one for each Gui implementation, but of you think it's easier to
write a common 'gui builder' with toolkit-specific backends, do it :)
I don't know these toolkits (i never programmed Guis), but i guess they are
named differently because they have different logic, design, features.

Of course you only need to support gtk2 , the win32 etc gui developers will
do it for their toolkit/platform, i guess.

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

Ok.
Actually grouping is already present in config layer, but afaik not yet used
in any of teh plugins. Maybe we need more detailed grouping
(multi-dimensional or hierarchieal?)...

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

I think there wont be too much things.
But it's sometimes possible that a module/plugin have options of type
module_list_t, ie. a selection of other plugins/modules.
I think this could be represented in gui by a pair of list boxes, the
selected plugins on the left side, and the list of available modules (of
that type) on right side. Then user can drag'n'drop (or other way
add/remove) items from right to left, and by double-clicking on left side
elements they can configure tehse modules (by pop-up new cofnig window).
Or I'm just dreaming :)))

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

The playtree code in g1 was quite broken (dunno if it works ok now, i guess
not yet), and Pontscho (g1 gui maker) didn't understand how it works.

We were designing some metadata structure to use for exporting tracklists,
playlists/trees etc from stream/demuxer layer, but it was not implemented
yet. See teh mail archives if interested, but if you need it ASAP i'll
increase its priority. Or if anyone interested in implementing that, tell me.

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

Great!


A'rpi / Astral & ESP-team

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