Nib Encoding Now Working in GNUstep

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

NeXTbuntu?

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.

Nib loading working in GNUstep

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.

Why Linux is boring

It seems, for whatever reason, that the Linux community has stopped evolving. We only seem to be heading towards one of two environments: GNOME or KDE. Now, of course, I'm not blind, this trend has been obvious for a very long time. It's amusing, however, that so many people buy into it. They don't see the potential for other possibilities, and they assume that anything which challenges the current two dominant players must be "nuts".

Is this the brave new world of open source? Will KDE and GNOME be all we have? I have looked at both and I am unimpressed with what they offer. Both are poorly designed, amateurish pieces of software. They both feel like they have "evolved" to this point and were never *designed* to be like this. In my next few articles, I'll examine them both further.

A couple of ideas

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. ;)

GUI Maintainer

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

A Phone Call From An Old Friend

I recieved a suprising phone call a couple of days ago. A friend I've been looking for since 1992 called. It was nice catching up with her, since she was someone I was close to. Anyway, it's nice to know that she's doing fine, even if she is 2000 miles away. We've agreed to keep in touch and make certain that it's less than 13 years before the next time we talk. :D

GUI Builders: Data vs. Code

Some people are of the concerted opinion that GNUstep, Cocoa, and indeed GNOME are on the wrong path when it comes to building GUIs when compared to editors of the likes of NetBeans or Eclipse. The first set of technologies have chosen to generate data (even though Glade can generate code... the GNOME project recommends against this), whether they are serialized streams or XML, to represent thier GUIs whereas most Java GUI builders generate code.

This is a fundamentally mistaken position for a very important reason: Metadata is portable across different languages. In GNOME there is a Java interface as well as a C and C++ interface to libglade. This means that my program, no matter which of these languages it's written in, can load my interface without any problems. In NetBeans or Eclipse, it's not necessary for them to consider that SWT or Swing will ever be used by anyone but them, so they can generate the code. However, data is better in general, since it can also be manipulated outside of the program. For instance, it's possible to apply a stylesheet to an XML file and transform it as needed. Why not do this to an interface file? This way an XML interface file can be manipulated like data inside the program and the resulting XML can be loaded as the GUI.

So I hope this settles any arguments about which type is better. In my opinion, Data generating GUI builders are better, hands down.

A Father's passing

This entry is dedicated to my Father, who passed away today at 11:15AM. He was the best man I ever knew. He had his faults, but in spite of them he was a good man. My relatives and I are making the final arrangements for him and the funeral will happen next Tuesday.

There were many things I didn't tell my Father before he died. It's taught me one lesson. If there's someone you care about, tell them now, if there's something you want someone to know, don't wait. Don't leave it until tomorrow... or the next day, do it *NOW* because sometimes you may not have tomorrow.

Near the end of his life, my father went into renal failure. His renal failure was brought on by his heart attack and his aneurysm before that. It came to a point in his life where he was fighting to live, not living as he once did. My Dad always used to be active, and loved to travel in his earlier years. He would sing and dance and do all kinds of things. I hope that now he can do all of those things, because wherever he is, I know he's happier.

I love you, Dad. Until we meet again...

Slashdot finally posts Gorm Announcement

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.

Slashdot's incessent rejection of Gorm 1.0 announcements

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 Released

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. :)

IB/Gorm vs. Java GUI Builders

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.

Why Gorm could never be done in C++

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. :)

The infamous "Burn-In Period"

Getting a new machine is really fun sometimes, but it can also be a royal pain in the butt. I despise the "burn-in" period (as I call it). This is the period where you need to adjust and tweek and frob every knob and adjustable piece of the machine until you get it just right.

Ironically, however, I find that this burn-in time really only happens with PCs. Particularly desktop machines. Especially expensive PCs. It seems as though the more a machine costs me, the more I have to frob with it. :/ Why is this? :) There's got to be some law of nature which makes it this way. :) Whatever the cause, there's nothing like the day when you can finally declare yourself done with all of the frobbing.

This of course, all begs the question: Why didn't I need to frob with my Mac?

Potential for GNUstep

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.

Got the new machine

After some hassles with Comp-USA's check writing service, I've got the new box!!

It's really sweet:

P4 630 w/ EM64T and Hyperthreading @ 3.0GHz.
2GB of RAM
120GB of HD
etc...

The challenge now will be getting GNUstep to run on the 64bit processor. Please see http://wiki.gnustep.org for more.

Broken computer

Well... my computer broke because of a power surge. It seems as though the MB was fried, so I simply replaced it with the old motherboard and put in a sound card I had lying around. I realized however that, this machine is on it's last legs. I uses Socket 423, which no one makes anymore and it also uses RAMBUS memory which was fast back in the day, but is not relatively slow when compared to more recent technologies and is also hideously expensive. I've decided to get a new machine.

Preparing for Gorm 1.0

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!

Many a new feature added this week

I've been quite busy lately. I added the following features to Gorm over the past few days:

1) Added the ability to dynamically modify the pulldown using the addInspectorModeWithIdentifier:... method.
2) Also added the ability for Gorm to call delegates to help it handle different pasteboard types using the IBViewResourceDraggingDelegates protocol.
3) Added a new layout menu which allows the developer to automatically layout the set of currently selected views. The user can other bring a view to the front, push it to the back, align it to the center, left, right, top or bottom relative to the other views.