Etoile Project Releases Mac-Like Environment 311
pschmied writes "Today the Étoilé Project released v0.2 of its Desktop Environment. Not only does Étoilé share user interface similarities with Mac OS X, Étoilé enjoys some source-level compatibility with Mac OS X as well. Many here undoubtedly remember NeXT, the revolutionary computer / development environment that gave rise to the first Web browser and later became the foundation of Mac OS X. Étoilé uses the FSF's own implementation of the NeXT development environment, GNUstep, making this a close technological relative of OS X. Screenshots and a source tarball are available."
Re:First web browser (Score:3, Informative)
Re:First web browser (Score:5, Informative)
NEXTSTEP = OS X (Score:2, Informative)
Re:Trying to get this up and running (Score:5, Informative)
Here's a rough step-by-step:
1. Install the dependencies listed here: http://gnustep.blogspot.com/2006/10/gnustep-on-ub
2. Use the GNUStep "Startup" package (you need a newer version of GNUStep than what is bundled with Ubuntu): http://www.gnustep.org/experience/Startup.html [gnustep.org]
3. Compile Etoile per the instructions in the tarball.
It's a bit different procedure than your average configure, make, make install. My hope is that someone will start packaging current versions for Ubuntu. Maybe I'll get off my duff and start doing that.
Cheers,
Peter
Re:Menus at the top! (Score:2, Informative)
You can't click above a Mac menu. Being against the edge of the screen makes it an infinite target, making it easier to hit. Just zip your mouse straight up to the top of the screen, and click.
It's another example of programmers copying the way things look rather than the way they work.
Re:Menus at the top! (Score:2, Informative)
Re:Menus at the top! (Score:4, Informative)
Re:Mac OSX? (Score:4, Informative)
If it can be done and they also find ways to integrate the now ubiquitous web applications' data, database, and other languages in that environment we could end up, for example, having a set of remote EJBs and Rails's active record objects, a couple local database rows and some emails being processed by a filter written in c that once belonged to openoffice calc, ending up in a nice graph.
Anyway, Gnome's bonobo, netbeans and probably lots of other projects wanted to achieve something like this as a primary or secondary goal, maybe people don't want such a paradigm shift.
Re:Menus at the top! (Score:5, Informative)
(a) The dock (which sort of doubles as a taskbar) is hideable. No screen real-estate need be sacrificed.
(b) The mouse-movement that the menu costs you is a lot easier than the mouse movement for menus attached to windows - that's the point of putting the menus at the top of the screen.
(c) If I'm using multiple applications on the same screen (and I'm not using a virtual-desktop, which to be fair I usually do), then I use Exposé to switch between them. It's bound to my 5th mouse button so it works anywhere and it's very quick.
(d) There are other ways the Mac tries to speed workflow, but to be fair, other systems have extras too, so I'll stick to what you identified...
You don't have to like the Mac way of doing things, but you ought to try it with a fair mind before criticising it...
Simon.
Re:Menus at the top! (Score:2, Informative)
Also as for the second monitor that wont play the games. You can simply disable the internal monitor of the laptop. Either via the hardware 'Fn' on a old IBM thinkpad or in the settings screen.
Urgh! (Score:3, Informative)
(Note to developers: you should actually use and think about the UI you're trying to emulate. Even broad concepts, like level of menu depth and placement of functions/actions appropriate to their complexity, can make all the difference in the world. Not that Apple themselves aren't adverse to ignoring their own guidelines on these matters when it suits them...)
It's like OpenStep (Score:3, Informative)
I think what GNUStep needs is a lot more artists to draw some pretty icons and some people who are concerned with the front-end appearance rather than back-end compatibility and framework APIs.
You mention "it's a typical, ugly Linux text experience to boot."
Re:Way to confuse NEXT with Mach and BSD (Score:5, Informative)
Mac OS X's Cocoa API is based on the OpenStep API, so Étoilé and GNUstep are related to Mac OS X through the OpenStep API. If you really love the Cocoa API and you want to make an app for Linux, you should take a look at GNUstep.
Re:Way to confuse NEXT with Mach and BSD (Score:2, Informative)
Here are some facts which might spur you to actually find something out about NeXT so you don't make a fool of yourself the next time you try to say something about this...
Etoile is based on GNUstep, which is based on the Openstep Specification published by NeXT.
Mac OS X is based on Rhapsody which was based on Openstep which was based on Nextstep which is the basis of the Openstep Specification.
Mach and BSD4.3 were a basis for Nextstep, but by no means were they necessary. The Openstep environment has run on top of Solaris, HP-UX and even Windows.
The intention of NeXT was, for a large part of their existence to make the underlying hardware and OS irrelevant, something that you have seen playing into Apple's favour of late with the Intel transition and iPhone OS.
You insult both NeXT's work and Gnustep by insinuating that they need Mach or BSD to be "NEXT".
Re:Menus at the top! (Score:4, Informative)
If you're seriously having to use more than one movement of the mouse to get from say, the top-left of your monitor to the bottom-right of your monitor and don't know how to fix it then you should have your geek card revoked.
Hitting a unified menubar or taskbar is exactly the same process, "slam" the mouse to the bottom of the screen and you're there no "voyaging" involved. There's a lot of well established ergonomic research to suggest that screen edges are good places for commonly used objects because they are effectively infinitely large in a certain direction, and that research has been heeded by ALL major OS vendors in one way or another.
Interestingly, research suggests that the time to acquire objects like menu bars is purely a function of their size and their distance from where your hands (or pointer on a computer) spend most of their time. Once you are "up to speed" with an interface, those are the only factors that matter in acquiring a target, the training of the user is irrelevant.
That suggests that both attached and detached menu bars are a good idea, attached menu bars by virtue of being close at hand to the content that you're manipulating, and detached menu bars by virtue of being effectively enormous in size. I'm certain, as would be anyone with common-sense that all users can acquire a menu bar at the top of the screen more quickly than one in the middle of the screen.
However, as you state above unless the user is quitting the application they probably have to return to the application window, this is still a much larger target than a menu bar, but leaves you much further from the content than the attached menu bar would.
I don't think there actually is a consensus on which type of menu bar is best, but there is a lot of agreement that no-one should have trouble navigating to a detached menu bar, because it's infinitely large, so either you're exaggerating, stupid, or have such unbelievably awful hand-eye coordination that you can't even hit a side of the screen.
Speaking as a Linux, OS X and Windows user with a 24" 1920x1200 monitor.
Re:Huh? (Score:2, Informative)
In general, I would agree with you. But if you had taken two minutes reading OUR website and not the misleading /. summary, you'd have realized that we DO NOT MAKE ANY CLAIM to be a MacOS-like environment (As in fact, we actually don't want MacOS X, we want something else.). Now, we do gladly accept criticism, and you are more than welcome to discuss UI issues on our mailing list : we actually are very UI focused, and I assure you that we think it's important. But as others said, this is only a 0.2 release, and many things will improve, we know that very well...
The "yardstick," further, is clear: they (be they /. editors or developers) threw down the gauntlet and said "Mac-like" while coughing up a poor approximation. Success and failure are determined by their ability to capture the theme. It's abundantly clear that this is sorely lacking. If you disagree, then be a rational adult and do it. I've outlined a few of the many ways they fail to measure up. Demonstrate how they ARE Mac-like if you can. The summary put itself in with the big kids and it can't hold its weight. You can't seem to divorce yourself from your rabid feelings and don't seem to know anything about space and weight, to say nothing of design in general, so I won't hold my breath for an intelligent response.
Well, you can't really hold on to us that the /. post is misleading ? Your whole premise is that we claimed that, and then you proceed to detail where we fail in that goal. And I totally agree ! Contrary to what you think, we are not claiming to be an OSX clone, we don't want to be one, and we are FAR from saying that we provide here a perfect thing: there are lots of things to do, to fix, to clean up, be it in the code or on the UI. And people are welcolme to provide constructive critiscism and give us a hand ;-) but at the same time you should also understand that it's "just" a 0.2 release and we are perfectly aware that we have a lot to do...
:-P [and we're far to that too...]
Sigh.. what happened to the whole premise "Release Early, Release Often"
Re:The want to avoid the GPL (Score:3, Informative)
We're not trying to fork GNUstep. I, and several other developers, have signed a Free Software Foundation copyright assignment form for GNUstep, so any bug fixes or changes we make can be pushed upstream. Being based on Objective-C, GNUstep can be patched at runtime easily with categories (which can replace methods in existing classes). You may see a few of these in various places fixing bugs in GNUstep, but these are always pushed upstream for inclusion in the next release. The categories are just there so people don't have to install GNUstep from SVN.
The choice to avoid the GPL comes from two things. The first is that we want to achieve very tight integration between components. This would mean that any license which controls linking as well as derived works would spread over the whole tree, and to third party components. We want to give people the choice to use more permissive licenses, and several of us prefer to use them for our own code.
One of the nice things about the BSDL and MITL is that you don't need to be a lawyer to understand them. They're one or two very short clauses with an absolute minimum of legalese. The LGPL is a lot more complicated. If you have read and understood the LGPL, then you should have no problems with any other licenses we use.
Re:Way to confuse NEXT with Mach and BSD (Score:4, Informative)
I think you have these two the wrong way around. GNUstep dates back to at least 1995 [google.co.uk], while Apple did not buy NeXT until December 1996.