[Audacity-devel] Proposed fix for Menus/Commands/Keys

[Dominic Mazzoni]

Here are the problems with the current system:

1. It requires the ability to create a file (currently
called audacity-commands.xml) in order for Audacity to
launch. This can be a small annoyance because it's
not obvious where to put the file, and it "clutters"
the system for the 90% of users who will not ever
modify the file.

2. Currently every time we add a new menu command, the
audacity-commands.xml file is invalidated. That
limits its usefulness because users would have to
start from scratch every time they get a new
version.

3. The Keyboard pane in the Preferences is unfinished.

Here are the benefits of the current system that we would
like to keep:

1. The menus are created dynamically and can be changed
or rebuilt while the program is running. (Even if it
doesn't work perfectly now, most of the infrastructure
is there.)

2. The dispatching of commands / the CommandsCallback
system is very nice and in the future could be leveraged
to allow scriptability, etc.

3. Power users have a really nice way to add or change
keyboard shortcuts using their favorite text editor or
XML editor, without having to deal with any interface
that we would need to create.

4. People can share XML files with each other.

Primary goal of this proposal:

- I want to fix this situation without rewriting all of the
code involved. I like 90% of how Brian implemented the
menus/commands, and I don't want to toss it. I also don't
want to spend too much time on it; I want to focus on
usability and getting 1.2.0 finished within months, not
years.

My proposal:

1. In a nutshell, hardcode the menus and default keyboard
shortcuts into the program, but allow the user to load
keyboard shortcuts only from an XML file.

2. The menus could still be loaded from XML, but we would
just load directly from the hardcoded string.

3. If the user wants to modify the keyboard shortcuts, they
go to the Prefs and Save the current shortcuts. From
this panel they can also Load another existing set, or
click another button to Use Defaults. All of these
buttons should be written to take effect immediately
(or just after the Preferences dialog closes).

4. When you upgrade to a new version of Audacity, it starts
with the new Audacity menus. Then if the user had a
keyboard shortcuts file, it loads it and applies all of
the shortcuts that still make sense. It would be neat
if it "stole" shortcuts away from other menus.

5. As much as possible, let's try to make every action that
can be triggered in Audacity, with the exception of things
where the location of the mouse is significant (like
selecting, dragging) to be commands in CommandsCallback.
That way users can configure the key to press for Play,
Stop, Pause, ExtendSelectionRight, etc.

I hope that this is a reasonable compromise that will allow
version 1.2.0 to be complete and consistent, even if it
doesn't have every feature we ever dreamed of (like letting
users completely customize the menu layout).

I'd like to hear your thoughts, especially from Brian, since
he wrote most of this code. Also, Markus, if you're able to
work on this effort, that'd be great. I'll definitely do it
if nobody else does, over the next few weeks. Right now I'm
focusing on loading legacy project files.

- Dominic

[Brian Gunlogson]

We could store (using wxConfig) if the user had opted to use custom keybindings. Otherwise use the
defaults? It shouldn't be difficult to read defaults from the constant CommandsDefaultXML
depending upon the capibilities of expat.

When I was implementing the Commands hashing code (see below) I came very near to supporting
non-menu keybindings. This won't be too difficult.

I am unsure of how to go about writing XML files (besides a memory dump). Maybe Markus could aid
in this area?

Has anyone implemented the Commands hashing code yet (to improve speed)? I wrote a prototype that
compiled but it didn't work. Due to lack of time/knowledge/documentation/examples I trashed the
code (I regret that now). How beneficial would it be? Does anyone know of any examples using
wxHashTable? Audacity uses hash maps which wxWindows says are obsolete. I am recalling all of this
from memory, so I may be wrong.

Brian Gunlogson

Date: Mon, 14 Apr 2003 19:28:48 -0700
Subject: [Audacity-devel] Proposed fix for Menus/Commands/Keys
1. It requires the ability to create a file (currently
called audacity-commands.xml) in order for Audacity to
launch. This can be a small annoyance because it's
not obvious where to put the file, and it "clutters"
the system for the 90% of users who will not ever
modify the file.
2. Currently every time we add a new menu command, the
audacity-commands.xml file is invalidated. That
limits its usefulness because users would have to
start from scratch every time they get a new
version.
3. The Keyboard pane in the Preferences is unfinished.
Here are the benefits of the current system that we would
1. The menus are created dynamically and can be changed
or rebuilt while the program is running. (Even if it
doesn't work perfectly now, most of the infrastructure
is there.)
2. The dispatching of commands / the CommandsCallback
system is very nice and in the future could be leveraged
to allow scriptability, etc.
3. Power users have a really nice way to add or change
keyboard shortcuts using their favorite text editor or
XML editor, without having to deal with any interface
that we would need to create.
4. People can share XML files with each other.
- I want to fix this situation without rewriting all of the
code involved. I like 90% of how Brian implemented the
menus/commands, and I don't want to toss it. I also don't
want to spend too much time on it; I want to focus on
usability and getting 1.2.0 finished within months, not
years.
1. In a nutshell, hardcode the menus and default keyboard
shortcuts into the program, but allow the user to load
keyboard shortcuts only from an XML file.
2. The menus could still be loaded from XML, but we would
just load directly from the hardcoded string.
3. If the user wants to modify the keyboard shortcuts, they
go to the Prefs and Save the current shortcuts. From
this panel they can also Load another existing set, or
click another button to Use Defaults. All of these
buttons should be written to take effect immediately
(or just after the Preferences dialog closes).
4. When you upgrade to a new version of Audacity, it starts
with the new Audacity menus. Then if the user had a
keyboard shortcuts file, it loads it and applies all of
the shortcuts that still make sense. It would be neat
if it "stole" shortcuts away from other menus.
5. As much as possible, let's try to make every action that
can be triggered in Audacity, with the exception of things
where the location of the mouse is significant (like
selecting, dragging) to be commands in CommandsCallback.
That way users can configure the key to press for Play,
Stop, Pause, ExtendSelectionRight, etc.
I hope that this is a reasonable compromise that will allow
version 1.2.0 to be complete and consistent, even if it
doesn't have every feature we ever dreamed of (like letting
users completely customize the menu layout).
I'd like to hear your thoughts, especially from Brian, since
he wrote most of this code. Also, Markus, if you're able to
work on this effort, that'd be great. I'll definitely do it
if nobody else does, over the next few weeks. Right now I'm
focusing on loading legacy project files.
- Dominic

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

[Dominic Mazzoni]

Post by Brian Gunlogson
We could store (using wxConfig) if the user had opted to use custom
keybindings. Otherwise use the
defaults? It shouldn't be difficult to read defaults from the constant
CommandsDefaultXML
depending upon the capibilities of expat.

Yes, that sounds great.

