While looking through the source code dealing with file handling, I came across two pieces of Windows-specific code, one in “App::dialog_open_file()” and the other in “App::dialog_save_file()” in “synfig-studio/src/gtkmm/app.cpp”, that apparantly are not used. The code is guarded by #ifdef’s, with the parameter “USE_WIN32_FILE_DIALOGS”, but the #define of USE_WIN32_FILE_DIALOGS is commented out, and the value is not defined anywhere else in the repository!
What’s more, the Windows-specific code hasn’t changed since it was originally imported in the Subversion (svn) repository (on march 24, 2005), but the generic (non-Windows code) has, mainly the “App::dialog_save_file()” code, with the latest changes in february/march 2008. So, if I’m not mistaken, this is dead code that has not been used in over three years and that cannot be used.
Therefore, in the interest of source code clarity and comprehensibility, I propose that we remove these two pieces of code.
While having Windows specific code is fine in principle, these two specific pieces of code cannot simply be turned on again. The current code is simply too old and has not been maintained in the last three years.
This lack of maintainance can be most easily shown with the Subversion annotate functionality (svn blame). If you look at the method App::dialog_open_file(), the windows-specific lines are on 1801-1841 and the generic lines are on 1843-1873. If you look with the annotate function, you’ll see that the windows-specific code is all from the original import by darco in revision 8, on 2005-03-24. It has not changed since! But if you look at the generic code, you’ll see that the latest changes were committed in revision 1456, by dooglus on 2008-01-24. The same can be said for App::dialog_save_file(), the windows-specific lines (1927-1967) are from revision 8, and the latest change to the generic lines (1969-2031) was made dooglus, in revision 1879 on 2008-03-08. Here the difference in the code is clear when you compare the complexity of the windows specific code to the complexity of the generic code.
I don’t think the code holds any value in itself, but it does distract and confuse people that try to understand this code. To put it succintly: I think it’s a liability, not an asset.
A windows developer could obviously update this code, but is that really the best use of his time?
Pabs, I don’t necessarily disagree with your comments, but they do seem rather general. Have you examined the actually lines of code I’m talking about? I hope I have made clear that I have (i.e., I’m not making a rushed judgement). Almost half the lines of the Windows-specific code are already commented out; and, of the other half, most lines are assignment statements. I simply cannot relate your general comments to the specifics of the code. Why do you think these specific lines hold value? Why do you think these lines would help pixelgeek with writing new file handling code? Can you give us some details? Explain a bit more?
I took a look at the code. I don’t think it’s going to help much if/when someone ever does get around to trying to implement Windows native dialog boxes. I’m sure there are more complete examples out there.