What are the Open Source alternatives to WPF/XAML? [closed] - wpf

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Improve this question
If we've learned anything from HTML/CSS it's that, declarative languages (like XML) do a good job of describing User Interfaces because:
It's easy to build code preprocessors that can template the code effectively.
The code is in a well defined well structured (ideally) format so it's easy to parse.
The technology to effectively parse or crawl an XML based source file already exists.
The UIs scripted code becomes much simpler and easier to understand.
It simple enough that designers are able to design the interface themselves.
Programmers suck at creating UIs so it should be made easy enough for designers.
I recently took a look at the meat of a WPF application (ie. the XAML) and it looks surprisingly familiar to the declarative language style used in HTML.
The current state of desktop UI development is largely fractionalized, otherwise there wouldn't be so much duplicated effort in the domain of graphical user interface design (IE. GTK, XUL, Qt, Winforms, WPF, etc).
There are 45 GUI platforms for Python alone
What are some Open Source GUI's that represent these characteristics:
standardized
platform independent
declarative markup language
language agnostic
WPF, or more specifically XAML seems like a pretty likely step in the right direction.
Update:
Thanks a lot for the info, keep it comin'. Here's are the options I've gathered from the comments and answers.
GladeXML
Editor: Glade Interface Designer
OS Platforms: All
GUI Platform: GTK+
Languages: C (libglade), C++, C# (Glade#), Python, Ada, Pike, Perl, PHP, Eiffel, Ruby
XRC (XML Resource)
Editors: wxGlade, XRCed, wxDesigner, DialogBlocks (non-free)
OS Platforms: All
GUI Platform: wxWidgets
Languages: C++, Python (wxPython), Perl (wxPerl), .NET (wx.NET)
XML based formats that are either not free, not cross-platform, or language specific
XUL
Editor: Any basic text editor
OS Platforms: Any OS running a browser that supports XUL
GUI Platform: Gecko Engine?
Languages: C++, Python, Ruby as plugin languages not base languages
Note: I'm not sure if XUL deserves mentioning in this list because it's less of a desktop GUI language and more of a make-webapps-run-on-the-desktop language. Plus, it requires a browser to run. IE, it's 'DHTML for the desktop.'
CookSwing
Editor: Eclipse via WindowBuilder, NetBeans 5.0 (non-free) via Swing GUI Builder aka Matisse
OS Platforms: All
GUI Platform: Java
Languages: Java only
XAML (Moonlight)
Editor: MonoDevelop
OS Platforms: Linux and other Unix/X11 based OSes only
GUI Platforms: GTK+
Languages: .NET
Note: XAML is not a pure Open Source format because Microsoft controls its terms of use including the right to change the terms at any time. Moonlight can not legally be made to run on Windows or Mac. In addition, the only platform that is exempt from legal action is Novell. See this for a full description of what I mean.
XAML is also not an ECMA standard like C#, Managed C++, and the CLR.
Update: The question has been changed from "Is there an Open source alternative to WPF? because the original question was wrong, and it sucked. The direction of this question has changed direction to match up to align with the new input. My apologies to the people who responded before it changed.

Qt is developing QML, which looks a lot like XAML except in JSON. It's available as a preview built against the current version, and is available in snapshots of the next version.
Here's a little snippet from http://doc.qt.nokia.com/4.7-snapshot/declarative-ui-components-progressbar.html
import Qt 4.7
import "content"
Rectangle {
id: main
width: 600; height: 405
color: "#edecec"
Flickable {
anchors.fill: parent
contentHeight: column.height + 20
Column {
id: column
x: 10; y: 10
spacing: 10
Repeater {
model: 25
ProgressBar {
property int r: Math.floor(Math.random() * 5000 + 1000)
width: main.width - 20
NumberAnimation on value { duration: r; from: 0; to: 100; loops: Animation.Infinite }
ColorAnimation on color { duration: r; from: "lightsteelblue"; to: "thistle"; loops: Animation.Infinite }
ColorAnimation on secondColor { duration: r; from: "steelblue"; to: "#CD96CD"; loops: Animation.Infinite }
}
}
}
}
}

