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:
> 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
>> 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
> 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
>>> 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
> 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:
> When you select another node in the tree, the problem corrects itself.
This is caused by the scrollbar being shown and hidden again.