In the wikipedia article on Cocoa it says:
There are also open source implementations of major parts of the Cocoa framework that allows cross-platform (including Microsoft Windows) Cocoa application development, such as GNUstep, Cappuccino, and Cocotron.
Yet when I looked into whether Mac application Tweetie was available for windows the developer had ruled it out:
Windows doesn't have Cocoa, the programming environment that Tweetie is made in, as such, it seems like a poor possibility.
I'd like to have an answer to point the Tweetie developers (and as a resource for other cocoa developers) which would tell them:
Which implementation is the most suitable for getting a cocoa app running on windows?
How much work is it likely to take to get the app running under windows?
How easy/hard is it to maintain a common code base for Mac and Windows?
(any other considerations I've missed?)
Of course if it would be too much work I'd like to know that too before suggesting it and potentially sending someone else on a fruitless search.
Don't forget:
“Major parts of the Cocoa frameworks” is not the same as “the entirety of the Cocoa frameworks”. Tweetie could be using something that's missing.
Tweetie could be (very probably is) using APIs from the non-Cocoa frameworks, such as Core Foundation, Core Services, Core Graphics, and Core Animation. A port of the Cocoa frameworks alone won't include any of these APIs, and even a more complete Mac-API-emulation framework will not include all of them.
These frameworks are eternally chasing Apple. Even if they catch up, they'll be instantly behind again as of the next Mac OS X release. Mac developers already put off using new APIs in new Mac OS X releases while they wait for users to upgrade to those new releases; now you're asking atebits to also wait for the other-framework developer to catch up to Apple again.
Any second implementation of an existing API will have bugs that the first implementation doesn't, and vice versa. These differences will cause development and support problems.
You're asking atebits to add a third platform to an application that already exists on two. Supporting one platform is a lot of work. Supporting two platforms is a hell of a lot of work. Supporting three? Now you're getting into big-company territory.
So, even with these Cocoa-like frameworks, the answer is: Hard.
Among GNUstep, Cappuccino and Cocotron, Cocotron is only possible choice to port a Mac application to windows.
Cappuccino is for web and GNUstep only runs on top of cygwin or mingw, which means the GUI looks nothing like native windows apps.
It is theoretically possible to build cocoa windows apps using Cocotron. However, the reality is that it is still very hard to use, and it is still quite limited in the Cocoa API.
Therefore, two possible solutions:
Try hard to remove the codes that are not supported by Cocotron in the original code base and do the cross compilation. Maintaining common code base will be painful.
Start a new GUI at all, no common code base. two choices here
Start a cross platform project with cross application framework such as Qt, or Java.
Start a windows only project. There are a lot of choices here, .Net WinForm application, MFC, etc.
There are Windows compilers for Objective-C (the programming language used to write cocoa apps). However, Cocoa includes the frameworks for presenting the GUI. These visual frameworks are specific to Mac OS X because they use OS X only windows and other controls. So someone would need to re-implement the controls in Cocoa to use Windows controls.
Also, I am fairly certain that Tweetie uses Mac OS X only technologies like Core Animation. This does not exist on Windows, so the nice animation effects present in the apps would have to be implemented in a completely different way.
Related
I have a friend who has an entry-level background in programming and is looking for a free GUI framework (IDE, GUI toolkit and GUI designer ) that:
He can use on Mac OS X to build Windows applications
It's very easy to use.
He is not interested in becoming a programmer, but would like to build an application for his work (not CS-related).
What are some good GUI frameworks/prog. languages he can use?
Qt including Qt Creater and Qt Designer is worth a try.
Especially, if your app should finally run cross-platform, on phones or on other embedded devices. Qt natively supports C++, but can also be used with 3rd-party extensions with Python (PyQt) and probably other languages.
On a Mac I have to recommend making Cocoa applications in Xcode written in Objective-C. Xcode is free to download and use, you pay if you want to submit applications to the Mac App Store.
I personally use Xcode every day and I think it's a great IDE. Currently has compiler support for Obj-C, C++, C and maybe more (not sure). More importantly for your needs, Xcode does a great job of integrating your code with its build in "interface builder" to help you quickly and easily create a nice UI.
NOTE: Xcode includes a new compiler feature (ARC) Automatic Reference Counting which is create for a new user. You can learn the language without having to worry about manual memory management.
Your friend should consider using PySide, a Python binding for the Qt GUI framework already mentioned.
With PySide you can use the Qt tools to create GUI elements interactively
and code your application logic in Python, which is a language often appreciated by non-programmers (and programmers too!) for its simplicity and intuitiveness.
Xcode includes a WYSIWYG editor for native controls and views. This was formerly a separate program called Interface Builder, but the editor was moved into the Xcode IDE at version 4.
AppKit is the framework it uses in most cases -- that's Objective-C. It's well supported. Your friend can also use it for source code editing and building and debugging apps. If he wants to write UIs programmatically, Xcode and AppKit are also good options.
I'm starting to program. Already did some things with Java: a calculator, one document management system powered with a database and some other home projects. But I don't like the visual look. I love however how mi Mac's Apps look. And I want to create Apps for mac. Already buy one but when I open netbeans to program it looks like the Apps doesn't feel like mac.
Is there any specific java code to make the controls looks like how the other mac apps look? My dad mention something about Object C but I don't understand. Can someone please explain me.
AFAIK You'll never get the look and feel of Aqua (Mac's UI Kit) by using Java. Why? Because to make Java platform independent some things needs to get ripped off. And native controls are one of them.
I think you're taking about Objective C which is the native development language for building Mac Apps. I'll recommend you the book "Learn Objective-C on the Mac" is pretty useful.
P.S. I'll encourage you to start with iOS (iPhone and iPad apps). Why? Well, I think is easier to begin with. Things like fixed resolution and so on make your development efforts small while beginning with. (Just my 2 cents)
If you want to code in Objective-C, you'll first need to trek over to the App Store and download Xcode. This will install C/C++/Objective-C compilers on your Mac and then you can start getting your hands dirty.
Depending on what you are trying to accomplish, you can just google/read/learn and build your own frameworks from the ground up or look at something like Cocoa to get started as well.
http://developer.apple.com/technologies/mac/cocoa.html
Cocoa Frameworks
The Cocoa frameworks consist of libraries, APIs, and runtimes that form the development layer for all of Mac OS X. By developing with Cocoa, you will be creating applications the same way Mac OS X itself is created. Your application will automatically inherit the great behaviors and appearances of Mac OS X, with full access to the underlying power of the UNIX operating system. Using Cocoa with the Xcode IDE is simply the best way to create native Mac applications.
Good luck!
Apple has deprecated a lot of the Java support in OS X. It's possible to have a Java application integrated, but there are some annoying bits missing. See one of my questions demonstrating some issues with Java applications in the Dock. You would be better off using Objective-C instead, since Apple has lots of documentation and tutorials available.
You're thinking of Objective C. You can also do applications for Mac using C/C++ but as of late the "popular" language for Mac development is Objective-C. There are tons of tutorials and plenty of documentation to walk you through writing apps for both Mac and iOS.
I am attempting to write a cross-platform GUI application that would be deployed to Windows, Mac OS X, and Linux. My requirements are:
Single code base for all three deployment platforms, without a large amount of conditional logic for handling differences between platforms.
Looks as close to "native" as possible on all three platforms.
Easily distributable to all three platforms, in the sense that it could be easily installed by end users and does not suffer from extreme bloat (as discussed in this ArsTechnica article.)
Based on these requirements, I've narrowed down the selection of toolkits to Qt and wxWidgets, since none of the other toolkits that I know about (including Java's Swing and SWT, Flex, AIR, etc.) satisfy the "native-looking" requirement. Among these two final contenders, Qt appears to offer better support for applications that look and feel native on all three of my deployment platforms, but I'm willing to consider opinions to the contrary.
I would prefer not to use C++ as the implementation language, but I'm not sure if there are any practical alternatives. My biggest concern about using an implementation language other than C++ is the deployment problem. As discussed in the Ars Technica article, PyQt does not meet the "easy deployment' requirement in any practical sense, and I suspect that most other language bindings for Qt would suffer from the same deployment problems (at least on Mac OS X). Java (or Scala) with QtJambi? QtRuby? wxPython?
Does anyone know of any combination of language and toolkit that satisfies all three of the above requirements?
It depends on your needs. But in general Qt Framework (with any language) and Java SE (with any language) is much more better because it has not only cross-OS GUI libraries but also cross-OS networking, threads, ... wxWidgets is GUI only.
Both Qt and wxWidgets are nice. In my experience Qt is better. Swing is... Well, not so nice.
Both Qt and wxWidgets applications written in C++ and Java Swing applications are not so hard to deploy on Windows, Mac and Linux. The rule is that the deployment is simple when you are programming in "native" language. By "native" language I mean the language a framework itself is written in.
PyQt does not meet the "easy deployment' requirement in any practical sense...
Python (and any other language with the default implementation as interpreter) apps is hard to deploy in the usual sense (I mean in form of standalone executables).
So probably you have 2 choices:
C++/Qt or C++/wxWidgets.
Java/Swing if native look & feel is not very strict requirement.
wxWidgets is quite good, and does contain some non-GUI code (contrary to what kemiisto said): threads, sockets etc.
The nice thing about wxWidgets is that wxPython actually should be pretty easy to deploy on OS X. There are some other language bindings for wx, but wxPython is probably one of the oldest ones.
At my day job I've been developing cross-platform (Windows / MacOS / Linux) using perl and wxWidgets. The combination is pleasant to use for development (I'm a perl hacker) and I rarely have to include specialized code per platform. There are some perl modules that help out with this (e.g. File::HomeDir that knows about the canonical locations for document directories etc on the various platforms).
For release, I don't rely at all on the system perl installation and instead build a perl installation that is included in the release. This way I can completely control the runtime environment of the app. I ship a windows installer package via innosetup, an mac os .dmg file with a .app included that the user can just drag to their /Applications, and for linux I build debian and redhat packages.
Have you looked at Xojo? It definitely meets all three of your requirements and it is much simpler to learn and use than C++.
About a decade ago or so, it was fashionable to model a GUI in a cross-platform flavor of XML (like XUL) and then have a platform-specific rendering engine process that XML-file to display a layout. It is no longer fashionable to do this, however. Today, in 2017, the trend is to build your apps on platforms that allow you to write everything in HTML, CSS and/or JavaScript, no matter what environment your code is supposed to run in.
The "first generation" of this type of tools produced what are basically "hybrid" applications, where web applications run on top of browser-like & platform-specific WebViews. This technique is rather inefficient, however. Your apps don't feel very "native", are rather bloated and they tend to be rather lacking in performance. However, it's relatively easy to have a consistent look-and-feel in different environments. Phonegap / Cordova is the most popular platform for mobile environments and NW.js for desktop environments.
The "second generation" is different : they compile everything to fully "native", platform-specific binaries. Instead of relying on WebViews, "native" widgets are used when possible. This gives your app a more "native" look-and-feel, typically has less bloat and is much better for performance. However, you'll have more differences between the different platforms. Examples are NativeScript, React Native & Tabris.js (all for mobile environments).
Unfortunately, there are no "second generation" tools for desktop just yet. So, right now, if you want to build a cross-platform desktop app, you're stuck with "first generation" tools. NW.js has a longer track record than Electron and has support for various features not present in Electron, but it also comes with its drawbacks. AppJS is still older, but it's not as mature - and not nearly as popular - as the other two.
Anyway, their reliance on WebViews means that your application will feel more like a web app than a desktop app. And bloat and performance drawbacks are inevitable with this kind of solution. This means you'll never get the same performance as code you write directly in Java or C++ nor the same performance you'd get in "second generation" platforms, and it will never feel equally "native". However, it can still be the best solution eg. when a consistent look-and-feel across different platforms is more important or when you have a background as a web developer.
If performance, lack of bloat and your application getting that "native" feel are important criteria, you might want to wait a little longer until the first "second generation" platforms appear for desktop. It's really but a matter of time before platforms for desktop apps follow the same evolutionary path as platforms for mobile apps, although it might actually come in the form of "desktop extensions" to existing mobile platforms.
The way it's currently looking, it looks like you'll soon be able to write "native" apps for desktop & mobile alike with the exact same codebase. With React Native already having plugins that add support for Windows 10 and support for MacOS, I would personally go with React Native and give their dev team some time until they support all desktop environments I need to support and those extensions for desktop are mature enough for production environments.
If you can't wait that long, you don't want to bet on what's to come in the future or if these criteria aren't that important for whatever application you want to build today, you might want to try some of the "first generation" platforms currently available and see which is most suitable for you. Just be aware of the drawbacks!
As always, choose wisely...
Popular platforms
First generation platforms for mobile environments (iOS & Android)
Meteor (built on top of Cordova)
Ionic (built on top of Cordova)
Second generation platforms for mobile environments (iOS & Android)
NativeScript (AngularJS eco-system).
React Native (React eco-system)
Tabris.js
Platforms for desktop environments (Windows, Linux or MacOS)
Electron
NW.js
AppJS
Platforms for smart home and IoT devices
iViewer
Iridium mobile
.Net (C# or VB.Net) is what I would use for this (in fact, it is what I use for my own application). Thanks to the Mono project, .Net applications can run on Mac and Linux as well as Windows without any modifications to the code (unless you're calling Windows API functions). You don't even have to compile different versions of your program: the same EXE will run on all platforms.
Java/SWT is one of the good choices. You can find a lot of information about it here.
Java does support "native-looking" applications by using the SystemLookAndFeel. The quickest way to try is to invoke the following at application start up.
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
Take a look at this for more information on the available Look and Feels in Java.
http://java.sun.com/docs/books/tutorial/uiswing/lookandfeel/plaf.html
I'm a Windows (native, not .NET) programmer and I'd like to port an application to the Mac.
Actually, I believe it will be more of a rewrite, as the original depends on many activex controls.
As I have never used a Mac in my entire life, I'll need some guidance. O:-)
a) What book(s) would you recommend to make the move from Win32 to Mac OS?
b) Is there anything similar to Delphi (RAD) for the Mac?
c) Can anyone recommend (or not) Lispworks (www.lispworks.com)?
d) Is there anything similar to the Windows market of 3rd party COM components (so I don't have to write everything)?
e) Anything else I should be aware of the Mac market?
f) Oh, BTW, what Mac should I buy? O:-) (must be a laptop)
Thanks in advance
I've taught Cocoa programming to several Windows-experienced programmers. You may find a previous post on the subject useful.
Cocoa is a very different way of thinking then MFC and its kin. You will do much, much better if you take the time to learn how Cocoa approaches things and adapt to its mindset rather than trying to find the quickest way to implement your current way of thinking in ObjC. It is possible to write MFC-style code for Mac, but you will always be fighting the framework if you do. I've seen a lot of Windows developers struggle with this.
The best book to learn Cocoa is Cocoa Programming for Mac OS X. Assuming you are a C++ developer with a solid OOP background, this is the book to start with. If you have limited Object Oriented background, then start with Programming Objective-C 2.0.
You would be amazed how fast Objective-C can be to code once you understand the patterns. It really can be stunning compared to C++ in my experience. There are more RAD-like systems like REALbasic, and you can develop Cocoa apps in Ruby now which can be a bit quicker. But there really is no substitute in the Mac market for ObjC. It's hard to make an app that works like a Mac app without using the Mac frameworks, and Mac users tend to be much fussier about such things than Windows users.
I have no background in LispWorks, but LISP seems a terrible language for developing the kind of rich UIs that Mac apps are known for. I like LISP (quite a lot actually), but Functional Programming's "no side effects" philosophy seems at odds with most rich UI goals (especially as the Mac UI becomes more and more animation-centric). If anything, Mac programming is moving towards Declarative rather than Functional programming (Core Animation and Grand Central Dispatch have a lot of Declarative concepts creeping in).
There is not as large a third-party component market as there is for Windows. Some of this is because Cocoa already provides such a rich set of components, which MFC does not, and because well-behaved Mac apps are expected to use those components so that you work like all other Mac apps. There is definitely little market for commercial components in the vein of RadControls for .NET (very nice toolkit, that one). But there are quite a few nice free components out there with flexible licenses (generally MIT-based). A few of my favorites:
Positive Spin Media's excellent tabbar control
OmniGroup's frameworks (though I never use them "as is;" they're better used as examples of how to do things)
Growl
Sparkle
RegexKit
CocoaDev's ObjectLibrary list of other stuff
As I mentioned before, Mac users are picky about their UI. Much, much more so than Windows users. They expect things to be polished, and they expect things to integrate with all the little things that make Macs nice. That means drag-and-drop, Spotlight, services, Applescript, Expose, QuickLook, integrated spelling check, etc. etc. It's very hard to do all these things right if you don't use the built-in frameworks. That's why I recommend new Mac developers start at the beginning and learn the frameworks.
For a Mac, if you have a bunch of hardware lying around (like keyboards and monitors), then a Mac Mini is a nice cheap box. iMacs are great if you want an all-in-one, and any MacBook is appropriate if you like portability. There is no Mac on the market today that is not a perfectly fine development box. Obviously if you do a lot of work, an 8-core Mac Pro makes compiling much faster, but I've done a lot of professional development on a 13" MacBook. If you want to get in as cheaply as possible, look for refurbished or used (I love my refurbished Mac Mini). Any Intel-based Mac is going to be fine for development, at least while you're getting started.
If you are familiar with C, you may want to learn Objective C since that is the Macs "native" programming language. It's also what you have to use to write iPhone applications. Cocoa is Apple's primary API that will have a lot of the tools you are looking for.
a) Read this thread for book recommendations: https://stackoverflow.com/questions/7571/cocoa-and-objective-c-resources
b) Apple makes Xcode for developing in. There are certainly better ones out there, but it's not bad.
d) Cocoa is Apple's main API, which provides "core" services like CFNetwork for networking. There is also core data, core audio, core animation, core image, core location,... Underneath it all, OSX is Unix, so you have access to many unix/linux libs.
e) The iPhone is a big part of the Mac market. The iPhone and OSX development environments are not that different, so you can learn both.
f) Any Mac is sufficient for most development. If you want a laptop, it's really a question of screen size and price. But I would recommend at least a 15 inch screen. You don't need to spend extra for a faster CPU, but you may want to get a larger hard drive.
If you've done your native Windows programming in C and/or C++, you may have an easier time migrating your application to C#/.Net, and then running it in Mac using Mono. At least some of the available third-party .Net components will run on Mono (see http://www.mono-project.com/Third_Party_Controls_Status).
I have no idea what Mac you should buy - I recommend getting one of the pretty ones.
a) ...
b) You could use Python coupled with wxPython and be cross platform. Python is included by default with Mac OS X.
c) ...
d) I'm sure there is, but I can't tell you more. If you use Python, you get tons of third party libraries for free.
e) They don't take kindly alien GUI guidelines:
Word 6.0, launched in 1993, is widely considered to be the worst version of Word ever for the Mac, as it was based on the same codebase as Word 6.0 for Windows. That meant that it looked and worked more like Windows software than a Macintosh program. Mac users were so up in arms that Microsoft actually released a Word 5.1 downgrade to unhappy Word 6.0 owners.
f) Mostly any iMac will be good enough for programming. Choose the one that you like the most and has lots of RAM.
e) Its a small market.
f) An iMac. Edit: since it says laptop - Macbook Pro 13 is a great deal.
How do you port a Cocoa/Mac application to Windows? I mean how would you go about it? Assume the app was written with Objective-C and Cocoa, there's nothing fancy going on, no "engine" that could be factored out, etc.
Rewrite from scratch? I don't think there will be huge overlaps between the Mac and Windows codebases, right?
I have doubts about cocotron.
Its not clear from the cocotron website that cocotron is actually production ready yet. Id suspect that it would be possible to start new app development and use cocotron constantly to maintain and test windows builds on the go.
But to retrofit it into an existing project might be a much larger task. There are also no alternatives to cocotron - other than perhaps gnustep.
The practical approach to cross platform development involves developing the non gui components of your application, once, in C or C++. And then using a cross platform GUI library like QT - which is VERY good at generating and using native UI where possible or faking it where not. Please DO go to qt.nokia.com and download the latest build of QTCreator for windows and mac - See how the same QT application looks and feels very convincingly native on both platforms.
If QT doesn't provide a native enough solution, then you need to develop your GUI twice :- once in Cocoa, and once in Win32. The cocoa GUI would be in objective C of course, the Win32 GUI in C/C++.
Your non gui application code would - written in c++ - not be able to call Objective-C directly, but its not hard to write shim classes, implemented in .mm files - the provide a c++ interface, and wrap access to an objective c object or class.
You are also going to have to come up with an alternative to CoreData on windows - perhaps sqlite? Given that XCode has integrated support for the sqlite framework, and testing multiple code paths is, well, more work - perhaps dropping CoreData in favor of a common layer is a better approach?
The problem with Objective C is its very poor support on any platform that is not OS X. You can attempt to use the Cocotron, but I wouldn't consider it production ready yet.
For portability, a re-write is in order. With judicious use of standard C or C++ for the "core" of the application, you could still implement platform specific GUI code. If you don't like maintaining two GUIs, you can also try a toolkit such as Qt
Depending on which objects and framework you are using for your cocoa app, you might be able to get away with using gnustep, although the end result will probably look very weird to windows users, and the development environment might be a bit difficult to setup at first.
Are you aware of Cocotron? It looks like the project may have gone stale, but it's a good starting point anyway. It's a project to port Core APIs.
If your application is not cleanly separated (ie: a la MVC) then the only solution is a rewrite, I think.