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).
Related
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
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I want to create a GUI driven application for a micro-controller (Atmel XMEGA) that is connected to a 128x64 dots graphics LCD (EA DOGL128-6) and 4 buttons for navigation.
Controlling the display itself (e.g. drawing pixels and characters) is no problem but in order to prevent me from reinventing the wheel I was googling for a GUI-Library/-Toolkit that is written in c, includes its source code, will run on a 32 MHz 8-bit micro-controller and provides at least the following controls:
panel (to group elements)
menu (scrollable)
icon
label
button
line-graph (optional)
But I didn't find any thing useful. Does anyone know (or better uses) such a library(preferably for free)?
I would consider rolling your own "immediate mode" GUI. Jari Komppa has a good tutorial about them. It's a lot easier than you may think, and you'll probably find most GUI libraries--even those targeting embedded systems--are a bit heavy-weight for your system.
If you insist on using a third-party library, below are a few I found. I've never used any of them and they are probably fairly expensive.
emWin
C/PEG
easyGUI
I personally used PEG (at work), but it is not for free. You just need to write a small layer of adaptation and use it. You can also look at Qt or minigui.
I also wrote a library which supports nearly any display technology: µGUI
http://www.embeddedlightning.com/ugui/
µGUI is a free and open source graphic library for embedded systems. It is platform-independent and can be easily ported to almost every micro-controller system. As long as the display is capable of showing graphics, µGUI is not restricted to a certain display technology. Therefore display technologies such as LCD, TFT, E-Paper, LED or OLED are supported. The whole module consists of two files: ugui.c and ugui.h.
This might be helpful as well
You should take a look at Contiki [wikipedia.org]
Besides being a small and elegant operating system for many 8/16/32-bit microcontrollers, it also features a GUI toolkit. It runs on the Atmel AVR!
For your convenience, here is a direct link to the The Contiki Toolkit (CTK) source code.
In addition to Judge Maygarden's list RAMTEX provide libraries specifically aimed at small graphic LCDs. Again not free, but is this is for commercial use, remember that if you did it yourself, it may take many man hours to achieve a polished product, so consider that before building your own.
At the rates my company accounts for my time (as opposed to my pay rate), if it took more than five hours, I'd be better off buying the Ramtex library (about two days if you only take my pay rate into account). If however you have the time and inclination, it is not a difficult task, and probably fun.
Rich Quinnell mentions
"... I saw a demonstration of Java applications running on an STM32-F3 MCU..."
http://www.microcontrollercentral.com/author.asp?section_id=1741&doc_id=253618
I guess it is what you are looking for?
Atmel (now owned by Microchip) actually makes a GUI library targeted at their microcontrollers.
This is part of the now called Microchip® Advanced Software Framework.
You may want to have a look at the Nano-X framework (formerly known as Microwindows): http://www.microwindows.org/
It claims to support down to a 16-bit DOS system, so I'm not sure if it's suitable for an 8-bit, but maybe the library can be pared down to just what you need.
I haven't used it, but at one point was considering looking into using it for some simple display UI (though on a 32-bit ARM system). Unfortunately, the project shifted gears before I actually did anything with it. I'd be interested in what your take on it is (or how well it works if you decide to try to use it).
We've started using easyGui and it seems good. You design the screens in a PC app then it generates the source code - making the design stage really easy.
It does most of the things on the list. Line graphs are coming soon. You can make up buttons pretty easily as reusable structures.
It comes with template drivers for lots of displays - depending on how closely the template matches your display (colour depth & interface are the biggest issues) you might be able to use the code unmodified or change it to suit.
I have been working on a similar project. Closest thing I could find are in the following links, but I doubt you will find a library with all the features you desire. These will only setup basic drawing functions, but it's a start. There are also some useful tools for bitmap converting and font creators if you dig around.
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/glcd_dcf77/index.html
http://en.radzio.dxp.pl/
Almost everything else I have seen here is way overkill for what the poster seems to be asking for.
The CodeVisionAVR development environment now has graphical libraries for XMEGA.
The CodeVisionAVR C Compiler features a powerful graphic library for
LCDs with resolutions from 84x48 up to 800x480 pixels.
However, it is not free.
You can use the "Microchip Graphics Library" for free.
This includes GUI tool "Graphics Display Designer X" for designing screens and this outputs the "C" files for your designed screen.
I am using this tool which is very user friendly, but some of the widgets what you are looking you may not find.
Here is the link for GUI tool:
Click here!
NuttX is a real-time operating system for microcontrollers. The author has starting a developing some gui primitives for LCD displays for it.
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.
I'm looking for some arguments to pitch to my boss and fellow developers.
We're currently finishing up the preliminary UI mockups and getting ready to move on to the next phases of development. In the meantime, I've been digging through the depths of the Carbon, Win32, and wxWidgets APIs attempting to make some of the controls have a more native look and feel on the Mac and Windows platforms.
The more I dig into the Win32 and Carbon APIs to implement the things we want in our project's UI, the more antiquated they feel, and the more I'm beginning to think that we should be implementing the project as described in the last paragraph here.
We're using wxWidgets for our current projects. wxWidgets is coming along on the wxCocoa port, but it doesn't look like it's going to be ready for prime-time before we start major development efforts on our new application. On the Windows side of things, it wraps the Win32 API rather than WinForms or WPF (likely due to native vs. managed code).
We're already designing the system with the MVC pattern in mind, thus aside from having to write two native UIs, it should be very doable, and, IMHO, easier to get the desired UI effects using modern APIs such as Cocoa and WPF.
I've been trying to push these points subtly, but the start of major development is coming soon. Does anyone have any suggestions on how to pitch using native UI toolkits in our next application vs sticking with wxWidgets?
Thanks in advance.
Create your core code in Standard C++ and use Objective-C++ with Cocoa to create your user experience on the Mac and C++/CLI plus C# with WPF to create your user experience on Windows. Follow the platform guidelines for the Mac in your Mac version, for Windows in your Windows version, and don't even bother thinking about trying to share user interface code.
One good way to manage this is, instead of just Model-View-Controller, following a Model-Model Controller-View Controller-View architecture. Your Model Controllers are platform-independent and manage the higher-level functionality of your application. (For example, its entire concept of documents, file format, job queues, and so on.) Your View Controllers are platform-dependent and mediate between your Model Controllers and your user experience.
Of course you'll probably also want some platform-dependent code at the model level too; for example to use NSOperation on the Mac and thread pools on Windows to implement job queues. Just create your own lightweight abstractions for that sort of thing.
Actually I think using Qt has become very interesting since it's now LGPL
Every time you add a layer of abstraction, you trade control over the details for more rapid development. You'll be able to get a lot done up-front using some cross-platform framework. On the flip side, when you want to do something that the framework doesn't support—and lets face it: it isn't going to implement all possible things those native APIs can do—you either have to implement it (for all platforms) using the native API, or do some other wierd hackery to get a "good enough" solution. And of course, when things go terribly wrong, having that extra layer of code you don't own makes it harder to debug. There really is something to be said for owning your entire stack as much as possible.
Writing two font ends is a lot of work, maintaining two front ends is a huge amount of work, if you need your program to run on multiple platforms go with a multi-platform toolkit.
If you write platform specific front-ends, each using the state of the art tools for that particular platform, you will get a much better user experience - but the cost of developing and maintaining those will be on the same order of magnitude as developing the entire application from scratch for each platform (yes, even with MVC).
Personally, I'd rather stick multiplatform and don't give a damn for that eyecandy, but if I wanted to pitch the use of those native APIs, I'd work out the (end-user-visible) differences between how things are done in different GUIs. If you can convince them that, in order to feel native, the program's user interface has to look and feel very differently on Windows and OSX (because of different design guides/philosophies/whatever), they should understand that, even with wx, you would still have to implement it twice, to accommodate those different requirements, so you might just as well use the real thing, i.e. the native API.
Also see this thread on the Google Chrome mailing list discussing the same choice of UI for Chrome on different platforms.
Win32 is definitely waay to old, but you might want to look into something like Microsoft Foundation Classes which is designed to do native development with C++. I assume that a similar thing exist for MAC.
Personally if I was in your situation I would properly also go for QT or WX.
Does anyone have any suggestions on how to pitch using native UI toolkits in our next application vs sticking with wxWidgets?
No one likes a corridor-wiseass.
I think action speak louder than words...make a small prototype of how you think it could be done, and show it. Maybe you have to do this in your spare time.
Cocoa is really great so I think that with little code you can show an idea...well, this require that you know Cocoa enough.
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.