Audacity

Hi LRN, 

see below... 


| From LRN <lrn1986@...> 
| Sun, 17 Jan 2010 18:14:48 +0300
| Subject: Exporting multiple MP3 files with FFMpeg
> On 17.01.2010 16:25, Gale Andrews wrote:
> > | From Steve the Fiddle 
> > | Sat, 16 Jan 2010 17:39:55 +0000
> > | Subject: Exporting multiple MP3 files with FFMpeg
> >   
> >> A user has recently reported that on their machine FFMpeg import of MP3s 
> >> is about 2x faster than the standard MP3 import method so they would 
> >> like to use FFMpeg when importing multiple files. However, when 
> >> importing multiple files and selecting "FFMpeg compatible files", the 
> >> first MP3 file is imported using FFMpeg, but every other file uses the 
> >> normal Audacity file import method.
> >>
> >> I have suggested renaming the files with a .MPG extension (which works). 
> >> Nevertheless, this behaviour seems a little odd and is perhaps an oversight.
> >> http://forum.audacityteam.org/viewtopic.php?f=16&t=22255&p=68137#p68137
> >>
> >> Steve
> >>     
> > Thanks for passing the report on. 
> >
> > My assumption is that the behaviour switching away from FFmpeg after the
> > first import was introduced in 1.3.9 when we fixed a crash importing a
> > file by drag or recent files where the format differed from that set by
> > the filter in the window. I've commented in situ:
> > http://forum.audacityteam.org/viewtopic.php?f=16&t=22255&p=68248#p68248
> >
> >   
> Yes, that is because the general importer does
> gPrefs->Write(wxT("/LastOpenType"),wxT(""));
> after
> wxString type = gPrefs->Read(wxT("/LastOpenType"),wxT(""));
> 
> I think it is easily fixable by moving
> gPrefs->Write(wxT("/LastOpenType"),wxT(""));
> somewhere lower on the stack.
> Diff attached (tested - compiles OK and works as intended; It might be
> necessary to make Audacity show OpenFileDialog once before starting to
> drag'n'drop files, to clear the LastOpenType setting). CC'ing to devel-
> I still think that passing valuable data via gPrefs is bad, but doing it
> the other way (passing extra arguments around) is going to be even
> worse, i think.

I've had this fix in the Windows Nightly for some time. It fixes the problem 
of unwanted switching to native import when multiple-importing files via
File > Open or File > Import using FFmpeg.  However, using File > Recent
Files, dragging in or using Explorer "Open With" still always uses the native
importer for me on Windows XP, however many times I first of all import 
via File > Import using FFmpeg. Any thoughts? 

 
> > and Cc'd to LRN. Perhaps he will also have some comment about the speed
> > differences when importing. 
> >   
> What can i say, FFmpeg stands for "Fast Forward mpeg". It's fast. Though
> i can't tell you whether that leads to quality degradation or not. You
> could try to import the same file via Audacity's importer (libmad, isn't
> it?) and via libavcodec, invert one of them, then mix them together and
> see the difference.
> 
> Actually, i just did that. Dismissing the alignment problems (fixed them
> by shifting one of the tracks) two tracks were identical. Though this is
> only one file, maybe there is a difference when special files are
> imported (joint stereo, for example).

Interesting to see that libmad and libavcodec give similar results. But
what I was really asking was why the situation was reversed on Ubuntu,
where FFmpeg is twice as slow importing MP3s compared to the native 
importer.



Thanks 


Gale

On 03.03.2010 7:25, Gale Andrews wrote:
> Hi LRN, 
>
> see below... 
>
>
> | From LRN <lrn1986@...> 
> | Sun, 17 Jan 2010 18:14:48 +0300
> | Subject: Exporting multiple MP3 files with FFMpeg
>   
>> On 17.01.2010 16:25, Gale Andrews wrote:
>>     
>>> | From Steve the Fiddle 
>>> | Sat, 16 Jan 2010 17:39:55 +0000
>>> | Subject: Exporting multiple MP3 files with FFMpeg
>>>   
>>>       
>>>> A user has recently reported that on their machine FFMpeg import of MP3s 
>>>> is about 2x faster than the standard MP3 import method so they would 
>>>> like to use FFMpeg when importing multiple files. However, when 
>>>> importing multiple files and selecting "FFMpeg compatible files", the 
>>>> first MP3 file is imported using FFMpeg, but every other file uses the 
>>>> normal Audacity file import method.
>>>>
>>>> I have suggested renaming the files with a .MPG extension (which works). 
>>>> Nevertheless, this behaviour seems a little odd and is perhaps an oversight.
>>>> http://forum.audacityteam.org/viewtopic.php?f=16&t=22255&p=68137#p68137
>>>>
>>>> Steve
>>>>     
>>>>         
>>> Thanks for passing the report on. 
>>>
>>> My assumption is that the behaviour switching away from FFmpeg after the
>>> first import was introduced in 1.3.9 when we fixed a crash importing a
>>> file by drag or recent files where the format differed from that set by
>>> the filter in the window. I've commented in situ:
>>> http://forum.audacityteam.org/viewtopic.php?f=16&t=22255&p=68248#p68248
>>>
>>>   
>>>       
>> Yes, that is because the general importer does
>> gPrefs->Write(wxT("/LastOpenType"),wxT(""));
>> after
>> wxString type = gPrefs->Read(wxT("/LastOpenType"),wxT(""));
>>
>> I think it is easily fixable by moving
>> gPrefs->Write(wxT("/LastOpenType"),wxT(""));
>> somewhere lower on the stack.
>> Diff attached (tested - compiles OK and works as intended; It might be
>> necessary to make Audacity show OpenFileDialog once before starting to
>> drag'n'drop files, to clear the LastOpenType setting). CC'ing to devel-
>> I still think that passing valuable data via gPrefs is bad, but doing it
>> the other way (passing extra arguments around) is going to be even
>> worse, i think.
>>     
> I've had this fix in the Windows Nightly for some time. It fixes the problem 
> of unwanted switching to native import when multiple-importing files via
> File > Open or File > Import using FFmpeg.  However, using File > Recent
> Files, dragging in or using Explorer "Open With" still always uses the native
> importer for me on Windows XP, however many times I first of all import 
> via File > Import using FFmpeg. Any thoughts?
At this moment i don't remember whether this is the way i intended it to
work or not (i'll take a look this evening).
Right now the only thing i can do is ask: isn't it a bit awkward that
Audacity automatically used the last import filter you happened to use?
This was unobvious (was it even documented anywhere?) and highly
unintuitive, IMO.
Back in the days i had an idea of a preferences section that allowed one
to change the order in which import filters are checked for
compatibility with the file being imported - that would have solved the
problem of hard-coding native importer to be of highest priority than
libavcodec or using unobvious heuristics like LastOpenType. But it would
have been unflexible. Or maybe the problem is that there are two
distinct importers with overlapping functionality, which is confusing by
itself, not to mention that there seems to be no simple/easy way to
specify which one you want to use.
Users would (reasonably) expect Audacity to "just open the goddamn file"
the best way it could, without having to decide which importer to use
(implying that when there is a choice, the developers can choose the
best option and implement it, instead of implementing both and giving
the choice to users).
Well, i'll look at it anyway and will try to make it consistently use
the heuristic.
>  
>
>  
>   
>>> and Cc'd to LRN. Perhaps he will also have some comment about the speed
>>> differences when importing. 
>>>   
>>>       
>> What can i say, FFmpeg stands for "Fast Forward mpeg". It's fast. Though
>> i can't tell you whether that leads to quality degradation or not. You
>> could try to import the same file via Audacity's importer (libmad, isn't
>> it?) and via libavcodec, invert one of them, then mix them together and
>> see the difference.
>>
>> Actually, i just did that. Dismissing the alignment problems (fixed them
>> by shifting one of the tracks) two tracks were identical. Though this is
>> only one file, maybe there is a difference when special files are
>> imported (joint stereo, for example).
>>     
> Interesting to see that libmad and libavcodec give similar results. But
> what I was really asking was why the situation was reversed on Ubuntu,
> where FFmpeg is twice as slow importing MP3s compared to the native 
> importer.
>   
No idea.

| From LRN <lrn1986@...> 
| Wed, 03 Mar 2010 09:09:13 +0300
| Subject: [Audacity-quality] [Audacity-devel] Importing multiple MP3 files with 
| FFMpeg WAS: Re: Exporting multiple MP3 files with FFMpeg
> On 03.03.2010 7:25, Gale Andrews wrote:
> > | From LRN <lrn1986@...> 
> > | Sun, 17 Jan 2010 18:14:48 +0300
> > | Subject: Exporting multiple MP3 files with FFMpeg
> >   
> >> On 17.01.2010 16:25, Gale Andrews wrote:
> >>     
> >>> | From Steve the Fiddle 
> >>> | Sat, 16 Jan 2010 17:39:55 +0000
> >>> | Subject: Exporting multiple MP3 files with FFMpeg
> >>>   
> >>>       
> >>>> A user has recently reported that on their machine FFMpeg import of MP3s 
> >>>> is about 2x faster than the standard MP3 import method so they would 
> >>>> like to use FFMpeg when importing multiple files. However, when 
> >>>> importing multiple files and selecting "FFMpeg compatible files", the 
> >>>> first MP3 file is imported using FFMpeg, but every other file uses the 
> >>>> normal Audacity file import method.
> >>>
> >>> ... My assumption is that the behaviour switching away from FFmpeg after the
> >>> first import was introduced in 1.3.9 when we fixed a crash importing a
> >>> file by drag or recent files where the format differed from that set by
> >>> the filter in the window. I've commented in situ:
> >>> http://forum.audacityteam.org/viewtopic.php?f=16&t=22255&p=68248#p68248
> >>>
> >> Yes, that is because the general importer does
> >> gPrefs->Write(wxT("/LastOpenType"),wxT(""));
> >> after
> >> wxString type = gPrefs->Read(wxT("/LastOpenType"),wxT(""));
> >>
> >> I think it is easily fixable by moving
> >> gPrefs->Write(wxT("/LastOpenType"),wxT(""));
> >> somewhere lower on the stack.
> >> Diff attached (tested - compiles OK and works as intended; It might be
> >> necessary to make Audacity show OpenFileDialog once before starting to
> >> drag'n'drop files, to clear the LastOpenType setting). CC'ing to devel-
> >> I still think that passing valuable data via gPrefs is bad, but doing it
> >> the other way (passing extra arguments around) is going to be even
> >> worse, i think.
> >>     
> > I've had this fix in the Windows Nightly for some time. It fixes the problem 
> > of unwanted switching to native import when multiple-importing files via
> > File > Open or File > Import using FFmpeg.  However, using File > Recent
> > Files, dragging in or using Explorer "Open With" still always uses the native
> > importer for me on Windows XP, however many times I first of all import 
> > via File > Import using FFmpeg. Any thoughts?
> 
> At this moment i don't remember whether this is the way i intended it to
> work or not (i'll take a look this evening).
>
> Right now the only thing i can do is ask: isn't it a bit awkward that
> Audacity automatically used the last import filter you happened to use?
> This was unobvious (was it even documented anywhere?) and highly
> unintuitive, IMO.
> 
> Back in the days i had an idea of a preferences section that allowed one
> to change the order in which import filters are checked for
> compatibility with the file being imported - that would have solved the
> problem of hard-coding native importer to be of highest priority than
> libavcodec or using unobvious heuristics like LastOpenType. But it would
> have been unflexible. Or maybe the problem is that there are two
> distinct importers with overlapping functionality, which is confusing by
> itself, not to mention that there seems to be no simple/easy way to
> specify which one you want to use.
>
> Users would (reasonably) expect Audacity to "just open the goddamn file"
> the best way it could, without having to decide which importer to use
> (implying that when there is a choice, the developers can choose the
> best option and implement it, instead of implementing both and giving
> the choice to users).

Yes, I think the key is that there is no easy way to specify which
importer you want to use, and that builds an expectation that 
Audacity will use the current one when the import method means 
you can't access the open or import window. And this expectation 
is fuelled by the Manual:

    "When "All files" or "All supported files" is chosen in the file
     types dropdown inside the file selection window, Audacity will
     automatically select the most appropriate importer for your file. 
     A "native" format like WAV or MP3 will therefore use the built-in
     importer for that format. If this importer fails to open the file,
     FFmpeg will be used instead. To force Audacity to import a native
     file format using FFmpeg, choose "FFmpeg-compatible files" in the
     file types dropdown. This will disable On-Demand Loading for WAV
     and AIFF files." 

That isn't now what happens (unless you read that as meaning "only if
you actually use File > Open or > Import"). 

People do seem to have various reasons for wanting to use FFmpeg
even for native formats, and I have several people pulling my ear
about this as well as the Forum complainant. 

Anyway, I have it as a "Review" P3 at the moment:
http://bugzilla.audacityteam.org/show_bug.cgi?id=140



Thanks


Gale 



> Well, i'll look at it anyway and will try to make it consistently use
> the heuristic.
> >  
> >
> >  
> >   
> >>> and Cc'd to LRN. Perhaps he will also have some comment about the speed
> >>> differences when importing. 
> >>>   
> >>>       
> >> What can i say, FFmpeg stands for "Fast Forward mpeg". It's fast. Though
> >> i can't tell you whether that leads to quality degradation or not. You
> >> could try to import the same file via Audacity's importer (libmad, isn't
> >> it?) and via libavcodec, invert one of them, then mix them together and
> >> see the difference.
> >>
> >> Actually, i just did that. Dismissing the alignment problems (fixed them
> >> by shifting one of the tracks) two tracks were identical. Though this is
> >> only one file, maybe there is a difference when special files are
> >> imported (joint stereo, for example).
> >>     
> > Interesting to see that libmad and libavcodec give similar results. But
> > what I was really asking was why the situation was reversed on Ubuntu,
> > where FFmpeg is twice as slow importing MP3s compared to the native 
> > importer.
> >   
> No idea.

On 03.03.2010 14:49, Gale Andrews wrote:
> | From LRN <lrn1986@...> 
> | Wed, 03 Mar 2010 09:09:13 +0300
> | Subject: [Audacity-quality] [Audacity-devel] Importing multiple MP3 files with 
> | FFMpeg WAS: Re: Exporting multiple MP3 files with FFMpeg
>   
>> On 03.03.2010 7:25, Gale Andrews wrote:
>>     
>>> | From LRN <lrn1986@...> 
>>> | Sun, 17 Jan 2010 18:14:48 +0300
>>> | Subject: Exporting multiple MP3 files with FFMpeg
>>>   
>>>       
>>>> On 17.01.2010 16:25, Gale Andrews wrote:
>>>>     
>>>>         
>>>>> | From Steve the Fiddle 
>>>>> | Sat, 16 Jan 2010 17:39:55 +0000
>>>>> | Subject: Exporting multiple MP3 files with FFMpeg
>>>>>   
>>>>>       
>>>>>           
>>>>>> A user has recently reported that on their machine FFMpeg import of MP3s 
>>>>>> is about 2x faster than the standard MP3 import method so they would 
>>>>>> like to use FFMpeg when importing multiple files. However, when 
>>>>>> importing multiple files and selecting "FFMpeg compatible files", the 
>>>>>> first MP3 file is imported using FFMpeg, but every other file uses the 
>>>>>> normal Audacity file import method.
>>>>>>             
>>>>> ... My assumption is that the behaviour switching away from FFmpeg after the
>>>>> first import was introduced in 1.3.9 when we fixed a crash importing a
>>>>> file by drag or recent files where the format differed from that set by
>>>>> the filter in the window. I've commented in situ:
>>>>> http://forum.audacityteam.org/viewtopic.php?f=16&t=22255&p=68248#p68248
>>>>>
>>>>>           
>>>> Yes, that is because the general importer does
>>>> gPrefs->Write(wxT("/LastOpenType"),wxT(""));
>>>> after
>>>> wxString type = gPrefs->Read(wxT("/LastOpenType"),wxT(""));
>>>>
>>>> I think it is easily fixable by moving
>>>> gPrefs->Write(wxT("/LastOpenType"),wxT(""));
>>>> somewhere lower on the stack.
>>>> Diff attached (tested - compiles OK and works as intended; It might be
>>>> necessary to make Audacity show OpenFileDialog once before starting to
>>>> drag'n'drop files, to clear the LastOpenType setting). CC'ing to devel-
>>>> I still think that passing valuable data via gPrefs is bad, but doing it
>>>> the other way (passing extra arguments around) is going to be even
>>>> worse, i think.
>>>>     
>>>>         
>>> I've had this fix in the Windows Nightly for some time. It fixes the problem 
>>> of unwanted switching to native import when multiple-importing files via
>>> File > Open or File > Import using FFmpeg.  However, using File > Recent
>>> Files, dragging in or using Explorer "Open With" still always uses the native
>>> importer for me on Windows XP, however many times I first of all import 
>>> via File > Import using FFmpeg. Any thoughts?
>>>       
>> At this moment i don't remember whether this is the way i intended it to
>> work or not (i'll take a look this evening).
>>
>> Right now the only thing i can do is ask: isn't it a bit awkward that
>> Audacity automatically used the last import filter you happened to use?
>> This was unobvious (was it even documented anywhere?) and highly
>> unintuitive, IMO.
>>
>> Back in the days i had an idea of a preferences section that allowed one
>> to change the order in which import filters are checked for
>> compatibility with the file being imported - that would have solved the
>> problem of hard-coding native importer to be of highest priority than
>> libavcodec or using unobvious heuristics like LastOpenType. But it would
>> have been unflexible. Or maybe the problem is that there are two
>> distinct importers with overlapping functionality, which is confusing by
>> itself, not to mention that there seems to be no simple/easy way to
>> specify which one you want to use.
>>
>> Users would (reasonably) expect Audacity to "just open the goddamn file"
>> the best way it could, without having to decide which importer to use
>> (implying that when there is a choice, the developers can choose the
>> best option and implement it, instead of implementing both and giving
>> the choice to users).
>>     
> Yes, I think the key is that there is no easy way to specify which
> importer you want to use, and that builds an expectation that 
> Audacity will use the current one when the import method means 
> you can't access the open or import window. And this expectation 
> is fuelled by the Manual:
>
>     "When "All files" or "All supported files" is chosen in the file
>      types dropdown inside the file selection window, Audacity will
>      automatically select the most appropriate importer for your file. 
>      A "native" format like WAV or MP3 will therefore use the built-in
>      importer for that format. If this importer fails to open the file,
>      FFmpeg will be used instead. To force Audacity to import a native
>      file format using FFmpeg, choose "FFmpeg-compatible files" in the
>      file types dropdown. This will disable On-Demand Loading for WAV
>      and AIFF files." 
>
> That isn't now what happens (unless you read that as meaning "only if
> you actually use File > Open or > Import").
>   
Now, here's the situation (assuming that my patch is applied):
Each call to ShowOpenDialog() unconditionally sets LastOpenType to the
last open type (who would have thought!):
gPrefs->Write(wxT("/LastOpenType"), mask.BeforeFirst(wxT('|')));

There are a few places where this function is called. Each one checks
for the number of selected files, and if it is equal to zero, the code does:
gPrefs->Write(wxT("/LastOpenType"),wxT(""));
that is, erases LastOpenType (restoring normal importer priority order).
Also, this is done after an import (of one or more file) is done -
either via Import->Audio or the call to OpenFiles() (seems to be an
external API function).

To allow people to drop files on Audacity (or select them from Recent
Files) and have them opened by LastOpenType, these LastOpenType cleanups
have to go.
The only question is whether selecting a different filter and canceling
the dialog will switch LastOpenType or not. On one hand, requiring a
user to actually import something with the filter reduces the number of
accidental filter switches. On the other hand, it might be undesirable
for a user to have to import something to merely switch a filter.

I'm still thinking that this trick theatens to traumatize typical (7
t-words (8 with "to") in a row! Hight score!) users, we need different
solution. Can you ask the users? What do they want?
You can make a poll, like this:
a) Dedicated preferences section that deals with import filter priority.
b) Same as (a), but different priority can be assigned to different
extensions (that is, you can have all your WAVs imported by libavcodec,
while AIFFs will be opened by libsndfile).
c) Same as (a), but without UI (can be accessed only by tweaking ini-file).
d) Use LastOpenType. Count canceled OpenFileDialog as valid when a
filter was switched in it.
e) Use LastOpenType. Ignore filter switches made in canceled OpenFileDialog.
f) Ask user for a filter each time file(s) is(are) dropped on Audacity.
Remember filters used for files in Recent Files list (don't ask for a
filter).
g) Same as (f), but LastOpenType is the filter selected by default when
a dialog asking for filter is shown.
h) Something else.

(d and e) or (f and g) can be implemented simultaneously and controlled
by a preference.

This seems to be getting over complicated and unintuitive.

I'd guess that an overwhelming majority of users just want Audacity to "just
open the goddamn file"
the best way it could.

For the few users that want to specify FFMpeg as the importer they can do
that by selecting FFMpeg compatible files.

The "problem" that started this topic is that if a user selects to use
FFMpeg to import "multiple files", Audacity does that for the first file,
then Audacity changes back to the default importer (even though the user
specified that they wanted to use FFMpeg).

To my mind the correct "fix" would be to not change the settings during a
multiple import. Is that possible?

Regarding:
"native formats like WAV or MP3 still import using the native importer when
using File > Recent Files, dragging in or opening from a file manager
program."

This seems to me a trivial issue (much less than P3). I've only seen one
post (out of thousands) that had any concern about "how" Audacity imported,
just as long as it did it. If it is really important to the user that
Audacity uses FFMpeg to import, then using "Import > Audio >
FFMpeg-compatible" is the way to do it.
-- 
View this message in context: http://n2.nabble.com/Re-Exporting-multiple-MP3-files-with-FFMpeg-tp4409795p4669828.html
Sent from the audacity-devel mailing list archive at Nabble.com.

On 03.03.2010 21:34, LRN wrote:
>  Can you ask the users? What do they want?
>   
So far i've got only two responses, and nothing from Gale.
If no one really cares, i'll just choose the easiest path (the one that
requires the least amount of code).

lrn-2 wrote:
> 
> On 03.03.2010 21:34, LRN wrote:
>>  Can you ask the users? What do they want?
>>   
> So far i've got only two responses, and nothing from Gale.
> If no one really cares, i'll just choose the easiest path (the one that
> requires the least amount of code).
> 

What solution would that be?
I'm quite happy with the easiest solution as long as it's the same as the
best solution :=)

Steve
-- 
View this message in context: http://n2.nabble.com/Re-Exporting-multiple-MP3-files-with-FFMpeg-tp4409795p4704738.html
Sent from the audacity-devel mailing list archive at Nabble.com.

On 09.03.2010 22:56, Stevethefiddle wrote:
>
> lrn-2 wrote:
>   
>> On 03.03.2010 21:34, LRN wrote:
>>     
>>>  Can you ask the users? What do they want?
>>>   
>>>       
>> So far i've got only two responses, and nothing from Gale.
>> If no one really cares, i'll just choose the easiest path (the one that
>> requires the least amount of code).
>>
>>     
> What solution would that be?
> I'm quite happy with the easiest solution as long as it's the same as the
> best solution :=)
>
> Steve
>   
Easiest is to remove LastOpenType reset lines from my path and not to
check for the lack of selection in the open dialog before switching
LastOpenType.

