Hi all.
Ive gone through mantis, and picked out a few bugs I'd like to fix (or
see fixed, whichever comes first). So far, I've had a few patches
accepted into the source tree, and would like to continue to contribute
to the project. However, I'd like to ask for some input/suggestions/etc
on what the best way to go about some of these would be. I'm sure the
senior developers can provide some good insight. If nothing else,
perhaps I can generate some interest in getting these specific issues
resolved. Thanks in advance for any comments on these.
Also, one more quick question. If a bug is marked for the 0.9x series,
but is still present in the 2.0 series (and I fix the 2.0 series bug),
should I post the patch to that bug, or file a new one for the 2.0
series, and post it there? Or just email out patches?
Thanks
~Brian
====================================
1. Bug #211, Most buttons do not show their status (colour) when the
mouse is hovering over them
Seems like #94 and #211 might be related?
http://tracker.ardour.org/view.php?id=94
http://tracker.ardour.org/view.php?id=211
I'm curious if the gtkrc file can be modified to fix this. That
certainly seems like the cleanest solution, if such would be possible. I
haven't played with gtkrcs too much, so I'm not sure if gtkrc is
powerful enough to do that. If not, another solution might be to
implement mouse-over handlers for all the affected widgets - but thats a
lot of work, touches a lot of code, and probably isn't the best possible
solution. It might also be possible to subclass the button widget, with
one that preserves its color on mouse over, but that still touches quite
a bit of code.
====================================
2. Bug #1194, If plugin connection impossible, Add dialog closes
http://tracker.ardour.org/view.php?id=1194
Seems that the connection dialog closes by default, and the
weird_plugin_dialog is called from deeper in the code. Here's whats
going on:
Connect Button Clicked -->
PluginSelector::run [plugin_selector.cc:482] -->
PluginSelector::use_plugin [plugin_selector.cc:380] -->
<signal> PluginCreated() -->
RedirectBox::insert_plugin_chosen [redirect_box.cc:359] -->
RedirectBox::wierd_plugin_dialog [redirect_box.cc:377]
Obviously, if the connection is impossible, which seems to be determined
in RedirectBox::insert_plugin_chosen, something needs to happen to tell
the top level method (PluginSelector::run) not to close the dialog - any
ideas on what would be a clean way to do this?
====================================
3. Bug #1210, Would be nice if there was a way to globally change the
height of all tracks in the editor.
http://tracker.ardour.org/view.php?id=1210
I've gone around on this one for a while. I have a patch for it, but I'm
sure theres a better way. According to the report in mantis, when the
'Display height' button is Ctrl+Shift clicked on a track, and then the
user selects a height from the pop-up menu, the height of all tracks
should change to that height. Seems reasonable enough.
The click handler for the button has a GdkEventButton *ev, passed to it,
from which it's possible to figure out if Ctrl+Shift was clicked. Is
there any way to figure out instead if the menu item was Ctrl+Shift
clicked? That would simplify the solution a bit. If not, I've come up
with two possible solutions, neither of which I'm perfectly happy with.
Let me explain:
a) use the existing pop-up menu, and just change the callback, so it
checks if Ctrl+Shift was clicked on the button. This works, but requires
some way to pass that information (ie, if Ctrl+Shift was pressed) to the
callback that handles the menu click. Using a flag somewhere in the
class isn't a good idea, since that introduces a bug that if you
Ctrl+shift click the button, then cancel the menu, then change the
height of a track, the height of all tracks still change... and since
Gtkmm doesn't wrap the menu_canceled signal, I haven't found a way
around that.
b) alternatively, define another pop-up menu, which only handles the
case of Ctrl+Shift click, and have the button callback select which menu
to display based on if Ctrl+Shift was clicked. Works great, but adds
another menu to the code...
My patch uses (b). If anyone is interested in seeing that, Ill email it
out, and/or post it to mantis.
====================================
4. Bug #1293, Punch markers can be hidden but the edit area remains colored
http://tracker.ardour.org/view.php?id=1293
Is this really a bug? Seems that if you hide the punch range, the
colored area is still there, however, deactivating the 'Punch In' and
'Punch Out' Buttons makes the colored area go away. Can someone clarify
the desired action?
Also, is this related to bug #1294 ?
http://tracker.ardour.org/view.php?id=1294
====================================
5. Bug #1292, "Original Position" function does not work
http://tracker.ardour.org/view.php?id=1292
Can someone explain to me what this function is supposed to do?
====================================
6. Bug #1041, If track name has ":" in it, outputs are not saved
http://tracker.ardour.org/view.php?id=1041
This seems like a good thing to have fixed. Jack gets seriously confused
if there is a colon in the name of a track. What would be the desired
action? Just prevent ":" in track names?
=====================================
7. Seems like there might be a few memory leaks?
There's no bug filed for this as of yet. But I ran Ardour through
valgrind, (ie, open ardour, play 2-3 seconds of audio, and close it).
The output from valgrind is nearly 10,000 lines long (ie, about 250
pages) Granted, a lot of that is bugs in GTK, Gtkmm, glib, etc... I
should set up valgrind to suppress the bugs in the libraries. Does
anyone have an existing ardour-specific suppression file that they use
for this kind of stuff?