The developers behind Etoile have discussed their future plans for the project recently, and have provided a summary of the discussion on the mailing list. The Etoile live CD project will be transferred from Nicolas (due to a lack of time) to Quentin; he says: “I will recreate an environment for building the LiveCD from scratch (will now be built on Ubuntu Feisty Fawn LiveCD). To help in this process, Nicolas sent me the current LiveCD scripts. I hope to succeed in two or three weeks.” On Etoile itself: “Focus will be put on core elements like System, MenuServer, Azalea, AZDock etc. rather than polished applications for this release. We don’t have enough manpower for now and it’s better to have a stable foundation to begin with.” The next release is now planned for the coming three weeks.
Etoile: New Release, Live CD on the Way
About The Author
Follow me on Twitter @thomholwerda
2007-05-01 1:22 amJohann Chua
GNUStep’s the better choice.
2007-05-01 6:34 pmDoc Pain
“GNUStep’s the better choice.”
I think that’s correct. GNUstep offers good API and framework while looking professional (or everything else you want it to look like). Applications can be developed for both UNIX / Linux and Mac OS X systems with relative few work which is an interesting point if you want to design multiplatform applications (which you cannot do with “Windows” in an acceptable manner).
While I tended to start a new software project (ranging in the sector of medical software, testing and diagnostics) using Gtk and C, I now feel GNUstep and ObjC would be the better choice. ObjC is not that bad and GNUstep even has useful RAD like tools. Personally, I would not think about using something like Wine or Cedega, but that may be different because I do not have to re-use “Windows” stuff. Furthermore, if software does not need to run on “Windows” platforms, why consider it?
2007-05-01 8:53 amjimcrofty
Haven’t used Wine in a while but I used Cedega a couple of years back and it was very good (at least for playing Civ + C&C).
While I love my Mac and would be interested to see OSX apps ported, porting Win32 versions is probably a better bet. Porting an OSX app will require a *lot* more work. OSX != GNUStep. They would likely have to port a myriad of OSX libs including CoreAudio, Quartz/CoreImage, CoreData (possibly). That’s not counting that fact in the last what, ~6 years the core Cocoa API has moved on beyond the original NextStep/OpenStep spec GNUStep are currently working towards.
Seems sensible to hit the ground running and port to WineLib than re-implement OSX APIs.
2007-05-01 11:15 amremenic
Yeah, porting the win32 API is a lot less work. I mean, it’s only been in development for 14 years now, and look how far it already is! It’s also used so widespread, and the apps feel SO native!
My money is on GNUStep
2007-05-02 1:45 pmTheRaven
In theory, GNUstep is a better choice. GNUstep makes it very easy to move Cocoa code to *NIX, and the emphasis on the separation of model and view code in OpenStep (the specification of which Cocoa and GNUstep are implementations) makes it pretty easy to maintain separate UIs for OS X and *NIX.
There are two main problems. First, a lot of applications mix Cocoa and Carbon code. Carbon and Cocoa objects are typically equivalent, and foo(X) in Carbon often has an analogue in Cocoa as [X foo]. Things like this are easy to get around with some #defines in GNUstep. Most developers don’t use these, however, they use the bits of Carbon that aren’t in Cocoa. These generally don’t exist in GNUstep, and need to be replaced by other code.
The other problem is that GNUstep only implements Foundation (GNUstep base) and AppKit (GNUstep gui). Some extra frameworks are available; we have a compatible implementation of the AddressBook framework in Étoilé subversion, for example. Things like CoreImage or CoreAudio, however, are very OS X only (for now…) and projects like Cubase are likely to have heavy dependencies on things like QuickTime, which is far beyond the scope of GNUstep.
If you have an existing codebase that runs on OS X and Windows, the odds are that you are using Carbon a lot more than Cocoa, so WineLib would probably be a better choice. If you are starting now, I’d suggest you develop with GNUstep (porting from GNUstep to OS X is easier than the other way around). There is a bundle available (somewhere) that attaches the menu to the active window for people using broken UI paradigms, and if you include that with your Windows version it should look similar to a Windows app. If you haven’t tried it yet, have a play with the OpenStep API (Cocoa or GNUstep), because it really is a joy to use in a way no other API I have used is. Frameworks like Qt try to implement something like an Objective-C runtime on top of C++, while OpenStep just uses a flexible, late-bound, dynamic language directly.
Of course, I’m biased, since I never could stand the Win32 API…
David (Étoilé developer)
2007-05-02 5:30 pmnicholas
Thanks for the info, it’s very interesting.
GNUStep is always something that has been “Looks nice, will have a play one day” but “one day” never seems to arrive. 🙂
(Lack of) Time is usually the key factor in this unfortunately. 🙁
ps You are not alone in hating the Win32 API. 😉
I think we have more chances to see the “next generation UI” coming from a project such as Etoilé than, say, Gnome 3.0
It is interesting to see the guys brainstorming over the desktop environment and its interactions with the user without actually having to worry about tons of written code.
Let’s see what comes out of it all.
2007-05-01 10:11 amjessta
it is interesting to see the guys brainstorming over the desktop environment and its interactions with the user without actually having to worry about tons of written code.
Yeah, I do that all the time. Although I never actually write the code.
Why was the PC-BSD article deleted? Because some misplaced people asked for it on the comment section?
So in *theory* GNUStep can be used as a starting point for commercial developers (Say Propellerheads or Steinberg) to port OSX apps (Say Reason or Cubase) to Linux?
Or would they be better off using WineLib and porting their Win32 versions?