Etoile Project Releases Mac-Like Environment

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."

Comments

Menus at the top!

[kinabrew]

Finally, an open-source desktop environment whose developers understand that menus at the top are infinite targets and always in the same place and therefore are easier to hit.

Re:Menus at the top!

[kinabrew]

You're not giving up real estate by having the menu bar at the top. If each program has its own menu bar inside its window, that uses several times as much real estate.

For example, I have six windows open right now in OS X. Were I using an environment where each window had its own menu bar, that would use six times as much screen real estate.

If menus are hidden and only activated by right-click, many people wouldn't realize the options that are available to them. That is admittedly easy for some people, but it's better not to require most people to memorize a whole bunch of stuff. Using a computer shouldn't be frustrating even for someone just sitting down for the first time. A luddite isn't going to know that they need to right-click to see menus.

As for the dock(not actually called a taskbar), that can be hidden. I suppose it would be beneficial to let people decide whether to display menus in-window or outside, and do I agree that all commands should be accessible through contextual menus, but by default, I believe strongly that controls should be placed to waste as little screen real estate as possible, and to be very easy to hit, regardless of movement.

Re:Menus at the top!

[Space cowboy]

I'm not sure I understand your comment. I think you don't get the usual Mac workflow.

(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!

[Curien]

[T]argets at the edge of a display are infinitely large (given that you can overshoot them endlessly without missing them)

They are NOT "infinitely large". If they were infinitely large, then you wouldn't have to move the mouse *at all* to click on them. Calling them "infinitely large" just confuses people who know what the words "infinite" and "large" mean.

He's referring to Fitt's Law, and one of its interesting corollaries. The relevant bit of the law is that the time it takes to point at a target is related to the size of that target.

Fitts' law, according to that Wikipedia article, states that the time it takes to complete a movement is proportional to the binary logarithm of the ratio between the distance to the center of the target and the width of the target in the direction of motion.

Note that Fitts' law does not say anything about how "easy" the task is -- just how much time it takes.

Now, the argument you and others seem to be making is that, for the purposes of Fitts' law, an object at the edge of the mousing area can be considered to have infinite width; the amount of time it takes to complete the action is therefore minimized.

However, you are neglecting the other parameter: if the width of the target is infinite, then the distance to its center is also infinite, and the ratio between the two converges to 1/2. But it's still not even that good: the 1/2 ratio between the "center" and the width doesn't hold in this case. Rather than being infinite, the width of the edge in a given instance is however much farther past the edge of the screen the user chooses to travel. The "center" is therefore effectively wherever the user clicks, and the ratio between the width and the center converges to 1 (it converges more quickly for narrower hotspots, so a menu bar would have a ratio very nearly 1). So Fitts' law gives T = a + (.58)b.

On my monitor, each application takes up roughly 1/4 of the screen, so while performing a sequence of actions, the menu bar is, on average, only 1/8 of a monitor width away from the location of the next action. The menu bar is 1/40 screen tall, so my average D/W ratio 5. So by Fitts' law, that gives T = a + (2.58)b.

So the log-factor ratio is 4.4, in favor of edge menus.

What this neglects is the time it then takes to perfor your NEXT action. On small monitors, the distance from the edge to any other point on the screen is small, so the cost of moving back to the location of interest isn't prohibitively large. With large monitors, however, the edge advantage actually becomes an edge disadvantage, as you have to move farther back.

For edge menus, the average distance is half the monitor size, so Fitts' law says the time is proportional to lg (1/(2w) + 1). For my screen, with the menu bar at the top of the app, the average distance is only 1/8 of the screen. So it's proportional to lg(1/(8w) + 1).

The ratio between the two is -1.415 - lg w. (Where the units for w are in terms of the size of the screen). So to click on a large item, edge menus still have the advantage. But for me, most things are button-sized (again, 1/40 the screen size in the vertical direction). In that case, the ratio comes out to about 3.9 in favor of app-menus. The ratio will favor app-menus more as the size of the target becomes smaller and less as the size becomes larger.

So not only does Fitts' law show that users with my usage pattern (roughly, as monitor size increases, window sizes remain contstant), there is no clear winner between app-menus and edge menus. But app-windows are getting more advantageous as monitor sizes increase, while edge-menus are becoming less advantageous.

If someone sees a fault in my math or reasoning, please point it out to me.

Re:First web browser

[Stormwatch]

What is the historical basis for claiming that NeXT gave rise to the Web browser? Was NCSA Mosaic developed on a NeXT? Or are you referring to an earlier browser?

WorldWideWeb was the world's first web browser and WYSIWYG HTML editor and was introduced on February 26, 1991 by Tim Berners-Lee and ran on the NeXTSTEP platform.

Strategic importance of Etoile

[pschmied]

Etoile may be in its relative infancy, but I believe it has great strategic potential for the FOSS movement. Etoile / GNUStep is building some great infrastructure, uniting the Mac and FOSS communities, and is building on some very interesting ideas.

If you haven't already done so, I urge you to check out David's Core Object posting. There is some exciting stuff there. Smalltalkers will find it particularly interesting.

Props to the Etoile team! This is even more reason for me to grow my Objective C / Cocoa / GNUStep skills.

-Peter

Re:Trying to get this up and running

[pschmied]

No, it's not a window manager. It's more analogous to something like GNOME or KDE with their associated libraries.

Here's a rough step-by-step:

1. Install the dependencies listed here: http://gnustep.blogspot.com/2006/10/gnustep-on-ubu ntuppc-610.html

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

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

So does the FSF for GNUStep

[pschmied]

The reasoning is actually pretty good. They are building a services based desktop that also has a lot of components for which they want broad reuse to be possible. The FSF actually releases most of GNUStep under the LGPL. Given the age and status as an FSF project, I wonder if LGPL wasn't in part to address the requirements of GNUStep.

Re:Huh?

[pschmied]

I think some times that the Linux community can be too concerned with window dressing and not enough by substance. What make this Mac like isn't a skin deep sort of thing. It's about being able to write a program and have it run on both.

Now, there is such a thing as not having enough of an eye for Window dressing as well. That's one of the historic complaints about GNUStep. People complain that it looks too much like the Old School NeXT. That's probably a valid complaint. These guys are making progress. I'd rather have the UI look pretty in 0.3 or 0.4 than the development libs suck into perpetuity. On that front, GNUStep is reasonably Cocoa-compatible--to the point of being able to share .Nibs (user interface files) with the Mac.

-Peter

Re:Huh?

[mr_matticus]

But the problem exists on that level as well. I confined my comments to the visual layer because that's what parent started with this thread. But these people seem to writing themselves into a corner and it's pretty easy to see how their frameworks are going to have to be wedged in with electronic equivalents of shims and compatibility layers to come back into the fold. They're writing a lot of their own stuff and making it, just like on the surface layer, an approximation of true interoperability.

GNUStep is reasonably compatible with NextStep which is reasonably compatible with Cocoa. They branched from a common ancestor and happen to be reasonably similar now. All the extra frameworks tossed in to this project looks to be a third fork more than a bridge between the two.

Re:Huh?

[forkazoo]

Ubuntu is more Mac-like than this. This is the perfect example of just plain not getting it. Copying a general layout isn't good enough.

"Mac-Like" in this context refers chiefly to the fact that programming for this is very similar to Cocoa development on Mac OS X. The guts are quite Mac-like compared to writing for Qt/KDE or GTK/Gnome.

OTOH, I expect that your criticism is quite valid. You may want to consider contributing some art to the project, or submitting patches to make it more aesthetic. Personally, the way it looks doesn't bother me, but don't let my bland tastes stop you from scratching your itch! :)

Re:Huh?

[mr_matticus]

Wouldn't it still be more accurate to say that this project is GNUstep-like? Or GNUstep-based?

Its similarity to OS X is purely by virtue of it using GNUstep, which is Cocoa-like. Credit for "Mac-like" would therefore go to the GNUstep project, at least in my book. I certainly agree with your assessment of the context of the summary, and I think that I simply glossed over the underpinnings. Perhaps my definition of similarity is too strict. I simply assumed that everyone knew GNUstep was Cocoa-like and that these people were making the claim based on their UI. It hadn't occurred to me that they would just take the "Mac-like" title from their GNUstep underpinnings.

Re:Way to confuse NEXT with Mach and BSD

[HeroreV]

You are confused (or trolling). Here's a history lesson:

1. NeXT creates the NextStep/NeXTstep/NeXTSTEP/NEXTSTEP operating system
2. NeXT releases a specification for some of their API as OpenStep
3. NeXT makes NEXTSTEP conform with the OpenStep spec and rebrands NEXTSTEP as OPENSTEP
4. Apple buys OPENSTEP and uses it to produce Mac OS X
5. GNU implements the OpenStep API as GNUstep
6. the Étoilé desktop environment is built on GNUstep

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.