Etoile: a GNUStep-based Linux GUI written in Objective-C | Hacker News Reader

Etoile: a GNUStep-based Linux GUI written in Objective-C

etoileos.com

101 pointsadamnemecek43 comments

I'm involved with Étoilé, and am the lead developer on a framework called CoreObject (https://github.com/etoile/CoreObject) - it's an object persistence framework something like CoreData except it's also a DVCS.

We're going to properly launch a website for it and do an alpha release in a few weeks, but thought I would mention it since this is where most of the development on Étoilé is happening right now.

I came across Etoile a few weeks back, posted it in a comment here. Glad to see others have run across it!

For those that think it's a dead project, it's not, check the mailing list. The devs are looking to move to GitHub, so hopefully we'll see more contributors. I'm going to get involved myself, I downloaded the source last night into a VM to have a fiddle :)

How viable nowadays is cross-platform application or server software development in Objective-C compared to the same in C++? GNUstep appears to be the best (only) solution for the former; is that so?

Edit: To clarify, I'm asking this as a developer who does most work on Linux. My interest in Obj-C is primarily due to its Smalltalk-like message passing mechanism. Edit 2: clarity.

There's Apportable for Android (http://www.apportable.com), which—I'm guessing—likely uses Cocotron under the hood: http://www.cocotron.org

But, in general, not very. Objective-C compilers certainly exist for Windows and Linux, but aren't worth much without Apple's frameworks.

Apportable does use Cocotron, but they also stitch in various other open source libraries that are found in the iOS runtime (libdispatch, CommonCrypto, etc):

http://www.apportable.com/open_source

interesting, thanks for the link!

Speak for yourself. I do game dev in objc, with my own framework, and find it infinitely more useful than c++ even without the apple toolkits.

Interesting. Could you expand a bit on the main advantages of Obj-C over C++ in your use case?

It's just easier to work with when you have to do things like iterate over dozens of game objects, each of which may or may not have certain properties or methods. Delegation is also a lot easier. So is FFI in some cases; the runtime exposes C functions for querying and even creating and updating classes. In fact, inside the (relatively tiny) ObjC runtime is a complete, COM-like object model that's less of a pain in the butt to use than COM, which is why ObjC was so central to NeXT's software-componentry plans in the good old days (WebObjects, etc.).

Obviously you don't want to have any method calls on code paths that need to be super fast, but I'm not afraid of using straight C for those. It's a 2D engine; and from the profiling I've done, drawing and updating the screen still dominates the CPU time used, and it works fast enough even on many, many years old hardware, so I'm not worried about performance.

I played with GNUStep some time ago and well ...

Simple core foundation applications for the command line are no problem but as soon as you get into GUI land with cocoa the differences start to grow.

IMHO trying out GNUStep is a nice project for a weekend but forget any serious cross platform development ideas.

I played with it last weekend. Not viable. Even the ubuntu packages don't produce a working dev environment. GNUstep is a major, standing lost opportunity for the free-software world. Imagine if the community had just taken openstep and don't a respectable job of this proven platform, instead of life in the wilderness with gnome/kde/unity/etc. Etoile is cool - I'd recommend they focus on making it easy to get a command-line GNUstep dev environment up, and bypass the fiddly IDE tools altogether.

Just a note, I would not use "Ubuntu doesn't even have" as an argument that something is not viable, since Ubuntu has its roots in Debian and there is a tendency to have old crap in the stable release.

For less popular stuff, even the most current release (trusty) is not likely to be kept up-to-date unless one of the core developers is an Ubuntu user. It's not as bad as Debian (used to be?) and I can't come up with an example off the top of my head of something that I needed that was too old and still is, but the most recent memory was Vim, trying to install YouCompleteMe, they had already come out with Vim 7.4 and the most current release of Ubuntu only had 7.3, with about 600 patches behind current and ~75 patches too few to be supported.

