Heron's Perch

A little history first. Keysight is a large company that, primarily, makes testing equipment such as oscilloscopes and other electronics. They bought a company a few years back named TestPlant. Prior to that, TestPlant bought a company by the name of Redstone that produced a product known as Eggplant. Recently, I was laid off for economic reasons (at least that's what they said). It occurs to me that nothing in this world lasts forever. I was so depressed when I was let go because Keysight was the perfect home for me... they used GNUstep deeply. So, as you can imagine, I was deeply upset when things ended... but all things do. 

Recently, I saw this article regarding ObjCs "end of life" from JetBrains.

The tiobe index seems to disagree. It’s also important to remember that jetbrains recently had to take down their AppCode application (which sucked) since it didn’t sell.
Jetbrains is the creator of the kotlin language so they have a vested interest in their android customers. I would take their “index” with a grain of salt to say the least.

While it is certain that Apple won’t be investing into thing beyond ObjC 2.0, it is foolhardy to think that ObjC is going away anytime soon since there is an enormous installed base of stable code, not the least of which is Foundation and AppKit themselves. Also consider CocoaPods.

So, no, not worried about it. Also… look at Java and COBOL. For years people have declared the end of both languages. Java is still popular, though not in vogue and COBOL while not one of the “cool kids” has literally billions of lines of code being maintained and new code being written every year. This (admittedly biased as it is by the CTO of MicroFocus) article gives some reasons why….

Here is the article about COBOL...

Plus… Apple already has a mechanism for automatically allowing objc and swift to work together. Take a look at the frameworks in Xcode and you’ll notice some files called *.apinotes. These are YAML files that are used by the compiler to allow easy integration into swift projects. So, essentially, if Apple writes an ObjC version of a framework they get the swift version for absolutely free (minus the cost of writing the YAML file). If they write a swift only version they don’t get that benefit.

So, yeah, in conclusion… Yes, ObjC is NOT on the rise, but reports of its demise have been greatly exaggerated! ;)

PS. That being said, Apple dumping ObjC might spell a boom for us as all of the people who have installed codebases would suddenly need support for it either on macOS (on which we don’t currently work) or on other platforms. Something to think about…

PPS. All of the above being said. I admit I wouldn’t be terribly shocked to hear from Apple that “we have dropped support for the legacy objc language to provide you with the best support for our new swift language to make it the ‘greatest developer experience in the world’” or some grotesque BS like that. Lol

GC

I made a correction this morning which allows for Gorm to have a Mac style menu when NSMenuInterfaceStyle is set to the Mac style.

You may need to remove your Gorm preferences, or at least do the following:

defaults delete Gorm NSMenuInterfaceStyle

to reset the style so that it will show up properly.

Recent replies to my previous post on the gnustep-dev mailing list have made it necessary for me to further define what I believe GNUstep should become in the future.

GNUstep is a development environment and API, first and foremost. While GNUstep contains a few apps which comprise a minimal desktop... mainly GWorkspace... I feel as though it should not be considered as a desktop project. Yes, I know this contradicts what I said in part of my previous posting, but here's why I've had this change of heart. It is necessary for GNUstep to focus on being one thing and doing that extremely well. GNUstep's main purpose, like OPENSTEP's, is to provide a multiplatform development environment and API.

The way I see it right now, the project is divided into two camps:

1. The group of people who feel that GNUstep should be an API/development environment
2. The group of people who feel that GNUstep needs to be a desktop and possibly a standalone OS which is a clone of OPENSTEP/NeXTSTEP.
   

What I am saying is that if we do #1, #2 can follow. There is no reason why GNUstep cannot be a strong, multiplatform API AND provide the basis for a desktop/OS.

My point, quite simply is, that we must be the first one. The second one can be done in other projects. Examples of these projects are Etoile, Backbone and GAP. These projects all contain applications which make up a desktop environment on top of GNUstep. Once completed they will complement GNUstep's offering. The LiveCD provides the other part of this, which is a self-contained GNUstep environment that people can sample.

As Chief maintainer, it is up to me to determine the direction of the project.

Over the past several years interest in GNUstep has steadily increased, but not nearly by enough. In order to reach a wider audience, GNUstep needs to do a number of things (not necessarily in priority order):

