ranger - mirror of ranger - a simple, vim-like file manager

	Commit message (Collapse)	Author	Age	Files	Lines
*	Added version info to examples	hut	2013-03-01	1	-0/+3
\|
*	examples/README: add instructions on how to install plugins	hut	2013-02-13	1	-0/+3
\|
*	removed options.py, improved plugins. UPDATE YOUR COMMANDS.PY	hut	2012-12-04	1	-1/+1
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	Previously, you could change settings in both rc.conf and options.py. With this commit, options.py is deprecated and you are encouraged to use rc.conf to change settings. I chose to do this because it is more elegant to use a simple list of ranger commands for configuration rather than a python file with lots of magic around it and potential syntax errors for inexperienced users. The existing "set" command doesn't evaluate python objects anymore, instead it always takes strings and converts to the proper type automatically. This means that the old set command will not work anymore and you have to update your commands.py if it still uses the old definition of the "set" command. This is how to convert your options.py: old way, in options.py \| new way, in rc.conf ---------------------------+------------------------ show_hidden = False \| set show_hidden false sort = 'basename' \| set sort basename column_ratios = (1, 5, 3) \| set column_ratios 1,5,3 For backward compatibility, you still can use options.py, but you get a warning when you start ranger. You can pipe stderr to /dev/null to silence the warning, or just move your stuff from options.py to rc.conf and plugins and delete the options.py. Finally, to extend ranger, which you previously could do through monkey-patching in options.py, you should now use the plugin system. This was an experimental, undocumented feature of ranger for some time, but this and the following commits will imrpove and document it. You can simply move all the monkey-patching code from options.py to a *.py file in ~/.config/ranger/plugins/.
*	added the examples from the man page to the examples directory	hut	2012-08-06	1	-0/+2
	I guess a whole directory for examples scales better than having them in the man page.

Colorschemes ============ This text explains colorschemes and how they work. Context Tags ------------ Context Tags provide information about the context. If the tag "in_titlebar" is set, you probably want to know about the color of a part of the titlebar now. There are a number of context tags, specified in /ranger/gui/context.py in the constant CONTEXT_KEYS. A Context object, defined in the same file, contains attributes with the names of all tags, whose values are either True or False. Implementation in the GUI Classes --------------------------------- The class CursesShortcuts in the file /ranger/gui/curses_shortcuts.py defines the methods color(*tags), color_at(y, x, wid, *tags) and color_reset(). This class is a superclass of Displayable, so these methods are available almost everywhere. Something like color("in_titlebar", "directory") will be called to get the color of directories in the titlebar. This creates a ranger.gui.context.Context object, sets its attributes "in_titlebar" and "directory" to True, leaves the others as False, and passes it to the colorscheme's use(context) method. The Color Scheme ---------------- A colorscheme should be a subclass of ranger.gui.ColorScheme and define the method use(context). By looking at the context, this use-method has to determine a 3-tuple of integers: (foreground, background, attribute) and return it. foreground and background are integers representing colors, attribute is another integer with each bit representing one attribute. These integers are interpreted by the used terminal emulator. Abbreviations for colors and attributes are defined in ranger.gui.color. Two attributes can be combined via bitwise OR: bold | reverse Once the color for a set of tags is determined, it will be cached by default. If you want more dynamic colorschemes (such as a different color for very large files), you will need to dig into the source code, perhaps add an own tag and modify the draw-method of the widget to use that tag. Run tc_colorscheme to check if your colorschemes are valid. Specify a Colorscheme --------------------- Colorschemes are searched for in these directories: ~/.config/ranger/colorschemes/ /path/to/ranger/colorschemes/ To specify which colorscheme to use, define the variable "colorscheme" in your options.py: colorscheme = "default" This means, use the colorscheme contained in either ~/.config/ranger/colorschemes/default.py or /path/to/ranger/colorschemes/default.py. Adapt a colorscheme ------------------- You may want to adapt a colorscheme to your needs without having a complete copy of it, but rather the changes only. Say, you want the exact same colors as in the default colorscheme, but the directories to be green rather than blue, because you find the blue hard to read. This is done in the jungle colorscheme ranger/colorschemes/jungle, check it out for implementation details. In short, I made a subclass of the default scheme, set the initial colors to the result of the default use() method and modified the colors how I wanted. This has the obvious advantage that you need to write less, which results in less maintainance work and a greater chance that your colorscheme will work with future versions of ranger.