When Does A Window Manager Become An Environment? 13
psycona asks: "This may seem kind of a nonsensical question, but it has been bugging me for some time now. When does a window manager become a desktop environment? Where's the point of transition? I've been a big fan of Window Maker for some time now, and here's the thing; it has wmfinder, FSViewer and a few other file managers, it has postilion and Aileron and probably other email clients, it has a ton of dockapps to do most desktop, filesystem, LAN, ppp etc. monitoring and even admin work and gawdknowswhatelse. It even has scripts to change screen resolution and colour on the fly. So can it start calling itself a desktop environment like kde,gnome,cde and xfce? And if not, what else is needed?" A simple answer might be: 'when it does more than manage windows', but that would describe most of our current crop WMs, wouldn't it?
Once it's bigger than the kernel :-) (Score:3)
Emacs is an environment. Actually, it's a whole ecosystem, isn't it? Complete with its own population of strange beings. Back in the VAX 780 days, it was bigger than the kernel, that's how we knew it was an environment, not just an editor. We just figured that 4BSD was the bootloader for Emacs. :-)
Bruce
It's really quiet here... (Score:1)
Bruce
Re:It's really quiet here... (Score:1)
Come on, Bruce! Stay on topic ;)
Everyone's too busy Trolling for OSM or wtf their trolling for now. It seems like Ask Slashdot has always been the slowest section though.
I mean, once you answer, what's the point of anyone else doing so? ;)
File-Oriented Window Manager? O-O Approaches? (Score:1)
I'm a longtime OS/2 fan and love the Workplace Shell. It's a full-up, truely object-oriented desktop (unlike Microsoft's Active Desktop that only has some O-O-like attributes). I've seen some OS/2 WS-like programs for X, but I'd like to see a full window manager like it. IBM, where's the source? [ wishing too much I guess ;->>> ]
Even without a OSS WS-like environment, can we at least get a file-oriented window manager? Personally, I'd love this. I hate just about everything about Windows with exception that the window manager is file-oriented. I guess that is what the Gnome 2.0 focus is on, but I'd really just like a light-weight window manager that was file manager-based -- even if you had to make some footprint decisions to leave out support for some graphics types, etc... I personally think it's overdue for X.
Anyone agree with me here? I like the CLI (which is *NOT* really a bad thing in UNIX because the shell capabilies are 100x better than Windows, hence why I always install Cygwin/BASH on NT ;-), but that 2% of the time I wish I had a file-oriented window manager.
-- Bryan "TheBS" Smith
Re:It's really quiet here... (Score:1)
Hell, it's nice to see a place that's not overrun by trolls...!
Anywaysss, emacs is nice, but it's an enviorment that scares the hell out of every newbie in the world... Maybe that's why I like it soo much *grin*
'course I think emacs under X is just disgusting. It makes me feel like the usability is gone... oh welps.
Re:[way OT] Linux & oldtimers (Score:2)
I started on Unix in '81, at the NYIT Computer Graphics Lab, which was sort of the predecessor of Pixar. At the time we had a lot of PDP-11 systems that were still running V6 Unix. There was no fsck. We had to check and repair filesystems using icheck, dcheck, ncheck, clri, and once in a while we had to use adb to reconnect orphan directories. So, an operator really had to understand the filesystem. We had an application that was stuck on V6 and eventually I back-ported fsck from 2.8 BSD to V6, and I ported the segmentation-based overlay loader to V6 for the Images paint system after we lost the source for our overlay loader. A lot of things were done backwards there.
I'm quite happy that the Debian systems I run have developed a good bit since the 4BSD system I learned in '81 or so. I don't compile things that the Debian folks have built for me, and I really enjoy the fact that they do most of the system administration I used to have to do by myself.
I wonder if the old Unix purists also use Morse code on their ham radios?
Thanks
Bruce
Window Maker will never be a desktop environment.. (Score:2)
all the apps you listed are not part of Window Maker, they are merely designed to work together with Window Maker, but their existance does not turn Window Maker itself into a desktop envirionment.
if the latter were the case then kwm would be the desktop environment, not KDE.
KDE is not and never has been a window manager either.
greetings, eMBee.
--
An environment is... (Score:3)
...whatever the hell you decide to define it to be.
:-)
That said, I think the key things that seperates GNOME, KDE, and CDE (and to a certain extent, OpenWindows and HP VUE) from the rest of the window managers is the concept of underlying services that facilitate communication between apps. In Windows, it's OLE (or COM or whatever they call it nowdays). In CDE, it's ToolTalk; in GNOME, it's CORBA (I don't know what it is in KDE).
You see this underlying communication in various ways: the most obvious is Drag-and-Drop between apps (or the desktop and apps). It also shows up in inter-app communication with documents (think Excel spreadsheet embeded in a Word Doc).
I'd almost consider WindowMaker an environment. It has most of the hooks that Enlightenment and Kwm have for their underlying services, and can work nicely in a GNOMEish or KDEish setup.
I think when people say "environment", they're referring to the whole shebang: backend libraries and daemons that provide Inter-app communication, a Window manager that uses those backend facilities, and apps that also are aware of the available functionality. Integration is the key here: all the parts need to be aware (and use) eachother, and not just be able to function next to eachother.
-Erik
My definition of a boombastic window manager (Score:2)
The Windowmaker Dock is a neat little app that's fairly well integrated with the window manager, but still basically separate in both concept and execution; you can run Windowmaker without it, and you could run it without Windowmaker (with a bit of work). The Clip is similarly separate, though its function (icon management) is specific enough to this window manager that it's really only useful as an adjunct to it.
From a programmer perspective, GNUStep is the real environment; it provides the API and a few other convenient commonalities for all those nice NeXTish tools (wterm, or the Windowmaker settings panel for instance). However from a user perspective, Windowmaker plus a tied-in desktop icon manager will pretty much constitute an "environment". In other words, it depends whom you ask.
Re:File-Oriented Window Manager? O-O Approaches? (Score:1)
Re:File-Oriented Window Manager? O-O Approaches? (Score:1)
What is GNOME? (Score:2)
Re:What is GNOME? (Score:1)