1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
This file describes my preferred coding style and how the code is
organized. It also contains a section describing how to add features
to ledd. Anybody who wants to contribute to ledd/gled/etc. should read
this file first.
General coding style
--------------------
I mainly abide to the coding style of the Linux kernel (see
/usr/src/linux/Documentation/CodingStyle for details) with very few
exceptions (I place the opening bracket of a function on the same line
as the declaration, ...). I also sometimes make longer functions if
they are trivial and doing some longer operation (such as parsing a
string). The most noticeable feature of the style is that the
indentation level is 8 characters. Read the Linux coding style for the
reason why.
Also, before _every_ function there must be a comment describing what
it does, returns etc. The only exception is when several functions
are doing approximately the same thing so the same comment could be
given to both. Then there is no blank line between the functions:
/*
* Do this/that... (of course, the comments are _supposed_ to tell you
* more than the function name... ;)
*/
int do_this(void) {
...
}
int do_that(void) {
...
}
/*
* Another comment...
*/
int blurb(void) {
...
}
ledd
----
This is supposed to be well-maintainable. The code is split into
several files, each of which deals with one thing. In the beginning of
each file is a short comment on what that file deals with.
Every function (both global and static) begins with the name of the
file they are in and an underscore (with the only exception being
main()). This way you can locate a function easily - led_set_all is in
led.c, for example. The function names should be describing, words
separated with underscores. The filename may and is recommended to be
used as a "word", as in parse_pipe_command() (in parse.c).
Adding features to ledd
-----------------------
If no too-fancy stuff is to be done (so that the basic blink and anim
types are enough), it is only a question of parsing the line. This is
done in parse.c. Say you want to make a "set xxx jump" command (where
xxx is the same kind of LED declaration as in all other "set"
commands) which takes two numerical arguments, one integer and one
float, and one string. You then add the function
static gboolean parse_set_jump(options *opts, gint type,
GSList *arglist, gchar *string);
in the place where there are similar declarations. Then add a line
into the parse_function_list[] struct. This would be:
{{"set","%s","jump","%d","%f","%s","%.",NULL},0,parse_set_jump}
The first part describes the line - first "set", then a string (the
LED definitions), then "jump", then an integer (both positive and
negative accepted), then a float, then a space-separated string and
nothing after that. These are parsed and placed in GSList *arglist
(with data types gchar *, gint *, gfloat *, gchar *, respectively). If
the "%." is omitted, then the rest of the line is passed to the
function in gchar *string. The third number - in this case 0 - is
passed in gint type. This is so that one function can handle several
types of strings, eg. set on/off/normal are all handled by
parse_set_constant. The LED list can be parsed with
parse_ledlist(opts,(gchar *)arglist->data) - see existing functions
for examples. The parse_function_list is parsed in order and when a
match is found, no further matches will be looked for.
All this is also shortly documented in parse.c.
The function can then rely on the data in *arglist being correct. It
can then modify the options *opts as it wills. It should not free any
data given to it, but, of course, free all the memory it itself has
used.
At some point I might do the same kind of reorganization for the fancy
stuff as I did for the parsing. Then adding new "cool" features should
also be quite straight-forward. The only question is that of the
priorities of the "cool features" to the LEDs.
gled
----
This is made using Glade (http://glade.pn.org/). The main file is
gled.glade (in the base directory). All not-made-by-glade stuff is in
main.c and callbacks.c. I have not even tried to make this as neat as
ledd. There are longer functions and poorer comments. You might,
though, be able to understand it if you try a little...
configure.in etc.
-----------------
These are attempted to be commented, but it's a total mess... This is
the first piece of software I've used autoconf/automake with and it
shows. I still don't master autoconf/automake... Maybe some day I'll
find time to clean them up too...
|
