About NXDE¶

NXDE does not really exist. It is the name i use to refer to a loose collection of simple tools intended to help one maintain a Linux Desktop without using a Desktop Environment like KDE, Gnome or Xfce. In days of yore, one could do so easily by just not using one. But in today's times of wonder, that's often not quite as easy. One might want some of the flashy-shiny newfangled features like automagic mounting, Keyrings or whatnot. Then there is software which wont work without DBus, user session handlers or polkit. Not to mention a gazillion XDG environmental variables.

If you are in search for something that easily and automagically does all that and more for you, this is not what you are looking for. If you are looking for some helpers to easify this endeavour, you may be right here. But keep in mind that all of what is collected here as "nxde" really is just my personal collection of tools, right in the middle of a slow and unordered process of getting polished for general use. It will totally lack features, often the documentation will be all but a stub (if existing at all). Of curse it is buggy. But meh, it just works for me. If you make it work for you, send me a patch, and it will work for both of us.

Concepts¶

A core and interlinking part for all of this is the configuration. In general, all configuration should happen in to files. One system wide, and one per session. These configuration files should be nothing more than simple key=value stores.

Configuration file format¶

Dead simple:

aKey = someValue

Defines a key "aKey" having some value "someValue". The first = sign in any row mark the end of the key and the beginning of the value. Note that for key as well as for value leading and trailing white spaces are ignored. There is no masking. Don't use quotation marks, as they don't do anything:

"  my key    = bob"    =    "    some value with spaces      " 

Results in the key: " my key with the value bob" = " some value with spaces ". One can't have = in their keys.

Environmental variables¶

There are a few variables crucial for NXDE. They are oriented in style some common XDG variables:

• $NX_DESKTOP_SESSION
  The name of the current Session. Should be a shell-safe string.
• $NX_CONFIG_HOME
  By default: $XDG_CONFIG_HOME/$XDG_CURRENT_DESKTOP/$NX_DESKTOP_SESSION
  This is where session configuration file is stored. Other session-specific configuration should be stored here too.
• NX_LOG_BASE
  By default: $XDG_DATA_HOME//$XDG_CURRENT_DESKTOP/$NX_DESKTOP_SESSION/log
  Here at NXDE we like logs. Because we are buggy. Logs are helping. Log all the things!

Configuration files¶

There are two main configuration files. One is the system configuration in /etc/nx/system.rc. The other is the (user) session configuration in $NX_CONFIG_HOME/session.rc. Anything part of nxde should store its configuration in these files. Except when it has a shitload of configuration, then it should use another configuration file (maybe even in a different format), and just store the files location here.

Sessions¶

Nxde sessions are sets of user configurations. What the user makes out of that is up to said user. For example, maybe said user usually uses dwm, but for reasons sometimes wants to use Openbox. Then he can have different setups for both (and different logs!).

Decisions¶

Nxde tries to be simple and minimal, yet configurable and extensible. And especially, replaceable. Every part of nxde should be easily replaceable but some other thing doing the same or similar. Thus:

Be minimal, be replaceable¶

Whatever you do, try to do only one thing. Maybe two if you really have to. It is said that specialisation is for ants. Good. Be an ant! If anything, nxde should be an anthill. No ant is irreplaceable. Be effective and efficient. And make it easy to be replaced. Avoid dependencies, especially heavy ones.

Programming languages¶

Currently everything is either written in C or Bash. Other languages may be acceptable too, but here are some general rules:

• Scripting languages are only acceptable for one-shots. That is, everything what is started, does something and ends. It may have user interactive parts, if the interaction is also of the short do-and-done kind.
• Compiled languages have to be compiled to native machine code. No runtime environments allowed.
• All kinds of libraries have to (usually) be distribution packaged. It does not matter if certain libraries are not packaged in certain distributions. But if most or all libraries are distributed via other means (like npm), the language is disqualified.
• The language may not be ultra heavy. This is a rubber rule.

Naming scheme¶

Shit should start with "nx".

Documentation¶

Documentation is fucking important. Always provide some. Please?

• Man pages for every program and every C-library function.
• In-code-documentation whenever one has time to do so. Please!
• Decent READMEs.
• TODO lists

Attitude¶

• We do things the way we do because we want to. Your way is not better. Neither is our.
• "Thing" is not better than "other thing", no matter how much you like it. It may be better suited for something, though.
• Especially: "New" is not by itself better than "old". And vice versa.
• For us, "ease of use" is more important than "easy to use"
• Looks may be deceiving. In UX more than as much as everywhere else.
• If "Thing" is not important to you, it still may to someone else.
• Efficiency is not devaluated by cheap CPU.