ThinkingRock Forum

Hi all,

first off, thanks for the magnificent app. I like some features alot, others less. But more of that later.

Right now, I can't productively use tr as the keyboard sometimes gets locked and no further input can be made. The mouse still works (though the highlighted part stays highlighted on clicking another textbox) but the keyboard won't type a thing.

I'm on

Product Version: ThinkingRock 2.2.1
Java: 1.6.0_10; Java HotSpot(TM) Client VM 11.0-b15
System: Linux Version 2.6.28-11-generic läuft auf i386; UTF-8; de_DE (tr)
Benutzerverzeichnis: /home/aegidel/.thinkingrock/tr-2.2.1

and my project files are in another 'hidden' directory that gets regular backups: ~/.trdata09/

This is running under Ubuntu-spinoff 'crunchbang' and on a Samsung NC10.

Reproducing it is difficult as it happens at different places in the UI. It usually starts with "New action", then "Description" gets highlighted with text "New Action". No clicking, tabbing or the like allows input.

I have found out a sometime-solution. Maximizing the action (click on far right) maximizes the action and restores the keyboard input. Going back to minimized keeps keyboard working, usually until I either create a new action or want to edit the description of an existing one.
Sometimes it also restores keyboard if clicking from Projects to Action or Reference etc..
Otherwise: restart the app.

Can anyone confirm this behaviour/ fix it? cos this is annoying and i don't get anything done :o)

Cheers
c

ps: happens in project-view and action view so far.

You are the first person reporting the problem. Which file did you download?

_________________
Claire
ThinkingRock Analyst and Tester

Hi Claire, thanks for looking into this.

I downloaded http://ovh.dl.sourceforge.net/project/t ... 2.1.tar.gz on 2009-08-29 16:10, file size is 38697846 and md5sum is a3d1405559becd7796eb931f1a324ea6

I have no compiz or the like running.

I will try on another "pure" ubuntu this afternoon with the same installation. just copying /opt/tr... and ~/.thinkingr... as well as data files should be fine, no?

Thanks,
c

Should be ok to copy .thinkingrock as well, however, I suggest you try it without doing this first just in case it causes a problem.

_________________
ThinkingRock Developer

I can confirm this behavior and perhaps add a bit more information. I also experience a lookup of the key board. I can reproduce this behavior by:

- Begin filling in details for an action using "Process Thoughts"
- Keyboard works fine
- Set Status to "Scheduled" and select a date
- Keyboard is now locked
- Select the "Process Thoughts" icon using the mouse
- Keyboard returns to normal

I've encountered this bug in other situations (including project view and action view), but I think they all have to do with selecting a date. I'll key my eye out for any others.

Here are my vitals:

- Product Version: ThinkingRock 2.2.1
- Java: 1.6.0_13; Java HotSpot(TM) Client VM 11.3-b02
- System: Linux version 2.6.28-16-generic running on i386; UTF-8; en_US (tr)
- Userdir: /home/rshea/.thinkingrock/tr-2.2.1

The md5sum of the tarball I'm working from is 218da581dc69b192aa462b6260b3524e. I downloaded it on Jan. 26, 2010 using the following URL:

http://iweb.dl.sourceforge.net/project/thinkingrock/ThinkingRock/TR%202.2.1/tr-2.2.1-with-jre.tar.gz

I'm running on an up to date Ubuntu Jaunty install.

Not sure if this contributes to my problems, but I thought I should note that to use the application I explicitly set the AWT_TOOLKIT environment variable. This is due to a bug that causes problems with the Awesome window manager. I've experienced this problem with other Java applications running in Awesome and explicitly setting AWT_TOOLKIT has worked fine for those applications. From the Awesome documentation:

Hi rshea,

thanks for confirming!

Unfortunately, i didn't follow up on this atm as there were other pressing issues (that haven't really gone away). But: As far as I remember, using openbox & gdm i also set AWT_TOOLKIT back then. In the meantime, I've refrained from using Compiz and reverted to using no desktop effects at all, also not using the AWT_TOOLKIT workaround. Since then, at least my other java apps seem to behave more friendly.

Once I have the time, i'll look into this in more detail. Would be great if your information provided the necessary steps for getting a patch out!

Thanks
c