[MPlayer-G2-dev] Developing a GTK2 GUI

Charles Ezell ardneh2 at hotmail.com
Wed Aug 6 04:54:03 CEST 2003


A'rpi writes:

> > >But mplayer does things a lot different than the other players out
> >
> > Yes, mplayer works.  I don't use xine because 1) when I was first 
> > for a movie player years ago (geez, has it been that long?) all xine did 
> > crash and  2) now, Totem, a GTK2 ui for libxine, doesn't start unless I
> > delete one
> > of its config files and sometimes I even have to use gconf!
>lol :)
>I've tried xine a year ago, and it look good, until i pressed play :)
>I liked its preferences window, it build Xvideo config dialog at runtime,
>by querying Xv attribs (like xvinfo) and used them to setup bars.
>(at least it looked so, i'm not 100% sure it was really runtime built
>or they were just tricky again, as usual...)

I haven't used xine itself since that first time.  I will download it and 
check it out.

>It gave me the idea of runtime built config windows...


> > I spent over a week porting that to GTK2 and it became
> > very clear that a lot of things were done that didn't need to be.
> > It could have been much smaller, simpler and more portable.
>Ok, time to tell teh big secret to you :)
>The original Gui (in v0.50) of g1 did not use gtk at all!
>It used Xlib only, and Pontscho wrote a skinned toolkit-like thing

I know.  I've looked at almost all the code in the Gui directory and
know most of it by heart.

>for it. If you look at old g1 skins, you'll see even the popup menus
>pre-drawn in .png. It worked for a while, until things like dinamically
>changed menus (like audio/vidoe ID, dvd title selectable in menu),
>and fileselector requirement came up. Ponstcho didn't want to code a
>so complex toolkit for his skin engine, so he started to hack gtk
>support in. Afair there wasn't gtk2 yet that times.
>Later more and more parts of his skinned stuff was replaced by gtk
>functions, and the things got more messy and ugly... you see the result.

Yes, what had happened was fairly obvious. :(

>I think, if he start with gtk at first day, or he implements complex
>toolkit elements in his xlib-based skinned engine, it woudl be better,
>than this mixed gtk+xlib hack.

I agree.  He probably thinks so, too.

>To make things even worse, he wanted it to look very good (which wasn't
>possible with gtk1 afaik, i mean non-rectangular gui window etc), but

No, it wasn't.  The good news is GTK2 does and my skin test program worked
very well.

>the gui development was sponsored for a while by UHU Linux, given a
>deadline. So he had no time to mess more with xlib, he used gtk...

Ah.  Well, I only have myself to worry about as far as funding.

> > You don't have a chance of discouraging me. :)
>Nice to hear!


>I've never wanted g1's gui to be ported to g2, and as i'm not a gui
>coder (and i don't even want to be), i designed g2 to be ui-independent,
>so that many ppl who started coding guis/frontends for g1 (and failed
>due to g1's monolitic design) can do it now.

For not being a GUI coder you seem to understand things very well.

>Btw I have some crazy(?) ideas for the g2 gtk2 gui, for example a mode
>when it starts without a gui window, like the commandline player
>(and even gets options/filenames etc from commandline) but some mouse
>click or hotkey can bring up config windows/preferences so filters,
>plugins can be configured runtime in an user-friendly interface, even
>for commandline-liker users like me or Rich.
>(Rich: it's quite hard to control (and display) a 24-band audio equalizer
>from commandline...)
>I think with a well-written layered gui it's easily doable.

I was not going to bring this up until later, but I guess now is fine. :)

I would like to suggest that MODULE_TYPE_UI be added to module_type_t
to represent all UI modules.  This would enable UIs to be
dynamically loaded / selected from either the mplayer conf file
or the command line.  Or from whatever UI is being used at the moment.
(NOTE: Yes, it should still be possible to statically link a UI in, if
this is an important feature.  I certainly think it is very convenient.)

Furthermore, UIs that _wanted to_ (this would not be forced on anyone)
could be composed of sub-modules: one for the preferences,
one for the equalizer, one for the main UI, etc...

If it is done this way, then the individual UI sub-modules could be remapped
at will (via the UI's config_t).  A command line UI that uses the GTK 
and equalizer, for example.

All the code to do the UI switching / manipulation would (obviously) be 
in a separate source + header file and only be used by UIs which want to 
have a
modular structure and be dynamically switchable.

None of this should be detrimental to mplayer core.  On the contrary --if I
understand things correctly-- it should be possible to make test-play.c UI
independent.  I think that this is a very good thing.

The main problems I see with this are:
1) it's going to have to be possible to find out what UIs are available on 
2) there needs to be a way to load and unload modules at will.
   module_info_t mentions loadable plugins so I'm assuming both of these are 
   if not currently implemented (I appologize for not checking the code more 
   I still have some work eating up all of my time).
3) It might not be possible because I do not understand mplayer well enough 

That is my very low-priority suggestion.  I am sure there are still things 
need to be worked out and tested.

What do you think?


Tired of spam? Get advanced junk mail protection with MSN 8. 

More information about the MPlayer-G2-dev mailing list