On 13.03.2010 9:34, Gale Andrews wrote:
> | From LRN <lrn1986@...> 
> | Tue, 09 Mar 2010 01:33:00 +0300
> | Subject: [Audacity-quality] Importing multiple MP3 files with FFMpeg
>   
>>> From Richard Ash <richard@...> 
>>> Mon, 08 Mar 2010 21:48:27 +0000
>>> Subject: [Audacity-quality] Importing multiple MP3 files with FFMpeg
>>> On Wed, 2010-03-03 at 21:34 +0300, LRN wrote:
>>>       
>>>>>> Users would (reasonably) expect Audacity to "just open the goddamn file"
>>>>>> the best way it could, without having to decide which importer to use
>>>>>> (implying that when there is a choice, the developers can choose the
>>>>>> best option and implement it, instead of implementing both and giving
>>>>>> the choice to users).
>>>>>>             
>>>       
>>>> I'm still thinking that this trick theatens to traumatize typical (7
>>>> t-words (8 with "to") in a row! Hight score!) users, we need different
>>>> solution. Can you ask the users? What do they want?
>>>> You can make a poll, like this:
>>>> a) Dedicated preferences section that deals with import filter priority.
>>>> b) Same as (a), but different priority can be assigned to different
>>>> extensions (that is, you can have all your WAVs imported by libavcodec,
>>>> while AIFFs will be opened by libsndfile).
>>>> c) Same as (a), but without UI (can be accessed only by tweaking ini-file).
>>>> d) Use LastOpenType. Count canceled OpenFileDialog as valid when a
>>>> filter was switched in it.
>>>> e) Use LastOpenType. Ignore filter switches made in canceled OpenFileDialog.
>>>> f) Ask user for a filter each time file(s) is(are) dropped on Audacity.
>>>> Remember filters used for files in Recent Files list (don't ask for a
>>>> filter).
>>>> g) Same as (f), but LastOpenType is the filter selected by default when
>>>> a dialog asking for filter is shown.
>>>> h) Something else.
>>>>         
>>> I don't like the current hack of changing the files-of-type selection to
>>> affect the import filter (and it only works patchily - you can't use it
>>> to prefer flac-via-libsndfile to flac-via-libflac for instance, if your
>>> libsndfile support flac files). I'd quite happily junk it if there was a
>>> better option to control imports.
>>>
>>> On that basis I favour option (a) over all the others. Essentially, what
>>> this is is a GUI to allow the list of importers (which already exists
>>> internally) to be re-sorted. I don't favour (b) not because it wouldn't
>>> be nice to have, but because it is based on the idea that file
>>> extensions describe mime types, which they don't, and has a lot of
>>> pitfalls.
>>>       
>>   
>> With a good mime type library (or a sane media framework with mime
>> detection plugin) at hand, it should be possible to detect mime types
>> and choose an importer accordingly.
>>     
> This would be the ideal IMO for other reasons too (misnamed files etc.). 
> But until that happens, (a) looks best to me on balance, though perhaps 
> the UI needs to asterisk which are the "native" importers to aid 
> understanding (a couple of users made this point strongly). If we get to 
> being able to support (b), then (c) a file for those wanting to tweak by
> extension might be best to save the interface looking like a control 
> panel.   
>
> Most users who replied to me thought it was reasonable (and actually 
> convenient/discoverable if you mainly use File > Import) to choose the 
> filter at import time, without having to go into a preferences dialogue. 
> (a) could be hard to discover if it was in a preference, but if we got to
> support (b), asking the first time (for any import method) as to what 
> importer should be used for that extension might be good. There would
> need to be an option to stop asking.  
>
> Developing the idea of discoverability and ease of toggling, it crossed
> my mind that a control in Selection Toolbar might be worth considering
> for (a) - though space might be an issue. This would be a handy 
> indication as to whether an optional library was available. 
>
> But given in many cases there will be only two possible choices (native 
> or FFmpeg), do we really need an "order" of importers, instead of just 
> one "preferred" selection from the list to try first? One worst case 
> example might be on a Mac where you might see Default/QuickTime/
> FFmpeg. I assume in the case of an M4A, "Default" and "QuickTime" 
> would do the same thing, but perhaps that's not unreasonable? If they
> leave it set to QuickTime, then we decide for them that they get 
> libsndfile, not FFmpeg, when they import an MP3? 
>
> I assume in any case we weren't thinking of indicating explicitly which 
> importer was actually used, even though it isn't always obvious. 
>     
>   
I've committed a change (uh...actually, it consists of one line) that
implements (d). This should be good enough until better solution (b) is
implemented.

As for (b), i think it will work like this:
A table with N lines and 1 column. The column contains file extenion or
"*" to indicate that it matches any extension. User can add and remove
rows (two buttons - "add rule" and "remove selected rules") and freely
edit extension (double-clicking the row) in each row. Only one extension
per row. Extension may contain wildcards, or even regular expressions
(i'm favoring simple wildcards over regular expressions though). When a
row is highlighted, a separate list is populated with known import
filters. User is then able to drag and drop these filters within the
list to change their priority (it could also be possible to implement a
special "These filters will not be used:" fake filter line; filters
dropped below this line will not be used for files matching this rule).

I'm speaking of a table with 1 column instead of a list because later,
when mime-type-based import prioritizing becomes available, i will just
add one column for mime type to that table and match files for both
extension and mime type (one of them or both can be  "*" to match
everything). This way it should be possible to do something useful right
now and keep it useful later.

The choice in Open File dialog will override any options (to keep
current behaviour unchanged).

By default the table will have one rule for "*" extension and a filter
list associated with it will have filters ordered as they are now
(libsndfile leading the way, libavcodec at the bottom).
New filters (i.e. Audacity with ffmpeg support compiled in was installed
on top of Audacity without such support) will be automatically added to
the bottom of each list (if filter-disabling line is implemented, the
will be added above that line only for "*" rules).

The "*" rule should be undeleteable.

Table contents will be stored in xml file (if you know how to fit them
into ini file, with both extenions and mime types, and avoid key name
conflicts, let me know).

Rules can be moved up and down the list to change the order in which
they are checked. Undeleteable "*" rule will stay at the bottom.

On 14.03.2010 21:57, James Crook wrote:
> On 14/03/2010 16:04, LRN wrote:
>   
>> Table contents will be stored in xml file (if you know how to fit them 
>> into ini file, with both extenions and mime types, and avoid key name 
>> conflicts, let me know).
>>     
> Before you do anything so rash as invent a new file type, even 'just 
> another' xml one, please talk it over on audacity devel.  We need to use 
> the ini file for this, I'm fairly sure.  One way would be to have keys 
> like ImportRule01, ImportRule02, ImportRule03....with extension/mime 
> types as a value on the same line with a separator e.g. | after the 
> extension.
>
> --James.
>   
That is what i wanted to hear.

| From LRN <lrn1986@...> 
| Sun, 14 Mar 2010 19:04:31 +0300
| Subject: [Audacity-quality] Importing multiple MP3 files with FFMpeg
> ... I've committed a change (uh...actually, it consists of one line) that
> implements (d). This should be good enough until better solution (b) is
> implemented.

Hi LRN

Sorry I had not tested this before:

> Modified:
>   /audacity-src/trunk/src/import/Import.cpp
> 
> =======================================
> --- /audacity-src/trunk/src/import/Import.cpp	Sun Jan 24 05:33:28 2010
> +++ /audacity-src/trunk/src/import/Import.cpp	Sun Mar 14 08:26:17 2010
> @@ -131,7 +131,6 @@
>      // If user explicitly selected a filter,
>      // then we should try importing via corresponding plugin first
>      wxString type = gPrefs->Read(wxT("/LastOpenType"),wxT(""));
> -   gPrefs->Write(wxT("/LastOpenType"),wxT(""));
> 
>      // First, add all explicitly compatible plugins
>      importPluginNode = mImportPluginList->GetFirst();

Presumably "Count canceled OpenFileDialog as valid when a filter was
switched in it" proposed for (d) doesn't work because you didn't code that (?).

Although this cures our two problems when filter is set to FFmpeg:

* subsequent files imported at the same time revert to native filter
* Recent Files and DragnDrop ignore the FFmpeg filter

this still leaves the original problem that made us change behaviour in the
first place i.e. set the filter to a specific filter like MP3 and Recent Files
and DragnDrop use it, leading to a crash importing WAV, a few ms of
noise importing FLAC etc. 

I do have a lot of sympathy with people who want Recent Files and 
DragnDrop to use a filter they want, but we can't have crashes. Until we 
implement b), can we go back to the attached temporary fix that at least 
lets user File > Import multiple files via FFmpeg without the filter 
reverting to native? This was tested in my Windows nightly for a couple
of months and is safe (LastOpenType is ignored for Recent Files and 
DragnDrop). 

(NB: the attached diff is not the same as the one you originally attached 
because we don't need any change in Import.cpp now).   



Thanks 



Gale 



> On 13.03.2010 9:34, Gale Andrews wrote:
> > | From LRN <lrn1986@...> 
> > | Tue, 09 Mar 2010 01:33:00 +0300
> > | Subject: [Audacity-quality] Importing multiple MP3 files with FFMpeg
> >>> From Richard Ash <richard@...> 
> >>> Mon, 08 Mar 2010 21:48:27 +0000
> >>> Subject: [Audacity-quality] Importing multiple MP3 files with FFMpeg
> >>> On Wed, 2010-03-03 at 21:34 +0300, LRN wrote:
> >>>       
> >>>>>> Users would (reasonably) expect Audacity to "just open the goddamn file"
> >>>>>> the best way it could, without having to decide which importer to use
> >>>>>> (implying that when there is a choice, the developers can choose the
> >>>>>> best option and implement it, instead of implementing both and giving
> >>>>>> the choice to users).
> >>>>>>             
> >>>       
> >>>> I'm still thinking that this trick theatens to traumatize typical (7
> >>>> t-words (8 with "to") in a row! Hight score!) users, we need different
> >>>> solution. Can you ask the users? What do they want?
> >>>> You can make a poll, like this:
> >>>> a) Dedicated preferences section that deals with import filter priority.
> >>>> b) Same as (a), but different priority can be assigned to different
> >>>> extensions (that is, you can have all your WAVs imported by libavcodec,
> >>>> while AIFFs will be opened by libsndfile).
> >>>> c) Same as (a), but without UI (can be accessed only by tweaking ini-file).
> >>>> d) Use LastOpenType. Count canceled OpenFileDialog as valid when a
> >>>> filter was switched in it.
> >>>> e) Use LastOpenType. Ignore filter switches made in canceled OpenFileDialog.
> >>>> f) Ask user for a filter each time file(s) is(are) dropped on Audacity.
> >>>> Remember filters used for files in Recent Files list (don't ask for a
> >>>> filter).
> >>>> g) Same as (f), but LastOpenType is the filter selected by default when
> >>>> a dialog asking for filter is shown.
> >>>> h) Something else.
> >>>>         
> >>> I don't like the current hack of changing the files-of-type selection to
> >>> affect the import filter (and it only works patchily - you can't use it
> >>> to prefer flac-via-libsndfile to flac-via-libflac for instance, if your
> >>> libsndfile support flac files). I'd quite happily junk it if there was a
> >>> better option to control imports.
> >>>
> >>> On that basis I favour option (a) over all the others. Essentially, what
> >>> this is is a GUI to allow the list of importers (which already exists
> >>> internally) to be re-sorted. I don't favour (b) not because it wouldn't
> >>> be nice to have, but because it is based on the idea that file
> >>> extensions describe mime types, which they don't, and has a lot of
> >>> pitfalls.
> >>>       
> >>   
> >> With a good mime type library (or a sane media framework with mime
> >> detection plugin) at hand, it should be possible to detect mime types
> >> and choose an importer accordingly.
> >>     
> > This would be the ideal IMO for other reasons too (misnamed files etc.). 
> > But until that happens, (a) looks best to me on balance, though perhaps 
> > the UI needs to asterisk which are the "native" importers to aid 
> > understanding (a couple of users made this point strongly). If we get to 
> > being able to support (b), then (c) a file for those wanting to tweak by
> > extension might be best to save the interface looking like a control 
> > panel.   
> >
> > Most users who replied to me thought it was reasonable (and actually 
> > convenient/discoverable if you mainly use File > Import) to choose the 
> > filter at import time, without having to go into a preferences dialogue. 
> > (a) could be hard to discover if it was in a preference, but if we got to
> > support (b), asking the first time (for any import method) as to what 
> > importer should be used for that extension might be good. There would
> > need to be an option to stop asking.  
> >
> > Developing the idea of discoverability and ease of toggling, it crossed
> > my mind that a control in Selection Toolbar might be worth considering
> > for (a) - though space might be an issue. This would be a handy 
> > indication as to whether an optional library was available. 
> >
> > But given in many cases there will be only two possible choices (native 
> > or FFmpeg), do we really need an "order" of importers, instead of just 
> > one "preferred" selection from the list to try first? One worst case 
> > example might be on a Mac where you might see Default/QuickTime/
> > FFmpeg. I assume in the case of an M4A, "Default" and "QuickTime" 
> > would do the same thing, but perhaps that's not unreasonable? If they
> > leave it set to QuickTime, then we decide for them that they get 
> > libsndfile, not FFmpeg, when they import an MP3? 
> >
> > I assume in any case we weren't thinking of indicating explicitly which 
> > importer was actually used, even though it isn't always obvious. 
>
> ... As for (b), i think it will work like this:
> A table with N lines and 1 column. The column contains file extenion or
> "*" to indicate that it matches any extension. User can add and remove
> rows (two buttons - "add rule" and "remove selected rules") and freely
> edit extension (double-clicking the row) in each row. Only one extension
> per row. Extension may contain wildcards, or even regular expressions
> (i'm favoring simple wildcards over regular expressions though). When a
> row is highlighted, a separate list is populated with known import
> filters. User is then able to drag and drop these filters within the
> list to change their priority (it could also be possible to implement a
> special "These filters will not be used:" fake filter line; filters
> dropped below this line will not be used for files matching this rule).
> 
> I'm speaking of a table with 1 column instead of a list because later,
> when mime-type-based import prioritizing becomes available, i will just
> add one column for mime type to that table and match files for both
> extension and mime type (one of them or both can be  "*" to match
> everything). This way it should be possible to do something useful right
> now and keep it useful later.
> 
> The choice in Open File dialog will override any options (to keep
> current behaviour unchanged).
> 
> By default the table will have one rule for "*" extension and a filter
> list associated with it will have filters ordered as they are now
> (libsndfile leading the way, libavcodec at the bottom).
> New filters (i.e. Audacity with ffmpeg support compiled in was installed
> on top of Audacity without such support) will be automatically added to
> the bottom of each list (if filter-disabling line is implemented, the
> will be added above that line only for "*" rules).
> 
> The "*" rule should be undeleteable.
> 
> Table contents will be stored in xml file (if you know how to fit them
> into ini file, with both extenions and mime types, and avoid key name
> conflicts, let me know).
> 
> Rules can be moved up and down the list to change the order in which
> they are checked. Undeleteable "*" rule will stay at the bottom.

Actually, I managed to attach the old diff last time. The one we would need 
to stop the importer reverting to native is attached this time. 

Sorry - 

Gale  


| From LRN <lrn1986@...> 
| Sun, 14 Mar 2010 19:04:31 +0300
| Subject: [Audacity-quality] Importing multiple MP3 files with FFMpeg
> ... I've committed a change (uh...actually, it consists of one line) that
> implements (d). This should be good enough until better solution (b) is
> implemented.

Hi LRN

Sorry I had not tested this before:

> Modified:
>   /audacity-src/trunk/src/import/Import.cpp
> 
> =======================================
> --- /audacity-src/trunk/src/import/Import.cpp	Sun Jan 24 05:33:28 2010
> +++ /audacity-src/trunk/src/import/Import.cpp	Sun Mar 14 08:26:17 2010
> @@ -131,7 +131,6 @@
>      // If user explicitly selected a filter,
>      // then we should try importing via corresponding plugin first
>      wxString type = gPrefs->Read(wxT("/LastOpenType"),wxT(""));
> -   gPrefs->Write(wxT("/LastOpenType"),wxT(""));
> 
>      // First, add all explicitly compatible plugins
>      importPluginNode = mImportPluginList->GetFirst();

Presumably "Count canceled OpenFileDialog as valid when a filter was
switched in it" proposed for (d) doesn't work because you didn't code that (?).

Although this cures our two problems when filter is set to FFmpeg:

* subsequent files imported at the same time revert to native filter
* Recent Files and DragnDrop ignore the FFmpeg filter

this still leaves the original problem that made us change behaviour in the
first place i.e. set the filter to a specific filter like MP3 and Recent Files
and DragnDrop use it, leading to a crash importing WAV, a few ms of
noise importing FLAC etc. 

I do have a lot of sympathy with people who want Recent Files and 
DragnDrop to use a filter they want, but we can't have crashes. Until we 
implement b), can we go back to the attached temporary fix that at least 
lets user File > Import multiple files via FFmpeg without the filter 
reverting to native? This was tested in my Windows nightly for a couple
of months and is safe (LastOpenType is ignored for Recent Files and 
DragnDrop). 

