mGSTEP
 
F A Q    |    Notes    |    Progress    |    Projects    |    Home   
 
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 Freshmeat.

   - Felipe A. Rodriguez

What other libs are required?
libtiff ... tiff-v3.6.1 or better
libavcall ... ffcall-1.6 or better
libfreetype ... Freetype 2.1.10 or better (and ideally some TrueType fonts)

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

If building the AppKit for X11 an X server which supports the Xrender extension is required
Xrender ... XFree86 4.5 or newer

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)

What is the advantage of Cocoa compatibility?
Beyond providing a clean well documented and proven API this facilitates rapid application development. Typically, a proof of concept demo would be developed on OS X. Doing so simplifies the task of ironing out GUI issues before or in parallel to the development of the actual embedded device. The resulting demo is also then a portable simulator of the embedded device suitable for marketing purposes.

How do I configure mGSTEP for the Linux framebuffer?
A Linux kernel with Vesa framebuffer support is a prerequisite. An unused virtual console must be available (no getty attached). The Linux framebuffer must be at a 32bit depth while current hardware support is limited to a PS/2 mouse and the keyboard. mGSTEP alters console settings so an ungraceful exit might require a console reset from a remote terminal (kbd_mode -a). Specify "fb" as the AppKit backend when prompted during build configuration. The build will then create a libvfb.so which must be linked to a location in the dynamic linker library search path. mGSTEP's framebuffer support makes use of several Linux ioctls but should not be difficult to port to OpenBSD or FreeBSD ...etc.

What is Objective-C?
Objective-C is a C derived Object Oriented programming language. It's simple to learn once you know C. As a true dynamic language it tends to be much more powerful than C++. And unlike Java it provides this without the performance hit and footprint of a Virtual Machine. Most of the OS X GUI is developed in it. Apple has a short primer.

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. During the configuration phase of the mGSTEP build say YES when prompted to 'Define the Obj-C constant string class'. The default is NO.

Building on Suse 11.1 fails.
On a default installation of Suse 11.1 I encountered several glitches:
  • GCC Objective-C support did not install. The error message is something like 'cc1obj' missing. You must manually install the Objective-C RPM packages from the Suse DVD.
  • You must download, build and install the ffcall libraries. Suse does not provide this.
  • mGSTEP has integrated support for Freetype. The font path should be set to the Suse default '/usr/share/fonts' when prompted during build configuration.
  • Once mGSTEP is built issue a 'make install' as the user who will run the AppKit examples. This configures defaults and the library path for the user. Otherwise you will need to either edit the dynamic linker search path or define LD_LIBRARY_PATH appropriately in the environment.
  • The AppKit examples launch the gdomap daemon required for DO if it is not already running. Unfortunately, the daemon will only run as root.
  • The Obj-C constant string issue mentioned above occurs on Suse.

Building on Yellow Dog 6.1 fails.
On a default installation of Yellow Dog 6.1 I encountered several glitches:
  • You must download, build and install the ffcall libraries. The distro does not provide this.
  • mGSTEP has integrated support for Freetype. The font path should be set to the distro default '/usr/share/X11/fonts' when prompted during build configuration.
  • Once mGSTEP is built issue a 'make install' as the user who will run the AppKit examples. This configures defaults and the library path for the user. Otherwise you will need to either edit the dynamic linker search path or define LD_LIBRARY_PATH appropriately in the environment.
  • The AppKit examples launch the gdomap daemon required for DO if it is not already running. Unfortunately, the daemon will only run as root.
  • The Obj-C constant string issue mentioned above occurs on Yellow Dog 6.1.

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. Additionally, projects dependent on the mGSTEP libraries should leverage the one time package configuration. The existing Makefiles build system implements most of this.

Is it possible to share the same application source code between mGSTEP and Cocoa?
The short answer is YES. But of course it depends 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. 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 mySTEP (QuantumSTEP\myPDA)?
mySTEP was derived from mGSTEP years ago. mySTEP 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 various differences such as the menu and nib handling code where mySTEP is more compatible with Cocoa than mGSTEP. A variety of useful additions have been back ported to mGSTEP over the years.

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 need an AppKit suitable for embedded development. Given that I really could not control the quality, performance or direction I made the decision to fork. Portions of libFoundation were utilized because at the time much of the GNUstep Base (Foundation) code was not 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 discern in most of the code.

How is its goal different from GNUstep?
As far as I know GNUstep remains focused on creating a general purpose GNU server and desktop development framework. mGSTEP is designed for use in embedded devices so the focus is instead on memory footprint, performance and stability which take precedence over implementing obscure Cocoa classes. Unnecessary legacy code is usually not kept around. There is some overlap such as the mGSTEP desktop application examples which help prove the libraries.

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 developed using it but there are various mostly non-core GUI components such as the Color and Print panels which are incomplete. In a typical embedded application this is probably not a big deal.