The Web is taking most of the steam away from desktop apps as it is.
I think that the big reason is that everyone's so focused on the web right now. HTML5 is going to be a quantum leap forward in what the web can do. With fast JavaScript interpreters and capable browsers, the need for a desktop programs will begin to wane over time. That's the horse that Google is betting on, and to a much lesser extent, Apple as well.
Creating something good would have radically different implementations for each OS, so the base toolkit itself wouldn't be very portable.
If you think about it, the Web is the only really common substrate we have upon which to develop this sort of infrastructure in a cross-platform manner. WPF is incredibly different from an architectural perspective vs. WinForms/straight WinAPI code. Adapting something like it to each OS would take a great deal of very different plumbing for each OS if you were to have a prayer of making something that performed well. (Not that web apps are very fast, mind you, but they're getting better).
Look and feel is always going to be somewhat of an issue.
Whose look and feel do you use? Do you try to adapt the UI to the OS chrome so it looks "native", or do you do something like Swing did years ago and develop apps that look distinctively different from everything out there? (Ugh, that was a train wreck...) And if you choose to adapt the UI to each OS's look and feel, you may have all sorts of measurement and design issues.

Novell has an open source implementation of Silverlight, with great support for XAML, called Moonlight:
http://en.wikipedia.org/wiki/Moonlight_(runtime)
http://www.mono-project.com/Moonlight

Related

Styled cross-platform native widgets and windows [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm looking for a reasonably cross-platform way to render windows and widgets and style them the way I want without losing the ability to interface with the OS-preferred ways of doing things like redrawing or text input. I am also keen on knowing how Photoshop did this on Windows, as a concrete example.
I'm writing a program primarily for myself but I want to leave open a possibility to share it with others afterwards if it would be useful for more people. I want to really customize its look-and-feel but would like to keep it using native GUI libraries, such as windows forms or something more specific than just rendering my inerface to X11 windows. As I have to use it both on Windows and X11 the solution would preferably be cross-platform but I'm ready to implement multiple UI front-ends if needed, too, if it would provide reasonably consistent looks on both systems. OSX support is a plus, but really far from mandatory. I don't see myself porting this to OSX quite yet. I have barely started.
The reason I want theming is simple: I like dark themes because they are very relaxing to my eyes. On Windows, Microsoft Visual Studio and Adobe Photoshop (Photoshop as the only one and VS by default) display a dark theme and I find it enjoyable to work with these pieces of software for the sole rest that my eyes get. However, both of these, as it seems, use Windows' native controls (I can get to individual widgets in these using Hawkeye and they seem to have descriptive class names, consistent with what they represent).
I see this done way more on Windows than on X11 systems (GNOME, KDE, XFCE on GNU/Linux), maybe because Windows' theming is as rigid as it can get and on X11 window managers and GUI toolkits (KDE with Qt comes to my mind) are really flexible at that so apps needn't implement their own styles when the user can choose them DE-wide quite freely.
I didn't really do GUI programming at all before so I feel a little lost. I would like to refrain from drawing all GUI in a window with an OpenGL context, because I like the idea of the OS drawing legible, subpixel-level text for me, according to the users' settings, and handling partial window redraws instead of full ones. I would also like to integrate with the operating system with, for example, text input. As I said, I would like to share the software some day, so it'd be nice if I don't have to make fundamental changes beforehand.
I'm using C for core code as I've grown tired of futile OOP (whose most benefits I fail to understand if I'm the only one working on the project) with C++ and just want to write code, but I see that GUI libraries for C are in deficit, so I'm ready to write the GUI front-end in another language and link it against my C object files.
Bottom line, to focus on a multiplatform example, how does Photoshop go about redrawing native Windows widgets? I see it looks very consistent on Windows and Mac. Supporting X11 would be less of a problem, as I wouldn't force my styling in the X11 version, just proxy all through a standard widget library (Gtk+? Qt?) and let the desktop environment/window managers/whatevs style it for me. Though I don't know enough on how window and widget management works on GNU/Linux desktop environments to make assumptions.
Thanks in advance.
NOTE: This is purely anecdotal and based upon my own assumptions.
Due to Photoshop's age, I would assume it uses its own custom, proprietary GUI toolkit. It may use the underlying OS's native toolkit but more than likely it just mimics the look and feel. I know Sublime Text uses a custom toolkit made by the developer.
I have made simple applications with .NET, GTK (PyGTK), and Qt (PySide). If you want to support multiple platforms I'd really recommend using a cross-platform toolkit instead of writing the GUI specific to each OS because of the amount of work involved.
I liked .NET but it's not really cross-platform (I'm not sure what all is supported by Mono).
GTK2 (via PyGTK) was fairly straight forward to us. It looked good on Linux (Ubuntu) but I could not get some custom styles working properly in Windows (unless Windows 95 looks good). I also found PyGTK's documentation lacking. GTK3 is the way forward, but last I knew it was still under heavy development and isn't stable on Windows (yet).
I will say I liked Qt (PySide) the best. I found its documentation and examples better than GTK's. It supports native OS themeing along with custom styles and themes (I don't have personal experience with this though). By default it looks native on both Windows (XP and 7), and Linux (Ubuntu).
I have no experience with wxWidgets so I have no say on it, but it is cross-platform.
I would recommend looking into using Qt, though you would have to use C++ (or a higher-level language with available bindings).

Tough question on WPF, Win32, MFC

Let's suppose you're an IT student with a basic knowledge of C++ and C#. Let's suppose that you want to design apps that:
need to deliver some performance like archivers, cryptographic algorithms, codecs
make use of some system calls
have a gui
and you want to learn an Api that will enable you to write apps like those described earlier and:
is mainstream
is future proof
entitles you to find a decent job
is easy enough - I mean easy like VCL, not easy like winapi
So, making these assumptions, what Api will you choose? MFC, WPF, other? I really like VCL and QT, but they're not mainstream and I think few employers will want you to write apps in QT or Visual C++ Builder...
Thanks for answers.
Note: The following answer was written several years ago with Desktop application development in mind. Today (in 2018), you'd probably just build a web application to end up with something reasonably cross-platform and device-independent. (For example, using ASP.NET Core on the server side, coupled with a UI framework/library such as React, Vue.js, or Angular on the client side).
Win32 API -- I'd forget about it, if I were you. Programming a Windows application directly via the Win32 API only makes sense if you're programming in pure C, or if you really need to do a lot of system calls, or if you're concerned about the additional overhead introduced by more "comfortable" platforms or frameworks (such as the ones named below). Programming UIs directly through the Win32 API is tiresome, messy, and you need to deal with lots of details. It's also not platform-independent at all, but you may or may not be concerned about that.
MFC -- Perhaps an option if you're programming in C++ and fixed on the Windows platform. I never understood what's so great about it, other than it makes the Win32 API much more comfortable (AFAIK it's basically a collection of object-oriented wrappers around the Win32 API that take away some of it's complexity / messyness). Also, it's also not very platform-independent.
Qt, wxWidgets -- Fairly widespread UI frameworks. Might be good options where platform independence plays a role. AFAIK both frameworks are targeted at the C++ language.
WinForms (.NET) -- Similar to MFC, this is also based on the Win32 API (USER32 and GDI+). AFAIK the WinForms framework is now being ported to Mono, and therefore somewhat cross-platform. However, it's not exactly the most up-to-date technology. For complex UIs it can also be somewhat sluggish sometimes. If I had to decide today which framework to use, I'd rather choose...:
WPF (.NET) -- More modern than WinForms, with more graphical capabilities and, apparently, faster rendering, as it is no longer based on the Win32 API (GDI). (And it runs on .NET, which I find a great platform to develop for. Programming in C# is so much easier than programming in C++ IMHO, which is also an argument against Win32 API, MFC, Qt, and wxWidgets.) Note that WPF is not cross-platform, it exists only on the Windows platform so far.
Then of course there's Java, including the UI frameworks that come with it. I can't say much about that since I'm not a Java person, but I could imagine that Java would be the best choice for platform independence; and it's the dominant platform (over .NET) in certain industries (e.g. mobile phones, banking, due to the very solid JVM and security considerations).
So my recommendation would be the .NET framework, and WPF for the UI, if you're planning to stay mostly in the Microsoft world. Remember that you can still use the Win32 API (you won't come closer to "system calls" than that) via P/Invoke.
If you enjoy coding in C# and working with the .Net framework I'd recommend that you have a look at WPF. WPF is a great GUI framework where you can do just about anything - and also make it shine! WinForms might be easier to get a grasp on, but I'd say WPF is more "future proof". Another positive thing is that WPF is really similar to Silverlight, so if you handle WPF well you should be able to write Silverlight applications too - if that's of interest. Please don't bother to learn MFC.. I can't believe there are many that is using MFC today for other reasons than that they were using it before, and didn't get an opportunity to change..
There are a lot of good jobs out there for .Net programmers, so being able to handle some GUI framework in addition to C# and general knowledge about the .Net framework will be worthwhile.
When it comes to your points about being able to "deliver some performance like archivers, cryptographic algorithms, codecs" this really shouldn't depend on your choice of GUI framework. This kind of code will be writen in layers outside of the GUI layer, and will typically be bound to the GUI. With WPF you'd write your e.g. cryptographic algorithms in C# in some class independent of the GUI layer, and then the View written in WPF would bind to C# code and get its answer from here. However, if you used WinForms you'd still do the same thing, and the performance relies on the algorithms - not the GUI.
When it comes to getting started with WPF there are a lot of questions on SO helping with this. So you should find good help with a quick search.
Good luck!

How to Write a Windows Application? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm very new to programming, and I'd like to write a Windows Application. So far I've read Teach Yourself C in 24 Hours, what should I do (tutorial to read) next to accomplish my goal? Thanks
When I first started developing applications for Windows (about 15 years ago) I recall reading some very useful stuff by Charles Petzold. His more recent books are about C#, but his older books are still relevant because the Win32 API has not changed that much when it comes to the basics.
Hello, World!
Write the famous "Hello, World" program (Google it if unsure):
To output text to the console.
To output text to a dialog window.
To make the dialog appear after selecting a menu item.
Then, if you are still keen:
Write a program that allows a person to type in text into a text field. Display that text in a dialog window after clicking a button.
Save the text to a file.
Write a program to read the file and display its contents in a window.
That should get you started learning the fundamentals of what is happening when writing a Windows application.
Also, read all the links that people recommend you read, in this thread and others.
Old vs. New
Advice for learning .NET, C#, and C++ is great. Those technologies hide a lot of the boring "grunt" work for you. I still feel it is good to have an understanding of what is happening at a lower level for various reasons, including:
Learning C is applicable to more than Windows-based applications (some would argue .NET and C# are portable, which is true in theory, whereas ANSI C and Java are portable in practice).
Understanding what is hidden will allow you to avoid technical blunders and diagnose deep technical issues.
At this point it really depends on your goals. If all you want to do is write a Windows application, then use modern technologies that are better suited to such a task. If you want to write a Windows application with an understanding of how to write applications in general (not necessarily just for Windows), then keep pursuing the C path for now, and branch into other technologies as you expand your knowledge.
Depends on the application. But what you need now is to familiarize yourself with an API. APIs are basically premade functions that you use as tools to do... whatever it is the API was designed to help you do. You're looking for a graphical user interface API. Windows has its own but I recommend you use something crossplatform so your application will work on multiple platforms.
Look these up on wikipedia:
GTK+
Trolltech's QT4
They can pretty much do anything the windows API can do with the added benefit of working on multiple platforms like windows, linux, mac, etc.
http://winprog.org/tutorial/
These are pretty good for learning Win32. Charles Petzold is good resource if you can get your hands on a copy but The Forger's are free and you can have them in your hot little hands right now.
In general though you should spend some time just writting C/C++ apps that use the standard libraries first. Opening files, writing output, writing files, reading/writing stdio and get a good handle on the basics of the language first.
Looking up books on data structures, and analysis of algorithms are fundemental to any type of programming you want to do as well.
Read this.
Are you suggesting that you'd like to write a Windows desktop app in C? That's reaching back a long way. You're back in 2002, according to this.
Most people writing on Windows are using .NET, which means C++ or C#.
If you need some GUI or complex features,
You need some oriented object programming skills...
You can read some of this book serie : Head first... from O'Reilly
Head first Object-Oriented Analysis and Design
Head First Software Development
Head first C# or Java (It doesn't matter which language...)
Trolltech Qt4, it's a must, too ! Thanks CptAJ
They are very nice books for beginners... and advanced programmers too ;-)
Nice reading !
I disagree with a lot of the answers here... learning from the ground up is not a bad thing.
I wouldn't go out and make a whole app in C, but certainly making a little app in C is a good way to both learn the language and to appreciate (or more likely, detest) the win32 API.
Besides, you can't really appreciate what the newer languages/frameworks do for you if you don't experience the old painful way of doing things.
That said, recognize that there are newer languages and frameworks out there and learn them as well; particularly if you're trying to land a job.
I highly recommend theForger's Win32 API Programming Tutorial. It's very concise and easy to follow, and it's free.
While I won't say you've wasted your time learning some C, I'm guessing it's not where you're going to end up either.
If you really want to get rolling, without too much trouble, I'd highly suggest getting:
Visual Studio C# Express (it's free, and it's a great development environment)
A book on C#...Petzold is great, so a book like Programming Microsoft Windows with C# is perfect.
This should get you pretty much exactly what you want. You'll have everything you need, and Petzold starts you out very simply, and ramps you up to making interesting apps without losing you.
(You may wonder why I, and many other people are directing you to C# or other languages after you specifically said that you've already read and learned about C. This is because programming in windows using the old Win32 API is much more tedious. It is easy to quickly become overwhelmed by the sheer amount of extra chaff that has to go into it.)
At Microsoft, we have been working hard to come up with some great resources for simply creating Windows applications. Our page, Start Programming with Windows 7, will be sourced with tons of new resources for intermediate and advanced programmers.
There are two really important new learning series that we have been working on:
The Hilo Project: An application built from the ground up to show how you can develop programs that are specifically taylored to Windows 7 features using the most modern programming and application design methodologies.
The Learn to Program for Windows Module: An introduction to Windows programming written by a developer education expert at Microsoft. This module sounds more like what you are looking for, I recommend you check it out.
We're working on ways to surface learning resources as best we can on the Windows Developer Center - a collection of developer learning resources for people new to developing Windows or new to developing using the latest Windows features.
Additional guidance is coming through the new Home and Hub resources for client / Desktop applications on the MSDN homepage.
Try Ramp Up's Developer Basics, a microsoft learning road that shows stpe by stpe how to start windows programming. You can use the Visual C# Express version of Visual Studio as a development enviroment.
Read this book, Learn to Program with C#.
Then, make small projects in WPF; the best WPF book is Windows Presentation Foundation Unleashed; try that after reading the C# / beginning-programming book.
C#, the .NET Framework and WPF were created to move beyond the C Win32 API, to make it easier to create Windows applications.
If you want to make a standard Windows application, follow that path.
I would suggest using VB rather than C#. The syntax is a little friendlier, and it has all equivalent features and performance.
Why not follow the MSDN tutorials? If you don't like them try googling "VB tutorial".
http://msdn.microsoft.com/en-ca/library/hewcw458.aspx
Either VB or C# has a zillion examples of everything that can be googled. I would stick to either of these languages, if only for the "google support" alone.

WPF alternatives [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
WPF is positioned as a successor to WinForms, but given Microsoft's practice of abandoning toolkits (and what I perceive a s"bloat" in WPF), are there any recommended alternatives?
I don't think you need to worry about WPF being abandoned. WinForm was around for a long time, and WPF is the replacement.
Bloat? I don't know. It seems like a huge upgrade from WinForms to me. If there's bloat it's always going to be there because underneath everything is the Win32 API. Until that gets rewritten from scratch I don't think anything will be perfect. And since every toolkit targeted at the Windows platform has to deal with that, I had rather go with WPF and ReSharper.
Another sign Microsoft is serious about WPF is that it's getting used to make Visual Studio 2010. XAML seems to get used by more than just WPF (Workflow Foundation, Communication Foundation).
I've been coding in WinForms for the past 5 years and I was a bit sceptic of WPF too at first. But after reading a few books and trying out my first application in WPF I'm starting to see the beauty of it!
I keep amazing myself at how little "glue" code is needed in a WPF application compared to how I would have done it in WinForms. Here's an example: I had to show a simple histogram. In WinForms I would have written a custom control and handled the rendering myself. In WPF, I did it all from xaml without one line of code! I just bound the data samples to a list box, replaced the listbox's layout template to an horizontal stack panel, and replaced the item template to rectangles which height is bound to the sample values!
MS does not have a practice of abandoning toolkits (WinForms, MFC, ActiveX and Win32 are all still being actively developed) and the "bloat" is actually new capabilities you may not need right now but there's a good chance you'll need in the future.
If you don't want bloat and use only an API that will be impossible for MS to stop supporting you are more then welcome to work with the Win32 API directly.
I believe 4 out of 5 developers never ever look beyond the surface of a technology, they just want to drag & drop a few controls, write a few lines of code and get something up & running, maybe googling for some samples to help iron out a few kinks, and that's it. To such folks, bloat is not a word in their dictionary.
I, for one, prefer to look under the covers and really figure out how a technology actually works before jumping into writing code using the technology. Today, I spent an hour or so to investigate how the WPF built-in commands work, and with the help of reflector i managed to track down how a simple built-in Cut command is executed for a plain-vanilla textbox control, and guess what, by the time the text changed event is raised for a cut operation, there are around 30 calls on the call stack, isn't that code bloat?
WPF certainly has many powerful functionalities, but they do come at a cost. In some ways, i feel that WPF is to WinForms what MFC is to Win32 API; both WPF and MFC has the word "Foundation" at least :), but it would be interesting to watch if WPF will come to the same fate of MFC.
It depends on your favorite programming language, but Qt is a good Gui toolkit for C++. It has impressive features, is free and as platform independent as it gets for GUI toolkits.
Qt Quick (QML) is the way to go. It has extremely sharp design, and it is kept from being polluted by XML unreadability.
Adobe AIR is the strong competitor. If you aim to create cross-platform applications with rich user interface, check out this one.
First of all, I love WPF! I don't see any elegant/immediate way to achieve the same functionality and flexibility for designing interfaces in WinForms... That said, it is very sad to see that WPF is not anymore in favor inside Microsoft. Actually some people, including 'insiders' have stated that MS has shifted focus form WPF, and the Silverlight is now THE Windows Phone 7 application framework (not something to supplant Flash anymore):
http://www.theregister.co.uk/2010/09/09/microsoft_html_5/
Many people, including the current WPF Leader, denies this, but I see that this may actually have some truth behind. HTML5 is certainly going to become the "de facto" standard for rich (web)client interfaces. It overlaps so much with WPF, and does many other things too. It can "easily" be extended to work for non-web rich-client applications, and I believe MS will invest in that to have the lead in development tools for both web, mobile and windows targets.
I would not fear abandonment if I was already in the middle of a WPF project, but I wouldn't start one in WPF either as many have already said: it is not that simple to abandon something like WPF without giving a migration path and supporting it for many years.
So, current alternatives for WPF in the MS world? I don't think we have one already, maybe using its subset in Silverlight is the way to go for now. But, in the upcoming years HTML5 will probably be THE alternative to WPF.

Porting WPF to Cocoa (and/or vice-versa)

I am in the beginning stages of creating software for a mISV-to-be. The program is a desktop application and in the long run I want to have a native version for both Windows and OS X (I have a looked at various cross-platform APIs, and none of them meet my needs). Initially though, I don't think it makes sense to develop for two platforms at once. With that in mind, I have been looking at WPF for Windows and Cocoa for OS X, and they seem similar.
Has anyone had experience porting one to the other? Are there particular techniques/paradigms to follow that will make porting easier? Ignoring business considerations, would you recommend developing on one of them first?
Well. Once you've written an app for Cocoa, it is possible to port it to Windows. This could be done using gnustep or Cocotron.
If you do it the other way, WINE is meant to make porting easier.
I would rather write the OSX version first. This is because Windows users have no clear idea what they want an application to look like. In my experience, they are quite able to suffer through all kinds of user interfaces. Consistency has little value to them. Since there is no common agreement, what a Windows app should look like, nothing stops Windows users from actually liking OSX designs, and they even frequently do. iTunes for windows looks like a very typical OSX app and you hear very few complaints that it would not be enough Windows-ish.
Going the other direction, this is not true. OSX users have a clear preference for Cocoa apps and very little tolerance for, as an example, things like GIMP or Inkscape which work under OSX just as well as anywhere else, but look plainly ugly to the OSX trained eye.
I think that you're on the right path by choosing windowing environments that are specific to each platform. This approach allows you to create a user experience on each platform that isn't restricted by the compromises inherent to cross-platform windowing toolkits.
A good first step is to break your design down into two parts: platform specific and platform neutral elements. You can already put any UI code into the platform specific column, but maybe your app will need some data persistence that can be written in platform-neutral C++. What you may find with this approach is that there is quite a bit of logic and infrastructure that you can write in a platform-neutral way, leaving just the UI and glue code as platform-specific.
There was a recent episode of Late Night Cocoa titled Porting Large Applications to the Mac platform. Your app may not qualify as "large" but this podcast gives quite a bit of great porting knowledge from someone that's done it a few times.
I'm currently working on porting tools in this space and have many years of oft-painful experience in either using or writing cross-platform frameworks on Mac and Windows.
One of the biggest problems in the past has been Apple's refusal to open up the nib format for Cocoa (Carbon nibs were open XML files years ago). That changed with XCode 3 and the .xib format, as well explained by Frasier Speirs.
At the basic layout level, at least, there is now an opportunity to automate porting from one XML format to another. I regard WPF (XAML) as cleaner and so I'm using that as my base format and migrating to Cocoa.
When it comes to the code behind, whilst you can use C# under Mono, the CocoaSharp project seems either stalled or very slow and I wouldn't recommend it.
If you are comfortable with C++, consider having as much logic as possible in C++ with a thin platform-specific layer in C# and Objective-C.
Another approach worth investigating is using a dynamic language like Python or Ruby. I'm not sure which is more mature at present between IronPython and IronRuby but both are now supported by Microsoft people. On the Cocoa side, I think the flexibility of Ruby syntax will triumph and RubyCocoa is probably overtaking PyObjC.
Otherwise, work in C# and Objective-C and maintain two completely independent code bases with identical designs. Fortunately the frameworks have comparable semantics for most things, especially if you make use of bindings.
Well, there is not a straightforward path. The best method is to use something like Model-View-Controller pattern or some other architecture to separate business logic and so forth from the presentation. However, unless you are using Mono, there will be very little code for you to share, I think.If you are developing WPF then you surely doing .NET and, other than Mono, Objective-C is the standard programming tool under Mac OS X.
Keep a good design and you can have most of your code simply be an Objective-C version of your .NET code and vice versa rather than trying to find a migration path.

Resources