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."
Mac OSX? (Score:2, Insightful)
Menus at the top! (Score:5, Insightful)
Re:The want to avoid the GPL (Score:2, Insightful)
Some people feel it's more important to create something that gets used whether in open or closed source form than something be bound by an ideology.
Re:First web browser (Score:3, Insightful)
So does the FSF for GNUStep (Score:5, Insightful)
Re:Huh? (Score:4, Insightful)
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. Approximations of a user experience defined by close attention to detail and sound design principles are simply bound to failure. Just look at the screenshots. This UI has the exact same deficiencies as nearly every other window manager for Linux--poor typefaces, rendered poorly and positioned poorly. Manipulation elements that lack refinement. You've got flat icons on a flat background shoehorned into a plain rectangular space.
The "About" screen shows it all. The background image is unbalanced. That's fine. But the shadowbox on top of it is precisely centered. Those are clashing elements. The corners on that shadowbox are too rounded to appear crisp and too confined to appear smooth or blended. The "let your environment grow" text looks goofy and childish, and it doesn't seem related to anything. It should be superimposed on the image, above the gradient bar, or it should be boxed into a separate branding box somewhere. Right now, it's superfluous text, and it's a typical, ugly Linux text experience to boot.
I don't mean to be an art snob or to demean the people who doubtlessly worked hard on this. I certainly don't mean to imply that Linux's goals should be as heavily slanted toward the aesthetic as, say, OS X. But if you put *yourself* in the big kids' pool, be prepared to take it. This is amateur, uninspired, and completely misses the boat.
Re:Huh? (Score:5, Insightful)
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
-Peter
Re:The want to avoid the GPL (Score:2, Insightful)
Re:Huh? (Score:5, Insightful)
"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:Menus at the top! (Score:5, Insightful)
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:Huh? (Score:5, Insightful)
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:Menus at the top! (Score:3, Insightful)
As for "... didn't even bother putting any UI components in to help you diagnose what the problem is", again I don't really see your point. It's UNIX. It has logs. Use them. If you want pretty UI-based logs, then open up the console application, and you can see all the logs in a nice pretty format. Personally I prefer grep.
Not to mention all the pretty UI-based help available using the 'help' key; or the drop-down 'help' menu available on all apps...
Simon.
Re:Huh? (Score:4, Insightful)
Needing or asking for a blessing is irrelevant. This is a discussion site, in case you hadn't noticed. The summary makes a proposition. People disagree with that proposition. I'm one of them. The idea that people should get a free pass because they're not paid to do it is likewise absurd. These developers are not children. They don't get a writeoff for failing to capture the essence and for missing the point. If they want to invite comparisons to other products and want to put something in the public eye, then they can accept the consequences that result, which includes criticism. It's not an arbitrary, empty, personal assault, much unlike your comment.
"My personal taste" is not a factor in this assessment. They're called basic design principles and are sorely misunderstood and violated by people at large. That's why not everyone is an architect or a designer or a sculptor. It's an art of subtlety, but as you clearly personify, there's no one more dense than an angry Slashdotter. "My personal taste" would be to avoid purple and flowers. "My personal taste" would involve a more dynamic menu bar that goes beyond the Mac metaphor. But you see, these aren't the issues with the project from a design standpoint. Part of a fair critique is looking at what it purports itself to be and seeing how well-realized that is. I don't like Gothic architecture, but I can certainly admire the success of a great Gothic revival piece.
The "yardstick," further, is clear: they (be they
While you're at it, cook up some rationale as to how thoughtful criticism is demeaning.
Re:Menus at the top! (Score:2, Insightful)
But I digress. The fact that you didn't know how to diagnose software problems isn't my fault. If you didn't know what Mac bomb code 92 was, well, you must have thrown out the manual. It was different, for sure, and I didn't prefer it for a number of reasons, but that's it. Different.
OSX is unix, and if you can't handle that then it's obvious why you had problems with OS =9. Windows power users are used to windows. You've spent years transforming from noob to where you are now. Mac power users did the same thing. To be certain, noobs on any system can't troubleshoot shit, just ask your parents/grandparents/whoever.
I'm sorry your such a Mac noob.
Re:Menus at the top! (Score:3, Insightful)
The point I was trying to make was simply that the assumption that something will "just work" often is used as justification for poor control over such actions being placed in the UI. For example, if it is assumed that the wireless subsystem will automatically pick the best access point, why bother putting an access point preference selector in the wireless device configuration UI? The idea that someone should have to go dig through logs to find out why the lesser favourite access point was selected is all well and good, but it doesn't help solve the immediate problem that the automatic selection of access points isn't working. Whereas, if the assumption is that things that "just work" might not "just work" now and then, the developer is more likely to provide the user with the tools they need to get the job done themselves.
Now, kindly, fuck off.
Re:Menus at the top! (Score:5, Insightful)
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.
It's all about GNUStep (Score:3, Insightful)
GNUStep [gnustep.org] is a decent implementation, though it's slow in development. It is based on Objective-C, which is (in MNSHO) a much better OO language than C++, Java, or C#. The foundation libraries are a little primitive by modern standards, but pretty clean and powerful nonetheless.
The window manager is the least of the operating environment.
It's about time! (Score:3, Insightful)
Objective C is not the best OOPL, and NeXTstep is not the best class library, but the competition that's actually got wide use is so appallingly bad that they shine like costume jewelry in a pile of muck. Being able to write code that will compile and run natively on OS X and X11 polishes it up a treat.
The looks and theme aren't the point. NeXTstep was awfully drab too but it developed a devoted following not because it looked cool, but because it worked well and consistently across all applications, and that was a result of the language and libraries as much as Steve Jobs' legendary attitude.