Re: [Audacity-devel] Mac - Slash in Filename Patch

[Richard A. <ri...@au...>]

On Sat, 2008-02-02 at 09:39 -0600, Brett Park wrote:
> On 2-Feb-08, at 6:01 AM, Richard Ash wrote:
> > My only problem with this would be the fact we are adding the same  
> > code
> > to two different places, once in FileDialog and once in
> > PlatformCompatibility. This is a problem from a maintenance point of
> > view, especially if we want to separate FileDialog out more in the
> > future.
> 
> I agree with you. The whole reason why I made two different copies of  
> the same function was to maintain the independence of the FileDialog  
> "library". I personally hate duplicate code, however, in this case it  
> seemed like the best option.
> 
> > The offending ConvertSlashInFileName() function is stateless, and
> > doesn't reference the object at all, so it could be a static method of
> > any class provided it can be called from the relevant places.  
> > Ideally it
> > would be a utility function in wxwidgets somewhere (wxFileName or
> > wxString presumably). Given in the short term we can't do that, we  
> > want
> > to find a home for it somewhere else, where it won't be a pain to
> > migrate to having it in wx eventually.
> 
> The best place for this patch is wxwidgets in my own opinion. The  
> issue really is with how the wxFileName functions work. It simply uses  
> the last / as the end of the path and the start of the filename. The  
> function I created adds file checking in order to guess which part of  
> the string is the filename and which part is the path. Because of the  
> guessing, the function won't work correctly 100% of the time, but it  
> will work better than what exists currently.

That's what I thought. I've got a couple of bones to pick with
wxFileName already because it's list of invalid characters for Linux is
wrong, and there is no way of check the validity of a proposed file name
against that list (you have to write a function to do it, which is a
messy route).

> > Unfortunately I'm not at all sure where this would be, because we want
> > to use it from both audacity and FileDialog (if it was just audacity,
> > then PlatformCompatibility is the right place). If we put it somewhere
> > public in FileDialog, would it be a pain to make it usable in the  
> > right
> > places in audacity as well?
> 
> I personally don't like the idea of putting it only in the FileDialog  
> object as converting slashes in a filename really doesn't have  
> anything to do with a File Dialog box. Do you think that the  
> FileDialog "library" should be changed to be a File "library" which  
> would contain the FileDialog object as well as a File object. If a  
> File object was created the filename and path could be stored in two  
> separate strings so the slash conversion could be done without  
> guessing. Also, if a File object was created the FileDialog object  
> would have access to it, as well Audacity would would have access to  
> it. Sound like a good idea? (I'm not entirely sure why FileDialog is  
> in a library of its own to begin with).

FileDialogue is in a library of it's own because it links to
platform-specific code, rather than going through wx. This was the only
way we could handle putting the extra options button into the dialogue,
because wx doesn't have a way of doing so. Because this is a cludge, and
we would like to see it done through wx eventually we (Leyland mostly)
put it in a separate library to keep it out of core audacity.

Richard