(NB: the attached diff is not the same as the one you originally attached 
because we don't need any change in Import.cpp now).   



Thanks 



Gale 



> On 13.03.2010 9:34, Gale Andrews wrote:
> > | From LRN <lrn1986@...> 
> > | Tue, 09 Mar 2010 01:33:00 +0300
> > | Subject: [Audacity-quality] Importing multiple MP3 files with FFMpeg
> >>> From Richard Ash <richard@...> 
> >>> Mon, 08 Mar 2010 21:48:27 +0000
> >>> Subject: [Audacity-quality] Importing multiple MP3 files with FFMpeg
> >>> On Wed, 2010-03-03 at 21:34 +0300, LRN wrote:
> >>>       
> >>>>>> Users would (reasonably) expect Audacity to "just open the goddamn file"
> >>>>>> the best way it could, without having to decide which importer to use
> >>>>>> (implying that when there is a choice, the developers can choose the
> >>>>>> best option and implement it, instead of implementing both and giving
> >>>>>> the choice to users).
> >>>>>>             
> >>>       
> >>>> I'm still thinking that this trick theatens to traumatize typical (7
> >>>> t-words (8 with "to") in a row! Hight score!) users, we need different
> >>>> solution. Can you ask the users? What do they want?
> >>>> You can make a poll, like this:
> >>>> a) Dedicated preferences section that deals with import filter priority.
> >>>> b) Same as (a), but different priority can be assigned to different
> >>>> extensions (that is, you can have all your WAVs imported by libavcodec,
> >>>> while AIFFs will be opened by libsndfile).
> >>>> c) Same as (a), but without UI (can be accessed only by tweaking ini-file).
> >>>> d) Use LastOpenType. Count canceled OpenFileDialog as valid when a
> >>>> filter was switched in it.
> >>>> e) Use LastOpenType. Ignore filter switches made in canceled OpenFileDialog.
> >>>> f) Ask user for a filter each time file(s) is(are) dropped on Audacity.
> >>>> Remember filters used for files in Recent Files list (don't ask for a
> >>>> filter).
> >>>> g) Same as (f), but LastOpenType is the filter selected by default when
> >>>> a dialog asking for filter is shown.
> >>>> h) Something else.
> >>>>         
> >>> I don't like the current hack of changing the files-of-type selection to
> >>> affect the import filter (and it only works patchily - you can't use it
> >>> to prefer flac-via-libsndfile to flac-via-libflac for instance, if your
> >>> libsndfile support flac files). I'd quite happily junk it if there was a
> >>> better option to control imports.
> >>>
> >>> On that basis I favour option (a) over all the others. Essentially, what
> >>> this is is a GUI to allow the list of importers (which already exists
> >>> internally) to be re-sorted. I don't favour (b) not because it wouldn't
> >>> be nice to have, but because it is based on the idea that file
> >>> extensions describe mime types, which they don't, and has a lot of
> >>> pitfalls.
> >>>       
> >>   
> >> With a good mime type library (or a sane media framework with mime
> >> detection plugin) at hand, it should be possible to detect mime types
> >> and choose an importer accordingly.
> >>     
> > This would be the ideal IMO for other reasons too (misnamed files etc.). 
> > But until that happens, (a) looks best to me on balance, though perhaps 
> > the UI needs to asterisk which are the "native" importers to aid 
> > understanding (a couple of users made this point strongly). If we get to 
> > being able to support (b), then (c) a file for those wanting to tweak by
> > extension might be best to save the interface looking like a control 
> > panel.   
> >
> > Most users who replied to me thought it was reasonable (and actually 
> > convenient/discoverable if you mainly use File > Import) to choose the 
> > filter at import time, without having to go into a preferences dialogue. 
> > (a) could be hard to discover if it was in a preference, but if we got to
> > support (b), asking the first time (for any import method) as to what 
> > importer should be used for that extension might be good. There would
> > need to be an option to stop asking.  
> >
> > Developing the idea of discoverability and ease of toggling, it crossed
> > my mind that a control in Selection Toolbar might be worth considering
> > for (a) - though space might be an issue. This would be a handy 
> > indication as to whether an optional library was available. 
> >
> > But given in many cases there will be only two possible choices (native 
> > or FFmpeg), do we really need an "order" of importers, instead of just 
> > one "preferred" selection from the list to try first? One worst case 
> > example might be on a Mac where you might see Default/QuickTime/
> > FFmpeg. I assume in the case of an M4A, "Default" and "QuickTime" 
> > would do the same thing, but perhaps that's not unreasonable? If they
> > leave it set to QuickTime, then we decide for them that they get 
> > libsndfile, not FFmpeg, when they import an MP3? 
> >
> > I assume in any case we weren't thinking of indicating explicitly which 
> > importer was actually used, even though it isn't always obvious. 
>
> ... As for (b), i think it will work like this:
> A table with N lines and 1 column. The column contains file extenion or
> "*" to indicate that it matches any extension. User can add and remove
> rows (two buttons - "add rule" and "remove selected rules") and freely
> edit extension (double-clicking the row) in each row. Only one extension
> per row. Extension may contain wildcards, or even regular expressions
> (i'm favoring simple wildcards over regular expressions though). When a
> row is highlighted, a separate list is populated with known import
> filters. User is then able to drag and drop these filters within the
> list to change their priority (it could also be possible to implement a
> special "These filters will not be used:" fake filter line; filters
> dropped below this line will not be used for files matching this rule).
> 
> I'm speaking of a table with 1 column instead of a list because later,
> when mime-type-based import prioritizing becomes available, i will just
> add one column for mime type to that table and match files for both
> extension and mime type (one of them or both can be  "*" to match
> everything). This way it should be possible to do something useful right
> now and keep it useful later.
> 
> The choice in Open File dialog will override any options (to keep
> current behaviour unchanged).
> 
> By default the table will have one rule for "*" extension and a filter
> list associated with it will have filters ordered as they are now
> (libsndfile leading the way, libavcodec at the bottom).
> New filters (i.e. Audacity with ffmpeg support compiled in was installed
> on top of Audacity without such support) will be automatically added to
> the bottom of each list (if filter-disabling line is implemented, the
> will be added above that line only for "*" rules).
> 
> The "*" rule should be undeleteable.
> 
> Table contents will be stored in xml file (if you know how to fit them
> into ini file, with both extenions and mime types, and avoid key name
> conflicts, let me know).
> 
> Rules can be moved up and down the list to change the order in which
> they are checked. Undeleteable "*" rule will stay at the bottom.

On 26.03.2010 18:03, Gale Andrews wrote:
> | From LRN <lrn1986@...> 
> | Sun, 14 Mar 2010 19:04:31 +0300
> | Subject: [Audacity-quality] Importing multiple MP3 files with FFMpeg
>   
>> ... I've committed a change (uh...actually, it consists of one line) that
>> implements (d). This should be good enough until better solution (b) is
>> implemented.
>>     
> Hi LRN
>
> Sorry I had not tested this before:
>
>   
>> Modified:
>>   /audacity-src/trunk/src/import/Import.cpp
>>
>> =======================================
>> --- /audacity-src/trunk/src/import/Import.cpp	Sun Jan 24 05:33:28 2010
>> +++ /audacity-src/trunk/src/import/Import.cpp	Sun Mar 14 08:26:17 2010
>> @@ -131,7 +131,6 @@
>>      // If user explicitly selected a filter,
>>      // then we should try importing via corresponding plugin first
>>      wxString type = gPrefs->Read(wxT("/LastOpenType"),wxT(""));
>> -   gPrefs->Write(wxT("/LastOpenType"),wxT(""));
>>
>>      // First, add all explicitly compatible plugins
>>      importPluginNode = mImportPluginList->GetFirst();
>>     
> Presumably "Count canceled OpenFileDialog as valid when a filter was
> switched in it" proposed for (d) doesn't work because you didn't code that (?).
>   
Ah, that's an oversight on my part. ShowOpenDialog() returns empty list
on Cancel before it has a chance to set LastOpenType.
If you still want such behaviour (when canceled OpenDialog is still able
to change LastOpenType), i can implement it - just have to move
gPrefs->Write(wxT("/LastOpenType"), mask.BeforeFirst(wxT('|')));
before
return selected;


> Although this cures our two problems when filter is set to FFmpeg:
>
> * subsequent files imported at the same time revert to native filter
> * Recent Files and DragnDrop ignore the FFmpeg filter
>
> this still leaves the original problem that made us change behaviour in the
> first place i.e. set the filter to a specific filter like MP3 and Recent Files
> and DragnDrop use it, leading to a crash importing WAV, a few ms of
> noise importing FLAC etc. 
>
> I do have a lot of sympathy with people who want Recent Files and 
> DragnDrop to use a filter they want, but we can't have crashes. Until we 
> implement b),
I'm very close to finishing (b). It should be ready by the time Audacity
thaws.
>  can we go back to the attached temporary fix that at least 
> lets user File > Import multiple files via FFmpeg without the filter 
> reverting to native?
Definitely.
>  This was tested in my Windows nightly for a couple
> of months and is safe (LastOpenType is ignored for Recent Files and 
> DragnDrop). 
>
> (NB: the attached diff is not the same as the one you originally attached 
> because we don't need any change in Import.cpp now).   
>
>
>
> Thanks 
>
>
>
> Gale 
>   
OK, i'll commit your patch (from the other message) with a couple of
minor tweaks (to enable (d); if you still want it, that is).
>> On 13.03.2010 9:34, Gale Andrews wrote:
>>     
>>> | From LRN <lrn1986@...> 
>>> | Tue, 09 Mar 2010 01:33:00 +0300
>>> | Subject: [Audacity-quality] Importing multiple MP3 files with FFMpeg
>>>       
>>>>> From Richard Ash <richard@...> 
>>>>> Mon, 08 Mar 2010 21:48:27 +0000
>>>>> Subject: [Audacity-quality] Importing multiple MP3 files with FFMpeg
>>>>> On Wed, 2010-03-03 at 21:34 +0300, LRN wrote:
>>>>>       
>>>>>           
>>>>>>>> Users would (reasonably) expect Audacity to "just open the goddamn file"
>>>>>>>> the best way it could, without having to decide which importer to use
>>>>>>>> (implying that when there is a choice, the developers can choose the
>>>>>>>> best option and implement it, instead of implementing both and giving
>>>>>>>> the choice to users).
>>>>>>>>             
>>>>>>>>                 
>>>>>       
>>>>>           
>>>>>> I'm still thinking that this trick theatens to traumatize typical (7
>>>>>> t-words (8 with "to") in a row! Hight score!) users, we need different
>>>>>> solution. Can you ask the users? What do they want?
>>>>>> You can make a poll, like this:
>>>>>> a) Dedicated preferences section that deals with import filter priority.
>>>>>> b) Same as (a), but different priority can be assigned to different
>>>>>> extensions (that is, you can have all your WAVs imported by libavcodec,
>>>>>> while AIFFs will be opened by libsndfile).
>>>>>> c) Same as (a), but without UI (can be accessed only by tweaking ini-file).
>>>>>> d) Use LastOpenType. Count canceled OpenFileDialog as valid when a
>>>>>> filter was switched in it.
>>>>>> e) Use LastOpenType. Ignore filter switches made in canceled OpenFileDialog.
>>>>>> f) Ask user for a filter each time file(s) is(are) dropped on Audacity.
>>>>>> Remember filters used for files in Recent Files list (don't ask for a
>>>>>> filter).
>>>>>> g) Same as (f), but LastOpenType is the filter selected by default when
>>>>>> a dialog asking for filter is shown.
>>>>>> h) Something else.
>>>>>>         
>>>>>>             
>>>>> I don't like the current hack of changing the files-of-type selection to
>>>>> affect the import filter (and it only works patchily - you can't use it
>>>>> to prefer flac-via-libsndfile to flac-via-libflac for instance, if your
>>>>> libsndfile support flac files). I'd quite happily junk it if there was a
>>>>> better option to control imports.
>>>>>
>>>>> On that basis I favour option (a) over all the others. Essentially, what
>>>>> this is is a GUI to allow the list of importers (which already exists
>>>>> internally) to be re-sorted. I don't favour (b) not because it wouldn't
>>>>> be nice to have, but because it is based on the idea that file
>>>>> extensions describe mime types, which they don't, and has a lot of
>>>>> pitfalls.
>>>>>       
>>>>>           
>>>>   
>>>> With a good mime type library (or a sane media framework with mime
>>>> detection plugin) at hand, it should be possible to detect mime types
>>>> and choose an importer accordingly.
>>>>     
>>>>         
>>> This would be the ideal IMO for other reasons too (misnamed files etc.). 
>>> But until that happens, (a) looks best to me on balance, though perhaps 
>>> the UI needs to asterisk which are the "native" importers to aid 
>>> understanding (a couple of users made this point strongly). If we get to 
>>> being able to support (b), then (c) a file for those wanting to tweak by
>>> extension might be best to save the interface looking like a control 
>>> panel.   
>>>
>>> Most users who replied to me thought it was reasonable (and actually 
>>> convenient/discoverable if you mainly use File > Import) to choose the 
>>> filter at import time, without having to go into a preferences dialogue. 
>>> (a) could be hard to discover if it was in a preference, but if we got to
>>> support (b), asking the first time (for any import method) as to what 
>>> importer should be used for that extension might be good. There would
>>> need to be an option to stop asking.  
>>>
>>> Developing the idea of discoverability and ease of toggling, it crossed
>>> my mind that a control in Selection Toolbar might be worth considering
>>> for (a) - though space might be an issue. This would be a handy 
>>> indication as to whether an optional library was available. 
>>>
>>> But given in many cases there will be only two possible choices (native 
>>> or FFmpeg), do we really need an "order" of importers, instead of just 
>>> one "preferred" selection from the list to try first? One worst case 
>>> example might be on a Mac where you might see Default/QuickTime/
>>> FFmpeg. I assume in the case of an M4A, "Default" and "QuickTime" 
>>> would do the same thing, but perhaps that's not unreasonable? If they
>>> leave it set to QuickTime, then we decide for them that they get 
>>> libsndfile, not FFmpeg, when they import an MP3? 
>>>
>>> I assume in any case we weren't thinking of indicating explicitly which 
>>> importer was actually used, even though it isn't always obvious. 
>>>       
>> ... As for (b), i think it will work like this:
>> A table with N lines and 1 column. The column contains file extenion or
>> "*" to indicate that it matches any extension. User can add and remove
>> rows (two buttons - "add rule" and "remove selected rules") and freely
>> edit extension (double-clicking the row) in each row. Only one extension
>> per row. Extension may contain wildcards, or even regular expressions
>> (i'm favoring simple wildcards over regular expressions though). When a
>> row is highlighted, a separate list is populated with known import
>> filters. User is then able to drag and drop these filters within the
>> list to change their priority (it could also be possible to implement a
>> special "These filters will not be used:" fake filter line; filters
>> dropped below this line will not be used for files matching this rule).
>>
>> I'm speaking of a table with 1 column instead of a list because later,
>> when mime-type-based import prioritizing becomes available, i will just
>> add one column for mime type to that table and match files for both
>> extension and mime type (one of them or both can be  "*" to match
>> everything). This way it should be possible to do something useful right
>> now and keep it useful later.
>>
>> The choice in Open File dialog will override any options (to keep
>> current behaviour unchanged).
>>
>> By default the table will have one rule for "*" extension and a filter
>> list associated with it will have filters ordered as they are now
>> (libsndfile leading the way, libavcodec at the bottom).
>> New filters (i.e. Audacity with ffmpeg support compiled in was installed
>> on top of Audacity without such support) will be automatically added to
>> the bottom of each list (if filter-disabling line is implemented, the
>> will be added above that line only for "*" rules).
>>
>> The "*" rule should be undeleteable.
>>
>> Table contents will be stored in xml file (if you know how to fit them
>> into ini file, with both extenions and mime types, and avoid key name
>> conflicts, let me know).
>>
>> Rules can be moved up and down the list to change the order in which
>> they are checked. Undeleteable "*" rule will stay at the bottom.
>>     
>

On 26.03.2010 18:39, LRN wrote:
> On 26.03.2010 18:03, Gale Andrews wrote:
>   
>
>> Although this cures our two problems when filter is set to FFmpeg:
>>
>> * subsequent files imported at the same time revert to native filter
>> * Recent Files and DragnDrop ignore the FFmpeg filter
>>
>> this still leaves the original problem that made us change behaviour in the
>> first place i.e. set the filter to a specific filter like MP3 and Recent Files
>> and DragnDrop use it, leading to a crash importing WAV, a few ms of
>> noise importing FLAC etc. 
>>
>> I do have a lot of sympathy with people who want Recent Files and 
>> DragnDrop to use a filter they want, but we can't have crashes. Until we 
>> implement b),
>>     
> I'm very close to finishing (b). It should be ready by the time Audacity
> thaws.
>   
Actually, it's more-or-less ready now (just finished the importing
part). Patch and two new files (and a screenshot) are attached.

You can ponder on it in your free time (if you have any, with the
releasing process and all the stuff).

I'm not sure about experimantal ifdefs. It's a kind of bother to insert
these everywhere, so i've just added two - one for import behaviour
change, and another for showing preferences tab. Everything else is
compiled unconditionally (it shouldn't affect anything anyway, unless it
crashes somewhere).

Preferences UI is still a bit rough (i'm going to make columns in
RuleTable autoresizeable somehow). Also, i didn't find any easy ways to
implement drag'n'drop for wxGrid or wxListCtrl and had to use
Ctrl+Up/Down for item reordering.
The lack of direct mapping between UI and data (since i'm not really
using ShuttleGUI for this) leads to overly complex code. I think it can
be simplified a bit by mimicking the list item layout with array data
layout (including an empty divider item), maybe i'll have to do that if
current code proves to be too buggy to fix.

I've used wxMatchWild for matching; wxRegex seems to be an overkill.

UI and stuff for mime-type matching is implemented, but mime_type is
always "*" (always matches), and default mime-type filter is also "*"
(in release version mime-type colum will be hidden, preventing users
from setting mime-type filter to anything other than "*"), because we do
not have any mime-type-detection library.

Extensions and mime-types are separated by ":" (colon). In preferences
they are stored as
extension1:extension2:extension3\mime_type1:mime_type2:mime_type3|filter1:filter2:filter3\unusedfilter1:unusedfilter2
I'm sure that there are no filenames and/or mime-types with colons,
pipes and backslashes.

By the time Audacity thaws i will probably fix most of the UI.

On 26.03.2010 20:39, LRN wrote:
> On 26.03.2010 18:39, LRN wrote:
>   
>> On 26.03.2010 18:03, Gale Andrews wrote:
>>   
>>
>>     
>>> Although this cures our two problems when filter is set to FFmpeg:
>>>
>>> * subsequent files imported at the same time revert to native filter
>>> * Recent Files and DragnDrop ignore the FFmpeg filter
>>>
>>> this still leaves the original problem that made us change behaviour in the
>>> first place i.e. set the filter to a specific filter like MP3 and Recent Files
>>> and DragnDrop use it, leading to a crash importing WAV, a few ms of
>>> noise importing FLAC etc. 
>>>
>>> I do have a lot of sympathy with people who want Recent Files and 
>>> DragnDrop to use a filter they want, but we can't have crashes. Until we 
>>> implement b),
>>>     
>>>       
>> I'm very close to finishing (b). It should be ready by the time Audacity
>> thaws.
>>   
>>     
> Actually, it's more-or-less ready now (just finished the importing
> part). Patch and two new files (and a screenshot) are attached.
>
> You can ponder on it in your free time (if you have any, with the
> releasing process and all the stuff).
>
> I'm not sure about experimantal ifdefs. It's a kind of bother to insert
> these everywhere, so i've just added two - one for import behaviour
> change, and another for showing preferences tab. Everything else is
> compiled unconditionally (it shouldn't affect anything anyway, unless it
> crashes somewhere).
>
> Preferences UI is still a bit rough (i'm going to make columns in
> RuleTable autoresizeable somehow). Also, i didn't find any easy ways to
> implement drag'n'drop for wxGrid or wxListCtrl and had to use
> Ctrl+Up/Down for item reordering.
> The lack of direct mapping between UI and data (since i'm not really
> using ShuttleGUI for this) leads to overly complex code. I think it can
> be simplified a bit by mimicking the list item layout with array data
> layout (including an empty divider item), maybe i'll have to do that if
> current code proves to be too buggy to fix.
>
> I've used wxMatchWild for matching; wxRegex seems to be an overkill.
>
> UI and stuff for mime-type matching is implemented, but mime_type is
> always "*" (always matches), and default mime-type filter is also "*"
> (in release version mime-type colum will be hidden, preventing users
> from setting mime-type filter to anything other than "*"), because we do
> not have any mime-type-detection library.
>
> Extensions and mime-types are separated by ":" (colon). In preferences
> they are stored as
> extension1:extension2:extension3\mime_type1:mime_type2:mime_type3|filter1:filter2:filter3\unusedfilter1:unusedfilter2
> I'm sure that there are no filenames and/or mime-types with colons,
> pipes and backslashes.
>
> By the time Audacity thaws i will probably fix most of the UI.
>   
Committed.
GUI is somewhat smoother now.
Added new .cpp file to Makefile.in, i hope it works (didn't find any
other places where source files are specified).

Hi LRN

Only tried compiling on Windows so far. I note you updated   
win/Projects/Audacity/Audacity.vcproj for the two new files so I 
compiled straight after updating, but ran into:

AboutDialog.cpp
c:\audacitysvn_unicode working\src\ShuttleGui.h(96) : error C2143: syntax error : missing ';' before '*'
c:\audacitysvn_unicode working\src\ShuttleGui.h(96) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
c:\audacitysvn_unicode working\src\ShuttleGui.h(96) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
c:\audacitysvn_unicode working\src\ShuttleGui.h(96) : warning C4183: 'AddGrid': missing return type; assumed to be a member function returning 'int'
..\..\..\src\AboutDialog.cpp(176) : fatal error C1903: unable to recover from previous error(s); stopping compilation



Gale 



| From LRN <lrn1986@...> 
| Sun, 04 Apr 2010 12:20:01 +0400
| Subject: [Audacity-devel] Extended import filtering
> On 26.03.2010 20:39, LRN wrote:
> > On 26.03.2010 18:39, LRN wrote:
> >   
> >> On 26.03.2010 18:03, Gale Andrews wrote:
> >>   
> >>
> >>     
> >>> Although this cures our two problems when filter is set to FFmpeg:
> >>>
> >>> * subsequent files imported at the same time revert to native filter
> >>> * Recent Files and DragnDrop ignore the FFmpeg filter
> >>>
> >>> this still leaves the original problem that made us change behaviour in the
> >>> first place i.e. set the filter to a specific filter like MP3 and Recent Files
> >>> and DragnDrop use it, leading to a crash importing WAV, a few ms of
> >>> noise importing FLAC etc. 
> >>>
> >>> I do have a lot of sympathy with people who want Recent Files and 
> >>> DragnDrop to use a filter they want, but we can't have crashes. Until we 
> >>> implement b),
> >>>     
> >>>       
> >> I'm very close to finishing (b). It should be ready by the time Audacity
> >> thaws.
> >>   
> >>     
> > Actually, it's more-or-less ready now (just finished the importing
> > part). Patch and two new files (and a screenshot) are attached.
> >
> > You can ponder on it in your free time (if you have any, with the
> > releasing process and all the stuff).
> >
> > I'm not sure about experimantal ifdefs. It's a kind of bother to insert
> > these everywhere, so i've just added two - one for import behaviour
> > change, and another for showing preferences tab. Everything else is
> > compiled unconditionally (it shouldn't affect anything anyway, unless it
> > crashes somewhere).
> >
> > Preferences UI is still a bit rough (i'm going to make columns in
> > RuleTable autoresizeable somehow). Also, i didn't find any easy ways to
> > implement drag'n'drop for wxGrid or wxListCtrl and had to use
> > Ctrl+Up/Down for item reordering.
> > The lack of direct mapping between UI and data (since i'm not really
> > using ShuttleGUI for this) leads to overly complex code. I think it can
> > be simplified a bit by mimicking the list item layout with array data
> > layout (including an empty divider item), maybe i'll have to do that if
> > current code proves to be too buggy to fix.
> >
> > I've used wxMatchWild for matching; wxRegex seems to be an overkill.
> >
> > UI and stuff for mime-type matching is implemented, but mime_type is
> > always "*" (always matches), and default mime-type filter is also "*"
> > (in release version mime-type colum will be hidden, preventing users
> > from setting mime-type filter to anything other than "*"), because we do
> > not have any mime-type-detection library.
> >
> > Extensions and mime-types are separated by ":" (colon). In preferences
> > they are stored as
> > extension1:extension2:extension3\mime_type1:mime_type2:mime_type3|filter1:filter2:filter3\unusedfilter1:unusedfilter2
> > I'm sure that there are no filenames and/or mime-types with colons,
> > pipes and backslashes.
> >
> > By the time Audacity thaws i will probably fix most of the UI.
> >   
> Committed.
> GUI is somewhat smoother now.
> Added new .cpp file to Makefile.in, i hope it works (didn't find any
> other places where source files are specified).

On Sunday 04 April 2010 06:20:56 Gale Andrews wrote:
> Hi LRN
> 
> Only tried compiling on Windows so far. I note you updated
> win/Projects/Audacity/Audacity.vcproj for the two new files so I
> compiled straight after updating, but ran into:
> 
> AboutDialog.cpp
> c:\audacitysvn_unicode working\src\ShuttleGui.h(96) : error C2143:
>  syntax error : missing ';' before '*' c:\audacitysvn_unicode
>  working\src\ShuttleGui.h(96) : error C4430: missing type specifier
>  - int assumed. Note: C++ does not support default-int
>  c:\audacitysvn_unicode working\src\ShuttleGui.h(96) : error C4430:
>  missing type specifier - int assumed. Note: C++ does not support
>  default-int c:\audacitysvn_unicode working\src\ShuttleGui.h(96) :
>  warning C4183: 'AddGrid': missing return type; assumed to be a
>  member function returning 'int' ..\..\..\src\AboutDialog.cpp(176)
>  : fatal error C1903: unable to recover from previous error(s);
>  stopping compilation
> 

Got the same thing on Linux, along with a number of other errors. I 
fixed them so it builds for me. Also, LRN's changes added new files to 
Makefile.in and some new includes, so anyone on Unix should re-configure 
and make dep.

I've only just made sure it builds on Linux and there are a couple 
things I'll look at more closely, probably tomorrow.

 - Al

On 04.04.2010 20:24, Al Dimond wrote:
> On Sunday 04 April 2010 06:20:56 Gale Andrews wrote:
>   
>> Hi LRN
>>
>> Only tried compiling on Windows so far. I note you updated
>> win/Projects/Audacity/Audacity.vcproj for the two new files so I
>> compiled straight after updating, but ran into:
>>
>> AboutDialog.cpp
>> c:\audacitysvn_unicode working\src\ShuttleGui.h(96) : error C2143:
>>  syntax error : missing ';' before '*' c:\audacitysvn_unicode
>>  working\src\ShuttleGui.h(96) : error C4430: missing type specifier
>>  - int assumed. Note: C++ does not support default-int
>>  c:\audacitysvn_unicode working\src\ShuttleGui.h(96) : error C4430:
>>  missing type specifier - int assumed. Note: C++ does not support
>>  default-int c:\audacitysvn_unicode working\src\ShuttleGui.h(96) :
>>  warning C4183: 'AddGrid': missing return type; assumed to be a
>>  member function returning 'int' ..\..\..\src\AboutDialog.cpp(176)
>>  : fatal error C1903: unable to recover from previous error(s);
>>  stopping compilation
>>
>>     
> Got the same thing on Linux, along with a number of other errors. I 
> fixed them so it builds for me. Also, LRN's changes added new files to 
> Makefile.in and some new includes, so anyone on Unix should re-configure 
> and make dep.
>
> I've only just made sure it builds on Linux and there are a couple 
> things I'll look at more closely, probably tomorrow.
>
>  - Al
>   
Basically, it thinks that wxGrid class is undeclared. I think i've
missed forward declaration for it. Don't know how i've managed to build
it before.
I've fixed that, Gale, give it a try, please.

Hi LRN

Thanks for what you've done so far. I think this will have to be
documented in the Manual when finished.   

Shouldn't the "Importer" column be "Importer order" or similar, if it 
is an order of importers to try? First time off I tried just selecting the
importer I wanted in the list and clicking OK, which doesn't change 
behaviour. 

Is the extension of the syntax "*.wav" (as per your earlier image), or
what exactly?  

Anyway, if I select a new "*.wav" rule then CTRL + UP to move 
"FFmpeg-compatible files" to the top of the list, I see in .cfg:

   Item0=*.wav \\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof

However, WAVs dragged in from Explorer import via libsndfile as usual. 
Using File > Import > Audio, I can choose whether to import with 
libsndfile or FFmpeg as usual. Should I be able to do that? I also tried 
"wav" and ".wav" for the rule then gave up.

* When first loaded, the rule header says "ile extension" on Windows 7
   here (attached) and "ile exten" on Ubuntu 9.10. It corrects when you 
   add a rule. 

* As you see from the image, "Extended Import" in the tree is cut off at 
   the bottom on Windows 7 here (but not on Ubuntu). Shouldn't this be 
   under "Import/Export" in the tree?

* If I tab from the preferences tree I seem to land in the last rule 
   I created and can't tab beyond that to any other part of the interface

* What's "Open IME" on the right-click menu for the extension?

* If you click "Add new rule" and type you just get a system "ding" 

* "Delete selected rule" needs a confirmation, I think. Maybe 
    it would be better if it only deleted a rule that was selected
    or had focus.

* If user edits the rules in .cfg and makes a mistake with the 
   importer name, should they have a way to remove that using 
   the interface?  



Gale 



