My screen gamma is actually set to somewhat low values. The thing with dark environments is that you then don't want to get an heart attack every time you switch to a browser window for instance. Or have the rest of the workspace be flooded with white from one of the opened windows which happens to be a browser window or a pdf reader.
The thing in the end is that YMMV. You'll always have to experiment with what will suit you better. For me, my eyes demand low contrast in darker environments. Too much contrast with a dark background and I invariably feel tired, and suspect even gain migraines. I also cannot concentrate on the screen so well. Under brighter settings, you want to do the exact opposite and increase contrast (sensibly, of course) by your choice of colors and how much you wish to saturate them.
The rule of thumb is more or less, like this:
Dark environments enhance differences in color (saturation and hue), while brighter environments tend to hide them. As such, you can reduce contrast more effectively without disabling your ability to discern colors and their differences. It's a pleasant paradox when you realize that a dark environment actually allows you to choose from a much wider palette of colors.
Try it. Place two very similar colors swatches with just a slight change in hue or saturation in a white background, and then in a black background. Spot the differences.
Huf! Where should I start? That's a book Yarin.Quote:
If I may: What do you like so much about SlickEdit? i.e., what does it do/have that you can't live without?
The immensely rich scripting language that allows you to change nearly every aspect of the IDE and add new functionality to it? The best gdb GUI in the market? The powerful search features that allow you to do syntax-based searches, Code inspection tools until recently weren't seen anywhere else but that were already in SlickEdit like (symbols definition and declaration, etc...)? The nearly flawless Context Tagging, while other editors where always coming up with their own broken versions of the broken InteliSense? The Keyboard emulations that allow you to use it as if it was Visual Studio, or CodeWarrior, or Emacs, or vim, or...?
And the little things everywhere around this immense editor that supports 60 programming languages out of the box, doesn't require you to install a virtual machine and a legion of plugins and complex interdependent systems, and all for a fraction of the disk cost of a Visual Studio or an Eclipse. There's so much to explore in SlickEdit that I'm still learning things today. Especially in the imensely powerful Slick-C scripting language.
And I just like it.
I like vim a lot, but for larger projects I tend to use kate and kdevelop. I highly recommend both if you ever install the KDE libraries. (NB: I have more than 40 GB in my / partition alone so I can afford the space. :) )
I use KDE most of the time, although looking at your current setup I don't think it's the sort of thing you would like. But if you ever try it, the single best thing about KDE 4 (if you have compositing working) is the ability to zoom out and see all of your desktops with all of your windows at once. :)
Do you use any kind of version control system for your personal projects?
Yeah, there are a few key applications that will eventually force me to install enough of the KDE libraries in order for them to run. Don't really have an issue with that other than keeping a watchful eye on my disk space.
As for my VCS... my head is a mess dwks. I honestly don't know what to do:
I use SVN for my personal projects. Just doing what I did in Windows. However Arch Linux community projects are heavily centered around git (whether this is actually needed or not). They have quite a few git trees with improved of fixed versions of upstream software that I wish to use and am not inclined to wait for upstream to incorporate the changes, neither I can expect them to be package (Arch mission statement doesn't allow for these trees to be packaged and moved to the official repositories. Only upstream sources can be).
So I do plan to eventually learn about it too. But I'm honestly not looking forward to it. I will almost certainly never be involved in projects that justify any of gits advantages. My requirements for vcs have always been simple. Even when working in a team in Windows. I don't appreciate git's complexity, lack of documentation and >100 binaries approach to vcs. This because of my modest requirements, but also because I never liked the idea of a vcs to be almost as difficult to learn as a programming language. It's exactly the type of tool I want to be out of my way. I prefer to spend my time doing code than digging around an unfriendly vcs.
I was a lot more interested in Mercurial for my distributed vcs needs (if I ever need distributed vcs). But guess I will have to pass on that. Until at least I find a project I wish to be involved or want to keep on my machine that uses Mercurial. And then... on to learning a 3rd vcs. This is really the part of coding I enjoy the least. There's nothing in Linux that annoys me more than this mess of vcs's (all with considerable adoption, which makes them hard to ignore).