GNOME Bugzilla – Bug 528064
gnome-volume-control UI improvements
Last modified: 2008-05-20 18:25:28 UTC
Some time ago I submitted a patch (bug #313495) that added to each entry in the track list whether it was a Playback, Recording, Switch or Option track. But in current gnome-volume-control releases that has disappeared. I'd like to add it back, but while thinking about it I came up with another idea on how to improve the interface. Basically: get rid of the Preferences window altogether. Instead, always show all four of the Playback/Recording/Switches/Options tabs. Inside the tabs, add a button which, when pressed, gives you a pop-up menu that lets you enable/disable mixer tracks. This means that tracks can be found more quickly, and are already located in the correct part of the user interface, without having to hunt through a list in a fiddly second window--which is problematic as toggling the visiblity of something does not always make it appear on the screen--if it is in a non-current tab then there is no feedback. Anyway, let me know what you think about re-vamping the UI and I will take a stab at it.
Created attachment 109272 [details] [review] restore the type column to the track list
Created attachment 109273 [details] [review] Sort mixer tracks by their type This makes the track list much more usable on systems with a lot of tracks.
Created attachment 109274 [details] [review] restore the type column to the track list Additionally update the track type labels to match the tabs in the main mixer window. Also remove a comment that I left in by accident.
Created attachment 109321 [details] [review] restore the type column to the track list Also change the 'option' string to say 'options' to match its tab.
Created attachment 109322 [details] [review] Sort mixer tracks by their type Remove debugging code
I don't if renaming the pages is such a good idea, please open a different bug for that, with string and usability as kw. In the origin path applied by Ronald, I can see the COL_TYPE, but yeah, it's obviously missing the patch #1. I think the patch #2 is quite rational and safe.
and btw, thanks :)
No problem! Note that I'm not renaming the pages--these changes actually change the string that appears in the track list. It appears that someone else renamed the tabs since my original patch, and since COL_TYPE went missing, the renaming was not applied to the get_page_description function (which is actually not called at all at the moment--the very reason for that function to exist is to provide the string that goes into the mixer list). :)
ok, so please apply, it's fine.
(In reply to comment #9) > ok, so please apply, it's fine. > Does the status of the patch need to be set to 'accepted-commit_now' for it to be picked up?
(In reply to comment #10) > (In reply to comment #9) > > ok, so please apply, it's fine. > > > > Does the status of the patch need to be set to 'accepted-commit_now' for it to > be picked up? > I am not sure to understand what your question means. As I am one of the maintainer of gnome media, I have the responsability of what goes in, and I review the patches. "accepted-commit_now" means it's ok, from the reviewer/maintainer POV, if you apply the patch in trunk, now. :)
Oh ok, I thought you were asking me to commit it myself which I can't do as I don't have commit access :)
Marc-Andre, can you commit the patch for Sam since he doesn't have svn access?
(In reply to comment #13) > Marc-Andre, can you commit the patch for Sam since he doesn't have svn access? > sure, committed. Thanks Sam!
and I just applied the first hunk of patch #1. r3857 Please open a different bug for the string change, if you still think it's a good idea. thanks :)