I'm working on an embedded system using ThreadX. The project will involve a GUI.
I'm looking for a port of wxWidgets for embedded on ThreadX operating system.
My search has turned up wxWidgets for embedded Linux and WinCE.
Also, is wxWidgets difficult to port to a new (different) OS?
Thanks,
(The project tools are C++ using Greenhills compiler and ThreadX operating system with ARM9 processor and conservative amount of RAM and FLASH.)
There is no wxWidgets port to ThreadX. And while porting wx to a new OS is usually not a problem at all, porting it to a different GUI toolkit is quite a lot of work. I don't know anything about GUI in this OS but basically you have the choice between wrapping native GUI widgets in wx API (supposing that the platform does have some native GUI) or implement just a small subset of graphical primitives natively and use wxWidgets own widgets implemented in wx itself (so called wxUniversal port). The latter is usually less work and as it's needed to do the former anyhow, this is what we usually advise people to do first anyhow. But wrapping native widgets (again, if any -- some embedded platforms don't have any native GUI at all) results in more native look-and-feel, of course.
In any case, you shouldn't expect this to be trivial to do, creating a new port will require some effort although usually you can reduce it if your application needs just a subset of wx GUI functionality in the first place. The only simple solution is to make X/DirectFB/GTK+ work on your platform and use the corresponding existing wx port but this might be unacceptable because of extra resources consumption due to the use of another toolkit.
Finally, if you do intend to port wxWidgets to a new platform, wx-dev mailing list would be the right place to ask for help and advice.
Do you have a strong reason not to use Express Logic's own PEGX GUI library?
Related
Programming languages are platform independent, so why is it that we can't write a program that will run on both a PC and a Mac?
I want to develop a software and I'm on a mac, but I want it to run on a PC also, is it possible to develop such a software without having to require the user to download a special program that will make my program compatible with their computer?
The problem with this is that most software is dependent on the OS to handle some tasks. Yes, most programming languages are compatible with many platforms, but the OS provides a lot of support. When software uses the OS, it is sometimes called making a system call. If you want here is some more information.
Theoretically if you write your program in a 'high level language' it should be portable between two operating systems.
Practically however, the differences start from the very beginning - the API of choice, which works on one and does not on another(Such as, Mac's BSD API is incompatible with Win32 API) and boils down to the very last, which is, executable format, linker and loader. Each operating system has its own quirks.
Then comes the difference between the underlying architecture. Previously Macs ran on PowerPC architecture and Motorola architectures, while PCs used Intel. Since Macs have switched to Intel, there have been attempts at making cross platform executables inside Apple. Most attempts have failed.
There is however a way around your problem. You can use a very high level language such as Python to code and then distribute your python code to your PC friends.(But remember remember, you need a Python interpreter in your PC friends' computers for your program to run). I have successfully ported Python programs from Mac to PC with 0 code changes, and sometimes requiring only 2-4% code changes.
Simple answer: because language per se is not enough to make an application cross-platform. Also the framework it uses must be cross-platform too, frameworks are required for everything: handling data, displaying things, communicate with the hardware, multi threading, etc
This can usually be done:
by choosing a complete solution like Java, which will actually run on both platforms seamlessly and even with the same binary
by using C/C++ and cross platform libraries so that the same program can be compiled for both platforms (keep in mind that you can't distribute the real same binary, you need to compile two in any case)
by writing the logic of your program just using standard libraries and a standard language and then attach whatever you need for a specific platform just to build two different libraries. Of course you will have to wrap as much as you need so that the cross-platform part of your program doesn't know it
Mind that developing cross-platform applications which are not trivial examples like a game (for which there are plenty of cross-platform APIs) without using a complete solution like Java is not an easy task at all. Especially because most of the GUI you can build are strictly platform specific and relies on their own frameworks.
If you want an application to run "anywhere" your best option is a JIT type language which means that it compiles as it runs (Just In Time) for the platform that it's on. Really the language that stands out in my mind is Java (there's others and personally I don't like java). However, it's not quite that simple. For example a Window on a Mac computer has pieces and functions that a Window on a PC doesn't have and vice versa. And other operating systems don't even have windows or anything equivilant yet still run Java like Android or iOS for example or countless Linux Distros. And that's just a very basic example it gets MUCH MUCH harrier. Really the best way to build an application that can be used by anyone on just about any device is going web based.
The lesson is that if it was that simple a lot of people wouldn't have jobs and it never will be that simple, things will always progress and change and not everyone is going to want to do the same thing with their OS as someone else. There's a million ways to skin a cat and there's many more ways to implement something in an OS.
Yes, it is possible. But it is quite tricky. You need to:
Use a cross platform language (this is the easy part, many languages run on different plaftforms)
Avoid using any platform-specific features (usually not too hard, but needs testing)
Ensure you have cross platform libraries for all your dependencies (hard!)
Because of the library issue in particular, there are very few options that work across platforms. Your best options are probably:
A JVM language (like Java, Scala or Clojure) - because the JVM abstracts away from platform specific features, pure Java applications and libraries will run on any platform. Java probably has the best ecosystem of cross platform libraries and tools as a result.
JavaScript - quite a good option if you don't mind running in a browser. There are lots of quirks to deal with, but JavaScript is one of the best cross-platform options because of it's ubiquity.
I'd like to develop a desktop app with Ruby. However, I'd like to have a native GUI on every platform (as opposed to a cross-platform GUI Toolkit that looks consistently awful across all platforms).
I expect to have to do different GUIs for each platform (as it's not just looks but also behaviors and idioms that are different), but I wonder what my options are? Especially wondering if there is a clean way to separate front and backend and bind the data properly?
Target Platforms are Windows (Vista & 7, XP is a Bonus), Mac OS X (Cocoa) and Linux (GTK? Qt? No idea).
The Ruby language has excellent Qt library bindings and your scripts will be cross-platform.
Two Kinds of Cross-Platform
It turns out there are two kinds of cross-platform UI toolkits.
One kind draws its own controls, and, like you said, looks equally bad on all platforms. Even worse: it looks out-of-place on all except one.
But there is another kind that just provides a harmonized interface to the native widgets. The best of example of this kind of toolkit is SWT1.. It looks, it is, approximately fully native on each platform, yet it has but a single API.
So you shouldn't simply rule-out all cross-platform toolkits, just rule out the ones that fake the native UI.
Develop the Wrapper Interface
There is a second way. If your program's interface with the user can be directed through a relatively narrow interface, you can simply develop to that interface and then implement the bottom part of it for each platform you want to support. Yes, you have to rewrite one module, but all the other modules stay exactly the same and you get native widgets. You also get the smallest possible executable without lots of bloat.
Perhaps most importantly, you don't have a complex and opaque software layer between your code and the native windowing system. You will probably save as much time debugging as you spend writing the extra module for your first port.
1. I know my Java examples won't help you much unless you are using jRuby, but SWT vs Swing is a really pure example of the right-vs-wrong (IMHO) UI toolkit divide.
The WxWidgets interface claims to use the native interface on Windows, OS X, Linux and UNIX through one API.
Coworkers who have used it in the past enjoyed it well enough, but I've not used it myself.
I am working on a new small utility desktop application but I am not really able to choose the GUI framework to use. I have worked on both JAVA,C# and C++, so language is not really a constraint. My criteria are:-
A very well designed architecture, something like QT. It's better if it follows typical C++ design methodologies.
Layout management should be easy, intuitive and not really cumbersome. I hate adjusting pixels on screen.
Its license should be open.
It should look good :)
Mentioned QT seems to comply to all your requirements. QT has "deploy everywhere" attribute, whilst Java needs no deploying at all (it depends on what is use of your utility).
Ad. 2 QT has really convenient GUI designer.
Ad. 3 LGPL. Usually it is enough.
Ad. 4 It is always matter of taste. IMO QT4 looks awesome under linux, but it's windows look'n'feel is correct at best. It's strong point is, that without additional tweaks it almost everywhere looks native.
I've been using Swing, and it works fine. NetBeans (a decent IDE by itself) even supports graphical GUI building.
It's well designed (basically
everything is done with listeners,
functions that are registered for a
certain event). It has bindings, so
you don't have to write code to set
up a value in a text field or read
it out
Layout is not perfect, but
acceptable within NetBeans. It's
WYSIWYG (almost). Look-and-feel can
be changed on the fly.
License is free. Source-code is not
available, I think.
Looks fine on Windows and Linux,
less so on OSX.
You could always try SWT. The advantages of Java with the standard L&F of supported operating systems.
Well designed. Lots of
documentation, and very easy to
develop with. (If you know Swing,
you can pick up SWT in no time.)
I believe layout managers do exist
that support SWT. I'm not positive
about this though, as I typically
don't use layout managers too much.
Uses the Eclipse Public
License. Should meet most of
your requirements.
From Wikipedia on SWT:
SWT is written in Java. To display GUI elements, the SWT implementation accesses the native GUI libraries of the operating system using JNI (Java Native Interface) in a manner that is similar to those programs written using operating system-specific APIs. Programs that call SWT are portable, but the implementation of the toolkit, despite the fact that it is written in Java, is unique for each platform.
Hope that helps you.
I'd suggest wxWidgets if you want to program in C++ or wxPython (the python language binding of wxWidgets if you know or don't mind learning Python.
Architecture is similar to QT I think.
Layout using sizers. Quite easy once you get the hang of it.
Liberal open source license.
Widgets are native on all platforms (Windows, Mac OS X, Linux).
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.
Which technology stack do you recommend for developing native windows executable (has GUI), other than .NET stack?
Other that C++ (MFC, ...) some could be named; yet which one is mature and pragmatic enough?
Delphi 7?
Common Lisp (Which one is proper for developing GUI?)?
Scheme?
Qt or wxXXX stack?
For native Win32 GUI apps, I've found nothing that beats Delphi. (Your question asks about Delphi 7, but please note that all versions of Delphi (including the latest - Delphi 2010) can produce single, standalone .EXEs).
Python is a good choice for some sorts of problems, and you can package python programs into a single .exe using py2exe.
Here is a nice py2exe tutorial: http://www.py2exe.org/index.cgi/Tutorial
Tcl/Tk is very mature, has a small footprint, is easy to learn and use, and uses native widgets on Windows and the Mac. Plus, it has a deployment mechanism second to none by way of starpacks, starkits and tclkits. You can either create a single-file executable (starpack) that embeds a very full featured virtual filesystem, or a two-file solution of a platform-specific runtime engine (tclkit) with a platform-independent application file (starkit).
It's downside is that it's low on "flash" -- there's not a lot of support for transparency, multimedia, animation and fancy graphics. So, depending on whether or not you need a lot of eye candy it may or may not be the right choice for you.