Expat can parse XML directly from a buffer in memory. In fact, this
should be even easier than parsing from a file. (Expat never reads
directly from the file - you just pass it bytes from the file and it
keeps parsing until there's an error or an EOF.)

Post by Brian Gunlogson
When I was implementing the Commands hashing code (see below) I came
very near to supporting
non-menu keybindings. This won't be too difficult.

Agreed, it shouldn't be too hard.

Post by Brian Gunlogson
I am unsure of how to go about writing XML files (besides a memory
dump). Maybe Markus could aid in this area?

I firmly believe that we should write the XML file the simple way:
just as a text file, one line at a time, without any special code
to "validate" it for us. However, we may want to consider using
a class to encode special characters. Still, let's start by coding
it the same way we write .aup files - recursively, passing around
a "depth" for indentation.

Post by Brian Gunlogson
Has anyone implemented the Commands hashing code yet (to improve
speed)? I wrote a prototype that
compiled but it didn't work. Due to lack of
time/knowledge/documentation/examples I trashed the
code (I regret that now). How beneficial would it be? Does anyone know
of any examples using
wxHashTable? Audacity uses hash maps which wxWindows says are
obsolete. I am recalling all of this
from memory, so I may be wrong.

Well, DirManager uses wxWindows' wxHashTable class, which isn't
great, but it's not horrible. For this use I think it would
be fine. The important thing is to use some sort of hashtable-like
API (actually I think the term is "Dictionary") and then we can
always swap in a better implementation later.

I've written some good hashtables before; if wxHashTable or one
of the newer wx hash classes doesn't cut it, I can write one.

Still, this is icing on the cake. Let's get the code to work
first and then optimize it.

Thanks for your feedback, Brian. I know that you've been busy - are
you able to help with any of this, especially since it's your code?
Feel free to say no, but I also want to give you first crack at it
if you're interested.

- Dominic

Post by Brian Gunlogson
Brian Gunlogson

Date: Mon, 14 Apr 2003 19:28:48 -0700
Subject: [Audacity-devel] Proposed fix for Menus/Commands/Keys
1. It requires the ability to create a file (currently
called audacity-commands.xml) in order for Audacity to
launch. This can be a small annoyance because it's
not obvious where to put the file, and it "clutters"
the system for the 90% of users who will not ever
modify the file.
2. Currently every time we add a new menu command, the
audacity-commands.xml file is invalidated. That
limits its usefulness because users would have to
start from scratch every time they get a new
version.
3. The Keyboard pane in the Preferences is unfinished.
Here are the benefits of the current system that we would
1. The menus are created dynamically and can be changed
or rebuilt while the program is running. (Even if it
doesn't work perfectly now, most of the infrastructure
is there.)
2. The dispatching of commands / the CommandsCallback
system is very nice and in the future could be leveraged
to allow scriptability, etc.
3. Power users have a really nice way to add or change
keyboard shortcuts using their favorite text editor or
XML editor, without having to deal with any interface
that we would need to create.
4. People can share XML files with each other.
- I want to fix this situation without rewriting all of the
code involved. I like 90% of how Brian implemented the
menus/commands, and I don't want to toss it. I also don't
want to spend too much time on it; I want to focus on
usability and getting 1.2.0 finished within months, not
years.
1. In a nutshell, hardcode the menus and default keyboard
shortcuts into the program, but allow the user to load
keyboard shortcuts only from an XML file.
2. The menus could still be loaded from XML, but we would
just load directly from the hardcoded string.
3. If the user wants to modify the keyboard shortcuts, they
go to the Prefs and Save the current shortcuts. From
this panel they can also Load another existing set, or
click another button to Use Defaults. All of these
buttons should be written to take effect immediately
(or just after the Preferences dialog closes).
4. When you upgrade to a new version of Audacity, it starts
with the new Audacity menus. Then if the user had a
keyboard shortcuts file, it loads it and applies all of
the shortcuts that still make sense. It would be neat
if it "stole" shortcuts away from other menus.
5. As much as possible, let's try to make every action that
can be triggered in Audacity, with the exception of things
where the location of the mouse is significant (like
selecting, dragging) to be commands in CommandsCallback.
That way users can configure the key to press for Play,
Stop, Pause, ExtendSelectionRight, etc.
I hope that this is a reasonable compromise that will allow
version 1.2.0 to be complete and consistent, even if it
doesn't have every feature we ever dreamed of (like letting
users completely customize the menu layout).
I'd like to hear your thoughts, especially from Brian, since
he wrote most of this code. Also, Markus, if you're able to
work on this effort, that'd be great. I'll definitely do it
if nobody else does, over the next few weeks. Right now I'm
focusing on loading legacy project files.
- Dominic

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Daniel James]

But let me just point out that
in audacity, 'record' is not a dangerous button, unlike on a tape deck
or on a number of other digital recorders. Given that, it seems out of
place to me way over on the right.

I'd actually expect record to be on the left of play, 'fast forward' to be on
the right of play, and 'reverse' to be on the left of record. At the moment
with 1.1.3 we've got record to the right of play, which I find a little
counter-intuitive.

Cheers

Daniel

[Juhana Sadeharju]

Hello, and thank you all for the feedback.

The transport button order seems to not be exactly of matter
of taste. I explaned earlier the magic behind the new order.
I actually used both the old and the new order. The new order
makes the transport more easily usable. Tested and confirmed. ;-)

The orders in tape recorders are motivated by the fact that
many years ago you had to press both the rec and the play down
for recording. They had to be nearly side by side.
And people lost their recording if they made a mistage in playing.

Compared to the old order, I find it better to have
the play and stop button side by side. So, that is a must.
The same for << and >> buttons, guess. They are good because
the mouse movement is minimized. Because I use the mouse and
not shortkeys, I appreciate the new order more.

The pause button is also next to the play because pause is
similar to stop in behaviour -- actually, pause could be used
far many times than the stop if user is transcripting a speech.

Rec button could be at either end, I selected the right end
because often used pause would then be next to rec button.
If you like it better put rec at left but leave a small space
between the rec and the pause, or move << and >> between
rec and pause: rec, <<, >>, pause, play, stop.

If you want try it out, you find the sources at
http://www.funet.fi/~kouhia/a113mod1.tgz
Remove the *.o files as the makefile did not clean all.
Please perform "diff -r" with audacity-src-1.1.3, just in case.

-*-

Yes, the feature 5 is a major change. The 0 would stay special.
"Play from start" could play from 0, "move to start" could go to 0,
etc. The "project save" could save all, but export could save only
starting from 0. The negative side could be used as a scratchpad.

In any case, I see the change is justified -- check the feel and look
with the modified source yourself. Now we would have to just make it
work with 0 being special.

It is all ok, if "zoom to all" would mean range starting from 0,
and something different would zoom to entire project. I was just
annoyed that I could not access the audio in the negative side,
and because I had planned to have an infinite tracks in the
editor I use. ;-)

Lets put it this way: Audacity could work just as it works now,
but the series of changes initiated by my feature 5 would only
open a possibility to edit and use the audio in the negative side.

I will continue on this feature so that it is transparent
against the current Audacity. No problem.

Best regards,

Juhana

[Brian Gunlogson]

