GNUstepWiki - User contributions [en]

Survey

2006-08-30T13:00:22Z

Stefan Urbanek: Added 'cross-platform' question

About the survey:
* ''Each question should have a 'comment' field''
* ''For any multi-choice one can check more than one option''

== General ==

You are:
* developer
* future developer
* user

Operating system (and flavour) you use:
* MS Windows: ....
* Linux: .....
* BSD: ....
* OSX
* Other: ....

== User ==

Kinds of applications you use (and reason):

Concrete list of applications:

What applications or application kinds you are missing: ....

What do you do not like about current applications you use: .....

== For Developers ==

=== Cross-platform ===

Please state whether you develop for/use/are familiar with/know/do not know one of the following environments:
* KDE
* Gnome
* ... list other environments as well, including Win32, Cocoa,...

* What are the features you like in the environments?
* What are you missing in those environments?

* What are you using for developing cross-platform applications and why?

What platform/environment you plan/want to port your applications to?

=== Development ===

''If you are not a developer and you are either planning to be one or imagining to be one, fill this part as well.''

* Your development platform: .....
* Reason for using the platform (for example: company choice, because of feature ..., only one I learned)

Type of applications you develop:
(FIXME: put a list of app types here)

* Languagaes you use and why: ''(give a reason for the language you use)''
** C
** C++
** C#
** Perl
** PHP
** FIXME: add languages here

== GNUstep ==

* What do you think gnustep is? .....
* Have you heard about gnustep? .....
* Where you have heard about gnustep? .....

* What is you experience with gnustep?

* Do you use gnustep? ....
* For what?
** Development of: .....
** Production of: .....
** Just for fun
** Other: .....

If you do not use gnustep, give a reson why:

(same for Do you plan to use GNUstep?)

What applications you use in GNUstep? ''Same for plat to use: use either two lists or single with two columns with check-boxes''
(put a list of major gnustep applications)

What applications would you like to see in GNUstep?

What frameworks do you (plan to) use from gnustep?

What frameworks are you missing?

How do you compare gnustep to other development environments?

== GNUstep development ==

* would you like to develop for GNUstep?
* what?
** gnustep core libraries
** applications:....
** frameworks:....

what are you missing to be able to develop for gnustep?
** experience
** courage
** documentation
** nothing
** other:.....

FOSDEM 2007

2006-08-30T12:50:49Z

Stefan Urbanek: Added 'survey' reference

Few ideas:
* http://groups.google.com/group/gnu.gnustep.discuss/browse_thread/thread/9580d4fb865bfa4c/f6edba0f74411dec?q=fosdem&rnum=1#f6edba0f74411dec

Extract:
* use Live CD - even rereleased last version
* Perhaps some GNUstep merchandize, like GNUstep T-shirts, GNUstep mouse pads,
GNUstep stickers, etc. Though I'm not sure we could so easily afford these yet.
Quickly lurking through the Internet, I calculated that 20 T-shirts come to
around 60 EUR, 30 T-shirts to ~85 EUR, and 50 T-shirts around ~130 EUR.
* perform a [Survey]

== Portability demonstration ==

Use several machines side-by side with:
* GNUstep with Camaelon, and perhaps the Etoile system
* some Apple hardware for showing that the same apps can run on GNUstep and OSX
* some Linux machine
* some BSD machine
* some x86 hardware to show that GNUstep is even available on Windows
* some other hardware (connected to the LCD we had) showing a presentation/video on GNUstep - something flashy, with sound and talk

FOSDEM 2007

2006-03-05T10:34:37Z

Stefan Urbanek:

Few ideas:
* http://groups.google.com/group/gnu.gnustep.discuss/browse_thread/thread/9580d4fb865bfa4c/f6edba0f74411dec?q=fosdem&rnum=1#f6edba0f74411dec

Extract:
* use Live CD - even rereleased last version
* Perhaps some GNUstep merchandize, like GNUstep T-shirts, GNUstep mouse pads,
GNUstep stickers, etc. Though I'm not sure we could so easily afford these yet.
Quickly lurking through the Internet, I calculated that 20 T-shirts come to
around 60 EUR, 30 T-shirts to ~85 EUR, and 50 T-shirts around ~130 EUR.

== Portability demonstration ==

Use several machines side-by side with:
* GNUstep with Camaelon, and perhaps the Etoile system
* some Apple hardware for showing that the same apps can run on GNUstep and OSX
* some Linux machine
* some BSD machine
* some x86 hardware to show that GNUstep is even available on Windows
* some other hardware (connected to the LCD we had) showing a presentation/video on GNUstep - something flashy, with sound and talk

FOSDEM 2007

2006-03-05T10:34:23Z

Stefan Urbanek:

Few ideas:
* http://groups.google.com/group/gnu.gnustep.discuss/browse_thread/thread/9580d4fb865bfa4c/f6edba0f74411dec?q=fosdem&rnum=1#f6edba0f74411dec

Extract:
* use Live CD - even rereleased last version
* Perhaps some GNUstep merchandize, like GNUstep T-shirts, GNUstep mouse pads,
GNUstep stickers, etc. Though I'm not sure we could so easily afford these yet.
Quickly lurking through the Internet, I calculated that 20 T-shirts come to
around 60 EUR, 30 T-shirts to ~85 EUR, and 50 T-shirts around ~130 EUR.

== Portability demonstration ==

Use several machines side-by side with:
- GNUstep with Camaelon, and perhaps the Etoile system
- some Apple hardware for showing that the same apps can run on GNUstep and OSX
- some Linux machine
- some BSD machine
- some x86 hardware to show that GNUstep is even available on Windows
- some other hardware (connected to the LCD we had) showing a presentation/video on GNUstep - something flashy, with sound and talk

GNUstepWiki:Community Portal

2006-03-05T10:31:26Z

Stefan Urbanek: Added FOSDEM 2007

== Development ==

* [[Roadmap]]
* [[GNUstep release procedure]]
* [[Quality assurance]]

* [[Ideas]]

* [[User knowledge requirements]]

== Marketing ==

* [[Marketing CD]]
* [[Survey]]
* [[Presentations]]
* [[News]]

Notes:
* [[GNUstep as product]]

== Events ==

* [[FOSDEM 2007]]
* [[FOSDEM 2006]]
* [[FOSDEM 2005]]
* [[FOSDEM 2004]]

NSString

2005-11-23T11:24:51Z

Stefan Urbanek: /* Getting a C String */

Strings in GNUstep use the NSString class in gnustep-base. See the reference manual for gnustep-base for more details about NSString.

== Constant Strings ==

As you can create static instances of char* plain C, you can create strings in GNUstep that automatically flatten out to be static instances of NSString. This is done by preceding the quoted string by an "at" symbol ('@'). For example:

NSString * myString = @"This is an example of a string.";
NSLog(myString);

myString is now an NSString object, and can have methods called on it like any other string.

== Getting a C String ==

You can convert an NSString object to a plain C string using the cStringUsingEncoding: method. For example:

NSString *newString = @"This is a test string.";
char *theString;

theString = [newString cStringWithEncoding:[NSString defaultCStringEncoding]];

or:

theString = [newString UTF8String];

Note that using [string cString] is deprecated!

Template:CompactTOC2

2005-11-10T09:19:12Z

Stefan Urbanek:

{| id="toc" border="0"
! {{MediaWiki:Toc}}:
| [[#top|Top]] - [[#0-9|0-9]] [[#A|A]] [[#B|B]] [[#C|C]] [[#D|D]] [[#E|E]] [[#F|F]] [[#G|G]] [[#H|H]] [[#I|I]] [[#J|J]] [[#K|K]] [[#L|L]] [[#M|M]] [[#N|N]] [[#O|O]] [[#P|P]] [[#Q|Q]] [[#R|R]] [[#S|S]] [[#T|T]] [[#U|U]] [[#V|V]] [[#W|W]] [[#X|X]] [[#Y|Y]] [[#Z|Z]] __NOTOC__
|}

Glossary

2005-11-10T09:18:53Z

Stefan Urbanek:

''Please add mainly GNUstep related terms here.''

{{compactTOC2}}

== A ==
* Action Message - see [[Message#Action_Message|Message]]
* Anonymous Object - see [[Object#Anonymous_Object|Object]]
* [[AppKit|Application Kit]]
* [[Application]]
* Asynchronous Message - see [[Message#Asynchronous_Message|Message]]

== B ==
* [[Back]]
* [[Bundle]]
* [[Bundle|Bundle, main]]

== C ==
* [[Category]]
* [[Class]]
* Class Method - see [[Method#Class_Method|Method]]
* Class Object - see [[Object#Class_Object|Object]]
* [[Controller]]

== D ==
* [[Delegate]]
* [[DPS]]
* [[Drag and Drop]]

== E ==
* [[Event Loop]], ~main, ~modal
* Event Message - see [[Message#Event_Message|Message]]

== F ==
* Factory Method - see [[Method#Factory_Method|Method]]
* Factory Object - see [[Object#Factory_Object|Object]]
* First responder - see [[Responder]]
* Formal Protocol - see [[Protocol#Formal_Protocol|Protocol]]
* [[Foundation]]
* [[Framework]]

== G ==
* [[GUI]]
* [[GNUstep]]
* [[GDL]]
* [[GDL2]]

== H ==
* [[HOM|High Order Messaging]]

== I ==
* Informal Protocol - see [[Protocol#Informal_Protocol|Protocol]]
* Instance Method - see [[Method#Instance_Method|Method]]
* Instance Object - see [[Object#Instance_Object|Object]]
* [[Instance variable]]
* [[Interface]]
* [[Invocation]]

== J ==

== K ==
* [[Key Value Coding]]
* [[Key Value Observing]]
* Key window - see [[Window#Key_Window|Window]]
* KVC - see [[Key Value Coding]]

== L ==

== M ==
* Main Event Loop - see [[Event_Loop#Main_Event_Loop|Event Loop]]
* Main window - see [[Window#Main_Window|Window]]
* [[Makefile]]
* [[Message]], ~action, ~asynchronous, ~event, ~remote, ~synchronous
* [[Method]], ~class, ~factory, ~instance
* Modal Event Loop - see [[Event_Loop#Modal_Event_Loop|Event Loop]]
* [[MVC|Model View Controller (MVC)]]

== N ==
* NeXTSTEP

== O ==
* [[Object]], ~anonymous, ~class, ~factory, ~instance, ~remote
* [[Objective-C]]
* [[OpenStep]] - API standard
* [[OPENSTEP]] - operating system
* [[Outlet]]

== P ==
* [[Protocol]], ~ formal, ~ informal

== Q ==

== R ==
* Remote Message - see [[Message#Remote_Message|Message]]
* Remote Object - see [[Object#Remote_Object|Object]]
* [[Responder]], ~ chain, ~ first
* Responder, first - see [[Responder]]
* Responder chain - see [[Responder]]

== S ==
* [[Scripting]]
* [[Service]]
* [[Application Services|Services, application]]
* [[Class#Subclass|Subclass]]
* [[Class#Superclass|Superclass]]
* Synchronous Message - see [[Message#Synchronous_Message|Message]]

== T ==
* [[Target-Action]]
* [[Tool]]

== U ==

== V ==
* [[View]]

== W ==
* [[Window]], ~ key, ~ main

== X ==

== Y ==

== Z ==

Main Page

2005-11-03T15:04:10Z

Stefan Urbanek: remove TOC

{| style="border:1px solid black; background-color:lavender; padding:10pt;"
|+
| '''GNUstep''' is a [[Portability|cross-platform]], object-oriented set of [[Frameworks|frameworks]] for desktop application [[Development tools|development]]. The set of frameworks, based on [[OpenStep]] (now [[Cocoa]]), enables developers to rapidly build sophisticated software by employing a large library of reusable software components. GNUstep is already used [[GNUstep in production|in production]] environments at several organizations.
|}

__NOTOC__

== About GNUstep ==

'''[http://www.gnustep.org GNUstep home page]'''

[[Blogs]] concerning GNUstep

[[Project development|Contact and Project development]]

[[Architecture]]

[[FAQ]]

[[Application News ]]

== Users ==
[[GNUstep_Installation_Process|GNUstep Installation Process]]

[[Internationalisation]]

[[GNUstep environments]]

[[Wish list]]

[[Artworks]]

== Developers ==

[[Development Subprojects]] ([[Themability]], [[Portability]], [[Package management]], [[I18n]], ...)

[[Development tools]]

[[Applications]]

[[Frameworks]]

[[Installation process]]

[[Scripting]]

[[Programming topics]] and [[Snippets]]

== [[Glossary]] ==

== About Wiki ==

[http://www.possibility.com/epowiki/Wiki.jsp?page=HowToOrganizeWiki How To Organize Wiki]

[http://meta.wikimedia.org/wiki/MediaWiki_development Wiki Dev Doc]

[http://meta.wikimedia.org/wiki/MediaWiki_User%27s_Guide User'sGuide]

[http://meta.wikimedia.org/wiki/MediaWiki_FAQ FAQ]

[http://wikipedia.sourceforge.net WikiPedia]

Scripting support

2005-09-17T11:36:22Z

Stefan Urbanek: /* Executing a script */

== Introduction ==

''Note: if something is not clear, add questions under the discussion tab or ask [[user:Stefan Urbanek|the author]] directly.''

To make a tool or an application scriptable you need to prepare:

* objects for scripting
* scripting context
* mechanism for script execution

For applications, there are two possibilities, to make them scriptable. One is custom, that means, that you have to create scripting mechanisms by yourself. The other is automatic, where the developer only needs to add few lines of code and several menu items to his application.

In brief, to add scripting you have to do:

# set-up and provide a scripting context/environment ([[STContect]] or [[STEnvironment]])
# prepare a conversation with the environment ([[STConversation]])
# use the conversation to execute a script in a scripting language

=== Objects to be used for scripting ===

What do you offer to users? What should users customise? What should users talk to? As scripting deals with objects, you need to think about the objects you would like to make available to the user.

It is up to developer to prepare a list of object names and ways of getting the objects.

=== Scripting context or environment ===

Like on our speech, we use references to object without any closer specification. How we do know what objects wer are refering to? From the conversation context. It is similar in the scripting language.

A simple context contains a map (or a dictionary, if you like), of object names and actual objects. Related classes: [[STContext]] or [[STEnvironment]].

== Creating scripting environment ==

To prepare a scripting environment.

#import <StepTalk/STEnvironment.h>

STEnvironment *environment;

environment = [STEnvironment environmentWithDefaultDescription]

or

description = [STEnvironmentDescription descriptionWithName:name]
environment = [STEnvironment environmentWithDescription:description];

Environment serves besides other things also like namespace for objects and you have to register all objects that you would like to have accesible by name:

[environment setObject:object forName:@"ObjectName"];

like in:

[environment setObject:MyApplication forName:@"Application"];

== Executing a script ==

One way to execute scripts is by using a 'conversation' objects. Conversations are made in a environment and using specified language. The language may change during scripting conversation.

#import <StepTalk/STConversation.h>

conversation = [STConversation conversationWithEnvironment: environment language: @"Smalltalk"];

To get names of all available languages:

STLanguageManager *languageManager;
NSArray *languages;
NSString *defaultLanguage;

languageManager = [STLanguageManager defaultManager];

languages = [languageManager availableLanguages];
defaultLanguage = [languageManager defaultLanguage];

Now when you have opened a conversation in an environment you can run the script string. It is better to guard the execution with an exception handler:

id result;

NS_DURING
[conversation interpretScript:string];
result = [conversation result];
NS_HANDLER
/* handle an exception */
NS_ENDHANDLER

''Note: the result handling will change in future StepTalk releases. The result will be no longer be returned by the direct execution message, but instead will need to be requested separately. There are several reasons for this change, including better handling of remote scripting environments (long distance conversations).''

To change a language of script conversation, just use:

[conversation setLanguage:@"ObjectiveC"]

== Automated scripting in applications ==

StepTalk provideas a bundle that allows users to 'script' their applications automatically. With this bundle, it instantly allows users of the application to:

* extend the behaviour of application by adding their own functionality
* automate tasks in the application
* create a batch task

The Application Scripting bundle is installed together with StepTalk. ''Note: the bundle needs a refresh, as it is quite out-dated.''

=== Creating a scriptable application ===

As usual, first think of objects you want to provide for scripting. Then create ''ScriptingInfo.plist'' file as described above. For example a file for a Mail application would be:

{
STClasses =
(
MessageComposition,
InternetAddress
);
}

Use the [[Project Center]] application to include the file or put this line to your makefile:

MyApp_RESOURCE_FILES = ScriptingInfo.plist

Then include the bundle loading code. Copy files ''STScriptingSupport.h'' and ''STScriptingSupport.m'' from '''ApplicationScripting/Support''' directory to your project and add them to your project or add the following line to your makefile:

MyApp_OBJC_FILES += STScriptingSupport.m

Funally, make scripting available to the user:

#import "STScriptingSupport.h"
...
if([NSApp isScriptingSupported])
{
[menu addItemWithTitle: @"Scripting"
action: NULL
keyEquivalent: @""];

[menu setSubmenu: [NSApp scriptingMenu]
forItem: [menu itemWithTitle:@"Scripting"]];
}
...

''FIXME: what is needed to do that with [[Gorm]] in a simple way?''

=== The scripts ===

See: [[Script management]]

[[Category:Scripting]]

Scripting support

2005-09-17T11:31:27Z

Stefan Urbanek: use language manager

== Introduction ==

''Note: if something is not clear, add questions under the discussion tab or ask [[user:Stefan Urbanek|the author]] directly.''

To make a tool or an application scriptable you need to prepare:

* objects for scripting
* scripting context
* mechanism for script execution

For applications, there are two possibilities, to make them scriptable. One is custom, that means, that you have to create scripting mechanisms by yourself. The other is automatic, where the developer only needs to add few lines of code and several menu items to his application.

In brief, to add scripting you have to do:

# set-up and provide a scripting context/environment ([[STContect]] or [[STEnvironment]])
# prepare a conversation with the environment ([[STConversation]])
# use the conversation to execute a script in a scripting language

=== Objects to be used for scripting ===

What do you offer to users? What should users customise? What should users talk to? As scripting deals with objects, you need to think about the objects you would like to make available to the user.

It is up to developer to prepare a list of object names and ways of getting the objects.

=== Scripting context or environment ===

Like on our speech, we use references to object without any closer specification. How we do know what objects wer are refering to? From the conversation context. It is similar in the scripting language.

A simple context contains a map (or a dictionary, if you like), of object names and actual objects. Related classes: [[STContext]] or [[STEnvironment]].

== Creating scripting environment ==

To prepare a scripting environment.

#import <StepTalk/STEnvironment.h>

STEnvironment *environment;

environment = [STEnvironment environmentWithDefaultDescription]

or

description = [STEnvironmentDescription descriptionWithName:name]
environment = [STEnvironment environmentWithDescription:description];

Environment serves besides other things also like namespace for objects and you have to register all objects that you would like to have accesible by name:

[environment setObject:object forName:@"ObjectName"];

like in:

[environment setObject:MyApplication forName:@"Application"];

== Executing a script ==

One way to execute scripts is by using a 'conversation' objects. Conversations are made in a environment and using specified language. The language may change during scripting conversation.

#import <StepTalk/STConversation.h>

conversation = [STConversation conversationWithEnvironment: environment language: @"Smalltalk"];

To get names of all available languages:

STLanguageManager *languageManager;
NSArray *languages;
NSString *defaultLanguage;

languageManager = [STLanguageManager defaultManager];

languages = [languageManager availableLanguages];
defaultLanguage = [languageManager defaultLanguage];

Now when you have opened a conversation in an environment you can run the script string. It is better to guard the execution with an exception handler:

id result;

NS_DURING
result = [conversation runScriptInString:string];
NS_HANDLER
/* handle an exception */
NS_ENDHANDLER

''Note: the result handling will change in future StepTalk releases. The result will be no longer be returned by the direct execution message, but instead will need to be requested separately. There are several reasons for this change, including better handling of remote scripting environments (long distance conversations).''

To change a language of script conversation, just use:

[conversation setLanguage:@"ObjectiveC"]

== Automated scripting in applications ==

StepTalk provideas a bundle that allows users to 'script' their applications automatically. With this bundle, it instantly allows users of the application to:

* extend the behaviour of application by adding their own functionality
* automate tasks in the application
* create a batch task

The Application Scripting bundle is installed together with StepTalk. ''Note: the bundle needs a refresh, as it is quite out-dated.''

=== Creating a scriptable application ===

As usual, first think of objects you want to provide for scripting. Then create ''ScriptingInfo.plist'' file as described above. For example a file for a Mail application would be:

{
STClasses =
(
MessageComposition,
InternetAddress
);
}

Use the [[Project Center]] application to include the file or put this line to your makefile:

MyApp_RESOURCE_FILES = ScriptingInfo.plist

Then include the bundle loading code. Copy files ''STScriptingSupport.h'' and ''STScriptingSupport.m'' from '''ApplicationScripting/Support''' directory to your project and add them to your project or add the following line to your makefile:

MyApp_OBJC_FILES += STScriptingSupport.m

Funally, make scripting available to the user:

#import "STScriptingSupport.h"
...
if([NSApp isScriptingSupported])
{
[menu addItemWithTitle: @"Scripting"
action: NULL
keyEquivalent: @""];

[menu setSubmenu: [NSApp scriptingMenu]
forItem: [menu itemWithTitle:@"Scripting"]];
}
...

''FIXME: what is needed to do that with [[Gorm]] in a simple way?''

=== The scripts ===

See: [[Script management]]

[[Category:Scripting]]

GNUstep environments

2005-09-08T19:57:11Z

Stefan Urbanek: despam

[http://dromasoftware.com/etoile/mediawiki/index.php?title=Main_Page Étoilé]

[http://www.nongnu.org/backbone/ Backbone]

Writing portable code

2005-09-08T19:56:59Z

Stefan Urbanek: despam

GNUstep opens up some fairly interesting opportunities to target a number of platforms with the same source code, for example porting Mac OS X Cocoa applications to Linux, the BSDs, other Unices and (ultimately) Windows without significant re-engineering effort or degraded end-user functionality.

Some portability gotchas are listed below (please update when you run into a new one!):

== Porting Applications ==

You can generally convert NIB bundles from NeXTSTEP and OPENSTEP to
GNUstep using the nib2gmodel tool.

* nib2gmodel Something.nib Something.gmodel
* Open the gmodel file in Gorm on GNUstep and save it as gorm

The nib2gmodel step must be done on either an OPENSTEP or Cocoa platform.

=== Porting from NeXTSTEP (NX*) to GNUstep ===

For this you should have access to an old OPENSTEP installation, or find a friend who has one, otherwise you're simply better off just rewriting the application from scratch.

There are some scripts which can be used to convert an application from NeXTSTEP to OPENSTEP located in:

/NextDeveloper/OpenStepConversion/ConversionScripts

They use a scripting language called "tops". I haven't been able, as yet, to locate a version of tops for Linux or any other operating system other than Mac OS X or OPENSTEP/Mach or NeXTSTEP.

There are a few conversion applications which basically just use the tops scripts to do the conversion. They are actually two versions of the same program, but the second one doesn't run on NeXT, so here's both. These are:

[ftp://next-ftp.peak.org/openstep/mach/apps/devtools/Conversion.0.5.NI.tar.gz]
[ftp://next-ftp.peak.org/openstep/mach/apps/devtools/ConversionII.1.0.I.tar.gz]

You should be able to point it at the project directory you wish to convert and start the conversion. The GUI is very straightforward.

You can also run the tops scripts on a Mac simply by saying:

tops -verbose -scriptfile {scriptfilename} {filestoconvert}

All of the files are converted in place. You must run all of the tops scripts in the ConversionScripts directory against the application code. It is considerably simply to use the existing applications. Unfortunately these scripts do not exist on Mac OS X, otherwise porting the Conversion application might be useful.

When you start the scripts, if you're running them on black hardware you should go get a cup of coffe and watch a movie with your wife or go code something else for a while. The conversion will take a good long while on an older machine. I haven't timed it on the Mac, though. Once this is done, there is still a long way to go. Read on.

OPENSTEP4.2/Mach had a class called NSCStringText. This class was primarily for apps which were converted from NeXTSTEP to use as a stop-gap measure in OpenStep. This is one of the main reasons why it isn't in GNUstep. You will need to make sure that any classes modified by the scripts to use NSCStringText will use NSText and it's related classes as appropriate.

OPENSTEP4.2/Mac also had some other extensions on the OpenStep standard such as NXStreams. You will also need to convert any and all instances of NXStream to use NSData instead in order to make your app work with GNUstep.

If your app is fairly small, you shouldn't be in for a great shock, but if your app is heavily reliant on the old Text object from NeXTSTEP, you have a lot of work ahead. Other gaps which the scripts might leave are problems with NSUserDefaults which it can't fix on it's own.

=== Porting from OPENSTEP (NS*) to GNUstep ===

See the section on Porting from Cocoa. Basically, porting from OPENSTEP is the same with the exception of the "Don'ts" (as those are not available on OpenStep) and the "Stubling Blocks" sections.

Unless otherwise noted here, follow the instructions there.

=== Porting from GNUstep to Cocoa ===

This should be an easy transition since GNUstep implements most of Cocoa, except for the very Apple specific classes such as the scripting extensions.

Since Gorm does not yet save .nib files, you will need to create the interfaces using IB. Also there is a gorm reading/parsing framework for Cocoa in the works as well, so please stay tuned.

Will will need to:

* Make a Project Builder project for your app or
* an Xcode project for your app

Do the following:

* Open Xcode.
* Choose Application (if your project is an application)
* Enter the name and location you wish the Project to reside at
* Copy your files from your GNUstep application into the new project
* Using the "Add Existing Files" option to add these file to your project.

You should preserve your original directory structure if you want to distribute one package for both GNUstep and Cocoa.

=== Porting from Cocoa to GNUstep ===

Porting from Cocoa to GNUstep has different aspects.

First there is the compatibility of the basic Foundation Kit and Application Kit. We support a lot of classes, but not all of them and the same is true for specific methods, Specifically newly introduced classes and methods may still be missing as GNUstep started out aiming at OpenStep compatibility.

Second you have all the additional frameworks and libraries programmers on Mac OS X take for granted, for some of them free replacements exists, for most they are still missing.

Mac OS X developers should try and avoid CoreFoundation as this will complicate your dependency situation on non-Mac hosts, even if that part of CoreFoundation has actually been ported.

GNUstep Base and the FoundationKit offer many parts of the CoreFoundation functionality in a natural [[Objective-C]] manner.

==== The porting itself ====

short overview:
* write a makefile
* convert your NIB files to gmodel
* provide an Info.plist.

detailed instructions:
# you need to write a new GNUstep make file for the project (very easy, still there is currently no automatic way to do so)
# you need to convert the NIB files to GNUstep format. At some point in time GORM will be able to read NIB files, but currently you need to use the gmodel intermediate format for this and for this the above mentioned tools are used.

==== Don'ts ====

Don't use anything we do not provide:

* don't use CoreFoundation
* don't use KeyChain
* don't use Carbon
* don't use Quartz
* don't use QuickTime

gcc mainline currently doesn't support ObjC++ although it is already in the works somewhat (expected for gcc 4.1). that means:

* don't use WebKit (currently)

gcc mainline also does not support altivec, this is an apple specific extentsion, that means:
* don't use altivec features or the vecLib.framework (a collection of functions for vector manipulation).

== Stumbling Blocks ==

* Apple's Cocoa.h

it is there to enable pre-compiled headers and speed up compile time thusly. Anyway, it contains just two lines:

#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>

So you can easily work around this by providing your own or replace your include of <Cocoa/Cocoa.h> with just the above, which will also work on OS-X.

* When you need to distinguish between Cocoa and GNUstep, you may use the following

#ifdef GNUSTEP
''/* GNUstep code goes here ... */''
#else
''/* OS-X Cocoa native code goes here ... */''
#endif

=== Porting the .nib files ===

First get [http://freshmeat.net/projects/nib2gmodel/ nib2gmodel], follow the included instructions to build and install it. Once that's done you're ready to begin:

* Run the nib2gmodel program on your nib like so:

nib2gmodel mygui.nib mygui.gmodel

This should create the .gmodel as a plist. I recommend that you convert the gmodel to a "normal" plist instead of an XML plist. You can do that by doing this on OS X:

pl < mygui.gmodel -output mygui.ser
pl > mygui.gmodel -input mygui.ser
rm mygui.ser

* Now you can either use the gmodel as it is, or you can convert it to a .gorm file.

==== Gmodel to .gorm conversion ====

NOTE: Conversion from gmodel to .gorm is experimental and will probably remain so for a while. It currently works in the majority of cases, but there are still improvements which need to be made.

Conversion to a .gorm file is relatively straightforward:

* Start Gorm.app.
* Choose Gorm->Document->Open and find the gmodel you wish to load.
* Gorm will prompt you to either define the superclass for classes it doesn't know about or to parse the headers.

After you've defined all of the unknown classes, Gorm should complete the conversion. Once this is done you should save the result to make sure you don't loose your work.

''' ''FIXME: add following:'' '''
* how to convert Xcode project to GNUstep project (creating a GNUstep [http://www.gnustep.it/nicola/Tutorials/WritingMakefiles/index.html Makefile] or [[ProjectCenter]])

== Notes ==

=== Do not rely on tools available in development environment ===

All the world is not Linux or FreeBSD or Windows. System constants may be different on different platforms. Paths to command-line tools, the parameters they accept and locations of temporary directories may be different to what you are used to on your platform.

* [[Foundation|GNUstep Base]] and the [[Foundation|FoundationKit]] offer some of this functionality "for free".
* Try not to hard code paths and so on into your code, use macros (not recommended), or even better an abstraction mechanism.
* Avoid hard-coding system constants, or platform-specific ones where Posix or commonly-accepted ones exist (and we're not talking about glibc here :-)
* Try to avoid advanced features of the linker, such as weak symbols, which may not be present on non-ELF systems. While this will work perfectly on most systems, it is not portable to all systems, most notably Windows.

[[Category:Project procedures]]

Help:Contents

2005-09-08T19:56:38Z

Stefan Urbanek: despam

StepTalk

2005-09-06T07:43:59Z

Stefan Urbanek:

StepTalk is the official GNUstep [[Scripting|scripting]] framework. In fact, StepTalk is more than a scripting framework with an illusion of a single objective environment between objects of scriptable servers or applications. StepTalk, when combined with the dynamism that the Objective-C language provides, goes way beyond mere scripting. It is language independent - it uses [[Scripting language bundle|languages as separate bundles]].

Author: [[User:Stefan Urbanek|Stefan Urbanek]] - see '''[http://steptalk.blogspot.com/ StepTalk blog]'''.

== Introduction ==

The Goal of StepTalk is to provide an environment for gluing applications together and to provide a framework for communication between users and objects in the applications. Other major goals are:

* simple and quick extensions of applications or tools
* batch-processing of objects in applications or tools
* fast prototyping of applications or new application features (play and tune a concept "online")

It does not mean that the framework should not be used for whole application development, however it was never designed for that purpose. StepTalk application development is a form of very fast prototyping of an application.

The StepTalk package features a framework, set of tools, [[Scripting language bundle|language bundle]], modules and object finders. '''The framework''' provides an application interface for developers to make their products scriptable. For more information about the tools, see [[StepTalk tools]]. Concerning the scripting language, the StepTalk is a '''language independent framework''' It can be extended via "language bundles" to provide and support other scripting languages. An experimental language bundle for Guile is included in the sources package.

The default scripting language in StepTalk is [[Smalltalk]]. This is because Smalltalk is a very simple language and it is easy to learn. There are just a few basic principles that the user has to know to be able to use the language and it is close to the natural language. [[Smalltalk]] uses a similar approach to that of [[Objective-C]], the language used in GNUstep itself.

'''Object Finders''' are an illusion of single objective environment. Name of an object may me known, but the object itself not. The object may be an application or it may reside on other host. Object Finder is an object that will search for object by specified name.

* '''Distributed Object Finder''' - This finder will try to look for a registered named object. It is possible to specify list of possible hosts where the object may reside and to specify a program that will provide the object if it cannot be found.
* '''Application Finder''' - Looks for a locally installed application and tries to connect to it. If the application is not running, it will try to launch it.

== Download ==

* [ftp://ftp.gnustep.org/pub/gnustep/libs/ Source]
* [http://packages.debian.org/cgi-bin/search_packages.pl?keywords=steptalk&searchon=sourcenames&version=all&release=all&exact=1 Debian packages]

* [http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-libs/StepTalk/ Browse CVS]

Get it by CVS:

export CVS_RSH="ssh"
cvs -z3 -d:ext:anoncvs@savannah.gnu.org:/cvsroot/gnustep co StepTalk

== The Framework ==

Classes:

* [[STActor]]
* [[STContext]]
* [[STConversation]]
* [[STDistantConversation]]
* [[STEnvironment]]
* [[STLanguageManager]]
* [[STScriptManager]]
* [[STScriptObject]]

== TODO ==

For more information about what should be done in StepTalk see [[StepTalk TODO]].

== Projects using StepTalk ==

[http://www.moltalk.org/ MolTalk] - a computational environment for doing Structural Bioinformatics. It interprets PDB formatted files and creates an object representation of the structure-chain-residue-atom hierarchy. Through the use of MolTalk, the PDB suddenly becomes an object-oriented database.

----

See also: [[Scripting]], [http://www.smalltalk.org/ Smalltalk.org]

[[Category:Scripting]] [[Category:Frameworks]]

Help:Contents

2005-09-06T06:41:37Z

Stefan Urbanek: despam

Release Checklist

2005-09-06T06:41:23Z

Stefan Urbanek: despam

This checklist details each step which needs to be taken in order to prepare a new version of apps and libs in the GNUstep repository for release.

''Special thanks to Larry Coleman, who sent me an e-mail asking what the release criteria was, so he could do his first release of RIGS (he's the new maintainer). He gave me the final impetus to type up this document which I'd been intending to do for a long time.''

== Quick procedure ==

# Make sure it compiles against the latest ''releases'' of GNUstep-core, not just CVS
# Avoid version inconsistency - use single place for storing the version number and get it from there.
# Make the tarball with version number in the name ''ProjectName-1.0.0.tar.gz''
# Send an e-mail to '''both''': info-gnustep@gnu.org and gnustep-announce@gnu.org, optionaly you can send it to the gnustep-discuss@gnu.org

== Detailed procedure ==

1) '''Make sure it compiles against the latest ''RELEASES'' of GNUstep-core''', not just CVS...this is a common problem and it's simply embarassing. If it does not, delay the release until the next GNUstep release that includes the fixes you need. If it is critical that you release a new version, you can always appeal to the release manager for a new release via the gnustep-dev@gnu.org mailing list. You can build a separate $PREFIX/GNUstep-Release dir or something which you can then execute the GNUstep.sh file from this tree, which will make it use those release libs without trouncing on your current (perhaps CVS) GNUstep build.

2) '''Use single place for storing the version number''' and get it from there. Be it a header file, or defined macro in a makefile.

it's very embarressing when you forget to change it somewhere, as has recently happened with the ProjectCenter 0.4.2 release (which was still marked as 0.4.1 in numerous places, including the info panel and framework version :[ )

Original suggestion: ''grep for the version number in the source tree.... and change it everywhere...''

3) Once you're actually ready for a release, '''make the tarball''', RIGS-x.y.z, and upload it to ftp.gnustep.org/pub/incoming. You can do this anonymously.

4) Once the file is uploaded, '''send an e-mail to webmasters@gnustep.org''', (which I am subscribed to, as well as others) and simply request that (A) the file be moved from the incoming directory on the FTP site to /pub/GNUstep/libs and (B) that we add a one-line news item to the GNUstep.org front page with a direct link to the latest tarball on the FTP site, and, OPTIONALLY, (C) add info to http://www.gnustep.org/experience/RIGS.html with what's new in the current version, etc.

5) Once the file has been moved to its permanent FTP directory (but you don't necessarily have to wait for the website to be updated to reflect this), '''send an e-mail to BOTH info-gnustep@gnu.org AND gnustep-announce@gnu.org''' with "ANN: RIGS version x.y.z etc et" in the subject, with a standard release-formatted e-mail (for a decent and recent ANN: example, see http://lists.gnu.org/archive/html/info-gnustep/2005-02/msg00000.html ) and be sure to include notable new changes. It's important to be informative about what has changed and why it's changed. Try to be as succinct as you can. (unlike /this/ e-mail ;-)

6) '''OPTIONAL:''' If you have CVS commit privelages to GNUstep, you also have the choice of updating GNUstep.org yourself via CVS. To check out the entire CVS GNUstep website, run:

CVS_RSH=ssh cvs -z3 -d <username>@savannah.gnu.org:/webcvs/gnustep co gnustep

you can choose to just check out the main index.html page if you'd like. There are a couple of large (~17MB) files on the GNUstep.org website which might take a while to download depending on the speed of your Internet connection.

Don't feel obligated to do step 6. It's actually not going to buy us much until we have a way set up where any gnustep person with CVS commit can post stuff anywhere on the GNUstep ftp site, but until then you will have to email webmasters@gnustep.org to ask us to move stuff from incoming/ to libs/ on the FTP site itself. We are of course more than happy to update the website for you, and since there are webmasters in both europe and the USA, it usually happens fairly quickly. If you do elect to update the website yourself, please be sure you know what you're doing. GNUstep.org pulls from CVS checkouts at the bottom of every hour, so be sure to check that the page updated properly the next time it goes live. In a worst-cast scenario, you might have bogus stuff on the main page for one hour. I do this accidentally from time to time.

[[Category:Project procedures]]

Blogs

2005-09-05T10:52:11Z

Stefan Urbanek:

Here is the list of bolgs concerning GNUstep and blogs of GNUstep people:

{| {{prettytable}}
! Blog
! Description
! Owner (#gnustep IRC nick)
|+
| [http://camaelon.blogspot.com/ Random thoughts of a Camaelon]
| programming stuff, free software and gnustep things
| Nicolas Roard (rIO)
|+
| [http://heronsperch.blogspot.com/ Heron's Perch]
| Mostly Apple, GNUstep and stuff about my personally
| Gregory Casamento (bheron)
|+
| [http://steptalk.blogspot.com/ StepTalk]
| Talks about software, programming and GNUstep
| Stefan Urbanek (Stiivi)
|+
| [http://stefankst.blogspot.com/ Think Blog]
| ''(none)''
| Stefan Kleine Stegemann (stefankst)
|+
| [http://gnustep.blogspot.com/ GNUstep News]
| Not an Official GNUstep News Site
| ''(unknown)''
|+
| [http://multixden.blogspot.com/ The Art is Long]
| The Den of Multix (aka grey gandalf)
| Riccardo (grey_gandalf)
|}

Template:Prettytable

2005-09-05T10:51:38Z

Stefan Urbanek:

border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse; font-size: 95%;"

Blogs

2005-09-05T10:50:52Z

Stefan Urbanek:

Here is the list of bolgs concerning GNUstep and blogs of GNUstep people:

{| border=1
! Blog
! Description
! Owner (#gnustep IRC nick)
|+
| [http://camaelon.blogspot.com/ Random thoughts of a Camaelon]
| programming stuff, free software and gnustep things
| Nicolas Roard (rIO)
|+
| [http://heronsperch.blogspot.com/ Heron's Perch]
| Mostly Apple, GNUstep and stuff about my personally
| Gregory Casamento (bheron)
|+
| [http://steptalk.blogspot.com/ StepTalk]
| Talks about software, programming and GNUstep
| Stefan Urbanek (Stiivi)
|+
| [http://stefankst.blogspot.com/ Think Blog]
| ''(none)''
| Stefan Kleine Stegemann (stefankst)
|+
| [http://gnustep.blogspot.com/ GNUstep News]
| Not an Official GNUstep News Site
| ''(unknown)''
|+
| [http://multixden.blogspot.com/ The Art is Long]
| The Den of Multix (aka grey gandalf)
| Riccardo (grey_gandalf)
|}

Main Page

2005-09-05T10:38:24Z

Stefan Urbanek:

{| style="border:1px solid black; background-color:lavender; padding:10pt;"
|+
| '''GNUstep''' is a [[Portability|cross-platform]], object-oriented set of [[Frameworks|frameworks]] for desktop application [[Development tools|development]]. The set of frameworks, based on [[OpenStep]] (now [[Cocoa]]), enables developers to rapidly build sophisticated software by employing a large library of reusable software components. GNUstep is already used [[GNUstep in production|in production]] environments at several organizations.
|}

== About GNUstep ==

'''[http://www.gnustep.org GNUstep home page]'''

[[Blogs]] - Blogs concerning GNUtep

[[Project development|Contact and Project development]]

[[Architecture]]

[[FAQ]]

[[Application News ]]

== Users ==
[[GNUstep_Installation_Process|GNUstep Installation Process]]

[[Internationalisation]]

[[GNUstep environments]]

[[Wish list]]

[[Artworks]]

== Developers ==

[[Development Subprojects]] ([[Themability]], [[Portability]], [[Package management]], [[I18n]], ...)

[[Development tools]]

[[Applications]]

[[Frameworks]]

[[Installation process]]

[[Scripting]]

[[Programming topics]] and [[Snippets]]

== [[Glossary]] ==

== About Wiki ==

[http://www.possibility.com/epowiki/Wiki.jsp?page=HowToOrganizeWiki How To Organize Wiki]

[http://meta.wikimedia.org/wiki/MediaWiki_development Wiki Dev Doc]

[http://meta.wikimedia.org/wiki/MediaWiki_User%27s_Guide User'sGuide]

[http://meta.wikimedia.org/wiki/MediaWiki_FAQ FAQ]

[http://wikipedia.sourceforge.net WikiPedia]

StepTalk

2005-08-31T08:42:08Z

Stefan Urbanek: /* Introduction */

StepTalk is the official GNUstep [[Scripting|scripting]] framework. In fact, StepTalk is more than a scripting framework with an illusion of a single objective environment between objects of scriptable servers or applications. StepTalk, when combined with the dynamism that the Objective-C language provides, goes way beyond mere scripting. It is language independent - it uses [[Scripting language bundle|languages as separate bundles]].

Author: [[User:Stefan Urbanek|Stefan Urbanek]]

(Not-only) StepTalk blog: [http://steptalk.blogspot.com/]

== Introduction ==

The Goal of StepTalk is to provide an environment for gluing applications together and to provide a framework for communication between users and objects in the applications. Other major goals are:

* simple and quick extensions of applications or tools
* batch-processing of objects in applications or tools
* fast prototyping of applications or new application features (play and tune a concept "online")

It does not mean that the framework should not be used for whole application development, however it was never designed for that purpose. StepTalk application development is a form of very fast prototyping of an application.

The StepTalk package features a framework, set of tools, [[Scripting language bundle|language bundle]], modules and object finders. '''The framework''' provides an application interface for developers to make their products scriptable. For more information about the tools, see [[StepTalk tools]]. Concerning the scripting language, the StepTalk is a '''language independent framework''' It can be extended via "language bundles" to provide and support other scripting languages. An experimental language bundle for Guile is included in the sources package.

The default scripting language in StepTalk is [[Smalltalk]]. This is because Smalltalk is a very simple language and it is easy to learn. There are just a few basic principles that the user has to know to be able to use the language and it is close to the natural language. [[Smalltalk]] uses a similar approach to that of [[Objective-C]], the language used in GNUstep itself.

'''Object Finders''' are an illusion of single objective environment. Name of an object may me known, but the object itself not. The object may be an application or it may reside on other host. Object Finder is an object that will search for object by specified name.

* '''Distributed Object Finder''' - This finder will try to look for a registered named object. It is possible to specify list of possible hosts where the object may reside and to specify a program that will provide the object if it cannot be found.
* '''Application Finder''' - Looks for a locally installed application and tries to connect to it. If the application is not running, it will try to launch it.

== Download ==

* [ftp://ftp.gnustep.org/pub/gnustep/libs/ Source]
* [http://packages.debian.org/cgi-bin/search_packages.pl?keywords=steptalk&searchon=sourcenames&version=all&release=all&exact=1 Debian packages]

* [http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-libs/StepTalk/ Browse CVS]

Get it by CVS:

export CVS_RSH="ssh"
cvs -z3 -d:ext:anoncvs@savannah.gnu.org:/cvsroot/gnustep co StepTalk

== The Framework ==

Classes:

* [[STActor]]
* [[STContext]]
* [[STConversation]]
* [[STDistantConversation]]
* [[STEnvironment]]
* [[STLanguageManager]]
* [[STScriptManager]]
* [[STScriptObject]]

== TODO ==

For more information about what should be done in StepTalk see [[StepTalk TODO]].

== Projects using StepTalk ==

[http://www.moltalk.org/ MolTalk] - a computational environment for doing Structural Bioinformatics. It interprets PDB formatted files and creates an object representation of the structure-chain-residue-atom hierarchy. Through the use of MolTalk, the PDB suddenly becomes an object-oriented database.

----

See also: [[Scripting]], [http://www.smalltalk.org/ Smalltalk.org]

[[Category:Scripting]] [[Category:Frameworks]]

ApplicationWishlist

2005-08-30T14:33:17Z

Stefan Urbanek: redirect

#REDIRECT [[Application_wish_list]]

Scripting language bundle

2005-08-30T14:25:37Z

Stefan Urbanek: Added proposed changes

Scripting language bundle is, well, a bundle that offers a language for [[StepTalk]]. The bundle provides mechanisms for understanding the language and interpreting it.

Core of a language bundle is a scripting engine. Each language should have its own engine that executes scripts. The engine should take into account a context, where the script will be executed, and the script itself. After the execution, the engine should provide some feedback, for example a result object or it should throw an exception when something went wrong.

Few steps for creating a custom language bundle:

# take a language template from StepTalk sources or create one of your own
# create your own language engine as a subclass of the [[STEngine]]
# implement method ''executeCode:inEnvironment:''
# provide an information list about the bundle

=== Language Template ===

Template for a language bundle can be found [http://stefan.agentfarms.net/Download/GNUstep/MyLanguage-20041021.tar.gz here].

=== Implementation ===

Header file for a custom language should look like this:

#import <StepTalk/STEngine.h>

@interface MyLanguageEngine:STEngine
{
/* ... */
}
@end

And the implementation:

#import "MyLanguageEngine.h"

@implementation MyLanguageEngine
- (id) executeCode:(NSString *)sourceCode
inEnvironment:(STEnvironment *)env
{
id retval = nil;

/* execute the code sourceCode using environment env */

/* retval = return value from the interpreter; */
return retval;
}
@end

You may want to use ''[environment objectDictionary]'' to get all environment's named objects.

To translate a selector (for example a symbolic selector) you can use ''[environment translateSelector:aString forReceiver:anObject]'' which returns a [[NSString]] containing translated selector or nil if the selector should not be sent (because it should be fobidden by the environment). Moreover you should use this method if you want to use restrictions of selectors of the scripting envornment. See [[STEnvironment]] and [[STEnvironmentDescription]] for more information.

If your language can execute scripts from files, you may specify the file type in the MyLanguageInfo.plist. Then script manager and [[StepTalk]] tools can execute files with an appropriate language engine.

{
/* Array of file types of your language scripts */
STFileTypes = ( "mylang" );
}

== Proposed Changes ==

- (id) executeCode:(NSString *)sourceCode
inEnvironment:(STEnvironment *)env

is going to be renamed to

- (id)interpretScript:(NSString *)sourceCode
inContext:(STContext *)context

=== STLanguageManager ===
New class is going to be added: '''STLanguageManager'''

+ defaultManager
- registerLanguage:engineClassName:info:
- registerLanguagesFromBundle:
- availableLanguages
- removeLanguage:

- createEngineForLanguage:
- engineClassForLanguage:

- infoForLanguage:
- bundleForLanguage:
- languageForFileType:

Class STLanguage is going to be removed as well as language related methods from STEngine.

[[Category:Scripting]]

StepTalk

2005-08-30T14:19:12Z

Stefan Urbanek: /* The Framework */

StepTalk is the official GNUstep [[Scripting|scripting]] framework. In fact, StepTalk is more than a scripting framework with an illusion of a single objective environment between objects of scriptable servers or applications. StepTalk, when combined with the dynamism that the Objective-C language provides, goes way beyond mere scripting. It is language independent - it uses [[Scripting language bundle|languages as separate bundles]].

Author: [[User:Stefan Urbanek|Stefan Urbanek]]

(Not-only) StepTalk blog: [http://steptalk.blogspot.com/]

== Introduction ==

The Goal of StepTalk is to provide an environment for gluing applications together - one uses StepTalk to make apps cooperate on a single user defined task. Other major goals are:

* simple and quick extensions of applications or tools
* batch-processing of objects in applications or tools
* fast prototyping of applications or new application features (play and tune a concept "online")

It does not mean that the framework should not be used for whole application development, however it was never designed for that purpose. StepTalk application development is a form of very fast prototyping of an application.

The StepTalk package features a framework, set of tools, [[Scripting language bundle|language bundle]], modules and object finders. '''The framework''' provides an application interface for developers to make their products scriptable. For more information about the tools, see [[StepTalk tools]]. Concerning the scripting language, the StepTalk is a '''language independent framework''' It can be extended via "language bundles" to provide and support other scripting languages. An experimental language bundle for Guile is included in the sources package.

The default scripting language in StepTalk is [[Smalltalk]]. This is because Smalltalk is a very simple language and it is easy to learn. There are just a few basic principles that the user has to know to be able to use the language and it is close to the natural language. [[Smalltalk]] uses a similar approach to that of [[Objective-C]], the language used in GNUstep itself.

'''Object Finders''' are an illusion of single objective environment. Name of an object may me known, but the object itself not. The object may be an application or it may reside on other host. Object Finder is an object that will search for object by specified name.

* '''Distributed Object Finder''' - This finder will try to look for a registered named object. It is possible to specify list of possible hosts where the object may reside and to specify a program that will provide the object if it cannot be found.
* '''Application Finder''' - Looks for a locally installed application and tries to connect to it. If the application is not running, it will try to launch it.

== Download ==

* [ftp://ftp.gnustep.org/pub/gnustep/libs/ Source]
* [http://packages.debian.org/cgi-bin/search_packages.pl?keywords=steptalk&searchon=sourcenames&version=all&release=all&exact=1 Debian packages]

* [http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-libs/StepTalk/ Browse CVS]

Get it by CVS:

export CVS_RSH="ssh"
cvs -z3 -d:ext:anoncvs@savannah.gnu.org:/cvsroot/gnustep co StepTalk

== The Framework ==

Classes:

* [[STActor]]
* [[STContext]]
* [[STConversation]]
* [[STDistantConversation]]
* [[STEnvironment]]
* [[STLanguageManager]]
* [[STScriptManager]]
* [[STScriptObject]]

== TODO ==

For more information about what should be done in StepTalk see [[StepTalk TODO]].

== Projects using StepTalk ==

[http://www.moltalk.org/ MolTalk] - a computational environment for doing Structural Bioinformatics. It interprets PDB formatted files and creates an object representation of the structure-chain-residue-atom hierarchy. Through the use of MolTalk, the PDB suddenly becomes an object-oriented database.

----

See also: [[Scripting]], [http://www.smalltalk.org/ Smalltalk.org]

[[Category:Scripting]] [[Category:Frameworks]]

StepTalk

2005-08-10T12:20:09Z

Stefan Urbanek:

StepTalk is the official GNUstep [[Scripting|scripting]] framework. In fact, StepTalk is more than a scripting framework with an illusion of a single objective environment between objects of scriptable servers or applications. StepTalk, when combined with the dynamism that the Objective-C language provides, goes way beyond mere scripting. It is language independent - it uses [[Scripting language bundle|languages as separate bundles]].

Author: [[User:Stefan Urbanek|Stefan Urbanek]]

(Not-only) StepTalk blog: [http://steptalk.blogspot.com/]

== Introduction ==

The Goal of StepTalk is to provide an environment for gluing applications together - one uses StepTalk to make apps cooperate on a single user defined task. Other major goals are:

* simple and quick extensions of applications or tools
* batch-processing of objects in applications or tools
* fast prototyping of applications or new application features (play and tune a concept "online")

It does not mean that the framework should not be used for whole application development, however it was never designed for that purpose. StepTalk application development is a form of very fast prototyping of an application.

The StepTalk package features a framework, set of tools, [[Scripting language bundle|language bundle]], modules and object finders. '''The framework''' provides an application interface for developers to make their products scriptable. For more information about the tools, see [[StepTalk tools]]. Concerning the scripting language, the StepTalk is a '''language independent framework''' It can be extended via "language bundles" to provide and support other scripting languages. An experimental language bundle for Guile is included in the sources package.

The default scripting language in StepTalk is [[Smalltalk]]. This is because Smalltalk is a very simple language and it is easy to learn. There are just a few basic principles that the user has to know to be able to use the language and it is close to the natural language. [[Smalltalk]] uses a similar approach to that of [[Objective-C]], the language used in GNUstep itself.

'''Object Finders''' are an illusion of single objective environment. Name of an object may me known, but the object itself not. The object may be an application or it may reside on other host. Object Finder is an object that will search for object by specified name.

* '''Distributed Object Finder''' - This finder will try to look for a registered named object. It is possible to specify list of possible hosts where the object may reside and to specify a program that will provide the object if it cannot be found.
* '''Application Finder''' - Looks for a locally installed application and tries to connect to it. If the application is not running, it will try to launch it.

== Download ==

* [ftp://ftp.gnustep.org/pub/gnustep/libs/ Source]
* [http://packages.debian.org/cgi-bin/search_packages.pl?keywords=steptalk&searchon=sourcenames&version=all&release=all&exact=1 Debian packages]

* [http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-libs/StepTalk/ Browse CVS]

Get it by CVS:

export CVS_RSH="ssh"
cvs -z3 -d:ext:anoncvs@savannah.gnu.org:/cvsroot/gnustep co StepTalk

== The Framework ==

Classes:

* [[STContext]]
* [[STEnvironment]]
* [[STScriptManager]]
* [[STScriptObject]]

== TODO ==

For more information about what should be done in StepTalk see [[StepTalk TODO]].

== Projects using StepTalk ==

[http://www.moltalk.org/ MolTalk] - a computational environment for doing Structural Bioinformatics. It interprets PDB formatted files and creates an object representation of the structure-chain-residue-atom hierarchy. Through the use of MolTalk, the PDB suddenly becomes an object-oriented database.

----

See also: [[Scripting]], [http://www.smalltalk.org/ Smalltalk.org]

[[Category:Scripting]] [[Category:Frameworks]]

Application News

2005-06-21T06:52:07Z

Stefan Urbanek:

{| border="1" cellpadding="2"
! Date !! Application and Link !! Version
|-
| 21. Jun 2005 || [ftp://ftp.gnustep.org/pub/gnustep/libs/StepTalk-0.9.0.tar.gz StepTalk] || 0.9.0
|-
| 8. Jun 2005 || [http://www.eskimo.com/~pburns/Dictionaries Jishyo] || 0.1
|-
| 8. Mar 2005 || [http://freshmeat.net/projects/emacs Emacs] || 8.0-rc1
|-
| 6. Mar 2005 || [http://www.gnustep.it/enrico/gworkspace/ GWorkspace] || 0.7.0
|-
| 2. Mar 2005 || [http://freshmeat.net/projects/price PRICE] || 0.5
|-
| 1. Mar 2005 || [http://freshmeat.net/projects/gorm Gorm] || 0.9.2
|-
|23. Feb 2005 || [http://netclasses.aeruder.net/ netclasses] || 1.03
|-
|23. Feb 2005 || [ftp://ftp.gnustep.org/pub/gnustep/libs RIGS] || 0.2.2
|}

== Older News ==
[[Application_News_2004|2004]], [[Application_News_2003|2003]], [[Application_News_2002|2002]]

Main Page

2005-06-21T06:48:18Z

Stefan Urbanek: Despam (huh, invisible spam??)

{| style="border:1px solid black; background-color:lavender; padding:10pt;"
|+
| '''GNUstep''' is a [[Portability|cross-platform]], object-oriented set of [[Frameworks|frameworks]] for desktop application [[Development tools|development]]. The set of frameworks, based on [[OpenStep]] (now [[Cocoa]]), enables developers to rapidly build sophisticated software by employing a large library of reusable software components. GNUstep is already used [[GNUstep in production|in production]] environments at several organizations.
|}

== About GNUstep ==

[http://www.gnustep.org GNUstep home page]

[[Project development|Contact and Project development]]

[[Architecture]]

[[FAQ]]

[[Application News ]]

== Users ==
[[GNUstep_Installation_Process|GNUstep Installation Process]]

[[Internationalisation]]

[[GNUstep environments]]

[[Wish list]]

[[Artworks]]

== Developers ==

[[Development Subprojects]] ([[Themability]], [[Portability]], [[Package management]], [[I18n]], ...)

[[Development tools]]

[[Applications]]

[[Frameworks]]

[[Installation process]]

[[Scripting]]

== [[Glossary]] ==

== About Wiki ==

[http://www.possibility.com/epowiki/Wiki.jsp?page=HowToOrganizeWiki How To Organize Wiki]

[http://meta.wikimedia.org/wiki/MediaWiki_development Wiki Dev Doc]

[http://meta.wikimedia.org/wiki/MediaWiki_User%27s_Guide User'sGuide]

[http://meta.wikimedia.org/wiki/MediaWiki_FAQ FAQ]

[http://wikipedia.sourceforge.net WikiPedia]

StepTalk TODO

2005-06-21T06:46:10Z

Stefan Urbanek: /* 1.0 release */

If you would like to help [[StepTalk]], just contact me and I will guide you. Requirements: courage only :-)

Contact: [[User:Stefan Urbanek|Stefan Urbanek]]

== 1.0 release ==

* implement STActor (reuse code from STScriptObject and make the class obsolete)
* implement NSRect object - see STStruct object
* implement distant conversations
* create stenvironment tool

=== STEnvironment tool ===

First, changes to the STConversation is needed as follows:
* method executing code should not return a value
* script result object should be fetched by method: -(id)result or -(bycopy id)resultByCopy;
* conversation object should collect error messages - it should hold kind of transcript
* it would be great if conversation object can send notifications when transcript was updated
* conversation object should hold last exception raised by the script

Then stand-alone process should be created with following functionality:
* point of the stand alone process is that it can load any framework it likes and it should provide semi-persistent environment holding intermediate results of a inter-process and inter-application tasks
* one creates an STDistantEnvironment object - the object is in fact represented by single process that will be launched on -init
* the environment process will handle all execution requests - connections are created in form of conversations: user makes conversation with the environment
* environment is "live" until someone requests it to die

To make it more clear about the STEnvironment stand-alone process, here is an analogy:
* stenvironment process = database instance
* conversation = database connection
* StepTalk script = SQL script
* result = SQL script result (rows, message, ...)

one should be able to do following:

stenv create experiment
stenv execute experiment script.st
stenv execute experiment script2.st

...
env = [STEnvironment distantEnvironmentWithName:@"experiment"];
conversation = [STConversation conversationWithEnvironment:env language:nil];
[conversation executeScript:aScript];
result = [conversation resultByCopy]; /* or .... [conversation result] */
...

== Smalltalk ==

* Rewrite Smalltalk compiler (grammar)
** Remove STBytecodeInterpreter and use only STCompiler. How?
Simply convert language constructions into 'command' objects like
SmalltalkStatement, SmalltalkPrimary, SmalltalkMethodSend, ...
and implement executeInEnvironment:context:receiver:

* Update application scripting to use STConversation

== Other ==

* handle 'connection did die' notification for distant objects in STEnvironment
* fix class-info lookup for proxies in STEnvironment
* Smalltalk: separate compiler and compilation context
* create a 'Shell' scripting environment
* Create ApplicationScripting framework, instead of bundle. It should offer
passive application scripting (without linking) and active app. scripting
(linking with the framewotk). Give it some reasonable name, becauase that one
is already used by Apple
* Add framework list into environment description
* Change Modules to Frameworks
* Fill implementation of STScriptObject, STMethod and related STEngine methods
* Remove empty directories (Source, Modules/StepTalk)
* Replace STMethod languageName with map table of method class->engine class

* integrate with Gorm - use Script objects, make a palette for Gorm with script objects

Gorm Manual

2005-04-27T08:57:52Z

Stefan Urbanek: removed spam

== Guide to the Gorm application ==

{| style="border:1px solid black; background-color:lavender; padding:10pt;"
|+
|
Documentation authors:
* Gregory John Casamento <greg_casamento@yahoo.com>
* Richard Frith-Macdonald <richard@brainstorm.co.uk>

''Copyright 1999,2000,2004,2005 Free Software Foundation, Inc.''

''License: FDL 1.2''
|}

=== Gorm Developers ===

* Gregory John Casamento <greg_casamento@yahoo.com> Is the current maintaner of Gorm. Has implemented lots of new features and rewritten large portions of the existing code.
* Richard Frith-Macdonald <richard@brainstorm.co.uk> wrote the original version of Gorm as part of the GNUstep project.
* Pierre-Yves Rivaille <gnustep@rivaille.net> Is also a major contributor to the Gorm application.

== Overview ==

Gorm is an application for creating the user interface (and possibly entire
applications) for a GNUstep application. Initially a close clone of the old
NeXTstep 3.3 Interface Builder application, I expect that Gorm will mutate
beyond the capabilities of that app.

GNUstep is an object-oriented programming framework and a collection of tools
developed for or using the GNUstep libraries.

You can find out more about GNUstep at [http://www.gnustep.org]

The basic idea behind Gorm is simple - it provides a graphical user interface
with which to connect together objects from the GNUstep libraries (as well as
custom-written objects) and set their attributes in an easy to use manner.

The collection of objects is then saved as a document which can either be
re-loaded into Gorm for further editing, or can be loaded into a running
GNUstep application in order to provide that application with a user
interface or some subsystem.

This manual assumes a working knowledge of Objective-C and C. These are
necessary prerequisites to understanding some of the technical details and
examples given here.

This manual is ment to cover basic operation of the Gorm application. More about the GNUstep development and programming, please refer to the links at the end of this document.

=== Major features ===

* Drag-and-drop creation of GUI elements from palettes.
* Direct on-screen manipulation of GUI elements
* Manipulation and examination of objects via inspectors.
* Drag-and-drop creation of connections between objects.
* Interactive test mode for interfaces/object-networks under development.
* Saving data in a format loadable by GNUstep applications.
* Run-time loading of additional palettes that may be written using an API

== First contact ==

To launch the Gorm application, select it in the workspace's file viewer or from the dock. If you are using terminal, then type following on the command line:

gopen Gorm.app

=== Menu ===

Here is a description of the menu structure and what each menu does -

* Info: The info menu produces a submenu ...
** Info Panel: A panel giving very limited information about Gorm
** Preferences: A panel allowing you to set preferences
** Help (not implemented)
** A panel providing general help on using Gorm

* Document: The Document menu item produces a submenu ...
** Open: This produces an open panel that lets you open a Gorm document.
You use this if you want to use Gorm to edit an exisiting document.
** New Application: This creates a new application document within Gorm, you may then use the Palettes panel to drag new objects into the document.
** New Module: Contains a submenu, which also contains:
*** New Empty: produces an empty document with only NSFirst and NSOwner.
*** New Inspector: produces a document with NSOwner, NSFirst and a window which is the correct size for an Inspector.
*** New Palette: produces a document which is like the one by New Inspector, but it's window is the right size for a Palette.
** Save: This saves the current document
** Save As: This saves the current document to a new file and changes the document name to match the new name on disk.
** Save All: This saves all documents currently being edited by Gorm.
** Revert To Saved: This removes all changes made to the document sunce the last save, or since the document was opened.
** Test Interface: This provides interactive testing of the active document. To end testing, you need to select the quit menu item.
** Miniaturize: This miniaturises the active document (or whatever panel is currently key).
** Close: This closes the currenly active document.
** Debug: Prints some useful internal information.
** Load Sound: Loads a sound into the .gorm file.
** Load Image: Loads an image into the .gorm file.

* Edit: In addition to the usual Cut, Copy, Paste, Delete Select All, this menu also contains:

** Group: Which produces a submenu
*** In Splitview: Groups views into an NSSplitView. Gorm does this based on the relative positions of the views being grouped. It determines the orientation and the order of th views and then groups them either vertically or horizontally in the order they appear on the screen.
*** In Box: Simply groups all of the views into one NSBox.
*** In ScrollView: Simply groups all of the views into one NSScrollView.
*** Ungroup: Ungroups the contained views.

** Set Name: This allows the user to set a name for a given object in the Objects view in the main document window.

** Disable Guideline: This item toggles between Enable Guideline and Disable Guideline. This allows the user to turn on or off the guides which appear when placing views in a window or view in Gorm.

* Classes: Contains menus for working with classes.
** Create Subclass: Creates a subclass of the currently selected class in the current document classes view.
** Load Class: Loads a class from a .h file into the current document.
** Create Class Files: Generates a .h and .m file from the currently selected class in the current document classes view.
** Instantiate: Creates an instance of the selected class in the current document classes view.
** Add Outlet/Action: Adds an outlet or an action depending on what is selected in the document classes view. If the outlet icon is selected, it will add an outlet, if it the action icon is selected it will add an action.
** Remove: Removes the currently selected outlet, action or class.

* Tools: Contains the inspector and the palette menus
** Inspector: Shows the inspector
** Palette: Shows the palette
** Load Palette: Opens a file panel and allows the user to load a palette into Gorm.

* Windows: Shows currently open windows.

* Services: Shows currently available services.

* Hide: Hides the application.

* Quit: Quits the application.

=== Preferences ===

The preferences panel contains a number of useful customizable options which can be used to modify the behavior of Gorm.

Some of these defaults can be safely modified from the command line by the user.
* PreloadHeaders:
The user can define a set of headers to load when Gorm starts creation of a new .gorm file. This is useful when the user is building a framework or a set of interfaces for a large application.

* ShowInspectors:
Controls whether the inspector shows when Gorm is started.

* ShowPalettes:
Controls whether the palettes window shows when Gorm is started.

* BackupFile:
Determines if the old .gorm is moved to .gorm~ when the modified version is saved.

== Basic Concepts ==

This chapter will explain some of the basic things you need to understand before starting work on a new application.

First you need to understand a few basic concepts. Gorm's main window includes a few standard entries which must be explained before we can proceed. The basic objects are abstract and they are being concretised on the runtime. They are:

* an owner of the object model or the user interface - NSOwner
* firs responder - an object or a view that will receive actions as first - NSFirst
* a font manager representation - NSFont

'''NSOwner''' is the class which "owns" the interface. This is, by default, [[NSApplication]], but it can be any class you like. You can change it by selecting NSOwner in the document window and going to the "Custom Class" inspector in the inspectors window. From there, you should see all of the classes which the NSOwner can assume. We'll discuss more about this later when we go over how to create a new application

'''NSFirst''' is your interface to the responder chain. NSFirst is representative of the current "first responder" in the application. When you want a message, such as a changeFont: message, to go to the current first responder from, say, a menu, you connect the menu item to the NSFirst object in the document window. By doing this, it means that whichever object has first responder status at that time in the application will become the reciever of the "changeFont:" message.

'''NSFont''' represents the NSFontManager object for the application. This object is a shared singleton. This means that, for any given app, there should be only one instance of the object. This object is generally added to the document window when another objec, such as a Font menu item, is added to the interface, which, in turn, requires that this object be added to the document.

=== Responder and responder chain ===

A responder is any subclass of NSResponder. This includes NSWindow, NSView and all of the NSControl subclasses.

The '''responder chain''' is a sequence of objects which are called to determine where a message sent to the first responder will go. A message invoked on the first responder will be invoked on the first object in the responder chain which responds to that message.

The object which this message will be called on is determined in the method [NSApplication targetForAction:]. The call sequence is as follows, it will only proceed to the next step in each case if the current step fails to respond to the message which was invoked:

* The firstResponder of the keyWindow, if one exists.
* Iterates through all responders by pulling each in the linked list of responders for the key window.
* It then tries the keyWindow.
* Then the keyWindow's delegate
* if the application is document based it tries the document controller object for the key window.
* then it tries the mainWindow's list of responders (as above)
* the mainWindow's delegate
* if the app is document based, it tries the document controller for the main window
* and finally, it tries the NSApplication delegate.

If all of the options in this list are exhausted, it then gives up and returns nil for the object which is to respond.

== Creating an Application Interface ==

Gorm provides you with prebuilt interface template for an application. Note that to create whole application you would need to use the [[ProjectCenter]] or other development tools.

If you have ProjectCenter create an "Application" project. Create it with the name "FirstApp". From there you can open the MainMenu.gorm by clicking on interfaces and selecting MainMenu.gorm. If Gorm.app is properly installed, you Gorm should start up.

If you don't have ProjectCenter, you can create the Gorm file by hand. First you need to start Gorm. You can either do this by doing:

You then need to select the Document menu, and then New Application. This should produce a new document window, with a menu and an empty window. This should be the same as with the ProjectCenter gorm file since this is the basic starting point for an application.

For the sections below... only do one or the other, not both.

== Editing the interface ==

=== Adding Controls from the Palette ===

Go to the Gorm menu and select Tools, then Palettes. This will bring the palette window to the front. The second palette from the left is the "ControlsPalette". Select that one and find the button object (it should have the word "Button" in it). Drag that to the window and drop it anywhere you like.

Repeat this operation with the text field. It's the control with "Text" in it. We are now ready to start making connections between different objects in the document.

=== Making Connections ===

The type of application we are creating is known as a "NSApplication delegate" this means that the MyController object will be set as the delegate of NSApplication.

To make this connection click on NSOwner and hold down the Control button, keep it pressed as you drag from the NSOwner object to the MyController object. The inspectors window should change to the Connections inspector and should show two outlets "delegate" and "menu". Select the "delegate", at this point you should see a green S and a purple T on the NSOwner and MyController objects respectively, and press the "Connect" button in the inspector. In the "Connections" section of the inspector you should see an entry which looks similar to "delegate (MyController)" this indicates that the connection has been made.

Now we need to make connections from the controller to the textfield and from the controller to the button. Select the MyController object and Control-Drag (as before) from the object to the text field, this will make an outlet connection. You should see the connections inspector again, this time select the "value" outlet and hit Connect.

Next, control-drag from the button to the controller, this will make an action connection. The connections inspector should again appear. This time you need to select the "target" outlet, to get the list of actions. The list should have only one entry, which is "buttonPressed:" since this is the one we added earlier. Press Connect. You should see an entry like "buttonPressed: (MyController" in the Connections section of the inspector.

It is also possible to make this connection to NSFirst, but to keep things simple, make it directly to the object. If you make the connection to buttonPressed: on NSFirst the functionality of the application will be unchanged, but the invocation will take the path described above in the section which describes "The Responder Chain".

=== Saving the gorm file ===

At this point you must save the .gorm file. Go to the Gorm menu and click Documents and then select "Save". If the document was opened from a pre-existing .gorm, it will save to that same file name. If it is an UNTITLED .gorm file a file dialog will appear and you will need to select the directory where you want to store the .gorm file and type the name of the .gorm file.

== Custom classes ==

There are two ways to do create a custom class in Gorm. I will take you through each step by step. First click on the classes icon in the toolbar on the top of the Gorm document window. You should see the view below change to an outline view containing a list of class names. Once this happens we're ready to create a class.

Select the class you wish to subclass in the outline view. For our example we will use the simplest: NSObject. Select it by clicking on the class name once. Then go to the Classes menu in the main menu and select Create Subclass (you can also type Alt-Shift-c, which will do this as well. The new class will be created in the list with the name "NewClass".

=== Using The Outline View ===

Double click on the subclass name to make it editable. Type the name of the class and hit enter. For our example, please use the class name MyController. When you hit enter an alert panel will appear and warn you about breaking connections, simply select OK and continue.

This method of inputting the classes was inspired by IB in OPENSTEP 4.2/Mach which had functionality very similar to this. For users of that the transition to Gorm will be seamless.

=== Object awakening ===

The method ''awakeFromNib'' is called on any custom object which is unarchived from a nib/gorm file. This method is called on all objects after the entire archive has been loaded into memory and all connections have been made. Given all of this, you should not make any assumptions at all about which objects have been called and which have not. You should not release any objects in this method.

=== Outlets and Actions ===

Too add an outlet, select the round icon with the two horizontal lines in it (it sort of looks like a wall outlet. This should become depressed. Here you need to go to the Gorm Menu, under Classes select "Add Outlet/Action". Each time you press this menu item another outlet will be added with a name similar to newOutlet, as you add more the number at the end will increase. For now add only one outlet.

To rename the outlet simply double click it and change it's name like you did the class above to "value" for the sake of our example.

The steps to add on action are precisely the same as adding an outlet, except you must click on the button which looks like a target (a circle with a + inside). Add an action and name it "buttonPressed:" for the sake of our example.

=== Using The Class Edit Inspector ===

This way is much more inline with the "OPENSTEP/GNUstep" philosophy. For each object there is an inspector, even for Class objects.

Once you have created the class as described in the previous section "Creating a Class In Gorm", you must skip to this section to use the inspector. In the Gorm main menu select Tools and then select "Inspectors". This will make certain that the inspectors window is being displayed. Once the inspectors window is up move the pulldown on the top to "Attributes" and select the class you created which should, at this point, have the name "NewClass". You'll notice that the "Class" field at the top which shows the name's background color has turned white, instead of grey. This indicates that this class name is editable. Erase "NewClass" from the text field and type "MyController".

Adding outlets is very intuitive in the inspector. Simply select the "Outlets" tab in the tab view and click "Add" to add more outlets, and "Remove" to remove them. For the sake of our example, add one outlet and name it "value".

Very much like above only with the "Actions" tab, add an action called button pressed.

=== Instantiating The Class ===

In the Classes outline view select the new class you've created, now called MyController and then go to the Gorm menu and select Classes, and then Instantiate. The document window should shift from the classes view to the objects view. Amoung the set of objects should be a new object called MyController.

=== Generating .h and .m files from the class. ===

This is different than saving, some people have gotten this confused with the idea of Gorm generating the code for the gui. Gorm does nothing of the sort (grin).

Go to the Classes section in the Document window and select the MyController class yet again. Now go to the Gorm menu and select Classes and the select "Create Class Files". This will bring up a file panel and it allow you to select the directory in which to put the files. It will first create the MyController.m file and then the MyController.h file. Simply select the directory in which your app will reside and hit okay for both. You can change the names, but the default ones, which are based on the class name, should be sufficient. When you look at the .m for this class, you should see the buttonPressed: method with the comment /* insert your code here */ in it. Delete this comment and add:

[value setStringValue: @"Hello"];

The class should look like this after you're done:

#include <AppKit/AppKit.h>
#include "MyController.h"
@implementation MyController
- (void) buttonPressed: (id)sender
{
[value setStringValue: @"Hello"];
}
@end

You recall, we connected the textfield to the "value" variable. The call above causes the method setStringValue to be invoked on the textfield you added to the window.

Also, note that the name of the method is "buttonPressed:". This is the action which is bound to the button. When it is pressed the text in the textfield should change to "Hello".

You now need to build the application either by copying in a GNUmakefile and making the appropriate changes or by using ProjectCenter's build capability, depending on if you use it or not.

This app is available as "SimpleApp" in the Examples directory under the Documentation directory distributed with Gorm. Hopefully this has helped to demonstrate, albeit on a small scale, the capabilities of Gorm. In later chapters we will cover more advanced application architectures and topics.

== A Simple Application ==

This chapter will describe an application, very much like the previous one, but using a slightly different structure. This application builds on the previous application and uses WinController as the NSOwner of the app instead of making it the delegate of NSApplication.

=== Adding Menu Items ===

Select the first palette in the palette window, this should be the MenusPalette. The palette will have a bunch of pre-made menu items on it that you can add. We want to keep this simple, so grab the one called "Item" and drag it over to the menu in main menu nib (the menu on the screen, not the one in the objects view). As you have this object over the menu, the copy/paste mouse cursor should appear (it looks something like one box over another box at a 45 degree angle). Where you drop the menu determines it's position in the menu. You can always drag it to a new position after you've placed it by simply selecting and dragging up or down. Once you've placed the menu item, double click on the title and change it to "Open"

You can also change the name in the NSMenuItem attributes inspector. Now you must add openWindow: to MyController and make the connection from the "Open" menu item to NSFirst. In the connections inspector, find the "openWindow:" action. You could simply make the connection directly, but this is an exaple to show you that this connection will work as well. Whichever object has First Responder status will be tested to see if it responds to this method.

The implementation for openWindow: in MyController should simply be:

- (void) openWindow: (id) sender
{
winController = [[WinController alloc] init];
}

Also add the winController attribute and an include to allow WinController to be referenced in the MyController.m file.

=== Making a Controller-based .gorm file ===

Create a new .gorm file as described in the previous section using the "New Module" menu item. Under "New Module" select "New Empty". This should produce a .gorm file with only NSOwner and NSFirst. From the WindowsPalette (which should be the second palette in the palette window) drag a window to the location where you want it to appear on the screen. In the window add a button called "Close".

Go through the same steps you went through previously to create MyController, except for adding the outlets/actions, but this time with the name WinController. Add an outlet called window and an action called "closeWindow:".

Now, instead of instantiating the class go back to the objects view and select the NSOwner object. After that select the "Custom Class" inspector. Look for the entry for WinController and select it. You now must connect the "window" outlet to the Window you added previously.

Switch back to the objects view, then Control-Drag not to the window on the screen, but to the window's representation in the objects view. In the connection inspector select the window outlet and click Ok.

Save the .gorm as using the name Controller.gorm in the project directory.

Generate the Controller.h and Controller.h files as described in the previous section.

=== Add the init method to WinController ===

Add an implementation of the action "closeWindow:" to WinController and also an init which loads the gorm/nib file and declares itself as the owner. Here's how:

/* All Rights reserved */
#include <AppKit/AppKit.h>
#include "WinController.h"
@implementation WinController
- (id) init
{
if((self = [super init]) != nil)
{
if([NSBundle loadNibNamed: @"Controller" owner: self] == NO)
{
NSLog(@"Problem loading interface");
return nil;
}
[window makeKeyAndOrderFront: self];
}
return self;
}
// close
- (void) closeWindow: (id) sender
{
[window close];
}
// dealloc
- (void) dealloc
{
[super dealloc];
RELEASE(window);
}
@end

The Controller gorm will be loaded and the connections will be made to the current instance, i.e. window will point to the window object instantianted in the .gorm file and all actions declared in the .gorm file which are attached to the object NSOwner will be resolved on self.

=== Running the App ===

Type the command:

gopen Controller.app

on the command line in the project directory. Once the application has started it should look very much like the first application. Select the "Open" button from the Menu and you should see the second window pop up, now choose close, this will call the method "closeWindow:" which should cause the window to disappear.

== Advanced Topics ==

=== Restrictions On Your Custom Subclasses ===

The restrictions here are the same as those in Apple's InterfaceBuilder. In general, you cannot have additional information which is expected to be decoded in an initWithCoder: method from a custom class which uses one of the methods in the previous section. This is because, by definition, Gorm doesn't know anything about these classes and allowing you to use them in Gorm in this way is a convenience to make it simpler for the developer. Gorm therefore, must use one of the proxies to encode the class since it cannot encode the class directly.

How can you get your classes into Gorm, you say? I'm pleased that you asked me that question. The best way to make your class known to Gorm so that you don't need to worry about the above restriction is to add a palette which contains your class. In this way, because you're literally linking the class into Gorm, you're making the class and it's structure known to Gorm so that it can encode the class directly. With the new palette loaded you can load and save classes containing real instances, not proxies, of your class encoded directly in the .gorm file. How to create a palette is discussed at length in the following section.

=== Graphical Objects In A Palette ===

You are, by now, familiar with the built in palettes which are provided with Gorm. Palettes are a powerful feature which allows the developer to add his/her own objects to Gorm. It is possible for a developer to write custom inspectors, editors and palettes for use with Gorm. A good example of a custom palette is palettetest in the dev-apps/test in the GNUstep distribution. Assuming you don't have that, however, I will explain precisely what you need to do in order to create a simple palette. The entire process is very short and suprisingly simple. First open Gorm and select Gorm->Document->New Module->New Palette. This will create a palette sized window. Once that's done go to the classes view in the main document window and find "IBPalette" in the class list. Create a subclass of that, the name can be whatever you want. For the purposes of our example we'll call it MyPalette. Drag a custom view to the window and choose the class you would like to add to the palette from one of your custom classes.

Once you've done this, generate the code for the classes (discussed in previous chapters). In the code, you'll add a method called "-(void) finishInstantiate" leave it empty for now. In the makefile for the palette make sure that the library or framework the view comes from is linked with the palette. Now build the palette.

After the palette is built you're ready to load it into Gorm. Go to the preferences panel and go to "Palettes". This should bring up a table view. Click on add. You should see a open dialog open. Select the palette bundle with this. If the palette is successfully loaded, you should see the name appear in the list. One thing to note here. Once a palette is loaded, it can't be unloaded until you close and restart Gorm. This is because by loading the palette bundle, the code in the bundle is being linked into Gorm. This can't be undone, once it's done.

Now, you should see the palette in the set of palettes in the palette window. Simply scroll over to it and select it's icon. When you do this, you should see the view that you set up using the custom view displayed as an actual instance. Note that we used one of the techniques listed above, it is possible to use any of the three for any object you add to your palette. You can now drag the view from the palette to a new window.

=== Non-Graphical Objects In A Palette ===
You may recall the creation of a method called "-(void) finishInstantiate" in the previous section. This section will make full use of that method. Re-open the palette you created before, but this time add an image view to the window. Then add to the image view, the icon you want to represent the non-graphical object. Here you'll need to add an ivar to the MyPalette class in both Gorm and in your source code called, imageView. Once you've done this make the connection between the image view and it's ivar.

Assuming that the class is called "NonUIObject", in finishInstantiate, you'll need to add the following line of code:

-(void) finishInstantiate
{
id obj = [NonUIObject new];
[self associateObject: obj type: IBObjectPboardType with: imageView];
}

This code has the effect of associating the non-ui object with the ui object you just added to represent it. When you drag and drop the element which prepresents the object to something, it will copy the object, not the ui element, to the destination.

Congratulations, you now know how Palettes work.

== Frequently Asked Questions ==

See: [[Gorm FAQ]]

== Implementation details ==

This chapter describes some details about implementation of various features of Gorm. You should read it if you are a developer that would like to add custom objects, inspectors or would like to do other Gorm development.

The IB documentation on how object selection is managed and how editors and
inspectors are used is unclear ... so the author of Gorm gone his own way.

When a document is loaded, the document object creates an editor attached
to each top-level object in the user interface (NSMenu and NSWindow objects).
These editors must be aware of their edited objects being clicked upon, and
clicking on one of these should cause the corresponding editor to become the
active editor.

The ''active editor'' is responsible for handling selection of the edited object
(and any objects below it in the object hierarchy). Upon change of selection,
the editor is responsible for sending an IBSelectionChangedNotification with
the selection owner (normally the editor itsself) as the notification owner.

The main application watches for these notifications in order to keep track
of who has the selection.

=== Connections ===

The connection API is the same as that for [[Interface Builder|IB]], but with the extension that the
document object must implement [-windowAndRect:forObject:] to return the
window in which the object is being displayed, and the rectangle enclosing
the object (in window base coordinates).

This information is needed by Gorm so that it can mark the connection.

The editors mananging the drag-and-drop operation for a connection must call:

[NSApp -displayConnectionBetween:and:]

to tell Gorm to update its display. This method sets the values currently returned by:

[NSApp -connectSource] and
[NSApp -connectDestination]

This section will cover some topics which won't be of general interest to most users. The details in this section pertain to the internal workings of Gorm.

== Gorm file format ==

The current Gorm file format is basically just a set of objects, encoded one after another in a continuous stream with some markers indicating when a new class starts or which class is encoded.

=== The Name Table ===

Each object in the .gorm file has a name assigned to it by the application. This allows Gorm to refer to the objects by a name once they are loaded rather than an address. Each name is associated with it's object in a dictionary which preserves the overall structure of the GUI which has been created.

'''The Custom Class Table''' - This is only used when the user has associated a custom class with an existing instance in the gorm file. If the user has, for instance, added an NSWindow to the gorm, he/she can use the custom class inspector to select a subclass of NSWindow to change to.

'''Connections Array''' - This array is used to form the connections after the .gorm file is loaded. The method [... establishConnection] is never called on either NSNibControlConnector or NSNibOutletConnector objects while in Gorm. This prevents the connections from having any effect while they are being edited in Gorm itself. Once they are loaded, the establishConnection method is called and the connections are made.

=== Custom Class Encoding ===

Custom objects are an interesting challenge in Gorm. By definition, custom classes are not known to Gorm, unless they are in a palette (covered elsewhere). For classes which are not in a palette instances of these classes in Gorm are encoding in one of three ways:

* '''Proxy''' - This is a standin object which takes the place of the custom object. This is usually used when the superclass of the object is a non-graphical object, such as a controller. The init message is called on this object when it's unarchived.
* '''Custom View''' - This is a standin view object similar to the one descrribed above, but it is a subclass of NSView. When this is used the initWithFrame: message is called on the view instance which is created (based on what view subclass the user selects)
* '''Template''' - Probably the most interesting of the three. This is a standin class which uses an existing instance created in Gorm to build a custom subclass from. For instance when a window subclass is created, call it MyWindow, a template class called GSWindowTemplate is used to hold the NSWindow created in Gorm as well as the name of the subclass to be created when the class is unarchived outside of Gorm as well as some additional information. When the classes are unarchived in the running app, the designated initializer for that class will be invoked, except in the case of [[NSControl]] subclasses. See the Apple documentation for more information.

All custom instances have awakeFromNib invoked on them when they are unarchived from the .gorm file. This allows the user to do whatever additional setup that needs to be done, such as setting attribute. Classes which are "known" are, of course, directly encoded into the .gorm file.

== References ==

[[ProjectCenter]] - GNUstep integrated development environment

[[Category:Development]]

Applications

2005-04-27T08:57:11Z

Stefan Urbanek: removed spam

There are several lists of applications:

http://freshmeat.net/search/?fourohfour=1&q=gnustep

http://www.gnustep.org/GSWeb/GSApps.woa

http://livecd.gnustep.org

FAQ

2005-04-26T10:57:07Z

Stefan Urbanek:

* [http://www.gnustep.org/resources/documentation/User/GNUstep/userfaq_toc.html User FAQ]
* [http://www.gnustep.org/resources/documentation/User/GNUstep/faq_toc.html Developer FAQ]
* [[GNUstepIsNotWindowMaker]]

Here are few FAQ from the old wiki :

: <MrBIOS-TS> WELCOME TO GNUSTEP! Don't ever ask these questions. Before you ask them, here are the answers!</tongue-in-cheek>

:'''Q.''' Why don't you just have Gorm output Renaissance files?<br/>
:'''A.''' Philosophical and architectural incompatibilities.

:'''Q.''' Is there a way to install GNUstep on Mac OS X? Perhaps some howto?<br/>
:'''Q.''' Is there any way to use gnustep-make and gnustep-base without using openapp/opentool?<br/>
:'''Q.''' Can GNUstep help with porting applications from MacOS-X? Is there any HOWTO on that? See for example Tamsys http://sourceforge.net/projects/tamsys. How difficult it should be to port it to Linux and GNUstep?<br/>
:'''A.''' Somehow relevant may be discussion on http://groups.google.com/groups?th=f8a07de1a707dbeb. Is there anything more?

:'''Q.''' Can I deploy my GNUstep application without requiring people to install GNUstep?
:'''A.''' No. Compare it to running Java applications without people requiring to install Java runtime environment.

Main Page

2005-04-22T09:21:05Z

Stefan Urbanek: remove spam

{| style="border:1px solid black; background-color:lavender; padding:10pt;"
|+
| '''GNUstep''' is a [[Portability|cross-platform]], object-oriented set of [[Frameworks|frameworks]] for desktop application [[Development tools|development]]. The set of frameworks, based on [[OpenStep]] (now [[Cocoa]]), enables developers to rapidly build sophisticated software by employing a large library of reusable software components. GNUstep is already used [[GNUstep in production|in production]] environments at several organizations.
|}

== About GNUstep ==

[http://www.gnustep.org GNUstep home page]

[[Project development|Contact and Project development]]

[[Architecture]]

[[FAQ]]

[[Application News ]]

== Users ==
[[GNUstep_Installation_Process|GNUstep Installation Process]]

[[Internationalisation]]

[[GNUstep environments]]

[[Wish list]]

== Developers ==

[[Development Subprojects]] ([[Themability]], [[Portability]], [[Package management]], [[I18n]], ...)

[[Development tools]]

[[Applications]]

[[Frameworks]]

[[Installation process]]

[[Scripting]]

== [[Glossary]] ==

== About Wiki ==

[http://www.possibility.com/epowiki/Wiki.jsp?page=HowToOrganizeWiki How To Organize Wiki]

[http://meta.wikimedia.org/wiki/MediaWiki_development Wiki Dev Doc]

[http://meta.wikimedia.org/wiki/MediaWiki_User%27s_Guide User'sGuide]

[http://meta.wikimedia.org/wiki/MediaWiki_FAQ FAQ]

[http://wikipedia.sourceforge.net WikiPedia]

I18n

2005-04-15T06:37:55Z

Stefan Urbanek: minor edits + few questions

Internationalisation (or localisation) touches:
* '''Input''' - how a user writes a text
* '''Presentation''' (or output) - how a text is presented to the user
* Aids - writing aids and processing mechanisms with and without user interaction
* Localisation of user interface

== Related informations ==

Input method standards:

* XIM
* IIIMF
* UIM
* kinput2

Output:

* vertical text layout
* bidi text layout
* opentype support
* [http://www.w3.org/TR/css3-text/ CSS3 Text Module]

== Requirements ==

Output:

* NSTextView
* Typesetters
* Opentype supports
* Word hyphenation
* Word segmentation

Input:

* NSTextInput protocol
* NSInputManager

Aid:

* Spell-checking NSSpellChecker

== Status ==

I'm trying to form a gnustep-i18n team and list all relevant subjects.
If you are experienced in this field, please help.

== FIXME ==

* what input method(s) GNUstep currently uses and for what backend? How?
* what output method(s) is used? How? Why?
* what aids are available? how they are backed? (for example, what spellchecking backend is used and how?)

HowToUseWiki

2005-04-05T06:46:37Z

Stefan Urbanek: Removed spam

Cocoa

2005-03-24T12:46:02Z

Stefan Urbanek:

From the [http://developer.apple.com/cocoa/ Apple] site: '''Cocoa''' is an object-oriented application environment designed specifically for developing Mac OS X-only native applications. The Cocoa frameworks include a complete set of classes, and for developers starting new Mac OS X-only projects, Cocoa provides the fastest way to full-featured, extensible, and maintainable applications. You can bring applications from UNIX and other platforms to Mac OS X quickly by using Cocoa to build state-of-the-art Aqua user interfaces while retaining most existing core code.

More info can be found at http://developer.apple.com/cocoa/

Predcessor to the Cocoa is [[OpenStep]].

OpenStep

2005-03-24T12:42:54Z

Stefan Urbanek: reference Cocoa

OpenStep is an Application Programming Interface (API) for creating applications using the Objective C language. It was published by NeXT Computer Inc. in 1994.

OpenStep consists of three parts:
* the [[Foundation]]Kit, a library of non-graphical objects;
* the [[AppKit]], a library of objects useful in creating graphical applications;
* and [[Display Postscript]], an interface for drawing to the screen using the PostScript graphics language.

The OpenStep specification is available in a couple of different formats from [http://www.gnustep.org/resources/resources.html].

Commercial successor of the OpenStep is Apple's [[Cocoa]].

Main Page

2005-03-24T12:42:02Z

Stefan Urbanek:

{| style="border:1px solid black; background-color:lavender; padding:10pt;"
|+
| '''GNUstep''' is a [[Portability|cross-platform]], object-oriented set of [[Frameworks|frameworks]] for desktop application [[Development tools|development]]. The set of frameworks, based on [[OpenStep]] (now [[Cocoa]]), enables developers to rapidly build sophisticated software by employing a large library of reusable software components. GNUstep is already used [[GNUstep in production|in production]] environments at several organizations.
|}

== About GNUstep ==

[http://www.gnustep.org GNUstep home page]

[[Project development|Contact and Project development]]

[[Architecture]]

[[FAQ]]

[[Application News ]]

== Users ==
[[GNUstep_Installation_Process|GNUstep Installation Process]]

[[Internationalisation]]

[[GNUstep environments]]

[[Wish list]]

== Developers ==

'''[[Development Subprojects]]''' (Themability, Portability, Package management, ...)

[[Development tools]]

[[Applications]]

[[Frameworks]]

[[Installation process]]

[[Scripting]]

== [[Glossary]] ==

== About Wiki ==

[http://www.possibility.com/epowiki/Wiki.jsp?page=HowToOrganizeWiki How To Organize Wiki]

[http://meta.wikimedia.org/wiki/MediaWiki_development Wiki Dev Doc]

[http://meta.wikimedia.org/wiki/MediaWiki_User%27s_Guide User'sGuide]

[http://meta.wikimedia.org/wiki/MediaWiki_FAQ FAQ]

[http://wikipedia.sourceforge.net WikiPedia]

Delegate

2005-03-21T12:20:36Z

Stefan Urbanek:

Extend with Delegates: http://cocoadevcentral.com/articles/000075.php

NSDocument

2005-03-20T19:50:05Z

Stefan Urbanek:

NSDocument is ...

== Code chunks ==

=== Multiple editors ===

If your document uses multiple editors and each is represented with a single [[NSWindowController]], you can commit all edits like in the following (obvious) code. Requirement is, that each NSWindowController should implement ''commitEditing''.

- (void)commitEdits
{
NSWindowController *controller;
NSEnumerator *enumerator;

enumerator = [[self windowControllers] objectEnumerator];

while( (controller = [enumerator nextObject]) )
{
if([controller respondsToSelector:@selector(commitEditing)])
{
[controller commitEditing];
}
}
}

AppKit

2005-03-20T19:45:58Z

Stefan Urbanek: /* Classes */

The GNUstep GUI Library is a library of objects useful for writing graphical applications. For example, it includes classes for drawing and manipulating graphics objects on the screen: [[NSWindow|windows]], [[NSMenu|menus]], [[NSButton|buttons]], [[NSSlider|sliders]], [[NSTextField|text fields]], and [[NSEvent|events]]. There are also many classes that offer operating-system-independent interfaces to [[NSImage|images]], [[NSCursor|cursors]], [[NSColor|colors]], [[NSFont|fonts]], [[NSPasteboard|pasteboards]], printing. There are also workspace support classes such as data links, open/save panels, context-dependent help, spell checking.

It provides functionality that aims to implement the `AppKit' portion of the [[OpenStep]] standard. However the implementation has been written to take advantage of GNUstep enhancements wherever possible.

The GNUstep GUI Library is divided into a front and back-end. The front-end contains the majority of implementation, but leaves out the low-level drawing and event code. Different back-ends will make GNUstep available on various platforms. The default GNU back-end currently runs on top of the X Window System and uses only Xlib calls for graphics. Another backend uses a Display Postscript Server for graphics. Much work will be saved by this clean separation between front and back-end, because it allows different platforms to share the large amount of front-end code. Documentation for how the individual backends work is coverered in a separate document.

== Features ==

* user interface elements (table views, browsers, matrices, scroll views)
* graphics (WYSIWYG, postscript-like graphics, bezier paths, image handling with multiple representations, graphical contextes)
* [[Colors|color management]] (calibrated vs. device colors; CMYK, RGB, HSB, gray and named color representations; alpha transparency)
* [[Text]] system features: rich text format, text attachements, layout manager, typesetter, rules, paragraph styles, font management, [[Spell checking|spell checking]]
* [[Document architecture|document management]]
* [[Printing|printing features]]: print operations, print panel and page layout
* help manager
* [[Pasteboard|pasteboard]] (aka clip board) services
* [[Spell checking|spell checker]]
* [[Workspace|workspace]] bindings for applications
* [[Drag and drop]] operations
* [[Application services|services]] sharing among applications

== Classes ==
* [[NSDocument]]
* [[NSTableView]]
* [[NSView]]

[[Category:Frameworks]]

DevelopmentKit

2005-03-19T13:12:30Z

Stefan Urbanek: added "mutable" flag

Develompent Kit Framework is [[ObjectiveC]]/[[GNUstep]] framework for generating Objective C code based projects and sources from applications.

Features:
* class compositing
* objective c source parsing and transforming into development objects (classes, methods, variables,...)
* source file generation using templates
* project building

Project Page: https://savannah.nongnu.org/projects/develkit/

[http://savannah.nongnu.org/cgi-bin/viewcvs/develkit/ Browse CVS Tree]

Author: [[user:Stefan Urbanek|Stefan Urbanek]]

== Tools ==

=== dkautogen ===
Autogenerate ObjectiveC Interface and Implementation methods

Usage:
dkautogen file1.h file2.h ...

Type 'dkautogen help' for more information.

To each .h and corresponding .m file a category DKGenerated is appended. If there is already such category, then it is replaced.

Instance variable keywords

hidden - do not generate accessor methods
exposed - expose accessor methods
retained - object is retained
notretained - object is NOT retained (weak reference)
readonly - instance variable is read only (setter is not generated)
mutable - instance variable is mutable (setter is generated despite "readonly" class default)
notarchived - ignore in archiving
object - instance variable is an object (see below)
customaccess - do not generate implementation of accessor methods, generate interface only

Class keywords (defaults for all instance variables)

hidden - all ivars are hidden
exposed - all ivars are exposed (accessors are generated)
retained - all objects are retained
notretained - objects are NOT retained
readonly - all instance variable are read only
objects - treat all unknown types as objects
customarchive - do not generate archiving methods
nosuperarchive - do not call archiving in superclass
customdealloc - do not generate -dealloc method

'''Known types'''

All standard C types including [[NSPoint]], [[NSSize]], [[NSRect]] and [[NSRange]] are treated as non-objects. By default only id and Class types are treated as objects.

Generated methods by default: accessors (getter and setter), dealloc methon, initWithCoder:, and encodeWithCoder

'''How to use'''

Attributes are written in same comments used for auto-documentation. They are read from comments after the LAST pipe '|' character in the comment and they should be separated by spaces. Example:

NSString *name; /** Object name | object readonly retained */

Class defaults are written immediately before @interface:

/** This is my class | nosuperarchive retained objects */
@interface MyClass : NSObject

Preferences (also usable as switches on commandline with '-' prefix):
interfaceTemplate - path to .h file template
implementationTemplate - path to .m file template
beginTag - tag used to mark beginning of generated code
endTag - tag used to mark end of generated code

Example:
dkautogen -implementationTemplate MyTemplate.m SomeClass.h

== Classes ==

* DKBuildMessage
* DKClass
* DKFramework
* DKFrameworkManager
* DKMethod
* DKObjectiveCParser
* DKProjectBuilder
* DKProject
* DKSourceGenerator
* DKTemplateMerger
* DKVariable

DevelKit reuses class [[AGSParser]] from [[autogsdoc]].

[[Category:Frameworks]]

GNUstep release procedure

2005-03-17T11:33:54Z

Stefan Urbanek:

Steps for releasing the GNUstep core libraries (as well as others):

1. Make sure news.texi and ReleaseNotes.gsdoc files are updated

2. Update the 'Version' file with the new version

3. Update the documentation and release notes in the main directory:

cd Documentation
make clean; make; make regenerate

4. Add a line in the ChangeLog, like:

'* Version 1.10.0' as well.

and commit the changed files.

5. Tag the release

make cvs-tag

6. Make a source distribution

make cvs-dist

7. Administrative stuff (scripts that I use to make this easier are in brackets):

* Make RPMS or whatever [gstep-distribute]
* Sign the packages [gstep-sign]
* Upload packages to ftp.gnustep.org [gstep-update, gstep-upload]
* Install the documentation and copy it to the web repository [update_documentation]
* Update the index.html and resources/downloads.php pages with the news.
* Commit the web repository.
* Make an announcement on info-gnustep@gnu.org, etc

''Note: gstep-distribute, gstep-update: must be run as root/sudo''

If the packages are used by the GNUstep umbrella package (runtime or development environment), then the ubrella package should be released too.

== Preparation ==

It is desired that the release is made from CVS checkout. The release should correspond to a tagged state in the CVS.

Also it is required that all release test passed. If not, the release should not be created. For more information about the tests see [[Quality assurance]].

Follow standard versioning guidelines.

[[Category:Project procedures]]

Talk:Roadmap

2005-03-14T14:13:18Z

Stefan Urbanek: Comments on clarifications

[[User:Arobert|Arobert]] writes: ''There are many parts of GUI that are not finished, though they do not come up as often in applications as the parts that are finished. They are marked in the code by "//FIXME" usually. One example is handling of scrollbars of multiple widths. OpenStep provides for both two fixed scrollbar widths (normal and small) and a variable-width option. Neither are supported in GUI (but are not used that often).''

Is that a "show stopper" for the 1.0 release? [[User:Stefan Urbanek|Stefan Urbanek]] 09:18, 23 Feb 2005 (CET)

''What needs to be done for GNUstep 1.0? Can someone provide a check-list? In the checklist, please provide a severity of the task, whether it is a blocker or if we can live without that.''

There are many parts of GUI that are not finished, though they do not come up as often in applications as the parts that are finished. They are marked in the code by "//FIXME" usually. One example is handling of scrollbars of multiple widths. OpenStep provides for both two fixed scrollbar widths (normal and small) and a variable-width option. Neither are supported in GUI (but are not used that often).

Base is almost entirely complete, excepting some Number formatting capabilities and maybe a couple of other things listed in the bug tracker.

== Clarifications ==

1) GNUstep RTE shouldn't include -make.

2) It should '''''only''''' include
-base
-gui
-back

that is all that is needed for the run-time environment so that is all that should be there.

3) The Developer Environment is a little trickier. It needs:
-runtime environment
-make
-Project Center
-Gorm
-Easy Diff would be good & we have it anyway.

Packaging

It is up to the distros to package for their system. We certainly can provide docs and guides to help make things easier and better but it remains that we're the upstream provider.

Many distros will ''not'' want a GNUstep Developer Environment package per se. They'll want it split into several packages, possibly with a meta-package for convenience. There are too many variations and decisions to be made about packaging for there to be a single distribution, especially in binary format.

Source Distro idea

The only distribution provided by the project itself should be the source distribution. GNUstep Startup is the 'package tool' for this. We want the source distro to be
- download and untar where-ever
- cd to Startup and execute InstallGNUstep

For this to work, the Startup system will need to be enhanced to build a more complete environment. It'll need to check to see what is available and what the OS is (for FS layout) and do appropriate things from there.
Maybe it needs to get information from a simple configuration file which a user can edit to specify what they want?

== Comments on clarifications ==

'''GNUstep RTE''' - Well, i think, that there should be some kind of 'launcher' application too. Some very simple app that can list and launch installed GNUstep applications. Something that can be described as ''computer-human interface to the gnustep environment''

'''Packagers''' - I agree, that packaging should be matter of host operating system. However! GNUstep shuold have mechanisms and/or tools for managing GNUstep 'packages' such as applications and frameworks. The packages belong to the GNUstep Env., not to the host operating system, therefore installing an application can be compared to adding a new macro to the MS Word. Yes, it is very extreme analogy, however GNUstep is stand-alone guest environment interacting with its surroundings. Applications, frameworks and bundles are in fact 'modules' or 'plug-ins' of one environment.

--[[User:Stefan Urbanek|Stefan Urbanek]] 15:13, 14 Mar 2005 (CET)

Talk:Installation on Windows

2005-03-10T15:06:10Z

Stefan Urbanek:

Are the *-bin.zip files needed? Are not the *-lib files sufficient?

[[User:Stefan Urbanek|Stefan Urbanek]] 16:06, 10 Mar 2005 (CET)

Installation on Windows

2005-03-10T15:05:07Z

Stefan Urbanek: Added more download links

== Install MinGW ==
Download MinGW-3.2.0-rc-3 or later from http://sourceforge.net/projects/mingw Install it into

C:/xxx/msys/1.0/mingw

(where /xxx/ is the top-level path you want to use, I use Nicola/GNUstep so I install it into C:/Nicola/GNUstep/msys/1.0/mingw) (earlier versions of MinGW won't work)

== Install msys ==

Download MSYS-1.0.10 or later from the same site. Install it into C:/xxx/msys/1.0
The postinstall script should ask you for the mingw location, then detect it and be happy that it's there and all is setup properly.

== Install msys developer toolkit ==

Download msysDTK-1.0.1 or later from the same site. Install it into

C:/xxx/msys/1.0

Now your MSYS/MinGW system should be setup! Go around and make sure you know how to use the Unix-like shell. Log into it and work in it.

== Download gnustep using cvs ==

== Install GNUstep make ==

go in core/make and do

./configure --prefix=/C/xxx/GNUstep
make
make install

== Setup your GNUstep environment ==

(you will need to do the same every time you start up your MSYS shell to do development)

. /C/xxx/GNUstep/System/Library/Makefiles/GNUstep.sh

Also, set HOMEPATH, HOMEDRIVE and HOME ... add the following lines to your ~/.profile:

export HOMEDRIVE=C:
export HOMEPATH=/home/Nicola
export HOME=/C/xxx/msys/1.0/home/Nicola
. /C/xxx/GNUstep/System/Library/Makefiles/GNUstep.sh

(obviously replacing 'Nicola' with your Login name) (not sure if this setting of HOMEDRIVE etc is really required, will investigate)

== Install the ObjC runtime ==

Download gnustep-objc, and compile it

make
make install

== Reinstall GNUstep make (with ObjC this time ==

go in core/make and reconfigure/recompile again so that gnustep-objc is detected:

make distclean
./configure
make
make install

gnustep-make should have detected your custom libobjc.

== Install ffcall ==

Download ffcall from the GNUstep website, and type:

./configure --prefix=$GNUSTEP_SYSTEM_ROOT
make
make install

== Install additional libs ==

Download the following packages:

[http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=73290 Download libintl]

libintl-0.11.5-2.bin.zip
libintl-0.11.5-2.lib.zip

[http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=17090 Download libiconv]

libiconv-1.8.1-bin.zip
libiconv-1.8.1-lib.zip

[http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=16861 Download zlib]

zlib-1.2.2-bin.zip
zlib-1.2.2-lib.zip

from http://gnuwin32.sourceforge.net, and install them. To install them, simply unzip them into

/C/xxx/msys/1.0/mingw.

== Install XML support ==

XML support not working yet, step omitted

== Install GNUstep base ==

go in gnustep-base, and type

./configure --disable-xml
make
make install

== Install addditional GUI libs ==

for the gui, download and install the following packages:

[http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=16348&release_id=218220 Download jpeg]

jpeg-6b-3-bin.zip
jpeg-6b-3-dep.zip
jpeg-6b-3-lib.zip

[http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=16351 Download tiff]

tiff-3.7.1-bin.zip
tiff-3.7.1-dep.zip
tiff-3.7.1-lib.zip

[http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=16183 Download libpng]

libpng-1.2.8-bin.zip
libpng-1.2.8-dep.zip
libpng-1.2.8-lib.zip

The process is always the same: download the zip file from the gnuwin32 website, then unzip them into

/C/xxx/msys/1.0/mingw.

== Install GNUstep gui ==

go in the gui, and type:

./configure
make
make install

== Install GNUstep back ==

go in back, and type:

./configure
make
make install

== Check the installation ==

go in a simple gui application (examples/gui a very good starting point), compile and run it. :-)

''based on a mail from Nicola Pero''

Installation on Windows

2005-03-10T15:00:28Z

Stefan Urbanek: Added links to packages for download

== Install MinGW ==
Download MinGW-3.2.0-rc-3 or later from http://sourceforge.net/projects/mingw Install it into

C:/xxx/msys/1.0/mingw

(where /xxx/ is the top-level path you want to use, I use Nicola/GNUstep so I install it into C:/Nicola/GNUstep/msys/1.0/mingw) (earlier versions of MinGW won't work)

== Install msys ==

Download MSYS-1.0.10 or later from the same site. Install it into C:/xxx/msys/1.0
The postinstall script should ask you for the mingw location, then detect it and be happy that it's there and all is setup properly.

== Install msys developer toolkit ==

Download msysDTK-1.0.1 or later from the same site. Install it into

C:/xxx/msys/1.0

Now your MSYS/MinGW system should be setup! Go around and make sure you know how to use the Unix-like shell. Log into it and work in it.

== Download gnustep using cvs ==

== Install GNUstep make ==

go in core/make and do

./configure --prefix=/C/xxx/GNUstep
make
make install

== Setup your GNUstep environment ==

(you will need to do the same every time you start up your MSYS shell to do development)

. /C/xxx/GNUstep/System/Library/Makefiles/GNUstep.sh

Also, set HOMEPATH, HOMEDRIVE and HOME ... add the following lines to your ~/.profile:

export HOMEDRIVE=C:
export HOMEPATH=/home/Nicola
export HOME=/C/xxx/msys/1.0/home/Nicola
. /C/xxx/GNUstep/System/Library/Makefiles/GNUstep.sh

(obviously replacing 'Nicola' with your Login name) (not sure if this setting of HOMEDRIVE etc is really required, will investigate)

== Install the ObjC runtime ==

Download gnustep-objc, and compile it

make
make install

== Reinstall GNUstep make (with ObjC this time ==

go in core/make and reconfigure/recompile again so that gnustep-objc is detected:

make distclean
./configure
make
make install

gnustep-make should have detected your custom libobjc.

== Install ffcall ==

Download ffcall from the GNUstep website, and type:

./configure --prefix=$GNUSTEP_SYSTEM_ROOT
make
make install

== Install additional libs ==

Download the following packages:

libintl-0.11.5-2.bin.zip
libintl-0.11.5-2.lib.zip

libiconv-1.8.1-bin.zip
libiconv-1.8.1-lib.zip

zlib-1.2.2-bin.zip
zlib-1.2.2-lib.zip

from http://gnuwin32.sourceforge.net, and install them. To install them, simply unzip them into

/C/xxx/msys/1.0/mingw.

== Install XML support ==

XML support not working yet, step omitted

== Install GNUstep base ==

go in gnustep-base, and type

./configure --disable-xml
make
make install

== Install addditional GUI libs ==

for the gui, download and install the following packages:

[http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=16348&release_id=218220 Download jpeg]

jpeg-6b-3-bin.zip
jpeg-6b-3-dep.zip
jpeg-6b-3-lib.zip

[http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=16351 Download tiff]

tiff-3.7.1-bin.zip
tiff-3.7.1-dep.zip
tiff-3.7.1-lib.zip

[http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=16183 Download libpng]

libpng-1.2.8-bin.zip
libpng-1.2.8-dep.zip
libpng-1.2.8-lib.zip

The process is always the same: download the zip file from the gnuwin32 website, then unzip them into

/C/xxx/msys/1.0/mingw.

== Install GNUstep gui ==

go in the gui, and type:

./configure
make
make install

== Install GNUstep back ==

go in back, and type:

./configure
make
make install

== Check the installation ==

go in a simple gui application (examples/gui a very good starting point), compile and run it. :-)

''based on a mail from Nicola Pero''

StepTalk TODO

2005-03-09T21:48:55Z

Stefan Urbanek:

If you would like to help [[StepTalk]], just contact me and I will guide you. Requirements: courage only :-)

Contact: [[User:Stefan Urbanek|Stefan Urbanek]]

== 1.0 release ==

* implement NSRect object - see STStruct object
* implement distant conversations
* create stenvironment tool

=== STEnvironment tool ===

First, changes to the STConversation is needed as follows:
* method executing code should not return a value
* script result object should be fetched by method: -(id)result or -(bycopy id)resultByCopy;
* conversation object should collect error messages - it should hold kind of transcript
* it would be great if conversation object can send notifications when transcript was updated
* conversation object should hold last exception raised by the script

Then stand-alone process should be created with following functionality:
* point of the stand alone process is that it can load any framework it likes and it should provide semi-persistent environment holding intermediate results of a inter-process and inter-application tasks
* one creates an STDistantEnvironment object - the object is in fact represented by single process that will be launched on -init
* the environment process will handle all execution requests - connections are created in form of conversations: user makes conversation with the environment
* environment is "live" until someone requests it to die

To make it more clear about the STEnvironment stand-alone process, here is an analogy:
* stenvironment process = database instance
* conversation = database connection
* StepTalk script = SQL script
* result = SQL script result (rows, message, ...)

one should be able to do following:

stenv create experiment
stenv execute experiment script.st
stenv execute experiment script2.st

...
env = [STEnvironment distantEnvironmentWithName:@"experiment"];
conversation = [STConversation conversationWithEnvironment:env language:nil];
[conversation executeScript:aScript];
result = [conversation resultByCopy]; /* or .... [conversation result] */
...

== Smalltalk ==

* Rewrite Smalltalk compiler (grammar)
** Remove STBytecodeInterpreter and use only STCompiler. How?
Simply convert language constructions into 'command' objects like
SmalltalkStatement, SmalltalkPrimary, SmalltalkMethodSend, ...
and implement executeInEnvironment:context:receiver:

* Update application scripting to use STConversation

== Other ==

* handle 'connection did die' notification for distant objects in STEnvironment
* fix class-info lookup for proxies in STEnvironment
* Smalltalk: separate compiler and compilation context
* create a 'Shell' scripting environment
* Create ApplicationScripting framework, instead of bundle. It should offer
passive application scripting (without linking) and active app. scripting
(linking with the framewotk). Give it some reasonable name, becauase that one
is already used by Apple
* Add framework list into environment description
* Change Modules to Frameworks
* Fill implementation of STScriptObject, STMethod and related STEngine methods
* Remove empty directories (Source, Modules/StepTalk)
* Replace STMethod languageName with map table of method class->engine class

* integrate with Gorm - use Script objects, make a palette for Gorm with script objects

StepTalk TODO

2005-03-09T21:47:44Z

Stefan Urbanek:

If you would like to help StepTalk, just contact me and I will guide you. Requirements: courage only :-)

Contact: [[User:Stefan Urbanek|Stefan Urbanek]]

== 1.0 release ==

* implement NSRect object - see STStruct object
* implement distant conversations
* create stenvironment tool

=== STEnvironment tool ===

First, changes to the STConversation is needed as follows:
* method executing code should not return a value
* script result object should be fetched by method: -(id)result or -(bycopy id)resultByCopy;
* conversation object should collect error messages - it should hold kind of transcript
* it would be great if conversation object can send notifications when transcript was updated
* conversation object should hold last exception raised by the script

Then stand-alone process should be created with following functionality:
* point of the stand alone process is that it can load any framework it likes and it should provide semi-persistent environment holding intermediate results of a inter-process and inter-application tasks
* one creates an STDistantEnvironment object - the object is in fact represented by single process that will be launched on -init
* the environment process will handle all execution requests - connections are created in form of conversations: user makes conversation with the environment
* environment is "live" until someone requests it to die

To make it more clear about the STEnvironment stand-alone process, here is an analogy:
* stenvironment process = database instance
* conversation = database connection
* StepTalk script = SQL script
* result = SQL script result (rows, message, ...)

one should be able to do following:

stenv create experiment
stenv execute experiment script.st
stenv execute experiment script2.st

...
env = [STEnvironment distantEnvironmentWithName:@"experiment"];
conversation = [STConversation conversationWithEnvironment:env language:nil];
[conversation executeScript:aScript];
result = [conversation resultByCopy]; /* or .... [conversation result] */
...

== Smalltalk ==

* Rewrite Smalltalk compiler (grammar)
** Remove STBytecodeInterpreter and use only STCompiler. How?
Simply convert language constructions into 'command' objects like
SmalltalkStatement, SmalltalkPrimary, SmalltalkMethodSend, ...
and implement executeInEnvironment:context:receiver:

* Update application scripting to use STConversation

== Other ==

* handle 'connection did die' notification for distant objects in STEnvironment
* fix class-info lookup for proxies in STEnvironment
* Smalltalk: separate compiler and compilation context
* create a 'Shell' scripting environment
* Create ApplicationScripting framework, instead of bundle. It should offer
passive application scripting (without linking) and active app. scripting
(linking with the framewotk). Give it some reasonable name, becauase that one
is already used by Apple
* Add framework list into environment description
* Change Modules to Frameworks
* Fill implementation of STScriptObject, STMethod and related STEngine methods
* Remove empty directories (Source, Modules/StepTalk)
* Replace STMethod languageName with map table of method class->engine class

* integrate with Gorm - use Script objects, make a palette for Gorm with script objects

StepTalk TODO

2005-03-09T21:42:18Z

Stefan Urbanek: