Hi, I’m using an AudioDeviceSelectorComponent for obvious reasons but it would be nice if I had some way of knowing how much space it needs to display all of its controls especially as these disappear/reappear depending on the device selected. As far as I can see there are two ways (possibly 3) ways of doing this.
The first is how I currently have it and is the ‘quick and dirty’ method by simply letting the component control its own size by calling something like this at the end of resized()
[code] if (midiOutputSelector != nullptr)
{
midiOutputSelector->setBounds (lx, y, w, h);
y += h + space;
}
setSize(getWidth(), y);
[/code]
This means we can just call selectorComp.setBounds(x, y, w, selectorComp.getHeight()); in our own resized method. However I can see how this could break other peoples code (and probably some of my own) so probably not a good idea for the library.
Another possibility is to keep a member variable which is updated inside resized called something like “minHeightRequiredToDisplayAllComponents” and provide a accessor for it. Then we would need some callback to tell us that the size has changed so we could respond accordingly.
Now, during writing this I realised that we can register with the AudioDeviceManager’s ChangeBroadcaster to be informed when a device changes but the problem then is that our own callback gets called before the AudioDeviceSelectorComponent’s so it doesn’t have a chance to update its size. This can be worked around by inheriting from AsycUpdater and triggering an async update during the change callback and repainting during the handleAsyncUpdate callback to make sure the AudioDeviceSelectorComponent has a chance to update its size. As you can probably tell, long winded.
A better solution would be for the AudioDeviceSelectorComponent to either directly inherit from changeBroadcaster and emit change messages when its size changes or for it to implement its own listener interface like so many other (admittedly more generic) UI widgets.
What do you think? Has anyone else implemented a possibly more elegant solution? I’m open to ideas.
Cheers.
Fair point. I’ve always shied away from re-implementing things already in the juce library but maybe this is a more specialised use case and as you say I then have complete control over the interface.
As a user, I prefer a dialog that keeps its size rather than changing when items are manipulated. For the audio selector, I would just make it as big as it needs to be for the largest configuration.
I have to admit that is what I usually do. This is a fairly simple settings pane with the audio settings present as a panel within it. It just seemed a bit odd to have the panel a lot larger than the controls that fill it. I was also unsure of how it would scale. For example if you have a device with lots of channels the panel ends up having to be being very large while most of the time not filling most of it (see below).
[attachment=0]Screen shot 2011-06-15 at 00.34.29.png[/attachment]
Having a selector component that can update its size also means it can be appropritaely put in a viewport so you can scroll around it if necessary. This would be a best of both worlds solution ie. best for most use cases (no evidence of viewport) but not unuseable for the edge cases.
I agree that’s why I used a ComboBox to display the channels. It doesn’t show all the channels until the user pops it. Here’s the thing, if there are 10 possible input channels, does it make sense within your application if all 10 of them are “checked” as per the standard Juce audio selector dialog? Or do you really want the user to just select 1 or 2 of them?
Ack! Scrollbars inside modal dialogs are quite unfriendly (unless they are displaying user-defined data).
I hear you but take my screenshot above (my main page has even fewer controls) at the moment about 30% of the window is doing nothing. If I can gauge a reasonable ‘normal’ size I can set the window to that as standard to minimise blank space and if the user happens to select a few options which mean not all the elements fit in the small window the component could fit itself into a viewport or even enlarge the window itself (some OSX panels do this for advanced type options).
All the points you make are perfectly valid and to be honest I haven’t set in stone the interface yet (as you can probably tell) so its good to hear some outside and experienced views.
As this is a really simple app, at least it should be simple to set up and use, I wan’t to make it as compact as possible so it reflects this simplicity. A big window with lots of controls just looks fidly and lots of empty space just looks like I haven’t thought about the design.
I think I will probably take your intial advice and roll my own. I can then split up the audio into ‘sender’ and ‘receiver’ controls to present a more unified interface.