| From LRN <lrn1986@...> 
| Sun, 04 Apr 2010 12:20:01 +0400
| Subject: [Audacity-devel] Extended import filtering
> On 26.03.2010 20:39, LRN wrote:
> > On 26.03.2010 18:39, LRN wrote:
> >   
> >> On 26.03.2010 18:03, Gale Andrews wrote:
> >>   
> >>
> >>     
> >>> Although this cures our two problems when filter is set to FFmpeg:
> >>>
> >>> * subsequent files imported at the same time revert to native filter
> >>> * Recent Files and DragnDrop ignore the FFmpeg filter
> >>>
> >>> this still leaves the original problem that made us change behaviour in the
> >>> first place i.e. set the filter to a specific filter like MP3 and Recent Files
> >>> and DragnDrop use it, leading to a crash importing WAV, a few ms of
> >>> noise importing FLAC etc. 
> >>>
> >>> I do have a lot of sympathy with people who want Recent Files and 
> >>> DragnDrop to use a filter they want, but we can't have crashes. Until we 
> >>> implement b),
> >>>     
> >>>       
> >> I'm very close to finishing (b). It should be ready by the time Audacity
> >> thaws.
> >>   
> >>     
> > Actually, it's more-or-less ready now (just finished the importing
> > part). Patch and two new files (and a screenshot) are attached.
> >
> > You can ponder on it in your free time (if you have any, with the
> > releasing process and all the stuff).
> >
> > I'm not sure about experimantal ifdefs. It's a kind of bother to insert
> > these everywhere, so i've just added two - one for import behaviour
> > change, and another for showing preferences tab. Everything else is
> > compiled unconditionally (it shouldn't affect anything anyway, unless it
> > crashes somewhere).
> >
> > Preferences UI is still a bit rough (i'm going to make columns in
> > RuleTable autoresizeable somehow). Also, i didn't find any easy ways to
> > implement drag'n'drop for wxGrid or wxListCtrl and had to use
> > Ctrl+Up/Down for item reordering.
> > The lack of direct mapping between UI and data (since i'm not really
> > using ShuttleGUI for this) leads to overly complex code. I think it can
> > be simplified a bit by mimicking the list item layout with array data
> > layout (including an empty divider item), maybe i'll have to do that if
> > current code proves to be too buggy to fix.
> >
> > I've used wxMatchWild for matching; wxRegex seems to be an overkill.
> >
> > UI and stuff for mime-type matching is implemented, but mime_type is
> > always "*" (always matches), and default mime-type filter is also "*"
> > (in release version mime-type colum will be hidden, preventing users
> > from setting mime-type filter to anything other than "*"), because we do
> > not have any mime-type-detection library.
> >
> > Extensions and mime-types are separated by ":" (colon). In preferences
> > they are stored as
> > extension1:extension2:extension3\mime_type1:mime_type2:mime_type3|
> > filter1:filter2:filter3\unusedfilter1:unusedfilter2
> > I'm sure that there are no filenames and/or mime-types with colons,
> > pipes and backslashes.
> >
> > By the time Audacity thaws i will probably fix most of the UI.
> >   
> Committed.
> GUI is somewhat smoother now.
> Added new .cpp file to Makefile.in, i hope it works (didn't find any
> other places where source files are specified).

On 05.04.2010 0:37, Gale Andrews wrote:
> Hi LRN
>
> Thanks for what you've done so far. I think this will have to be
> documented in the Manual when finished.   
>
> Shouldn't the "Importer" column be "Importer order" or similar, if it 
> is an order of importers to try?
Yes, probably.
>  First time off I tried just selecting the
> importer I wanted in the list and clicking OK, which doesn't change 
> behaviour. 
>   
You have to use Ctrl+Up and Ctrl+Down to change the order of importers
and rules.
> Is the extension of the syntax "*.wav" (as per your earlier image), or
> what exactly?  
>   
Whatever wxMatchWild takes. It is made for filename matching, so it only
works with "*" wildcards. "*.wav" should do the trick.
> Anyway, if I select a new "*.wav" rule then CTRL + UP to move 
> "FFmpeg-compatible files" to the top of the list, I see in .cfg:
>
>    Item0=*.wav \\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof
>   
There should be no space between "*.wav" and "\\". This space counts as
part of the pattern. Obviously, you are unlikely to find a file with
extension "wav " (with space).
I can add some code that will trim leading and/or trailing spaces from
extenions, but i suspect that some users might not appreciate that.
> However, WAVs dragged in from Explorer import via libsndfile as usual. 
>   
> Using File > Import > Audio, I can choose whether to import with 
> libsndfile or FFmpeg as usual. Should I be able to do that?
Yes. The filter you choose in OpenFile dialog overrides any rule. That
keeps the behaviour consistent with previous Audacity versions (but i'm
open to suggestions).
>  I also tried 
> "wav" and ".wav" for the rule then gave up.
>   
"*.wav" is the correct one.
> * When first loaded, the rule header says "ile extension" on Windows 7
>    here (attached) and "ile exten" on Ubuntu 9.10. It corrects when you 
>    add a rule.
>   
Fixed.
> * As you see from the image, "Extended Import" in the tree is cut off at 
>    the bottom on Windows 7 here (but not on Ubuntu). Shouldn't this be 
>    under "Import/Export" in the tree?
>   
The tree grows when you resize the dialog. Normally you should have
scrollbars, but they seem to be disabled for this particular tree. I
will consider enabling them. Hope that doesn't break anything...
Import/Export is too crowded as it is, i think. It doesn't have any more
space for large table and a list.
> * If I tab from the preferences tree I seem to land in the last rule 
>    I created and can't tab beyond that to any other part of the interface
>   
That is a bug. I'll see what i can do.
> * What's "Open IME" on the right-click menu for the extension?
>   
What? I haven't seen that. Probably 7'ish or Ubunt'ish thing.
> * If you click "Add new rule" and type you just get a system "ding" 
>   
Because "Add new rule" button is focused, not the table. Fixable.
> * "Delete selected rule" needs a confirmation, I think. Maybe 
>     it would be better if it only deleted a rule that was selected
>     or had focus.
>   
Selection in wxGrid is a wild thing. I'll try to fix both selection bug
(make sure it actually looks selected) and add confirmation dialog.
> * If user edits the rules in .cfg and makes a mistake with the 
>    importer name, should they have a way to remove that using 
>    the interface?
>   
Users are not supposed to edit .cfg file. If they do, they can edit it
again and remove erroneous importer.
>
>
> Gale 
>
>
>
> | From LRN <lrn1986@...> 
> | Sun, 04 Apr 2010 12:20:01 +0400
> | Subject: [Audacity-devel] Extended import filtering
>   
>> On 26.03.2010 20:39, LRN wrote:
>>     
>>> On 26.03.2010 18:39, LRN wrote:
>>>   
>>>       
>>>> On 26.03.2010 18:03, Gale Andrews wrote:
>>>>   
>>>>
>>>>     
>>>>         
>>>>> Although this cures our two problems when filter is set to FFmpeg:
>>>>>
>>>>> * subsequent files imported at the same time revert to native filter
>>>>> * Recent Files and DragnDrop ignore the FFmpeg filter
>>>>>
>>>>> this still leaves the original problem that made us change behaviour in the
>>>>> first place i.e. set the filter to a specific filter like MP3 and Recent Files
>>>>> and DragnDrop use it, leading to a crash importing WAV, a few ms of
>>>>> noise importing FLAC etc. 
>>>>>
>>>>> I do have a lot of sympathy with people who want Recent Files and 
>>>>> DragnDrop to use a filter they want, but we can't have crashes. Until we 
>>>>> implement b),
>>>>>     
>>>>>       
>>>>>           
>>>> I'm very close to finishing (b). It should be ready by the time Audacity
>>>> thaws.
>>>>   
>>>>     
>>>>         
>>> Actually, it's more-or-less ready now (just finished the importing
>>> part). Patch and two new files (and a screenshot) are attached.
>>>
>>> You can ponder on it in your free time (if you have any, with the
>>> releasing process and all the stuff).
>>>
>>> I'm not sure about experimantal ifdefs. It's a kind of bother to insert
>>> these everywhere, so i've just added two - one for import behaviour
>>> change, and another for showing preferences tab. Everything else is
>>> compiled unconditionally (it shouldn't affect anything anyway, unless it
>>> crashes somewhere).
>>>
>>> Preferences UI is still a bit rough (i'm going to make columns in
>>> RuleTable autoresizeable somehow). Also, i didn't find any easy ways to
>>> implement drag'n'drop for wxGrid or wxListCtrl and had to use
>>> Ctrl+Up/Down for item reordering.
>>> The lack of direct mapping between UI and data (since i'm not really
>>> using ShuttleGUI for this) leads to overly complex code. I think it can
>>> be simplified a bit by mimicking the list item layout with array data
>>> layout (including an empty divider item), maybe i'll have to do that if
>>> current code proves to be too buggy to fix.
>>>
>>> I've used wxMatchWild for matching; wxRegex seems to be an overkill.
>>>
>>> UI and stuff for mime-type matching is implemented, but mime_type is
>>> always "*" (always matches), and default mime-type filter is also "*"
>>> (in release version mime-type colum will be hidden, preventing users
>>> from setting mime-type filter to anything other than "*"), because we do
>>> not have any mime-type-detection library.
>>>
>>> Extensions and mime-types are separated by ":" (colon). In preferences
>>> they are stored as
>>> extension1:extension2:extension3\mime_type1:mime_type2:mime_type3|
>>> filter1:filter2:filter3\unusedfilter1:unusedfilter2
>>> I'm sure that there are no filenames and/or mime-types with colons,
>>> pipes and backslashes.
>>>
>>> By the time Audacity thaws i will probably fix most of the UI.
>>>   
>>>       
>> Committed.
>> GUI is somewhat smoother now.
>> Added new .cpp file to Makefile.in, i hope it works (didn't find any
>> other places where source files are specified).
>>     
>   
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>
>
> _______________________________________________
> audacity-devel mailing list
> audacity-devel@...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

On 05.04.2010 1:47, LRN wrote:
> On 05.04.2010 0:37, Gale Andrews wrote:
>
>> * If I tab from the preferences tree I seem to land in the last rule 
>>    I created and can't tab beyond that to any other part of the interface
>>   
>>     
> That is a bug. I'll see what i can do.
>   
Seems to be a wxBug. Even if i remove my keyboard handlers from wxGrid,
it still remains a tab trap. Or maybe i didn't know a special voodoo
function to call that will turn wxGrid into normal tabbable widget. I
will try to dig a bit more. Anyone knows anything about wxWidgets
tabbing internals?
>> * If you click "Add new rule" and type you just get a system "ding" 
>>   
>>     
> Because "Add new rule" button is focused, not the table. Fixable.
>   
Fixed.
>> * "Delete selected rule" needs a confirmation, I think. Maybe 
>>     it would be better if it only deleted a rule that was selected
>>     or had focus.
>>   
>>     
> Selection in wxGrid is a wild thing. I'll try to fix both selection bug
> (make sure it actually looks selected) and add confirmation dialog.
>   
Fixed.

On Sun, 2010-04-04 at 21:37 +0100, Gale Andrews wrote:
> * What's "Open IME" on the right-click menu for the extension?

Input Method Editor - standard X11 feature for extended language and
alternative input methods. So it will only appear for Linux systems most
likely.

Richard

I've fixed one missing include to make today's version compile, but I've
got a visual problem once I do so:
http://richardash1981.users.sourceforge.net/audacity/ExtendedImportPrefs.png

also both lists are completely empty, which I'm guessing isn't meant to
be the case. Once I click "add new rule" then the right-hand list fills
up with entries, and I get one cell at the top left of the left-hand
list, which is the default entry for file name pattern "*" with the
order as now. Shouldn't this have been there to start with?

Having got that, I can't then change the order in the list at all - they
won't drag, and the arrow keys won't touch them, and I can't right-click
on the entries either.

Richard

On 05.04.2010 14:58, Richard Ash wrote:
> I've fixed one missing include to make today's version compile,
Since now i can (with some effort) build Audacity with MinGW, i should
do that more often. MSVS seems too forgivable.
>  but I've
> got a visual problem once I do so:
> http://richardash1981.users.sourceforge.net/audacity/ExtendedImportPrefs.png
>
>   
The importer list is autoresized - the column size is as large as the
largest item. Since there are no items, it's small. Maybe there's a
function that will count header size as well when resizing. I'll take a
look.
> also both lists are completely empty, which I'm guessing isn't meant to
> be the case.
It's normal. There is a default fallback for empty rulesets, but it is
hardcoded into Audacity. That is, when ruleset is empty (which is what
you get by default), Audacity will behave just as it behaved before.
>  Once I click "add new rule" then the right-hand list fills
> up with entries, and I get one cell at the top left of the left-hand
> list, which is the default entry for file name pattern "*" with the
> order as now. Shouldn't this have been there to start with?
>   
No, as i have said, last default rule is hardcoded. I've made the
function that creates stub rule (to add via "add new rule" button)
create it with the same contents as the default rule. That doesn't
really serve any purpose.
In early concept i thought of actually displaying the default rule at
the bottom, frozen, uneditable and unmovable. But that just adds
difficulty to the code without any real advantages.
> Having got that, I can't then change the order in the list at all - they
> won't drag,
They don't. As i have said, drag'n'drop is tricky, i had to settle with
Ctrl+Up and Ctrl+Down.
P.S. Any sample wxDragNDrop code in Audacity (i'm not speaking of
homegrown trackpanel widgets)?
>  and the arrow keys won't touch them, and I can't right-click
> on the entries either.
>
> Richard
>
>

On 05.04.2010 2:13, LRN wrote:
> On 05.04.2010 1:47, LRN wrote:
>   
>> On 05.04.2010 0:37, Gale Andrews wrote:
>>
>>     
>>> * If I tab from the preferences tree I seem to land in the last rule 
>>>    I created and can't tab beyond that to any other part of the interface
>>>   
>>>     
>>>       
>> That is a bug. I'll see what i can do.
>>   
>>     
> Seems to be a wxBug. Even if i remove my keyboard handlers from wxGrid,
> it still remains a tab trap. Or maybe i didn't know a special voodoo
> function to call that will turn wxGrid into normal tabbable widget. I
> will try to dig a bit more. Anyone knows anything about wxWidgets
> tabbing internals?
>   
It's definitely a wxBug. This happens because wxGrid is created with
wxWANT_CHARS window style. Due to funny wxWidgets implementation, this
style makes it accept not only chars, but also all tabs and arrow key
presses. This is not a problem for most widgets, since they can say
"well, i've got a tab, but i don't want handle it, so i'll just do
event.Skip()", and default handler will pick it up and do the navigation
magic. Not so with wxGrid - it actually *handles* Tab, Ctrl+Tab and all
other keys that are considered navigational. Also, because of wxWidgets
funnyness there is absolutely no way to make a custom OnKeyDown handler
and tell wxWidgets "OK, i don't want default wxGrid handler to handle
some of the navigation events, let me call your navigation processing
function directly, supplying wxKeyEvent as argument - if it's a navkey,
you'll do the right thing, otherwise i'll skip it and default wxGrid
handler will do whatever it wants to", so you have to implement that
yourself - i.e. you have to call ::Navigate(forward) and
::Navigate(backward) by hand when Tab and Ctrl+Tab are pressed. It might
be OK for one platform, but on different platforms these might not be
Tab and Ctrl+Tab at all (i don't really have any data at hand, but i
wouldn't be surprised to learn that MacOS uses
Meta+Left/Right+and-a-magic-gesture combination for widget navigation).
So whatever custom navigation i can do, it is less portable than
internal wxWidgets navigator - which is not available (or, at best case,
i'm going to re-implement whatever wxWidgets does).
Or i can remove wxWANT_CHARS style, in which case navigation occurs
normally (well, not exactly, it skips the grid when navigating backward,
but i'm sure that is fixable). But wxGrid is written with wxWANT_CHARS
in mind and in-grid navigation (moving cursor) simply doesn't work. And
my custom OnKeyDown handler is not called as well - meaning that Ctrl+Up
and Ctrl+Down do not work anymore. And i can't call OnKeyDown handler
manually from OnNavKey handler, because wxNavigationKey event is not
derived from wxKeyEvent and does not provide any keycode information
(also, Ctrl+Up/Down do not trigger EVT_NAVIGATION_KEY on wxPrefsPanel -
apparently they are handled by one of its parents).

On the bright side: I think i've successfully implemented
drag'n'drop-based item reordering (at least for wxGrid). But given the
accessibility concerns, lack of Ctrl+Up/Down fallback is unacceptable.
Unless someone have better idea, i will have to go back to calling
::Navigate() manually in response to Tab and Ctrl+Tab keypresses.

On Tue, Apr 6, 2010 at 9:18 AM, LRN <lrn1986@...> wrote:
> On 05.04.2010 2:13, LRN wrote:
>> On 05.04.2010 1:47, LRN wrote:
>>
>>> On 05.04.2010 0:37, Gale Andrews wrote:
>>>
>>>
>>>> * If I tab from the preferences tree I seem to land in the last rule
>>>>    I created and can't tab beyond that to any other part of the interface
>>>>
>>>>
>>>>
>>> That is a bug. I'll see what i can do.
>>>
>>>
>> Seems to be a wxBug. Even if i remove my keyboard handlers from wxGrid,
>> it still remains a tab trap. Or maybe i didn't know a special voodoo
>> function to call that will turn wxGrid into normal tabbable widget. I
>> will try to dig a bit more. Anyone knows anything about wxWidgets
>> tabbing internals?

I presume that the metadata editor and the labels editor use a wxGrid.
Just wondered whether the code for those editors might be of any help.

With respect to the ctrl+up and ctrl+down shortcuts for moving items
up and down. I think it could be argued that alt+up and alt+down might
be a better choice. In lists, ctrl+up/down is normally used for
changing the focus without changing the selection, and  in tables
ctrl+up/down are normally used to move to the top and bottoms of
columns. Internet Explorer uses alt+up/down for moving favorites up
and down the list in the favorites center.

David.

On 06.04.2010 13:55, David Bailes wrote:
> On Tue, Apr 6, 2010 at 9:18 AM, LRN <lrn1986@...> wrote:
>   
>> On 05.04.2010 2:13, LRN wrote:
>>     
>>> On 05.04.2010 1:47, LRN wrote:
>>>
>>>       
>>>> On 05.04.2010 0:37, Gale Andrews wrote:
>>>>
>>>>
>>>>         
>>>>> * If I tab from the preferences tree I seem to land in the last rule
>>>>>    I created and can't tab beyond that to any other part of the interface
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> That is a bug. I'll see what i can do.
>>>>
>>>>
>>>>         
>>> Seems to be a wxBug. Even if i remove my keyboard handlers from wxGrid,
>>> it still remains a tab trap. Or maybe i didn't know a special voodoo
>>> function to call that will turn wxGrid into normal tabbable widget. I
>>> will try to dig a bit more. Anyone knows anything about wxWidgets
>>> tabbing internals?
>>>       
> I presume that the metadata editor and the labels editor use a wxGrid.
> Just wondered whether the code for those editors might be of any help.
>   
It does it by handling WXK_TAB in OnKeyDown. That is, it doesn't use
native navigation either. Although that does help indeed - now i know
that it's OK to skip native navigation.
> With respect to the ctrl+up and ctrl+down shortcuts for moving items
> up and down. I think it could be argued that alt+up and alt+down might
> be a better choice. In lists, ctrl+up/down is normally used for
> changing the focus without changing the selection, and  in tables
> ctrl+up/down are normally used to move to the top and bottoms of
> columns. Internet Explorer uses alt+up/down for moving favorites up
> and down the list in the favorites center.
>   
I'm open to suggestions.

| From LRN <lrn1986@...> 
| Mon, 05 Apr 2010 01:47:16 +0400
| Subject: [Audacity-devel] Extended import filtering
> On 05.04.2010 0:37, Gale Andrews wrote:
> > Hi LRN
> > Is the extension of the syntax "*.wav" (as per your earlier image), or
> > what exactly?  
> >   
> > Anyway, if I select a new "*.wav" rule then CTRL + UP to move 
> > "FFmpeg-compatible files" to the top of the list, I see in .cfg:
> >
> >    Item0=*.wav \\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof
> >   
> There should be no space between "*.wav" and "\\". This space counts as
> part of the pattern. Obviously, you are unlikely to find a file with
> extension "wav " (with space).
> 
> I can add some code that will trim leading and/or trailing spaces from
> extenions, but i suspect that some users might not appreciate that.
 
OK. The added space must have been my mistake. Maybe you should add 
that code though, if a space would stop the extension being recognised? 
After all, until the text of a rule is selected, you cannot see whether there
are unwanted spaces or not. 

 
> > However, WAVs dragged in from Explorer import via libsndfile as usual. 

Still true, with a "*.wav" rule and "FFmpeg-compatible files" at top of the 
importer list. How can I make it work? Or doesn't it work in release 
builds with the MIME-type list disabled? 

By the way, is the code case-sensitive, so that a .wav rule will ignore a 
*.WAV file? 


> > Using File > Import > Audio, I can choose whether to import with 
> > libsndfile or FFmpeg as usual. Should I be able to do that?
> 
> Yes. The filter you choose in OpenFile dialog overrides any rule. That
> keeps the behaviour consistent with previous Audacity versions (but i'm
> open to suggestions).

It may be good to have an override, but I would not expect it to be default.
For example, the "all supported files" filter would seem to be less work for
the user because they should never have to change it if they don't mind 
all those files in the list. But if that filter means a WAV imported via the
dialogue must come in via libsndfile, in defiance of a rule in Preferences
that says WAV comes in via FFmpeg, that makes no sense to me. 

If there are no rules in Preferences, that should I think mean open dialogue 
can behave as before, so users will see no difference. But if a power user 
adds a rule, I would suggest the rule should by default be respected. 
Otherwise, we are back again to the import method determining the 
importer used.  

Could there be a checkbox in the dialogue to override a rule ("Ignore 
extended import preference")?

 
> > * As you see from the image, "Extended Import" in the tree is cut off at 
> >    the bottom on Windows 7 here (but not on Ubuntu). Shouldn't this be 
> >    under "Import/Export" in the tree?
> >   
> The tree grows when you resize the dialog. Normally you should have
> scrollbars, but they seem to be disabled for this particular tree. I
> will consider enabling them. 

Is there any flexibility to extend the tree a bit farther down below the
bottom of the panel to the right?  As it is now, there "looks" adequate 
space to accommodate a taller tree without need of a scrollbar. 


> Import/Export is too crowded as it is, i think. It doesn't have any more
> space for large table and a list.
 
Agreed, but what I meant was: keep "Extended Import" as a separate 
page, but the item to select it is underneath the Import / Export item,
instead of orphaned at the bottom of the tree. 

Is it possible that when editing a rule, ESC only cancels the edit and 
not boot you out of the entire Preferences? Compare escaping a field  
edit in Metadata Editor.


... and David wrote:
> With respect to the ctrl+up and ctrl+down shortcuts for moving items
> up and down. I think it could be argued that alt+up and alt+down might
> be a better choice. In lists, ctrl+up/down is normally used for
> changing the focus without changing the selection, and  in tables
> ctrl+up/down are normally used to move to the top and bottoms of
> columns. Internet Explorer uses alt+up/down for moving favorites up
> and down the list in the favorites center.

FWIW, xplorer2 (Explorer replacement) does use CTRL + up/down to 
move list items. But I don't think either CTRL or ALT are all that 
discoverable to sighted users. Does Widgets support up button and 
down button to move a selected list item? That seems quite a common
solution. 


Thanks




Gale

On 08.04.2010 8:28, Gale Andrews wrote:
> | From LRN <lrn1986@...> 
> | Mon, 05 Apr 2010 01:47:16 +0400
> | Subject: [Audacity-devel] Extended import filtering
>   
>> On 05.04.2010 0:37, Gale Andrews wrote:
>>     
>>> Hi LRN
>>> Is the extension of the syntax "*.wav" (as per your earlier image), or
>>> what exactly?  
>>>   
>>> Anyway, if I select a new "*.wav" rule then CTRL + UP to move 
>>> "FFmpeg-compatible files" to the top of the list, I see in .cfg:
>>>
>>>    Item0=*.wav \\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof
>>>   
>>>       
>> There should be no space between "*.wav" and "\\". This space counts as
>> part of the pattern. Obviously, you are unlikely to find a file with
>> extension "wav " (with space).
>>
>> I can add some code that will trim leading and/or trailing spaces from
>> extenions, but i suspect that some users might not appreciate that.
>>     
>  
> OK. The added space must have been my mistake. Maybe you should add 
> that code though, if a space would stop the extension being recognised? 
> After all, until the text of a rule is selected, you cannot see whether there
> are unwanted spaces or not. 
>   
I can add a messagebox that will warn the user about spaces (when they
are present) and will offer to remove them.
>  
>   
>>> However, WAVs dragged in from Explorer import via libsndfile as usual. 
>>>       
> Still true, with a "*.wav" rule and "FFmpeg-compatible files" at top of the 
> importer list. How can I make it work? Or doesn't it work in release 
> builds with the MIME-type list disabled? 
>
>   
Check your ini file. Does filter string look like "*.wav\\*|...."? That
is, with "\\*" after extension. If not, add it. At the moment Audacity
will not automatically match empty list of mime types (vs single mime
type "*") to anything (i've fixed that in my local copy to match empty
list to anything; i'm open to suggestions however).
Dragging a wav file from Explorer works for me as intended (imports via
FFmpeg).
> By the way, is the code case-sensitive, so that a .wav rule will ignore a 
> *.WAV file? 
>   
I think it's case-sensitive. At least that is the expression i've got
from wxMatchWild() code. For case-insensitivity there are two options:
1) ToLowerCase() both strings before comparing them
2) Use regular expressions instead of wxMatchWild().
I'd go for (1), easier for me, easier for users.
>
>   
>>> Using File > Import > Audio, I can choose whether to import with 
>>> libsndfile or FFmpeg as usual. Should I be able to do that?
>>>       
>> Yes. The filter you choose in OpenFile dialog overrides any rule. That
>> keeps the behaviour consistent with previous Audacity versions (but i'm
>> open to suggestions).
>>     
> It may be good to have an override, but I would not expect it to be default.
> For example, the "all supported files" filter would seem to be less work for
> the user because they should never have to change it if they don't mind 
> all those files in the list. But if that filter means a WAV imported via the
> dialogue must come in via libsndfile, in defiance of a rule in Preferences
> that says WAV comes in via FFmpeg, that makes no sense to me. 
>
> If there are no rules in Preferences, that should I think mean open dialogue 
> can behave as before, so users will see no difference. But if a power user 
> adds a rule, I would suggest the rule should by default be respected. 
> Otherwise, we are back again to the import method determining the 
> importer used.  
>
> Could there be a checkbox in the dialogue to override a rule ("Ignore 
> extended import preference")?
>   
Yes, checkboxes are easy :)
>  
>   
>>> * As you see from the image, "Extended Import" in the tree is cut off at 
>>>    the bottom on Windows 7 here (but not on Ubuntu). Shouldn't this be 
>>>    under "Import/Export" in the tree?
>>>   
>>>       
>> The tree grows when you resize the dialog. Normally you should have
>> scrollbars, but they seem to be disabled for this particular tree. I
>> will consider enabling them. 
>>     
> Is there any flexibility to extend the tree a bit farther down below the
> bottom of the panel to the right?  As it is now, there "looks" adequate 
> space to accommodate a taller tree without need of a scrollbar. 
>   
No. Dialog template means that "OK" and "Cancel" buttons get the whole
line for themselves.
>
>   
>> Import/Export is too crowded as it is, i think. It doesn't have any more
>> space for large table and a list.
>>     
>  
> Agreed, but what I meant was: keep "Extended Import" as a separate 
> page, but the item to select it is underneath the Import / Export item,
> instead of orphaned at the bottom of the tree. 
>   
OK.
> Is it possible that when editing a rule, ESC only cancels the edit and 
> not boot you out of the entire Preferences? Compare escaping a field  
> edit in Metadata Editor.
>   
It should be. I'll take a look.
>
> ... and David wrote:
>   
>> With respect to the ctrl+up and ctrl+down shortcuts for moving items
>> up and down. I think it could be argued that alt+up and alt+down might
>> be a better choice. In lists, ctrl+up/down is normally used for
>> changing the focus without changing the selection, and  in tables
>> ctrl+up/down are normally used to move to the top and bottoms of
>> columns. Internet Explorer uses alt+up/down for moving favorites up
>> and down the list in the favorites center.
>>     
> FWIW, xplorer2 (Explorer replacement) does use CTRL + up/down to 
> move list items. But I don't think either CTRL or ALT are all that 
> discoverable to sighted users. Does Widgets support up button and 
> down button to move a selected list item? That seems quite a common
> solution. 
>   
I can implement that, but it's rather ugly. Also, keyboard controls (or
button controls, if i agree to your up/down-button solution) will be
mostly for accessibility (since drag'n'drop is almost ready), and i
can't imagine mouseless accessibility-feature users selecting an item,
then tabbing all the way to "Up" button, pressing it a few times, then
tabbing back and selecting something else...

On Thu, Apr 8, 2010 at 6:06 AM, LRN <lrn1986@...> wrote:

>> ... and David wrote:
>>
>>> With respect to the ctrl+up and ctrl+down shortcuts for moving items
>>> up and down. I think it could be argued that alt+up and alt+down might
>>> be a better choice. In lists, ctrl+up/down is normally used for
>>> changing the focus without changing the selection, and  in tables
>>> ctrl+up/down are normally used to move to the top and bottoms of
>>> columns. Internet Explorer uses alt+up/down for moving favorites up
>>> and down the list in the favorites center.
>>>
>> FWIW, xplorer2 (Explorer replacement) does use CTRL + up/down to
>> move list items. But I don't think either CTRL or ALT are all that
>> discoverable to sighted users. Does Widgets support up button and
>> down button to move a selected list item? That seems quite a common
>> solution.
>>
> I can implement that, but it's rather ugly. Also, keyboard controls (or
> button controls, if i agree to your up/down-button solution) will be
> mostly for accessibility (since drag'n'drop is almost ready), and i
> can't imagine mouseless accessibility-feature users selecting an item,
> then tabbing all the way to "Up" button, pressing it a few times, then
> tabbing back and selecting something else...

