|
Frequently Asked Questions
Should you have any questions, patches, bug reports or comments regarding
mGSTEP please feel free to email me. You can also post questions on the
Freshmeat site.
- Felipe A. Rodriguez
What other libs are required?
libtiff ... tiff-v3.6.1 or better
libavcall ... ffcall-1.6 or better
Some of the example applications require:
libjpeg ... jpeg-6b or better
libgif ... giflib-4.1.0 or better
libpng ... libpng-1.0.3 or better
Additionally, mGSTEP 0.555 and up require:
libfreetype ... Freetype 2.1.10 or better (and ideally some TrueType fonts)
Xrender ... XFree86 4.5 or better
What tools are needed to build mGSTEP?
BASH is recommended.
GNU Make 3.77 or newer.
GCC with Objective-C support (gcc-3.x versions or newer are recommended)
I get "NXConstantString does not recognize characterAtIndex:" errors when I try to run the examples.
On some Linux distributions the GCC Objective-C runtime's version of NXConstantString gets linked in as the default constant string class. To get around this go into Makefiles/configs/Linux-* and enable the two CFLAGS lines below before you configure and build mGSTEP.
CFLAGS := $(CFLAGS) -DNXConstantString=NSConstantString
CFLAGS := $(CFLAGS) -fconstant-string-class=NSConstantString
What is Objective-C?
Objective-C
is a C derived Object Oriented programming language. It's relatively simple to
learn once you know C. In practice it tends to be much more powerful than C++
because it's a dynamic language. And unlike Java it provides this without the
performance hit and footprint of a Virtual Machine.
Why not use GNU autoconf? How do you add support for another platform?
With Autoconf you never really know what you're going to get. Simply building interdependent components out of order can produce very different results. In the embedded space this is generally not acceptable. The configuration utility employed by the Linux kernel is more or less what is required. An additional requirement is that projects dependent on the mGSTEP libraries should leverage the one time package configuration. The existing Makefiles build system implements some of this.
Is it possible to share the same application source code between mGSTEP and Cocoa?
The short answer is YES. But it may depend on the application. In a simple
case like the AppKit's tableview example app the only difference between the
mGSTEP version and the Cocoa/OS X version is that Cocoa's implementation of the
NSApplicationMain() function sends a "-sharedApplication" message to the app's
principal class while mGSTEP's version merely creates an instance of the
principal class. A proper XML Info.plist within the app wrapper would probably
fix this. Another area where issues arise is in the Menus. mGSTEP employs
vertical OPENSTEP style Menus while OS X/Cocoa utilize Apple's menu bar style.
In mGSTEP 0.532 and up the menu creation code in AppKit/Testing/Controller.m
employs a simple solution which allows the Menu code to be shared. Other
significant issues may arise because mGSTEP only implements a subset of Cocoa.
How is mGSTEP related to QuantumSTEP (myStep\myPDA)?
mGSTEP is a core component of QuantumSTEP. QuantumSTEP contains many additions
as a result of its focus on creating a Cocoa compatible PDA environment that
leverages the Mac OS X development tools. There are also numerous differences
such as the menu code where QuantumSTEP is more compatible with Cocoa than mGSTEP.
How is mGSTEP related to GNUstep and libFoundation?
Years ago I was the principal developer of the GNUstep AppKit. I was probably
the third person to take on the role. My predecessors took the project from
creation to where you could kind of build a "Hello World" application. I began
developing the GNUstep AppKit after it had been abandoned for some time, but as the
AppKit became viable disagreements arose among the developers. Some of the
disagreements were fundamental in that many of the other developers wanted to
create 'The Linux desktop' while I wanted an AppKit suitable for embedded development.
I also found myself spending a considerable amount of time just managing the code
others were submitting. Given that I really could not control the
quality, performance or direction I made the decision to fork.
I grabbed portions of libFoundation for mGSTEP because at the time much of the
GNUstep Base (Foundation) code was not very pretty and relied heavily on things
like 'behavior' classes which provided an element of multiple inheritance. After
years of independent development including the introduction of many new classes
any relationship to either of these projects is probably difficult to see in much of the code.
How is its goal different from GNUstep?
When I last checked GNUstep was still focused on creating the GNU Linux Desktop.
mGSTEP is focused on being useful in embedded applications so the focus is
instead on memory footprint, performance and stability which take precedence
over implementing obscure Cocoa classes. Unnecessary legacy code is also not
usually kept around. There is some overlap and mGSTEP does contain desktop
application examples which help to prove the libraries.
Why don't you just go and work on GNUstep?
A successful Open Source project must be useful to its developer. Primarily,
I need something useful in embedded development. I've also never really been
convinced that a successful Open Source *STEP desktop was realistic. Beyond the simple
issue of convincing Qt, GTK ...etc developers to use another toolkit there is
also the reality that Apple and even Microsoft will at some point be forced to
support Linux if existing trends continue. And so to my mind it's a foregone
conclusion which desktop will matter.
How is its completion state and stability?
That depends on how you define completion. mGSTEP is not trying to implement
every Cocoa class. The core elements are the primary goal with an eye towards
maintaining performance and stability in these. mGSTEP is far enough along
that I can't imagine any application that could not be written using it. But
there are a number of mostly non-core GUI elements such as the Color and
Print panels that are incomplete. In a typical embedded application this is
probably not a big deal.
|
|
|
|
