[MPlayer-G2-dev] Developing a GTK2 GUI

[Charles Ezell]

Hi,

A'rpi writes:

>Hi,
>
> > >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 
>looking
> > for a movie player years ago (geez, has it been that long?) all xine did 
>was
> > 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...

Cool.

> > 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 
preferences
and equalizer, for example.

All the code to do the UI switching / manipulation would (obviously) be 
placed
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 
startup.
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 
planned,
   if not currently implemented (I appologize for not checking the code more 
closely,
   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 
yet.

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

What do you think?

-Charles

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail