Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Focus Bug #13

Closed
GoogleCodeExporter opened this issue Apr 24, 2015 · 5 comments
Closed

Focus Bug #13

GoogleCodeExporter opened this issue Apr 24, 2015 · 5 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. Click on Ardesia ribbon
2. Click on an application window and try to draw

What is the expected output? What do you see instead?
1.  Focus reverts to application window most of the time; I cannot say why
it sometimes remains with ardesia, but mostly not.
2.  Clicking on the desktop background first (i.e. ardesia's transparent
window, right?) seems to solve the problem temporarily - I can then draw
over my application windows.

What version of the product are you using? On what operating system?
Using r760 (I like the new thickness button, by the way!) on Ubuntu Lucid.
Apart from this bug, Ardesia seems stable and usable with this version (no
freezes or segfaults yet) - bravo!

Please provide any additional information below.


Original issue reported on code.google.com by daybir...@gmail.com on 19 May 2010 at 5:55

@GoogleCodeExporter
Copy link
Author

I'm very happy that you confirm that the program is now more stable.
In any case I want ask you which type of input driver are you using.


It is possible from your description that the input device do not send 
the click event.
And then you see the pushed focused ribbon but it is not been clicked.

The gtk click is the push-release combination.
In the case in witch you are using Ardesia with a tablet or a whiteboard or
a wiimote driver can you test if the program has the same behavior used with
a mouse.

I hope that you are not using the uwesmidth wiimote whiteboard
because with this program it is sure that you lost a lot of IR pen event


In the case that the user want to push the button but this fail,
Ardesia remains without the focus and the pointer will be free to go around the 
other
windows.

Ardesia infact now ungrab the pointer all the time that the cursor it is over 
the bar.

This is useful with the mouse but I don't know if it is better let only the 
unlock
button in the ardesia bar for this purpose or not.

In any case I'll confirm the bug only in the case that you are using the mouse
but if you are using the perenegre whiteboard such as explained at the page
I'll try to help you
http://code.google.com/p/ardesia/wiki/CreateWiimoteWhiteboard 

In any case specify the input device too

Cheers bye



Original comment by al...@paranoici.org on 19 May 2010 at 11:39

@GoogleCodeExporter
Copy link
Author

Thanks very much.  You're quite correct, I was using the Uwe Schmidt 
whiteboard.  I
installed the perenegre program and it works very well with Ardesia.  I'm doing 
a
small Wiimote Whiteboard demo for some IT folks at my university on Monday, so 
I'm
excited to be able to use Ardesia for this.  Thanks again.

Original comment by daybir...@gmail.com on 20 May 2010 at 4:32

@GoogleCodeExporter
Copy link
Author

A lot of time do the soothsayer works fine for this.
Only an other question have you tried the other tools in the Ardesia
trunk such as the florence-ramble that is a keyboard that it works with
stroke.

Cheers bye, Thanks for the feedback

Original comment by al...@paranoici.org on 20 May 2010 at 8:13

@GoogleCodeExporter
Copy link
Author

If you are interested to use the uwe whiteboard you might tarck the problem
in the uwe website

Original comment by al...@paranoici.org on 20 May 2010 at 8:15

@GoogleCodeExporter
Copy link
Author

Original comment by al...@paranoici.org on 20 May 2010 at 7:07

  • Changed state: Done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant