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)
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: (Score:3, Interesting)
If people supported WindowMaker/OpenStep as they really seem to get impressed with OS X Desktop, things could really change in Linux Desktop scene. Especially those guys who spend hard time trying to make OS X work flawless on white box PCs via binary hacks.
Thanks to Fink project I checked WindowMaker again on OS X and I easily recommend it to Mac only people wanting a "real" fullscreen X11 since it is very close
Menus at the top! (Score:5, Insightful)
Re: (Score:3, Interesting)
There's hacks to work around it of course.
Re: (Score:2, Interesting)
Just show the menu bar on both screens with the menus of whatever is the front application on that particular screen.
Re: (Score:2)
I wish OS X would put the menu bar on both screens. It's really not too hard to do.
That said, I think Windows is a worse violator, or maybe it's just the drivers... The task bar only goes on the secondary display. When I hook my laptop up to my big monitor, the task bar simply refuses to budge! But at home, with the big LCD, I only use my laptop screen as a tools palette for apps like Photoshop and 3dsmax. This is very annoying. I can't even get games to run on the big monitor, since the display panel wou
Re: (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.
Re: (Score:2)
Re: (Score:2)
(although, unfortunately, you cannot right clock this clock for the date)
Re: (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: (Score:2, Informative)
Re: (Score:2)
Must have been a long while ago, as the KDE menu bar works exactly how you want it, with an infinitely tall target.
Re:Menus at the top! (Score:4, Informative)
Re: (Score:2)
I know it's just a really nice Window Manager on top of BSD (for the most part), but I think they would really have a market among the people who want to get away from Windows, but just aren't ready to make the leap to Linux.
Is it really just a device driver issue where they don't want to support 1,000,000 combinations of hardware?
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
Not even close.
Is it really just a device driver issue where they don't want to support 1,000,000 combinations of hardware?
In a word: yes. If you ever have the misfortune to have to use a 3rd party driver for, say, a networking device on Mac OS X - whether on a real Mac or because you need it to run Mac OS X on your generic x86 box - you will come to understand quite quickly the difference in quality between Apple's ef
Re: (Score:2)
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: (Score:2, Interesting)
With Sawfish, I have neither of those downsides. The only thing that now bothers me with Sawfish is that is s
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: (Score:2, Interesting)
Except that I now have to move the pointer farther to get to it. Like I said, I trade real estate for motion.
> 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.
That's just nonsense, unless ALL windows are opened immediately below the menu bar, and, even then, the per
Re: (Score:3, Interesting)
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.
Re: (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. Per
Console.app/Event Viewer (Score:2)
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.
That's true, It's amazing how many people don't seem to know that the OS X log viewer exists. One can find it here: /Applications/Utilities/Console.app. To draw a parallel, the Console.app serves a roughly similar purpose as "Event Viewer" in Windows (Start->Control Panel->Administrative Tools->Event Viewer). Personally I feel the OS X logs are somewhat less cryptic than the ones in Windows but that's probably just because I don't have much experience with debugging Windows since I haven't used it
Re: (Score:2)
I think it's kind of funny that many Windows users seem to think that you can't "debug" Macs. I attribute this misconception to a lack of experience with Macs. Obviously, you can diagnose problems with Mac OS X, and in my exper
Re: (Score:2, Insightful)
But I digress. The fact that you didn't know how to diagnose software problems isn't my
Re: (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 acces
Re: (Score:2)
Which is why a lot of people just hide the Dock.
Well, it may indeed cost you "mouse movement," but on the other hand, you gain time. Fitt's law, look it up.
More mouse movement does not equal more time used.
Re: (Score:2)
Take a gander at this screenshot [thejagcompany.com] of NeXtstep to see where it's coming from. Very early 90s. Yes, the window controls are not Mac-like, but on the whole it's not all that different in feel from System 7 or OS 8. As I said, a very 90s feel to it.
Re: (Score:2)
Re: (Score:2, Interesting)
I can't tell you how much I hate tooling around to the top of the screen when I have several applications open on a large monitor. It's bad enough that I have my mousepad sideways (long-axis vertical), because that's the direction that requires the most unnecessary movement:
(1) Click on a button in the application.
(2) Motor the fuck all the way up to the top of the screen, click a menu option.
(3) Voyage the mouse all the way back down to the bottom of the screen where the application window i
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:Menus at the top! (Score:4, Interesting)
The Mac argument for zoom is that noone wants maximised windows... which is true when you really think about it. Most Windows or indeed Linux converts (that includes me) I see are always struggling to maximise their windows until it hits them - they never really wanted it maximised in the first place. Why would they want to maximise Word on a 36" monitor?
I'm not sure why we maximise windows. I think I had two reasons:
- It was hard to tell which window was what. I have quite a bit of difficulty distinguishing between windows without decent shadows behind them, which neither Windows or Linux at the time provided.
- I always used to use the top of the screen as a sort of mouse reflection point. I knew that if I threw the mouse up there from any point on the screen, it's stop and I could be more precise and lower it carefully to select a menu button... it was easier because the top of the screen was a sort of infinite height target.
The small screen argument has been irrelevant for a few years, I think.
I think the problem you're having is that your mouse settings are crap. Macs are really optimised towards high precision mice optimised so that you can cover the entire screen in a short sweep as well as having good precision when you move slowly. This means quite high acceleration. I can cover over 1000 pixels in about 4cm when I move my mouse sharply, but if I move slowly I can almost move the mouse with 1:1 distance correspondence between mouse distance and screen distance... about 40px/cm.
Plus, try using cmd+tab (and other shortcuts or expose once in a while, though expose is also optimised for decent mouse settings. You do have a point about dual monitor, but I think even mac fanboys tend to accept that it's a PITA for dual monitor. What applications are you using that require menu interaction that frequently? CS3 suite or something? If so, do yourself a favour and learn the shortcuts. It's damn near impossible to use a program with that much menu interaction without learning shortcuts... Windows, Linux or OS X.
First web browser (Score:2, Interesting)
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Fun fact (Score:2)
Re:First web browser (Score:5, Informative)
Re:First web browser (Score:4, Funny)
The want to avoid the GPL (Score:3, Interesting)
Re: (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: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:3, Informative)
So does the FSF for GNUStep (Score:5, Insightful)
Re: (Score:2)
Why do you find it odd? The GPL has a fairly viral nature, which they find does not works with their component based system.
They actually have very strong reasoning.
Huh? (Score:2, Interesting)
Re: (Score:2)
On the other hand, these Étoilé guys seem to be writing
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:Huh? (Score:5, Interesting)
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: (Score:2)
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: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.
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: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2, Informative)
In general, I would agree with you. But if you had taken two minutes reading OUR website and not the misleading /.
+10^100 super-effin'-ultra-über insightfull!! (Score:2)
(apart from the opening insults maybe - allthough they're understandable)
Re: (Score:2)
"work for which they were not paid, did not ask your blessing, nor did they need it"
It doesn't matter why someone is doing something, it's the end result that counts. Even if someone is doing volunteer work for a charity, if they do a bad job then something needs to be done. Best intentions are not an excuse. That said, in a project like this it's up to the developers to decide what they want to achieve. As users, we can only hope that our interests are the same as
Re:Huh? (Score:4, Funny)
Re: (Score:2)
Re: (Score:2)
It looks vaguely like a mac (though eesh, invest in some antialiasing), but the static looks of an interface are a relatively small part of what matters. I'd bet cash money that it doesn't work like a mac.
Sorry, I don't mean to disparage your choice of window dressing or imply that it doesn't work well for you. I'm just frustrated by the decades of people willing to steal the very simple superficial parts of another known-good system and declare, "okay, user interface problem solved!"
Trying to get this up and running (Score:2)
It's not a window manager like my enlightenment or blackbox and I'm not sure where to start it. Seems to have installed fine.
Can I configure it to be an option in my login or do I need to command line it?
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: (Score:2)
Cheers,
Peter
Re: (Score:2)
As well as not being able to choose my desktop environment I'm having trouble choosing between the "theme" option I've chosen and what's available through gdmsetup.
Basically there are several desktop configuration menus, and none seem to allow me to choose a desktop environment.
Re: (Score:2)
Strategic importance of Etoile (Score:5, Interesting)
If you haven't already done so, I urge you to check out David's Core Object posting. [etoile-project.org] 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: (Score:2)
not so closely related anymore (Score:2)
Iffy work on next-gen-file-abstraction (Score:3, Interesting)
The discussion of a replacement for the "file" abstraction seems a bit iffy. We've seen this before, many times, and it hasn't worked:
In short: it seems they're improving object serialization. Nice, but hardly revolutionary, and likely to introduce fun problems when interoperating with software relying on it.
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...)
Re: (Score:2)
Checked out the screenshots and it looks really ugly. Surely this is what an interface designer comes up with on their first, embarrassing attempt?
Comment removed (Score:3, Funny)
not a good direction for Linux (Score:2)
Why does runtime safety matter? It matters because it makes software more robust and more secure. Without it, an error in a plugin or application can cause not only a crash, but also silent data corruption or data loss. M
Re: (Score:2)
Re: (Score:2)
Only what has been publicly released, which indicates that Objective C 2.0 includes garbage collection but remains backwards compatible; that would make it an unsafe language.
If Objective C 2.0 turns out to be a safe language and if someone creates an open source implementation, then it's a reasonable consideration. But if Objective C 2.0 turns out to be a safe language, then Etoile and Cocoa would have to be reengineered from the ground up to take advanta
Re: (Score:2)
I find this matter tedious, but I feel compelled to defend the honor of the old girl Objective-C:
Re: (Score:2)
If you have more information, maybe instead of name calling, you can share that with the rest of us.
Re: (Score:2)
Objective C has never used garbage collection until now, and Objective C has had one of the fastest method dispatches of any dynamic object-oriented language. The issue with Objective C has always been its lack of runtime safety, which is even worse than C. For example, nothing checks that the argument types for method c
Someone help me out: What's the point? (Score:2)
However the rest just looks like an inconsistent WMaker/*Step theme with an XFCE bar at the left. Or is there more to it than meets the eye? Some underlying feature laden super framework that will make this WM
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 win
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 bec
NEXTSTEP = OS X (Score:2, Informative)
Maybe, but why? (Score:2)
You don't seem to have described any actual problems that you perceive with a windowing paradigm. You assert that there must be some other metaphor, but you don't say anything about the ways in which it would be beneficial for that metaphor to differ from this one. You assert that you want something "better", but don't say anything about what would be better about it or what is currently lacking.
You can't find a solution without understanding what the problem is.
Re: (Score:2)
First, overlapping windows are often undesirable, users either maximize the current window or tile them. An exception are dialogs, which obviously cannot be tiled. (Toolwindows CAN be tiled, however.)
It matches the design principle of an application's GUI: there, no widgets overlap, they are tiled, and/or organized into tabbed groups.
With the advent of large screens (and multi-monitor setups) tiling window managers like ion or wmii become more interesting. Now, something
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: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.
Re: (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 Specif
No, this is oblig. :) (Score:3, Funny)
Slashdot 29 July 2007: Sun Says Project Indiana is Not a Linux Copy - yeah right!
Slashdot 30 July 2007: Etoile Project Releases Mac-Like Environment
Slashdot 31 July 2007: Mac OS-X is the most copied OS on planet - copying is the highest form of flattery.
So, Solaris copies Linux, Linux copies Mac OSX, but nobody is really interested in Vista.
Re: (Score:3, Funny)
All that's missing from that description is "synergy" and "paradigm." Throw those in there and the VC money will start flowing in