Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

First GNUstep Renaissance Public Release.

Hemos posted more than 11 years ago | from the who's-da-vinci dept.

GNUStep 13

Christopher "CJayC" Jenkins writes "Nicola Pero recently announced on the discuss-gnustep mailing list the public release of his GNUstep Renaissance software, which allows for user interfaces utilizing the GNUstep and Apple Cocoa APIs to be specified in XML. While still alpha-quality code, it can be used at the present to replace .nib (and .gorm and .gmodel) files with .gsmarkup files, which can be easily edited by hand. "

The source code can be checked out of the GNUstep CVS repo:
cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/gn ustep login
cvs -z3 -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/gn ustep co dev-libs/Renaissance

Sorry! There are no comments related to the filter you selected.

great.... (0)

Anonymous Coward | more than 11 years ago | (#4961809)

With an Gorm/IB like tool it will be best way to develop GUI on GNUstep/*nix GNUstep/Windows and MacOSX.

I hope MacOSX developpers will use it.

Re:great.... (4, Insightful)

cbv (221379) | more than 11 years ago | (#4961987)

With an Gorm/IB like tool it will be best way to develop GUI on GNUstep/*nix GNUstep/Windows and MacOSX.

It seems to be the way to go if you (in general) want to develop applications that run basically wherever GNUstep runs on, without having to worry about the layout of your GUI, however...

I hope MacOSX developpers will use it.

... why the fsck would they care? They have Interface- and ProjectBuilder that undeniably are much more mature compared to Gorm and ProjectCenter (and now Renaissance). And I don't think most really _are_ interested in porting their software to Windows or any of the various UNICES, GNUstep runs on. A few, maybe, but most certainly not.

But Renaissance most certainly will help GNUstep to "get the word out" - and it might even help to get GNUstep a little (compared to GNOME and KDE) of much deserved (again, compared to GNOME and KDE) "hype" - as applications do not require a running X server, like ported GTK/Qt applications do.

Re:great.... (2, Informative)

Anonymous Coward | more than 11 years ago | (#4962191)

first off, Real OpenStep (from NeXT) is/was available for Windows. While the core gnustep libraries are mature, useable, and reportedly faster than Cocoa, the GUI part is not.


Additionally, GTK, QT, and GNUstep are all varying degrees of X-independent... QT has QT embedded as well as QT for Windows and MacOS. GTK is available for Windows (though, why?), but GNUstep has a raw xlib backend, a postscript backend (eg ghostscript + XWindows), or a Windows backend.

Re:great.... (1)

cbv (221379) | more than 11 years ago | (#4962289)

Additionally, GTK, QT, and GNUstep are all varying degrees of X-independent... QT has QT embedded as well as QT for Windows and MacOS. GTK is available for Windows (though, why?), but GNUstep has a raw xlib backend, a postscript backend (eg ghostscript + XWindows), or a Windows backend.

True, but - you still need to install GTK and Qt on your MacOSX, while GNUstep applications can (or say: should - as long as you don't use GNUstep extesions) run "out of the box" - as most prominently demonstrated by GNUMail.

Windows, as usual, is a different story entirely....

As a Mac OSX developer ... (2)

torpor (458) | more than 11 years ago | (#4966803)

... I can say that I'd use it, if it meant I could take my OSX apps and - relatively easily - move them to Linux-land...

Of course, audio API's are a different story.

WTF? (0)

Anonymous Coward | more than 11 years ago | (#4961852)

Story was posted at 8:30 (am). But, comments couldn't posted until 12:04 (pm). Huh?

rapid response (2)

bill_mcgonigle (4333) | more than 11 years ago | (#4961970)

I mailed hemos about it, and he turned on comments within minutes, with a polite thank you note to me. I assume noone else bothered since he was so fast to respond. I guess some people would rather be annoyed and bitchy. Let's cut him some Holiday Slack.

The full announcement.... (2, Informative)

cbv (221379) | more than 11 years ago | (#4961890)

... is here [gnustep.us] and here [google.com] .

Re:The full announcement.... (0)

Anonymous Coward | more than 11 years ago | (#5012300)

There is also a web page
here [gnustep.it]
and a short tutorial here [gnustep.it]

Any chance of a standard? (4, Insightful)

bill_mcgonigle (4333) | more than 11 years ago | (#4961921)

Off the top of my head, we have:
  • Glade XML [gnome.org] for GTK+ apps
  • XUL [xulplanet.com] from the Mozilla [mozilla.org] project
  • and now Renaissance from the GNUStep/Cocoa folks

plus dozens of non-portable, programmatic interfaces (Tk, Swing, Motif, Mac Toolbox, etc.) Is anybody looking at whether a portable superset XML spec is feasible? XSLT transforms ought to be able to derive a platform-specifc file. Imagine:

./configure --with-interface=cocoa

User Interfaces are the final frontier of program portability.

Re:Any chance of a standard? (1)

cbv (221379) | more than 11 years ago | (#4962195)

XSLT transforms ought to be able to derive a platform-specifc file. Imagine: ./configure --with-interface=cocoa

Not every software needs to be ./configure'd ;-)

User Interfaces are the final frontier of program portability.

Take a look at THE [sourceforge.net] .

Re:Any chance of a standard? (0)

Anonymous Coward | more than 11 years ago | (#4962245)

> Off the top of my head, we have:
>* Glade XML [gnome.org] for GTK+ apps

Please don't compare toys and real app

Re:Any chance of a standard? (0)

Anonymous Coward | more than 11 years ago | (#4979688)

The problem with this approach is that Glade/XUL and nib files solve different problems. A glade file will contain a description of the interface, while a nib file will contain a description of the interface, a listing of classes, instances of those classes, and interconnections between the classes and the interface that specify the flow of data.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?