Sure, I'll start on this tonight or tomorrow.

Brian Gunlogson

Post by Dominic Mazzoni

Post by Brian Gunlogson
We could store (using wxConfig) if the user had opted to use custom
keybindings. Otherwise use the
defaults? It shouldn't be difficult to read defaults from the constant
CommandsDefaultXML
depending upon the capibilities of expat.

Yes, that sounds great.
Expat can parse XML directly from a buffer in memory. In fact, this
should be even easier than parsing from a file. (Expat never reads
directly from the file - you just pass it bytes from the file and it
keeps parsing until there's an error or an EOF.)

Post by Brian Gunlogson
When I was implementing the Commands hashing code (see below) I came
very near to supporting
non-menu keybindings. This won't be too difficult.

Agreed, it shouldn't be too hard.

Post by Brian Gunlogson
I am unsure of how to go about writing XML files (besides a memory
dump). Maybe Markus could aid in this area?

just as a text file, one line at a time, without any special code
to "validate" it for us. However, we may want to consider using
a class to encode special characters. Still, let's start by coding
it the same way we write .aup files - recursively, passing around
a "depth" for indentation.

Post by Brian Gunlogson
Has anyone implemented the Commands hashing code yet (to improve
speed)? I wrote a prototype that
compiled but it didn't work. Due to lack of
time/knowledge/documentation/examples I trashed the
code (I regret that now). How beneficial would it be? Does anyone know
of any examples using
wxHashTable? Audacity uses hash maps which wxWindows says are
obsolete. I am recalling all of this
from memory, so I may be wrong.

Well, DirManager uses wxWindows' wxHashTable class, which isn't
great, but it's not horrible. For this use I think it would
be fine. The important thing is to use some sort of hashtable-like
API (actually I think the term is "Dictionary") and then we can
always swap in a better implementation later.
I've written some good hashtables before; if wxHashTable or one
of the newer wx hash classes doesn't cut it, I can write one.
Still, this is icing on the cake. Let's get the code to work
first and then optimize it.
Thanks for your feedback, Brian. I know that you've been busy - are
you able to help with any of this, especially since it's your code?
Feel free to say no, but I also want to give you first crack at it
if you're interested.
- Dominic

Post by Brian Gunlogson

Post by Dominic Mazzoni
1. It requires the ability to create a file (currently
called audacity-commands.xml) in order for Audacity to
launch. This can be a small annoyance because it's
not obvious where to put the file, and it "clutters"
the system for the 90% of users who will not ever
modify the file.
2. Currently every time we add a new menu command, the
audacity-commands.xml file is invalidated. That
limits its usefulness because users would have to
start from scratch every time they get a new
version.
3. The Keyboard pane in the Preferences is unfinished.
Here are the benefits of the current system that we would
1. The menus are created dynamically and can be changed
or rebuilt while the program is running. (Even if it
doesn't work perfectly now, most of the infrastructure
is there.)
2. The dispatching of commands / the CommandsCallback
system is very nice and in the future could be leveraged
to allow scriptability, etc.
3. Power users have a really nice way to add or change
keyboard shortcuts using their favorite text editor or
XML editor, without having to deal with any interface
that we would need to create.
4. People can share XML files with each other.
- I want to fix this situation without rewriting all of the
code involved. I like 90% of how Brian implemented the
menus/commands, and I don't want to toss it. I also don't
want to spend too much time on it; I want to focus on
usability and getting 1.2.0 finished within months, not
years.
1. In a nutshell, hardcode the menus and default keyboard
shortcuts into the program, but allow the user to load
keyboard shortcuts only from an XML file.
2. The menus could still be loaded from XML, but we would
just load directly from the hardcoded string.
3. If the user wants to modify the keyboard shortcuts, they
go to the Prefs and Save the current shortcuts. From
this panel they can also Load another existing set, or
click another button to Use Defaults. All of these
buttons should be written to take effect immediately
(or just after the Preferences dialog closes).
4. When you upgrade to a new version of Audacity, it starts
with the new Audacity menus. Then if the user had a
keyboard shortcuts file, it loads it and applies all of
the shortcuts that still make sense. It would be neat
if it "stole" shortcuts away from other menus.
5. As much as possible, let's try to make every action that
can be triggered in Audacity, with the exception of things
where the location of the mouse is significant (like
selecting, dragging) to be commands in CommandsCallback.
That way users can configure the key to press for Play,
Stop, Pause, ExtendSelectionRight, etc.
I hope that this is a reasonable compromise that will allow
version 1.2.0 to be complete and consistent, even if it
doesn't have every feature we ever dreamed of (like letting
users completely customize the menu layout).
I'd like to hear your thoughts, especially from Brian, since
he wrote most of this code. Also, Markus, if you're able to
work on this effort, that'd be great. I'll definitely do it
if nobody else does, over the next few weeks. Right now I'm
focusing on loading legacy project files.
- Dominic

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

[Dominic Mazzoni]

Excellent!

One last thing: if possible, let's try to avoid header files that
are included multiple times to mean different things. If that's
the only way to avoid code duplication, that's okay, but having
header files that do multiple things is making it difficult for
me to implement precompiled headers on the Mac.

- Dominic

Post by Brian Gunlogson
Sure, I'll start on this tonight or tomorrow.
Brian Gunlogson

Post by Dominic Mazzoni

Post by Brian Gunlogson
We could store (using wxConfig) if the user had opted to use custom
keybindings. Otherwise use the
defaults? It shouldn't be difficult to read defaults from the
constant
CommandsDefaultXML
depending upon the capibilities of expat.