Having move up and move down buttons would be more easily discoverable
for users of screen readers, rather than a keyboard shortcut such as
alt+up/down or ctrl+up/down, as these aren't used very much. Once a
user of a screen reader knows that the buttons exist, they don't have
to tab to them each time, they just use their access keys, eg alt+u
for the up button and alt+d for the down button.

David.

On 08.04.2010 8:28, Gale Andrews wrote:
> | From LRN <lrn1986@...> 
> | Mon, 05 Apr 2010 01:47:16 +0400
> | Subject: [Audacity-devel] Extended import filtering
>   
>> On 05.04.2010 0:37, Gale Andrews wrote:
>>     
>>> Hi LRN
>>> Is the extension of the syntax "*.wav" (as per your earlier image), or
>>> what exactly?  
>>>   
>>> Anyway, if I select a new "*.wav" rule then CTRL + UP to move 
>>> "FFmpeg-compatible files" to the top of the list, I see in .cfg:
>>>
>>>    Item0=*.wav \\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof
>>>   
>>>       
>> There should be no space between "*.wav" and "\\". This space counts as
>> part of the pattern. Obviously, you are unlikely to find a file with
>> extension "wav " (with space).
>>
>> I can add some code that will trim leading and/or trailing spaces from
>> extenions, but i suspect that some users might not appreciate that.
>>     
>  
> OK. The added space must have been my mistake. Maybe you should add 
> that code though, if a space would stop the extension being recognised? 
> After all, until the text of a rule is selected, you cannot see whether there
> are unwanted spaces or not. 
>   
Fixed, now a message box is shown, when leading/trailing spaces are
found, which offers to trim them. Spaces that are within are not
detected (since they are somewhat easier to notice and are less likely
to be entered by mistake).
Note, that 'space'  here means anything that Trim() considers a space
(actual, space, newline, line feed, tab etc).
>  
> By the way, is the code case-sensitive, so that a .wav rule will ignore a 
> *.WAV file? 
>
>   
Fixed, now both filename and pattern are Lower()'ed before wxMatchWild()
is called. This is as case-insensitive as it gets without regex.
>>> Using File > Import > Audio, I can choose whether to import with 
>>> libsndfile or FFmpeg as usual. Should I be able to do that?
>>>       
>> Yes. The filter you choose in OpenFile dialog overrides any rule. That
>> keeps the behaviour consistent with previous Audacity versions (but i'm
>> open to suggestions).
>>     
> It may be good to have an override, but I would not expect it to be default.
> For example, the "all supported files" filter would seem to be less work for
> the user because they should never have to change it if they don't mind 
> all those files in the list. But if that filter means a WAV imported via the
> dialogue must come in via libsndfile, in defiance of a rule in Preferences
> that says WAV comes in via FFmpeg, that makes no sense to me. 
>
> If there are no rules in Preferences, that should I think mean open dialogue 
> can behave as before, so users will see no difference. But if a power user 
> adds a rule, I would suggest the rule should by default be respected. 
> Otherwise, we are back again to the import method determining the 
> importer used.  
>
> Could there be a checkbox in the dialogue to override a rule ("Ignore 
> extended import preference")?
>   
Fixed, now a checkbox controls this behaviour (and it is off by default,
meaning that user's choice in OpenFile dialog doesn't affect anything).
>
>
>> Import/Export is too crowded as it is, i think. It doesn't have any more
>> space for large table and a list.
>>     
>  
> Agreed, but what I meant was: keep "Extended Import" as a separate 
> page, but the item to select it is underneath the Import / Export item,
> instead of orphaned at the bottom of the tree. 
>   
Fixed, now it's next to Import/Export.
> Is it possible that when editing a rule, ESC only cancels the edit and 
> not boot you out of the entire Preferences? Compare escaping a field  
> edit in Metadata Editor.
>   
This one is tricky. ESC is handled by the dialog window at the level
higher than PrefsPanel class i'm working with. I think i can override
ESC handling while a field is being edited in a grid, but that will
require access to PrefsDialog class and will break the abstraction
(PrefsPanel, by design, should not have any knowledge of PrefsDialog).
To put it plainly, it will be a hack.
>
> ... and David wrote:
>   
>> With respect to the ctrl+up and ctrl+down shortcuts for moving items
>> up and down. I think it could be argued that alt+up and alt+down might
>> be a better choice. In lists, ctrl+up/down is normally used for
>> changing the focus without changing the selection, and  in tables
>> ctrl+up/down are normally used to move to the top and bottoms of
>> columns. Internet Explorer uses alt+up/down for moving favorites up
>> and down the list in the favorites center.
>>     
> FWIW, xplorer2 (Explorer replacement) does use CTRL + up/down to 
> move list items. But I don't think either CTRL or ALT are all that 
> discoverable to sighted users. Does Widgets support up button and 
> down button to move a selected list item? That seems quite a common
> solution. 
>   
Fixed. Now there are 4 additional buttons for moving things up and down.
All with hotkeys (Alt+<char>). Ctrl+Up/Down are still supported, and
drag'n'drop reordering is available for rule table.

| From LRN <lrn1986@...> 
| Sat, 10 Apr 2010 10:32:28 +0400
| Subject: [Audacity-devel] Extended import filtering
> On 08.04.2010 8:28, Gale Andrews wrote:
> >>> Anyway, if I select a new "*.wav" rule then CTRL + UP to move 
> >>> "FFmpeg-compatible files" to the top of the list, I see in .cfg:
> >>>
> >>>    Item0=*.wav \\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof
> >>>   
> >>>       
> >> There should be no space between "*.wav" and "\\". This space counts as
> >> part of the pattern. Obviously, you are unlikely to find a file with
> >> extension "wav " (with space).
> >>
> >> I can add some code that will trim leading and/or trailing spaces from
> >> extenions, but i suspect that some users might not appreciate that.
> >>     
> >  
> > OK. The added space must have been my mistake. Maybe you should add 
> > that code though, if a space would stop the extension being recognised? 
> > After all, until the text of a rule is selected, you cannot see whether there
> > are unwanted spaces or not. 
> >   
> Fixed, now a message box is shown, when leading/trailing spaces are
> found, which offers to trim them. Spaces that are within are not
> detected (since they are somewhat easier to notice and are less likely
> to be entered by mistake).
> 
> Note, that 'space'  here means anything that Trim() considers a space
> (actual, space, newline, line feed, tab etc).

It certainly detects "*.wav " (trailing space) but not leading spaces (it 
passes " * .wav"). For the trailing space, after confirming you want to trim,
it then asks you to confirm a second time.


> >>> Using File > Import > Audio, I can choose whether to import with 
> >>> libsndfile or FFmpeg as usual. Should I be able to do that?
> >>>       
> >> Yes. The filter you choose in OpenFile dialog overrides any rule. That
> >> keeps the behaviour consistent with previous Audacity versions (but i'm
> >> open to suggestions).
> >>     
> > It may be good to have an override, but I would not expect it to be default.
> > For example, the "all supported files" filter would seem to be less work for
> > the user because they should never have to change it if they don't mind 
> > all those files in the list. But if that filter means a WAV imported via the
> > dialogue must come in via libsndfile, in defiance of a rule in Preferences
> > that says WAV comes in via FFmpeg, that makes no sense to me. 
> >
> > If there are no rules in Preferences, that should I think mean open dialogue 
> > can behave as before, so users will see no difference. But if a power user 
> > adds a rule, I would suggest the rule should by default be respected. 
> > Otherwise, we are back again to the import method determining the 
> > importer used.  
> >
> > Could there be a checkbox in the dialogue to override a rule ("Ignore 
> > extended import preference")?
> >   
> Fixed, now a checkbox controls this behaviour (and it is off by default,
> meaning that user's choice in OpenFile dialog doesn't affect anything).

Thanks for following that suggestion. My idea was actually to have 
this checkbox in the File Open/Import dialogue so you could toggle 
it at export time without wading into Prefs. Don't know how hard that 
is with a standard dialogue, but it might be nice if you could do that so 
that it mirrored the checkbox in Prefs.

BTW using my usual mouse emulator on XP, that override checkbox
in Prefs. won't check/uncheck unless I click the text. All the other 
Prefs. checkboxes are working normally with the emulator. 
   
However I am afraid in either Unicode Release or ANSI Release on 
Windows, I still can't get the basic functionality to work. The ANSI 
is unmodified SVN. 

I have a "*.wav" rule with "FFmpeg-compatible files" as the first item. 
Cfg has:

   Item0=*.wav\\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof

which seems correct. The File Open/Import filter is set to the default 
"All files". (I think it should default to "All supported files", but still).
WAVs dragged in with Explorer still open with libsndfile (either 
alisased or not, according to the Preferences). 

If I drag in MP3s that open fine in 1.3.12 Unicode Release, I get 
"error importing... - if it is uncompressed, try Import Raw". 

Adding the rule appears to be irrelevant to this problem. I cannot 
drag MP3s in even on an initialised .cfg, unless I set the Open/Import 
filter to "All supported files", "MP3 files" or "FFmpeg-compatible files".
If I do that, the MP3 comes in via FFmpeg (either imported via the 
dialogue or dragged), even if "All supported files" or "MP3 files" is 
selected. So if FFmpeg is unavailable, MP3s cannot now be imported. 

Maybe build Release and take a look?


> > Is it possible that when editing a rule, ESC only cancels the edit and 
> > not boot you out of the entire Preferences? Compare escaping a field  
> > edit in Metadata Editor.
> >   
> This one is tricky. ESC is handled by the dialog window at the level
> higher than PrefsPanel class i'm working with. I think i can override
> ESC handling while a field is being edited in a grid, but that will
> require access to PrefsDialog class and will break the abstraction
> (PrefsPanel, by design, should not have any knowledge of PrefsDialog).
> To put it plainly, it will be a hack.

You have to decide how safe a solution is, but clearly it's a problem. 
I may have set a lot of other preferences before making a bad edit in 
an Extended Import rule, then cancelling the edit. As it is now, I lose all 
the Prefs. changes I wanted to make, but the false rule edit I did not want 
is actually saved in its false state.  

 
> > ... and David wrote:
> >   
> >> With respect to the ctrl+up and ctrl+down shortcuts for moving items
> >> up and down. I think it could be argued that alt+up and alt+down might
> >> be a better choice. In lists, ctrl+up/down is normally used for
> >> changing the focus without changing the selection, and  in tables
> >> ctrl+up/down are normally used to move to the top and bottoms of
> >> columns. Internet Explorer uses alt+up/down for moving favorites up
> >> and down the list in the favorites center.
> >>     
> > FWIW, xplorer2 (Explorer replacement) does use CTRL + up/down to 
> > move list items. But I don't think either CTRL or ALT are all that 
> > discoverable to sighted users. Does Widgets support up button and 
> > down button to move a selected list item? That seems quite a common
> > solution. 
> >   
> Fixed. Now there are 4 additional buttons for moving things up and down.
> All with hotkeys (Alt+<char>). Ctrl+Up/Down are still supported, and
> drag'n'drop reordering is available for rule table.

Drag n' drop does not work for me, either with a cheap ball mouse on 
Linux or with my mouse emulator on Windows (yes, both real and 
emulated mouse can drag and drop properly) :=). 

I think the four buttons make Prefs. way too wide. On Ubuntu 9.10 at 
800 x 600, the last button for moving the selected filter down says 
"Move selected". Could we just have buttons that say "Move Up" and
"Move Down" and they work on the selected rule or filter? You cannot 
select a rule and a filter at the same time, so that should not be a
problem. Or "Selected Rule/Filter up" and "Selected Rule/Filter down"?

Or, if we need four buttons, drop the "selected" word. I do think we
need the buttons, even if drag n drop worked, because Audacity does
not use drag n drop a lot and there is nothing to suggest it will work
here.

 
> > Is there any flexibility to extend the tree a bit farther down below the
> > bottom of the panel to the right?  As it is now, there "looks" adequate 
> > space to accommodate a taller tree without need of a scrollbar. 
> >   
> No. Dialog template means that "OK" and "Cancel" buttons get the whole
> line for themselves.

There is a scrollbar on Linux, so why not on Windows? A truncated
"Mouse" item does not look very good. Also each time I launch Prefs. 
on Windows, the tree panel now bleeds into the boundaries between 
the static boxes. For example this on Win XP: 
http://www.gaclrecords.org.uk/launch_prefs.png

When you select another node in the tree, the problem corrects itself.



Thanks 



Gale

On 10.04.2010 19:50, Gale Andrews wrote:
> | From LRN <lrn1986@...> 
> | Sat, 10 Apr 2010 10:32:28 +0400
> | Subject: [Audacity-devel] Extended import filtering
>   
>> On 08.04.2010 8:28, Gale Andrews wrote:
>>     
>>>>> Anyway, if I select a new "*.wav" rule then CTRL + UP to move 
>>>>> "FFmpeg-compatible files" to the top of the list, I see in .cfg:
>>>>>
>>>>>    Item0=*.wav \\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof
>>>>>   
>>>>>       
>>>>>           
>>>> There should be no space between "*.wav" and "\\". This space counts as
>>>> part of the pattern. Obviously, you are unlikely to find a file with
>>>> extension "wav " (with space).
>>>>
>>>> I can add some code that will trim leading and/or trailing spaces from
>>>> extenions, but i suspect that some users might not appreciate that.
>>>>     
>>>>         
>>>  
>>> OK. The added space must have been my mistake. Maybe you should add 
>>> that code though, if a space would stop the extension being recognised? 
>>> After all, until the text of a rule is selected, you cannot see whether there
>>> are unwanted spaces or not. 
>>>   
>>>       
>> Fixed, now a message box is shown, when leading/trailing spaces are
>> found, which offers to trim them. Spaces that are within are not
>> detected (since they are somewhat easier to notice and are less likely
>> to be entered by mistake).
>>
>> Note, that 'space'  here means anything that Trim() considers a space
>> (actual, space, newline, line feed, tab etc).
>>     
> It certainly detects "*.wav " (trailing space) but not leading spaces (it 
> passes " * .wav"). For the trailing space, after confirming you want to trim,
> it then asks you to confirm a second time.
>   
Sorry, my bad. Fixed.
>
>   
>>>>> Using File > Import > Audio, I can choose whether to import with 
>>>>> libsndfile or FFmpeg as usual. Should I be able to do that?
>>>>>       
>>>>>           
>>>> Yes. The filter you choose in OpenFile dialog overrides any rule. That
>>>> keeps the behaviour consistent with previous Audacity versions (but i'm
>>>> open to suggestions).
>>>>     
>>>>         
>>> It may be good to have an override, but I would not expect it to be default.
>>> For example, the "all supported files" filter would seem to be less work for
>>> the user because they should never have to change it if they don't mind 
>>> all those files in the list. But if that filter means a WAV imported via the
>>> dialogue must come in via libsndfile, in defiance of a rule in Preferences
>>> that says WAV comes in via FFmpeg, that makes no sense to me. 
>>>
>>> If there are no rules in Preferences, that should I think mean open dialogue 
>>> can behave as before, so users will see no difference. But if a power user 
>>> adds a rule, I would suggest the rule should by default be respected. 
>>> Otherwise, we are back again to the import method determining the 
>>> importer used.  
>>>
>>> Could there be a checkbox in the dialogue to override a rule ("Ignore 
>>> extended import preference")?
>>>   
>>>       
>> Fixed, now a checkbox controls this behaviour (and it is off by default,
>> meaning that user's choice in OpenFile dialog doesn't affect anything).
>>     
> Thanks for following that suggestion. My idea was actually to have 
> this checkbox in the File Open/Import dialogue so you could toggle 
> it at export time without wading into Prefs. Don't know how hard that 
> is with a standard dialogue, but it might be nice if you could do that so 
> that it mirrored the checkbox in Prefs.
>   
That is harder to do than a prefs checkbox. I'm not sure that current
version of wx allows embedding arbitrary widgets into OpenFile dialog.
> BTW using my usual mouse emulator on XP, that override checkbox
> in Prefs. won't check/uncheck unless I click the text. All the other 
> Prefs. checkboxes are working normally with the emulator. 
>    
> However I am afraid in either Unicode Release or ANSI Release on 
> Windows, I still can't get the basic functionality to work. The ANSI 
> is unmodified SVN. 
>
> I have a "*.wav" rule with "FFmpeg-compatible files" as the first item. 
> Cfg has:
>
>    Item0=*.wav\\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof
>
> which seems correct. The File Open/Import filter is set to the default 
> "All files". (I think it should default to "All supported files", but still).
> WAVs dragged in with Explorer still open with libsndfile (either 
> alisased or not, according to the Preferences). 
>
> If I drag in MP3s that open fine in 1.3.12 Unicode Release, I get 
> "error importing... - if it is uncompressed, try Import Raw". 
>
> Adding the rule appears to be irrelevant to this problem. I cannot 
> drag MP3s in even on an initialised .cfg, unless I set the Open/Import 
> filter to "All supported files", "MP3 files" or "FFmpeg-compatible files".
> If I do that, the MP3 comes in via FFmpeg (either imported via the 
> dialogue or dragged), even if "All supported files" or "MP3 files" is 
> selected. So if FFmpeg is unavailable, MP3s cannot now be imported. 
>
> Maybe build Release and take a look?
>   
Works for me. With exactly this filter line. In Unicode Release.
What's your wxWidgets version?
>
>   
>>> Is it possible that when editing a rule, ESC only cancels the edit and 
>>> not boot you out of the entire Preferences? Compare escaping a field  
>>> edit in Metadata Editor.
>>>   
>>>       
>> This one is tricky. ESC is handled by the dialog window at the level
>> higher than PrefsPanel class i'm working with. I think i can override
>> ESC handling while a field is being edited in a grid, but that will
>> require access to PrefsDialog class and will break the abstraction
>> (PrefsPanel, by design, should not have any knowledge of PrefsDialog).
>> To put it plainly, it will be a hack.
>>     
> You have to decide how safe a solution is, but clearly it's a problem. 
> I may have set a lot of other preferences before making a bad edit in 
> an Extended Import rule, then cancelling the edit. As it is now, I lose all 
> the Prefs. changes I wanted to make, but the false rule edit I did not want 
> is actually saved in its false state.  
>
>  
>   
>>> ... and David wrote:
>>>   
>>>       
>>>> With respect to the ctrl+up and ctrl+down shortcuts for moving items
>>>> up and down. I think it could be argued that alt+up and alt+down might
>>>> be a better choice. In lists, ctrl+up/down is normally used for
>>>> changing the focus without changing the selection, and  in tables
>>>> ctrl+up/down are normally used to move to the top and bottoms of
>>>> columns. Internet Explorer uses alt+up/down for moving favorites up
>>>> and down the list in the favorites center.
>>>>     
>>>>         
>>> FWIW, xplorer2 (Explorer replacement) does use CTRL + up/down to 
>>> move list items. But I don't think either CTRL or ALT are all that 
>>> discoverable to sighted users. Does Widgets support up button and 
>>> down button to move a selected list item? That seems quite a common
>>> solution. 
>>>   
>>>       
>> Fixed. Now there are 4 additional buttons for moving things up and down.
>> All with hotkeys (Alt+<char>). Ctrl+Up/Down are still supported, and
>> drag'n'drop reordering is available for rule table.
>>     
> Drag n' drop does not work for me, either with a cheap ball mouse on 
> Linux or with my mouse emulator on Windows (yes, both real and 
> emulated mouse can drag and drop properly) :=).
>   
That's weird. But then, i've developed that on Windows. Drag'n'drop
seems to be very platform-dependent, maybe i've missed something.
> I think the four buttons make Prefs. way too wide. On Ubuntu 9.10 at 
> 800 x 600, the last button for moving the selected filter down says 
> "Move selected". Could we just have buttons that say "Move Up" and
> "Move Down" and they work on the selected rule or filter? You cannot 
> select a rule and a filter at the same time, so that should not be a
> problem. Or "Selected Rule/Filter up" and "Selected Rule/Filter down"?
>
>   
You can select a rule and a filter at the same time. At least on Windows
you can. Currently selected row defines the contents of the list and
stays selected.
> Or, if we need four buttons, drop the "selected" word.
Sounds sensible.
>  I do think we
> need the buttons, even if drag n drop worked, because Audacity does
> not use drag n drop a lot and there is nothing to suggest it will work
> here.
>
>  
>   
>>> Is there any flexibility to extend the tree a bit farther down below the
>>> bottom of the panel to the right?  As it is now, there "looks" adequate 
>>> space to accommodate a taller tree without need of a scrollbar. 
>>>   
>>>       
>> No. Dialog template means that "OK" and "Cancel" buttons get the whole
>> line for themselves.
>>     
> There is a scrollbar on Linux, so why not on Windows?
Ask wxWidgets developers.
By the way, there IS a scrollbar on Windows, i've seen it. It just
disappears...
>  A truncated
> "Mouse" item does not look very good. Also each time I launch Prefs. 
> on Windows, the tree panel now bleeds into the boundaries between 
> the static boxes. For example this on Win XP: 
> http://www.gaclrecords.org.uk/launch_prefs.png
>
> When you select another node in the tree, the problem corrects itself.
>
>   
This is caused by the scrollbar being shown and hidden again.

| From LRN <lrn1986@...> 
| Sat, 10 Apr 2010 20:48:29 +0400
| Subject: [Audacity-devel] Extended import filtering
> On 10.04.2010 19:50, Gale Andrews wrote:
> > | From LRN <lrn1986@...> 
> > | Sat, 10 Apr 2010 10:32:28 +0400
> > | Subject: [Audacity-devel] Extended import filtering
> >   
> >> On 08.04.2010 8:28, Gale Andrews wrote:
> > ... However I am afraid in either Unicode Release or ANSI Release on 
> > Windows, I still can't get the basic functionality to work. The ANSI 
> > is unmodified SVN. 
> >
> > I have a "*.wav" rule with "FFmpeg-compatible files" as the first item. 
> > Cfg has:
> >
> >    Item0=*.wav\\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof
> >
> > which seems correct. The File Open/Import filter is set to the default 
> > "All files". (I think it should default to "All supported files", but still).
> > WAVs dragged in with Explorer still open with libsndfile (either 
> > alisased or not, according to the Preferences). 
> >
> > If I drag in MP3s that open fine in 1.3.12 Unicode Release, I get 
> > "error importing... - if it is uncompressed, try Import Raw". 
> >
> > Adding the rule appears to be irrelevant to this problem. I cannot 
> > drag MP3s in even on an initialised .cfg, unless I set the Open/Import 
> > filter to "All supported files", "MP3 files" or "FFmpeg-compatible files".
> > If I do that, the MP3 comes in via FFmpeg (either imported via the 
> > dialogue or dragged), even if "All supported files" or "MP3 files" is 
> > selected. So if FFmpeg is unavailable, MP3s cannot now be imported. 
> >
> > Maybe build Release and take a look?
> >   
> Works for me. With exactly this filter line. In Unicode Release.
> What's your wxWidgets version?

The recommended 2.8.10 of course. Two other users of the Windows 
"Nightlies" confirm the same behaviour. I can try a Win debug build to 
compare, but the behaviour is identical on SVN Unicode Release in
Ubuntu 9.10 (absolutely stock SVN, wx 2.8.10, configure and make, 
no compile time options).

Have you tried downloading your Unicode build on to a non-developer 
machine?  


> >>> ... and David wrote:
> >>>   
> >>>       
> >>>> With respect to the ctrl+up and ctrl+down shortcuts for moving items
> >>>> up and down. I think it could be argued that alt+up and alt+down might
> >>>> be a better choice. In lists, ctrl+up/down is normally used for
> >>>> changing the focus without changing the selection, and  in tables
> >>>> ctrl+up/down are normally used to move to the top and bottoms of
> >>>> columns. Internet Explorer uses alt+up/down for moving favorites up
> >>>> and down the list in the favorites center.
> >>>>     
> >>>>         
> >>> FWIW, xplorer2 (Explorer replacement) does use CTRL + up/down to 
> >>> move list items. But I don't think either CTRL or ALT are all that 
> >>> discoverable to sighted users. Does Widgets support up button and 
> >>> down button to move a selected list item? That seems quite a common
> >>> solution. 
> >>>   
> >>>       
> >> Fixed. Now there are 4 additional buttons for moving things up and down.
> >> All with hotkeys (Alt+<char>). Ctrl+Up/Down are still supported, and
> >> drag'n'drop reordering is available for rule table.
> >>     
> > Drag n' drop does not work for me, either with a cheap ball mouse on 
> > Linux or with my mouse emulator on Windows (yes, both real and 
> > emulated mouse can drag and drop properly) :=).
> >   
> That's weird. But then, i've developed that on Windows. Drag'n'drop
> seems to be very platform-dependent, maybe i've missed something.

