Re: [FFADO-devel] Mixer stuff

[Jonathan W. <jw...@ph...>]

Hi Arnold

> 1) The mixer got switched from "one mixer window per device" to "one window 
> with tabs for each device".

Yes, I noticed that last week.  I'm not actually convinced that this is a
good idea.  I can imagine many workflows where, if multiple devices are
present, having all device mixers visible simultaneously would be a huge
advantage.  True, it is painful if you have only one monitor, but with two
or more monitors the extra screen real estate wouldn't be an issue. 
Therefore, having an ability to "undock" the mixers from the tab view would
be a good thing IMHO.  Whether that's beyond the ability of qt is not
something I can comment on at the moment though. :-)

The other thing I'm slightly concerned about is that for some devices we're
starting to get nested tabbed environments now that the top level is also a
tab.  Is this likely to get confusing for users?

> One of the resulting changes is that the over-all 
> window gets resized to the minimumSize of the mixer-widgets plus the 
> tab-related sizes. So the mixer-widgets actually have to return a minimumSize 
> > 0x0. This can be done by either hardcoding that size in qt designer or by 
> aligning the widgets in layouts.

I noticed this last week too and put in a hacky fix for it.  If I recall
correctly I tried specifying a minimum size for the MOTU mixer and it didn't
make any difference (hense my eventual change in ffadomixer).  I could be
wrong though - maybe I specified a minimum size for the wrong widget.

> The usage of layouts has several advantages, first all the minimum sizes
> are handled automatically, second the gui becomes re-sizable without
> anything to be done from your point.

Changing everything to use layouts would be cool but I suspect it should be
a 2.1 thing.  I don't know qt/qt-designer well enough to have an opinion but
I'm guessing that such a move would be a lot of work.

> 2) As all devices (should?) support clockselection and nicknames, I plan on 
> dividing the mixer-tab for each device in a generic row, where nickname and 
> clocksource (and other possible generic options) are controlled and a second 
> row where the specific gui (if available) is shown. That way devices that 
> don't have a specific gui (because they don't implement a mixer) still 
> support setting the clocksource. And the specific mixer-widgets don't have to 
> duplicate the clocksource.

I can't see any immediate problems with this idea.  The only thought I'll
mention now is whether such a layout can be optimal in terms of screen
usage.  By its definition the "generic" row will occupy an entire layout row
for what will (in most cases) be a single control.  If it were left to the
individual device mixers the clock source could for a part of that device's
basic configuration section and not cause as much empty space in the dialog.

> @jwoithe: Do the motu devices support the clocksource-setting as the 
> bebob/dice/etc?
> If not, is the clocksource-selection hidden from dbus for motu-devs?
> Is the nickname supported/possible for motu-devices?

I'll have to look into more details before answering these questions - I'm
not sure how these generic details are implemented.  The MOTU devices
certainly support clock source settings but I have no idea how this is
communicated via dbus at the lower ffado levels.  I've currently done
nothing special along these lines so I suspect at the very least I need to
add some glue to make the generic clock setting stuff work for MOTU.  FYI
getting a functioning clock source widget was more or less next on my list
of things to do so I'll look into all this and see what I find.

> 3) The generic mixer is only thought as a development-tool. Therefor it 
> shouldn't get installed (ffadomixer should run without mixer_generic.py 
> installed, if it doesn't please send me the error-message). I will deactivate 
> the installation of mixer_generic.py again after I implemented controlling of 
> the clocksource and the nickname in the generic part of the mixer-tab...

Ok, cool.

> 4) I plan to switch ffadomixer to qt4. Don't worry, this is only planned for 
> 2.1, during 2.0 it will stick with qt3. But qt3 has (almost) reached the end 
> of its lifetime. And programming with qt4 is so much more fun...

On the subject of qt3 it should be noted that qt3 is the foundation of Sugar
(of OLPC fame) and it has been stated in numerous places that qt3 will
continue to be supported for quite some time as a result.  I therefore don't
think we have much to worry about in terms of qt3 support.  I agree that a
move to qt4 should be done, but at the same time I don't want it to happen
before qt4 is in my development machine's standard distro.

> If my mails (and commit-messages) offend you, please forgive me. Sometimes I 
> am a little fast-tempered. But I cool down rather fast...

No offense - I just want to make sure that all possible issues are
considered. :-)

Regards
  jonathan