Slashdot Mirror

Sure. Just about any UNIX desktop environment is as flexible as LiteStep. Roll your own...don't feel like you just need to use KDE or GNOME or something like that. I've got a rather nice desktop with sawfish, the sawfish pager, all status information being shown via gkrellm, and programs launched via the keyboard using xbindkeys. No GNOME or KDE flavoring necessary.

AfterStep is probably the closest in functionality to LiteStep, but I personally prefer Enlightenment if you're looking for flash, Sawfish if you're looking for functionality, and Black Box if you're looking for speed.

Steps in roll-your-own:

Choose a base desktop environment (keep in mind that you can just mix and match bits of them...I used to use the GNOME panel without the rest of GNOME, and a roommate uses GNOME apps with the KDE environment):
None
GNOME
KDE
ROX
foXdesktop
Perltop
Equinox
XFce
Once you've chosen a desktop environment (or the lack of one), and possibly removed the parts of it that you don't like (with GNOME, I wholeheartedly suggest trying it without Nautilus, possibly without anything but the panel), then you get to choose a dock. Your current desktop may or may not include a dock/panel/wharf.

If it doesn't, icedock provides an environment-independent wharf for the afterstep-style wharf system -- swallowing apps.
gkrellm (seems to be currently down) makes for a nice status-monitor style dock.
Or you can make your own impromptu dock...I've built them before by starting xload and xlock with proper geometry arguments to stack them on top of each other, and having sawfish make the windows sticky and slap 'em at the edge of the screen.
Now a window manager. There are so many of these that I'm not going to list them all. I'll mention a few notables:
sawfish is a fairly fast, *extremely* flexible (everything's written in lisp, much like emacs) window manager that uses gtk. Currently GNOME's default. I love this thing, but it doesn't come with a pager, so you either need to use a base desktop environment with a pager or use spager.
enlightenment is, at least until the next major release, still a window manager and not a desktop environment. Lots of emphasis on eye candy.
ion, a novel window manager that's designed to be managed entirely with the keyboard and never overlap windows.
blackbox is what I'd suggest if you needed a fast environment that still looked nice.

Most WMs support launching programs with given key combinations. I'd advise against this. The excellent XBindKeys is window-manager independent, quite capable, allows you to kill off your window manager and still use keys to start programs, etc. Plus, there's a nice benefit to using a different program than your window manager to launch programs. If you never launch external programs with your WM, you can renice -10 `pidof sawfish` or whatever your window manager is. Making your window manager (and X) meaner with respect to CPU scheduling makes for a much more snappy environment when edge flipping or the like. Sure, it might take a sec for the mozilla windows in the background to finish redrawing when I flip to a new desktop, but in the meantime I can do my work without waiting around for them.

The reason you don't want to make your WM meaner if you use it to launch programs is that then all the programs will also be equally mean.

Decide on the Big Four applications of any X desktop. Text editor, web browser, file manager, and terminal emulator.

Text editor:
I can't possibly cover this holy war here. My personal preference is xemacs, which is a bit of a learning curve for new users from Windows, but well worth it in power in the long run. You may want something that meshes more with the rest of your chosen desktop environment.

Web browser:
Just because KDE uses Konqueror and GNOME uses galeon by default is no reason to stick with those. Of course, you also can use either Konq without KDE or galeon without GNOME. You're rolling your own environment!
mozilla is now (after years of work) a good web browser. Big, still slow and still RAM-hungry, but usably so.
dillo Lightweight, very fast, pretty stable, very screen-space efficient...I can't say enough good things about dillo. If you use dillo as your primary browser, be aware of the fact that it has fewer features than the large browsers, that it doesn't currently (without a patch) support SSL, that it uses a UNIXish config-file preferences interface, and that it doesn't lay out nested tables or wrap text around images the same way Mozilla does. I keep Mozilla around as a backup browser, but dillo is so freakishly fast that it's hard to want to use anything else.
There are a few other browsers, but Konqueror, Mozilla, and dillo are (IMHO) the big GUI players on Linux. Amaya is a specialty browser, Opera (thanks to its MDI interface) doesn't seem to have caught on much in the Linux world, and Navigator 4.x is definitely on its way out the door.

File manager:
You may choose to simply use a command-line shell and the standard file utilities (cp, rm, ls) to do your file management -- I do, and I've tried hard to give other things a chance. But if you prefer to use a specalized GUI tool:
Konqueror can be used, even if you aren't using KDE (you do, of course, need the KDE libraries installed). Faster than gecko (the engine in mozilla and galeon) and almost as standards compliant, Konqueror has a lot of fans.
GMC is no longer being developed, but it's a reasonable lightweight interface.
Nautilus, the current official GNOME file manager is big, slow, RAM-hungry, and pretty. Not sure how well Nautilus works outside of GNOME (given that Konqueror can work outside of KDE, I would expect this capability of Nautilus).
ROX filer is a very fast little gtk file manager.
There are a lot of file managers out there, so I won't list them all, especially as I'm happy with just bash and the POSIX tools.

Terminal emulator:
GNOME and KDE both come with terminal emulators -- gnome-terminal and Konsole. I'm not very impressed with either -- they're both very slow and aren't available apart from their associated desktop environment. Konsole supports tabbed terminals, which some people may like. Both of them are fairly easy to configure, and are suitable for newbies to work with.
Multi Gnome Terminal extends gnome-terminal significantly with Konsole-style tabs and a set of other features. If you like gnome-terminal, you should probably consider using this instead.
Eterm is a RAM-heavy terminal emulator that was designed to look nice. For all the tinting and blending it can do, reasonably fast.
Aterm seems to be basically a less featureful, less memory-hungry Eterm-like terminal.
xterm is the reasonably fast not-so-pretty fairly RAM-hungry terminal that's used all over the world.
rxvt is easily my favorite terminal emulator. rxvt uses less RAM than anything else out there, and is incredibly fast. You can compile in only the features you want to use (which can, of course, also be disabled at runtime). Background images are supported, but emphasis is not much on eye candy. Very configurable. The biggest drawback is that configuration is through traditional UNIX methods, which may scare away some -- X resources, command line options, compile-time options.

Whatever you do, choose a set of software that you like, and remember -- your desktop environment is based on Linux, which means it should composed of exactly the parts that you like most. Have fun!

>I prefer Linux and Unix. Made by hackers, for hackers.

OS X was made by hackers too, but for normal human beings. Oh wait, that's Unix too! :)

>Not all computer users look like the folks in the advertisements where everyone is smiling

And they don't have to be. If you hate XP's day-glo interface, change it! Customizing OS X visually isn't as easy, afaik -- please correct me if I'm wrong. Using standard OS options (Folder Options and Display Preferences), you can make it look like Windows 95 if you so choose.

>Microsoft's disgraceful filesystem

NTFS 5 is disgraceful? How?

>and complete neglect of the command line

Cygwin. Services for Unix. MKS Toolkit. XEmacs. I believe even LaTeX is available, although I can't say how good it is since I don't use it.

Here's something random to think about: If Windows is all that bad, how come Windows NT is voted the most productive Java development environment on multiple occasions? These are Java developers, not the mom n' pop set (I know, some will say, they're just as bad :->), after all.

Like Tim O'Reilly said: ``I was recently looking over the shoulder of a very well-known perl hacker as he picked his way through the cascading Windows Start Menu to find a program he wanted to run...''

Maybe, just maybe, you should check out how `power' (couldn't think of a better word) Windows users operate without losing their minds everyday? Maybe buy a book that doesn't treat its readers like dummies?

I'm in the market as well and I found this article pretty helpful. To summarize, unless all you do is hack audio/video, it's a waste of money to get a P4-M w/ DDR memory, despite the faster bus, etc. Photoshop and AutoCAD tests were actually faster on the PIII-M.

I was leaning toward the Toshiba Satellite 5005-S504 until I read this. Running linux is a must, so now I'm considering a Dell Inspiron 8100.

Both of the above have UXGA (1600x1200) displays. I originally tought I wanted a Powerbook G4, but am not convinced that I can be productive on a 1152x768 display. My development environment looks like this: Left 1/3 of the screen is an Eterm running screen. Right 2/3 is XEmacs. A higher resolution means more code visible at a time and/or a more readable font.

Given that there is now a version of Vim for both Gnome & KDE, does it make sense for (X)Emacs to make the jump too? I know the origins of Xemacs are as much political as technical - but does it not make sense to try to branch off 2 versions of emacs into the 2 guis?

"One-click tabs for each emacs buffer would be nice."

XEmacs has had this feature since v21.something - it's present in 21.4, which is what I use.

If you want some graphics and multiple windows, X11 is actually not that heavy-weight, although Gnome and KDE are. Consider running plain X11 with "twm", "fvwm", or Oroborus. Of those, "twm" is ubiquitous, while oroborus is a little more modern. For minimal graphical web browsing, consider the "dillo" web browser, although it won't work on complex sites. You could also download Opera, although it's commercial.

XEmacs.

"The facts speak for themselves: we have tried very hard to work with the FSF. We have spent hundreds of thousands of dollars and several man-years on it...." - Jamie Zawinski, March 4, 1993.

And unless you believe GPL programmer time is completely valueless, that $1 million figure has easily been surpassed by almost every program you use over the course of your day.

here

I've beein using Xemacs now for a long time, really back when it was Lucid Emacs.

My understanding (most likley quite flawed) is that XEmacs is developed more with GUI's in mind, and GnuEmacs is more pure-text oriented - at least in any particular incarnation thus far when I've tried Xemacs and Gnu Emacs, XEmacs always seemed to be a bit better integrated into whatever wnvironment I happened to be working in.

For the last few years I've been using NT as a primary development machine, but soon I hope to be able to return to a proper UNIX environment. I guess I'll have to re-visit Xemacs and GnuEmacs then to see for myself which I like better.

I just re-read XEmacs vs. Gnu Emacs which I find to be a pretty fair assessment of the situsation. My understand was fiarly on-target, but there are also other reasons (like the package system) that are pretty good points.

I would like to see somewhere an outline of what Gnu Emacs now has that Xemacs lacks! That's the only unfair aspect of that page.

Ahem:

http://www.xemacs.org/Download/win32/

XEmacs already has native win32 widgets, if you prefer.

There has been a serious flame war raging for almost a decade about gnu emacs and (gnu) Xemacs (formerly lucid emacs).

To summarise, undisputed (I hope) facts only to avoid flames.
- RMS stopped developing emacs and appointed someone to develop it.
- The company "Lucid" wanted to use emacs 19 in conjuction with their product, but it wasn't finished, so they paid the developer to work on emacs full time.
- RMS decided that it was time to take control back from the emacs developer and wanted to approve every line of code, but his schedule wouldn't allow him to do that in a timely manner.
- The emacs developer and lucid (who put a few more people onto emacs, under control of the developer) pushed ahead.
- RMS appointed a new developer for emacs, and the code forked.
- A philosophical argument between people at lucid (who wanted an emacs 19 with a certain feature set - like using X, and wanted it ASAP) and RMS ensued. Various and numerous comments were made.
- Offers of a merge were made by both sides, but major features that would have to be scrapped (like being able to use X in that release) and management style have kept the majority of the code apart. Some features have been merged on both, which everyone agrees is a good thing.
- Both projects are GPLed, you can get the source of both and modify them as you wish. Aparently the copyright of both is held by the FSF, although one party believes there is some issue with "legal papers". The other party, not having written the GPL, assumed that it meant what it said, and that copyright still remains with the FSF.

There is some info about the history of (gnu) Xemacs and gnu emacs from both sides here, with an interesting quote from RMS, paticularly since ALL of XEmacs was written under the GPL and is available under the GPL.

No flames please, if you disagree then read the source material, become enlightened, and carry on a sensible conversation with one of the two parties that care about the issue.

Could someone with experience explain the difference between Xemacs and gnu emacs??

Well, I could point out that image support and colors on TTYs were in XEmacs a long time ago (I still have a machine with XEmacs 20.4 on it, which has both...) but that might start up another "frank exchange of views" so I guess I'd better be pusillanimous instead.

To be more succinct: they're different, based on the fact that the different development teams have different priorities. There are features that come in both directions, but IMHO they tend to show up on XEmacs first.

If you start a fork of a web browser project .... For nothing more than ego points, by giving the false impression you set out the goal and started from scratch

What I thought was obvious, is that if a developer wishes to go in a different direction then they can take the code and fork it. They are then responsible for updating the forked code - effectively they "own" that branch, since they control what happens to the code in the branch. An example of a code fork is XEmacs & GNU Emacs. Both can run under X windows, so the X just denotes that it is different, and that a group of developers wished to fork the code.

Those are big shoulders you're standing on--praise them

But burying them and claiming the world starts at your feet is wrong.

And the name of it? Emacs/XEmacs.

Now, don't get me wrong, I'm not a mindless Emacs zealot. I happen to think that Vi and Emacs are both (gasp) pretty neat. I was introduced to Emacs a year or so ago, and decided that it would be in my best interests as a hacker to make myself learn it. I'm still in that process, but so far it's paid off tremendously.

The power of Emacs is in the amazing integration of it's various extensions. As an example. Right now, I'm editing a perl script. At the bottom my screen, the "modeline" says this (abbreviated):

XEmacs: PasswdFile.pm 'set_up' S0 (CPerl ARev DCln Avoid Font Fill Abbrev)----L11--C0ll

Let's go through those codes one at a time:

• 'set_up': this is an indicator provided by an extension called function-menu that tells me which function I'm editing. The same extension also creates a menu of functions in the current file. It's completely seperate from any language-specific editing mode; and apparently uses a generic library to determine what functions exist in the current file. This means the extension itself doesn't have to change to be able to recognize functions in a new language.
• S0: This tells me I'm on screen zero. It's provided by an Emacs screen-management extension that works independently from (but seamlessly with) all other loaded extensions.
• CPerl: This says I'm in CPerl-mode, a sooper-dooper Perl code editing mode. It provides all sorts of handy keyboard shortcuts and auto-formatting, as well as the logic that other extensions use to customize themselves to Perl code (like how to tell a comment, so font-lock-mode can colorize comments, etc. properly).
• ARev: This means that the buffer is in auto-revert mode. Whenever another program modifies the file, it updates appropriately. This is completely seperate from all other extensions.
• DCln: This indicates dryclean-mode. The buffer will be stripped of extraneous tabs and spaces whenever it is saved. Again, this is independent from other extensions, and could be used on any type of file.
• Avoid: This mode moves the mouse pointer away from the text I'm editing, so it won't be in the way. Once again, completely independent of other extensions.
• Font: This means my code is being colorized, according to the patterns provided by CPerl mode.
• Fill: This means my comments will automatically be formatted to stay within the column limit I've set, and will be properly indented and have '#' characters prepended whenever a new line is started. This mode adapts itself to whatever language is being edited, and adds the appropriate markers to comments.
• Abbrev: This mode interactively expands abbreviations I've defined as I type them.

All of these extensions are independant from each other; they can be mixed and matched at will; and many can be used equally well in dozens of other types of files. Yet they all coexist happily in this one buffer, and even help each other. This is the kind of integration of little tools that the modern desktop needs; and so far, no one has attempted it since Emacs. All the many incompatible component technologies are based on the "fear and loathing" model - components are closed little black boxes, with their own little piece of the screen, and a few methods that they grudgingly make available to the outside world. This model, while very clean and attractive to OO programmers such as myself, doesn't lend itself to the kind of friendly, trusting, pervasive integration that Emacs features. Yes, all these extensions daringly allow other pieces of code view and even (gasp) change their "private members". The downside of this? Horrifyingly complex dependencies. The advantage? an amazingly well-integrated piece of software.

Until programmers can figure out how to provide this kind of pervasive integration within a modern GUI environment, the XPCOMs, Bonobos, KParts, etc. of the Linux world will simply remain programmer's tools, rather than timesavers for users. I believe that this article espouses a noble goal, but any hackers trying to implement it should look first to the past. They should remember this proverb, which I just made up:

Every good idea you have has probably already been coded, in Emacs Lisp

I'd like to point out how bad the I/O is in Lisp

LISP has had highly sophisticated I/O for many decades. This is why it's so widely used in parsers, text processors, editors and so on. The (Common LISP) I/O specification is here.

...and how hard it is to properly handle the myriad possible errors a program has to handle gracefully when working with humans

in fact, of course, LISP has a condition handling system at least as sophisticated as any other language. The specification is here.

Also, most lisp engines I've seen are interpreted (save for things like the Lisp Machine).

Originally LISP was a compiled language. However it is extremely easy to write a LISP interpreter in LISP, so most LISP systems area able to execute both interpreted source and compiled code. Furthermore, interpreted code can call compiled code and vice-versa. Documentation on the Common LISP compiler is here.

Only a few toy LISP systems lack a compiler.

Now this doesn't prevent you from doing very powerful very high level things with Lisp, but for the most part you can do them easier and faster with C

You really never have used the language, have you? If a programming problem can be solved easier by a good C programmer in C than it can by a good LISP programmer in LISP, it wasn't a problem in the first place. For example, I wrote a CASE tool for expert system design in LISP by myself in three months; it took a team of four programmers two years to produce the production C version of the same program.

Read about the pain Ben Wing, the architect of XEmacs, goes through, and you might change your mind. If it only helps one person, it's worth the effort.

XEmacs

--

The Ctrl-?? hotkey bug killed it for me. I read something on the nedit site about changing something in the X config to fix it but I never could cure this problem.

I use xemacs now.

I hope this problem can be resolved because Nedit really is a very nice editor

I was in the same position as you. At the time (6-9 months ago) I emailed the authors of UltraEdit and TextPad to ask about porting to linux. Both of them said that it is a possibility they are considering. However nothing's happened yet.

I've tried Nedit several times in the last two years and every time I end up with a bug where the Ctrl-?? hotkeys cease to function and start dropping odd xml type tags into the document. It does this intermittently but always eventually. Killed it for me.

Now I use xemacs - I just wish it would colour highlight more languages (jsp, xml, xslt in particular).

Bait swollen.

Actually there have been a few minor version bumps in the release history of the True One, namely because of jealousy of the even Truer One (M-x all-hail-emacs!). The current incarnation of It reached version 15 around 1984 (if my Info files tell the Truth, which of course they do). Apocryphal history has it that versions prior to 15 belonged to the ITS incarnation of the True One and are long forgotten in the hallowed halls of MIT.

My favourite version number scheme is that used by Prof. Don Knuth for TeX releases, but you'll have to do some research to know what I'm talking about...
--

I would gladly concur with you WRT to E, but you are terribly mistaken about sawfish. It's improved a lot since the first sawmill releases, and the pace of development is stunning (even if most of it are bug fixes).
And besides, you gotta love any piece of software that's customizable in Lisp (insert shameless plug to the One True Editor here...)
--

Moderators, please forgive me for veering offtopic, but this lad needs to be enlightened.

There are several alternative browsers on the market. They're all maturing slowly and some have even got features that Exploder doesn't already, despite Micro$oft's corporate feature bloating.

Konquerer, part of the KDE Project, is another good example of an underdog browser that's starting to take hold in the market. It's support for standards which make a viable browser are almost unmatched at the moment (in the alternative browser market).

Xemacs has a Browser called W3. It supports the majority of standards that make a viable Browser, and is written in Elisp, thus compatible with the Xemacs editor.

Of course, we can't forget Mozilla. It's the open-source version of Netscape 5. Probably the best browser out at the moment aside from Exploder/Win32, it runs on many platforms and is the most likely browser to take over the Exploder market share. It already enjoys a large market share in the UNIX world, just under that of Netscape 4.x. This thing supports nearly everything, including Alpha channels. Watch out for it.

You may want to read some of this article.
It deals a little with the issues of windows treatment of TCHAR, WCHAR.

Yeah, if he's so goddamn photogenic, I'd like to see salon.com explain this photo.

WRONG! If you run an Open Source project and you don't get contributed code assigned to you (and then forward it to RMS) then you DO NOT own that code. You do not have rights to distribute that code. All ownership resides with the contributor. This is why RMS makes a big deal out of getting people to assign their code to the Free Software Foundation. For instance, if you pop on over to http://www.xemacs.org and read about the differences between XEmacs and GNUEmacs, you'll see that one of the big reasons the XEmacs code has not been re-integrated into the GNU/Emacs is because some of the contributors have not (or perhaps refuse for philosophical reasons) assigned the rights to the Free Software Foundation. I'm not aware of an court cases involving open source software, so I'm *pretty sure* that the first one that comes about will go ALL ACROSS THE BOARD: The company that sues will stick to a strict interpretation of copyright law (i.e., the GPL is hogwash, and that it's not clear even if it was legal, whether the source code IN QUESTION was clean, and untainted by other licenses -- what if code under one license gets combined with GPL code? What license is it under? Can you prove that all the code in your tree is 100% GPL'd? I strongly doubt that any open source project can say this -- most don't keep any records of anything. LET ME CLARIFY: You probably *do not* have legal rights to distribute GPL'd code, for the same reason you probably *do not* have legal rights to distribute a shrink-wrapped binary version - No one has assigned the code to you. It doesn't matter if you're giving it away or selling it. For all you know half your contributions could be from proprietary code bases that programmers mistakeningly thought their company had no interest in...

• 4.1. A Single Makefile Is Too Big
  
• 4.2. A Single Makefile Is Unmaintainable
  
• 4.3. It's Too Hard To Write The Rules
  
• 4.4. I Only Want To Build My Little Bit
  
• 4.5. The Build Will Take Too Long
  
• 4.6. You'll Run Out Of Memory

Mutt seems to me to have the nicest of the text interfaces; it is somewhat unfortunate that it doesn't have huge support for the multiplicity of folders that a MH user grows to. (I've got 350 mail folders and 179MB of archived email, for instance.) For managing that, the user interface of EXMH combined with a variety of shell scripts are pretty much necessary.

A busy session with "make", "gdb" and some interactive source-level debugging can look like this screenshot. XEmacs parses gcc's output and with a click you jump right to the warning or error.

Best yet, you can do everything with your hands on the keyboard, or you can use the mouse if you feel like it. XEmacs 21, the new beta series, also has a very nice package management system. Select a package source from the Options/Manage Packages menu and it'll retrieve them from the net and install them--modes for every language known to man.

XEmacs.

Accept no substitute.

(Oh yeah, I am an HTML fascist. So what? you can make übercool pages with XEmacs too.)

If you want an IDE with syntax higlighting I recommend that you try XEmacs (or GNU Emacs). Hairy syntax highlighting, automatic configurable code layout, RCS/CVS revision control, diff/merge interface, tags searching, compiler interface, debugger interface, it's all there. When you cone to write documentation it's the best tool there is (even Neal Stephenson says so, so this must be true). It's got a vi emulation mode if your fingers are wired to the hjkl keys. M-x 1000 praise-emacs! Flames to alt.religion.emacs.