GNUstepWiki - Recent changes [en]

User FAQ

Bheron — Fri, 03 May 2013 01:30:23 GMT

/* Does GNUstep run on Windows? */

DBusKit

Thebeing — Wed, 01 May 2013 09:38:37 GMT

Zipper.app

Buzzdee — Sun, 21 Apr 2013 14:35:10 GMT

Template:GNUstep News

Buzzdee — Sun, 21 Apr 2013 14:31:39 GMT

NSAlert

Awiebe — Mon, 15 Apr 2013 08:13:22 GMT

New page

{{stub}}
NSAlert is a modal dialog or [[sheet]].

<syntaxhighlight lang="c_max">

<code>

/**
NS Alert Example*/

NSAlert* a = [ NSAlert alertWithMessageText:@"title" defaultButton:@"ok" alternateButton:@"cancel" otherButton:nil informativeTextWithFormat:@"more information ];

//Run as a dialog
NSInteger returnCode = [a runModal];
switch(returnCode)
{
case 1:

//ok
break;

case 2:

//cancel
break;
}

//Attach to window
[a beginSheetModalForWindow:windowP modalDelegate:self didEndSelector:@selector(alertDidEnd:) contextInfo:nil];

- (void) alertDidEnd:(NSAlert *)alert returnCode:(NSInteger)returnCode contextInfo:(void *)contextInfo
{
switch(returnCode)
{
case 1:
//ok
break;
case 2:
//cancel
break;
}
}
</p>

</syntaxhighlight>
==See also==
* [https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSAlert_Class/Reference/Reference.html Apple on NSAlert]

User FAQ

Awiebe — Mon, 15 Apr 2013 07:56:41 GMT

/* Why not use framework bundles? */ changed dynamic link to symbolic link

 and the non-gui libraries are reported to work well.
-The GUI library uses the win32 backend library to work under Windows. The backend library is a thin layer that converts the GNUstep methods to handle drawing of GUI elements to calls to the Windows API. This project is currently in beta.
+The GUI library uses the cairo backend library to work under Windows. The backend library is a thin layer that converts the GNUstep methods to handle drawing of GUI elements to calls to the Windows API.
+GNUstep also has a theme which lets it use native windows widgets wherever possible so it can better blend into the Windows environment.
 === What is GNUstep's position towards KDE and the GNOME project? ===

 {{Framework|
 shortdescription = DBusKit is a framework that interfaces Objective-C applications with the D-Bus IPC service. |
-currentversion = 0.1 |
+currentversion = 0.1.1 |
-releasedate = April 15 2011 |
+releasedate = April 16 2013 |
 license = LGPL |
 overview = The DBusKit framework offers tight integration of D-Bus services into
 * 'dk_make_interface' tool to generate Objective-C protocol declarations from D-Bus interface files. |
 maintainer = * Niels Grewe |
-relatedlinks = * [http://download.gna.org/gnustep/dbuskit-0.1.tar.bz2 Current release tarball]
+relatedlinks = * [http://download.gna.org/gnustep/dbuskit-0.1.1.tar.gz Current release tarball]
 *  [http://svn.gna.org/svn/gnustep/libs/dbuskit/trunk SVN trunk]|
 category =
 }}

 shortdescription = Tool for inspecting the contents of a compressed archive. |
-currentversion = [http://savannah.nongnu.org/download/gap/Zipper-1.4.tar.gz 1.4] |
+currentversion = [http://savannah.nongnu.org/download/gap/Zipper-1.5.tar.gz 1.5] |
-releasedate = May 10, 2012 |
+releasedate = April 21, 2013 |
 license = GPL v2 or later |
 overview = Zipper consists only of a single window, displaying the contents of the selected archive. Currently, you can view and extract .tar, .tar.gz, .tar.bz2, .rar, .lha, .lhz and .zip archives.
-Sinve Version 1.4, Zipper moved to GAP in accordance to the original Author and changed its license to GPL v2+
+Since Version 1.4, Zipper moved to GAP in accordance to the original Author and changed its license to GPL v2+
 |
 * Multi-document
-* ZIP, TAR (and BSD tar), LHA, 7Zip
+* ZIP, TAR (and BSD tar), LHA, 7Zip, ACE, ARJ, ZOO
-* TAR creation
+* TAR, LHA, 7Zip, ZIP and ZOO creation
 * GWorkspace integration|
-maintainer = [mailto:mailto:dirk@xanthippe.ping.de Dirk Olmes] |
+maintainer = GNUstep Application Project team |
 relatedlinks =

+=== Apr 21 2013 ===
+* '''[[Zipper.app]] 1.5'''
+: ([http://gap.nongnu.org/zipper Zipper Homepage])
 === Apr 02 2013 ===
 * '''GNUstep [[Gui]]  0.23.1 stable release'''

 Framework bundles are much more difficult to port and to use, and are very unnatural on a UNIX system; extremely unnatural on Windows. In a framework bundle, the shared dynamic library is inside a framework wrapper directory. Because of this, the dynamic linker can't find it.
-We have frameworks, so how do we work around that? Well, we build dynamic links from a directory inside the dynamic linker path into the framework, which work, but then you can't move the framework anywhere else on the system, otherwise you break the link, and nothing will find the framework any longer! On systems without dynamic links, like Windows, we can't even do this! We have to copy the library from the framework into the dynamic linker path, but that is simply a shared library then! Absolutely no difference. You put the dynamic library in a system directory in the dynamic linker path, and associate with that library a resource directory. OpenStep for Windows did that, and still called them frameworks. So we can do the same, and call our libraries frameworks.
+We have frameworks, so how do we work around that? Well, we create symbolic links from a directory inside the dynamic linker path into the framework, which work, but then you can't move the framework anywhere else on the system, otherwise you break the link, such that nothing will find the framework any longer! On systems without symbolic links, like Windows, we can't even do this! We have to copy the library from the framework into the dynamic linker path, but that is simply a shared library then! Absolutely no difference. You put the dynamic library in a system directory in the dynamic linker path, and associate with that library a resource directory. OpenStep for Windows did that, and still called them frameworks. So we can do the same, and call our libraries frameworks.
 Shared libraries are all in a flat directory where the dynamic linker can easily find them. This is how it works on Unixoids, Windows and probably most other systems. The OpenStep API requires us to provide some stuff for frameworks, like creating and registering a framework object automatically each time a framework is used (linked at runtime, or linked into the app), and attaching to it the list of classes inside the framework, which are not particularly trivial to implement and might make trouble when porting, as they depend on playing with the linker and the object file format. However, shared libraries are handled by the operating system for us, so we never have to use these facilities.