Slashdot Mirror

← Back to Stories (view on slashdot.org)

Etoile Project Releases Mac-Like Environment

Posted by kdawson on from the starry-eyed-penguin dept.

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

57 of 311 comments (clear)

  1. Mac OSX? by Daengbo · · Score: 2, Insightful

    Except for the fact that it has a top panel and a launcher, I don't see the similarity to Mac OSX (Not that I really use either of them -- just seen screenshots). Honestly, it reminds me more of WindowMaker using GnuStep apps. I think GnuStep is a great platform, though, and am glad that someone is finally puuting together a DM for it from the ground up, instead of using WindowMaker or similar. With the ease of development GnuStep gives, I guess the project could develop quickly if enough people get on board.

    --
    Put identity in the browser.
    1. Re:Mac OSX? by marcello_dl · · Score: 3, Informative

      In fact if I got TFA it has similarities with what the mac could have been if Apple didn't practically kill hypercard and left the newton and opendoc to wither. The monolithic app is what commercial software vendors want, while a document or object centric environment is very exciting from the power user point of view. In fact is kinda translating the unix philosophy of making specialized tools work together for complex tasks in a GUI and OO.

      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.

      --
      ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
    2. Re:Mac OSX? by Ilgaz · · Score: 2, Interesting

      I am saying something for 3-4 years since I switched to OS X as ex Slackware/WindowMaker user.

      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 to OS X Desktop. In fact I made it my default X11 windowmanager easily. It has some features which lacks from OS X as it would confuse average end user (in Apple eyes) which are there on Next.

      If Apple releases Cocoa etc. stuff for open source systems one day, I am sure they will first check WindowMaker and AfterStep.

      It is either the submissions choice of words/headline or some Linux distro known for its fanatics but the discussion under this story is completely off topic. I think it is a waste.

  2. Menus at the top! by kinabrew · · Score: 5, Insightful

    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.

    1. Re:Menus at the top! by gilesjuk · · Score: 2, Interesting

      It's a pain when you have dual screens though. With OSX you have to choose which screen gets the menubar.

      There's hacks to work around it of course.

    2. Re:Menus at the top! by kinabrew · · Score: 2, Interesting

      A simple solution to that is to have menu bars appear on both screens if there are applications on both screens.

      Just show the menu bar on both screens with the menus of whatever is the front application on that particular screen.

    3. Re:Menus at the top! by kinabrew · · Score: 2, Informative

      Actually, while KDE has long had the option to put the menu bar at the top of the screen, the last time I used KDE, if you move your mouse to the very top of the screen, you would still click above the menu, not activating it.

      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.

    4. Re:Menus at the top! by Anonymous Coward · · Score: 2, Informative

      How long ago was this? As it is now, you're just spreading FUD, you can't click above the KDE top-menu as there is nothing above it, and it's been like this for a long time.

    5. Re:Menus at the top! by chill · · Score: 3, Informative

      I believe this was fixed in 3.2. In any case, with the most recent version of KDE (3.5.6) I can't click above the menu bar.

      --
      Learning HOW to think is more important than learning WHAT to think.
    6. Re:Menus at the top! by kinabrew · · Score: 5, Insightful

      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.

    7. Re:Menus at the top! by dltaylor · · Score: 2, Interesting

      The task bars, docks, whatever you call them, cost me real estate; the "menu at the top" costs me mouse movement, unless I put every application at the very top of the screen. Since I multitask, I would have a lot of hidden windows, which then costs me work to sort through (without a task bar). I end up trading real estate (taskbar) for mouse, or keyboard, actions (sorting through active windows).

      With Sawfish, I have neither of those downsides. The only thing that now bothers me with Sawfish is that is seems to have lost the ability to focus a window, without bringing it "front", which is common with other recent window managers/desktops. Again, since I multitask, it takes me longer to "copy and paste" from, for example, a log window in a corner of the screen to an email.

    8. Re:Menus at the top! by Space+cowboy · · Score: 5, Informative

      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.

      --
      Physicists get Hadrons!
    9. Re:Menus at the top! by kevorkian · · Score: 2, Informative

      in regards to the task bar that wont budge .. there is a setting called "lock the taskbar" when unlocked you can move it where ever you want .. even the 'other' display

      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.

    10. Re:Menus at the top! by Space+cowboy · · Score: 2, Insightful

      So, as I *stated* in the post, I was responding to the points raised by the poster. If you want to raise your own, go right ahead - pulling "all the bad things" out as a catch-all isn't a good argument though.

      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.

      --
      Physicists get Hadrons!
    11. Re:Menus at the top! by Millenniumman · · Score: 2, Funny

      Well, there is that thing about them wanting to make money.

      --
      Stupidity is like nuclear power, it can be used for good or evil. And you don't want to get any on you.
    12. Re:Menus at the top! by Anonymous Coward · · Score: 2, Interesting

      Here's one: Me.

      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 is. Click something.
      (4) Trundle the motherfucking mouse all the way back up to the top of the screen. This is getting old.

      It also makes multimonitor so much of a pain that it's not worth it for anything but graphics programs (where you can have a fullscreen, non-interactive preview on the 2nd monitor - and you never mouse over there).

      The "we don't need stinking maximize" argument for the "zoom" button is exposed as the bullshit it is with this argument for the menus at the top of the screen, isn't it? (the Mactard argument for zoom is that monitors are huge, nobody wants maximized windows - the Mactard argument for menus being at the top of the screen is that monitors are tiny and menus are a waste of valuable space).

      I really do like almost every aspect of OSX (typing this on my Mac right now) - except for the menu placement and that the dock doesn't behave more like the Windows taskbar (which is not so good for starting programs - but is infinitely superior for managing programs and windows that are open).

    13. Re:Menus at the top! by dltaylor · · Score: 2, Interesting

      > (a) The dock (which sort of doubles as a taskbar) is hideable. No screen real-estate need be sacrificed.

      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-application menu might be more compact horizontally than the top-of-screen menu. Any window that opens mid-display still has to have its menu accessed at the top of the screen. On a 640x480 Amiga, that was too far, and it's still too far on an 1024x768, or larger, Mac or Linux box.

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

      Haven't tried that (have to use the middle of a three-button, I suppose), but if Expose pops up close the current pointer, it would help.

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

      Could be, but I unless (c) helps, I can't find them.

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

      We have three in current use (all PPC: two iBooks, since Linux laptop support didn't used to be as good as it is now, and a Mini below the home theater monitor, for casual web browsing and streaming media), so I have tried them. I cannot get a Mac to multitask even as well as the Amiga used to, since the Amiga had fast paging through applications screens, and I cannot find that on the Mac, and it had a "lower window" feature on the windows that made togging through stacks faster since there was not even the need to move from the mouse to the keyboard. I'm not saying you can't do it, but that it takes more mouse or keyboard work to accomplish it. Could be worse, though.

    14. Re:Menus at the top! by Onan · · Score: 2, Interesting

      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-application menu might be more compact horizontally than the top-of-screen menu. Any window that opens mid-display still has to have its menu accessed at the top of the screen. On a 640x480 Amiga, that was too far, and it's still too far on an 1024x768, or larger, Mac or Linux box.

      He didn't say it was closer, he said it was easier. And the two are generally not the same thing.

      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. The interesting corollary is that targets at the edge of a display are infinitely large (given that you can overshoot them endlessly without missing them), and therefore vastly faster and easier to point at than any targets not at the edge of the display.

      Moving to a mid-screen menubar requires far more precision, and is therefore much slower, even though it's a shorter distance to move.

      ...the Amiga had fast paging through applications screens, and I cannot find that on the Mac...
      You mean just switching easily between the various windows of one application? How is that not covered by expose or command-` ?
    15. Re:Menus at the top! by QuantumG · · Score: 2, Insightful

      Thanks you my rude friend.

      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.

      --
      How we know is more important than what we know.
    16. Re:Menus at the top! by steeviant · · Score: 3, Informative

      Here's a tip... tune your mouse acceleration settings so that the mouse goes completely to the left and right (or top and bottom if your monitor is in portrait orientation) in one sweep of the mouse, then you'll find you can reach any point on your screen in just one sweep of the mouse. This works not only for menus, but for taskbars and Docks as well.

      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.

    17. Re:Menus at the top! by Curien · · Score: 4, Insightful

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

      --
      It's always a long day... 86400 doesn't fit into a short.
    18. Re:Menus at the top! by someone300 · · Score: 3, Interesting

      That's strange. The main aspects I like about my Mac are the menu placement and the way the dock+expose manages applications and windows.

      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.

    19. Re:Menus at the top! by Anonymous Coward · · Score: 2, Interesting
      You obviously haven't touched a Mac, or at least haven't done any experimenting with mouse control.

      Acceleration on OS X is nothing like Windows. It actually works.

      As in, I can move the mouse gently within just the range that my fingers reach and only move about a total of an onscreen inch. That's great for precision work.
      If I move the mouse the same distance, but quickly, I can reach any side of the screen or corner.

      Clearer now?

      Whenever you increase the acceleration you reduce the precision of the entire mouse system period.

      INCORRECT.
  3. First web browser by HighPerformanceCoder · · Score: 2, Interesting

    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?

    1. Re:First web browser by Anonymous Coward · · Score: 3, Informative

      The very first web browser (called WorldWideWeb) was developed on a NeXT by Tim Berners-Lee.

    2. Re:First web browser by Strepsil · · Score: 2, Insightful

      And, of course, so was the world's first web server, without which the browser wouldn't have been very useful. :)

      --
      Wasting your time since 1997.
    3. Re:First web browser by Stormwatch · · Score: 4, Informative

      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.
      --
      Circumcision is child abuse.
    4. Re:First web browser by marcello_dl · · Score: 3, Funny

      Well if berners lee developed on windows he'd have to integrate his browser into the OS. If he developed on mac, users who surfed with http would have had their sexual orientation questioned. If he developed on unix nobody would have left telnet and gopher for http, unless it had either perl or remote exploits. That leaves the amiga and the next.

      --
      ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
  4. The want to avoid the GPL by bomanbot · · Score: 3, Interesting

    Interestingly, the Etoile developers seem to want to avoid the GPL and prefer the BSD License (as seen on their about page here: http://www.etoile-project.org/etoile/mediawiki/ind ex.php?title=EtoileWiki:About/), which I find a bit odd...

    1. Re:The want to avoid the GPL by Microlith · · Score: 2, Insightful

      It's not odd, it's just not what -you- would have done I imagine.

      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.

    2. Re:The want to avoid the GPL by larry+bagina · · Score: 2, Insightful

      The GNUStep libraries are LGPL. Anything can link to them. the LGPL is not supposed to be viral. Let's keep it that way.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    3. Re:The want to avoid the GPL by TheRaven64 · · Score: 2, Informative
      Hi, I wrote the document you linked to (although the other core devs agree with the reasoning and conclusions). The LGPL affects GNUstep code, and GNUstep code only. The only requirement it places on other code is that it should be possible for the end user to re-link it with their own version of GNUstep. This is not a problem for us (we distribute source code). If people want to distribute binary-only components for Étoilé, I probably wouldn't use them, but they can if they don't statically link to GNUstep.

      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.

      It certainly would be easier if Etoile and GNUstep would use the same license because you do not have different licenses with different legal aspects and issues that may even be interacting with each other We do have a few LGPL'd components in the core system, and none of us have a problem with the LGPL as a license. Every other license we use is more permissive. If what you are doing is allowed under the LGPL, then it will be allowed. For some components, you may have more rights. Some parts are MIT-licensed, so you can do pretty much anything with them. Most new code is 3-clause BSD-licensed. The one exception currently is PopplerKit which, being based on Poppler, which is based on xpdf, inherits the GPL. If you know of an LGPL, BSDL, MITL or PD library for parsing and displaying PDFs, I'd love to hear about it.

      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.

      --
      I am TheRaven on Soylent News
  5. Huh? by JimDaGeek · · Score: 2, Interesting

    This isn't even close to OS X. Seriously. This is like making some really crappy "OS" and then saying, hey, we are close to MS Windows 95. I looked at this site, screen shots and other stuff. They just don't come close to the current Mac OS X OS.

    --
    General, you are listening to a machine! Do the world a favor and don't act like one.
    1. Re:Huh? by mr_matticus · · Score: 3, Insightful

      Parent is not a troll.

      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.

    2. Re:Huh? by pschmied · · Score: 4, Insightful

      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

      --
      . Penguins Surely Ca
    3. Re:Huh? by mr_matticus · · Score: 4, Interesting

      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.

    4. Re:Huh? by forkazoo · · 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.


      "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! :)
    5. Re:Huh? by mr_matticus · · Score: 4, Insightful

      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.

    6. Re:Huh? by Orange+Crush · · Score: 3, Funny

      It looked more Mac-like before the name change, but Apple threatened to sue if they called it iToil.

    7. Re:Huh? by mr_matticus · · Score: 3, Insightful

      Perhaps you should ask yourself what your problem is. You're the blustery, vitriol-spitting pig that makes Slashdot infamous as a hive of morons and assholes.

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

      While you're at it, cook up some rationale as to how thoughtful criticism is demeaning.

    8. Re:Huh? by Nicolas+Roard · · Score: 2, Informative
      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.

      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...
      Sigh.. what happened to the whole premise "Release Early, Release Often" :-P [and we're far to that too...]

  6. Strategic importance of Etoile by pschmied · · Score: 5, Interesting

    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

    --
    . Penguins Surely Ca
  7. NEXTSTEP = OS X by Anonymous Coward · · Score: 2, Informative

    Read some history, Apple bought NEXTSTEP and based OS X on it. Etoile uses some NEXTSTEP.

  8. Re:Trying to get this up and running by pschmied · · Score: 4, Informative

    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

    --
    . Penguins Surely Ca
  9. So does the FSF for GNUStep by pschmied · · Score: 4, Insightful

    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.

    --
    . Penguins Surely Ca
  10. Iffy work on next-gen-file-abstraction by Craig+Ringer · · Score: 2, 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:

    1. Files are a low level SHARED abstraction agreed upon by ALL major plaforms in use. Like the use of the C interface to communicate between components in an executable (no matter what language(s) they're written in) it's going to stay dominant unless you can convince everybody to change to your new one.
    2. Because of (1), cross-platform data sharing will be much harder, and apps will have to support a conventional file format too. Especially for a niche platform that lacks the market power to force the new approach down everybody's throats.
    3. It's very much like the Apple Resouce Fork - a quite nice (if imperfectly implemented and historically limited) approach to enhancing files. ResEdit was amazing. Unfortunately, the resource fork is fading from use because it was always a royal PITA for cross platform work, and because portable apps can't rely on it.
    4. This is different to, say, Java's object serialization how?

    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.

  11. Urgh! by NoMaster · · Score: 2, Informative

    Urgh! Looks like an ugly version of a Gnome-ified WindowMaker/GNUstep. Granted, with GNUstep the underpinnings should be sufficiently NeXT / OS X like - but the 'G' part of the 'GUI' is fugly as sin and hardly Mac-like (with the exception of the 'taskbar at the top'), which doesn't bode well for the 'UI' part of the equation.

    (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...)

    --
    What part of "a well regulated militia" do you not understand?
  12. It's like OpenStep by OrangeTide · · Score: 2, Informative

    The GNUStep project has been around for a very long time (been available since around 1991). Internally it is more like MacOS X or OpenStep, and therefor theoretically easier to port applications to this environment (or port GNUStep apps to OSX).

    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." .. but it's older than Linux kernel.

    --
    “Common sense is not so common.” — Voltaire
  13. Wow! by Caspian · · Score: 2, Funny

    It's like a Mac, but minus all the cool!

    *dodges Linux fanboys* Aieee!

    --
    With spending like this, exactly what are "conservatives" conserving?
  14. Re:Way to confuse NEXT with Mach and BSD by HeroreV · · Score: 4, Informative
    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.
  15. Re:Way to confuse NEXT with Mach and BSD by Anonymous Coward · · Score: 2, Informative

    Way to show that you know nothing about NeXT, and can't even read the summary of an article, let alone the article itself.

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

  16. No, this is oblig. :) by Anonymous Coward · · 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.

  17. Re:Oblig. by ubrgeek · · Score: 2, Funny

    "... built from the ground up on highly modular and light components with project and document orientation in mind, in order to allow users to create their own workflow by reshaping or recombining provided Services (aka Applications), Components etc. Flexibility and modularity on both User Interface and code level should allow us to scale from PDA to computer environment."

    All that's missing from that description is "synergy" and "paradigm." Throw those in there and the VC money will start flowing in ;)

    --
    Bark less. Wag more.
  18. It's all about GNUStep by Tony · · Score: 2, Insightful

    A window manager is not a desktop environment; it is but one part of a desktop environment. GNUStep is an implementation of OpenStep, an open API that is based closely on the old NeXTStep environment from the old NeXT computers.

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

    --
    Microsoft is to software what Budweiser is to beer.
  19. Re:Way to confuse NEXT with Mach and BSD by jrumney · · Score: 3, Informative

    4. Apple buys OPENSTEP and uses it to produce Mac OS X
    5. GNU implements the OpenStep API as GNUstep

    I think you have these two the wrong way around. GNUstep dates back to at least 1995, while Apple did not buy NeXT until December 1996.

  20. Re:Way to confuse NEXT with Mach and BSD by blankaBrew · · Score: 2, Interesting

    You are absolutely correct. In fact, NeXT was positioning OPENSTEP as what Java later turned out to be; write once, run anywhere. Actually, Sun was very interested in NeXT and included it in Solaris. However, a funny thing happened. About a year or two after Sun became involved in OPENSTEP, they dropped it and came out with their own environment called Java. Amazing to think how history might have changed if they stayed the course with OPENSTEP, rather than coming out with their own Java.

    So, OPENSTEP/NeXTSTEP/Cocoa/GNUstep are in no way tied to their BSD underpinnings, and have actually been implemented over other OSes.

  21. It's about time! by argent · · Score: 2, Insightful

    Making something "cool" around GNUstep is something I've been hoping would happen for some time.

    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.