Re: Developing a GTK2 GUI
"Charles Ezell" <[email protected]>
| Newsgroups | gmane.comp.video.mplayer.g2.devel |
|---|---|
| Message-ID | <[email protected]> |
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