Another user has confirmed drag n drop does not work in my "Nightly" 
(in Vista, Logitech optical mouse). 

 
> > I think the four buttons make Prefs. way too wide. On Ubuntu 9.10 at 
> > 800 x 600, the last button for moving the selected filter down says 
> > "Move selected". Could we just have buttons that say "Move Up" and
> > "Move Down" and they work on the selected rule or filter? You cannot 
> > select a rule and a filter at the same time, so that should not be a
> > problem. Or "Selected Rule/Filter up" and "Selected Rule/Filter down"?
> >
> >   
> You can select a rule and a filter at the same time. At least on Windows
> you can. Currently selected row defines the contents of the list and
> stays selected.

I can see the rule remains highlighted (in grey) when you tab or click 
into one of the importer fields (which then takes over the OS "selected" 
colour from the rule). However the rule doesn't appear to be active, 
because up/down keys only affect the importers.  
 

> > Or, if we need four buttons, drop the "selected" word.
> Sounds sensible.

Can we do that then please, if we need the four buttons? 


> >>> Is there any flexibility to extend the tree a bit farther down below the
> >>> bottom of the panel to the right?  As it is now, there "looks" adequate 
> >>> space to accommodate a taller tree without need of a scrollbar. 
> >>>   
> >>>       
> >> No. Dialog template means that "OK" and "Cancel" buttons get the whole
> >> line for themselves.
> >>     
> > There is a scrollbar on Linux, so why not on Windows?
>  Ask wxWidgets developers. By the way, there IS a scrollbar on Windows, 
>  i've seen it. It just disappears...
>
> >  A truncated
> > "Mouse" item does not look very good. Also each time I launch Prefs. 
> > on Windows, the tree panel now bleeds into the boundaries between 
> > the static boxes. For example this on Win XP: 
> > http://www.gaclrecords.org.uk/launch_prefs.png
> >
> > When you select another node in the tree, the problem corrects itself.
> >
>    
> This is caused by the scrollbar being shown and hidden again.

It must appear subliminally then because I can't see it. Have you reported 
this to Widgets? It seems a serious restriction - apart from the current 
cosmetic problems, it would mean we can never add another preferences 
page on  Windows without increasing the default window height. 


Thanks



Gale