1) Adopt a more modern look. This includes the look of the windows, the color scheme and how the menus are rendered. It's okay to let that old gui go, it's not going to kill you to do so. ;) Users like things to look "good". This is entirely subjective. Personally, I think GNOME and KDE are quite ugly under the best of circumstances. To this end, we need to make integrated theming available in GNUstep and make it easy.

2) Make regular releases. Start courting different distributions to include GNUstep in their package set. Start getting the word out. Start making sure that people KNOW that GNUstep is alive and well. This, I believe, is the main reason why people have the perception that GNUstep is dead. We don't push ourselves hard enough and into enough distributions to be visible enough for people to care.

3) Eliminate the need for GNUstep.sh, either by making GNUstep place it's binaries and libraries in more "standard" places, or by providing an installation procedure

4) Start appealing more to the Mac OS X/Cocoa crowd. While some people disagree with me, I believe that this group IS the group we need to be playing towards. In the past some have advocated that GNUstep be an "OPENSTEP-like" or a "Cocoa-like" environment. While I don't believe that GNUstep should necessarily follow all of the design decisions Apple has made, I believe that it should implement all of the classes which are useful and which are being commonly used in spite of whether or not people personally agree with having that class in GNUstep or not. A good, and recent, example of this is NSToolbar. It's not about us, remember, it's about them... the users and developers USING GNUstep. We are here to make life easier for our users not to make GNUstep into the epitome of "perfect design" by excluding classes we personally don't like. This is not productive and, not to mention, highly subjective.

5) Focus and concentrate on one and only one set of display technologies per platform. We expend way too much time and energy on maintaining mulitple backends (xlib, art and etc) when we really don't have to. For Linux/BSD we have two functional backends and another on the away for cairo. What's the point of this? In my opinion we should complete the cairo backend and deprecate BOTH the xlib and art backends. xlib is hopelessly outdated and libart isn't really supported by anyone anymore.

6) Decide what we are. Yes, that's right. Some people view GNUstep as a desktop, others view GNUstep as a development environment. GNUstep needs to define itself as one or the other. The website says it's a development environment, but it has many aspects which fit the definition of a desktop environment. In truth, I believe it should be both.

7) Make GNUstep friendly with other environments like GNOME, KDE, Windows and etc. Make sure that GNUstep functions sanely in these environments. This might mean that we need to have behaviors for each different environment. How to implement this is unclear, but it's something that I believe would make the user experience better overall.

All of this is just for starters. Anyone who is familiar with my work on Gorm knows that I tend to focus intently on things until they succeed. I intend to do the same with this project as a whole.

If you have anything to add to or detract from the above, please feel free to comment. I would love to hear all opinions.

I have been involved with GNUstep for seven years now, since 1999. It is my great pleasure to take leadership of the project so that I can help it grow. From my first commit to NSScreen to the latest Gorm nib modifications, this project has been a labor of love for me, and it will continue to be so for many years to come.

I sincerely hope that Adam will remain a part of the project. A "thank you" hardly expresses what the project owes him. You have our deepest gratitude, Adam, for everything.

I just don't understand what it is about some people. While reading slashdot, I came upon this article at regdeveloper and I'm thinking to myself that it's nice to see another crossplatform library, aside from GNUstep, in the open source world, but when I get to page 3 the author pops up with this little tidbit:

In fact, on the Mac, I find the combination of Qt and C++ far more intuitive than the weird Objective-C language and the frighteningly non-intuitive Interface Builder.

Whoa there... did he just say Interface Builder is unintuitive? Wow.... of all of the lame brained things I've heard Qt developers say, this really tops the list. If you take a look here.. you will see that it is quite easy to learn InterfaceBuilder, or alternatively, GNUstep's Gorm.

Interface Builder is built on one basic principle: making connections between objects. That's really it. Everything else is peripheral. "Modern" C++ programmers complain about Objective-C because they are completely convinced that C++ personifies what is meant by Object Oriented Programming. In fact, quite the opposite is the case. The person who coined the phrase, Alan Kay, has specifically said that when he did so he was NOT referring to C++:

I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.

