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
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
_
(_)
_ __ ___ ___ _____ ___
| '_ \ / _ \ / _ \_ / |/ _ \
| |_) | (_) | __// /| | (_) |
| .__/ \___/ \___/___|_|\___/
| |
|_|
Homepage: http://poezio.eu
Forge Page: http://dev.louiz.org/projet/poezio
Poezio is a console Jabber/XMPP client. Its goal is to use anonymous
connections to simply let the user join MultiUserChats. This way, the user
doesn't have to create a Jabber account, exactly like people are using
IRC. Poezio's commands are designed to be (if possible) like commonly
used IRC clients (weechat, irssi, etc).
Since version 0.7, poezio can handle real Jabber accounts along with
roster and one to one conversations, making it a full-featured console
Jabber client, but still MultiUserChats-centered.
In the futur, poezio should implement at a 100% level all XEP related to
MUCs, especially XEP 0045.
=======================
Install
=======================
You need python 3.0 (and the associated devel package, to build C modules)
or higher, and the SleekXMPP python library.
In the developpement version, you’ll need this fork of SleekXMPP
http://github.com/louiz/SleekXMPP.
The simplest way to have up-to-date dependencies and to be able to test
this developpement version is to use the update.sh script that downloads
and places them in the right directory.
You also need to compile some external C modules, to do this, just enter
$ make
you can then launch poezio with
$ ./launch.sh
or you can install it with (as root or with sudo)
$ make install
(`make uninstall' works, don't worry ;))
you can now simply launch `poezio'
You can edit the config file (~/.config/poezio/poezio.cfg by default)
or data/default_config.cfg (if you want to edit the config before the
first launch). The default config file is fully commented.
Please, see the online documentation for more information on installing,
configuring or using poezio:
http://dev.louiz.org/project/poezio/doc
If you still have questions, or if you're lost, don't hesitate to come
talk to us directly on our Jabber chat room (see Contact section).
Please DO report any bug you encounter and ask for any
feature you want.
=======================
Authors
=======================
Florent Le Coz (louiz’) <louiz@louiz.org> (main developper)
Mathieu Pasquet (mathieui) <mathieui@mathieui.net> (developper)
=======================
Contact/support
=======================
Jabber ChatRoom: poezio@muc.poezio.eu
Forum: http://dev.louiz.org/project/poezio/forum
Report a bug: http://dev.louiz.org/project/poezio/bugs/add
=======================
License
=======================
Poezio is Free Software.
(learn more: http://www.gnu.org/philosophy/free-sw.html)
Poezio is released under the zlib License.
Please read the COPYING file for details.
The artwork logo was made by Gaëtan Ribémont and released under
the Creative Commons BY license (http://creativecommons.org/licenses/by/2.0/)
=======================
Hacking
=======================
If you want to contribute, you are invited on poezio@muc.poezio.eu to
announce your ideas, what you are going to do, or to seek help if you
have trouble understanding some of the code.
The preferred way to submit changes is through a public git repository.
But mercurial repositories or simple patches are also welcome.
For contributors having commit access:
This section explains how the git repository is organized.
The “master” branch is the branch where all recent development is made. This is
the unstable version, which can be broken, but we should try to keep it usable
and crash-free as much as possible (so, never push to it if you are adding a
*known* crash).
New big features that take time to be complete should be developped in feature
branches (for example the “plugins” or the “opt” branches).
If it’s a really long feature, merge the “master” branch in that feature branch
from time to time, to avoid huge merges (and merge issues) when you’ll have to
merge your feature back in “master”.
Merge your work in master once it works and is usable, not necessarily when
it’s 100% finished. Polishing and last bug fixes can take place in “master”.
Conflicts should be solved with *rebase* and not with merge. This means
that if two developpers commited one thing at the same time in their own
repository, the first pushes on the public public repos, and the other
has to pull before being able to push too. In that case, the second
developper should use the rebase command instead of merge. This avoids
creating unnecessary “branches” and visible merges.
On the contrary, when merging feature branches back to “master”, we should
use merge with the --no-ff tag (this makes sure the branch will always
distinctly appear in the logs), even if no conflict occured.
Finally, when a release is ready, we should merge the “master” branch
into the releases branch, then tag it to that version number.
If an “urgent” bugfix has to be made for a release (for example
a security issue is discovered on the last stable version, and
the current master has evolved too much to be released in the current
state), we create a new bugfix branch from the “releases” branch, we fix
it and finally merge it back to the “releases” branch, and tag it (and
we merge it to “master” as well, of course).
=======================
Thanks
=======================
= People =
Todd Eisenberger (todd@teisen.be) - Plugin system
Link Mauve - Code, testing
Gaëtan Ribémont (http://www.bonbref.com) - Logo design
Ovart - Testing
Koshie - Donation
Gapan - Makefile
FlashCode (weechat dev) - Useful advices on how to use ncurses efficiently
= Project =
Gajim - send_vcard method and common.py
|
