Ticket #298 (closed enhancement: fixed)

Opened 10 years ago

Last modified 9 years ago

width of Audiofire ffado-mixer should be resizable

Reported by: yves.g Assigned to: arnonym
Priority: minor Milestone:
Component: ffado-mixer Version: FFADO 2.0.1
Keywords: Cc:
The device the bug applies to: Audiofire

Description

When used with Echo Audiofire Pre8, the window of ffado-mixer has a width around 2152px. This is larger than the highest resolution of any screen today. The problem is that the width cannot be changed (only the height of the window can be resized).

The interface would be more user friendly if it could be resized. The buttons (pan, solo, mute) are large and could be reduced, the space between the columns could also be reduced.

Attachments

ffado.1882.diff (12.9 kB) - added by euan on 08/31/10 08:15:56.
SVN Diff of my changes.
ffado-mixer.png (66.6 kB) - added by euan on 08/31/10 08:23:49.
Screen shot of proposed change
Capture-ffado-mixer-r1885-chained.png (68.4 kB) - added by yves.g on 09/05/10 23:49:23.
Capture of ffado-mixer, r1885 plus correction of QToolButton, two chained devices

Change History

08/31/10 08:15:56 changed by euan

  • attachment ffado.1882.diff added.

SVN Diff of my changes.

08/31/10 08:20:46 changed by euan

  • device_name set to Audiofire.

The mixer window is expanded horizontally due to the large number of "Pad" buttons across the page on the Input tab. In addition, the Output Strips are all too big to fit in a single window.

I have changed the audiofire_strip.ui and audiofire.py to force the widgets to reasonably small values and to force the dynamic "Pad" buttons to be smaller too.

Please can a developer review and submit if acceptable.

Thanks,

Euan.

08/31/10 08:23:49 changed by euan

  • attachment ffado-mixer.png added.

Screen shot of proposed change

09/02/10 01:37:05 changed by yves.g

I tested the patch on rev 1882 and it works exactly as I hoped. Thank you, Euan.

I suggest that a developer reviews it and submits it.

09/05/10 12:56:37 changed by arnonym

  • status changed from new to assigned.

Can you guys check to see whether r1885 fixes things?

Otherwise I will try to add horizontal scrollbars. But I don't know whether these should affect the whole mixer, one tab (ie. one sub-mix) or just the inputs on each tab, so that playback and output are always visible.

Strange problem for me: I know Qt and python and why some of the layout-problems where there. Only I can't really test it as I don't have a profire:-) But I am working on tricking my ffado-mixer into believing I am having a profire...

09/05/10 23:48:00 changed by yves.g

ffado-mixer in this version r1885 does not open the mixer window, it stops after displaying the following log messages:

08:11:58 dbus: connecting to: Updated on /org/ffado/Control/DeviceManager (server: org.ffado.Control)
08:11:58 panelmanager: PanelManager::updatePanels()audiofire.py", line 257
08:11:58 panelmanager: going to add 0014860a5b6be484
08:11:58 panelmanager: Adding device 0: 0014860a5b6be484
08:11:58 panelmanager:  Found (0014860a5b6be484, 1486, AF9) Echo Digital Audio AudioFirePre8
08:11:58 registration: version/GUID combo already registered
08:11:59 audiofire: Init AudioFire mixer window
08:11:59 audiofire: Building mixer
08:12:00 audiofire: strip

Launching ffado-mixer in a terminal shows that the problem comes from QToolButton (was QPushButton previously):

$ ffado-mixer
08:11:58 dbus             DEBUG    connecting to: Updated on /org/ffado/Control/DeviceManager (server: org.ffado.Control)
08:11:58 panelmanager     DEBUG    PanelManager::updatePanels()
08:11:58 panelmanager     DEBUG    going to add 0014860a5b6be484
08:11:58 panelmanager     DEBUG    Adding device 0: 0014860a5b6be484
08:11:58 panelmanager     DEBUG     Found (0014860a5b6be484, 1486, AF9) Echo Digital Audio AudioFirePre8
08:11:58 registration     DEBUG    version/GUID combo already registered
08:11:59 audiofire        DEBUG    Init AudioFire mixer window
08:11:59 audiofire        DEBUG    Building mixer
08:12:00 audiofire        DEBUG    strip
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/ffado/panelmanager.py", line 349, in updatePanels
    mixerwidget.buildMixer()
  File "/usr/lib/python2.6/site-packages/ffado/mixer/audiofire.py", line 257, in buildMixer
    btn = QToolButton( grpInput )
NameError: global name 'QToolButton' is not defined

I replaced QToolButton by QPushButton in audiofire.py, line 257, and it worked!

I tested it with a single Audiofire Pre8, but also by chaining two of them. In this last case, ffado-mixer shows two tabs (I attach a screen capture). Adding horizontal scrollbars does not seem useful, at least for a screen that has a width of 1280px. The only point is that I cannot identify which box corresponds to each tab. It would be nice to show the IDs of the boxes.

May be the button "Identify Device" in tab "Settings" plays this role, but I see nothing when I push this button, except in the log which displays the message:

audiofire: trigger /Identify

09/05/10 23:49:23 changed by yves.g

  • attachment Capture-ffado-mixer-r1885-chained.png added.

Capture of ffado-mixer, r1885 plus correction of QToolButton, two chained devices

09/06/10 00:14:17 changed by arnonym

The advantage of the QToolButton is that this needs less space at the side of the text. So it gives smaller channel-strips.

I will add the correct include for the QToolButton this evening.

I don't have (or know) the hardware, but could it be that when you click the "identify" button, some lights on the device start to blink? So that you can identify it?

09/06/10 01:01:46 changed by yves.g

Unfortunately, there is no blinking light that could help identify the device.

It could be useful to see in the "Settings" tab for each box, an information similar to what is shown by ffado-test ListDevices , for instance: port, node and GUID.

09/06/10 05:54:30 changed by euan

This looks good. Thanks.

03/28/12 04:23:51 changed by jwoithe

  • status changed from assigned to closed.
  • resolution set to fixed.

Arnold's final round of fixes for this issue seem to have been committed in r1887, which included the include fix noted in comment 5. It would therefore appear that this issue is resolved so I'll close the ticket.