testing
alpha
I have done a test on python-whiteboard
and it works very welltt
I have only a point; why the move only
button is locked?
I think that can be selected or deselected at runtime
it is useful if a people want show some point without press
I think that this option might remain in the main window
I think that a good important point will be the handling
of the wiimote address and label in the profile
An other issue is try to see what happen if two wiimotes
are trying to sychronize at the same time
(the driver could ask which wiimote do you want)
Cheers bye
Pere Negre
> I have only a point; why the move only
> button is locked?
Fixed. Now you can change the cursor behavior even when it is active.
> I think that a good important point will be the handling
> of the wiimote address and label in the profile
>
> An other issue is try to see what happen if two wiimotes
> are trying to sychronize at the same time
> (the driver could ask which wiimote do you want)
This is slightly more complicated. This only can happen when the user
has selected "All devices" from the authorized devices list.
Imagine the situation: two (or more) wiimotes are in discovery mode at
the same time. The program detects all of them and present a list to
the user. Then, the user has to select his/her device based on the MAC
address (if he is a non-technical person, maybe he doesn't understand
that notion), and then it has to put again the wiimote in discovery
mode. A little messy... I'll think of a solution. I am aware that now,
if there are more than one device avaliable, picks one at random (not
the right thing either).
Implementing this feature also complicates a bit the code (thread
syncronization, etc...). I'll look at this issue tomorrow.
--
Pere
al...@paranoici.org
Pere Negre <pere....@gmail.com> ha scritto:
> On Tue, Aug 10, 2010 at 10:35 PM, alpha <al...@paranoici.org> wrote:
> > I have only a point; why the move only
> > button is locked?
>
> Fixed. Now you can change the cursor behavior even when it is active.
>
> > I think that a good important point will be the handling
> > of the wiimote address and label in the profile
> >
> > An other issue is try to see what happen if two wiimotes
> > are trying to sychronize at the same time
> > (the driver could ask which wiimote do you want)
>
> This is slightly more complicated. This only can happen when the user
> has selected "All devices" from the authorized devices list.
>
> Imagine the situation: two (or more) wiimotes are in discovery mode at
> the same time. The program detects all of them and present a list to
> the user. Then, the user has to select his/her device based on the MAC
> address (if he is a non-technical person, maybe he doesn't understand
> that notion),
Yes but it possible that the wiimote has a label; I'm thinking
in the school or in the office
You have already introduced in the program some wiimote mac address
and label.
The teacher Jonh connect at the start of the lesson and see Paul and
Jonh and select John in the other case the program could erroneously
connect to Paul
The MAC address is a difficult notion but no more than a phone number,
I think that the program might systematically ask if the user want label
the unknown wiimote each time that discover a new one (in the all
device also)
The driver might prefer the stored and labeled wiimote rather then the
new one.
I try to make some use cases:
UC1) The user is the "first time" (no setting or empty knowledge base)
that use the python-whiteboard
- ask to keep pressed the 1 & 2 (the wiimote will be in a
continuos discovery)
- start the scan
- list the devices
- for each device
- if it is possible connect to the device
- connect
- show the mac address
- ramble the wiimote (this give a feedback to the user to
concretize the mac address concept)
- ask if the user want allow the device
- if yes
- ask and store the wiimote label (associated with the mac)
- start calibration
- ...
- if no disconnect and continue to the other device
- else continue with the next device
UC2) It is not the first time
- ask to press 1 & 2
- start the scan
- if it is found one of the allowed device, it take the first in the
allowed device, make the connection
- visualize the mac and the label of the connected device
- calibration
- ...
I think that this use cases are all for the major of need.
Can be useful in the allowed device allow to move up or down the
wiimote items and use allowed device list such as a priority list
The preferred wiimote will be moved up
Thinking to the connection option I see three different options
O1) All devices (all the devices discovered are allowed)
O2) Allowed devices
O3) Fix device (allowed device equals to 1 item)
For O1 and O2 it is possible to use the UC1
the O3 is easy
I see in the connection two different critical scenarios:
S1) Two wiimote in discovery mode when the python-whiteboard try to
connect all devices (O1) or allowed devices (O2) and the list of the
devices is greater than 1.
The UC1 might solve this scenario
S2) What happen if the user want change wiimote?
The same computer is used with different wiimote.
A personal profile might fix this problem.
It also possible that an other allowed device is in discovery mode
in a closed place...
I have not a complete idea I have written this to try to think to the
user experience starting from use cases. We can discuss also about
which cases we can handle or not
> and then it has to put again the wiimote in discovery
See in the UC1 this might solve!
ask to keep pressed the 1 & 2 (the wiimote will be in a
continuos discovery)
> mode. A little messy... I'll think of a solution. I am aware that now,
> if there are more than one device avaliable, picks one at random (not
> the right thing either).
The random is not a great think a first automatic choice can be done
choosing the closest wiimote, it can be done approximatelyt aking the
wiimote the with a best signal in a similar way to the wifi wireless
connection programs. The other proposal for the allowd devices is have
a priority list.
>
> Implementing this feature also complicates a bit the code (thread
> syncronization, etc...). I'll look at this issue tomorrow.
>
Yes it could complicate the code but a think that this can be a great
added value.
We are thinking about this issue I think that we can arrive to a good
and simple solution
I want underlie an other time that at the moment the usage of wiimote
in adjacent classroom or the usage of many wiimote with the same
computer (think about a classrom with a computer and each teacher has
his wiimote) are problems and I'm sure that can be solved
Ok, bye
--
Pere Negre
A few changes in the code. Now it detects multiple wiimotes and
presents a list to the user, who may choose the appropiate device.
It's not finished yet. But it works somehow.
I've found a very strange thing: even I keep pushing buttons 1+2 in
the wii devices, most of the time the libraries only detect one of
them. I don't know why this happens.
It takes many tries in my computer to actually detect more than one
device. I've done some limited testing, and I think it works in a
basic way.
Can you test it, Pietro? I wonder if other combinations of hardware
have this problem, too.
--
Pere
Pere Negre
--
Pere
al...@paranoici.org
Pere Negre <pere....@gmail.com> ha scritto:
> Uf.
>
> A few changes in the code. Now it detects multiple wiimotes and
> presents a list to the user, who may choose the appropiate device.
Good, I have not two wiimote I must wait a my collegue to test it
>
> It's not finished yet. But it works somehow.
>
A good start if a success if you know where is the goal
> I've found a very strange thing: even I keep pushing buttons 1+2 in
> the wii devices, most of the time the libraries only detect one of
> them. I don't know why this happens.
I'll study this. I have proposed to keep pushed the button to avoid to
join to an other wiimote that is in discovery mode...
>
> It takes many tries in my computer to actually detect more than one
> device. I've done some limited testing, and I think it works in a
> basic way.
>
> Can you test it, Pietro? I wonder if other combinations of hardware
> have this problem, too.
>
I think that i will able to test this only in september
An other little strange info; do you remember the segmentation fault a
the quit,
this occurs only in one of the two my computer (and the distro is the
same Ubuntu Lucid and also in 64bit)
Bye
--
Pere Negre
<al...@paranoici.org> wrote:
> I think that i will able to test this only in september
Ok. I can't do much more testing with the material I have right now.
We'll wait a few weeks to see if someone says something.
> An other little strange info; do you remember the segmentation fault a
> the quit,
> this occurs only in one of the two my computer (and the distro is the
> same Ubuntu Lucid and also in 64bit)
It's strange indeed. I run Debian testing 32bit in my two computers
and I don't get this error. Let's hope that's a library bug.
--
Pere
alpha
Pere Negre <pere....@gmail.com> ha scritto:
> Forgot to push the changes to the server. Now the git repository is
> updated.
>
Hi Pere I have tested the code to
add a know device at the next connection give the error
============================================================================
Unexpected error: <type 'exceptions.TypeError'>
Traceback (most recent call last):
File "/usr/lib/python-whiteboard/threads.py", line 11, in run
func()
File "/usr/lib/python-whiteboard/wiimote.py", line 220, in func
self.bind(selectedmac)
File "/usr/lib/python-whiteboard/wiimote.py", line 108, in bind
self.wii = cwiid.Wiimote(self.addr)
TypeError: cwiid.Wiimote.init() argument 1 must be string, not QString
Segmentation fault
=============================================================================
I have fixed changed the line 108 of wiimote.py
from
self.wii = cwiid.Wiimote(self.addr)
to
self.wii = cwiid.Wiimote(str(self.addr))
Sorry can I have further information about your environment
(it seems different)
- python interpreter version
- python cwiid bindings
- libcwiid version
I have
-python 2.6.5
-python-cwiid 0.6.00+svn201-2
-libcwiid 0.6.00+svn201-2
Thanks bye
Pere Negre
(lines 107 - 108) wiimote.py
self.addr = str(addr)
self.wii = cwiid.Wiimote(self.addr)
I have:
Python 2.6.5+
python-cwiid 0.6.00+svn201-2+b2
libcwiid1 0.6.00+svn201-2+b2
--
Pere
alpha
Pere Negre <pere....@gmail.com> ha scritto:
> Forgot to push the changes to the server. Now the git repository is
> updated.
>
Hi, the profile in the advanced menu does't work for me
Is it a stub??
What is this profile? It is the selection of an other configuration
I am continuing to thing about the connection stuff also to support
multiple user and wiimotes
I think that everytime that a new wiimote
is discover can be ask to the user if he want add this
in the authorized drivers
When the program start we are three possibility:
1) No preferred device and then all device are good
2) One item then will connect to this
3) More item then can be asked to the user
which is device to be connected
Only a linguistic consideration can be better
talk about "preferred devices" instead of "allowed devices"
In this way I hope that are handled the greater number of uses case
without complicate the interface
What do you think about?
I am also thinking about the possibility to have
different configuration file for each user,
I don't know if it is your profile implementation
but I have some doubts about this, the program has
no more options the handling of multiple configuration
can be overkilling
A simple way to handle this is give the possibility
to save a setting with a name and then loading
The most important think is think to give a semantic
to the configuration file
Does exist a file for each user?
If the reply is yes each user will have a file
in this one the mac of the used wiimote
At the startup the tool if exists more setting file
will ask which file must use
Thanks bye
Pere Negre
> Hi, the profile in the advanced menu does't work for me
> Is it a stub??
> What is this profile? It is the selection of an other configuration
Not implemented yet. I'm working on it.
> I think that everytime that a new wiimote
> is discover can be ask to the user if he want add this
> in the authorized drivers
Yes, good suggestion. We can have a "check" in the mac selection when
there are two or more wiimotes discovered.
Doing this action when only one device is detected, I think it will
confuse the user. The way it works now, the user has no need to touch
the computer keyboard. Simply starts the program, press buttons 1+2 on
the wiimote, and calibrate.
> When the program start we are three possibility:
> 1) No preferred device and then all device are good
> 2) One item then will connect to this
> 3) More item then can be asked to the user
> which is device to be connected
That is the way it works now, I think.
> Only a linguistic consideration can be better
> talk about "preferred devices" instead of "allowed devices"
Yes, it's a semantic appreciation. I think the "allowed" is more
acurate with the functionality, because you are forbidding devices
that do not have the MAC you choose from connecting to the computer. A
minor issue. Allowed and preferred should be understandable to the
users in the same manner. That's my opinion.
> In this way I hope that are handled the greater number of uses case
> without complicate the interface
>
> What do you think about?
I think we need more testing. In september we plan to deploy the
program in four or five classrooms in the school I work. We'll see.
Let's have some feedback from the users (teachers) and we will have
elements to decide what directions we should take.
> A simple way to handle this is give the possibility
> to save a setting with a name and then loading
>
> The most important think is think to give a semantic
> to the configuration file
Yes. This can be done in this way.
In the implementation I'm thinking now is to use the qsettings
"groups". It should not be very difficult to make the thing work.
Expect news soon.
> Does exist a file for each user?
> If the reply is yes each user will have a file
> in this one the mac of the used wiimote
The profile will include all the program options: authorized device
list, preferences...
> At the startup the tool if exists more setting file
> will ask which file must use
It's a good idea. Imagine a teacher having three or four profiles in
his/her laptop. When entering a class, initiate the program and choose
the appropiate profile.
--
Pere
al...@paranoici.org
Dear Pere
I have some news about testing
I have seen that sometimes the calibration fail
To repoduce the error you must start the calibration
and when you push the button and lease it
sometimes the calibration windows freeze
If you push esc and recalibrate you can continue to use
python-whiteboard and retry
An other issue;
I think that if the wiimote lost the connection
for low battery, because of the user switch-off the wiimote or for others
reasons
could be a good think if the python-whiteboard continue to try to connect
to the wiimote; in this way when the user will resynchronize the wiimote
all will work fine
An other last minor issue I am not able to generate the translation file
correctly
running the generate_trans.sh
The problem is that the my pylupdate doesn't support the option that you
are passing
and seems that it take a qt project file in input and not the file list
This is a man extract:
================================================
SYNOPSIS
pylupdate [ options ] project-file...
================================================
Anywayn Can I ask you to regenerate the translation file before all
commit?
In this way I will update the italian translation
A little info I have bought a wiimote clone called woomote
and it works fine with the python-whiteboard software
Now I am able to test if multiple wiimote are handled in a correct way
I'll be at work from the first of September (now I'm in holliday) and I
will have more time to
make a better test
Cheers bye.
Thanks, bye
On Thu, 12 Aug 2010 02:18:20 +0200, Pere Negre <pere....@gmail.com>
wrote:
Pere Negre
> I have seen that sometimes the calibration fail
> To repoduce the error you must start the calibration
> and when you push the button and lease it
> sometimes the calibration windows freeze
You mean the button in GUI or the "A" button in the wiimote? I'm
unable to reproduce the bug you mention. But again, I will be doing
more testing in september. I'm on vacation too now.
> An other issue;
> I think that if the wiimote lost the connection
> for low battery, because of the user switch-off the wiimote or for others
> reasons
> could be a good think if the python-whiteboard continue to try to connect
> to the wiimote; in this way when the user will resynchronize the wiimote
> all will work fine
Good suggestion. In my school we will be using the wiimote with a
power unit permanently plugged in (so, no dead batteries anymore). For
a fixed installation, this is what I recommend.
Anyway, it's simple to implement that feature. I'll do it.
> Anywayn Can I ask you to regenerate the translation file before all
> commit?
> In this way I will update the italian translation
Updated the trans files in the git repository.
> A little info I have bought a wiimote clone called woomote
> and it works fine with the python-whiteboard software
>
> Now I am able to test if multiple wiimote are handled in a correct way
Good news.
--
Pere
al...@paranoici.org
On Thu, 26 Aug 2010 11:57:38 +0200, Pere Negre <pere....@gmail.com>
wrote:
> On Tue, Aug 24, 2010 at 10:24 PM, <al...@paranoici.org> wrote:
>> I have seen that sometimes the calibration fail
>> To repoduce the error you must start the calibration
>> and when you push the button and lease it
>> sometimes the calibration windows freeze
>
> You mean the button in GUI or the "A" button in the wiimote? I'm
> unable to reproduce the bug you mention. But again, I will be doing
> more testing in september. I'm on vacation too now.
No in the fullscreen calibration sometimes the round circle remain
partially filled and the windows is freeze, also other theachers
has the same problem
The problem appears only sometimes it seems a race condition,
if I press ESC and redo the fullscreen calibration sometimes
I am able to do the calibration fine
Try to do the fullscreen calibration leasing the button
before that the circle is full filled more time and I think
that you can reproduce the problem
>
>> An other issue;
>> I think that if the wiimote lost the connection
>> for low battery, because of the user switch-off the wiimote or for
others
>> reasons
>> could be a good think if the python-whiteboard continue to try to
connect
>> to the wiimote; in this way when the user will resynchronize the
wiimote
>> all will work fine
>
> Good suggestion. In my school we will be using the wiimote with a
> power unit permanently plugged in (so, no dead batteries anymore). For
> a fixed installation, this is what I recommend.
Good issue the power unit can you send me more information about the
device
that you are using
Do you know if your power unit is able to charge the battery when the
wiimote is active
(to see this can you try to put low power batteries to test it)
>
> Anyway, it's simple to implement that feature. I'll do it.
>
An other time thanks a lot of your precious work
>> Anywayn Can I ask you to regenerate the translation file before all
>> commit?
>> In this way I will update the italian translation
>
> Updated the trans files in the git repository.
>
Thnx
>> A little info I have bought a wiimote clone called woomote
>> and it works fine with the python-whiteboard software
>>
>> Now I am able to test if multiple wiimote are handled in a correct way
>
> Good news.
Cheers bye
matt ledding
Just got a (non-MS stack) BT adapter for Linux, and off to get things fired off. Now to get involved in the "English improvement" part, and working on some documentation.
For getting things powered and permanently set up have you checked "deal extreme"? If you don't want to get into modding the hardware like in There is a usb charged battery that should work in a permanent installation. (I think... there are two types, one that you can use while playing and one that you use unplugged. I believe this is the good one.) http://www.dealextreme.com/details.dx/sku.30771
Deal extreme has imitation wiimotes for under 20$ us.
I have previously ordered a lot of bt adaptors for under 3$ and they worked pretty good for me (MS Stack.) Shipping takes a month or two, but is free.
Pere Negre
> Hello, I am back from vacation, and looking at all your great work.
>
> Just got a (non-MS stack) BT adapter for Linux, and off to get things fired
> off. Now to get involved in the "English improvement" part, and working on
> some documentation.
Welcome back, Matt! It's great to hear from you again.
> For getting things powered and permanently set up have you checked "deal
> extreme"? If you don't want to get into modding the hardware like in
> There is a usb charged battery that should work in a permanent installation.
> (I think... there are two types, one that you can use while playing and one
> that you use unplugged. I believe this is the good one.)
> http://www.dealextreme.com/details.dx/sku.30771
We bought the kit advertised in http://www.3pinteract.co.nz/
There are more alternatives:
http://teachwithtech.com/Deluxe-Classroom-Bundle-p32.html
http://www.irgreat.com/kits.htm
First thing in september is to test this hardware for a fixed
installation on a class. We'll see if the teachers find the system
easy to work with.
> Deal extreme has imitation wiimotes for under 20$ us.
> I have previously ordered a lot of bt adaptors for under 3$ and they worked
> pretty good for me (MS Stack.) Shipping takes a month or two, but is free.
Thank you for the info. Very interesting. Pietro said that a wii clone
called "woomote" work well with the software too.
--
Pere
matt ledding
Hello Pere,
The Pinteract whiteboard kit looks great... While you can cut costs further, and the BT dongles look very dealxtreme.com (at 1,86 dollars, I seem to remember.) I haven't seen the wireless connect before, very cool. Things are advancing.
There is a new program out to also look at in Windows, looks fancy, will check it out: http://www.iwiiboard.com/
Looks like it is maybe a bit "fluffy", but it looks very pretty, and that sells.
If you'd like me to send a homemade pen, I can mail you one and give instructions on making them. (I have done workshops showing smoothboard and how to make the pens as a free add on when I do English language shows in Spain... they are not hard to do, one of the most beautiful moments in my life was seeing a near retirement Spanish nun using a soldering iron.) It could be a good project for high schoolers, as they can make their own system then.
Speaking of tricks, just heard a new one for calibrating the wiimote: put a lazer pointer on the wiimote to check if it is pointed directly at the center. so you don't go back and forth moving around. Thought it was a neat hack.
Matt
Pere Negre
>
> Hello Pere,
>
> The Pinteract whiteboard kit looks great... While you can cut costs
> further, and the BT dongles look very dealxtreme.com (at 1,86 dollars, I
> seem to remember.) I haven't seen the wireless connect before, very cool.
> Things are advancing.
It seems so. We ordered that kit three months ago (before summer
vacation). Didn't have much time to test it properly. Next week I'll
be at work again. We'll see how it works for the teachers.
> There is a new program out to also look at in Windows, looks fancy, will
> check it out: http://www.iwiiboard.com/
> Looks like it is maybe a bit "fluffy", but it looks very pretty, and that
> sells.
I didn't heard of this software before. Anyway, at the school I work,
we'll be using linux-only laptops next year. So I think we'll use
python-whiteboard if it proves to be stable.
> If you'd like me to send a homemade pen, I can mail you one and give
> instructions on making them. (I have done workshops showing smoothboard and
> how to make the pens as a free add on when I do English language shows in
> Spain... they are not hard to do, one of the most beautiful moments in my
> life was seeing a near retirement Spanish nun using a soldering iron.) It
> could be a good project for high schoolers, as they can make their own
> system then.
Hehe... that should have been funny, for sure. As I work as a
professor (high school), I do this activity every year. We google for
instructions to make ir pens and every group of students come with
their own design. It's a very entertaining class.
> Speaking of tricks, just heard a new one for calibrating the wiimote: put a
> lazer pointer on the wiimote to check if it is pointed directly at the
> center. so you don't go back and forth moving around. Thought it was a neat
> hack.
Yeah, that's a good trick. If you're carrying your wiimote (with a
little tripod), it makes sense to attach the laser pointer to position
it without wasting too much time setting things up.
--
Pere