He, in fact, had Smalltalk in mind. Objective-C, for the uninitiated, is a dialect of C which incorporates some Smalltalk like features. So, as you can see, it is not the weirdness of Objective-C or the "non-intuitiveness" of InterfaceBuilder, but it's really the closed mindedness and relative stupidity of most "modern C++" programmers which causes this type of thing to happen.

And, as we all know, it's much less common to be intelligent than to be dumb. Perhaps this explains why there are so goddamn many of them.

The latest release is available on the ftp site. You can also go to the gnustep website to download. This version has support for NSStreams, RTFD, Nibs and lots and lots more... go check it out!

Although it's experimental at the moment it's working. As you can see here, I'm saving a nib file from Gorm to the "Cocoa Nib" format:














Here is the same nib file after being loaded into IB on OSX:














This functionality opens up all kinds of possibilities for GNUstep. It will ease porting by allowing developers to utilize one format or to easy translate from nib->gorm and vice versa. All Mac OS X developers need to do is to make sure they save the nib files as 10.2 or later, and GNUstep will be able to read the archives.

I'm going to continue refining these enhancements until they are perfected. They're very close at the moment, but like anything new they need to be shaken out a little.

Feel free to comment. Thanks, GJC

I read a blog today called "nextbuntu" it can be seen at nextbuntu.wordpress.com. A few things stated on the website are entirely false:

1) That GNUstep has changed the names of the classes "and everything"
GNUstep has done nothing of the sort. For all of the classes in the published API of OpenStep and Cocoa, we have used the same class names, constants, method and function names. Period. It is trivial to port applications from Cocoa or OpenStep to GNUstep so long as Carbon and the Core* libraries (for which we have no equivalent) aren't used. The only classes which use GS as a prefix are private classes which are not part of the NS (Cocoa) framework.

It's immediately apparent that no review whatsoever was done by NeXTbuntu regarding the current state of GNUstep.

2) Graphics makeover
This is something that has been on the top of my personal list, as GUI maintainer, for a long time. RIO and others have made some progress in getting this done on the theme branch.

3) Give the user the option of using cascading menus instead of the menu bar.
GNUstep currently has cascading menus, it also has the capability to show the menu as a menu bar on the top of the screen. To change it is a matter of changing a default.

All of these concerns are known and are being addressed in GNUstep at present. The goal of NeXTbuntu seems compatible with that of GNUstep. The only thing about his post that concerns me is his "dislike" of the GPL. Currently GNUstep is under the LGPL, which is a "lesser" version of the GPL which lacks certain things that some people don't like about the GPL.

4) Mac OS X/Cocoa compatibility
Porting from Cocoa to GNUstep or from OpenStep to GNUstep is quite easy. Please see this link: http://mediawiki.gnustep.org/index.php/Portability for more information. Also, recently, as you may or may not have noticed, I've implemented nib compatibility, so it's currently possible to read/write nib files for use on OS X.

Cocoa compatibility is one of the main aims of the GNUstep project. It's a very challenging one because Apple keeps adding things, so It's a moving target.

5) The Desktop Env. vs Development Env. issue
GNUstep needs to be both, or, at least, have a separate desktop project which is the official desktop.

Conclusion
I would suggest that the person behind NeXTbuntu should contact a member of the GNUstep team such as myself, Richard, or Adam to discuss collaboration. If you are planning on re-writing all of this stuff yourself, good luck, but it would go much more quickly for you to use GNUstep. Also, I suggest you drop the attitude that you seem to have, it won't make you any friends.

As you can see from the screenshot, Gorm is now able to load nibs just fine.



Gorm should be able to save nibs in the next few weeks. This is a huge step forward for GNUstep. Builder and Loader classes have been added along with a factory class which gets the appropriate builder/loader for a given format. Gorm has also been changed so that it is effectively format agnostic. This means that it can accept any format that a builder/loader class can give it.

In addition to the above Gorm also uses the NSDocument* classes instead of implementing it's own framework.

A few ideas have been rolling around in my head recently:

• Champollion -- OSX app, most likely will need a kernel extension.... translator from x86 -> PPC (the opposite of Rosetta.app)
• GNUstep ABI compatibility with Mac OS X. (suggested by aurynn)
  

Both of these seem like good ideas to me and I wanted to get the out someplace. ;)