On 11.04.2010 16:19, Gale Andrews wrote:
> | From LRN <lrn1986@...> 
> | Sat, 10 Apr 2010 20:48:29 +0400
> | Subject: [Audacity-devel] Extended import filtering
>   
>> On 10.04.2010 19:50, Gale Andrews wrote:
>>     
>>> | From LRN <lrn1986@...> 
>>> | Sat, 10 Apr 2010 10:32:28 +0400
>>> | Subject: [Audacity-devel] Extended import filtering
>>>   
>>>       
>>>> On 08.04.2010 8:28, Gale Andrews wrote:
>>>>         
>>> ... However I am afraid in either Unicode Release or ANSI Release on 
>>> Windows, I still can't get the basic functionality to work. The ANSI 
>>> is unmodified SVN. 
>>>
>>> I have a "*.wav" rule with "FFmpeg-compatible files" as the first item. 
>>> Cfg has:
>>>
>>>    Item0=*.wav\\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof
>>>
>>> which seems correct. The File Open/Import filter is set to the default 
>>> "All files". (I think it should default to "All supported files", but still).
>>> WAVs dragged in with Explorer still open with libsndfile (either 
>>> alisased or not, according to the Preferences). 
>>>
>>> If I drag in MP3s that open fine in 1.3.12 Unicode Release, I get 
>>> "error importing... - if it is uncompressed, try Import Raw". 
>>>
>>> Adding the rule appears to be irrelevant to this problem. I cannot 
>>> drag MP3s in even on an initialised .cfg, unless I set the Open/Import 
>>> filter to "All supported files", "MP3 files" or "FFmpeg-compatible files".
>>> If I do that, the MP3 comes in via FFmpeg (either imported via the 
>>> dialogue or dragged), even if "All supported files" or "MP3 files" is 
>>> selected. So if FFmpeg is unavailable, MP3s cannot now be imported. 
>>>
>>> Maybe build Release and take a look?
>>>   
>>>       
>> Works for me. With exactly this filter line. In Unicode Release.
>> What's your wxWidgets version?
>>     
> The recommended 2.8.10 of course. Two other users of the Windows 
> "Nightlies" confirm the same behaviour. I can try a Win debug build to 
> compare, but the behaviour is identical on SVN Unicode Release in
> Ubuntu 9.10 (absolutely stock SVN, wx 2.8.10, configure and make, 
> no compile time options).
>
> Have you tried downloading your Unicode build on to a non-developer 
> machine?  
>   
No, i didn't. I'll add debug logging to see what's going on.
>
>   
>>>>> ... and David wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> With respect to the ctrl+up and ctrl+down shortcuts for moving items
>>>>>> up and down. I think it could be argued that alt+up and alt+down might
>>>>>> be a better choice. In lists, ctrl+up/down is normally used for
>>>>>> changing the focus without changing the selection, and  in tables
>>>>>> ctrl+up/down are normally used to move to the top and bottoms of
>>>>>> columns. Internet Explorer uses alt+up/down for moving favorites up
>>>>>> and down the list in the favorites center.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> FWIW, xplorer2 (Explorer replacement) does use CTRL + up/down to 
>>>>> move list items. But I don't think either CTRL or ALT are all that 
>>>>> discoverable to sighted users. Does Widgets support up button and 
>>>>> down button to move a selected list item? That seems quite a common
>>>>> solution. 
>>>>>   
>>>>>       
>>>>>           
>>>> Fixed. Now there are 4 additional buttons for moving things up and down.
>>>> All with hotkeys (Alt+<char>). Ctrl+Up/Down are still supported, and
>>>> drag'n'drop reordering is available for rule table.
>>>>     
>>>>         
>>> Drag n' drop does not work for me, either with a cheap ball mouse on 
>>> Linux or with my mouse emulator on Windows (yes, both real and 
>>> emulated mouse can drag and drop properly) :=).
>>>   
>>>       
>> That's weird. But then, i've developed that on Windows. Drag'n'drop
>> seems to be very platform-dependent, maybe i've missed something.
>>     
> Another user has confirmed drag n drop does not work in my "Nightly" 
> (in Vista, Logitech optical mouse). 
>   
Seems that i will have to test it myself after all :(

Do you have the same problems with debug builds?
>  
>   
>>> I think the four buttons make Prefs. way too wide. On Ubuntu 9.10 at 
>>> 800 x 600, the last button for moving the selected filter down says 
>>> "Move selected". Could we just have buttons that say "Move Up" and
>>> "Move Down" and they work on the selected rule or filter? You cannot 
>>> select a rule and a filter at the same time, so that should not be a
>>> problem. Or "Selected Rule/Filter up" and "Selected Rule/Filter down"?
>>>
>>>   
>>>       
>> You can select a rule and a filter at the same time. At least on Windows
>> you can. Currently selected row defines the contents of the list and
>> stays selected.
>>     
> I can see the rule remains highlighted (in grey) when you tab or click 
> into one of the importer fields (which then takes over the OS "selected" 
> colour from the rule). However the rule doesn't appear to be active, 
> because up/down keys only affect the importers.  
>   
If you select, say, a rule (it is highlighted in blue) and then press
"Move selected rule up" button, the button will capture the keyboard
focus, and the rule will be again highlighted with grey only. So the
keyboard focus is a good way of figuring out which control should have
its items moved.
>  
>>> Or, if we need four buttons, drop the "selected" word.
>>>       
>> Sounds sensible.
>>     
> Can we do that then please, if we need the four buttons? 
>   
Yes, i will do that.
>
>   
>>>>> Is there any flexibility to extend the tree a bit farther down below the
>>>>> bottom of the panel to the right?  As it is now, there "looks" adequate 
>>>>> space to accommodate a taller tree without need of a scrollbar. 
>>>>>   
>>>>>       
>>>>>           
>>>> No. Dialog template means that "OK" and "Cancel" buttons get the whole
>>>> line for themselves.
>>>>     
>>>>         
>>> There is a scrollbar on Linux, so why not on Windows?
>>>       
>>  Ask wxWidgets developers. By the way, there IS a scrollbar on Windows, 
>>  i've seen it. It just disappears...
>>
>>     
>>>  A truncated
>>> "Mouse" item does not look very good. Also each time I launch Prefs. 
>>> on Windows, the tree panel now bleeds into the boundaries between 
>>> the static boxes. For example this on Win XP: 
>>> http://www.gaclrecords.org.uk/launch_prefs.png
>>>
>>> When you select another node in the tree, the problem corrects itself.
>>>
>>>       
>>    
>> This is caused by the scrollbar being shown and hidden again.
>>     
> It must appear subliminally then because I can't see it.
Reduce the dialog height to the minimum, press OK, reopen the dialog -
you'll see it.
>  Have you reported 
> this to Widgets? It seems a serious restriction - apart from the current 
> cosmetic problems, it would mean we can never add another preferences 
> page on  Windows without increasing the default window height. 
>   
It's normal for a scrollbar to appear and disappear when a control
changes its size, it's how WinAPI-based GUI works. I doubt that it's
really a wxBug. It might be an intersection of the ways window resizing
is handled by wx and by ShuttleGUI.

> -----Original Message-----
> From: LRN [mailto:lrn1986@...] 
> On 11.04.2010 16:19, Gale Andrews wrote:
> > Another user has confirmed drag n drop does not work in my "Nightly"
> > (in Vista, Logitech optical mouse).
> >
> Seems that i will have to test it myself after all :(
> 
[   --Ed   ] 
If someone wants to give detailed explicit step to test I will do so. I have
been reading this thread but not following the details nor testing the code,
I am assuming that I can build the current SVN HEAD with no #define editing
to experience this new code.


--Ed

On 11.04.2010 20:30, Ed Musgrove wrote:
>> -----Original Message-----
>> From: LRN [mailto:lrn1986@...] 
>> On 11.04.2010 16:19, Gale Andrews wrote:
>>     
>>> Another user has confirmed drag n drop does not work in my "Nightly"
>>> (in Vista, Logitech optical mouse).
>>>
>>>       
>> Seems that i will have to test it myself after all :(
>>
>>     
> [   --Ed   ] 
> If someone wants to give detailed explicit step to test I will do so. I have
> been reading this thread but not following the details nor testing the code,
> I am assuming that I can build the current SVN HEAD with no #define editing
> to experience this new code.
>
>
> --Ed
>   
Yes, it's normal SVN HEAD, no special #define magic.
Before running Audacity add this:
[ExtImportItems]
Item0=*.wav\\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof

to the end of audacity.cfg
Of course, you should have libav*-based importer working (else there is
no point in ExtImportFilter).
After running Audacity drag a wav file (preferably a long one, so that
you can see the import progress dialog in action and verify that FFmpeg
importer is indeed being used) to Audacity window. You can also look at
debug log now.

I tried (the test steps outlined at the end of this email) with a 25 minute
.wav and drag'n'drop worked fine--used the FFMPEG I have installed (don't
really know anything about this stuff, just using what seems to be
recommended by Audacity).
I converted said WAV to an MP3--it also drag'n'dropped just fine and also
used the same FFMPEG to load (as far as I can tell--the progress dialog was
the same).

I do note that if I initialize the config file and try to drag'n'drop an MP3
or MP4 I get the "Audacity did not recognize the type..." error dialog (as
expected, I think). I wonder if this is what the reporters were
(accidentally??) seeing?

Obviously, since I had to edit the config file to perform this test, it was
not an accurate test of the entire process. Maybe it is time for LRN to
write up an "User's Manual" entry for the interface (and maybe a
"Programmer's Manual" entry detailing the code--similar to the ShuttleGUI
page:
http://wiki.audacityteam.org/wiki/ShuttleGui
James Cook (I think) started). If I can have detailed steps to get from a
virgin Audacity to this test I will try to follow them and do the test
again.

--Ed
FYI:
All tests with a completely new download of SVN HEAD just before testing.
Tested using Unicode Release only; wx2.8.10.

10:17:17: Trying to load FFmpeg libraries
10:17:17: mLibAVFormatPath is not empty, = D:\audio\Audacity\FFmpeg for
Audacity\avformat-52.dll. Loading from it.
10:17:17: Looking up PATH...
10:17:17: PATH = C:\Program Files\Common Files\Microsoft Shared\Windows
Live;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\Syst
em32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\ATI
Technologies\ATI.ACE\Core-Static;D:\nonVista
Programs\cvsnt\cvsnt;C:\Python26;D:\audio\Audacity;D:\nonVista
Programs\GnuWin32\bin;C:\Program Files (x86)\Microsoft SQL
Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL
Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL
Server\100\DTS\Binn\;D:\nonVista Programs\TortoiseSVN64\bin;D:\nonVista
Programs\SlikSVN64\bin\;C:\Program Files
(x86)\QuickTime\QTSystem\;C:\Program Files\Common Files\Microsoft
Shared\Windows Live
10:17:17: Checking that D:\audio\Audacity\FFmpeg for Audacity is in PATH...
10:17:17: not in PATH!
10:17:17: Appending ;D:\audio\Audacity\FFmpeg for Audacity ...
10:17:17: Loading avformat from D:\audio\Audacity\FFmpeg for
Audacity\avformat-52.dll
10:17:17: Loading avutil from D:\audio\Audacity\FFmpeg for
Audacity\avutil-50.dll
10:17:17: Loading avcodec from D:\audio\Audacity\FFmpeg for
Audacity\avcodec-52.dll
10:17:17: Returning PATH to normal...
10:17:17: Importing symbols...
10:17:17: All symbols loaded successfully. Initializing the library.
10:17:17: Retrieving library version.
10:17:17: AVCodec version 0x342000 - 52.32.0 (built against 0x342000 -
52.32.0)
10:17:17: AVFormat version 0x342400 - 52.36.0 (built against 0x342400 -
52.36.0)
10:17:17: AVUtil version 0x320300 - 50.3.0 (built against 0x320300 - 50.3.0)
10:17:17: AVCodec version mismatch is 0
10:17:17: AVFormat version mismatch is 0
10:17:17: AVUtil version mismatch is 0
10:17:17: Libraries loaded successfully!

> -----Original Message-----
> From: LRN [mailto:lrn1986@...]
> Sent: Sunday, April 11, 2010 9:36 AM
> To: audacity-devel@...
> Subject: Re: [Audacity-devel] Extended import filtering
> 
> On 11.04.2010 20:30, Ed Musgrove wrote:
> >> -----Original Message-----
> >> From: LRN [mailto:lrn1986@...] On 11.04.2010 16:19, Gale
> >> Andrews wrote:
> >>
> >>> Another user has confirmed drag n drop does not work in my "Nightly"
> >>> (in Vista, Logitech optical mouse).
> >>>
> >>>
> >> Seems that i will have to test it myself after all :(
> >>
> >>
> > [   --Ed   ]
> > If someone wants to give detailed explicit step to test I will do so.
> > I have been reading this thread but not following the details nor
> > testing the code, I am assuming that I can build the current SVN HEAD
> > with no #define editing to experience this new code.
> >
> >
> > --Ed
> >
> Yes, it's normal SVN HEAD, no special #define magic.
> Before running Audacity add this:
> [ExtImportItems]
> Item0=*.wav\\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof
> 
> to the end of audacity.cfg
> Of course, you should have libav*-based importer working (else there is no
point in
> ExtImportFilter).
> After running Audacity drag a wav file (preferably a long one, so that you
can see the import
> progress dialog in action and verify that FFmpeg importer is indeed being
used) to Audacity
> window. You can also look at debug log now.

> -----Original Message-----
Gale: 
> > > Is there any flexibility to extend the tree a bit farther down below
the
> > > bottom of the panel to the right?  As it is now, there "looks"
adequate
> > > space to accommodate a taller tree without need of a scrollbar.
LRN:
> > No. Dialog template means that "OK" and "Cancel" buttons get the whole
> > line for themselves.
Gale:
> There is a scrollbar on Linux, so why not on Windows? A truncated
> "Mouse" item does not look very good. Also each time I launch Prefs.
> on Windows, the tree panel now bleeds into the boundaries between
> the static boxes. For example this on Win XP:
> http://www.gaclrecords.org.uk/launch_prefs.png
> 
> When you select another node in the tree, the problem corrects itself. 
[   --Ed   ] 
This does not present on Win7 (see attached pic). There is a scroll bar and
no "bleed". My XP laptop is in Utah for a while, my XP desktop is at a
client's but he is in Utah with the laptop so I am a bit leary of going into
his house while he is away. He should be back within a week or so.

--Ed

On 11.04.2010 21:45, Ed Musgrove wrote:
> I tried (the test steps outlined at the end of this email) with a 25 minute
> .wav and drag'n'drop worked fine--used the FFMPEG I have installed (don't
> really know anything about this stuff, just using what seems to be
> recommended by Audacity).
>   
Cool.
> I converted said WAV to an MP3--it also drag'n'dropped just fine and also
> used the same FFMPEG to load (as far as I can tell--the progress dialog was
> the same).
>   
Strange. You only had one rule - about *.wav files. The default rule
(which kicks in when your *.wav-rule doesn't find a match) has mp3
importer in it with higher priority than ffmpeg, so it should have used
mp3 (libmad) importer.
> I do note that if I initialize the config file and try to drag'n'drop an MP3
> or MP4 I get the "Audacity did not recognize the type..." error dialog (as
> expected, I think). I wonder if this is what the reporters were
> (accidentally??) seeing?
>   
By 'initialize' you mean 'delete and let Audacity write in the
defaults'? If so, then you just don't have libmad-based importer in
Audacity, and the only way you can import mp3s is by ffmpeg (which is
unavailable, because it probably requires extra configuration, and
you've just killed your config). That's my guess.
> Obviously, since I had to edit the config file to perform this test, it was
> not an accurate test of the entire process.
The .cfg editing is just for quicker testing (it's difficult to mess
with a config file, while making a mistake with GUI is easy enough).
>  Maybe it is time for LRN to
> write up an "User's Manual" entry for the interface
It isn't finalized yet (although i don't think any major changes are
expected either).
>  (and maybe a
> "Programmer's Manual" entry detailing the code--similar to the ShuttleGUI
> page:
> http://wiki.audacityteam.org/wiki/ShuttleGui
> James Cook (I think) started).
No need for that - the code is rather simple (and i can add some
comments for difficult parts). And it's not an interface one is going to
use in other parts of Audacity (unlike ShuttleGUI).
>  If I can have detailed steps to get from a
> virgin Audacity to this test I will try to follow them and do the test
> again.
>   
Difficult to do with virgin Audacity for the reason stated above -
without libav*-based importer being available this feature doesn't make
any sense, and you generally don't get libav*-based importer working
without first tweaking the preferences (well, on Windows you don't,
maybe Linux version is better in this regard).
> --Ed
> FYI:
> All tests with a completely new download of SVN HEAD just before testing.
> Tested using Unicode Release only; wx2.8.10.
>
>   
That is seems to be taken with older-than-current version of SVN HEAD.
I've updated  it recently to log some additional info. Maybe SVN is too
slow to soak up the changes.

>   
>> -----Original Message-----
>> From: LRN [mailto:lrn1986@...]
>> Sent: Sunday, April 11, 2010 9:36 AM
>> To: audacity-devel@...
>> Subject: Re: [Audacity-devel] Extended import filtering
>>
>> On 11.04.2010 20:30, Ed Musgrove wrote:
>>     
>>>> -----Original Message-----
>>>> From: LRN [mailto:lrn1986@...] On 11.04.2010 16:19, Gale
>>>> Andrews wrote:
>>>>
>>>>         
>>>>> Another user has confirmed drag n drop does not work in my "Nightly"
>>>>> (in Vista, Logitech optical mouse).
>>>>>
>>>>>
>>>>>           
>>>> Seems that i will have to test it myself after all :(
>>>>
>>>>
>>>>         
>>> [   --Ed   ]
>>> If someone wants to give detailed explicit step to test I will do so.
>>> I have been reading this thread but not following the details nor
>>> testing the code, I am assuming that I can build the current SVN HEAD
>>> with no #define editing to experience this new code.
>>>
>>>
>>> --Ed
>>>
>>>       
>> Yes, it's normal SVN HEAD, no special #define magic.
>> Before running Audacity add this:
>> [ExtImportItems]
>> Item0=*.wav\\*|libav:libsndfile:liboggvorbis:libflac:libmad:lof
>>
>> to the end of audacity.cfg
>> Of course, you should have libav*-based importer working (else there is no
>>     
> point in
>   
>> ExtImportFilter).
>> After running Audacity drag a wav file (preferably a long one, so that you
>>     
> can see the import
>   
>> progress dialog in action and verify that FFmpeg importer is indeed being
>>     
> used) to Audacity
>   
>> window. You can also look at debug log now. 
>>     
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> audacity-devel mailing list
> audacity-devel@...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

On 11.04.2010 21:56, Ed Musgrove wrote:
>> -----Original Message-----
>>     
> Gale: 
>   
>>>> Is there any flexibility to extend the tree a bit farther down below
>>>>         
> the
>   
>>>> bottom of the panel to the right?  As it is now, there "looks"
>>>>         
> adequate
>   
>>>> space to accommodate a taller tree without need of a scrollbar.
>>>>         
> LRN:
>   
>>> No. Dialog template means that "OK" and "Cancel" buttons get the whole
>>> line for themselves.
>>>       
> Gale:
>   
>> There is a scrollbar on Linux, so why not on Windows? A truncated
>> "Mouse" item does not look very good. Also each time I launch Prefs.
>> on Windows, the tree panel now bleeds into the boundaries between
>> the static boxes. For example this on Win XP:
>> http://www.gaclrecords.org.uk/launch_prefs.png
>>
>> When you select another node in the tree, the problem corrects itself. 
>>     
> [   --Ed   ] 
> This does not present on Win7 (see attached pic). There is a scroll bar and
> no "bleed". My XP laptop is in Utah for a while, my XP desktop is at a
> client's but he is in Utah with the laptop so I am a bit leary of going into
> his house while he is away. He should be back within a week or so.
>   
Try resizing the dialog vertically back and forth, see if the problem
appears. On my machine (XP x64 SP2) it does - when you increase vertical
size, the scrollbar disappears, and when you shrink it back it doesn't
appear again, but the tree gets wider, causing the bleed.

> -----Original Message-----
> From: LRN [mailto:lrn1986@...]
> > Gale:
> >
> >> There is a scrollbar on Linux, so why not on Windows? A truncated
> >> "Mouse" item does not look very good. 
> > [   --Ed   ]
> > This does not present on Win7 (see attached pic). There is a scroll
> > bar and no "bleed". My XP laptop is in Utah for a while, my XP desktop
> > is at a client's but he is in Utah with the laptop so I am a bit leary
> > of going into his house while he is away. He should be back within a
week or so.
> >
> Try resizing the dialog vertically back and forth, see if the problem
appears. On my machine
> (XP x64 SP2) it does - when you increase vertical size, the scrollbar
disappears, and when
> you shrink it back it doesn't appear again, but the tree gets wider,
causing the bleed.
> 
[   --Ed   ] 
OK, I see the flickering scrollbar but not the "bleed". To experience the
scrollbar glitch make the Prefs dialog (viewing Extended Import) as short as
possible then slooooowly stretch and shrink it horizontaly. James Cook is
probably the best one to look at this. 

--Ed

| From LRN <lrn1986@...> 
| Sun, 11 Apr 2010 22:53:49 +0400
| Subject: [Audacity-devel] Extended import filtering
> On 11.04.2010 21:56, Ed Musgrove wrote:
> > Gale: 
> >   
> >>>> Is there any flexibility to extend the tree a bit farther down below
> >>>>  the bottom of the panel to the right?  As it is now, there "looks"
> >>>> adequate space to accommodate a taller tree without need of
> >>>> a scrollbar.
> >>>>         
> > LRN:
> >   
> >>> No. Dialog template means that "OK" and "Cancel" buttons get the whole
> >>> line for themselves.
> >>>       
> > Gale:
> >   
> >> There is a scrollbar on Linux, so why not on Windows? A truncated
> >> "Mouse" item does not look very good. Also each time I launch Prefs.
> >> on Windows, the tree panel now bleeds into the boundaries between
> >> the static boxes. For example this on Win XP:
> >> http://www.gaclrecords.org.uk/launch_prefs.png
> >>
> >> When you select another node in the tree, the problem corrects itself. 
> >>     
> > [   --Ed   ] 
> > This does not present on Win7 (see attached pic). There is a scroll bar and
> > no "bleed". My XP laptop is in Utah for a while, my XP desktop is at a
> > client's but he is in Utah with the laptop so I am a bit leary of going into
> > his house while he is away. He should be back within a week or so.
> >   
> Try resizing the dialog vertically back and forth, see if the problem
> appears. On my machine (XP x64 SP2) it does - when you increase vertical
> size, the scrollbar disappears, and when you shrink it back it doesn't
> appear again, but the tree gets wider, causing the bleed.

On Win 7 and XP, I never actually see the scrollbar after reducing the dialog
height to the minimum, click OK, and reopening the dialogue. If that causes
the bleed, it must happen too fast here.

I do see it momentarily after reopening, then dragging the dialog down. I also 
see it momentarily when dragging back up. When dragging back up, it happens 
just before the base of the tree touches the bottom of "Mouse". 



Gale

On 13.04.2010 21:25, Gale Andrews wrote:
> | From LRN <lrn1986@...> 
> | Sun, 11 Apr 2010 22:53:49 +0400
> | Subject: [Audacity-devel] Extended import filtering
>   
>> On 11.04.2010 21:56, Ed Musgrove wrote:
>>     
>>> Gale: 
>>>   
>>>       
>>>>>> Is there any flexibility to extend the tree a bit farther down below
>>>>>>  the bottom of the panel to the right?  As it is now, there "looks"
>>>>>> adequate space to accommodate a taller tree without need of
>>>>>> a scrollbar.
>>>>>>         
>>>>>>             
>>> LRN:
>>>   
>>>       
>>>>> No. Dialog template means that "OK" and "Cancel" buttons get the whole
>>>>> line for themselves.
>>>>>       
>>>>>           
>>> Gale:
>>>   
>>>       
>>>> There is a scrollbar on Linux, so why not on Windows? A truncated
>>>> "Mouse" item does not look very good. Also each time I launch Prefs.
>>>> on Windows, the tree panel now bleeds into the boundaries between
>>>> the static boxes. For example this on Win XP:
>>>> http://www.gaclrecords.org.uk/launch_prefs.png
>>>>
>>>> When you select another node in the tree, the problem corrects itself. 
>>>>     
>>>>         
>>> [   --Ed   ] 
>>> This does not present on Win7 (see attached pic). There is a scroll bar and
>>> no "bleed". My XP laptop is in Utah for a while, my XP desktop is at a
>>> client's but he is in Utah with the laptop so I am a bit leary of going into
>>> his house while he is away. He should be back within a week or so.
>>>   
>>>       
>> Try resizing the dialog vertically back and forth, see if the problem
>> appears. On my machine (XP x64 SP2) it does - when you increase vertical
>> size, the scrollbar disappears, and when you shrink it back it doesn't
>> appear again, but the tree gets wider, causing the bleed.
>>     
> On Win 7 and XP, I never actually see the scrollbar after reducing the dialog
> height to the minimum, click OK, and reopening the dialogue. If that causes
> the bleed, it must happen too fast here.
>
> I do see it momentarily after reopening, then dragging the dialog down. I also 
> see it momentarily when dragging back up. When dragging back up, it happens 
> just before the base of the tree touches the bottom of "Mouse". 
>   
Do you have XP theme (blue one) or some other theme? I think that is
important too (i have Windows Classic theme).

Regardless, what are we going to do about it? Scrollbar IS necessary
since the list has grown. I say - make it visible permanently
(grayed-out when there's nothing to scroll). That should solve the
bleeding as well. More difficult solution is to make the scrollbar
appear consistently when it is needed and without bleeding anything.

On 13.04.2010 23:28, LRN wrote:
> On 13.04.2010 21:25, Gale Andrews wrote:
>   
>> | From LRN <lrn1986@...> 
>> | Sun, 11 Apr 2010 22:53:49 +0400
>> | Subject: [Audacity-devel] Extended import filtering
>>   
>>     
>>> On 11.04.2010 21:56, Ed Musgrove wrote:
>>>     
>>>       
>>>> Gale: 
>>>>   
>>>>       
>>>>         
>>>>>>> Is there any flexibility to extend the tree a bit farther down below
>>>>>>>  the bottom of the panel to the right?  As it is now, there "looks"
>>>>>>> adequate space to accommodate a taller tree without need of
>>>>>>> a scrollbar.
>>>>>>>         
>>>>>>>             
>>>>>>>               
>>>> LRN:
>>>>   
>>>>       
>>>>         
>>>>>> No. Dialog template means that "OK" and "Cancel" buttons get the whole
>>>>>> line for themselves.
>>>>>>       
>>>>>>           
>>>>>>             
>>>> Gale:
>>>>   
>>>>       
>>>>         
>>>>> There is a scrollbar on Linux, so why not on Windows? A truncated
>>>>> "Mouse" item does not look very good. Also each time I launch Prefs.
>>>>> on Windows, the tree panel now bleeds into the boundaries between
>>>>> the static boxes. For example this on Win XP:
>>>>> http://www.gaclrecords.org.uk/launch_prefs.png
>>>>>
>>>>> When you select another node in the tree, the problem corrects itself. 
>>>>>     
>>>>>         
>>>>>           
>>>> [   --Ed   ] 
>>>> This does not present on Win7 (see attached pic). There is a scroll bar and
>>>> no "bleed". My XP laptop is in Utah for a while, my XP desktop is at a
>>>> client's but he is in Utah with the laptop so I am a bit leary of going into
>>>> his house while he is away. He should be back within a week or so.
>>>>   
>>>>       
>>>>         
>>> Try resizing the dialog vertically back and forth, see if the problem
>>> appears. On my machine (XP x64 SP2) it does - when you increase vertical
>>> size, the scrollbar disappears, and when you shrink it back it doesn't
>>> appear again, but the tree gets wider, causing the bleed.
>>>     
>>>       
>> On Win 7 and XP, I never actually see the scrollbar after reducing the dialog
>> height to the minimum, click OK, and reopening the dialogue. If that causes
>> the bleed, it must happen too fast here.
>>
>> I do see it momentarily after reopening, then dragging the dialog down. I also 
>> see it momentarily when dragging back up. When dragging back up, it happens 
>> just before the base of the tree touches the bottom of "Mouse". 
>>   
>>     
> Do you have XP theme (blue one) or some other theme? I think that is
> important too (i have Windows Classic theme).
>
> Regardless, what are we going to do about it? Scrollbar IS necessary
> since the list has grown. I say - make it visible permanently
> (grayed-out when there's nothing to scroll). That should solve the
> bleeding as well. More difficult solution is to make the scrollbar
> appear consistently when it is needed and without bleeding anything.
>   
After a couple of hours of toying with wxTreebook i have to conclude
that it is difficult to fix this either way.
wxTreeCtrl resizing is handled automatically by DefWindowProc(), so it
is Windows who actually removes or hides the scrollbar, and there is no
control over this behaviour - Tree Control in Windows doesn't have
anything like TVS_DISABLENOSCROLL style (there is LBS_DISABLENOSCROLL,
but that is for list boxes) which should have prevented it from hiding
the scrollbar.
Also, wxTreeCtrl lacks any scrollbar control interface, because it is
not derived from wxScrolledWindow, so changing window styles to
something like wxALWAYS_SHOW_SB doesn't work either.
It is possible to force tree control to show disabled scrollbar instead
of hiding it by calling SetScrollInfo() WinAPI function (or the
corresponding wx wrapper, although that's a bit tricky), but that has to
be done each time AFTER DefWindowProc() does its destructive wxSizeEvent
handling job, and i haven't seen a wx event handler with "after-default"
placement (like the ones in GTK+)
The "difficult" solution here is to fix the sizer function (or whatever
arranges child widgets) to make it react adequately on ever-changing
wxTreeCtrl size. Alas, my humble wxSkills are not enough for that.

On 19.04.2010 20:16, LRN wrote:
> On 13.04.2010 23:28, LRN wrote:
>   
>> On 13.04.2010 21:25, Gale Andrews wrote:
>>   
>>     
>>> | From LRN <lrn1986@...> 
>>> | Sun, 11 Apr 2010 22:53:49 +0400
>>> | Subject: [Audacity-devel] Extended import filtering
>>>   
>>>     
>>>       
>>>> On 11.04.2010 21:56, Ed Musgrove wrote:
>>>>     
>>>>       
>>>>         
>>>>> Gale: 
>>>>>   
>>>>>       
>>>>>         
>>>>>           
>>>>>>>> Is there any flexibility to extend the tree a bit farther down below
>>>>>>>>  the bottom of the panel to the right?  As it is now, there "looks"
>>>>>>>> adequate space to accommodate a taller tree without need of
>>>>>>>> a scrollbar.
>>>>>>>>         
>>>>>>>>             
>>>>>>>>               
>>>>>>>>                 
>>>>> LRN:
>>>>>   
>>>>>       
>>>>>         
>>>>>           
>>>>>>> No. Dialog template means that "OK" and "Cancel" buttons get the whole
>>>>>>> line for themselves.
>>>>>>>       
>>>>>>>           
>>>>>>>             
>>>>>>>               
>>>>> Gale:
>>>>>   
>>>>>       
>>>>>         
>>>>>           
>>>>>> There is a scrollbar on Linux, so why not on Windows? A truncated
>>>>>> "Mouse" item does not look very good. Also each time I launch Prefs.
>>>>>> on Windows, the tree panel now bleeds into the boundaries between
>>>>>> the static boxes. For example this on Win XP:
>>>>>> http://www.gaclrecords.org.uk/launch_prefs.png
>>>>>>
>>>>>> When you select another node in the tree, the problem corrects itself. 
>>>>>>     
>>>>>>         
>>>>>>           
>>>>>>             
>>>>> [   --Ed   ] 
>>>>> This does not present on Win7 (see attached pic). There is a scroll bar and
>>>>> no "bleed". My XP laptop is in Utah for a while, my XP desktop is at a
>>>>> client's but he is in Utah with the laptop so I am a bit leary of going into
>>>>> his house while he is away. He should be back within a week or so.
>>>>>   
>>>>>       
>>>>>         
>>>>>           
>>>> Try resizing the dialog vertically back and forth, see if the problem
>>>> appears. On my machine (XP x64 SP2) it does - when you increase vertical
>>>> size, the scrollbar disappears, and when you shrink it back it doesn't
>>>> appear again, but the tree gets wider, causing the bleed.
>>>>     
>>>>       
>>>>         
>>> On Win 7 and XP, I never actually see the scrollbar after reducing the dialog
>>> height to the minimum, click OK, and reopening the dialogue. If that causes
>>> the bleed, it must happen too fast here.
>>>
>>> I do see it momentarily after reopening, then dragging the dialog down. I also 
>>> see it momentarily when dragging back up. When dragging back up, it happens 
>>> just before the base of the tree touches the bottom of "Mouse". 
>>>   
>>>     
>>>       
>> Do you have XP theme (blue one) or some other theme? I think that is
>> important too (i have Windows Classic theme).
>>
>> Regardless, what are we going to do about it? Scrollbar IS necessary
>> since the list has grown. I say - make it visible permanently
>> (grayed-out when there's nothing to scroll). That should solve the
>> bleeding as well. More difficult solution is to make the scrollbar
>> appear consistently when it is needed and without bleeding anything.
>>   
>>     
> After a couple of hours of toying with wxTreebook i have to conclude
> that it is difficult to fix this either way.
> wxTreeCtrl resizing is handled automatically by DefWindowProc(), so it
> is Windows who actually removes or hides the scrollbar, and there is no
> control over this behaviour - Tree Control in Windows doesn't have
> anything like TVS_DISABLENOSCROLL style (there is LBS_DISABLENOSCROLL,
> but that is for list boxes) which should have prevented it from hiding
> the scrollbar.
> Also, wxTreeCtrl lacks any scrollbar control interface, because it is
> not derived from wxScrolledWindow, so changing window styles to
> something like wxALWAYS_SHOW_SB doesn't work either.
> It is possible to force tree control to show disabled scrollbar instead
> of hiding it by calling SetScrollInfo() WinAPI function (or the
> corresponding wx wrapper, although that's a bit tricky), but that has to
> be done each time AFTER DefWindowProc() does its destructive wxSizeEvent
> handling job, and i haven't seen a wx event handler with "after-default"
> placement (like the ones in GTK+)
> The "difficult" solution here is to fix the sizer function (or whatever
> arranges child widgets) to make it react adequately on ever-changing
> wxTreeCtrl size. Alas, my humble wxSkills are not enough for that.
>   
Just confirmed this on Windows 7 as well.
Steps to reproduce:
1) Resize preferences dialog to minimal height.
2) Close preferences dialog.
3) Open preferences dialog.
You will see vertical scrollbar.
4) Increate preferences dialog height until scrollbar disappears
5) Decrease preferences dialog height to trigger control bleeding.
Scrollbar will not reappear (it will blink in for a split second each
time the height changes though).

| From LRN <lrn1986@...> 
| Sun, 11 Apr 2010 18:12:06 +0400
| Subject: [Audacity-devel] Extended import filtering
> On 11.04.2010 16:19, Gale Andrews wrote:
> > | From LRN <lrn1986@...> 
> > | Sat, 10 Apr 2010 20:48:29 +0400
> > | Subject: [Audacity-devel] Extended import filtering
> >   
> >> On 10.04.2010 19:50, Gale Andrews wrote:
> >>> Drag n' drop does not work for me, either with a cheap ball mouse on 
> >>> Linux or with my mouse emulator on Windows (yes, both real and 
> >>> emulated mouse can drag and drop properly) :=).
> >>>   
> >>>       
> >> That's weird. But then, i've developed that on Windows. Drag'n'drop
> >> seems to be very platform-dependent, maybe i've missed something.
> >>     
> > Another user has confirmed drag n drop does not work in my "Nightly" 
> > (in Vista, Logitech optical mouse). 
> >   
> Seems that i will have to test it myself after all :(
> 
> Do you have the same problems with debug builds?

Yes, Unicode Debug on Windows and Ubuntu has the same problem. Can't 
drag with any type of real or virtual mouse I have here. 


> It's normal for a scrollbar to appear and disappear when a control
> changes its size, it's how WinAPI-based GUI works. I doubt that it's
> really a wxBug. It might be an intersection of the ways window resizing
> is handled by wx and by ShuttleGUI.

> Do you have XP theme (blue one) or some other theme? I think that is
> important too (i have Windows Classic theme).

The XP theme. And I have Tahoma font (which seems just a little taller 
than Windows default) on both Windows XP and 7. So in your Win 7 steps:

    1) Resize preferences dialog to minimal height.
    2) Close preferences dialog.
    3) Open preferences dialog.
    You will see vertical scrollbar...

I never see the vertical scrollbar, except momentarily dragging down from
minimum height and back up again. 

---

I just did a lot of testing of file import and dragging behaviour on Ubuntu and
Windows 7 (Unicode Release). Pretty good, but some points:

* In out-of-box state (launch with initialised .cfg), unable to import any native
    formats via FFmpeg using OpenFile

* State of override filter affects behaviour even when there are no rules

* If rule states to use FFmpeg and override checked, you have to select the
    specific format to get the native importer, not just "All supported files".
   That  "may" be unexpected given pre-ExtendedImport behaviour


Details at:
http://wiki.audacityteam.org/wiki/User_talk:Galeandrews#extimp




Gale

On 21.04.2010 14:57, Gale Andrews wrote:
> | From LRN <lrn1986@...> 
> | Sun, 11 Apr 2010 18:12:06 +0400
> | Subject: [Audacity-devel] Extended import filtering
>   
>> On 11.04.2010 16:19, Gale Andrews wrote:
>>     
>>> | From LRN <lrn1986@...> 
>>> | Sat, 10 Apr 2010 20:48:29 +0400
>>> | Subject: [Audacity-devel] Extended import filtering
>>>   
>>>       
>>>> On 10.04.2010 19:50, Gale Andrews wrote:
>>>>         
>>>>> Drag n' drop does not work for me, either with a cheap ball mouse on 
>>>>> Linux or with my mouse emulator on Windows (yes, both real and 
>>>>> emulated mouse can drag and drop properly) :=).
>>>>>   
>>>>>       
>>>>>           
>>>> That's weird. But then, i've developed that on Windows. Drag'n'drop
>>>> seems to be very platform-dependent, maybe i've missed something.
>>>>     
>>>>         
>>> Another user has confirmed drag n drop does not work in my "Nightly" 
>>> (in Vista, Logitech optical mouse). 
>>>   
>>>       
>> Seems that i will have to test it myself after all :(
>>
>> Do you have the same problems with debug builds?
>>     
> Yes, Unicode Debug on Windows and Ubuntu has the same problem. Can't 
> drag with any type of real or virtual mouse I have here. 
>   
Maybe you're dragging them the wrong way? You have to select an item
first, then drag it (if you drag without selecting, you'll just select
multiple items).
I've tested drag'n'drop reordering on Windows 7 (inside VirtualBox) and
it worked.
>> It's normal for a scrollbar to appear and disappear when a control
>> changes its size, it's how WinAPI-based GUI works. I doubt that it's
>> really a wxBug. It might be an intersection of the ways window resizing
>> is handled by wx and by ShuttleGUI.
>>     
>> Do you have XP theme (blue one) or some other theme? I think that is
>> important too (i have Windows Classic theme).
>>     
> The XP theme. And I have Tahoma font (which seems just a little taller 
> than Windows default) on both Windows XP and 7. So in your Win 7 steps:
>
>     1) Resize preferences dialog to minimal height.
>     2) Close preferences dialog.
>     3) Open preferences dialog.
>     You will see vertical scrollbar...
>
> I never see the vertical scrollbar, except momentarily dragging down from
> minimum height and back up again. 
>   
I've seen scrollbar on both Windows XP and Windows 7.
Also, i've found
http://article.gmane.org/gmane.comp.lib.wxwindows.general/67888 - the
guy had the same problem.
Also, if i set up a few breakpoints and make preferences dialog window
visible all the time without covering it with other windows, and if i
trace the OnSize event handling, i can see that the treeview changes its
size a few times before settling in that strange
wider-than-it-should-be-but-without-a-scrollbar state.
> ---
>
> I just did a lot of testing of file import and dragging behaviour on Ubuntu and
> Windows 7 (Unicode Release). Pretty good, but some points:
>
> * In out-of-box state (launch with initialised .cfg), unable to import any native
>     formats via FFmpeg using OpenFile
>   
That is expected. Override is disabled by default. Without override AND
without any rules it's impossible to use libav* importer on native
formats. So you have to either enable override (to return to old
behaviour with OpenFile dialog filter choice overriding the rules) or
add some rules.
> * State of override filter affects behaviour even when there are no rules
>   
This is also expected. There is a default rule that kicks in when no
matching rules are found (or when there are no rules), this rule has
filters in hardcoded order (as they were before ExtImport). Override is
still able to affect this rule.
> * If rule states to use FFmpeg and override checked, you have to select the
>     specific format to get the native importer, not just "All supported files".
>    That  "may" be unexpected given pre-ExtendedImport behaviour
>   
Yes, that is unexpected. I think this is easily fixable - i'll make sure
that default rule is used when override is unable to pinpoint a single
filter (such as when "All supported files" is selected).

