# Doxyfile 1.8.11 # This file describes the settings to be used by the documentation system # doxygen (www.doxygen.org) for a project. # # All text after a double hash (##) is considered a comment and is placed in # front of the TAG it is preceding. # # All text after a single hash (#) is considered a comment and will be ignored. # The format is: # TAG = value [value, ...] # For lists, items can also be appended using: # TAG += value [value, ...] # Values that contain spaces should be placed between quotes (\" \"). #--------------------------------------------------------------------------- # Project related configuration options #--------------------------------------------------------------------------- # This tag specifies the encoding used for all characters in the config file # that follow. The default is UTF-8 which is also the encoding used for all text # before the first occurrence of this tag. Doxygen uses libiconv (or the iconv # built into libc) for the transcoding. See http://www.gnu.org/software/libiconv # for the list of possible encodings. # The default value is: UTF-8. DOXYFILE_ENCODING = UTF-8 # The PROJECT_NAME tag is a single word (or a sequence of words surrounded by # double-quotes, unless you are using Doxywizard) that should identify the # project for which the documentation is generated. This name is used in the # title of most generated pages and in a few other places. # The default value is: My Project. PROJECT_NAME = "Profanity C Plugin API" # The PROJECT_NUMBER tag can be used to enter a project or revision number. This # could be handy for archiving the generated documentation or if some version # control system is used. PROJECT_NUMBER = # Using the PROJECT_BRIEF tag one can provide an optional one line description # for a project that appears at the top of each page and should give viewer a # quick idea about the purpose of the project. Keep the description short. PROJECT_BRIEF = # With the PROJECT_LOGO tag one can specify a logo or an icon that is included # in the documentation. The maximum height of the logo should not exceed 55 # pixels and the maximum width should not exceed 200 pixels. Doxygen will copy # the logo to the output directory. PROJECT_LOGO = # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path # into which the generated documentation will be written. If a relative path is # entered, it will be relative to the location where doxygen was started. If # left blank the current directory will be used. OUTPUT_DIRECTORY = # If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub- # directories (in 2 levels) under the output directory of each output format and # will distribute the generated files over these directories. Enabling this # option can be useful when feeding doxygen a huge amount of source files, where # putting all generated files in the same directory would otherwise causes # performance problems for the file system. # The default value is: NO. CREATE_SUBDIRS = NO # If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII # characters to appear in the names of generated files. If set to NO, non-ASCII # characters will be escaped, for example _xE3_x81_x84 will be used for Unicode # U+3044. # The default value is: NO. ALLOW_UNICODE_NAMES = NO # The OUTPUT_LANGUAGE tag is used to specify the language in which all # documentation generated by doxygen is written. Doxygen will use this # information to generate all constant output in the proper language. # Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese, # Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States), # Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian, # Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages), # Korean, Korean-en (Korean with English messages), Latvian, Lithuanian, # Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian, # Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish, # Ukrainian and Vietnamese. # The default value is: English. OUTPUT_LANGUAGE = English # If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member # descriptions after the members that are listed in the file and class # documentation (similar to Javadoc). Set to NO to disable this. # The default value is: YES. BRIEF_MEMBER_DESC = YES # If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief # description of a member or function before the detailed description # # Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the # brief descriptions will be completely suppressed. # The default value is: YES. REPEAT_BRIEF = YES # This tag implements a quasi-intelligent brief description abbreviator that is # used to form the text in various listings. Each string in this list, if found # as the leading text of the brief description, will be stripped from the text # and the result, after processing the whole list, is used as the annotated # text. Otherwise, the brief description is used as-is. If left blank, the # following values are used ($name is automatically replaced with the name of # the entity):The $name class, The $name widget, The $name file, is, provides, # specifies, contains, represents, a, an and the. ABBREVIATE_BRIEF = # If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then # doxygen will generate a detailed section even if there is only a brief # description. # The default value is: NO. ALWAYS_DETAILED_SEC = NO # If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all # inherited members of a class in the documentation of that class as if those # members were ordinary class members. Constructors, destructors and assignment # operators of the base classes will not be shown. # The default value is: NO. INLINE_INHERITED_MEMB = NO # If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path # before files name in the file list and in the header files. If set to NO the # shortest path that makes the f
Colorschemes
============
Abstract
--------
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 logical 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:
~/.ranger/colorschemes/
/ranger/colorschemes/
To specify which colorscheme to use, define the variable "colorscheme"
in your options.py:
colorscheme = colorschemes.default
This means, use the (one) colorscheme contained in
either ~/.ranger/colorschemes/default.py or /ranger/colorschemes/default.py.
You can define more than one colorscheme in a colorscheme file. The
one named "Scheme" will be chosen in that case. If there is no colorscheme
named "Scheme", an arbitrary one will be picked. You could also explicitly
specify which colorscheme to use in your options.py:
colorscheme = colorschemes.default.MyOtherScheme
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.Scheme,
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.