Yes, that sounds great.
Expat can parse XML directly from a buffer in memory. In fact, this
should be even easier than parsing from a file. (Expat never reads
directly from the file - you just pass it bytes from the file and it
keeps parsing until there's an error or an EOF.)

Post by Brian Gunlogson
When I was implementing the Commands hashing code (see below) I came
very near to supporting
non-menu keybindings. This won't be too difficult.

Agreed, it shouldn't be too hard.

Post by Brian Gunlogson
I am unsure of how to go about writing XML files (besides a memory
dump). Maybe Markus could aid in this area?

just as a text file, one line at a time, without any special code
to "validate" it for us. However, we may want to consider using
a class to encode special characters. Still, let's start by coding
it the same way we write .aup files - recursively, passing around
a "depth" for indentation.

Post by Brian Gunlogson
Has anyone implemented the Commands hashing code yet (to improve
speed)? I wrote a prototype that
compiled but it didn't work. Due to lack of
time/knowledge/documentation/examples I trashed the
code (I regret that now). How beneficial would it be? Does anyone
know
of any examples using
wxHashTable? Audacity uses hash maps which wxWindows says are
obsolete. I am recalling all of this
from memory, so I may be wrong.

Well, DirManager uses wxWindows' wxHashTable class, which isn't
great, but it's not horrible. For this use I think it would
be fine. The important thing is to use some sort of hashtable-like
API (actually I think the term is "Dictionary") and then we can
always swap in a better implementation later.
I've written some good hashtables before; if wxHashTable or one
of the newer wx hash classes doesn't cut it, I can write one.
Still, this is icing on the cake. Let's get the code to work
first and then optimize it.
Thanks for your feedback, Brian. I know that you've been busy - are
you able to help with any of this, especially since it's your code?
Feel free to say no, but I also want to give you first crack at it
if you're interested.
- Dominic

Post by Brian Gunlogson

Post by Dominic Mazzoni
1. It requires the ability to create a file (currently
called audacity-commands.xml) in order for Audacity to
launch. This can be a small annoyance because it's
not obvious where to put the file, and it "clutters"
the system for the 90% of users who will not ever
modify the file.
2. Currently every time we add a new menu command, the
audacity-commands.xml file is invalidated. That
limits its usefulness because users would have to
start from scratch every time they get a new
version.
3. The Keyboard pane in the Preferences is unfinished.
Here are the benefits of the current system that we would
1. The menus are created dynamically and can be changed
or rebuilt while the program is running. (Even if it
doesn't work perfectly now, most of the infrastructure
is there.)
2. The dispatching of commands / the CommandsCallback
system is very nice and in the future could be leveraged
to allow scriptability, etc.
3. Power users have a really nice way to add or change
keyboard shortcuts using their favorite text editor or
XML editor, without having to deal with any interface
that we would need to create.
4. People can share XML files with each other.
- I want to fix this situation without rewriting all of the
code involved. I like 90% of how Brian implemented the
menus/commands, and I don't want to toss it. I also don't
want to spend too much time on it; I want to focus on
usability and getting 1.2.0 finished within months, not
years.
1. In a nutshell, hardcode the menus and default keyboard
shortcuts into the program, but allow the user to load
keyboard shortcuts only from an XML file.
2. The menus could still be loaded from XML, but we would
just load directly from the hardcoded string.
3. If the user wants to modify the keyboard shortcuts, they
go to the Prefs and Save the current shortcuts. From
this panel they can also Load another existing set, or
click another button to Use Defaults. All of these
buttons should be written to take effect immediately
(or just after the Preferences dialog closes).
4. When you upgrade to a new version of Audacity, it starts
with the new Audacity menus. Then if the user had a
keyboard shortcuts file, it loads it and applies all of
the shortcuts that still make sense. It would be neat
if it "stole" shortcuts away from other menus.
5. As much as possible, let's try to make every action that
can be triggered in Audacity, with the exception of things
where the location of the mouse is significant (like
selecting, dragging) to be commands in CommandsCallback.
That way users can configure the key to press for Play,
Stop, Pause, ExtendSelectionRight, etc.
I hope that this is a reasonable compromise that will allow
version 1.2.0 to be complete and consistent, even if it
doesn't have every feature we ever dreamed of (like letting
users completely customize the menu layout).
I'd like to hear your thoughts, especially from Brian, since
he wrote most of this code. Also, Markus, if you're able to
work on this effort, that'd be great. I'll definitely do it
if nobody else does, over the next few weeks. Right now I'm
focusing on loading legacy project files.
- Dominic

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Brian Gunlogson]

The duplication isn't necessary. It was just done in an effort to keep similar items together.
Would you like me to place them in separate files? (I won't be creating any additional
duplications)

Brian Gunlogson

Post by Dominic Mazzoni
Excellent!
One last thing: if possible, let's try to avoid header files that
are included multiple times to mean different things. If that's
the only way to avoid code duplication, that's okay, but having
header files that do multiple things is making it difficult for
me to implement precompiled headers on the Mac.
- Dominic

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

[Dominic Mazzoni]

Post by Brian Gunlogson
The duplication isn't necessary. It was just done in an effort to keep similar items together.
Would you like me to place them in separate files? (I won't be creating any additional
duplications)

Sorry for the delay...yes, having them in separate files would be fine,
so that including one header file always means the same thing no matter
where you include it from.

- Dominic

Post by Brian Gunlogson
Brian Gunlogson

Post by Dominic Mazzoni
Excellent!
One last thing: if possible, let's try to avoid header files that
are included multiple times to mean different things. If that's
the only way to avoid code duplication, that's okay, but having
header files that do multiple things is making it difficult for
me to implement precompiled headers on the Mac.
- Dominic

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Dominic Mazzoni]

As I just mentioned, I'm starting to hack on the
Menus/Commands/Keys refactoring. Here's what I've come up
with so far:

1. I think I want to move the AudacityProject commands
(i.e. the callbacks) back into the main directory, in
Menus.h and Menus.cpp. The code to build the menu bar
will be there too.

2. In the commands/ directory, I'm going to refactor some
of Brian's classes so that they become generic classes
for building a menu bar, associating IDs with menus,
reading and writing XML files for keybindings, and
dispatching commands based on keypresses.

3. I'm calling the new main class in commands a
"CommandManager". Any other ideas? It dispatches
commands from menus and commands from keypresses.

4. Below, here is what some of the code to build the menu
bar and add some other commands will now look like.
I think it's about as clean as I could get it. It
requires more than 80 columns, sorry.

- Dominic

