“The Etoile project is pleased to announce the release of version 0.2 of the Etoile User Environment for UNIX-like systems. The Etoile project aims to produce a user environment for desktop and small form-factor devices, with tight integration between components. The 0.2 release is primarily targeted at developers interested in a GNUstep-based environment. This release includes improvements to the Camaelon theme engine, providing a clean and modern appearance to GNUstep-based applications. This is combined with the Etoile Menu Server, providing a horizontal menu bar similar to that found in Mac OS, and making this the first Etoile release with enough features in place to be usable on a daily basis.” There are screenshots too.
does anyone know if there is a lisp gnustep bridge? it would be great to be able to build apps that way.
it looks like openmcl did at one point have some support for gnustep, but i haven’t been able to find the current status of the bindings. on another note it looks like popplerkit from etoile 0.2 doesn’t build on ubuntu gutsy.
does anyone know if there is a lisp gnustep bridge? it would be great to be able to build apps that way.
Afaik, there’s scheme bindings in GNUstep. Never used them though.
This project really seems to coming along compared to the last time I looked at it. Here’s hoping it keeps going.
I have been using Etoile for the last two months and I like it a lot. It is user friendly and works well. It has become my default mp3 player on Gnome.
what? this is an article on a desktop environment. Do you mean exaile?
Like the menu bar, the dock. Not complaining, just stating what it looks like to me. I like it. Of course I like OSX too.
Mac OS X has its roots in NeXTStep which spawned OpenSTEP which in turned spawned GnuStep.
The Dock is directly from NeXTSTEP – and that’s where OS X has the dock from
. The menu bar is obviously inspired by Mac OS X, but is none-the-less the only sensible option for menubars in GnuSTEP due to the detached nature of menues in NextSTEP.
I’m old fashioned I know, but I liked those detached menus from NEXTSTEP.
Give me a dwrite options for OS X 10.5 for such a layout effectively removing the top menubar and I’d be very happy and more productive. Give me the option to autohide all other windows–except those targeted with my current application–by double clicking the active working app icon and it would make my fond memories of NeXTSTEP/Openstep rise again.
Docks have been around since RISCOS even…menu bars, DRI GEM got sued by Apple for that (before Look n feel turned out not to be copyrightable through the Lotus lawsuit I think), they had to change their whole interface. Same with Microsoft and Windows.
Just an FYI.
NEXTSTEP was the original OS.
OPENSTEP wasn the second OS
and OpenStep is the API Framework. unless im mistaken. the naming scheme is confusing
Browser: Mozilla/4.0 (compatible; MSIE 6.0; Windows 95; PalmSource; Blazer 3.0) 16;160×160
From wikipedia (http://en.wikipedia.org/wiki/Openstep):
OpenStep is an API specification, OPENSTEP (all capitalized) is a specific implementation of this OpenStep developed by NeXT.
It’s a good time to be a fan of unified menu bars…
Recently some enterprising Gnome hackers discovered a way to get Gnome (or maybe any Gtk+) apps to use a unified menu bar.
KDE has offered a unified menu bar for years, and shows no signs of wanting to rid themselves of the feature.
Apparently the Etoile project brings unified menu bars to GNUstep.
But sadly I don’t believe any one is compatible with any other, in look-and-feel or features.
Could we please see a little standardization, lest we end up with unified menu aficionados having to put up with applications from three desktop environments fighting for the same piece of real estate, and with each wanting to display their own filler menu when they think no tasks are active… yuck.
Please don’t let this be a repeat of the “system tray” woes of a few years back.
Yes, a standard for unified menus is very much needed.
My hope is that such a thing gets implemented as a separate application, i.e. a menu manager, that communicated with all apps over a well specified open protocol.
That way it woold be less problems with the not invented here syndrome as a network protocol would be independent of things like toolkits and programming languages.
We would also get yet another way to style our desktops, just like we can do with window managers today. It could also be a good way to ease development of better accecability for handicapped people.
Anyway, its nice to hear that more and more free desktop environmnents think about providing unified menu. The idea behind the unified menu a la MacOS is the the screen edge presents an infinitly large target.
And large targets are esier to hit. This is one of the most tested priciples in usability (Fits law), and it is very strange that it hasn’t been more used.
It is also nice to see that they have placed the doc to the side of the screen instead of at the bottom as more and more computers have widescreen displays.
The more I think about it, the more I see that you are so right.
The standard would have to be pretty extensive, though. It must include a standard for “menulets” as Étoilé calls them, and it must not take away features found in existing systems. Menus have to be tear off-capable, and there might need to be an option for whether teared off menus are shown only for the focused application.
GNUstep always got unified menus , but before etoile they where floating , like in the original NS environment.
Exactly. That’s why a “Unified” menubar are the only sensible solution for Etoile – or any DE based on the OpenStep specification.
It’s a bit ignorant to claim this is the only sensible solution. I’m sure there are NeXTstep users that find floating menus to be the ultimate productivity boost.
Not saying I don’t like the Mac-style unified menubar, just that different people have different preferences.
dylansmrjones only said that if you want a menubar, then you should use a unified one, as the floating menu of *step is also unified.
Then I apologize. I obviously read that differently.
No problem
– and I’ll try to be clearer in my wording next time 
Yes. Having them floating instead of a unified menubar is definitely an option. Personally I haven’t decided what I prefer. But as puenktchen pointed out it was merely if you wanted a menubar then unified menues made most sense. Having them floating is of course not a bad idea, though it might confuse some
the floating menus of *step are cool, but i’m not sure if they enhance your productivity. I’ve never used them for more than a few hours, so i don’t have a educated opinion. pros and cons:
+ detachable submenues
+ on big screens they are closer to your mousepointer
– they can get in your way
– harder to hit (fits law)
but many programms use floating menus for the most common commands anyway, and that’s probably the best use for them – you’re not going to use the main menu that often.
Let’s not forget that you can of course have detachable menus with a horizontal menubar as well. Apple’s first attempt to theme OPENSTEP with a MacOS look’n’feel had this. I’m not sure whether the submenus were detachable, but why would that be any harder than when the main menu is floating?
From the Nathan’s Toasty Technology GUI Gallery page on Rhapsody DR2;
http://toastytech.com/guis/rhapprefsoptions.png
Those in Rhapsody DR1/DR2 were reminiscent of BeOS.
NeXTSTEP/Openstep’s Floating Menus/Tear-off Submenus restoring state upon close that Apple has started to use again in Pages.app (Andrew Stone’s Cocoa AppSuite uses as much as possible) are hindered by the Top Menu bar being ubiquitous across the screen. And for the lazy user the right mouse button for NeXTSTEP/Openstep did allow access to an applications full menu system.
@ tyrione: ???
– where do you see similarities between the menus in rhapsody and beos? iirc, beos doesn’t have a unified menu and no detachable menus either.
– the floating “inspector”-window of stone create, apple pages and other cocoa apps has nothing to do with the floating main menu used by *step. it’s just a tool-palette. and you can’t even tear off the subpalettes – as you can do with the palettes of mellel (redlers.com).
– why is the top menu bar hindering these kind of palettes?
– i also like the main menus which show up where you click a mouse button. iirc, riscos used them, fluxbox and some other wm use them, and an alternative workbench for amiga os (scalos?) also used them. great for experienced users, but confusing for most users. expeciallly, if you have to remember which functions are in the context menu and which are in the main menu. and if you combine both, the menu can become far too big.
> – where do you see similarities between the menus in
> rhapsody and beos? iirc, beos doesn’t have a unified
> menu and no detachable menus either.
In that screen shot? Look at the title bar on the floating menu – it is a “tab” like those of BeOS. That is what I read from that comment (having also come to the same conclusion when viewing the image.) IIRC, Rhapsody was created *after* BeOS too.
> In that screen shot? Look at the title bar on the floating menu – it is a
> “tab” like those of BeOS. That is what I read from that comment (having
> also come to the same conclusion when viewing the image.) IIRC,
> Rhapsody was created *after* BeOS too.
the tab, i see. but it’s a tab on a floating menu and not on a window like in beos. anyway, it’s a cosmetic detail and nothing fundamental.
a comparison of menu-systems from the time before rhapsody (1999 – sorry gnome & kde!):
http://www.mackido.com/Interface/menus_who.html
http://www.mackido.com/Interface/menus.html
obviously from a macuser, but still not all bad! 😉
Actually, I don’t think the tab is inspired by BeOS at all. I think the detached menu has that look in order to keep its appearance intact as much as possible while you tear it off. Open a menu in any OS that uses a menubar (pretty much anything but NeXT and RISC). What do you see? A tab! Just look at the little picture of an open File menu in the screenshot’s appearance panel. It looks nearly identical to the detached Applications menu, except for the close button on the latter.