Re: A Critique: Getting Started with GNUstep on Windows

I think this is a valuable discussion, so I'd like to offer my perspective as yet another one of many points of view. I'm one of the developers at TestPlant. Our eggPlant software testing tool gets mentioned here sometimes as an example of a commercially-shipping product using GNUstep. We originally wrote eggPlant as a Mac-only product, written in Objective-C on Cocoa. About 8 years ago we needed to port it to Windows and Linux, and decided to use GNUstep so we could maintain a single code base.

We've occasionally had some misgivings about the decision to use GNUstep, due to a number of challenges (outlined below). On the whole, though, GNUstep is an amazing code achievement, and we're incredibly grateful that it exists. It has allowed us to port eggPlant, which our customers now use daily on Windows, Mac, and Linux (in that order). We build it from a single codebase, with a minimal number of #ifdef's for the different platforms, and on the whole everything works well.

Our challenges working with GNUstep fall mainly in these areas:

(1) - Bugs -- things are sometimes buggy compared to Cocoa (no surprise, given the relative resources of GNUstep and Apple!)

(2) - Code Limitations -- the frameworks are always playing catch-up with Cocoa, of course, so we have to either add the missing pieces or be limited in what classes we can use

(3) - Nib Files -- this is a tricky compatibility area

(4) - Infrastructure -- the build environment is particularly challenging

(5) - User Experience -- the user interface is less polished than we would like, in both appearance and usability

(6) - Community -- working with the community is sometimes a challenge

Areas (1) and (2) -- bugs and limitations -- were totally expected from the start, and just part of the ongoing work we have to deal with in developing and shipping a cross-platform product. Similarly, area (6) comes with the territory for working with an open-source project. Most of our issues there were resolved by creating our own branch so we can control which changes go into our product releases.

Areas (3) and (4) -- nibs and builds -- are frustrating, and present challenges that anyone porting from Cocoa is going to run into like a brick wall. We don't use Gorm or ProjectCenter at all. All of our nib files are created and maintained on the Mac, and loaded directly by the GNUstep nib-loading code at runtime. Mostly this works great, but sometimes there are object properties in the nibs that get ignored or misinterpreted. The biggest problem, though, is that Apple keeps changing the nib/xib file formats, and newer versions of Xcode don't support the older format that GNUstep can read. This may soon become a catastrophic situation, but for now we're able to cope by creating and editing our nibs very carefully... For newcomers doing a port I think this will be a challenging area.

The build system is another problem area. We use an OLD version of pbxbuild (newer versions won't process our semi-complex project file) plus various shell scripts to make everything work. We recently made the switch to clang and libobjc2 and had many issues with various libraries etc. (I don't know all the details -- I avoid build scripts like the plague if I have the chance). Having a system that mostly worked out of the box for ported projects would be an astronomical help for developers who are trying GNUstep out. As for us, if it was possible to do our Windows and Linux builds from within Xcode, we would be in seventh heaven. Just saying. :-)

Area (5) -- user experience -- is partly an expected cross-platform maintenance issue, but I thought I should share our perspective. We first started with the default NeXT-style menus, etc. That at least got us up and running, but really wasn't going to work if we wanted our customers to be happy with our product (which we do!). For at least the last 2 or 3 years we've been using the in-window menus on all platforms and the WinUXTheme on Windows. It's not entirely perfect but it's a vast improvement and is working well for our customers.

That pretty much sums up where we are now.

Here are my personal thoughts on where best to focus GNUstep resources next:

What I would most like to see would be more developers using GNUstep, particularly for Windows development. More developers to share the work will help improvements to move along more quickly and we can all have an even better GNUstep experience (which in turn will attract yet more developers). I think this will give the most "bang for the buck" with the current limited resources, because it will multiply the available resources.

Goals such as more/better/awesome apps and operating systems are fine, and would be of some peripheral value from my point of view, but the single thing that will help the most to bring all of those dreams to reality would be to increase the resources available. In short: attract more developers!

To that end, the points that Thom brought up in his video are worth paying attention to. Begin at the beginning by making the initial contact experience as painless as possible. Point people to the right resources on the website, make the steps crystal clear, and make as many things "just work" right out of the box as possible. If people want to tweak and customize later, they can, but make an initial set of defaults that first gets them up and running and building without having to decide or configure anything. (And yes, in my opinion that means enabling the WinUXTheme by default. If it doesn't just work, then fix it.)

After the initial experience has been made as drop-dead simple as possible, then focus on the next areas a new developer will run into. The build cycle. Debugging. Porting a Cocoa app, including its nib files. Start with clear instructions, then look at what can be done to improve the tools (makefiles, configuration files, etc.) to simplify and remove steps so that the instructions can be made even simpler.

From:	Doug Simons
Subject:	Re: A Critique: Getting Started with GNUstep on Windows
Date:	Thu, 18 Feb 2016 20:47:35 -0700