discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Basic questions about Gorm


From: Ivan Vučica
Subject: Re: Basic questions about Gorm
Date: Fri, 8 Apr 2011 23:24:20 +0200

Here's a few words that I'm writing about my experiences with Debian's GNUstep 
and Gorm (which are somewhat older than what people are working with today, so 
depending on what you're using, your mileage may vary).

These are my opinions and they may be incorrect.  Someone more informed should 
probably step in and correct everything I'm about to say incorrectly :-)

On 8. tra. 2011., at 22:57, Omar Campos wrote:

> Hi all,
> 
>   First I'd like to say that I'm still a newbie in all things Objective-C, so 
> please excuse me if my questions sound too basic or just plain stupid. My 
> only experience has been using Xcode on the Mac, and with UIKit (and have 
> only used a few widgets about it so far). When using Gorm to draw a simple 
> interface, the following doubts came up:
> 
> - I dragged a "Title" to my window, but I found no way to change its caption. 
> The Inspector only allows to change the color and alignment properties. Does 
> this need to be changed programatically?

Try doubleclicking on Title, or change the active mode of Inspector. I don't 
have Gorm working on my current machine, so I cannot check to provide correct 
instructions. But, caption can most definitely be changed!

> - I found no way to create connections between outlets by dragging like I do 
> in Xcode. How is this done? (It may simply be that I don't have any 
> connectable properties yet!)

It is important to understand that Gorm does NOT automatically analyze the 
header files. You NEED to define the classes in Gorm first, for example, for 
your AppController. You need to define actions and outlets that the class 
supports; again, both in code and in Gorm since Gorm does not analyze header 
files. Then you need to ensure that object instances are of correct class type. 

Gorm does include analysis of header files, so it can be used for initial 
linking. But attempting to do analysis again bears a warning that links will 
break, so be cautious. (Maybe this changed.)

After you do all this, it is quite similar to what you'd do under Interface 
Builder... but not exactly the same. 

If I remember correctly:
You do the control-drag FROM the object INTO WHICH you want to store an action 
target, or an outlet. 
You drag TO the object WHICH you want to store.
You look at inspector, and you choose the action variable or outlet command 
from the first object with which you want to link the second object.
You click on connect in the inspector.

For example, you have a button. You want to link with your controller class' 
action -(void)buttonVisible:(id)sender.  You control-drag from the button onto 
the controller. You look at inspector. You choose buttonVisible:. You choose 
Connect.

Again, don't forget that Gorm won't know that an outlet or action exists until 
you define that outlet or action in the class.

> - Using @property for my controls had errors. Is this not supported in 
> GNUStep? (It's OK, if it isn't, I don't have a problem with manually creating 
> my properties).

Problem is in the compiler. I think GCC 4.6 introduced Objective-C 2.0 
features. You can try using clang compiler, and you'd probably need to switch 
to libobjc2 runtime; I did not, but your mileage may vary. If you're under 
Debian (which, although it contains a deceptively named package "libobjc2", 
does not include the actual "libobjc2") I have a small blog post about this:

http://blog.vucica.net/2010/12/getting-objective-c-2-0-to-work-on-debians-gnustep-with-clang.html

For the purposes of that post, I did not compile GNUstep from source, so I'm 
using Debian's outdated GNUstep. I have also not used libobjc2. But, @property 
works for me there, and so does fast iteration (that is, the 'for x in y' 
syntax) and several other objc2.0 tricks.

> - I am not exactly sure how do I get my Objective-C class inheriting from 
> NSWindow to load the nib? In UIKit, I've seen this done with 
> initWithNibName:bundle:, and even though I haven't successfully used it yet, 
> I wonder if such a function exists in AppKit. Or do I need to inherit from 
> NSWindowController instead.

If I understand correctly, you're a UIKit developer and are trying to use 
AppKit for the first time with GNUstep. I really recommend you try playing with 
Cocoa's AppKit *in parallel*. It'll make understanding GNUstep much easier, 
while at the same time not messing up your ideas of what is and isn't supported 
in GNUstep. Gorm, Project Center and friends are, despite all the great work 
Gregory and others are throwing at them, really not yet up to the level of 
Apple's tools, and what Apple recommends as your workflow isn't really the same 
thing that feels best under GNUstep (at the moment).

To get the idea of how you should ideally write GNUstep applications, read 
these excellent tutorials:
http://www.gnustep.it/nicola/Tutorials/
You may notice Gorm not being used there too much. This is because Gorm has its 
quirks. I love Gorm. I use Gorm. But is it perfect for introducing a newbie to 
GNUstep? No. Newbies should probably programatically create GUI, and use Gorm 
for more advanced things. This is completely opposite to what I feel about 
Interface Builder. Gregory is doing great work on Gorm, but it's still "not 
there". (Or maybe I just didn't track what was being done lately.)

Now back to your question.

You should most definitely inherit from NSWindowController, have File's Owner 
set to your subclass of NSWindowController, link File's Owner with an instance 
of window, and implement stuff such as - 
(void)windowControllerDidLoadNib:(NSWindowController *) aController.


> 
> If you guys can point me to a tutorial which shows how to do these things, 
> that would work as well.


Again, these are nice:
http://www.gnustep.it/nicola/Tutorials/

--
Ivan Vučica
ivan@vucica.net - http://ivan.vucica.net/
Coming soon for iPhone, Zombie Ball - http://j.mp/zbivmail






Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]