Dear all (and especially all developers)

Expected an announcement of this from kysoh, but didn't see it yet and in order to avoid that we (read I ) create a mess, I decided to post this message.

A new driver has been put on svn. I've been told that this is going to be the base of the new middleware.
This version is not compatible with the old one and does not yet support TTS (due to licensing issues), so for regular users this is probably not too interesting yet (although you could read the docs and create programs already to use the new interface.
This version works quite well, but of course there are always some issues left. As Remi (sorry, still don't know how to enter accents ) has a lot of other things on his hand it is released as is.

I've been challenged (mostly by myself to improve the driver. However as others might also start to work on this I would like to at least report that I am doing this, and if possible arrange some form of collaboration.

I am not really sure how to arrange this. I've been involved in several other open source projects, but never initiated something like this.

I suggest that if you are interested in cooperating in this, you let me know one way or another (by posting in this thread, leaving me a message, posting to the mailing list, or trying to catch me on IRC #tuxdroid (where I am also eFfeM).

Issues that I have seen in the new driver for now are the following:

• I saw some code duplication (e.g. for handling left and right wing), which could be generalised
• the test program could be extended
• different api's (the current interface is C, not sure how easy/difficult it is to call from e.g. python. It might also be interesting to add a REST based interface on top of this.
• the interface to the driver is text based. Personally I would prefer a C-like interface as that offers better type checking. Then again I have been asked not to touch the existing interface. The solution I am thinking about is to split the driver into three parts:
  
  At he lowest level we have the functions to deal with the usb stuff (including transmitting the raw commands). This is mostly in usb.c
  Next we could have a layer which provides a C interface.
  On top of that we could have a layer that provides the current interface (and handles the text to C abstraction).
  

How do others feel about this? I appreciate your response

Btw: a few notes on the new driver:
this one is not http based any more. Instead it is a dynamic linked library that can be called directly from an application.
It should work on windows as well (but I never tried this).
If you want to use it, check it out from svn, build it, then build the test program.
For running first kill tuxd (and probably tuxosl as well). then start the test program

Some other things:
How do we best communicate?
- mailing list?
- a separate forum section?
- other ideas?

Enough ranting for now.
Let me know what you think about this.

FM

I saw with pleasure the starting of a new interest for the Tuxdroid developement
I don't have the time this weekend for talking (familly meeting ) But monday, I will answer to the posts of this weekend. I will talk with you about a way to organizing the developement.

Tuxdroid is still alive ! Héhé

yes it is.

I did an initial commit (added some changes in the test program to control the output and a usage function).

Didn't see the commit in CIA though. Is it possible for you to check?
Also do we want to post commits in the irc channel? Guess we need a bot for that.

I've committed a lot of changes.

I've went through all the files, making lots of changes mainly wrt layout.

Things I did are:

• remove unused include files
• sorted the include files by name (yeah, I know, I'm a freak)
  
• corrected indenting
• added { and } to if and for statements that were missing them (because they only had one statement). I've been bitten once too often by a macro in an if statement that expanded to multiple statements
• put { for if and for statements on a line on their own (sometimes this was done, sometimes it was not)
• some small optimisations and code changes
• and probably some more things I forgot
  

After doing this, the test program still works as expected.
I did see other places where improvements are possible. E.g. there seems to be quite some code that is (mostly) identical between spinning, mouth and eyes.
Also some of the scanning for tokens is done in the parser, some in e.g. leds.

I'll be tackling some of these items later. Stay tuned.....

FM

Hi,

I saw all your changes. greatz

-I replaced tabs by white spaces, because the indentation seems to be crazy with tabulations set to 4
(Do not use tabs please)

-The commits are on (http://cia.vc/stats/project/tuxdroid)

-For the commit reports on irc, I don't know how to make this.

-IRC is the good way for the developers of this project. We will also add a section in the forum.

-For windows, you need to install MinGWStudio and the libusb win32 1.12. Be carefull with the dongle, the audio interfaces are in conflic with libusb win32, and you must to set your pc audio card as default audio device for avoid the blue screen of the death. Our hardward staff works to this problem.

spaces instead of tabs is a good plan. I'll change my default vi settings to use spaces.

I also found the commits on CIA but apparently last saturday it was not working.
Not sure how to relay CIA commits to irc, but I've been working on openembedded and they had something like that.
It requires a bot in the channel. Not sure if CIA does provide that or if that was a project bot.

IRC: I try to get on it when I am under linux. However, I have yet to see any activity.

Windows: guess I'll leave that part to someone else. Never used MinGW.

BTW: for application projects it might be interesting to use wxwidgets. They support both C and Python bindings and run on both windows and linux (www.wxwidgets.org)