Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Silicon Graphics

What Happened to 5dwm? 38

Posted by Cliff from the anyone-still-interested dept.
CoolVibe asks: "Remember that project called 5dwm? It was supposed to give us free Unix users a Magic Desktop clone. The project seems to have died. What happened to it? Are there any mirrors? As far as I can remember, this project wasn't open source. Too bad, because if it was, we would have a MD clone. Anyone who remembers working on a SGI machine (I used to use an O2) probably has fond memories of the Magic Desktop for IRIX. If anyone from SGI is listening, how about porting that fantastic piece of work to Linux and the *BSD's?"
This discussion has been archived. No new comments can be posted.

What Happened to 5dwm? More

What Happened to 5dwm?

Comments Filter:
  • I don't mean to nitpick, but the correct names for the SGI desktop environment were either "Indigo Magic" (the older name) or "IRIS Interactive Desktop" (the circa-IRIX 6.5 name). Calling it "Magic Desktop" isn't technically right.

    Just dotting the i's and crossing the t's.

  • well, for one thing it kinda sucked (Score:4, Informative)

    by quinto2000 ( 211211 ) on Sunday October 27, 2002 @02:52AM (#4540371) Homepage Journal
    I've used it on an Indy machine (IRIX 6.5 or so) and while it's not terrible, it's also not terribly functional for today's desktop user. While it had some good ideas, they've all been expanded upon and are exhibited much better in most modern desktops. I'd use it over Windows 3.1, but not much else. On the Irix box, my desktop consists of a number of xterms and Window Maker :)
    • Indigo Magic had one thing that no other UNIX desktop that I've seen was ever able to provide: ubiquitous drag-and-drop on a level rivaling what you get with a Mac. If you had two programs that were written with Indigo Magic desktop integration code in them-- admittedly, these were few and far between-- you could drag something (say, a picture) out of one app to the desktop, then drag the icon from the desktop to a folder, then from the folder to the other app. It worked really well. Indigo Magic was (is, I suppose) really light on the eye candy but seriously strong on application integration.

      • You say "ubiquitous drag-and-drop", and then later that it works if you have two programs written with Indigo Magic desktop integration code in them which are few and far between. This is the same problem every Desktop has, Indigo is no better. KDE and Gnome both the capability to the same and more, if people would just use the "desktop integration code" in their apps. The unix desktop world would be a whole lot better off if we'd develop some common APIs for things like this. There's supposedly an XDND protocol, but why don't KDE and Gnome both use it and drop to each other? I always have problems with that.
        • You were correct, up to a point.

          Both KDE and Gnome use XDND and you can drag & drop. (Gnome also supports some older protocols but I believe it uses XDND even when you go between two Gnome programs).

          The problem is not the protocol, but the data being dragged. About the only things you can drag are text (and recently some url's). But in fact XDND has a type identifier very much like Windows for the type of data. In theory the ability to drag different types of data is identical in both systems. However I can list a few advantages Windows has:

          First and foremost is that they list in their header file a simple enumeration of types of data. Yes in many ways the set is stupid and based on 1985 technology (for instance URLs are not specified), but at least the list is there and easy to find. The Linux design suffers greately because the people writing XDND try to be correct and admit that somebody else probably knows how to select the data types better than they do. Unfortunately what happens is nobody does.

          Second, for some data types (particularily Bitmap) Windows has a simple method to get it on the screen. So an app that just wants to draw what was dropped on it and not think about it much, it is pretty easy. Compare this to X where it is a total nightmare to draw an image (again caused by engineers who don't want to risk doing it wrong and so only provide low level stuff that describes how the screen works). I would think if you had to do a different call for each letter to draw it you would not drag & drop text either.

          I am not sure what the problem is with the Xlib designers. I think a lot of it is paranoia about back compatability, and a lot of it is the inability to see that their interface is not understandable, and that an understandable and simple interface is much more important that the maximum-speed interface.

      • Never used NeXTstep, huh? Drag-drop, and Services too.

        NeXTstep had a marvellous integration and consistency which far surpassed anything else---esp. the Mac OS, and even Mac OS X (which is riddled w/ backwards-compatible Mac UI-isms which are execrable and excrutiating)

        William

    • Re:well, for one thing it kinda sucked (Score:4, Funny)

      by Neillparatzo ( 530968 ) on Sunday October 27, 2002 @04:13AM (#4540550)
      Vector-based icons were cool. And the little wheel that you could drag up and down to make them bigger... and smaller... and bigger... and smaller... and bigger... and smaller... and bigger... and smaller...

      Second thought, I lost so much productivity to IRIX. Good riddance.

  • Do we need yet another window manager (YAWM)? (Score:3, Insightful)

    by Bob Bitchen ( 147646 ) on Sunday October 27, 2002 @03:21AM (#4540442) Homepage
    I have fond memories of the Irix desktop but it wasn't so good that we need YAWM. There are enough to choose from now. Nostalgia isn't the right reason to choose a window manager IMO. The Open source community really needs to focus on fewer projects and make those projects that are popular robust, make them out-perform the alternatives and give them the features that are taken for granted in the mainstream OSs like MacOS X and Windows. Have a look at sourceforge sometime and you'll agree that things are spread too thin. Lots of projects that have never even released any files. Focus on making what's working now better instead of coming up with another new project will help us all.
    • Well, this project ( developing another WM ) might contribute little to OSS community but , it could bring back a lot of joyful memories to those who had been lived with it. So , IMHO , if there are people willing to spend some time on bringing it to Linux or *BSDs , let them do it and we're glad that they do so , and that's what the author's calling for.
    • Have a look at sourceforge sometime and you'll agree that things are spread too thin. Lots of projects that have never even released any files. Focus on making what's working now better instead of coming up with another new project will help us all.

      Too thin? Unfinished projects has little to do with being spread too thin, rather more a sign of lost interest. Choice is a good thing - innovation is found in it. Code is not difficult to produce, ideas are the difficult part. And the best way to generate more ideas is to start more projects. Some of them will finish, and some of those will be useful.

      Avoid the borg! There is no single right way.

    • Ah, nostalgia. It wasn't what it used to be, you know.
    • OSS does not need managers.

      I wrote a window manager because that's what I wanted to do and I was able to do it better than anyone else that's ever written a window manager (because I know what I want in a window manager and everyone else got it wrong when they tried). I don't care if you, or anyone, else finds my work useful - I posted the code because it doesn't cost me anything not to do so. This is my spare time and I'll spend it as I see fit.

      If you want me to write whatever god-awful financial database application you may consider useful for your business, you'll have to pay me because that's not fun. That's what I do at work - I write window managers and kernels at home because that's fun, and it's not as much fun dealing with the politics on other window manager projects.

      Whoever said that we need some ridiculous system to pander to newbies like OS X or Windows? FreeBSD does everything I want it to do and if there's a problem that bugs me, I'll write a patch. I don't give a damn about its commercial success because I'm not getting a cut. As long as it's still alive with people like me and I can still use it, I'm happy.

      If you're really worried about these issues, shut the hell up and write code. Don't come in to some project expecting to manage and direct it, because I don't take kindly to armchair managers.

      • >Don't come in to some project expecting to manage and direct it, because I don't take kindly to armchair managers.

        And while that attitude isn't bad, per se, it certainly is the major reason why you can't have any fun writing those applications at work (I'll let you work out the "reason why" part for yourself. It might be fun! I doubt your answer will be the same as mine!).
  • did you know that 4dwm was a enchancement to mwm? you can find mwm and information here [plig.org]. as a fellow sgi user (indigo2 and o2), i can say there isn't a great deal of difference between the two. compare:

  • Some comments (Score:3, Interesting)

    by CoolVibe ( 11466 ) on Sunday October 27, 2002 @05:08PM (#4543191) Journal
    yes, I'm the one that submitted this story. Here are some other things I found out:

    I also posted an article about this on Advogato here [advogato.org]. I got some replies on that, and one person attended me to here [dnetc.org] where you can find a copy of the 5dwm stuff.

    About the functionality of this thing, it's not just a WM. It's a desktop environment. If you ever worked on a SGI machine, you'd agree it was (well, arguably) the best damn internet workstation out there. Sure, KDE and Gnome fill in a huge gap here, but there is much to be learned from how the IMD is put together.

    I hope the people at SGI see this and decide to either opensource this thing, or to provide linux binaries. I know, it's idle hope, but a man can dream, can't he? I'd love to see this on my desktop at home.

  • Should copy the good stuff from 4DWM (Score:3, Interesting)

    by spitzak ( 4019 ) on Sunday October 27, 2002 @07:24PM (#4543831) Homepage
    I don't think we need another window manager, but having used Irix for many years, and then switched to Linux, there are a few things that it did that I really miss, and I seriously think they should be put into modern Linux window managers:

    One is MWM style raise/drag behavior. Even though I thought it was strange when I first encountered it, I quickly learned to use it, and it is obvious from trying to use modern systems how much superior it was. The rules were simple: the only thing that raised a window was a quick click in the window border. If you dragged or resized the window, it did not raise! Also (vitally important) if you clicked inside the window it did not raise.

    Basically if windows raise on clicks it makes it impossible to use overlapping windows. The real horror of today's designs is that nobody seems to realize this, and think all kinds of actually retro ideas ("tiled" windows, "dockable" windows, and "MDI") are "innovations" and not just work-arounds for this bug. If tiled windows were so great they would have been adopted from the Andrew system (or the first Windows systems) for the entire screen. The truth is that the human mind is not set up to deal with objects that change size based on stuff other than the contents of the objects, and this is very unfriendly and makes it hard to spacially locate things. The other scary thing is that every time this is proposed somebody says "but that will be user-unfriendly because it is not EXACTLY like Windows!!!". I believe these are the same Whiners who keep saying "Linux does not innovate".

    Another thing is to stop locking "parent" and "child" windows together. This is really the same complaint, but there are NO modern window managers that don't have this bug. What happens is that if you raise a child window, they raise the parent as well, rather than leaving the parent where it was. The parent/child relationship should specify an order but does not mean they have to be next to each other. Again this bug prevents overlapping windows, unless you make all of the windows children of some large and useless parent window.

    Also Irix's terminal emulator was a lot better. Especially the methods use to select text and end-of-line. On xterm, kterm, and gterm and the OS/X Terminal app I have to be really careful when trying to select text, and I almost always get it one character off on the end. For some reason the algorithim used by Irix worked perfectly.

    • Basically if windows raise on clicks it makes it impossible to use overlapping windows.

      Huh? I'm a long-time Mac user, and I'm trying to imagine what you're talking about. I think I follow you: click inside a window, it doesn't raise; resize or move a window, it doesn't raise; if you want it to raise you have to click on the border. I don't understand how these rules could even be convenient, let alone why this makes my Mac desktop impossible to use.

      One thing that does bug the hell out of me in some window managers is windows that raise on mouseover. Or have focus on mouseover, without raising.

      On the Mac, clicking on any part of a window (title bar, border, or content inside) raises the window and gives it focus. However, you can move a window without raising it or giving it focus by holding the Command key while dragging the title bar. In Mac OS 9 this only worked for windows belonging to the same application; Command-clicking the title bar of a window belonging to another application would raise it. This is fixed in Mac OS X.

      You also mention parent and child windows. I agree that the Windows 3.1 way of doing application and document windows was crap. On Mac OS 9, document windows are associated with an application, and one application's windows can be in front of or behind another application's windows, but you can't have a BBEdit window layered in between two Mozilla windows. On Mac OS X, windows aren't tied so closely to apps, and you can do just that. An application can be hidden though, which hides all of its windows - the easiest way to do this is Option-clicking on another application or on the desktop, to hide the app you were working in while switching to another app.

      The closest thing Mac OS X has to child windows is child dialog boxes, called "sheets", which are attached to their parents (they slide down out from under the title bar, pretty and animated, and they stay attached to the window, allowing you to continue with your work in other windows before dismissing the dialog if you need to).

      Anyway, sorry for rambling, but please explain yourself.

      • You have the explanation of the window raising correct. A simpler way is: there are exactly TWO ways of raising the window: *clicks* in the window border and any dead space that does not do anything else (such as gaps between buttons), and the program saying "raise this window". (in my ideal system at the low level in fact there is *ONLY* the program giving the "raise this window" command, but the toolkits would be written to give the impression to the user that the system raises windows when you click on dead area).

        The problem with clicking raising windows is that if you have two displays that are too big to both fit on the screen, you cannot work on both of them by overlapping them. Clicking in the lower one would raise it and obscure the upper one. This is not wanted because there is a good chance it will obscure information the user wants from the former top window (there is ZERO chance it will reveal information from the former bottom window because if the user needed that information they would have to raise the window to look at it before clicking on that window). The result is that people have been forced to "tile" the windows, resizing them and designing displays that are able to be resized (including changing the aspect ratio), when in fact people are much better at handling objects that act like real physical things where portions can be obscured, but the objects themselves do not change shape.

        This is extremely difficult to explain, there is a huge number of people (including me at one time) that don't see any reason to not raise windows when they are clicked on. However if you have worked with software designed for such systems (such as much 3D software used in visual effects) you would find out just how painful it is to use "tiled" systems. Imagine a program that wants to display a 1024x600 image and also a 1024x1024 graphical control at the same time, where the user often needs to click on both of them rapidly and very much wants to see what the results are in one of them based on changes to the other. This CANNOT be done in tiled systems.

        Even if you disagree with whether this is a good GUI idea or not, the truth is that in any system where the program has a "raise this window" call, there is absolutely no reason for the system to raise windows. That is because the program can do this call on the clicks and you get exactly the same behavior as you are used to, but now programs are at least able to experiment with the behavior I want. I don't think there is any possible argument against changing systems to work this way because current behavior is emulated trivially.

        "sheets" are much more similar to "modal child windows" that block interaction with the parent window. Since these are up for a very short time they usually have no time to get seperated from the parent or for the user to rearrange the windows, the bugs in the window managers (or designs like the Mac where you cannot seperate them) are not too painful.

        What I was talking about is "child windows" that stay up but still allow you to interact with the parent. In a properly designed system where all window-raising is left up to the program these are useless, but I can use them *somewhat* to solve the overlapping window problem, since they prevent the "parent" from raising above the child (in my example the image viewer is a child of the graphical control). The huge problem is that the program has to choose the order, and cannot change it (at least not with kludges that make the windows blink as they are destroyed and recreated), and the user cannot decide what order they should be in. The other problem is what I was complaining about: raising a child window raises it's parent (and all the other child windows of that parent). This makes overlapping windows useless even on systems that can be instructed to not raise on click, because you still cannot do some useful stuff (unobscure the child) without raising a window you don't want raised.

        I guess the OS/X equivalent are those slide-out trays, though they certainly don't solve my problem because you can only have one of these and the size is limited to the height of the parent window.

        I have used OS/X and I can say I am extremely pleased that they got rid of the "application windows stick together" behavior, like you mentioned. It is a tiny, tiny, tiny baby step in the right direction!

  • The Author of 5DWM (Erik Masson) has not been working on the project for a while. Since the last version was working quite well. Erik says that he is willing to bring it back online if there is enough interest. Check Tomorrow at http://www.5dwm.org [5dwm.org] for More Information. As we will reopen the Website to be /.
  • One of the things I liked about 4dwm was the ability to "iconize" a window (minimize it to a little icon you could drag around). I found this preferable to today's taskbars, because you could organize/group the icons.

    I have been looking for an open source window manager with this feature, but so far have not found any.

    • Iconization is a fairly fundamental and common window manager thing. I don't know how easy it is to configure something like sawfish to support this mode of operation, but it is generally the default for window managers like fvwm [fvwm.org], twm, or even mwm. I would not be surprised if many modern alternate window managers supported powerful ways of controlling icons and iconification behavior; I know fvwm does.

      • Thanks, I forgot about fvwm! I ignored it earlier because there were no themes that I liked, but I see things have improved a lot.

        Right now I'm using icewm - it's easy to configure and there is an excellent 4Dwm theme available for it - that's all I really ask =).
  • and I have no clue what it's called, or for that matter how to describe it too well.

    but there was this feature.. a small window that would display all your 'virtual screens/desktops'... say, you had four different screens, then on each screen it would display small versions of the windows you had open on each screen. Then, if you wished, you could move these small versions of each window amongst the 'virtual screens' by moving them in this small display from one of the squares which represented the one screen to the other.. would move the actual windows amongst the actual screens. You could also get to each screen by simply clicking on it's representation in the window. I'm sure it could do plenty of other things, but that's how I used it.
  • Indeedy, IMD is not dead (like some people here said). Eric masson mailed me, and better yet, he sent me screenshots. He's been working on it underground, and the IMD is looking pretty good. Also, sourcecode is going to be provided at that snazzy sourceforge place.

    Screenshots here:

Slashdot Top Deals

BLISS is ignorance.

Close