hehe i was also a bit bored:

1. class Line{
2.   float angle;
3.   float x,y,vx,vy;
4.   color c;
5.   Line(){
6.     x = random(width);
7.     y = random(height);
8.     float temp = random(TWO_PI);
9.     vx = cos(temp);
10.     vy = sin(temp);
11.     c = color(random(255),random(255),random(255),30);
12.   }
13.   void tick(float dAngle){
14.     if(dAngle-angle >PI){
15.       angle += TWO_PI;
16.     }else if(dAngle-angle <-PI){
17.       angle -= TWO_PI;
18.     }
19.     angle += (dAngle-angle)/20;
20.     x += vx*3;
21.     y += vy*3;
22.     if(x>width||x<0)vx = -vx;
23.     if(y>height ||y<0) vy =-vy;
24.     stroke(c);
25.     line(x-cos(angle)*50,y-sin(angle)*50,x+cos(angle)*50,y+sin(angle)*50);
26.   }
27. }
28. float destAngle;
29. ArrayList lines;
30. void setup(){
31.   size(650,600);
32.   smooth();
33.   strokeWeight(2);
34.   lines = new ArrayList();
35.   for(int i = 0; i< 10;i++){
36.    lines.add(new Line());
37.   }
38.   background(0);
39.   stroke(255,20);
40. }
41. void draw(){
42.   for(int i = 0; i< lines.size();i++){
43.    ((Line)lines.get(i)).tick(destAngle);
44.   }
45. }
46. void mouseMoved(){
47.   if(dist(mouseX,mouseY,pmouseX,pmouseY)>1)
48.     destAngle = atan2(mouseY - pmouseY,mouseX - pmouseX);
49. }

That is a neat and simple solution, assuming it meets the OP's needs; though do you oversimplfy in one respect.  Whilst it's perhaps unlikely to happen you don't take account of the possibility of mouseX == pmouseX.  So perhaps this would be more foolproof:

1. void mouseMoved() {
2.   ellipse(mouseX, mouseY, 5, 5);
3.   // find direction
4.   if (mouseX > pmouseX) {
5.     currDirection = "left to right";
6.   }
7.   else if (mouseX < pmouseX) {
8.     currDirection = "right to left";
9.   }
10.   else {
11.     currDirection = "no horizontal motion";
12.   }
13. }

Mind you, since we're dealing with mouse motion we're dealing with user input... and users don't necessarily have frame level control over the mouse.  As an example someone could be moving the mouse to the left but 'twitch' at which point this frame-level approach would register motion to the right.  If you've got this hooked up to some kind of visual feedback you'd then see some unpleasant jitter; which is why smoothing is probably a good idea...

Actually my OpenProcessing example demonstrates this issue: when you bring the mouse to a stop it's not unusual for your hand to overcompensate and draw it back slightly in the opposite direction and the system registers this as a separate move event.  Ideally I should have incorporated something to avoid this happening (probably a short time-delay before a new mouse move event could be registered).

Obviously this is all rather academic...  though at the very least it does highlight the need for questions to be put into some kind of context ;)