void AudacityProject::CreateMenusAndCommands()
{
CommandManager *c = &mCommandManager;

c->AddMenuBar("appmenu");

c->BeginMenu(_("&File"));
c->AddItem("New", _("&New\tCtrl+N"),
&OnNew);
c->AddItem("Open", _("&Open...\tCtrl+O"),
&OnOpen);
c->AddItem("Close", _("&Close\tCtrl+W"),
&OnClose);
c->AddItem("Save", _("&Save Project\tCtrl+S"),
&OnSave);
c->AddItem("SaveAs", _("Save Project &As..."),
&OnSaveAs);
c->AddSeparator();

...

c->BeginMenu(_("&Generate"));
c->AddItemList("ListName", namesArrayString, generateHandlerFunction);
c->EndMenu();

...

c->BeginMenu(_("&Help"));
c->AddItem("About" _("&About Audacity..."),
&OnAbout);
c->AddSeparator();
c->AddItem("Help", _("&Online Help..."), &OnHelp);
c->AddSeparator();
c->AddItem("Benchmark", _("&Run Benchmark..."),
&OnBenchmark);
c->EndMenu();

c->AddCommand("Play/Stop", _("Play/Stop\t "),
&OnPlayStop);
c->AddCommand("Stop", _("Stop\tS"), &OnStop);
c->AddCommand("Pause", _("Pause\tP"),
&OnPause);
c->AddCommand("Record", _("Record\tR"),
&OnRecord);
c->AddCommand("SkipStart", _("Skip to Start\tCtrl+Left"),
&OnSkipStart);
c->AddCommand("SkipEnd", _("Skip to End\tCtrl+Right"),
&OnSkipEnd);

c->AddCommand("CursorLeft", _("Cursor Left\tLeft"),
&OnCursorLeft);
c->AddCommand("CursorRight", _("Cursor Right\tRight"),
&OnCursorRight);

Post by Dominic Mazzoni
1. It requires the ability to create a file (currently
called audacity-commands.xml) in order for Audacity to
launch. This can be a small annoyance because it's
not obvious where to put the file, and it "clutters"
the system for the 90% of users who will not ever
modify the file.
2. Currently every time we add a new menu command, the
audacity-commands.xml file is invalidated. That
limits its usefulness because users would have to
start from scratch every time they get a new
version.
3. The Keyboard pane in the Preferences is unfinished.
Here are the benefits of the current system that we would
1. The menus are created dynamically and can be changed
or rebuilt while the program is running. (Even if it
doesn't work perfectly now, most of the infrastructure
is there.)
2. The dispatching of commands / the CommandsCallback
system is very nice and in the future could be leveraged
to allow scriptability, etc.
3. Power users have a really nice way to add or change
keyboard shortcuts using their favorite text editor or
XML editor, without having to deal with any interface
that we would need to create.
4. People can share XML files with each other.
- I want to fix this situation without rewriting all of the
code involved. I like 90% of how Brian implemented the
menus/commands, and I don't want to toss it. I also don't
want to spend too much time on it; I want to focus on
usability and getting 1.2.0 finished within months, not
years.
1. In a nutshell, hardcode the menus and default keyboard
shortcuts into the program, but allow the user to load
keyboard shortcuts only from an XML file.
2. The menus could still be loaded from XML, but we would
just load directly from the hardcoded string.
3. If the user wants to modify the keyboard shortcuts, they
go to the Prefs and Save the current shortcuts. From
this panel they can also Load another existing set, or
click another button to Use Defaults. All of these
buttons should be written to take effect immediately
(or just after the Preferences dialog closes).
4. When you upgrade to a new version of Audacity, it starts
with the new Audacity menus. Then if the user had a
keyboard shortcuts file, it loads it and applies all of
the shortcuts that still make sense. It would be neat
if it "stole" shortcuts away from other menus.
5. As much as possible, let's try to make every action that
can be triggered in Audacity, with the exception of things
where the location of the mouse is significant (like
selecting, dragging) to be commands in CommandsCallback.
That way users can configure the key to press for Play,
Stop, Pause, ExtendSelectionRight, etc.
I hope that this is a reasonable compromise that will allow
version 1.2.0 to be complete and consistent, even if it
doesn't have every feature we ever dreamed of (like letting
users completely customize the menu layout).
I'd like to hear your thoughts, especially from Brian, since
he wrote most of this code. Also, Markus, if you're able to
work on this effort, that'd be great. I'll definitely do it
if nobody else does, over the next few weeks. Right now I'm
focusing on loading legacy project files.
- Dominic

[Joshua Haberman]

Post by Dominic Mazzoni
2. In the commands/ directory, I'm going to refactor some
of Brian's classes so that they become generic classes
for building a menu bar, associating IDs with menus,
reading and writing XML files for keybindings, and
dispatching commands based on keypresses.

I still wish we could use the XRC system already written for use with
wxWindows. The main problem is that is isn't built as part of wxWindows
by default.

[Dominic Mazzoni]

Post by Joshua Haberman

Post by Dominic Mazzoni
2. In the commands/ directory, I'm going to refactor some
of Brian's classes so that they become generic classes
for building a menu bar, associating IDs with menus,
reading and writing XML files for keybindings, and
dispatching commands based on keypresses.

I still wish we could use the XRC system already written for use with
wxWindows. The main problem is that is isn't built as part of wxWindows
by default.

[Joshua Haberman]

Post by Joshua Haberman

Post by Dominic Mazzoni
2. In the commands/ directory, I'm going to refactor some
of Brian's classes so that they become generic classes
for building a menu bar, associating IDs with menus,
reading and writing XML files for keybindings, and
dispatching commands based on keypresses.

I still wish we could use the XRC system already written for use with
wxWindows. The main problem is that is isn't built as part of wxWindows
by default.

[Dominic Mazzoni]

See http://aspn.activestate.com/ASPN/Mail/Message/wxPython-users/1543249
Apparently you can generate a .po file from an .xrc file, and xrc will
automatically translate the resource when you load it!

Wow, that's really cool.

I'll definitely take a look at this. If the XRC code is "pure
wxWindows" (doesn't require any native code), then it should be
really easy to add it to lib-src...

- Dominic

Josh
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Dominic Mazzoni]

Josh,

At first glance it doesn't appear that there's going to be a
huge advantage to using XRC for menus. I'm working on adding
special support for dynamic menus and menus that contain
lists of similar items, which will simplify both the effect
code and submenus like "align". XRC wouldn't help with that
at all.

Another concern I have is that I don't want Audacity to fail
to load its menu bar if it can't find its XRC file.

But I can definitely see some advantages to using XRC for
dialogs, especially the prefsdialog.

- Dominic

Post by Joshua Haberman

Post by Dominic Mazzoni
2. In the commands/ directory, I'm going to refactor some
of Brian's classes so that they become generic classes
for building a menu bar, associating IDs with menus,
reading and writing XML files for keybindings, and
dispatching commands based on keypresses.

I still wish we could use the XRC system already written for use with
wxWindows. The main problem is that is isn't built as part of wxWindows
by default.

[Joshua Haberman]

Post by Dominic Mazzoni
Josh,
At first glance it doesn't appear that there's going to be a
huge advantage to using XRC for menus. I'm working on adding
special support for dynamic menus and menus that contain
lists of similar items, which will simplify both the effect
code and submenus like "align". XRC wouldn't help with that
at all.

If what you are doing is outside the scope of what XRC could reasonably
do, then that's fine. I was just hoping that we weren't spending time
reimplementing XRC. I was under the impression that some of the
commands code involved saving and loading custom XML files describing
the menus, and this would definitely be inside the scope of XRC.

What do you mean by "dynamic menus?" What would change about a menu
during runtime?

A side note: to organize LADSPA plugins in our effects menu, we should
use Steve Harris's liblrdf [0]. It allows applications to parse
metadata about the plugins so they can be reasonably arranged in an
application.

Post by Dominic Mazzoni
Another concern I have is that I don't want Audacity to fail
to load its menu bar if it can't find its XRC file.

I think you could generate a C++ source file from the default XRC file
that you could compile into your application to allow it to operate
without any external files.

Josh

[0] http://plugin.org.uk/releases/lrdf/

[Dominic Mazzoni]

Post by Joshua Haberman
What do you mean by "dynamic menus?" What would change about a menu
during runtime?

Some menus are currently dynamically created (as opposed to loaded
from a fixed file), like the Effects. Some of the menus could
benefit from that, like all of the Align options.

Post by Joshua Haberman
A side note: to organize LADSPA plugins in our effects menu, we should
use Steve Harris's liblrdf [0]. It allows applications to parse
metadata about the plugins so they can be reasonably arranged in an
application.

Sounds great.

Post by Joshua Haberman

