What concerns me about this screenshot is that it so much looks like the Windows version.
As far as I can tell, the font is Tahoma — the default on Windows, while the Mac default is Lucida Grande. A curious choice in that this would make the application fit in worse with the rest of the Mac UX. Though, if this were a WINE port, Lucida Grande wouldn't be accessible, so you couldn't use that. Tahoma, on the other hand, is probably the font in WINE that renders the best, if you also use the (illegal) freetype patch enabling ClearType-like subpixel hinting.
The screenshot has been sized down, which makes it impossible to see if the font rendering engine is indeed native Quartz, or say, that of an X11 used by WINE. Which would mean worse antialiasing that what we're used to. We also can't see the system menu bar to pick out what it says about the running application.
The menus are situated inside the main window, a feat that would have you jump through hoops to implement if you are indeed porting this as a native Mac Cocoa app, where you'd normally just use the menu system provided by the OS/Cocoa — saving boatloads of developer time and making an application that would integrate properly with rest of the OS (e.g. hooking into services and allowing one to control keyboard shortcut to menu mappings). Of course, if it were ported using WINE as a wrapper, the opposite would be true: it would be very hard to get the menus out of the main window and integrate with Mac OS X properly.
The window control buttons are at the right, as in Windows, and sport the same appearance as in Windows. Again, this would be something that would require extra work for the developer to not use the regular ones offered by Cocoa. Yet again, if it were a WINE-based port, getting native Mac window control buttons would probably be close to impossible.
Overall, the GUI widgets look exactly like the skinned Windows ones that we know from the native Windows version. Again a feat that would require much work by a developer to make happen in a native Cocoa app. In WINE, on the other hand, the opposite would again be true.
This looks so much like the early Picasa builds for Mac and Linux, which used WINE as a wrapper for the native Windows application. Doing so has some drawbacks with regards to font rendering, performance, resources usage, multiple display servers, UI responsiveness and general system integration, but it's not necessarily a deal-breaker.
It's just that in the interest of full disclosure, I have to ask this question:
Is this port a native Cocoa one or is it based on WINE or any derivative of WINE? If not Cocoa-based, is it scheduled to become so? And if yes to that question, when?
Thank you,
Daniel
Author
Topic: Progress and a Screenshot-- February 8, 2013 (Read 11047 times)