[Blink] New Blink Qt release 0.2.0 for Microsoft Windows
dan at ag-projects.com
Fri Nov 12 17:09:32 CET 2010
On 12 Nov 2010, at 16:23, François Delawarde wrote:
> On Fri, 2010-11-12 at 14:31 +0200, Dan Pascu wrote:
>> Anyone should be able to contribute a feature. Blink is an
>> project. The only requirement for the code to be accepted is to be
>> well written and maintainable. If someone needs a feature that's
>> important to them but it's not on our roadmap, they can contribute
> Nice idea, sounds hard but I can try to look into it. Can you give me
> hints to find some API documentation for me to read?
You may be interested in the python-sipsimple API (you can find
documentation about it here):
You'll need to implement the REFER method in order to support call
transfers. After that REFER needs to be used to implement the call
transfer in blink and some way to initiate the call transfer needs to
be designed for the UI.
There is no API documentation for blink as blink is an application not
a library/API to be used by other software. So the only blink
documentation has, is its code, which I'd say is pretty well organized
and should be easy to dig into (the blink-qt code I mean).
> Also, if someone develops a feature, must he port it to Blink Cocoa if
> only interested in Blink QT?
No. It will be ported eventually, either by us if it is
straightforward, or by someone who is interested by the same
functionality to be available on OS X.
We do not impose restrictions on what a contributor should implement.
That's up to them. We only decide if something will be included based
1. How useful a feature is for other people.
2. The code that adds the feature must be well designed. The design
should be clean, simple and self contained, avoiding complex
dependencies on other parts of the code as much as possible. The code
should be self documenting (well named classes, methods, variables
that help understand what they intend to do without resorting to
comments or external documentation).
3. The code must follow the coding conventions already in place in
blink, regarding naming conventions, spacing, etc. We mainly use
python's pep8 for our coding style in python and pep7 for the C code
in case there is a python extension involved. They are available here:
It would be good to discuss design with us early so we can find a good
approach and avoid multiple costly iterations later. Also follow the
coding style in order to avoid similar multiple iterations before the
code is admitted.
More information about the Blink