This area is one that I've been pondering for a long time. In my view, the most sensible approach is to abstract the entire UI and write to the abstracted UI. Then you write the translation piece in whatever toolkit(s) and platform(s) you care about (and in whatever language is most appropriate). This hard separation of the platform and toolkit opens the door for some nice benefits (cross platform being the first and most obvious).
However, the benefits don't need to stop with cross-platform. By adding location independence to the non-application part of the code, you get the flexibility to decide later (even after the application is written) whether to deploy it as a "fat" app (application logic running locally) or "thin" (UI commands and events routed over network to your app running on a server).
I've been experimenting with these ideas for years and it's all doable. I've done various UI/toolkit implementations such as: Cocoa/ObjC, Gtk/C++, wxWidgets/C++, win32/C++, Delphi VCL/Pascal, HTML/JS, Java Swing, Java SWT, etc.
I look forward to being able to share publicly (once I decide which license to use).
However, the benefits don't need to stop with cross-platform. By adding location independence to the non-application part of the code, you get the flexibility to decide later (even after the application is written) whether to deploy it as a "fat" app (application logic running locally) or "thin" (UI commands and events routed over network to your app running on a server).
I've been experimenting with these ideas for years and it's all doable. I've done various UI/toolkit implementations such as: Cocoa/ObjC, Gtk/C++, wxWidgets/C++, win32/C++, Delphi VCL/Pascal, HTML/JS, Java Swing, Java SWT, etc.
I look forward to being able to share publicly (once I decide which license to use).