(It works now. This is not a bug report. You should file one if this GNUstep interests you, unless it's really an upstream problem.)

Agree re ubuntu not being the last word on things. OP wants a cross-platform dev environment though. If a platform that is primarily for free unix is obviously broken on a major linux distro, it's a bad omen for its multiplatform prospects.

Yeah, or it's a bug that needs to be filed with the relevant authority.

There are honestly a lot of major linux distros now.

If your cross-platform environment's users are all Gentoo, Fedora, NixOS, Exherbo, Arch Linux, your own homebrew distro, and some OSes with another kernel(s), you may have really achieved cross-platform support without finding Ubuntu support.

My favorite cross-platform project supports Ubuntu, but is lacking Fedora support. It was a major stumbling block for me (just one day), but the dependencies are nothing special, you can compile libuv and libgmp, ncurses, openssl, and libsigsegv pretty much anywhere that I care about (Mac, Linux, BSD).

The only time it mattered for me is when I've got half an hour to give a presentation and the audience is supposed to compile and install the stuff I'm using, but unexpectedly found to be using Fedora and I don't know what packages to tell them to get.

When I switched from AmigaOS to Linux in 1995, I expected GNUstep to be ready within a short time after it.

Those were the days …

Apple has a patent on the Dock. https://www.google.com/patents/US7434177

And clickable pull-down menus in the menu bar. https://www.google.com/patents/USD629412

The legal system strikes again.

Wow, I was surprised to see that Apple has patents on those, especially the one on pull-down menus. Wasn't pull-down menus there in some old Xerox computer?

Pull-downs are entirely Apple's:

http://folklore.org/StoryView.py?story=On_Xerox,_Apple_and_P...

and

http://www.folklore.org/StoryView.py?story=Busy_Being_Born.t...

That's interesting, IIRC pull-downs were used in GEM and Amiga Workbench too...

They both did, but came after Apples implement implementation in Lisa.

The Apple Lisa was released in January 1983, GEM was first demoed in November 1984 (http://en.wikipedia.org/wiki/Graphical_Environment_Manager, http://en.wikipedia.org/wiki/COMDEX), and Amiga Workbench was released in july 1985 (http://en.wikipedia.org/wiki/Workbench_(AmigaOS), http://en.wikipedia.org/wiki/Amiga_1000)

I don't think anybody ever claimed parallel inventions here.

Ubuntu has a dock-like-launcher and pull-downs in the menu bar. Interesting.

The menu patent is for translucent menus "large, lower rectangle that conveys the impression of a translucent/transparent surface"

I am not a patent lawyer, but the second patent appears to be for an interface where windows can situationally be rendered translucent, not for the general idea of pull-down menus.

So that affects how the project is hosted, big whoop. Another "amazing" property of platforms without a gatekeeper!

(PS- pretending the lawlers' games are important just serves to propagate their influence)

The Dock patent is specifically on the dynamic resizing and repositioning of icons when moused over. A plain collection of icons won't infringe this patent.

The second patent is a design patent, which means you'd have to have a menu exactly like that to infringe.

Funnily enough, one of the icons in the figures in the first patent is for Internet Explorer. I think I also spied one for Word.

It's from 1999; at that time, Apple shipped IE.

Yep, just seems funny today.

I actually never understood the usability behind growing/shrinking the Dock icons. Good icons have enough of a profile to be distinguishable when they're small.

Oh shit. Ubuntu better change their menus...

...that they've been using from 2005. Oh, they also really have to change their dock!...

...that they've been using from 2011.

The menu patent is a design patent, so you'd have to have a translucent menubar and menus to infringe. The Dock patent is, I believe, strictly for magnification and behavior, so icons arranged in a row do not infringe.

I messed around with GNUstep on Ubuntu around 2011-ish when I tried to port an OS X service to Linux. (I did not touch Etoile, though, as I didn't need a GUI.) I didn't come away with a good impression at all.

It was not very easy to get up and running, the documentation was lacking, requiring digging through many mailing lists, and it didn't support Objective-C 2.0... which was a big pain since the code was in Objective-C 2.0. Some of the libraries didn't even compile, for which I submitted a patch or two that never got accepted. When I finally got the app to compile, it was rather slow, so I abandoned further work.

Looking at the wiki, it apparently still does not properly support Objective C 2.0, and does not even mention plans for things like ARC. I don't think it'll see any adoption until they bring it closer to modern Objective-C style development.

The GNUstep Objective-C runtime actually supported ARC before Apple even shipped their implementation: http://etoileos.com/news/archive/2011/07/03/1215/

Hmm, they really should update their wiki, I cannot find a mention of ARC on http://wiki.gnustep.org.

It says 'PDA' in the first paragraph. That makes it looks old

But the last code edit was 11 hours ago. Web page is not so important to me.

http://svn.gna.org/viewcvs/etoile/

Argh! Svn!

I remember trying to install and run this 2 years ago. I checked up on it from time to time, but since it seemed dead I stopped following it(although there seems to be code edit that was an hour ago[1]).

[1] http://svn.gna.org/viewcvs/etoile/

yeah it's old. personally i'm wondering how complicated it would be to have a transparent wineish layer for running mac binaries on linux. the kernel modules are i guess the biggest problem, but last i remember they were fairly heavily based on their freebsd counterparts(well, at least many years ago)

i wish vmware workstation in linux was as good as the mac and windows counterparts ... then i could just run linux as my main os on my mba again

The biggest problem would be the binary loader. OS X uses the Mach-O executable format, as opposed to the ELF format used in other unixes. There is a project to get Mach-O binaries to be usable under other unixes,, but it looks to be a ways off still -- http://darling.dolezel.info/en/Darling

I really don't think that a binary loader would be that big of an issue. Unless I'm missing something, I would say that it would be one of the easier things. I'd guess that implementing all the frameworks would be the worst part.

There isn't a whole lot of magic in loaders. They do much the same job as linkers, except instead of files on disk, they set up pages in memory. All the import slots are filled with references to all the corresponding exports, until all imports are satisfied; and all the relocations are adjusted based on load location. There are a couple more wrinkles for optimization and extra functionality, but that's approximately it.

Doesn't appear to be Linux only at all.

Reply on news.ycombinator.com