|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Thu Nov 29 2001 - 10:29:23 EST
Dear Calin, Yours is rather a knee-jerk reaction to the idea of a GUI for magic. However, I think of it this way: More and more Linux window managers appear by default in a "Windows emulation mode" where they mimic the appearance of the Windows desktop and task bar. A veteran UNIX user will likely reject this on principle, complaining about the poor saps who can't wean themselves off of the Bill Gates' Manifesto. And I do, and I gripe about it to my circle of friends. However, at the same time, I recognize that Linux has taken a not-insignificant chunk of the OS market away from Windows, and part of this has to do with converting some users by giving them what they already feel comfortable with. The rest of us don't have to take that path, although it is a good idea to be wary that one day, suddenly, XFree86 ONLY supports Windows emulation mode. But people are wary, and this has a near-zero probability of happening. So what does this have to do with Magic? The long-term survivability of Magic lies in its ability to compete with its closed-source rivals such as Tanner, Cadence, and Mentor Graphics for a share of the VLSI user base. If Magic is viewed as a "toy editor" (which I've heard said), it will lose that user base. If it loses the user base, it will lose the support to keep it viable. I first realized this when I started dealing with vendors other than MOSIS, and started coming across design rules mandating non-Manhattan geometry. I realized that magic was eventually going to be ignored altogether if it was not brought up to a level competitive with its non-open-source alternatives. This really annoyed me because I think Magic is fundamentally better than any other layout editor, and the things it lacks which causes people to think that it is not as "powerful" as the costware are largely superficial. Of course, the marketing folks at Tanner/Cadence/Mentor Graphics encourage the view that poor little open-source Magic is a toy editor, useful only for beginners in the classroom. One of the superficial things that adds to the impression that magic is just a toy is the lack of a GUI. Those of us who work deep in the code know that the lack of a GUI both streamlines the graphics processing and makes the core part of magic independent of the graphics environment it's in. A lot of people will reject Magic on the basis that when it came up, there was just this big empty window sitting there, and they were required to work through a large tutorial to learn how to use it, and there wasn't even an online reference manual. In other words, if you weren't forced to learn Magic in your first college VLSI course, you're not likely to pick it up on your own. A GUI with menus and tool buttons and integrated help windows and such will always be considered "unnecessary fluff" by veteran Magic users, but if it captures more users, then there is a greater chance that our development team is not here just trying to keep a dying patient alive. Okay, now that I got that off my chest. . . Pardon me for trying to be the Voice of the Open Source Revolution. > there is _a lot_ of space in the window not used.(in > the atachment you send). We used to make a little > window for commands and a very large window for layout > because we must see as much layout as possible without > using details. Hey, calm down. It's just an example. I agree that it could use some work on the "conceptual design" level, though. The best concepts for VLSI layout are 1) maximize your layout area, and 2) get yourself a 21" monitor. > TclTk is slower than pure X routines. > One of the good things about magic is that it can be > run on old, low memory machines (but in new versions > this is hard to achieve). I've always disliked Tk/Tcl. BUT. . . it's open source. Possibly open API, too. If you don't like it, suggest a viable alternative. At least the window-grabbing concept means that Tk/Tcl only affects response to input events, not rendering (all widget sets seem to want to redefine all the graphics rendering commands, thus slowing them down to unacceptable levels, but most don't *require* their use. Here, Tk/Tcl presumably would only deal with menus, buttons, and input events. So it only has to keep up with the user, which is not a great demand). Ghostscript/Ghostview works on almost exactly the same method: Ghostview forks off ghostscript and "grabs" its window, framing it and adding buttons, menus, etc. Ghostscript continues to run (and more to the point, render) at its usual rate. This setup doesn't prevent Ghostscript from running as an independent program (which I often do when testing snippets of PostScript code). > old machines don't have native OpenGL, and not every > university in the world has money to buy the latest > computer technology every year Remember that the graphics interface is independent of the rest of the program and can be chosen at run-time. OpenGL is just an option; the proposed setup should not disallow the X11 interface. By the way, I run OpenGL on my machine, which required a $120 video card and the purchase of a $99 X server, two years ago. Now you can get an OpenGL video card for < $100 and the X server for around $20. That's the nice thing about Linux. . . every university in the world *can* afford to have computer technology competitive with companies with large budgets for workstations and servers. > The company where I work didn't use magic for layout > because of the lack of a free hierarhical scematic > editor for linux. I sense that xcircuit is also being viewed as a "toy program". Although it depends on how long ago they made this decision. > Magic is allready [sic] a very fast layout editor. With > macros you can do great things at "a touch of a > button". Interesting choice of words. I would have said "at a touch of a key". Perhaps you are really a closet GUI proponent? ;) Regards, Tim
|
|
|
|