Post by Dominic Mazzoni
Another concern I have is that I don't want Audacity to fail
to load its menu bar if it can't find its XRC file.

I think you could generate a C++ source file from the default XRC file
that you could compile into your application to allow it to operate
without any external files.

Let's consider doing this if we end up using XRC for dialogs.
I like the idea that the Audacity executable is almost completely
functional without any support files.

- Dominic

Post by Joshua Haberman
Josh
[0] http://plugin.org.uk/releases/lrdf/
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Dominic Mazzoni]

I'm trying to make some of the Commands classes store
function pointers but have them be generic enough that
they don't need to know what an AudacityProject is.

Does anyone know how to:

1. Represent a method as a generic type - i.e. is there
any C++ type that is compatible with this type:

void (AudacityProject::*) ()

2. Or, how to cast one of those to a void *? When I try:

void *p = (void *)(&AudacityProject::OnNew)

I get an error message:

converting from `void (AudacityProject::*) ()' to `void *'

- Dominic

Post by Dominic Mazzoni
As I just mentioned, I'm starting to hack on the
Menus/Commands/Keys refactoring. Here's what I've come up
1. I think I want to move the AudacityProject commands
(i.e. the callbacks) back into the main directory, in
Menus.h and Menus.cpp. The code to build the menu bar
will be there too.
2. In the commands/ directory, I'm going to refactor some
of Brian's classes so that they become generic classes
for building a menu bar, associating IDs with menus,
reading and writing XML files for keybindings, and
dispatching commands based on keypresses.
3. I'm calling the new main class in commands a
"CommandManager". Any other ideas? It dispatches
commands from menus and commands from keypresses.
4. Below, here is what some of the code to build the menu
bar and add some other commands will now look like.
I think it's about as clean as I could get it. It
requires more than 80 columns, sorry.
- Dominic
void AudacityProject::CreateMenusAndCommands()
{
CommandManager *c = &mCommandManager;
c->AddMenuBar("appmenu");
c->BeginMenu(_("&File"));
c->AddItem("New", _("&New\tCtrl+N"), &OnNew);
c->AddItem("Open", _("&Open...\tCtrl+O"), &OnOpen);
c->AddItem("Close", _("&Close\tCtrl+W"), &OnClose);
c->AddItem("Save", _("&Save Project\tCtrl+S"), &OnSave);
c->AddItem("SaveAs", _("Save Project &As..."), &OnSaveAs);
c->AddSeparator();
...
c->BeginMenu(_("&Generate"));
c->AddItemList("ListName", namesArrayString, generateHandlerFunction);
c->EndMenu();
...
c->BeginMenu(_("&Help"));
c->AddItem("About" _("&About Audacity..."), &OnAbout);
c->AddSeparator();
c->AddItem("Help", _("&Online Help..."), &OnHelp);
c->AddSeparator();
c->AddItem("Benchmark", _("&Run Benchmark..."), &OnBenchmark);
c->EndMenu();
c->AddCommand("Play/Stop", _("Play/Stop\t "), &OnPlayStop);
c->AddCommand("Stop", _("Stop\tS"), &OnStop);
c->AddCommand("Pause", _("Pause\tP"), &OnPause);
c->AddCommand("Record", _("Record\tR"), &OnRecord);
c->AddCommand("SkipStart", _("Skip to Start\tCtrl+Left"),
&OnSkipStart);
c->AddCommand("SkipEnd", _("Skip to End\tCtrl+Right"), &OnSkipEnd);
c->AddCommand("CursorLeft", _("Cursor Left\tLeft"), &OnCursorLeft);
c->AddCommand("CursorRight", _("Cursor Right\tRight"), &OnCursorRight);

Post by Dominic Mazzoni
1. It requires the ability to create a file (currently
called audacity-commands.xml) in order for Audacity to
launch. This can be a small annoyance because it's
not obvious where to put the file, and it "clutters"
the system for the 90% of users who will not ever
modify the file.
2. Currently every time we add a new menu command, the
audacity-commands.xml file is invalidated. That
limits its usefulness because users would have to
start from scratch every time they get a new
version.
3. The Keyboard pane in the Preferences is unfinished.
Here are the benefits of the current system that we would
1. The menus are created dynamically and can be changed
or rebuilt while the program is running. (Even if it
doesn't work perfectly now, most of the infrastructure
is there.)
2. The dispatching of commands / the CommandsCallback
system is very nice and in the future could be leveraged
to allow scriptability, etc.
3. Power users have a really nice way to add or change
keyboard shortcuts using their favorite text editor or
XML editor, without having to deal with any interface
that we would need to create.
4. People can share XML files with each other.
- I want to fix this situation without rewriting all of the
code involved. I like 90% of how Brian implemented the
menus/commands, and I don't want to toss it. I also don't
want to spend too much time on it; I want to focus on
usability and getting 1.2.0 finished within months, not
years.
1. In a nutshell, hardcode the menus and default keyboard
shortcuts into the program, but allow the user to load
keyboard shortcuts only from an XML file.
2. The menus could still be loaded from XML, but we would
just load directly from the hardcoded string.
3. If the user wants to modify the keyboard shortcuts, they
go to the Prefs and Save the current shortcuts. From
this panel they can also Load another existing set, or
click another button to Use Defaults. All of these
buttons should be written to take effect immediately
(or just after the Preferences dialog closes).
4. When you upgrade to a new version of Audacity, it starts
with the new Audacity menus. Then if the user had a
keyboard shortcuts file, it loads it and applies all of
the shortcuts that still make sense. It would be neat
if it "stole" shortcuts away from other menus.
5. As much as possible, let's try to make every action that
can be triggered in Audacity, with the exception of things
where the location of the mouse is significant (like
selecting, dragging) to be commands in CommandsCallback.
That way users can configure the key to press for Play,
Stop, Pause, ExtendSelectionRight, etc.
I hope that this is a reasonable compromise that will allow
version 1.2.0 to be complete and consistent, even if it
doesn't have every feature we ever dreamed of (like letting
users completely customize the menu layout).
I'd like to hear your thoughts, especially from Brian, since
he wrote most of this code. Also, Markus, if you're able to
work on this effort, that'd be great. I'll definitely do it
if nobody else does, over the next few weeks. Right now I'm
focusing on loading legacy project files.
- Dominic

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Dominic Mazzoni]

Answering my own questions...

I'd be curious if anyone has any other ideas still, but
I think that the right solution (better because it's
typesafe) is to use a simple functor (an object that
acts like a function).

- Dominic

Post by Dominic Mazzoni
I'm trying to make some of the Commands classes store
function pointers but have them be generic enough that
they don't need to know what an AudacityProject is.
1. Represent a method as a generic type - i.e. is there
void (AudacityProject::*) ()
void *p = (void *)(&AudacityProject::OnNew)
converting from `void (AudacityProject::*) ()' to `void *'
- Dominic