I was made gui maintainer of GNUstep today. I will try to take the project forward as much as possible.

One of the people on the #gnustep channel on freenode posted the Gorm article which ran on slashdot earlier this week. A myriad of good, non-controversial articles were posted before hand, but were ultimately rejected. So when Malda does finally decide to publish a GNUstep article, it has to be this one, which was intended as a joke.

This post was approved not be one of Malda's minions, but apparently by Malda himself as it was approved by CmdrTaco according to slashdots entry. This is a shameful commentary on just how unreliable slashdot is as any measure of good news. Slashdot is yellow journalism at it's worst.

I'm sorry, but am I the only person in the world getting pissed off at slashdot for rejecting my posts? Does it seem like slashdot only worries about certain peoples posts and indeed only posts on certain subjects?

The site has increasingly become an GNOME/KDE site over the course of the past few years. It's become apparent to me that no other competing API toolkit will be able to edge it's way into that site so that it can get some attention.

It's time to make a better slashdot.

Gorm 1.0 is finally released. It seems like it's taken forever to get here, but it's finally done. Thanks to all who helped. There's still more I'm going to add, so this is not the end, just a bright new beginning. :)

This post appeared briefly on osnews.com today

It's basically a "pointer piece" about an article on informit in which the author has reached an ephiphany about how much better InterfaceBuilder is that almost any java code generation GUI builder out there. From the article "It's lightyears ahead of anything we've got in the java world."

I'm really not sure why this is such a revelation to Java folks. I also do a lot of Java programming as a consultant and I've found that there is no inherent value to code generating gui builders. They are, in most circumstances, unweildy. Many of these GUI builders don't have the concept of palettes, which allow the expansion of the basic set of widgets available to the developer, which leaves the programmer using other widget sets from another jar library on his/her own when using those.

Have we made so little progress in the last decade that programmers STILL have to trudge around making GUIs by hand? This is efficient?

Intuitive vs. Counterintuitive

In the Java gui builder world the predominant paradigm when it comes to associating widgets with methods is the event/handler paradigm, even though Java has a wonderful thing called reflection, it's not used when building GUIs in any of the gui builders I can think of. InterfaceBuilder and Gorm use the target/action paradigm. The target/action paradigm, takes advantage of Objective-C's dynamic nature to allow the direct invocation of the method against the target class. This is what I think gets most Java developers tripped up when they try to use Interface Builder, since they may not be used to this way of viewing the world.

I recently had a discussion with a friend of mine whom I work with regarding C++ vs. Objective-C. I told him about GNUstep and also showed him Gorm. I explained the dynamic features of Objective-C and compared it to smalltalk and Java.

When I showed him some images of Gorm from the GS website I told him that Gorm could not be done in C++. He took some offense to this and immediately asked me "May I ask why you believe this couldn't be done?"

I explained that, it's because Gorm uses does several things which depend on the dynamic nature of Objective-C in order to do it's job. Here is a quick summary of the features of Objective-C which Gorm uses:

1) Categories - many categories, these are used in Gorm to do the following things
a) add the name of the inspector class for each type of inspector to the class itself so that it can be looked up easily. Mainly adding the extensions from the IBObjectAdditions.h protocol.
b) Also used for editors inspectors.
2) Loadable bundles - The palettes, which actually make up a large percentage of the code in Gorm are actually loadable bundles. These can be loaded when the application starts or during runtime.
3) Protocols - Many many protocols in Gorm. :)
4) Dynamic binding - As such, per #3, it's important to be able to call objects without knowing thier true class.

So far as I know C++ is incapable of doing #1, and is also incapable of #3 and #4. He went on to explain that it could be done in C++ if the modeller was a "code generator" to which I responded, but mine doesn't generate any code at all. :)

Many things are happening right now with respect to GNUstep, that it's almost scary. There are opportunities that have been brought to my attention that I cannot talk about at the moment, but I can simply say that they could be very good for GNUstep's future.

It's hard not to be nervous at times like these.

It's been a real task preparing for Gorm's 1.0 release. I've been hunting down and correcting bugs for a week straight. I've also been adding documentation. Fabien Vallon has volunteered to help me with both pre and post 1.0 work, and it's working out great!