MAC OS version

[mrbogus27]

> FFS uses a frame because when running as a batch job, the copy progress acts as the main window.

Maybe you could just use wxWindow::MakeModal function?

[Zenju]

Hm, if I made the progress window modal, it would naturally disable its parent, the main dialog. On Windows this prevents the user from minimizing the main dialog so that it can minimize to systray. AFAIR this was also the reason why I changed the progress dialog to a frame when running FFS as a batch job. Modal and non-modal dialogs require a different allocation strategy (stack vs heap), so implementing a platform-specific solution doesn't seem simpler than finding a way to select between wxFrame and wxDialog for the progress dialog - which is the most wxWidgets-conformant solution.

[cecilyen]

> resizing the window is relatively slow

I believe this has to do with OS X double-buffering all graphics output by default. I see the same slow performance for GTK, e.g. on Ubuntu Linux. On Windows on the other hand it's the application's responsibility to double buffer, which seems to work a lot faster. The drawback is a little more flicker if one isn't careful. Also on windows there is a flag to apply double-buffering generally: SetDoubleBuffered()/WS_EX_COMPOSITED. The result is the same slow performance like on Linux and OS X. It's possible though, that this is a wxWidgets performance bug, where they apply double-buffering unconditionally without checking first if the OS does this already. I found this to be the case with wxComboBoxControl and a few other places. But I'm not sure if this is enough to completly explain the slowdown on Linux/OSX.

> if you want to scroll in the file list, you have to use the scrollbar and can not scroll inside the file list as usual

I fixed this.

> the gui looks kind of strange (not mac-like ;-))

There is a lot of small stuff that's not quite right yet. For example all the font sizes that I set larger than default, like the big "comparison" and "synchronize" button texts, are very small on OS X. Also a lot of button graphics do not look good (view filters) because there is not enough room towards the button borders. I fixed the same issue bluntly on GTK by just changing the OS defaults to not show fancy frames around the buttons. Maybe it's time to revise this and make it right.

But besides the obvious graphical issues. What are the most important points about design convention that OS X users expect and that FFS does not get right? One important point seems they expect an order of "Default, Cancel, Okay" with a big gap before the "Okay". Are there similar points that I should be aware of?

Another thing is that both FFS and RTS packages share a lot of resource files which bloats the overall package sizes. Is there some way to share the resources of these two apps?

> drag and drop does not work

This is still a todo.

> i try to sync with a network share, and there are files like ._ for each file which is .
> there is the file "About Downloads" (in the Downloads folder, from Apple) which seem to be a package,
> like app packages. These packages are displayed as folders, not as a single file.
> You should treat mac packages as one file (like they appear in the finder), not as a folder.

This means I would have to show users one "logical view" but internally work with the "real view", i.e. the view that the posix layer has on the files. I don't think this is really worthwhile to implement, for one it would require a lot of non-portable shell-layer code and a redesign affecting FFS's core routines. On the other hand there is no functional advantage and power users might event want to see the "real view". For Windows there is the same distinction between shell and kernel layer. FFS generally works at kernel layer, so far without any real complaints from users. At this point it's best to just wait and see if there is a demand for this at all.

> the file date of copied files is changed to the current date and time and not preserved. So after a sync, when you analyze
> the directories again, FFS sees a different date, and wants to copy the files back from the new to the old directory.

FFS correctly calls "utime" and reports failure codes it receives. In my tests on a local volume this worked correctly. If "utime" is not the correct API to call on OS X, I'll change it. To be investigated.


> Note: I got the same error for both apps. THe one above was for freefilesync.app.
> In this discussion, some people talk about setting the deployment target to 10.7 in Xcode:

I set the 10.7 sdk when compiling wxWidgets, but not for boost and FreeFileSync. Maybe there's currently a mixture of 10.7 and 10.8 SDKs, latter of which is selected by default if nothing else is specified.
I made a test and recompiled FFS using the "isysroot" command, then compared the dynamic library dependencies. It definitively did something as can be seen on the diff screenshot attached. BUT I did not yet re-compile boost to consider the 10.7 sdk, so this could still cause trouble. Anyway let's test again with the new version. I've updated the link below:
[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_5.13_OSX_10.7_64bit.zip]

FreeFileSync 5.13 crashed right after I run it on my Mac 10.6.8.

[fgirault]

Hi just for the record: I synchronized some 500GB of data with your latest version, with pauses inbetween and computer going to sleep etc, wifi connection drops etc...
It works pretty fine! I think it's safe to say that you can release it as a beta version for Mac OS.
Thank you very much for your work Zenju!

[Zenju]

> I synchronized some 500GB of data with your latest version

Thanks a lot for your tests! Although there is still a bunch on my todo (file icon loading is next), it's good to hear that the core functionality is working reliably. I find a lot of small stuff myself when testing (e.g. noticed and fixed already that opening external applications was not working for non-ascii file names), but I appreciate feedback on the things I miss.

[sagantech]

I get crashes upon startup running under 10.5.8 or 10.6.x (Dyld Error Message: unknown required load command 0x80000022). Any chance this could be made to work for those OS's? Also are the data files cross platform?

[Zenju]

@Jerm: FFS requires OS X 10.7 and later (which is a requirement of libc++ and clang). I updated the bundle with this version information, so that starting with next release, at least the error message won't be that obscure anymore.

[Zenju]

Just finished implementing file icons for the preview list:

[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_5.14_Mac_OS_X_64-bit_beta.zip]