Good evening fellow hackers,
the Tox-project[0] has recently come to my attention and I'd really
like to share it with you, as it is a project housing a great potential
to finally replace Skype for all your IM, VoIP and MoIP needs.
For everyone who is not yet familiar with it:
tox-core provides a C-API handling all the IM-related stuff
in the background (afaik even logging), making the development of
Tox-clients very simple.
There are numerous clients for Tox, the two most popular are Venom[1]
(GTK) and toxic[2] (ncurses). Apart from the cmake-build-system, the
former is good and has a decent user-interface.
The latter however, being the only CLI-client, leaves a lot to ask for.
This is the reason why I am bringing up this topic: If we start
discussing and developing a clean, suckless client for the tox-core by
now, it may just be ready when the tox-core reaches the aimed
feature-set for broad use in a few months.
First of all, I'll discuss the problems of the given toxic-client (and
why it's unfixable) before I bring in some suggestions for a new design:
0) It's GPL'ed (well, I learned to love MIT/X)
1) auto*hell
2) messed up ncurses-rendering (check it out, the flashing makes me
sick)
3) hardcoded nodes
Well, I'd probably send in some patches (like so often), but I just
can't live with the fact this client is missing out on so many
opportunities we haven't really seen before, and that's where my ideas
for a rewrite come along:
0) MIT/X license of course
1) Makefiles (!)
2) ncurses needs to be discussed. A design like we have with ii would
be very creative, but (imho) not very pleasant in everyday life with
a proper secondary interface on top of it.
Handling files for IO is great for writing IRC-bots and the like, but
most people would definitely prefer a small, clean and suckless
client for everyday use (and most probably, written in ncurses).
We discussed ncurses before and we might want to look into termbox[3]
for that matter.
3) allow the nodes to be specified in the config.h. this gives much
greater freedom to the user while still keeping it simple if you go
for the defaults.
4) *VoIP* on the terminal. I know of no CLI-IM-client implementing
VoIP-facilities when the protocol offers it.
Most of the time, using the CLI limits you in this regard and it's
definitely time to break those unnecessary handcuffs.
Tox-VoIP isn't ready yet (only call-auditing is still missing), but
from what I read in the code it handles the streams with SDL.
Combining this with Alsa should be feasible (maybe even over SSH).
5) *Videochat* on the terminal. This could be done by spawning a small
player-window (just like mplayer without X; SDL probably offers it),
allowing the window manager to do the window management, unlike
Skype, which tries to do it for you (and does a horrible job).
6) config.h details: As stated above, a list of nodes.
What I could also think of is a compile-time-definition of the
user-related-details, so you might just able to carry your
statically-linked toxic-client around on an USB-stick with all your
presets already set in the central config.h.
This could be a huge step over the common Skype-configurations,
which depend on the user moving the multitude of config-directories
around each time he switches computers if he wants to keep his logs;
Everything else (nick, friends, avatar) is handled on the servers,
which we haven't got here.
Additionally, the config.h of course would store the audio- and
video-devices to use and other things I can't think of right now.
7) The UI should be really simple. Unlike toxic, I would scrap the
prompt and just include a log-window.
Entering commands should be possible by pressing TAB or something
else in the chat-field, changing it to a prompt.
Looking at the toxic-code, a _lot_ of time has been spent on
implementing the prompt (read prompt.c).
This is one case of unneeded complexity which could easily be dealt
with by just handling it all in one field.
You can find a sketch of what I was thinking about right below:
## chat window ##
[friend's name] [status] [status message]
([call status] (...))
--------------------------------------------------------
chat log
--------------------------------------------------------
text field
--------------------------------------------------------
[log] [contacts] [chat1] [chat2] [chat3]
## log window ##
[client name & version]
([call status] (...))
--------------------------------------------------------
log
--------------------------------------------------------
prompt (it would directly jump into this mode)
--------------------------------------------------------
[log] [contacts] [chat1] [chat2] [chat3]
## contacts window ##
[client name & version]
([call status] (...))
--------------------------------------------------------
1 [friend 1] [status]
2 [friend 2] [status]
3 [friend 3] [status]
(...)
--------------------------------------------------------
special friend prompt for quick access
(tab-complete, number, w/e, ...)
--------------------------------------------------------
[log] [contacts] [chat1] [chat2] [chat3]
*tl;dr*: Please let me know what you think about this concept and if
you agree or see it completely different.
I worked on quite a lot of patches in the last few days to fix toxic,
but I just found it to be broken beyond repair (in suckless-terms).
It should be a good reference for implementing tox-core.
Releasing a client under the well-renowned suckless-name would
definitely bring in more trust into the Tox-IM-protocol, and, if it
turns out to be successful, in turn make the suckless-philosophy more
popular.
It was only coincidence that I heard of this great piece of software,
let's proceed and make something with it!
Cheers
FRIGN
[0]:
https://github.com/nurupo/ProjectTox-Qt-GUI
[1]:
https://github.com/naxuroqa/Venom
[2]:
https://github.com/Tox/toxic
[3]:
https://github.com/nsf/termbox
--
FRIGN <dev_AT_frign.de>
Received on Sun Mar 23 2014 - 21:33:29 CET