On 21.04.2010 15:34, LRN wrote:
> On 21.04.2010 14:57, Gale Andrews wrote:
>   
>> | From LRN <lrn1986@...> 
>> | Sun, 11 Apr 2010 18:12:06 +0400
>> | Subject: [Audacity-devel] Extended import filtering
>>   
>>     
>>> On 11.04.2010 16:19, Gale Andrews wrote:
>>>     
>>>       
>>>> | From LRN <lrn1986@...> 
>>>> | Sat, 10 Apr 2010 20:48:29 +0400
>>>> | Subject: [Audacity-devel] Extended import filtering
>>>>   
>>>>       
>>>>         
>>>>> On 10.04.2010 19:50, Gale Andrews wrote:
>>>>>         
>>>>>           
>>>>>> Drag n' drop does not work for me, either with a cheap ball mouse on 
>>>>>> Linux or with my mouse emulator on Windows (yes, both real and 
>>>>>> emulated mouse can drag and drop properly) :=).
>>>>>>   
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> That's weird. But then, i've developed that on Windows. Drag'n'drop
>>>>> seems to be very platform-dependent, maybe i've missed something.
>>>>>     
>>>>>         
>>>>>           
>>>> Another user has confirmed drag n drop does not work in my "Nightly" 
>>>> (in Vista, Logitech optical mouse). 
>>>>   
>>>>       
>>>>         
>>> Seems that i will have to test it myself after all :(
>>>
>>> Do you have the same problems with debug builds?
>>>     
>>>       
>> Yes, Unicode Debug on Windows and Ubuntu has the same problem. Can't 
>> drag with any type of real or virtual mouse I have here. 
>>   
>>     
> Maybe you're dragging them the wrong way? You have to select an item
> first, then drag it (if you drag without selecting, you'll just select
> multiple items).
> I've tested drag'n'drop reordering on Windows 7 (inside VirtualBox) and
> it worked.
>   
Just tested on Debian lenny/squeeze - drag'n'drop rule sorting works as
expected. I could try to change it to be a bit more fine: select item in
1 click, and initiate dragging right after that if mouse is moved with
the button still pressed (i.e. no need to select in 1 click, then start
dragging in another click-and-hold), and forbid multiple selection. But
don't get too excited, i might not be possible.

Ctrl+Up/Down sorting of filters shows some weirdness - filters jump more
than one row up when i moved them (Move Filter Up/Down buttons do not
show such behaviour, though, i guess it has something to do with default
up/down keypress handling being different on Windows and GTK).

| From LRN <lrn1986@...> 
| Thu, 22 Apr 2010 21:06:01 +0400
| Subject: [Audacity-devel] Extended import filtering
> On 21.04.2010 15:34, LRN wrote:
> > On 21.04.2010 14:57, Gale Andrews wrote:
> >>>>> On 10.04.2010 19:50, Gale Andrews wrote:
> >>>>>> Drag n' drop does not work for me, either with a cheap ball mouse on 
> >>>>>> Linux or with my mouse emulator on Windows (yes, both real and 
> >>>>>> emulated mouse can drag and drop properly) :=).
> >>>> Another user has confirmed drag n drop does not work in my "Nightly" 
> >>>> (in Vista, Logitech optical mouse). 
> >>>>         
> >>> Seems that i will have to test it myself after all :(
> >>>
> >>> Do you have the same problems with debug builds?
> >>>       
> >> Yes, Unicode Debug on Windows and Ubuntu has the same problem. Can't 
> >> drag with any type of real or virtual mouse I have here. 
> >>   
> >>     
> > Maybe you're dragging them the wrong way? You have to select an item
> > first, then drag it (if you drag without selecting, you'll just select
> > multiple items).
> > I've tested drag'n'drop reordering on Windows 7 (inside VirtualBox) and
> > it worked.
> >   
> Just tested on Debian lenny/squeeze - drag'n'drop rule sorting works as
> expected. I could try to change it to be a bit more fine: select item in
> 1 click, and initiate dragging right after that if mouse is moved with
> the button still pressed (i.e. no need to select in 1 click, then start
> dragging in another click-and-hold), and forbid multiple selection. But
> don't get too excited, i might not be possible.

OK, I wasn't even trying to drag rules, but trying to drag filters (which is 
what I need to change). The order in which the rules appear in the list does
not affect behaviour does it? 

Yes I can drag a rule easily with real or virtual mouse. Click the extension 
to move, move icon appears, and drag (without releasing mouse). That's 
what I would have expected, just like you drag tracks in Audacity or files 
in Explorer. 

The list of filters is just "dead" though for me (not even a multi-select when
clicking and dragging). Did I miss something that you can't drag filters, only 
rules?   
 
I have some apps that behave like you say in a list (click and drag 
multi-selects, you have to release to drag the selected item). I don't regard 
that as intuitive though. Where multiple selection has any purpose, I'd expect 
to CTRL + click to multi-select, and SHIFT + click (or SHIFT + Up/Down) to 
select adjacent items. The rules list does multiple select like that, but does 
not move multiple items.

 
> Ctrl+Up/Down sorting of filters shows some weirdness - filters jump more
> than one row up when i moved them (Move Filter Up/Down buttons do not
> show such behaviour, though, i guess it has something to do with default
> up/down keypress handling being different on Windows and GTK).

I did not know you could CTRL + Up/Down on the filters, but I see similar on 
Ubuntu to what I think you are saying. Holding CTRL, the first Up press 
moves the item that was selected up one, then the item above that becomes
selected, and that item moves up one when you press Up again. So, I can 
only move the item I wanted to move up/down one step by that method. 

CTRL + Up/Down on filters does work correctly for me on Windows, and 
works on Ubuntu too for the rules. 




Gale

On 23.04.2010 0:12, Gale Andrews wrote:
> | From LRN <lrn1986@...> 
> | Thu, 22 Apr 2010 21:06:01 +0400
> | Subject: [Audacity-devel] Extended import filtering
>   
>> On 21.04.2010 15:34, LRN wrote:
>>     
>>> On 21.04.2010 14:57, Gale Andrews wrote:
>>>       
>>>>>>> On 10.04.2010 19:50, Gale Andrews wrote:
>>>>>>>               
>>>>>>>> Drag n' drop does not work for me, either with a cheap ball mouse on 
>>>>>>>> Linux or with my mouse emulator on Windows (yes, both real and 
>>>>>>>> emulated mouse can drag and drop properly) :=).
>>>>>>>>                 
>>>>>> Another user has confirmed drag n drop does not work in my "Nightly" 
>>>>>> (in Vista, Logitech optical mouse). 
>>>>>>         
>>>>>>             
>>>>> Seems that i will have to test it myself after all :(
>>>>>
>>>>> Do you have the same problems with debug builds?
>>>>>       
>>>>>           
>>>> Yes, Unicode Debug on Windows and Ubuntu has the same problem. Can't 
>>>> drag with any type of real or virtual mouse I have here. 
>>>>   
>>>>     
>>>>         
>>> Maybe you're dragging them the wrong way? You have to select an item
>>> first, then drag it (if you drag without selecting, you'll just select
>>> multiple items).
>>> I've tested drag'n'drop reordering on Windows 7 (inside VirtualBox) and
>>> it worked.
>>>   
>>>       
>> Just tested on Debian lenny/squeeze - drag'n'drop rule sorting works as
>> expected. I could try to change it to be a bit more fine: select item in
>> 1 click, and initiate dragging right after that if mouse is moved with
>> the button still pressed (i.e. no need to select in 1 click, then start
>> dragging in another click-and-hold), and forbid multiple selection. But
>> don't get too excited, i might not be possible.
>>     
> OK, I wasn't even trying to drag rules, but trying to drag filters (which is 
> what I need to change).
LOL, that's what people call "miscommunication". Drag'n'drop for filters
(the list on the right) IS NOT implemented yet.
>  The order in which the rules appear in the list does
> not affect behaviour does it? 
>   
It does. They are evaluated from top to bottom.
> Yes I can drag a rule easily with real or virtual mouse. Click the extension 
> to move, move icon appears, and drag (without releasing mouse). That's 
> what I would have expected, just like you drag tracks in Audacity or files 
> in Explorer. 
>   
Good.
> The list of filters is just "dead" though for me (not even a multi-select when
> clicking and dragging). Did I miss something that you can't drag filters, only 
> rules?
>   
Yes, exactly. Simply not implemented yet.
>  
> I have some apps that behave like you say in a list (click and drag 
> multi-selects, you have to release to drag the selected item). I don't regard 
> that as intuitive though. Where multiple selection has any purpose, I'd expect 
> to CTRL + click to multi-select, and SHIFT + click (or SHIFT + Up/Down) to 
> select adjacent items. The rules list does multiple select like that, but does 
> not move multiple items.
>   
Moving multiple items at once might be...cumbersome...The code is
already too complicated and ugly. I would rather disable the ability to
select more than one item.
It's not like people are going to tinker with this thing five times per
day...

| From LRN <lrn1986@...> 
| Fri, 23 Apr 2010 00:22:09 +0400
| Subject: [Audacity-devel] Extended import filtering
> On 23.04.2010 0:12, Gale Andrews wrote:
> > | From LRN <lrn1986@...> 
> > | Thu, 22 Apr 2010 21:06:01 +0400
> > | Subject: [Audacity-devel] Extended import 
> 
> >  ... The order in which the rules appear in the list does
> > not affect behaviour does it? 
>    
> It does. They are evaluated from top to bottom.

OK.  Please include this in your eventual documentation, with a practical 
example of the difference the rule order makes (for example if it affects 
what happens when importing multiple files). 

   
> > I have some apps that behave like you say in a list (click and drag 
> > multi-selects, you have to release to drag the selected item). I don't regard 
> > that as intuitive though. Where multiple selection has any purpose, I'd expect 
> > to CTRL + click to multi-select, and SHIFT + click (or SHIFT + Up/Down) to 
> > select adjacent items. The rules list does multiple select like that, but does 
> > not move multiple items.
> >   
> Moving multiple items at once might be...cumbersome...The code is
> already too complicated and ugly. I would rather disable the ability to
> select more than one item.
> 
> It's not like people are going to tinker with this thing five times per
> day...

Personally I'm OK with disabling move of multiple items. I think a lot
of people won't figure you can drag all until it's documented.   

You say you used undocumented EnableDragCell() method for RuleTable 
multi-item drag selection.  Anyway, I can't drag multiple selected rules 
with the "real" mouse.  In fact, the rules list is less functional now for me,
because I could previously select and drag a single rule without releasing 
the mouse. I tried that many times. That's not possible now unless the rule 
was already selected. 

Unfortunately the fix for CTRL + Up/Down in the filter list breaks selecting
a rule then clicking the "Move Filter up/down" button (or using the access
key). The row of the originally selected item remains selected, so all "Move
Filter up" now does is move the filter you selected up one, then back down
again. 

I'll try and test your fixes for override behaviour soon.




Gale

On 24.04.2010 1:36, Gale Andrews wrote:
> | From LRN <lrn1986@...> 
> | Fri, 23 Apr 2010 00:22:09 +0400
> | Subject: [Audacity-devel] Extended import filtering
>   
>> On 23.04.2010 0:12, Gale Andrews wrote:
>>     
>>> | From LRN <lrn1986@...> 
>>> | Thu, 22 Apr 2010 21:06:01 +0400
>>> | Subject: [Audacity-devel] Extended import 
>>>       
>>     
>>>  ... The order in which the rules appear in the list does
>>> not affect behaviour does it? 
>>>       
>>    
>> It does. They are evaluated from top to bottom.
>>     
> OK.  Please include this in your eventual documentation, with a practical 
> example of the difference the rule order makes (for example if it affects 
> what happens when importing multiple files). 
>
>    
>   
>>> I have some apps that behave like you say in a list (click and drag 
>>> multi-selects, you have to release to drag the selected item). I don't regard 
>>> that as intuitive though. Where multiple selection has any purpose, I'd expect 
>>> to CTRL + click to multi-select, and SHIFT + click (or SHIFT + Up/Down) to 
>>> select adjacent items. The rules list does multiple select like that, but does 
>>> not move multiple items.
>>>   
>>>       
>> Moving multiple items at once might be...cumbersome...The code is
>> already too complicated and ugly. I would rather disable the ability to
>> select more than one item.
>>
>> It's not like people are going to tinker with this thing five times per
>> day...
>>     
> Personally I'm OK with disabling move of multiple items. I think a lot
> of people won't figure you can drag all until it's documented.   
>
> You say you used undocumented EnableDragCell() method for RuleTable 
> multi-item drag selection.
To be precise, this function (when called with 'true' argument, like i
did) disables drag-to-select-multiple-items behaviour of wxGrid. That
is, you can't select multiple items by dragging anymore.
>   Anyway, I can't drag multiple selected rules 
> with the "real" mouse.
Because you can't select multiple items (maybe you can do that with
keyboard? Remind me to fix that too).
>   In fact, the rules list is less functional now for me,
> because I could previously select and drag a single rule without releasing 
> the mouse. I tried that many times.
Fixed that.
>  That's not possible now unless the rule 
> was already selected. 
>   
That is how that worked on Windows all the time, until my last commit.
> Unfortunately the fix for CTRL + Up/Down in the filter list breaks selecting
> a rule then clicking the "Move Filter up/down" button (or using the access
> key). The row of the originally selected item remains selected, so all "Move
> Filter up" now does is move the filter you selected up one, then back down
> again. 
>   
Fixed.
> I'll try and test your fixes for override behaviour soon.
>
>   
Don't. I've introduced an error that causes a segfault on Linux.
Investigating it now.

On 24.04.2010 2:38, LRN wrote:
> On 24.04.2010 1:36, Gale Andrews wrote:
>   
>
>> I'll try and test your fixes for override behaviour soon.
>>
>>   
>>     
> Don't. I've introduced an error that causes a segfault on Linux.
> Investigating it now.
>   
OK, false alarm. After a clean rebuild it doesn't crash anymore. Go
ahead, try it :)

| From LRN <lrn1986@...> 
| Sat, 24 Apr 2010 03:52:59 +0400
| Subject: [Audacity-devel] Extended import filtering
> On 24.04.2010 2:38, LRN wrote:
> > On 24.04.2010 1:36, Gale Andrews wrote:
> >   
> >
> >> I'll try and test your fixes for override behaviour soon.
> >>
> >>   
> >>     
> > Don't. I've introduced an error that causes a segfault on Linux.
> > Investigating it now.
> >   
> OK, false alarm. After a clean rebuild it doesn't crash anymore. Go
> ahead, try it :)

Well, on Ubuntu I just did an update and configure/make/install. I get 
a reproducible crash either opening preferences, or if not, on OK after 
going into it.

When I was in Prefs, I noticed that "Extended Import" in the tree had 
no text. When selected, the item just shows a narrow selection to left 
of where the text should be. 

The console error suggests memory corruption (attached). 

I did get long enough in Prefs though to see that all the problems with 
dragging and moving (single) rules or filters seem to have been solved 
(same on Windows).

 
>>   Anyway, I can't drag multiple selected rules 
>> with the "real" mouse.
> Because you can't select multiple items (maybe you can do that 
> with keyboard? Remind me to fix that too).

The only way I can now seem to select any multiple rules is to select
one, then hold SHIFT with Up/Down. I can't drag those multiple items, 
or move them together in any way. I can't select multiple filters at 
all. All the above is true both on Windows XP and Linux.     


Thanks,



Gale

On 24.04.2010 13:26, Gale Andrews wrote:
> | From LRN <lrn1986@...> 
> | Sat, 24 Apr 2010 03:52:59 +0400
> | Subject: [Audacity-devel] Extended import filtering
>   
>> On 24.04.2010 2:38, LRN wrote:
>>     
>>> On 24.04.2010 1:36, Gale Andrews wrote:
>>>   
>>>
>>>       
>>>> I'll try and test your fixes for override behaviour soon.
>>>>
>>>>   
>>>>     
>>>>         
>>> Don't. I've introduced an error that causes a segfault on Linux.
>>> Investigating it now.
>>>   
>>>       
>> OK, false alarm. After a clean rebuild it doesn't crash anymore. Go
>> ahead, try it :)
>>     
> Well, on Ubuntu I just did an update and configure/make/install. I get 
> a reproducible crash either opening preferences, or if not, on OK after 
> going into it.
>   
Great. What are your configure options/flags? I've tried
make clean && ./configure && make
and the resulting binary does not crash anymore.
Just in case, i've made a small change in dialog initialization, see if
that helps.

Backtrace isn't very verbose - as far as i understand, it points to
ExtImportPrefs constructor, but tells nothing else. Maybe the problem is
in this
:   PrefsPanel(parent, _("Extended Import")), RuleTable(NULL),
    PluginList(NULL), mCreateTable (false), mDragFocus (NULL),
    last_selected (-1), mFakeKeyEvent (false)
bit of code (i believe it is a constructor initialization list and a
parent constructor call)? That would also explain why you didn't see a
label in the tree, because this is where it is created.
This doesn't happen on Ubuntu in debug build, i presume?
>   
>>>   Anyway, I can't drag multiple selected rules 
>>> with the "real" mouse.
>>>       
>> Because you can't select multiple items (maybe you can do that 
>> with keyboard? Remind me to fix that too).
>>     
> The only way I can now seem to select any multiple rules is to select
> one, then hold SHIFT with Up/Down. I can't drag those multiple items, 
> or move them together in any way. I can't select multiple filters at 
> all. All the above is true both on Windows XP and Linux.
>   
Will disable shift-multi-selection once the crash is gone.

On Sat, 2010-04-24 at 10:26 +0100, Gale Andrews wrote:
> Well, on Ubuntu I just did an update and configure/make/install. I get 
> a reproducible crash either opening preferences, or if not, on OK after 
> going into it.
You missed the
make dep
step to update object dependencies on header files. If it still doesn't
work after that, then something deeper is wrong. Without that, not
surprising it's not working, because header file changes in class
definitions are not being propagated to object files.

Richard

On 24.04.2010 14:38, Richard Ash wrote:
> On Sat, 2010-04-24 at 10:26 +0100, Gale Andrews wrote:
>   
>> Well, on Ubuntu I just did an update and configure/make/install. I get 
>> a reproducible crash either opening preferences, or if not, on OK after 
>> going into it.
>>     
> You missed the
> make dep
> step to update object dependencies on header files. If it still doesn't
> work after that, then something deeper is wrong. Without that, not
> surprising it's not working, because header file changes in class
> definitions are not being propagated to object files.
>   
So, the correct way is to
configure
make dep
make
? (i generally don't need to install, running Audacity from builddir)

On Sat, 2010-04-24 at 14:48 +0400, LRN wrote:
> So, the correct way is to
> configure
> make dep
> make
> ? (i generally don't need to install, running Audacity from builddir)

Yes, although if configure and the Makefile.in's haven't changed, you
can skip the configure step.

Running from the install directory will work, but can catch you out,
because of files loaded from the environment, which tend to come from
your installed copy not the SVN copy - I'm trying to look at this at the
moment, will come back to you.

For this purpose (where loading files isn't needed), you won't have
problems.

Richard