Sneak peek of Caedium running as a native application under Mac OS X. The screenshot shows an airflow simulation around an F1 in Schools dragster.
Find out more in our February 2010 Newsletter.
Sorry to be a Mac bullyboy, but shouldn't a "native" app be written in Cocoa/ Objective-C?
This looks like a PC app that has been developed for Mac in the Qt Framework, all those 'save' and 'open' cheesy windows-like folder icons in the main window, when the finder already has these functions as both mouse clicks and key commands, just above- it's a mess, and something that really should be avoided! It's nice though that you are releasing Caedium for Mac, so thanks, but, hey, let's just get these things right eh?
We use wxWidgets as our cross-platform GUI toolkit, not Qt. wxWidgets uses the native underlying GUI system Carbon/Cocoa, so in my mind that makes Caedium a native Mac application.
While the GUI is an essential element of an application, there is also the fact that the majority of the code in Caedium (and in other CAE systems) is hidden behind the GUI facade and it is that code that determines the speed and efficiency of an application to a large extent - here I'm talking about geometry engine, mesh generators, flow solvers and 3D visualization - all these elements are likely to perform better compiled natively (as opposed to running say in a virtual machine as is the case with Parallels) and that is another important point to note here.
Thanks for the feedback on the toolbar icons. I didn't realize that having 'new object' (not just file) and 'save' as a convenience on a toolbar was considered bad form on the Mac.
Of course! Isn't Blender too, also made with wxWidgets? It's the wxWidgets' Carbon look/function that is at fault. It's horrible. Please don't get me wrong, I'm not having a go at your software, but I suppose what I am referring to is an interface standard that's set by Apple, for their computers. Other developers who are using Objective-C's Interface Builder, all share an exact (or pretty near exact) common denominator. This type of working assures that all interfaces for the Mac remain similar, therefore much improving workflow. I notice that all Carbon apps fail to make use of Apple Services function also available in the menu. Many carbon apps that I've seen also completely fail on the way files are handled whether opening or saving. I think it is really important to also get that right- hence following the code. If you are unsure of what one of these apps looks like, take a look at Apple's own Finder or Preview app for starters. If you need to look at CAD, Rhino or SketchUp, PowerCADD, even Solidwork's eDrawings app was created this way!
Don't get me wrong, it's absolutely great and I'm thrilled that you are bringing Caedium/ CAE to the Mac platform and do I appreciate how much code is involved behind the main window, however, If you build Caedium in accordance to Apple's GUI guidelines, and in Objective-C, it will, in the long run, be highly beneficial for your company, because Caedium will behave in the same manner as other Cocoa/ Objective-C apps, with the Interface Builder made GUI, thus far improving workflow, and interpolarity with other Cocoa apps, and the Mac OSX GUI as a whole.
Sorry to be a right bore, but this is why you must write Caedium in Cocoa Obj-C;
Joe Dunne, SolidWorks’ director of technical marketing, confirmed, “We’re working on several concepts. One of the concepts is definitely running SolidWorks as a native Mac app, in addition to the no-install (browser-based) version … So you can run it on a Mac or run on a Mac machine using a browser — take your pick.”
Just think- you could be there first, partnering to Solidworks (and/or Rhino) using the same and therefore 100% compatible technologies! fwiw, e-Drawings is already Cocoa native. e-Drawings on Mac is dynamite. IMHO, It is better than the PC version!