[MPlayer-G2-dev] Developing a GTK2 GUI

[Gustavo Sverzut Barbieri]

 --- Charles Ezell <ardneh2 at hotmail.com> escreveu: 
> 
> Gustavo writes:
> 
> >Yes, I know that... win32 is the other way (coordinates-based) and I
> >don't know Mac to tell...
> 
> Don't know either. :)  But it is probably coord based.  I was also
> thinking
> about Qt (which I know next to nothing about).

QT works the same way gtk does, vertical and horizontal layout boxes.

 
> > > Second, if I understand A'rpi correctly, is that the whole system
> > > is supposed to be dynamic.  If I do my job correctly,
> > > you guys should be able to add dozens of modules to mplayer and
> the
> > > users
> > > will not have to upgrade the GUI.  This isn't going to be
> possible
> > > if xml tweaking is involved.
> >
> >How dynamic it would be... it will generate those windows at compile
> >time or at run time?
> 
> Run time.  Completely dynamic.  Also, I only want to create windows
> as
> they are needed.

Cool!


> Example: (please see gedit2's prefs for a visual of the layout, if
> possible)

In their site they don't have screenshots about the prefs. Could you
send me some in private (outside the list)?

> you open the preferences and it generates the first
> page (because it is showing) but nothing else.  Then you click on
> "Audio" (I am going to need help with internationalization)
> from the list on the left and it will create and show the
> audio options, complete with a list of audio plugins.  Fun, huh?

Hum... I din't quite understood that :(

And about translators, you have one: I'm Brazilian, so we can have
pt_BR


> 
> > > Third, the core gui builder code isn't that complex and
> > > the config design is well thought out.  This makes things much
> > > easier.
> > > If I run into problems, we'll work things out.
> >
> >My only hope is that the ui doesn't become something unlogical and
> >non-intuitive... sometimes it's better to put things together
> because
> >they're related, but doesn't worth to put them in a Frame or a
> Tab...
> >so maybe we can have at least 2 kind of groups: Visual (Frames,
> Tabs)
> >and Non-Visual.... or 3: Frames, Tabs, Non-Visual...
> >    Any ideas on that?
> 
> I do not want that either.
> 
> Yep. First I'm going to avoid tabs.  If there are so many options
> they have to be used OK (like if one group of options is really
> large),
> but hopefully that won't be often.

Sometimes we have to get some, like those in mplayer g1. I'm wrong?
 

> Second, a frame in GTK is a group box in win32.  Does this help?
> Even a single item can look good in a frame (Anjuta's preferences are
> proof of that...)

I know about frames in gtk, and don't know nothing about win32 group
boxes :)

What I think is that sometimes you may have to groups things together
as I said and if all the grouping is visible (like a frame), you will
get many frames inside other and that's ugly :)
 

> Third, I'm hoping to have unamed / anonymous groups.  So if I group
> of
> options doesn't fit anywhere else they can be grouped together
> (probably
> without a frame / box).

Ok
 
> Fourth:  What did you mean by non-visual?

Only logical, they're put together but we don't have a frame around
them.


> >Also, maybe we could have the tab-order specified somewhere, so we
> can
> >arrange items based on that order... maybe that list could be other
> >place...
> 
> I think the options should be in the same order as in the config_t.

It's an option! :)

 
> If you mean for the case where there are so many options several tabs
> are
> needed, then that is worth thinking about.  Since I would be
> generating tabs
> on the fly it would be next to impossible to come up with good names
> for 
> them.
> 1, 2, 3 does not cut it.

Yes... maybe we could have a string as the name of the group, if the
group is too large, it's dettached to a tab with that name?

 
> I think maybe you have best solution below.

:)
 
 
> >And (just to make you crazy ;) sometimes it's cool to have small
> items
> >arranged in 2/3 columns
> 
> I was actually planning to do that. :)  Not necessarily based on
> size,
> but on how many options there are.  Not based on size because of the
> way GTK
> works.  

Coll... but if there should be a selection(combo) box?


> This is definatley going to take some work.

Sure! :)

 
> > > >But, there comes a problem: how to keep track from human
> (manual)
> > > >interventions? Maybe the window builder could try to keep the
> old
> > > >layout (and maybe learn with it). Maybe we could keep the manual
> > > >changes as patches and apply it over and over (ugly, but
> easier).
> > >
> > > That would be very hard to do and maintain.  I am probably going
> to
> > > have
> > > to write some algorithms for control placement (mainly how many
> > > controls on
> > > a
> > > page is too many),  I will tweak those as necessary.
> > > The most important thing is not jamming stuff together.
> >
> >IDEA: Every page you put, please I beg you to use a scroll-able
> content
> >(automatic scrollbars), so if someone have a 800x600 with big fonts,
> >things that generally looks well in 1024x768 will probably overflow
> the
> >screen... that happens a lot with linux gui apps :(
> 
> Done.  Really good idea.  I usually run at 1280x1024 and admit I
> tend not to think about lower resolutions. :(
> 
> Actually, I think I might just do this instead of tabs.

Again, I didn't understood what you say about gedit2 prefs, so maybe I
misunderstanding things...
But, only one page with all options inside it sucks very hard :)


> I should be able to make the scrolling view look good, too.
> I have never tried anything like that so I'm going to have to get
> back to you.

Ok.
It's something like adding a viewport as the base widget and setting
the scrollbars to automatic (maybe just the vertical if you don't want
horizontal ones)

 
Gustavo

_______________________________________________________________________
Conheça o novo Cadê? - Mais rápido, mais fácil e mais preciso.
Toda a web, 42 milhões de páginas brasileiras e nova busca por imagens!
http://www.cade.com.br