Post by Dominic Mazzoni
As I just mentioned, I'm starting to hack on the
Menus/Commands/Keys refactoring. Here's what I've come up
1. I think I want to move the AudacityProject commands
(i.e. the callbacks) back into the main directory, in
Menus.h and Menus.cpp. The code to build the menu bar
will be there too.
2. In the commands/ directory, I'm going to refactor some
of Brian's classes so that they become generic classes
for building a menu bar, associating IDs with menus,
reading and writing XML files for keybindings, and
dispatching commands based on keypresses.
3. I'm calling the new main class in commands a
"CommandManager". Any other ideas? It dispatches
commands from menus and commands from keypresses.
4. Below, here is what some of the code to build the menu
bar and add some other commands will now look like.
I think it's about as clean as I could get it. It
requires more than 80 columns, sorry.
- Dominic
void AudacityProject::CreateMenusAndCommands()
{
CommandManager *c = &mCommandManager;
c->AddMenuBar("appmenu");
c->BeginMenu(_("&File"));
c->AddItem("New", _("&New\tCtrl+N"), &OnNew);
c->AddItem("Open", _("&Open...\tCtrl+O"), &OnOpen);
c->AddItem("Close", _("&Close\tCtrl+W"), &OnClose);
c->AddItem("Save", _("&Save Project\tCtrl+S"), &OnSave);
c->AddItem("SaveAs", _("Save Project &As..."), &OnSaveAs);
c->AddSeparator();
...
c->BeginMenu(_("&Generate"));
c->AddItemList("ListName", namesArrayString, generateHandlerFunction);
c->EndMenu();
...
c->BeginMenu(_("&Help"));
c->AddItem("About" _("&About Audacity..."), &OnAbout);
c->AddSeparator();
c->AddItem("Help", _("&Online Help..."),
&OnHelp);
c->AddSeparator();
c->AddItem("Benchmark", _("&Run Benchmark..."), &OnBenchmark);
c->EndMenu();
c->AddCommand("Play/Stop", _("Play/Stop\t "), &OnPlayStop);
c->AddCommand("Stop", _("Stop\tS"),
&OnStop);
c->AddCommand("Pause", _("Pause\tP"), &OnPause);
c->AddCommand("Record", _("Record\tR"), &OnRecord);
c->AddCommand("SkipStart", _("Skip to Start\tCtrl+Left"),
&OnSkipStart);
c->AddCommand("SkipEnd", _("Skip to End\tCtrl+Right"),
&OnSkipEnd);
c->AddCommand("CursorLeft", _("Cursor Left\tLeft"), &OnCursorLeft);
c->AddCommand("CursorRight", _("Cursor Right\tRight"),
&OnCursorRight);

Post by Dominic Mazzoni
1. It requires the ability to create a file (currently
called audacity-commands.xml) in order for Audacity to
launch. This can be a small annoyance because it's
not obvious where to put the file, and it "clutters"
the system for the 90% of users who will not ever
modify the file.
2. Currently every time we add a new menu command, the
audacity-commands.xml file is invalidated. That
limits its usefulness because users would have to
start from scratch every time they get a new
version.
3. The Keyboard pane in the Preferences is unfinished.
Here are the benefits of the current system that we would
1. The menus are created dynamically and can be changed
or rebuilt while the program is running. (Even if it
doesn't work perfectly now, most of the infrastructure
is there.)
2. The dispatching of commands / the CommandsCallback
system is very nice and in the future could be leveraged
to allow scriptability, etc.
3. Power users have a really nice way to add or change
keyboard shortcuts using their favorite text editor or
XML editor, without having to deal with any interface
that we would need to create.
4. People can share XML files with each other.
- I want to fix this situation without rewriting all of the
code involved. I like 90% of how Brian implemented the
menus/commands, and I don't want to toss it. I also don't
want to spend too much time on it; I want to focus on
usability and getting 1.2.0 finished within months, not
years.
1. In a nutshell, hardcode the menus and default keyboard
shortcuts into the program, but allow the user to load
keyboard shortcuts only from an XML file.
2. The menus could still be loaded from XML, but we would
just load directly from the hardcoded string.
3. If the user wants to modify the keyboard shortcuts, they
go to the Prefs and Save the current shortcuts. From
this panel they can also Load another existing set, or
click another button to Use Defaults. All of these
buttons should be written to take effect immediately
(or just after the Preferences dialog closes).
4. When you upgrade to a new version of Audacity, it starts
with the new Audacity menus. Then if the user had a
keyboard shortcuts file, it loads it and applies all of
the shortcuts that still make sense. It would be neat
if it "stole" shortcuts away from other menus.
5. As much as possible, let's try to make every action that
can be triggered in Audacity, with the exception of things
where the location of the mouse is significant (like
selecting, dragging) to be commands in CommandsCallback.
That way users can configure the key to press for Play,
Stop, Pause, ExtendSelectionRight, etc.
I hope that this is a reasonable compromise that will allow
version 1.2.0 to be complete and consistent, even if it
doesn't have every feature we ever dreamed of (like letting
users completely customize the menu layout).
I'd like to hear your thoughts, especially from Brian, since
he wrote most of this code. Also, Markus, if you're able to
work on this effort, that'd be great. I'll definitely do it
if nobody else does, over the next few weeks. Right now I'm
focusing on loading legacy project files.
- Dominic

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Joshua Haberman]

Post by Dominic Mazzoni
I'm trying to make some of the Commands classes store
function pointers but have them be generic enough that
they don't need to know what an AudacityProject is.
1. Represent a method as a generic type - i.e. is there
void (AudacityProject::*) ()

[Dominic Mazzoni]

Thanks to both Josh and Matt for the answers.

I think that creating a very simple object to encapsulate the
method call (i.e. a functor) will work well.

- Dominic

Post by Dominic Mazzoni
I'm trying to make some of the Commands classes store
function pointers but have them be generic enough that
they don't need to know what an AudacityProject is.
1. Represent a method as a generic type - i.e. is there
void (AudacityProject::*) ()

[Dominic Mazzoni]

I just committed a major refactoring of the Menus/Commands/Keys code.
All of the necessary functionality is working.

To compile on Windows, you'll need to remove all of the current files
in commands/, add commands/Keyboard.cpp and commands/CommandManager.cpp,
and add Menus.cpp and SelectionFormat.cpp from the main directory.

Quick summary:

CommandsManager is a generic class that doesn't know anything about
AudacityProjects. It can construct menu bars with an interface
almost identical to the one Brian came up with, plus you can add
other commands that don't appear in the menu (but can contain
keyboard shortcuts). To simplify things, you can now add a whole
list of menu items at once; if any of them is called, you get a
callback with an integer parameter indicating the index number.
This interface is now being used for all Effects, the Align
items, and the Selection Format items. (I was able to cut out
hundreds of lines of duplicated code with this.)

Anyway, I'm very happy with how this turned out. I was able to
re-use lots of Brian's code, but learned from the experience and
I think I came up with an even more flexible and clean system.
I still intend to support keyboard shortcuts in XML files, just
to be clear.

Specifics:

- Everything that was in the menu bar before should function as
before. Please tell me if you discover any exceptions.
- Keyboard shortcuts for menus work.
- The Align submenus were completely refactored and the code is
about 1/10 the size it was before, with minimal loss in
functionality. Let me know if you have any complaints or it
doesn't meet your needs any more.
- The Selection Format and Snap-To Mode options are now in the
View menu. The code is completely out of TrackPanel, finally!
I tested it briefly; please let me know if you see any problems.
- Keyboard shortcuts for Audio I/O (' ', 'P', 'R', 'S') and
cursor editing (arrow keys) have been implemented using this
new system. They should now work no matter what window has the
focus.
- CommandsManager now uses wxHashMaps, so looking up IDs
and keyboard shortcuts is now very fast.

What is still broken/missing:

- No ability to edit keyboard shortcuts anymore - I'm going to
try to add this back soon.
- TrackPanel still has a few keyboards shortcuts that should be
migrated to the new system
- Enabling/Disabling menu items hasn't been rewritten - this
should be easy but I just haven't done it yet.
- Need to implement check marks next to menu items - let me know
if anyone wants to add this to CommandManager.
- Need to implement saving/loading of custom keyboard shortcuts.
- Organize LADSPA plug-ins according to their categorization.
Possibly this should go in a separate LADSPA menu?

[Vaughan Johnson]

Post by Dominic Mazzoni
I just committed a major refactoring of the Menus/Commands/Keys code.
All of the necessary functionality is working.
To compile on Windows, you'll need to remove all of the current files
in commands/, add commands/Keyboard.cpp and commands/CommandManager.cpp,
and add Menus.cpp and SelectionFormat.cpp from the main directory.
...

I don't find SelectionFormat.* in CVS.
-Vaughan

[Dominic Mazzoni]

Post by Vaughan Johnson

Post by Dominic Mazzoni
I just committed a major refactoring of the Menus/Commands/Keys code.
All of the necessary functionality is working.
To compile on Windows, you'll need to remove all of the current files
in commands/, add commands/Keyboard.cpp and commands/CommandManager.cpp,
and add Menus.cpp and SelectionFormat.cpp from the main directory.
...

I don't find SelectionFormat.* in CVS.

Sorry, I guess I named the file FormatSelection.cpp! :) That's in CVS.

Post by Vaughan Johnson
-Vaughan
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Vaughan Johnson]

Post by Dominic Mazzoni

Post by Vaughan Johnson

Post by Dominic Mazzoni
I just committed a major refactoring of the Menus/Commands/Keys code.
All of the necessary functionality is working.
To compile on Windows, you'll need to remove all of the current files
in commands/, add commands/Keyboard.cpp and
commands/CommandManager.cpp,
and add Menus.cpp and SelectionFormat.cpp from the main directory.
...

I don't find SelectionFormat.* in CVS.

Sorry, I guess I named the file FormatSelection.cpp! :) That's in CVS.

Yep, it sure is. Sorry I didn't look around more. Builds fine now. Will
check in the updated audacity.dsp in a little while, with some
pitch-related stuff I'm finishing up.

-Vaughan

[Dominic Mazzoni]

Post by Vaughan Johnson
Yep, it sure is. Sorry I didn't look around more. Builds fine now. Will
check in the updated audacity.dsp in a little while, with some
pitch-related stuff I'm finishing up.

Great! Looking forward to having the pitch stuff completed!

Post by Vaughan Johnson
-Vaughan

[Dominic Mazzoni]

I added the ability to edit keyboard shortcuts directly in the
Preferences dialog again. Unlike in previous versions, it
will now only store the preference if the shortcut is different
than the default. This will make it possible for us to rearrange
shortcuts in the future with less hassle.

For some reason, I can't get it to change the main menu bar when
you close the dialog. The menus do change the next time you
open the program. Please take a look if you have any ideas.

- Dominic

[Vaughan Johnson]

Post by Vaughan Johnson

Post by Dominic Mazzoni

Post by Vaughan Johnson

Post by Dominic Mazzoni
I just committed a major refactoring of the Menus/Commands/Keys code.
All of the necessary functionality is working.
To compile on Windows, you'll need to remove all of the current files
in commands/, add commands/Keyboard.cpp and
commands/CommandManager.cpp,
and add Menus.cpp and SelectionFormat.cpp from the main directory.
...

I don't find SelectionFormat.* in CVS.

Sorry, I guess I named the file FormatSelection.cpp! :) That's in CVS.

Yep, it sure is. Sorry I didn't look around more. Builds fine now.
Will check in the updated audacity.dsp in a little while, with some
pitch-related stuff I'm finishing up.

Well, it builds fine, but I'm getting lots of access violations,
prominently in , and I didn't notice them until I'd done a bunch of
changes to Change Pitch, whose textCtrls are now behaving weirdly.
Probably unrelated, but I need more time to figure both out. Definitely,
it's not the Change Pitch code causing the other problems, because if I
just open Audacity, record a few seconds, then exit, I get an unhandled
exception, or a debug assertion, or... (it seems inconsistent). So, I
just checked in the .dsp file, so at least it builds on Windows. More soon.

-Vaughan

[Dominic Mazzoni]

Post by Dominic Mazzoni
- Enabling/Disabling menu items hasn't been rewritten - this
should be easy but I just haven't done it yet.

Done.

- Dominic

[Matt Brubeck]

Post by Dominic Mazzoni
void *p = (void *)(&AudacityProject::OnNew)
converting from `void (AudacityProject::*) ()' to `void *'

See the "Pointers to member functions" FAQ:

http://www.parashift.com/c++-faq-lite/pointers-to-members.html

Since OnNew is non-static, it requires an AudacityProject instance to
passed as the "this" argument. Your code will probably need to be at
least somewhat aware of AudacityProjects.

One solution would be to create a function object (a class with
operator() defined), which could store a pointer to an AudacityProject
and act as a proxy for member function calls to that object. I think
that Stroustrup demonstrates this approact in The C++ Programming
Language, but my copy has been shipped to my new house in Seattle, so I
can't look it up right now.

[Greg Mekkes]

Post by Dominic Mazzoni
I just committed a major refactoring of the Menus/Commands/Keys code.
All of the necessary functionality is working.
...
- The Align submenus were completely refactored and the code is
about 1/10 the size it was before, with minimal loss in
functionality. Let me know if you have any complaints or it
doesn't meet your needs any more.

At first I thought you had removed the Align Group functions, but I see
that you have made the align functions work on a group by default for
multiple selected wave tracks. Very interesting - great way to save
screen real estate, my align menus covered a couple acres when unfurled :)

Post by Dominic Mazzoni
- The Selection Format and Snap-To Mode options are now in the
View menu. The code is completely out of TrackPanel, finally!
I tested it briefly; please let me know if you see any problems.

There were a couple little details that are now in cvs - no more invalid
iformat statement, and the printed comments are a bit more consistent
with how you re-did the menus. New versions of FormatSelection.cpp/.h

Greg

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com